Risk Governance and Fraud Prevention in EWA

To govern EWA fraud risk, a business needs controls across the whole chain — from verifying employees, approved timesheets, and limits, through to receiving accounts, payment instructions, and reconciliation. Three layers matter: prevention through access control and transaction rules; detection through data, alerts, and reconciliation; and response through controlled locking, investigation, reversal, and root-cause remediation. Not every anomaly should be treated as fraud, and funds shouldn't be automatically paid out again while a transaction's outcome is still unclear.

> Note: This article provides a reference governance and technical framework. Alert thresholds, limits, hold periods, investigation procedures, and each party's responsibilities must be approved by the business, the EWA provider, the payment partner, legal, and information security, based on the actual implementation model.

> Glossary: EWA (earned wage access) · HRIS (human resource information system) · payroll (wage calculation) · ERP (enterprise resource planning) · MFA (multi-factor authentication) · risk-based auth (authentication scaled to risk level) · idempotency (duplicate-transaction prevention) · callback/webhook (automated notification between systems) · timeout (a wait period expiring) · false positive (a wrongful block/false alarm) · social engineering (non-technical deception/fraud) · go-live (moving into official operation) · NIST CSF / OWASP ASVS (information-security frameworks and standards).

How Is EWA Risk Different from Loan Risk?

EWA – Earned Wage Access is designed to let employees access a portion of wages they've already earned. So the core risk isn't primarily about "failure to repay a debt" — it's about the system identifying the wrong person, the wrong hours, the wrong limit, the wrong receiving account, or the wrong payment status.

Examples:

• an employee's account is taken over and the receiving account number is changed;

• unapproved timesheet data gets counted into the limit;

• a request is resent after a timeout and results in a duplicate payout;

• an employee has resigned but their HRIS status hasn't been updated;

• a person who can edit timesheets also has the authority to approve transactions;

• a transaction succeeds at the bank but isn't yet reflected in payroll;

• a genuine employee gets wrongly locked out because the alert model is oversensitive.

EWA risk governance therefore has to protect four properties at once:

1. The right person: whoever initiates the transaction is the legitimate account holder.

2. The right entitlement: the amount is calculated from approved data and the current policy.

3. The right recipient: funds go to a verified account.

4. Exactly once: every valid request produces exactly one payment outcome and is fully reconciled.

1. Distinguishing Errors, Abuse, and Fraud

Not every discrepancy is fraud. If the operations team jumps to conclusions too fast, a business risks wrongly penalizing an employee or overlooking a system defect that needs fixing.

A good system should log an event as an anomaly requiring verification before there's enough evidence to conclude it's fraud.

2. A Risk Map Across the EWA Transaction Lifecycle

flowchart TD
    A["Identity & Activation"] --> B["Receive Timesheet/Pay Data"]
    B --> C["Calculate Limit"]
    C --> D["Create Request"]
    D --> E["Transfer Funds"]
    E --> F["Reconciliation & Settlement"]
    F --> G["Monitoring, Disputes & Reversals"]

Each step carries its own risk group:

3. Building an EWA Risk Register

A risk register turns general concerns into concrete ownership and action. Each risk should have:

• a code and a scenario description;

• the asset or process affected;

• the cause and triggering conditions;

• likelihood and impact severity;

• preventive, detective, and corrective controls;

• the data or metric used to monitor it;

• a risk owner;

• residual risk after controls;

• the authorized person who accepts the residual risk;

• the next review date.

Sample Risk Matrix

Don't copy likelihood ratings from another business. Scores need to be based on this program's own workforce size, transaction frequency, automation level, data quality, and incident history.

4. Controlling Identity and Account Takeover

An attacker usually doesn't need to break the limit-calculation logic if they can simply take over a legitimate account. The highest-risk points are usually activation, account recovery, changing phone number, changing device, and changing the receiving account.

Controls at Activation

• cross-check the employee ID against an approved HRIS source;

• verify the contact channel belongs to the employee;

• don't rely on easily guessable information like date of birth or employee ID;

• limit the number of attempts and detect multiple accounts from the same device;

• notify activation through the registered channel;

• keep evidence of the terms version and the time of acceptance.

Controls at Login and Transaction Time

• authentication scaled to the risk level;

• re-authentication before a transaction or a sensitive change;

• detecting new devices, unusual sessions, and repeated failed attempts;

• invalidating old sessions after a password change or a reported lost device;

• immediate notification on a new login or a created transaction;

• letting users report "this wasn't me" through an easily accessible channel.

Account Recovery Must Be as Strong as Login

If a support agent can recover an account with just a few easily guessed questions, every login control upstream can be rendered useless. The recovery process needs multiple pieces of evidence, limited support-agent authority, full logging, and additional approval for high-risk cases.

5. Controlling Changes to the Receiving Account

Changing the payment recipient is the action that can turn a compromised account into actual financial loss.

Recommended controls:

1. re-authenticate the user;

2. verify the new account through an approved method;

3. notify the change through both the old and new channels where appropriate;

4. apply a hold period or enhanced limits based on risk;

5. block the transaction if the change is accompanied by a new device or other unusual signals;

6. don't let one support agent both make and approve the change;

7. keep a history of the masked old value, the masked new value, who made the change, and why;

8. route transactions immediately following the change into a separate monitoring flow.

Don't publish specific thresholds or hold-period lengths in a public article if that information could help an attacker adjust their behavior to evade controls.

6. Ensuring Timesheet Data and Employment Status Are Trustworthy

The EWA limit depends directly on source data. Fraud controls must start before data ever reaches the platform (see What Is an Approved Timesheet? and Integrating EWA with Timekeeping, Payroll, and ERP).

For Employee Data

• use a unique employee ID that's never reused;

• update effective dates for new hires, leave, and resignations;

• check for conflicts among HRIS, payroll, and EWA;

• suspend transaction rights when status is unclear;

• review still-active EWA accounts belonging to former employees.

For Timekeeping Data

• only count statuses the business has approved;

• record who approved it, when, and the record's version;

• flag hours added or edited after the cutoff;

• detect implausible hours, overlapping shifts, or sudden spikes;

• separate whoever edits timesheets from whoever approves exceptions;

• recalculate the limit whenever source data is adjusted.

For Pay and Limit Rules

• version-control the formula;

• test before rolling out;

• require two-layer approval for significant changes;

• keep full before/after values;

• don't edit production data directly for a "quick fix";

• be able to reproduce the calculation from the source data and the policy version.

7. Preventing Duplicate Transactions with Idempotency

A classic scenario: the platform sends a payment instruction but gets no response because of a timeout. If the system treats that as a failure and sends a new instruction, the employee can end up paid twice.

Idempotency ensures that resending the same request multiple times still produces just one business outcome. A sound design needs:

• a unique idempotency_key generated by the caller;

• a uniqueness constraint in the database;

• binding the key to the user, transaction type, and request content;

• a key-retention period that covers the full processing lifecycle;

• returning the original transaction_id and status when the request is resent;

• refusing to let the same key be paired with a different amount or recipient;

• preserving the key across queue-based retries or after system recovery.

Idempotency doesn't replace reconciliation. It prevents duplication at processing time; reconciliation catches discrepancies that have already occurred between EWA, the payment partner, and payroll/ERP.

8. Managing Transactions with an Unresolved Outcome

A payment transaction isn't just "succeeded" or "failed." There needs to be an intermediate state for when an instruction has been sent but the final outcome isn't known yet.

stateDiagram-v2
    [*] --> Created
    Created --> Validating
    Validating --> Processing
    Processing --> Succeeded
    Processing --> Failed
    Processing --> Unknown
    Unknown --> Succeeded
    Unknown --> Failed
    Succeeded --> Reconciled
    Succeeded --> Reversed

While in the UNKNOWN state or its equivalent:

• hold the related portion of the limit;

• don't automatically create a new payment instruction;

• query the status using the original reference code;

• alert the operations team if it exceeds the internal time limit;

• cross-check against the partner's report or statement;

• record who handled it manually and on what basis;

• only restore the limit after confirming the funds were never sent, or have been reversed.

9. Fraud Warning Signals Should Be Combined

A single signal is usually not enough to draw a conclusion. An employee changing their phone, for example, can be perfectly legitimate. Risk rises when several signals appear together.

Account and Device Signals

• logging in from a new device and then changing the receiving account;

• more accounts on one device than is normal;

• repeated authentication failures;

• unusual changes in device information;

• logins from locations too far apart within an implausible time window;

• a recovery request immediately followed by a transaction.

Timesheet and Limit Signals

• hours spiking sharply against history or the shift schedule;

• bulk timesheet adjustments right before a transaction is created;

• many records approved by the same person outside working hours;

• a large limit change with no corresponding payroll event;

• data from an old version overwriting newer data;

• a resigned employee still generating a limit.

Transaction Signals

• multiple requests close together;

• repeated transactions near the cap;

• changing the recipient and then requesting a large amount;

• multiple employees' funds routed to the same account;

• repeated failed transactions across many receiving accounts;

• one payment reference appearing across multiple transactions;

• a transaction outside the account's normal behavior pattern.

Internal-Staff Signals

• granting access followed by an unusual transaction;

• the same person editing data, approving it, and handling exceptions;

• bulk data exports with no business justification;

• many admin actions outside working hours;

• repeatedly dismissing alerts or logging identical exception reasons en masse;

• touching accounts that share a device, receiving account, or unit in common.

Detailed thresholds should stay in internal operational documentation with restricted access.

10. A Risk-Scoring Model Must Not Become a "Black Box"

A risk score can support decisions to allow, require extra verification, hold, or route to manual review. But a business still needs to know which signals the model relies on and how its error rate is controlled.

A reference decision process:

At minimum, track:

• the true-alert rate;

• the rate of legitimate users wrongly blocked;

• alert-handling time;

• the value of loss prevented;

• the number of alerts dismissed;

• the number of fraudulent transactions that went unflagged;

• impact broken down by employee group, unit, or device.

If a machine-learning model is used, any change to the model or its data sources must be tested, approved, monitored for drift, and explainable enough for the investigation team. In an early stage, a clear rule set with solid reconciliation is usually easier to control than a sophisticated model built on data that isn't yet solid.

11. Controlling Internal Fraud

Insiders understand the process and may hold legitimate access rights (see Data Security and Privacy When Implementing EWA). Login controls alone are therefore not enough.

Key principles:

• separate whoever creates, approves, and reconciles;

• don't share admin accounts;

• grant access scoped to legal entity, unit, and duty;

• special privileges are time-bound and require a justification;

• sensitive actions require two-layer approval;

• keep tamper-proof logs for data and configuration changes;

• alert on bulk data exports;

• review access rights periodically and revoke immediately on role change;

• mandatory rotation or leave for sensitive positions where policy allows;

• have a whistleblowing channel and an independent investigation mechanism.

The investigation team shouldn't include the direct manager of, or anyone with a conflict of interest regarding, the person under review.

12. Multi-Way Reconciliation to Detect Loss

Reconciliation should run across at least three sources (see The Earned Wage Access Process from Timekeeping to Reconciliation):

1. the EWA platform's transaction ledger;

2. results from the bank or payment partner;

3. approved payroll/ERP records or settlements.

Depending on the design, timesheet data, limits, and the accounting ledger can also be cross-checked.

Discrepancies That Must Be Tracked Separately

• EWA reports success but the partner hasn't confirmed it;

• the partner reports success but EWA has no matching transaction;

• the amount, fee, or recipient doesn't match;

• a transaction is reversed but the limit hasn't been updated;

• a successful transaction is missing from payroll/ERP;

• one payment reference tied to multiple transactions;

• a transaction appears twice in the reconciliation file;

• timesheet data is adjusted after a transaction has already occurred.

Every discrepancy needs a case code, an owner, a priority level, evidence, an internal deadline, and a final outcome. Don't delete a discrepancy record just because the figures were later corrected.

13. Alert Handling and Investigation Process

flowchart TD
    A["Alert Created"] --> B["Triage & Prioritize"]
    B --> C["Protect Account & Transaction"]
    C --> D["Gather Evidence"]
    D --> E["Conclude & Act"]
    E --> F["Fix Root Cause"]
    F --> G["Measure Effectiveness & Update Rules"]

Step 1: Triage

Verify whether the alert has complete data, what state the transaction is in, and whether further loss is still possible.

Step 2: Contain the Damage

Depending on authority, this can mean revoking the session, temporarily locking the account, holding an unpaid transaction, reversing a receiving-account change, or pausing an integration flow. Measures must be proportionate and reversible in case the alert turns out to be a false alarm.

Step 3: Preserve Evidence

Record logs, data versions, configuration, transaction codes, payment references, change history, and support communications. Never edit the original evidence directly.

Step 4: Analyze the Root Cause

Distinguish between account takeover, internal fraud, data error, system error, and policy abuse. Consider both technical causes and process gaps.

Step 5: Act and Notify

Act according to the contract, internal policy, and legal requirements. Don't publicly conclude or take disciplinary action before an appropriate verification process is complete.

Step 6: Prevent Recurrence

Fix the rules, access rights, code, process, and training materials, and track effectiveness after the change.

14. Protecting Employees When the System Raises a False Alarm

Fraud prevention shouldn't become a barrier that keeps legitimate employees from accessing their entitlement when they need it.

A business needs:

• a clear notice that a transaction is under verification, without labeling it "fraud" before anything is concluded;

• an easy-to-use dispute channel;

• a case code and a status the employee can track;

• internal deadlines scaled to the impact;

• a fast unlock/restore mechanism once legitimacy is confirmed;

• an authorized person to review exceptions;

• measuring the false-positive rate per rule;

• reviewing whether a rule unfairly disadvantages a particular group of users.

The support team shouldn't see more data than necessary. Investigation information needs its own access controls to protect privacy and avoid exposing the fraud rules themselves.

15. Risk-Governance Metrics Worth Tracking

Metrics need consistent definitions. "Fraud prevented" should only be recorded when there's actual grounds for it — don't inflate every rejected transaction into loss avoided.

16. Pre-Go-Live Fraud Testing Checklist

Identity and Accounts

• [ ] Activation using someone else's employee ID is rejected.

• [ ] Repeated attempts or automation trigger appropriate alerts/limits.

• [ ] Changing device and recovering an account require the right level of verification.

• [ ] Old sessions are revoked after a credential change.

• [ ] A support agent alone cannot bypass the controls.

Receiving Account

• [ ] Changing the account requires re-authentication.

• [ ] Change notifications are sent through the correct channel.

• [ ] Transactions right after a change are handled per the risk policy.

• [ ] One receiving account appearing across multiple employees is detected.

• [ ] Staff without authorization cannot view or edit full data.

Timesheets, Pay, and Limits

• [ ] Unapproved timesheets don't generate a limit when policy requires approval.

• [ ] A late timesheet correction causes the limit to be recalculated correctly.

• [ ] Old data doesn't overwrite a newer version.

• [ ] A resigned employee is suspended as of the correct effective date.

• [ ] Formula changes have approval and a before/after log.

Transactions and Payment

• [ ] Resending the same idempotency_key doesn't cause a duplicate payout.

• [ ] The same key with a different amount is rejected.

• [ ] A timeout produces an unresolved state, without automatically sending a new instruction.

• [ ] Spoofed or duplicate callbacks are rejected.

• [ ] A reversed transaction updates the limit through the approved process.

Internal Fraud

• [ ] One person cannot create, approve, and reconcile an exception alone.

• [ ] Temporary privileges expire automatically.

• [ ] Bulk data exports generate a log entry and an alert.

• [ ] Administrative actions cannot be removed from the standard audit trail.

• [ ] Access for someone who changes roles or resigns is revoked on time.

Reconciliation and Investigation

• [ ] A transaction missing from any of the three sources creates a discrepancy case.

• [ ] Each case has an owner and a handling history.

• [ ] Evidence is preserved, never edited directly.

• [ ] A wrongly locked-out user has a dispute channel and a way to be unlocked.

• [ ] Drills for account takeover and erroneous transactions have been completed.

17. Legal Framework and Data Protection in Fraud Prevention

Fraud prevention can involve account, device, behavioral, and transaction-history data. A business therefore has to simultaneously ensure a clear processing purpose, appropriately scoped data, and employees' privacy.

In Vietnam, Personal Data Protection Law No. 91/2025/QH15 takes effect on January 1, 2026. Decree No. 356/2025/ND-CP, also effective January 1, 2026, provides detailed guidance on a number of articles and implementation measures under the Law. Depending on its role and payment flow, a business also needs to consider Decree No. 52/2024/ND-CP on Non-Cash Payments along with related industry-specific regulations.

Monitoring for fraud doesn't mean collecting every piece of data that's technically possible. Each signal has to be tied to a purpose, a necessity threshold, a retention period, access controls, and a process for explaining/responding when an employee pushes back. Any specific legal conclusions need to be reviewed against the actual architecture and contracts.

For information-security governance, the NIST Cybersecurity Framework 2.0 offers an approach organized around the Govern, Identify, Protect, Detect, Respond, and Recover functions. The OWASP Application Security Verification Standard can serve as a basis for testing an application's and API's technical controls. These are reference frameworks — they don't replace a business's own legal obligations or risk assessment.

Conclusion

Effective EWA risk governance rests on multiple layers of control: trustworthy source data, correct identity verification, verified recipient changes, idempotent transactions, clear payment status, separated internal access, explainable alerts, and reconciliation down to every transaction.

The goal isn't to block as much as possible — it's to stop loss at the right moment while still protecting legitimate employees. If your business is evaluating an earned wage access rollout, prepare your risk scenarios, an access-rights map, and the UAT cases that need testing, then learn more about Earned Wage Access for Businesses to request documentation on transaction controls, reconciliation, and the right pilot scope.

References

• Personal Data Protection Law No. 91/2025/QH15 (Vietnam)

• Decree No. 356/2025/ND-CP Guiding the Personal Data Protection Law (Vietnam)

• Decree No. 52/2024/ND-CP on Non-Cash Payments (Vietnam)

• NIST Cybersecurity Framework

• OWASP Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

Author: Tran Van Tai — Deputy General Director's Assistant, in charge of development strategy, Nhan Kiet Manpower Supply Co., Ltd.

Consultation on earned wage access solutions for businesses: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned Wage Access for Businesses