Real-Time Payment Reconciliation: Why It Should Be a Check, Not a Calculation

In April 2024, Synapse Financial Technologies filed for Chapter 11, and the four partner banks holding its end users’ funds discovered they couldn’t answer the one question that actually mattered: whose money is this? By the time a court-appointed trustee finished picking through the wreckage, she’d identified a shortfall of up to $95 million between what the banks held and what depositors were owed — and, as Banking Dive reported, nobody had ever been checking, in real time, that those two numbers stayed equal.

If you’ve spent time in fintech software development, this isn’t a shocking story. It’s a familiar one wearing a bigger price tag. Every fintech with more than one settlement partner has lived some smaller version of it — the ledger says one thing, the bank statement says another, and someone spends a day proving which one is lying. Synapse is just what happens when that gap is allowed to compound for long enough, across enough partner banks, without anyone owning the reconciliation.

The industry’s response to Synapse has mostly been regulatory: the FDIC’s proposed rule on custodial account recordkeeping would force banks to maintain daily-reconciled, auditable records of who owns what inside pooled FBO accounts. That’s necessary. It’s also not sufficient, and it’s aimed at banks, not at the fintechs building on top of them. The deeper fix has to happen in architecture: real-time payment reconciliation needs to stop being a batch process that calculates what the ledger should say, and start being a continuous check that confirms the ledger is already right.

That’s the argument this piece makes. Not “add more monitoring” — a different relationship between your ledger and the outside world.

The Rails Got Fast. The Back Office Didn’t.

Real-time payments aren’t an emerging trend anymore — they’re where the volume already lives. The RTP network, operated by The Clearing House, is running close to $500 billion in transaction value per quarter in 2026, averaging more than 1.5 million payments a day and reaching roughly 75% of U.S. bank accounts. Every instant payment processed through the RTP network settles in seconds with final, irrevocable finality — a different animal entirely from a T+1 ACH batch. FedNow, the Fed’s younger instant-payments rail, has crossed 1,600 participating financial institutions as of early 2026, after 2025 volume grew 460% year over year. Industry analysts expect combined real-time payment transaction volume across both rails to climb from roughly 8 billion transactions in 2026 to nearly 13.9 billion by 2028 — a 31.7% compound annual growth rate. Deloitte, meanwhile, has projected that real-time electronic payments could pull almost $19 trillion in B2B volume away from ACH and paper checks by 2028.

None of that growth curve was matched by an equivalent shift in how anyone reconciles the money once it’s moved. The rails settle in seconds; the back office still runs on a nightly file. That same gap showed up in our Fintech Garden episode with Dan Feaheny: banking moved from end-of-day processing to always-on infrastructure, but the trust and identity layers never caught up at the same speed. Real-time money movement without continuous proof is acceleration without control.

And the fintech sector building on top of these rails still has a long runway ahead of it — McKinsey put global fintech revenue at roughly $650 billion in 2025, a 21% jump year over year, yet that’s still only about 4% of the roughly $15 trillion global financial-services revenue pool. There’s a lot of room left to grow. Scaling that growth on top of infrastructure that can’t answer “is our balance sheet correct, right now” is a bet most executives don’t realize they’re making until it comes due.

Three Questions Most Fintech Leadership Teams Can’t Answer on the Spot

Ask a CFO or Head of Product these three questions cold, and watch how long it takes to get a real answer:

How much of our cash is actually available right now?

Money moving between a BaaS partner, the card networks, and clearing rails exists in a genuine limbo state — not yet “yours,” not exactly “gone.” Without a live view of what’s settled versus still in flight, cash-in-transit is invisible until someone manually pulls it together. That’s a solvable engineering problem, and it usually comes down to fintech integrations that were never built to expose real-time state in the first place.

Does what we owe users match what’s actually sitting in the bank?

This is the exact mechanism that failed at Synapse — and it’s structurally identical to what the FDIC’s proposed rule is now trying to force banks to police from the outside. The uncomfortable truth is that fintechs shouldn’t need a regulator to make them check this. It should already be true, continuously, by design.

What did we actually make this month?

Interchange, float income, processing costs — all of it gets recognized only after settlement lag clears. Pricing decisions, risk appetite, hiring plans: all of it gets set against numbers that were already stale by the time anyone looked at them.

The Part Nobody Puts in the Slide Deck: Cross-Border and Multi-Currency Breaks

Everything above gets meaningfully harder the moment a fintech operates in more than one currency, and this is the part most reconciliation discussions skip entirely because it’s genuinely unpleasant to solve.

A domestic RTP or FedNow transaction has one currency, one settlement window, and (usually) one intermediary. A cross-border payment has a trade date, a value date, an FX rate locked at authorization time that may not match the rate realized at settlement, and often a correspondent banking chain where each intermediary bank takes its own cut and posts on its own schedule. That means a single customer-facing transaction can generate three, four, or five separate internal postings, each with a different effective date, each denominated in a different currency, each arriving at a different time.

The practical consequence: a reconciliation engine that only understands “does amount X on our side match amount X on their side” will flag FX-driven variances as breaks constantly, because a few basis points of rate slippage between authorization and settlement is normal, not an error. Real reconciliation logic needs a tolerance band that’s aware of why a variance exists — a rate movement inside expected bounds is not the same category of problem as a duplicate posting, even though both show up as “the numbers don’t match” if you’re not careful about how you classify them. Teams that don’t build this distinction in from day one end up either drowning in false-positive exceptions or, worse, tuning their tolerance bands so loose that a real break slips through disguised as FX noise.

A Taxonomy of Reconciliation Breaks (Most Teams Only Handle One Kind)

This is worth stating explicitly, because most reconciliation tooling — homegrown or vendor — treats “the numbers don’t match” as a single problem. It isn’t. There are at least four distinct categories, and each needs a different resolution path:

• Timing breaks. The transaction is real and correct on both sides; one system just hasn’t caught up yet. Bi-temporal matching against effective date, not system clock, resolves the overwhelming majority of these automatically.
• True breaks. A genuine discrepancy — duplicate posting, missing posting, wrong amount. These are the only category that should ever reach a human.
• FX/rate breaks. Variance explained by exchange rate movement between authorization and settlement, within an expected tolerance band.
• Fee and rounding breaks. Small, structural discrepancies from processor fees, rounding rules, or currency minor-unit conversion that recur predictably and should be auto-classified, not investigated fresh every time.

Once breaks are classified this way, three operational metrics become possible — and worth tracking as seriously as uptime:

• Match rate: the percentage of transactions that auto-reconcile without human intervention. Mature real-time systems should be well north of 95%; anything meaningfully below that is a signal the matching logic (or the tolerance bands from the section above) needs work, not that the team needs to work harder.
• Break aging: how long an open exception has been sitting unresolved. A break aging past 24-48 hours in a real-time system is a process failure, not just an inconvenience.
• Mean time to resolution (MTTR): how long it takes, from detection to close, to resolve a true break. This is the number that should be reported to leadership alongside uptime and latency — because a reconciliation break is, functionally, a partial outage of trust in your own numbers.

What Batch Reconciliation Actually Breaks in Practice

None of this is theoretical if you’ve operated payments infrastructure for more than a year. The failure modes are boring and specific:

A retried payout reuses an idempotency key and books the same transfer twice — a duplicate the PSP’s own system never generated. A webhook silently drops, and your ledger keeps showing “pending” while the processor already shows “paid.” Neither of these announces itself. They sit there until the next batch run surfaces a discrepancy nobody can immediately explain.

Here’s the version that actually costs a day of somebody’s life: finance flags a $90,000 settlement sitting in the ledger that never hit the bank account. It gets escalated to engineering. Engineering pulls webhook logs. Someone finally calls the PSP to confirm what actually cleared on their end. A full day disappears — three teams, one preventable bug, and whatever business decision was waiting on that number sitting stalled the whole time.

That’s the real cost of relying on anything short of automated reconciliation. Not that batch processing is slow — it’s that it turns every single discrepancy into a cross-functional investigation instead of a boring, automated non-event. This is also where the line between your payment processing layer and your ledger tends to blur: the PSP moves the money, but only the ledger should be trusted to say what actually happened.

Batch vs. Real-Time Payment Reconciliation, Side by Side

The row that actually matters is the second one. In a batch model, the bank file is the truth, and your ledger is a best-effort reconstruction of it. Flip that relationship — make the ledger the system of record and the bank file a confirmation you check against — and real-time reconciliation stops being a calculation you run and starts being a proof you pass or fail.

What Real-Time Payment Reconciliation Actually Requires

An event-sourced, double-entry fintech ledger as system of record. Every money movement posts at the moment of authorization or intent, not at settlement. The ledger doesn’t wait for the bank to tell it what happened — it already knows, and the bank’s file becomes the thing that has to agree with it.

A multi-account ledger system built for real fan-out. Marketplaces splitting settlements across sellers, escrow accounts, tax jurisdictions, and multiple bank partners generate reconciliation complexity that grows exponentially, not linearly, with scale. A single flat ledger table doesn’t survive that; a properly designed multi-account structure does.

Bi-temporal matching. Reconcile against a transaction’s effective date, not the system clock. This one design decision alone eliminates most of the false-positive “missing” alerts that in-flight settlements otherwise trigger — the transaction isn’t missing, it just hasn’t cleared yet, and a well-designed matcher knows the difference.

Confidence-scored automated matching. The overwhelming majority of transactions — often north of 95% — should auto-clear with zero human involvement. Route only genuine breaks (not timing artifacts) to a person, and that person’s day stops being a forensic exercise.

Sagas instead of two-phase commit for distributed money movement. Real-time payments almost never touch a single database transaction — a payout might involve your ledger, a PSP call, a notification service, and a fraud check, each a separate system. Trying to wrap all of that in a classic two-phase commit doesn’t scale and creates its own class of outages. The pattern that actually works is a saga: each step posts a local transaction and emits an event, with a compensating action defined for every step in case something downstream fails. Done right, this is what makes the ledger able to post at “intent” instead of waiting for every downstream system to confirm — the saga handles the choreography, and the ledger just needs to know what to reverse if the choreography breaks.

Tamper-evidence beyond double-entry. Double-entry accounting proves your books balance internally; it doesn’t prove nobody altered a historical entry after the fact. Some real-time ledger implementations are borrowing an idea from triple-entry accounting and hash-chaining each entry to the one before it — the same tamper-evidence concept underpinning blockchain ledgers, applied to a conventional database. It’s not necessary for every fintech, but for anyone who expects to be audited by a banking partner or regulator on short notice, it removes an entire category of “prove this wasn’t changed” conversation before it starts.

Solid api banking solutions underneath all of it. None of this holds together without well-built APIs wiring your ledger to RTP, FedNow, card networks, and every bank partner in real time. This is also exactly why white label banking platforms live or die on their ledger architecture — the brand on the app is only as trustworthy as the reconciliation happening underneath it.

This is now a market, not a build-it-yourself problem. Flagship Advisory Partners formalized “Ledger-as-a-Service” as its own infrastructure category in a July 2025 report, explicitly citing Synapse as the cautionary tale that made the category legible. Modern Treasury — founded in 2018, backed by Altimeter, Benchmark, and Y Combinator — has built exactly this kind of real-time ledger, connecting across ACH, wire, RTP, and FedNow for banks, marketplaces, and issuers. Ledger as a service sits alongside the broader shift toward payment as a service as core infrastructure fintechs increasingly buy rather than build. The point isn’t to pitch a vendor; it’s that sophisticated capital already treats real-time ledgering as foundational plumbing, not a nice-to-have you get to later.

Migrating Without a Big-Bang Rewrite

The obvious objection to everything above: nobody gets to rebuild their ledger from scratch on a clean slate. There’s a live system processing real money, and “we’re rearchitecting reconciliation” is not a sentence that gets you a maintenance window.

The pattern that actually works in practice is a strangler migration, applied to the ledger specifically:

1. Dual-write, don’t cut over. Stand up the new event-sourced ledger alongside the existing system and write every new transaction to both. The old system stays authoritative; the new one is just listening and building up its own history.
2. Shadow-reconcile the two ledgers against each other. Before the new ledger is trusted with anything, it needs to prove it agrees with the old one, transaction for transaction, for weeks — not days. This is the same continuous-check philosophy from the rest of this article, just applied to the migration itself.
3. Cut over reads first, writes last. Once shadow reconciliation is clean, start serving balance queries and reporting from the new ledger while the old one is still the system of record for writes. This is where most of the organizational risk in the migration actually gets retired, because it’s low-stakes: if the new ledger is wrong, nothing downstream actually broke yet.
4. Flip the system of record, keep the old ledger as a fallback. Only after reads have been stable for a full reconciliation cycle (ideally a full month-end close) does the new ledger become authoritative for writes. Keep the old system running in read-only mode for at least one more cycle — it’s your rollback plan if something the shadow period didn’t catch shows up.

The teams that get burned here are almost always the ones that skip step 2 because it feels like busywork. It isn’t. It’s the only part of the migration that tells you, with evidence instead of hope, whether the new ledger actually understands the business the way the old one did.

What We’ve Seen Building This at DashDevs

A few patterns show up repeatedly across the fintech engagements we’ve done in this space — including work like our Kleos core banking case — worth naming plainly:

The gap is almost never a single bug — it’s an accumulation of small architectural shortcuts. Nobody sits down and decides to build a fintech without real-time reconciliation. It happens one integration at a time: a new PSP gets bolted on with its own webhook handling, a new bank partner gets added with a slightly different file format, a new product line starts splitting settlements a new way. Each shortcut is individually reasonable. The sum is a ledger nobody fully trusts.

Teams underestimate how much of “reconciliation” is actually a data modeling problem, not a matching-algorithm problem. The engagements that go fastest are the ones where the ledger’s schema already distinguishes effective date from posting date, already tags transactions with enough metadata to classify a break automatically, and already treats multi-currency and multi-party splits as first-class citizens rather than edge cases bolted on later. The engagements that drag are the ones trying to retrofit a smarter matching engine onto a ledger schema that was never designed to support it — you can’t out-algorithm a data model that’s missing the fields you need.

The organizational fix and the technical fix have to land together. A better ledger doesn’t help if finance still treats every automated exception the way they used to treat every batch discrepancy — as something that needs a human to eyeball before anyone trusts it. Part of what makes real-time reconciliation actually stick is redefining, explicitly, what counts as an event worth a person’s attention versus what the system is now allowed to clear on its own. That’s a change management conversation as much as an engineering one, and skipping it is why some technically sound real-time ledger rollouts still end up with a human quietly re-checking everything anyway.

That last point echoes what Rob Lunn argued on Fintech Garden episode 128: without interoperability between treasury, payments, and accounting systems, automation only amplifies existing inefficiencies. Real-time payment reconciliation fails for the same reason — disconnected data models, not insufficient matching code.

Why This Isn’t Just an Engineering Problem

Regulators are done being patient. The FDIC’s proposed rule would require banks holding custodial FBO accounts to maintain daily-reconciled, auditable records identifying beneficial owners and their balances — a direct response to Synapse, and a strong signal of where supervisory expectations are headed for the fintechs sitting on top of those banks too.

Fraud and error windows shrink or they don’t. Continuous matching catches a duplicate posting or a partner-bank break in the same cycle it happens. Batch reconciliation catches it whenever the next file runs — which, for anything that occurs on a Friday night, can mean an entire weekend of exposure. As we discussed in Fintech Garden episode 149, the industry rewarded acceleration — real-time payments, faster onboarding, automated compliance — while resilience lagged. Continuous reconciliation is part of closing that gap.

Product velocity is downstream of this, whether people realize it or not. Instant payouts, dynamic risk limits, same-day pricing changes — none of it is possible on top of a ledger that only tells the truth once a day. The same logic applies to core banking systems more broadly: real-time rails are pushing what used to be a back-office nicety into a baseline expectation for any modern banking stack. Treasury products in banks — cash concentration, liquidity sweeps, just-in-time vendor payments, instant payroll — only scale safely when real-time deposits and each real-time money transfer can be proven against the ledger in the same cycle they clear.

From Producing Truth to Proving It

Here’s the mental model shift, stated plainly: stop treating reconciliation as the nightly process that produces your truth, and start treating it as the continuous process that proves your ledger and the real world already agree.

Synapse is what it looks like when nobody can run that proof — when the gap between “owed” and “held” is allowed to grow quietly for long enough that by the time someone notices, it’s a bankruptcy filing instead of an automated alert. The fintechs that don’t end up as the next cautionary case study will be the ones that can already answer, at any given moment, whether their balance sheet checks out — not the ones that find out the hard way, after it’s too late to do anything but explain it to a trustee.