Eligibility Engine 如何判定使用條件與限額？

Eligibility Engine 是在員工提出申請時檢查 EWA 使用條件的決策層。它不會產生薪資，而是接收已計算的已賺取薪資結果，再套用個人資料狀態、企業政策、使用限額與控管條件，以決定申請是否可繼續及允許範圍。

Eligibility Engine 解決什麼問題？

EWA 中有兩個容易混淆的問題：

1. 員工透過已核准工作賺取了多少薪資？
2. 在目前時間，此人是否符合使用資格，允許領取的範圍是多少？

第一個問題屬於 Earned Wage Engine，第二個屬於 Eligibility Engine。

將兩層分開，可避免系統混淆透過勞動已產生的價值與使用某項金融功能的權限。

員工可能已有核准工作日，但個人資料條件尚未完成。反過來，個人資料可能完整，但還沒有足夠的合格已賺取薪資。

通常需要檢查的六組條件

良好的 Eligibility Engine 應把條件整理成具有明確業務意義的群組。

檢查群組	需要回答的問題	資料來源
員工狀態	個人資料是否有效且在適用範圍內？	HRM/ERP
出勤與已賺取薪資	是否已形成合格的已賺取薪資？	Earned Wage Engine
企業政策	該工作地點是否已啟用政策？	Policy/configuration
身分與帳戶	收款資料是否已驗證？	Identity/account
使用限額	目前申請是否在允許範圍內？	Policy + transaction ledger
系統狀態	是否存在必須停止或保留的條件？	Transaction/monitoring

每項條件都必須有明確的資料來源與負責人。

若規則依賴沒有權威來源的資料，系統很難說明員工為何遭拒或受限。

限額是政策結果，不是薪資

在 EWA 中，「限額」不應被理解為預先授予員工的一筆獨立金額。

Earned Wage Engine 會先判定已形成的薪資。

Eligibility Engine 隨後可套用規則來縮小允許使用的範圍，但不應自行產生高於合格已賺取薪資的價值。

可以表示為：

可使用價值 ≤ 已形成的合格已賺取薪資

Nhan Kiet 已賺取薪資服務的基礎計算為：

可領取金額 =（已核准工作日數 × 日薪）− 本期已領金額 − 企業規定的保留額。

之後才評估其他使用條件。

為什麼要在申請當下重新檢查？

App 顯示的「符合資格」狀態可能已過時。

從員工開啟畫面到按下確認之間，可能發生：

• 出勤紀錄被修改；
• 另一筆交易剛成功；
• 員工狀態變更；
• 帳戶不再有效；
• 政策進入新版本；
• 先前交易仍在等待處理。

因此，伺服器必須在建立申請時重新評估條件。

介面只應顯示資料，最終決定必須依據伺服器最新資料。

Eligibility Engine 與 Earned Wage Engine 有何不同？

層次	核心問題	重點資料
Earned Wage Engine	已形成的薪資是多少？	出勤、單價、已領金額、保留額
Eligibility Engine	此人目前是否可使用服務，允許範圍為何？	個人資料、政策、限額、帳戶
Payment Orchestration	有效申請將如何作為交易處理？	交易 ID、狀態、銀行

分開三個層次，可讓各層責任明確。

出勤異動時，Earned Wage Engine 重新計算；政策異動時，Eligibility Engine 重新評估；銀行網路逾時時，Payment Orchestration 處理交易狀態。

政策需要版本與生效日期

常見的設計錯誤是只儲存「目前政策」。

數個月後，企業可能無法說明為何早期交易獲准，而其他時間的類似交易卻未獲准。

每套規則應包含：

• 版本代碼；
• 生效日期與時間；
• 適用範圍；
• 建立者；
• 核准者；
• 變更原因；
• 啟用／停用狀態。

評估申請時，系統應保留所用政策版本的紀錄。

Eligibility Engine 何時應停止？

若重要資料不夠確定，引擎不應自動開放權限。

例如：

• 先前交易狀態不明；
• 來源出勤紀錄相互衝突；
• 收款帳戶無效；
• 個人資料不再有效；
• 無法判定適用政策版本；
• 來源系統未以可驗證方式回應。

在這些情況下，安全的設計是保留申請等待檢查，而不是假設一切正常。

這與資金處理系統採用的失敗時關閉原則相同。

原因代碼與結果同樣重要

Eligibility Engine 不應只回傳：

• true；
• false；
• 一個數字。

它應回傳結構化原因，例如：

• 尚無已核准工作日；
• 個人資料未驗證；
• 客戶尚未啟用功能；
• 申請超出允許範圍；
• 有交易正在等待；
• 需要重新驗證帳戶。

原因代碼有助於：

• 介面向使用者說明結果；
• 支援團隊查詢；
• 營運團隊分類錯誤；
• 統計衡量；
• 稽核決策。

不必公開敏感技術細節，但使用者需要知道下一步該如何處理。

企業應如何管理 Eligibility Engine？

Eligibility Engine 應視為可執行的政策，而不只是一段程式碼。

每項重要規則都應具備：

• 業務負責人；
• 資料來源；
• 生效日期；
• 存在理由；
• 適用範圍；
• 例外處理方式；
• 變更歷史。

產品團隊與薪資團隊需要統一已形成薪資與允許使用部分之間的界線。

營運團隊需要知道申請被保留的原因。

支援團隊需要足夠清楚的原因代碼，以便在不存取敏感技術設定的情況下說明結果。

應追蹤的 KPI

可以追蹤：

• 資格通過率；
• 因缺少已核准出勤而保留的比例；
• 因個人資料或帳戶而保留的比例；
• 因有待處理交易而遭阻擋的申請數；
• 政策變更次數；
• 關於資格條件的申訴數；
• 具有完整原因代碼的決定比例；
• 需要人工處理的例外數。

不應朝「允許盡可能多人交易」的方向最佳化 KPI。目標是條件正確、可說明且一致。

結論

Eligibility Engine 協助 EWA 清楚區分已形成的已賺取薪資與在特定時間使用服務的權利。良好的引擎會在申請時重新評估條件，使用具有版本的政策，回傳清楚的原因代碼，並在重要資料不確定時停止。如此企業可調整政策，同時維持薪資完整性及向員工說明的能力。

作者： Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

企業已賺取薪資服務諮詢： Hotline 0937.022.655 · Email info@nhankiet.vn · 企業已賺取薪資服務