Operating Earned Wage Access Post Go-Live: RACI, Daily Controls, and Incident Management

Operating Earned Wage Access Post Go-Live: RACI, Daily Controls, and Incident Management

After go-live, Earned Wage Access can only operate sustainably when businesses manage the entire chain from HR data → timekeeping → approval → available balance calculation → disbursement → bank reconciliation → payroll settlement. Each stage must have a responsible person, alert indicators, processing deadlines, and a safe halt plan when the status is unclear.

> In short: Go-live is not the end of the project but the point of transferring ownership from the implementation team to the operations team. Businesses need a clear RACI, three control rhythms daily-weekly-end of period, a runbook for incidents, and a change approval mechanism.

> Scope of the article: Ngô Nhã Kỳ — Biên tập viên ban biên tập, not a signed SLA or process of Nhan Kiet. The frequencies in the code are system characteristics; service objectives and responsible persons must be officially confirmed by Nhan Kiet.

1. Why is Earned Wage Access prone to issues after the pilot phase?

(See also: Pilot Results of Earned Wage Access: KPI and Lessons and What Businesses Need to Prepare for Implementing Earned Wage Access.)

During the pilot, the project team often closely monitors each transaction, data is manually cleaned, and the scope is small. When expanding, conditions change:

• the number of workers and customers increases;

• multiple shifts, timekeeping templates, and unit prices operate simultaneously;

• staff turnover, transfers, or code changes occur daily;

• supervision is no longer reminded by the project team for each record;

• bank transactions occur outside office hours;

• payroll must consolidate multiple periods and sources;

• configuration changes can affect hundreds of people;

• the support team receives questions from those not initially trained.

Therefore, a successful pilot does not prove the model can operate on a large scale. The post go-live phase needs to transition from "skilled individuals closely monitoring" to "systems and processes that can be controlled".

2. Identifying the Service Owner

Earned Wage Access often lies between HR, labor operations, payroll, finance, and technology. Without a Service Owner, each department only optimizes its part.

The Service Owner should be responsible for:

• end-to-end service objectives and quality;

• approving standard processes;

• convening to handle serious incidents;

• deciding on change priorities;

• monitoring KPIs and risks;

• reporting to the executive board;

• ensuring post-incident actions are completed.

The Service Owner does not necessarily handle every ticket directly. The main role is to ensure there are no responsibility gaps between teams.

3. RACI Matrix for Operating Earned Wage Access

Symbols: R Responsible, A Accountable, C Consulted, I Informed.

The above matrix is a template. For each customer, Nhan Kiet needs to record specific names, phone numbers/on-call, substitutes, and availability times; just listing department names is insufficient.

4. Three Control Rhythms Post Go-Live

4.1. Daily: Maintain a Clean Flow

The operations team needs to monitor:

• number of new, resigned, and transferred synchronized employees;

• time records missing join keys or incorrect formats;

• time pending approval beyond deadlines;

• number of eligible individuals but incomplete ID/account profiles;

• successful, failed, and unclear status transactions;

• disbursed amounts by customer and compared to limits;

• alerts on changes to approved time;

• tickets related to incorrect time, available balance, or unreceived funds.

The goal of daily controls is to detect discrepancies before they accumulate by the end of the period.

4.2. Weekly: Identify Trends and Causes

Weekly operations meetings should not read each ticket. Focus on:

• customers/teams with low time approval rates;

• recurring errors by data source;

• groups of workers with high authentication failure rates;

• pending transaction processing times;

• configuration changes made;

• unresolved post-incident actions;

• worker feedback and misleading content;

• risks for the upcoming payroll period.

Each issue must have an owner, completion deadline, and closure criteria.

4.3. End of Period: Prove Money Matches

Before closing payroll, reconcile:

1. total approved time eligible;

2. total calculated available balance;

3. total received requests;

4. total successful bank transactions;

5. total amounts included in payroll offset;

6. discrepancies and pending amounts;

7. uncollectible amounts;

8. approval trace for period closure.

Do not close the period by manually adjusting a total figure without explaining each transaction causing the discrepancy.

5. Minimum Operational Dashboard

The dashboard must allow filtering by customer, period, status, and cause. Some system-wide totals may hide a customer experiencing severe errors.

6. Alert Thresholds Should Not Use a Single Number for All Customers

Customers with 50 workers and those with 5,000 need different alert methods. Combine:

• absolute threshold: e.g., number of pending transactions;

• percentage threshold: error percentage of total transactions;

• time threshold: record existing beyond minutes/hours;

• monetary threshold: total unreconciled value;

• anomaly threshold: sudden increase compared to history.

All target numbers must be approved in SOP/SLA. This article does not substitute for Nhan Kiet's operations.

7. Process for Handling Unapproved or Edited Time

(See also: Customer Portal: Approve Time, Edit Shifts, Control.)

Time Pending Approval

1. Classify by customer, supervisor, and record age.

2. Remind the person with approval authority.

3. Escalate when exceeding thresholds.

4. Do not generate amounts from unapproved records.

5. Record reasons: late data, missing shifts, disputes, or omissions.

Edited Approved Time

In the Earned Wage Access system, editing approved hours/shifts reverts the status to pending approval and logs before/after changes. Operations need to:

• determine if the edit increases or decreases time;

• check if the worker has received money from that time portion;

• recalculate available balance;

• include discrepancies in the exception list;

• notify the correct person;

• do not delete history of occurred transactions.

If time decreases after disbursement, the system has a ledger for uncollectible amounts. Accounting policies and worker handling must be approved by Nhan Kiet.

8. Runbook for Transactions with Unclear Status

(See also: How Businesses Handle Earned Wage Access Incidents.)

When the app has not received a clear result from the bank, the most dangerous action is to issue a new transaction code immediately. The runbook should include:

1. keep the request in pending status;

2. lock to prevent duplicate orders;

3. query using the original transaction code;

4. reconcile with the disbursement service response;

5. check statements at the appropriate time;

6. only mark as successful/failed with evidence;

7. notify workers in non-misleading language;

8. record the person closing and the basis.

The system currently has a mechanism for periodic reconciliation of pending amounts and T+1 reconciliation. This is a fail-closed safety design: when unclear, hold and wait, do not guess.

9. Incident Tiering P1–P4

Official definitions must link SLA, escalation points, and notification channels. Do not classify P1/P2 solely by the number of people; a single transaction error can still be a critical control incident.

10. How to Operate a War Room for Serious Incidents

In the first 30–60 minutes, prioritize:

• confirming the event and scope;

• preserving logs/evidence;

• stopping parts at risk of further damage;

• appointing an Incident Commander;

• separating technical, operational, communication, and legal teams;

• establishing update rhythms;

• not speculating on causes before data is available.

After recovery, conduct an RCA including timeline, direct cause, systemic cause, controls that worked/didn't work, corrective actions, and responsible persons. RCA is not for blame; the goal is to prevent recurrence.

11. Configuration Change Management

Changes like unit price/day, limits, reserve, self-withdrawal rights, time source, or approver can all impact money. The process needs:

1. request form stating reason and scope;

2. verify requester authority;

3. assess data/money impact;

4. four-eye principle for sensitive changes;

5. test on a small scale;

6. deployment and rollback plan;

7. pre/post-change logs;

8. post-change verification;

9. notify stakeholders.

Do not make direct production changes through verbal or unapproved message exchanges.

12. Managing the Worker Lifecycle

New Employees

Synchronize profiles, match ID, timekeeping code, customer, start date; complete VPBank account ownership and usage guidance.

Transfers

Close old assignments on the correct date, open new assignments, separate time and unit prices by customer; avoid double-counting a day.

Resignations

Lock the ability to generate new amounts from the effective date; finalize time, pending transactions, and received amounts; include in final settlement per approved policy.

Phone/Account Changes

The system controls one person–one device and locks the bank account after verification. Exception processes require strong identity verification, logging, and higher permissions than usual operations.

13. Limit and Fund Source Control

The code currently has default levels: minimum 50,000 VND/transaction, maximum 3 million VND/order, and 5 million VND/person/day; customers may have reserve configurations. These are technical defaults, not policies suitable for all groups.

Weekly or per approved cycle, operations should review:

• total available funds;

• disbursed amounts by customer;

• funding source utilization;

• distribution of receipt frequency/person;

• individuals hitting limits;

• reserve amounts;

• uncollected amounts and age;

• demand forecast by payroll period.

Funding sources and who bears operational costs still require official confirmation from Nhan Kiet.

14. Three-Layer Reconciliation

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

Layer 1 — System and Transactions

Requests must match disbursement orders by stable code, amount, and recipient.

Layer 2 — System and Bank

Internal status must match statements/reconciliation. Discrepancies are categorized and have a closer.

Layer 3 — Transactions and Payroll

Total disbursed by person/period must match offset amounts on settlement and payslips. Covered days must be locked to prevent accumulation in the next period.

Only when all three layers match should a period be considered fully closed.

15. Supplier and Dependent Service Control

Earned Wage Access may depend on banks, VietQR, sFTP, customer systems, Google Sheets, ERP, and infrastructure. The Service Owner needs to maintain:

• list of dependencies and owners;

• committed service levels of each party;

• escalation points;

• plans for service interruptions;

• change/maintenance schedules;

• evidence of periodic risk assessments.

An end-to-end SLA cannot be better than the weakest link without backup or compensatory processes.

16. Suggested Meeting and Reporting Schedule

Small scale may combine rhythms, but control outputs must not be omitted.

17. Frequently Asked Questions

Who is primarily responsible after go-live?

There should be a Service Owner responsible end-to-end; each stage still has specific R/A in the RACI.

Should workers retry unclear transactions?

No, not before reconciling with the original code and confirming the initial order was unsuccessful. The goal is to avoid duplicate payments.

What happens if approved time is edited?

The system reverts time to pending approval and logs changes. Operations must check impacts on available balance, disbursed transactions, and payroll.

Is the 30-minute sync schedule an SLA?

No. It is the current technical schedule for Google Sheet sources; SLA must specify objectives, measurement methods, exclusions, and responsibilities in writing.

When should the emergency stop switch be used?

When there is a risk of financial loss, widespread calculation errors, duplicate payments, data breaches, or inability to determine a safe status. Stop/start rights must be pre-defined.

18. Conclusion

Operating Earned Wage Access post go-live is more a discipline challenge than a feature addition challenge. A good model must know what to look at each morning, what to fix by the end of the week, what to prove by the end of the period, and who has the authority to stop the system when incidents occur. When RACI, dashboards, runbooks, and change management work together, businesses can expand Earned Wage Access while maintaining the principles of the right person, right time, right money, and right period.

---

Author: Ngô Nhã Kỳ — Biên tập viên ban biên tập, 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