Internal Audit Checklist for Earned Wage Access: 50 Controls and Evidence

Internal Audit Checklist for Earned Wage Access: 50 Controls and Evidence to Retain

Internal audit for earned wage access must verify the entire chain of right person – right work – right authority – right amount – right account – right status – right pay period. Each conclusion must be based on traceable evidence, not just interviews or screenshots. The following 50-control checklist helps businesses build a regular audit program.

> In short: Audit across 10 groups, each with five controls: governance; human resources; timekeeping; formulas/limits; transactions; banking; payroll; personal data; security/incidents; change/business continuity. Select samples based on risk and verify from original data to final results.

> Warning: This is a reference checklist, not an audit standard or legal opinion. Businesses must adjust according to scale, contracts, policies, systems, and actual risk assessments. The status "in code" does not self-prove that controls are effectively operating.

1. Audit Objectives

(See also: Earned Wage Access Due Diligence File.)

The program should answer:

1. Can only eligible individuals use it?
2. Does only approved work generate available amounts?
3. Are formulas, limits, and reserves correctly approved/applied?
4. Are transactions free from duplication, wrong individuals, and unclear statuses?
5. Do bank statements match transaction records?
6. Are received amounts correctly entered into payroll and not accumulated?
7. Is personal data processed for the correct purpose/rights?
8. Are incidents and changes controlled?
9. Are management reports complete/accurate?
10. Have previous recommendations been addressed?

2. Scope and Frequency

Can be applied:

• pre-go-live checks;
• checks after 30–90 days;
• quarterly/annual regular audits;
• ad-hoc checks after incidents;
• reviews before onboarding large clients;
• checks when changing banks, formulas, or payroll.

The scope should clearly state the legal entity, clients, period, systems, bank accounts, work sources, software versions, and third parties.

3. Sample Selection Based on Risk

Do not select randomly. Samples should include:

• high-value transactions/near limits;
• individuals with multiple transactions per day/period;
• pending, failed, then successful transactions;
• work corrected after approval;
• individuals who resigned/transferred;
• workers serving multiple clients;
• account/device changes;
• transactions outside normal hours;
• clients with high error rates;
• unrecoverable amounts;
• random samples to detect unforeseen discrepancies.

Sample size must be determined by audit based on the overall and risk, not using a fixed number for all periods.

4. Finding Evaluation Scale

Level	Characteristics	Example
Critical	High risk to money/data or core control failure	Duplicate payments, wrong person, key exposure
High	Affects many people/periods or cannot be reconciled	Wrong formulas, payroll discrepancies
Medium	Controls exist but are inconsistently operated	Late approvals, unchecked permissions
Low	Records/effectiveness need improvement	Lack of training evidence

Official levels must attach criteria for money, number of people, legal obligations, and remediation deadlines.

5. Group 1 — Governance and Policies (Controls 1–5)

1. There is a Service Owner responsible end-to-end.
2. Earned wage access regulations are valid, with approval authority and version history.
3. RACI matches actual system permissions.
4. KPIs do not incentivize forcing workers to transact.
5. Risks, exceptions, and actions are reported regularly.

Evidence: appointment decisions, regulations, permission matrix, meeting minutes, dashboard, risk register.

Testing: select three roles and compare documented permissions with actual permissions; check if overdue actions have responsible parties.

6. Group 2 — Employee List and Identification (6–10)

1. The list includes only current employees/correct clients.
2. ID cards are matched and non-duplicated identification keys.
3. Timekeeping codes are correctly linked to clients/workplaces.
4. VPBank accounts are verified and matched to the rightful owner before use.
5. Device/account changes or exceptions are approved and logged.

Evidence: source HR files, synchronization logs, verification results, change history, exception approval forms.

Testing: select samples of new hires, resignations, transfers, and device changes; trace from source records to current usage rights.

7. Group 3 — Timekeeping and Approval (11–15)

1. Work sources/link keys/synchronization frequency are documented.
2. Future work and unclosed days do not generate available amounts.
3. Only authorized individuals can approve/reject/edit work.
4. Editing approved work returns records to pending approval and logs before/after.
5. Night shifts, overtime, leave, and multiple workplaces are processed according to approval rules.

Evidence: source configuration, import logs, permission lists, audit trails, shift/code dictionaries.

Testing: recreate a regular shift, overnight shift, and edited record; check results in available amounts.

8. Group 4 — Formulas, Rates, Limits, and Reserves (16–20)

1. System formulas match approved policies.
2. Rates/daily are correctly linked to clients and effective periods.
3. Minimum limits, per order, per day are correctly configured.
4. Reserves/N workdays are calculated and displayed correctly.
5. Sensitive parameter changes have four-eye checks, logs, and post-change verification.

Evidence: policy tables, configuration, change logs, approvals, sample calculation results.

Testing: recalculate samples using the formula approved work × rate − received − reserve, check rounding down to 1,000 VND and limit thresholds.

Default levels in code include 50,000 VND/transaction, 3 million VND/order, and 5 million VND/person/day; audit must compare with actual applied levels, not default these numbers as policy.

9. Group 5 — Transaction Initiation and Processing (21–25)

1. Servers recheck all conditions, not just trust data from the app.
2. Workers confirm content before each request.
3. Each request has a stable transaction code to prevent replay.
4. There is a concurrency lock/preventing two orders for the same available amount.
5. Only valid responses change the status to disbursed.

Evidence: flow documentation, obfuscated data logs, transaction codes, automated testing, commitment content samples.

Testing: attempt two nearly simultaneous requests, requests exceeding limits, missing ID cards, unapproved work, and invalid bank responses in a permitted test environment.

10. Group 6 — Banking and Reconciliation (26–30)

(Details: see Reconciliation of Earned Wage Access Transactions with Payroll and Accounting.)

1. Bank key holding services are separated and access restricted.
2. Source accounts, signatories/authorizations, and disbursement limits are managed.
3. Unclear statuses are held pending, not automatically initiating new orders.
4. Suspended amounts are reconciled according to procedures and have alert ages.
5. T+1 statement reconciliation is performed, discrepancies have responsible parties.

Evidence: cash flow diagrams, permission matrix, reconciliation logs, obfuscated statements, reconciliation reports, and closing minutes.

Testing: select all suspended transactions in the period and samples of successful/failed ones; cross-check two-way from system to statement and from statement back to system.

The system currently has a 5-minute reconciliation schedule and reads statements at 08:00 T+1. This is a technical specification; audit needs to see actual runs and official SLAs.

11. Group 7 — Payroll and Settlement (31–35)

1. Only confirmed successful transactions enter the total received.
2. Transactions are correctly linked to individuals, clients, and pay periods.
3. Workdays have covered keys, not accumulated into the next period.
4. Total transactions match amounts on payroll/payslips.
5. Resignations, reduced work, refunds, and unrecoverable amounts have procedures.

Evidence: transaction files, bridge reports, payroll, sample payslips, advancecovereddays, unrecoverable amounts register.

Testing: re-perform reconciliation for sample users; check cut-off at the start/end of the period and a resignation case.

Do not conclude deduction/recovery methods solely from software logic; must compare with approved policies and legal opinions.

12. Group 8 — Personal Data and Privacy (36–40)

(Full framework: see Data Security and Privacy in Earned Wage Access Deployment.)

1. Processing roles, purposes, and data categories are documented.
2. Notifications/consents and data subject rights are implemented when applicable.
3. Access to ID cards, photos, GPS, accounts, and salaries is restricted.
4. Retention periods, deletion/anonymization, and sub-processors are managed.
5. Data breaches have detection, assessment, and notification procedures.

Evidence: policies, processing records, impact assessments, sub-processor lists, access logs, deletion evidence, incident reports.

Testing: select one data type from collection to deletion; select three internal accounts and check permissions; review data export logs.

Current legal framework includes the Personal Data Protection Law 91/2025/QH15 and Decree 356/2025/NĐ-CP, both effective from 01/01/2026.

13. Group 9 — Information Security and Incident Handling (41–45)

(See also: Protection Layers for an Earned Wage Access Transaction and Handling Incidents in Earned Wage Access.)

1. There is vulnerability management, patching, and security testing.
2. Secrets/keys are stored, rotated, and revoked securely.
3. Important logs are protected, time-synchronized, and alerted.
4. Incidents P1–P4 have an Incident Commander, escalation, and RCA.
5. Emergency stop switches are controlled and rehearsed.

Evidence: scan/pentest reports, asset registers, key policies, alerts, incident tickets, RCA, rehearsal minutes.

Testing: select a closed incident and check the timeline; confirm RCA actions are completed; check that resigned individuals have lost sensitive access.

The number of test files does not replace independent security testing or operational control evidence.

14. Group 10 — Change, BCP/DR, and Service Exit (46–50)

1. All releases/configurations have requests, approvals, testing, and rollback.
2. Separation of duties between developers, approvers, and deployers is risk-appropriate.
3. Backups, RTO/RPO, and recovery are tested.
4. Bank/ERP/Sheet/VietQR dependencies have disruption plans.
5. Service termination includes data export/return/deletion and access revocation.

Evidence: change tickets, deployment logs, backup restore minutes, BCP/DR plans, rehearsal results, supplier offboarding checklists.

Testing: select one emergency change and one regular change; check for post-implementation review. Select a backup and verify recovery evidence, not just "backup successful" status.

15. Recommended Audit Techniques

Walkthrough

Select a transaction and accompany the process owner from work to payslip.

Reperformance

Recalculate available amounts and total reconciliation from original data.

Inspection

Check configurations, logs, approvals, and documentation.

Observation

Observe user/supervisor handling an exception.

Confirmation

Confirm balances/statuses with suitable independent sources, such as bank statements.

Data Analytics

Scan the entire dataset to find duplicate codes, individuals exceeding limits, transactions outside hours, work edited after disbursement, or payroll discrepancies.

Interviews only indicate how processes are described; they are insufficient to prove they have operated.

16. Sample Audit Working Paper

Field	Content
Control Code	C01–C50
Objective	What risk is controlled
Owner	Responsible person
Design	Is the control appropriate?
Operation	Did it operate during the period?
Overall/Sample	Size and selection method
Evidence	Path or file code
Exception	Quantity/value/impact
Conclusion	Effective/ineffective/partial
Action	Responsible person and deadline

17. Suggested Data Queries

• same ID card linked to multiple active accounts;
• one bank account linked to multiple individuals;
• transactions with duplicate amounts/times/individuals;
• total per individual exceeding daily limits;
• work with future dates generating amounts;
• work edited after successful transactions;
• successful transactions without statements;
• disbursement statements without internal transactions;
• failed/pending transactions appearing in payroll;
• resigned individuals still generating requests;
• configuration changes without tickets;
• inactive admin still having permissions;
• logs missing during unusual periods.

Queries must be tested to avoid false positives and executed within data rights scope.

18. How to Write Audit Findings

A good finding has five parts:

1. Criteria: what regulations/contracts/controls require.
2. Condition: what evidence shows.
3. Cause: why the control did not operate.
4. Effect: money, people, data, legal, operational impact.
5. Recommendation: specific action, responsible person, and deadline.

Poor example: “Need to strengthen controls.”
Better example: “Of 25 limit changes selected, 4 lacked independent approval. Add mandatory four-eye approval in the system by…”

Do not disclose real examples unless anonymized and permitted.

19. Follow-up on Remediation

Each action needs:

• owner;
• completion deadline;
• priority level;
• required evidence;
• re-checker;
• status;
• extension reason;
• risk accepted by proper authority if not corrected.

Do not close findings just because there is a plan; verify implementation evidence and effectiveness post-correction.

20. Frequently Asked Questions

Does "in code" mean the control is effective?

No. Configuration, actual data, operators, and in-period evidence must be checked.

How many transactions should be audited?

Depends on the overall, risk, and objectives. Combine risk samples, random samples, and full data analysis when possible.

Who should not audit their own operations?

Operators can self-check first line; independent assessments should be done by second/third line or sufficiently independent auditors.

Are suspended transactions errors?

Not inherently. Check if the system safely holds pending, reconciles on time, and avoids duplicate disbursements.

Is separate personal data auditing necessary?

Can be combined or separate, but must have expertise and full scope according to current laws/policies.

21. Conclusion

Effective earned wage access auditing must traverse the entire chain and re-perform using real data. A system with multiple protection layers still needs to prove those layers are enabled, correctly authorized, and operational during the period. The 50-control set helps businesses shift from trust in descriptions to evidence: who did what, on which data, what the results were, and how discrepancies were handled.

Official Reference Sources

• Personal Data Protection Law No. 91/2025/QH15, effective from 01/01/2026.
• Decree 356/2025/NĐ-CP, detailing some provisions and measures for implementing the Personal Data Protection Law, effective from 01/01/2026.

---

Author: Nguyen Minh Khang — Strategy Team Specialist, Nhan Kiet Manpower Supply Co., Ltd.

Earned Wage Access Solutions for Businesses: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned Wage Access for Businesses