A batch settlement system fails closed. If something goes wrong at 11pm, the nightly run stops, someone gets paged, and the file reruns before morning. Nobody’s money has actually moved yet, so a bad record just gets fixed and resubmitted. Real-time rails take that safety net away. The payment has already settled by the time anyone notices a problem, and the fix has to happen in a world where the funds are gone.
This matters for anyone moving a settlement system off nightly batch windows and onto RTP, FedNow, or similar instant rails. The individual pieces, funding, duplicate detection, reconciliation, fraud screening, failure handling, look similar to what a batch system already does. What changes is the order of operations: everything that used to happen before money moved now has to happen while it moves, in a window measured in seconds.
Why a batch mindset breaks once settlement happens in seconds
A batch file is a single unit of work with a single outcome. It either processes clean or it gets rejected and reviewed before the next run. That structure lets teams build checks around the batch window itself. You validate the file, you reconcile the totals, you release it. The checks are separate from the payment.
Real-time settlement removes the gap between the check and the payment. There’s no file to hold, no overnight window to review, no natural pause where an engineer can look at a batch total and notice it’s off. Every validation, fraud screen, and balance check has to complete inside the same transaction that moves the money, and the transaction has to finish in a few seconds or the sending bank’s system will time it out.
The practical effect is that systems built for batch processing tend to carry assumptions that were never written down because the batch window made them safe to ignore: that there’s time to retry, that a human can intervene before funds move, that reconciliation happens after the fact rather than before it. Moving to real-time rails means finding every one of those assumptions and replacing it with something that holds up with the funds already gone.
Funding liquidity when money moves 24 hours a day, 7 days a week
Batch settlement lets a bank fund its settlement account once a day, based on a predictable net position calculated from the batch file. Real-time rails don’t give you that. Payments settle continuously, including nights, weekends, and holidays, and the settlement account has to carry enough balance to cover outbound transfers at any moment without waiting for a daily funding cycle.
This turns liquidity management into a live monitoring problem rather than a scheduling problem. Teams running real-time rails typically need:
-
A settlement account funded well above expected peak outflow, with a defined process for topping it up outside banking hours.
-
Real-time visibility into the account balance, not a balance that’s accurate as of last night’s batch.
-
An automatic response, such as throttling or queuing outbound payments, for when the balance runs low, rather than a manual escalation that assumes someone is at a desk.
FedNow and RTP both require participants to prefund or maintain settlement balances continuously, which is a different operational posture than the net settlement most ACH participants are used to. The liquidity desk’s job shifts from a daily calculation to something closer to continuous monitoring, and that shift usually requires new tooling, not just a new schedule.
Idempotency and duplicate prevention without a batch cutoff to catch errors
In a batch system, duplicate records often get caught during file validation, before anything settles. A duplicate request in a real-time system doesn’t get that pause. If a client retries a request after a timeout, or a network hiccup causes the same message to arrive twice, the system has to recognize the duplicate in-flight, before the second request settles as a second payment.
The standard fix is an idempotency key: the sender attaches a unique identifier to every payment request, and the receiving system checks that identifier against a short-lived store before processing. If the key has been seen before, the system returns the original result instead of processing again. This sounds simple, but it has to work under load, across retries that arrive milliseconds apart, and it has to be enforced at the point where the request first enters the system, not somewhere downstream where the damage is already done.
A few things worth getting right early:
-
Store idempotency keys with enough retention to cover realistic retry windows, including retries from a client that gave up and tried again hours later.
-
Treat the idempotency check as part of the critical path, not an optimization. A race condition here is exactly the kind of bug that only shows up under real traffic.
-
Decide explicitly what happens when a duplicate is detected after partial processing, such as a debit that posted but a credit that hasn’t. That partial state needs a defined resolution path, not an assumption that it won’t happen.
Batch systems could tolerate a sloppier approach here because a human reviewed the file before it posted. Real-time systems can’t.
Reconciliation when there is no overnight window left to do it in
Reconciliation used to be an overnight job: compare the day’s settled transactions against the ledger, flag mismatches, fix them before the branches opened. Real-time settlement means transactions post continuously, so waiting until 2am to reconcile means running reconciliation against a ledger that’s already hours out of date and still moving.
The shift is toward continuous or near-continuous reconciliation: matching settled transactions against internal ledgers in small windows, often every few minutes, rather than once a day. This requires the ledger itself to be built for frequent reads without locking up the write path, which is a real architectural constraint, not a reporting detail.
Mismatches also need a different handling process. In batch, a mismatch gets flagged and someone fixes the source file before resubmitting. In real-time, the mismatch is sitting against money that has already moved, so the resolution process has to work backward: open an exception case, hold the discrepancy in a suspense account, and resolve it through a separate correction transaction rather than editing the original record. Reconciliation stops being a nightly checklist and becomes a standing operational process with its own queue and its own staffing.
Fitting fraud and compliance checks inside a ten-second settlement clock
Batch systems can run fraud scoring and compliance screening as a step before the batch posts, with as much time as the model needs. Real-time rails typically give a transaction a window of a few seconds, sometimes closer to one, to clear fraud checks, sanctions screening, and AML rules before the payment either settles or gets rejected.
That time pressure forces tradeoffs. Full-file batch fraud models, the kind that look across a day’s volume for patterns, don’t fit in a single-transaction window. Real-time fraud screening has to work on a per-transaction basis, scoring each payment independently against a model trained to produce a fast answer with limited context. For a closer look at how that scoring actually works and where it catches things rule-based systems miss, see how machine learning catches fraud that rule based systems miss.
Compliance screening faces the same squeeze. Sanctions list checks and AML rules still have to run, but they have to run against a list that’s cached locally and fast to query, because a live lookup against an external database won’t finish in time. Teams usually resolve this by pre-loading screening lists into memory, keeping them updated on a tight refresh cycle, and accepting that the real-time check is a fast approximation of a more thorough process rather than a replacement for it.
Handling failures and reversals after a payment is already final
This is the part batch never had to deal with. A batch file can be pulled before it posts. A real-time payment, once settled, is final. There’s no overnight window to catch the error and quietly correct it before anyone notices. FedNow and RTP are both built around the idea that settlement finality is immediate and irrevocable.
That means every failure scenario, a wrong amount, a duplicate, a fraud case caught a few minutes too late, has to be handled through a new transaction rather than an undo. Practices that hold up here:
-
Build a return-payment process as a first-class transaction type, separate from the original payment, with its own tracking and its own approval path.
-
Set clear thresholds for what gets auto-returned versus what requires manual review, since not every error is worth the delay of human review.
-
Keep a record of every irreversible payment’s full context, not just the amount and parties, so disputes can be resolved without reconstructing what happened from fragments.
The operational mindset has to shift from “stop it before it posts” to “the payment already happened, now what.” That’s a genuinely different discipline than batch processing teams are used to, and it tends to need its own runbook rather than an adaptation of the existing one.
Choosing a path between RTP, FedNow, and ISO 20022 messaging
Most US fintechs weighing real-time settlement are choosing between The Clearing House’s RTP network and the Federal Reserve’s FedNow service, both of which run on ISO 20022 messaging. The two networks differ in reach, participating banks, and specific operational rules, and the right choice depends on which banks your business already connects to and which network they support.
ISO 20022 itself is worth separate attention, because it’s the messaging standard underlying both networks and it carries more structured data than older formats like NACHA batch files. That extra structure, including richer remittance information and standardized fields, is part of why real-time systems can carry more context with each payment than batch systems could. Teams building for real-time settlement generally need to invest in parsing and generating ISO 20022 messages correctly, since a malformed message doesn’t get caught by review the way a flawed batch file might.
The decision between networks isn’t purely technical. It depends on coverage, existing banking relationships, and sometimes a dual-rail approach where a business supports both and routes based on which network a counterparty can receive on.
Monitoring and alerting built for a system that never closes
A batch system’s monitoring question is usually “did the file run and did it balance.” A real-time system is always running, so monitoring has to answer a continuous question: is the system healthy right now, and will it still be healthy in the next minute.
This changes what gets watched and how fast someone has to respond. Settlement account balance, transaction latency, idempotency store health, and fraud-check response times all need live dashboards, not end-of-day reports. Alerting thresholds need to be tight enough to catch a problem before it compounds, since there’s no overnight window where a slow leak gets caught before it does real damage.
It also changes staffing. A system that settles continuously needs on-call coverage that matches, since a liquidity shortfall at 3am on a Saturday is a live incident, not something that waits until Monday. Teams moving to real-time rails often underestimate this until the first weekend incident makes the gap obvious.
Moving a settlement system from batch to real-time rails touches funding, duplicate handling, reconciliation, fraud timing, and failure recovery all at once, and each of those pieces has to hold up without the review window batch processing used to provide. For a look at how the consumer side of this same transaction flow works, from the checkout click through to a settled payment, see what actually happens between a checkout click and a settled payment.