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 已赚取工资服务的基础计算为：

可领取金额 =（已审批工作日数 × 日工资）− 本周期已领取金额 − 企业规定的预留金额。

然后再评估其他使用条件。

为什么要在申请时重新检查？

应用程序显示的“符合条件”状态可能已经过时。

从员工打开页面到点击确认之间，可能发生：

• 工作记录被修改；
• 另一笔交易刚刚成功；
• 员工状态发生变化；
• 账户不再有效；
• 政策进入新版本；
• 之前的交易仍在等待处理。

因此，服务器必须在创建申请时重新评估条件。

界面只应显示资料，最终决定必须依据服务器的最新数据。

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 · 企业已赚取工资服务