Most conversations about Earned Wage Access start with the payout: how fast the worker receives pay, which rail moves it, what the fee is. Those are real questions. But they sit downstream of a harder one, and it’s the one that actually defines earned wage access infrastructure: can the system show, at any given moment, how much a worker has earned, how much it can still advance, how much it has already advanced, and how much payroll still owes?
Giving a worker access to money before payday isn’t just a matter of changing when a transfer executes. The infrastructure has to track earned wages, available balances, advances, repayments, fees, and settlement in near real time. It has to keep those numbers consistent across three systems: payroll, the EWA provider, and the payment rail. Get that wrong, and rail speed doesn’t fix it.
EWA Starts With the Ledger
Take a simple case. A worker clocks in at 8am. By 2pm they’ve earned $200 based on hours worked and an hourly rate. Their normal pay cycle doesn’t disburse for six more days. An EWA program wants to let them access part of that $200 today.
To do that responsibly, the system needs five numbers, updated continuously, not at end of pay period:
- Earned: wages accrued against actual time or transaction data, not an estimate
- Available: the portion the program will advance, governed by risk limits or employer policy
- Advanced: what’s already been paid out
- Paid: what’s settled through the normal payroll cycle
- Remaining: what’s still owed once advances and fees are netted against the paycheck
If the worker requests $100 at 2pm, “available” has to drop immediately. Otherwise a second request an hour later could approve against money that’s already gone. Six days later, when payroll runs, the ledger has to net the advance and fees correctly. Payroll, the provider, and the bank all need to land in agreement.
Advance vs. Earned Wages: Why the Distinction Matters
It also matters what kind of claim that $100 represents. Under one model, the provider extends something advance-like against wages not yet paid. That carries real repayment risk if hours get cut or a payroll deduction fails. Under the other model, the product is access to wages already earned, not a loan. There’s no credit exposure, but far more pressure on getting the “earned” number exactly right at the moment of the request.
That distinction also determines what happens when the number turns out to be wrong: a disputed shift, a retroactive payroll correction, a reversed gig payment. If an advance already went out against that data, the ledger needs a defined path for the clawback. It might net the amount against a future advance, adjust the next cycle, or flag it for manual review. A system that only models the forward path, earn, advance, repay, isn’t production-ready. Reversals aren’t an edge case at volume. They’re routine.
None of this works unless three things happen: wage data flows to the provider near real time, the ledger updates on every transaction, and reconciliation across payroll, provider, and rail runs automatically. Miss any one of those and you get double advances, bad payroll deductions, or support tickets that don’t match what the worker sees in the app.
What Real-Time EWA Infrastructure Actually Requires
The five numbers above, earned, available, advanced, paid, and remaining, only work as a system if they update continuously and stay synchronized across every party involved. That’s the infrastructure question underneath every EWA payout decision.
Where Batch ACH Breaks the Model
Batch ACH was built to move money on a schedule. For standard payroll disbursement, that’s still fine. The problem is layering a continuous, intraday product like EWA on top of it.
A worker earns continuously through a shift. A provider wants to advance against those earnings on demand, potentially several times a day across a large population. But the funding money, and the money that reconciles against payroll, often still moves through ACH windows. A same-day transaction submitted after the cutoff waits for the next window. Settlement can lag origination by a full business day or more.
So: a worker earns $200 by 2pm Tuesday. The provider advances $100 through a rail that won’t settle until Wednesday morning. Someone carries that exposure overnight, and who depends on the funding model:
- Employer-funded: the employer reimburses on the next payroll run, so exposure is short and a known date backstops it.
- Provider-funded: the provider carries the float itself, off its own balance sheet or a credit facility, until repayment clears.
- Third-party-funded: a bank or funding partner sits behind the provider with its own settlement and reconciliation requirements.
Each model changes what the ledger reconciles against, and who carries exposure if wage data and advance data drift. At low volume, drift is a nuisance. At scale, it’s a staffed operational function. In a provider-funded model, it’s a balance sheet question a CFO has to answer for. Batch settlement also caps what the product can become: no differentiated access windows, no frequent small advances without a large float buffer, no accurate real-time balance visibility. The numbers that matter are only as current as the last batch run.
When the Ledger Fails, the Problem Becomes Operational
At scale, small ledger errors stop being bookkeeping issues. They become operational ones. According to the CFPB’s July 2024 analysis, its sample of eight employer-partnered EWA providers processed 83.4 million transactions totaling $8.9 billion across 2.8 million users in 2022.
Using that sample alongside public data, the CFPB estimated the broader employer-partnered market at 214 million transactions and $22.8 billion in advances across 7.2 million workers. At that frequency, a missed reversal, a duplicate advance, or a delayed balance update can produce a funding discrepancy. It can also produce an incorrect payroll deduction, or a support ticket that takes multiple teams to untangle.
State-Level Evidence of the Same Pattern
The California Department of Financial Protection and Innovation’s 2021 review illustrates how quickly EWA issues become operational. Seven responding providers reported approximately $765 million in advances to California consumers. Among 345 complaints and inquiries analyzed across six companies, 67% involved receiving or repaying funds. Approximately 34% concerned settlement issues, including claims that repayment exceeded the original advance.
The report also describes an employer changing its payroll date without notifying the EWA provider. Settlement began before the worker’s payroll deposit, resulting in an overdraft. The example shows that EWA reliability depends on more than payment-rail speed. It depends on synchronized employer data, accurate balance states, and a ledger that can coordinate advances, settlement, and repayment.
A Cautionary Example Beyond EWA
A related, non-EWA example shows how severe this can get when balances, funding records, and partner-bank ledgers don’t align. In the 2024 Synapse bankruptcy, a court-appointed trustee reported that end users were owed roughly $265 million, while partner banks held about $180 million. More than 100,000 customers couldn’t access their funds while banks worked to reconcile records.
Synapse wasn’t an EWA provider, and this isn’t an EWA failure case. But it’s a useful infrastructure warning. When ownership, fund flows, and balances are hard to reconcile, the result is funding exposure, delayed access, manual investigation, and lost trust. Ledger design isn’t the only thing that can break an EWA program, but these are the consequences when it does.
Real-Time Rails Fix Part of the Problem
Still, RTP and FedNow change the settlement side: transactions move and settle in seconds, any hour, not within a batch window. That means less overnight exposure and the ability to fund advances closer to the moment of request.
But real-time rails only fix speed and finality. They don’t fix whether the ledger knows what should move, how much, and to whom. If the ledger still updates on a delay, or earned wage data only arrives in a nightly file, real-time settlement just moves money fast to a system that doesn’t yet have the right number. That’s arguably worse. It removes the buffer that batch timing used to provide while reconciliation caught up.
Continuous processing also raises the bar elsewhere. Risk and funding decisions now have to happen continuously. Batch cycles can no longer true them up after the fact. Fraud patterns that used to surface in daily reconciliation now need catching intraday, because funds have already moved. Continuous requests also need built-in idempotency, so a network retry or a duplicate tap doesn’t execute the same advance twice, since both could settle before anyone notices. A program built on a real-time rail with a batch-updated ledger underneath isn’t a real-time program. It just moves the bottleneck.
Payroll and Gig Platforms Are Solving Different Problems
That said, payroll-based and gig-based EWA aren’t the same infrastructure problem with two front ends. In a traditional payroll model, wages accrue against a known structure: hourly rate or salary, defined pay period, scheduled disbursement. The job is tracking accrual accurately between paydays, calculating what’s safely available to advance, and netting the eventual payroll run correctly. The employer is usually the funding backstop. Repayment happens through payroll deduction on a known date.
Gig and marketplace environments don’t have those fixed points. Earnings come from individual completed transactions, a delivery, a ride, a task, not a pay period. A worker might generate fifteen discrete earning events in a day, each changing their available balance. There’s no single employer funding source, and often no fixed date to net an advance against. Repayment comes from the next transaction, the platform’s payout cycle, or both. That demands tighter, faster ledger updates than a payroll model, precisely because there’s no scheduled event to fall back on if something drifts. A gig platform building EWA on payroll-style infrastructure hits its ceiling faster than a traditional employer would.
The Architecture Behind Real-Time EWA
Real-time EWA isn’t a feature added to a payment flow. It’s four layers designed together.
A ledger that updates continuously and represents earned, available, advanced, paid, and remaining balances at any moment. Account structures that segment funds by worker, program, and employer so nothing is commingled. Payment orchestration that routes each transaction to the right rail, ACH for scheduled movement, RTP or FedNow where speed matters, without a separate integration per rail. And reconciliation that runs automatically across employer data, provider ledger, and payment rail, so a discrepancy surfaces as an exception to review, not a mystery at month end.
Qolo’s embedded ledger and multi-rail orchestration are built to address this layer. They track balances and program-level activity in real time. They route money movement across rails as programs require, rather than assuming one rail and one settlement cadence fits every case.
A gap in any one of these four layers shows up as friction somewhere else in the system. Usually at the worst moment: a worker trying to access money they’ve already earned.
Providers and platforms building EWA should evaluate the money movement architecture underneath the feature, not just the payout experience on top of it. A fast payout backed by a ledger that can’t track earned, available, advanced, and remaining balances in real time isn’t a real-time product. It’s a fast interface on a system that will eventually need to be rebuilt.
Talk to Qolo about the ledger and orchestration layer behind your EWA program.
