Written by: Kamil Ponicki, Director of Talent Acquisition, Digital Colliers
If you work in payments ops or treasury, you already feel this one. SEPA Instant, FedNow, Faster Payments, RTP. Money moves in seconds. Your ledger of record still updates at 2am off a batch file. That gap is where fraud lives, where disputes rot, and where your treasury team is essentially guessing at intraday positions.
The uncomfortable part is that most of the industry knows this and is still shipping it. The rails got upgraded. The back office did not.
The mismatch nobody wants to say out loud
Instant payment schemes were designed on the assumption that the rest of the stack would catch up. It largely hasn't. Card networks, correspondent banking, and internal ledgers still lean on end-of-day cutoffs because that is how the accounting systems were built in the first place.
Meanwhile the front door moved. A customer initiates a push payment at 14:47, the funds land at the beneficiary bank at 14:47:04, and the sending bank's reconciliation engine won't see a matched entry until the overnight run completes around 03:00 the next morning. That is a 12-hour window where your view of cash, exposure, and fraud is stale by design.
And it is not just a tech problem. DORA has been in force across the EU since 17 January 2025, and it explicitly expects firms to demonstrate operational resilience across ICT systems that support critical functions. Overnight batch recon on real-time rails is going to look increasingly hard to defend when a regulator asks how quickly you can detect and isolate an incident.
What actually breaks
The operational risks compound faster than most exec teams model them.
- Fraud windows. If a mule account receives funds in seconds and cashes out in minutes, an overnight batch tells you what happened, not what is happening. Recovery rates collapse the longer detection lags settlement.
- Disputes and chargebacks. Customers now expect same-day visibility. When your dispute team is working from a ledger that is 12 to 18 hours behind the customer's app, every call starts with the customer knowing more than the agent.
- Treasury visibility. Intraday liquidity management on instant rails needs intraday data. Batch feeds give treasury a rear-view mirror at exactly the moment they need a windscreen.
- AML noise. Transaction monitoring already runs at 85 to 95 percent false-positive rates at typical mid-market banks. Piling real-time volume onto a batch-oriented monitoring stack makes that ratio worse, not better, because the tuning was never designed for the velocity.
Each of these lands on a different team, which is part of why it stays unfixed. Nobody owns the whole gap.
The left-behind risk
Here is the pattern worth naming. The banks and PSPs that upgraded the rails but not the ledger are quietly becoming the higher-risk counterparties in the network. Regulators notice. Corporate clients notice when their treasurers get better data from a fintech than from their tier-one bank. Fraud rings absolutely notice.
The firms shipping ahead in 2026 are not the ones with the flashiest AI story. They are the ones whose internal ledger updates in the same second the rail does. Everyone else is going to spend the next two years explaining why their incident response, their liquidity reporting, and their fraud metrics all trail the market by a shift.
What a streaming reconciliation model looks like
You don't need to rip out the general ledger to fix this. You need to stop treating reconciliation as a nightly job and start treating it as a continuous data product.
A few concrete shifts the stronger operators are making:
- Event-sourced payment records. Every state change on a payment becomes an immutable event on a log, not a row update. Kafka, Pulsar, or the equivalent inside the bank.
- Continuous matching, not batch matching. Recon engines subscribe to the event stream and resolve matches as events arrive. Exceptions surface in minutes, not the next morning.
- A real-time position store. Treasury, fraud, and ops all read from the same materialised view of current state. One version of the truth, updated per event.
- Batch as a fallback, not the source. The overnight file becomes a consistency check against the stream, not the system of record.
None of this is exotic engineering anymore. It is well-understood streaming architecture applied to a domain that has been putting it off. The question is whether your team has the senior engineers who have actually built event-driven ledgers, or whether they are learning on your production traffic.