How does an Eligibility Engine determine conditions and limits?

An Eligibility Engine checks EWA usage conditions when a worker submits a request. It does not create earned pay. Instead, it receives the calculated earned-pay result and applies profile status, employer policy, usage limits and control conditions to determine whether and within what scope the request may proceed.

What question does an Eligibility Engine answer?

Two questions in EWA are easily confused:

1. How much pay has the worker earned from approved work?
2. At this moment, is the worker eligible to use the service, and how much may they receive?

The first question belongs to the Earned Wage Engine. The second belongs to the Eligibility Engine.

Separating these layers prevents the system from confusing value already created through work with permission to use a financial feature.

A worker may have approved workdays but may not have completed profile requirements. Conversely, the profile may be complete while there is not yet enough eligible earned pay.

Six groups of conditions commonly checked

A good Eligibility Engine should organize conditions into groups with clear business meaning.

Check group	Question to answer	Data source
Worker status	Is the profile active and within the applicable scope?	HRM/ERP
Work and earned pay	Has eligible earned pay been generated?	Earned Wage Engine
Employer policy	Has the policy been enabled for this workplace?	Policy/configuration
Identity and account	Has the receiving profile been verified?	Identity/account
Usage limits	Is the current request within the permitted scope?	Policy + transaction ledger
System status	Is there a condition requiring a stop or hold?	Transaction/monitoring

Each condition must have a clear data source and owner.

If a rule relies on data without a source of truth, it is difficult to explain why a worker was rejected or limited.

A limit is a policy outcome, not earned pay

In EWA, a “limit” should not be understood as a separate amount granted to a worker in advance.

The Earned Wage Engine first determines the pay already earned.

The Eligibility Engine can then apply rules that narrow the permitted usage scope, but it should not create a value greater than the eligible earned pay.

The relationship can be expressed as:

Usable value ≤ Eligible earned pay already generated

For Nhan Kiet's earned wage access service, the basic calculation is:

Available amount = (approved workdays × daily pay rate) − amount already received in the period − reserve required by the employer.

Other usage conditions are evaluated afterward.

Why recheck at request time?

An “eligible” status shown in the app may already be stale.

Between opening the screen and confirming a request, any of the following may occur:

• a work record is edited;
• another transaction succeeds;
• worker status changes;
• the account is no longer valid;
• the policy moves to a new version;
• a previous transaction remains pending.

The server must therefore reevaluate eligibility when the request is created.

The interface should only display information; the final decision must use the latest server data.

How does the Eligibility Engine differ from the Earned Wage Engine?

Layer	Main question	Key data
Earned Wage Engine	How much earned pay has been generated?	Work, rate, amount received, reserve
Eligibility Engine	May this person currently use the service, and within what scope?	Profile, policy, limits, account
Payment Orchestration	How will a valid request be processed as a transaction?	Transaction ID, status, bank

Separating the three layers gives each one a clear responsibility.

If work changes, the Earned Wage Engine recalculates. If policy changes, the Eligibility Engine reevaluates. If the banking network times out, Payment Orchestration manages the transaction status.

Policies need versions and effective dates

A common design error is to store only the “current policy”.

Months later, the employer may be unable to explain why an earlier transaction was permitted while a similar transaction at another time was not.

Each rule set should include:

• a version code;
• effective date and time;
• scope;
• creator;
• approver;
• reason for the change;
• active/inactive status.

When a request is evaluated, the system should retain a trail of the policy version used.

When should the Eligibility Engine stop?

If important data is not sufficiently certain, the engine should not grant access automatically.

Examples include:

• the previous transaction status is unclear;
• source work records conflict;
• the receiving account is invalid;
• the profile is no longer active;
• the applicable policy version cannot be determined;
• a source system fails to respond in a verifiable way.

In these situations, the safe design is to hold the request for review rather than assume everything is valid.

This is the same fail-closed principle used in money-processing systems.

Reason codes matter as much as the result

The Eligibility Engine should not return only:

• true;
• false;
• a number.

It should return structured reasons, such as:

• no approved workdays;
• profile not verified;
• feature not enabled by the client;
• request exceeds the permitted scope;
• a transaction is pending;
• account reverification is required.

Reason codes help:

• the interface explain the result to users;
• support teams investigate;
• operations classify errors;
• teams measure statistics;
• auditors review decisions.

Sensitive technical details need not be disclosed, but users should know what to do next.

How should employers govern the Eligibility Engine?

The Eligibility Engine should be treated as an executable policy, not merely a piece of code.

Every important rule should have:

• a business owner;
• a data source;
• an effective date;
• a reason for existence;
• a scope;
• an exception-handling method;
• a change history.

Product and payroll teams need a common boundary between earned pay and the amount permitted for use.

Operations teams need to know why a request was held.

Support teams need sufficiently clear reason codes to explain outcomes without accessing sensitive technical configurations.

KPIs to monitor

Possible measures include:

• eligibility rate;
• hold rate due to missing approved work;
• hold rate due to profile or account status;
• requests blocked because a transaction is pending;
• number of policy changes;
• complaints about eligibility;
• decisions with complete reason codes;
• exceptions requiring manual handling.

KPIs should not be optimized toward “allow as many transactions as possible”. The goal is to be eligible, explainable and consistent.

Conclusion

The Eligibility Engine helps EWA separate two issues: earned pay already generated and the right to use the service at a specific time. A good engine reevaluates conditions at request time, uses versioned policies, returns clear reason codes and stops when important data is uncertain. This allows employers to change policy while preserving payroll integrity and explainability for workers.

Author: Do Huy Le — General Director, Nhan Kiet Manpower Supply Co., Ltd.

Earned wage access advice for employers: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned wage access for employers