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 · 企業已賺取薪金服務