The pitch is irresistible. Real-time settlement: instant funds, no overnight delay, money moves at the speed of the customer. Batch settlement, by comparison, sounds like something from a 1970s mainframe: files, schedules, T+1, T+2, settlement windows.
The pitch is also misleading. Batch isn't slow because it's old; it's batched because batching solved real problems. Real-time isn't fast because it's modern; it's fast because it accepts a different set of trade-offs that don't always make sense for the merchant. The choice between them is one of the most important architectural decisions a payment platform makes, and the way the choice is usually framed — "real-time good, batch bad" — obscures what's actually being decided.
What batch settlement actually does
In a batch settlement model, transactions accumulate during some window (typically a day) and are settled in a single operation at the window's close. The merchant doesn't see funds in their bank account until the settlement file is processed and the funds are transferred — usually one or two business days later (T+1 or T+2).
What batch buys you:
Risk windowing. Within the settlement window, the platform has time to detect fraud, hold suspicious transactions, and reverse mistakes before the funds are committed. Once batch settles, reversal becomes harder; before settlement, it's just a database update.
Reconciliation accuracy. Batches produce settlement files with full transaction detail. Reconciliation can run on the complete batch, with all amounts, fees, and adjustments visible. Discrepancies surface clearly because everything in the batch is closed.
Cost amortization. Network fees, processing infrastructure, and operational costs are amortized across the batch. Per-transaction costs are lower than they would be for individual real-time settlements.
Operational simplicity. Batch processing happens on a schedule. Operations teams know when batches run, what they look like, and what to investigate when something goes wrong. There's a single time window each day where the action happens.
Refund eligibility. Refunds against transactions in the same batch can be netted, simplifying both the merchant's accounting and the processor's settlement.
These are real benefits. The cost is that the merchant doesn't see funds for one to two business days.
What real-time settlement promises
Real-time settlement (FedNow, RTP, SEPA Instant, UPI in India, PIX in Brazil) moves funds in seconds rather than days. The transaction ID, the amount, and the receiving bank account are all that's needed to push funds end to end.
What real-time buys you:
Cash flow. The merchant has funds available immediately. For SMBs operating on thin margins, this is genuinely valuable. A restaurant that takes $5,000 in card payments at lunch can pay its evening staff with that money the same day.
Customer expectations. Some customer flows expect instant settlement: gig economy payouts, peer-to-peer transfers, instant withdrawals. Without real-time, these flows have to use workarounds (instant payouts that are actually credit lines, for example).
International parity. In countries where real-time is the default (UPI, PIX), batch-only platforms feel obsolete. International expansion requires real-time capability for some markets.
New product surfaces. Real-time enables products that don't exist in batch (instant refunds, instant payouts to workers). For platforms targeting these surfaces, real-time isn't optional.
What real-time costs:
Reduced risk window. Funds are committed in seconds. If fraud is detected after settlement, recovery is much harder than reversing a batch entry. The platform takes more risk, or has to build sophisticated real-time fraud detection, or both.
Higher per-transaction cost. Real-time payment rails charge per transaction, with no batch amortization. For low-value transactions, the per-transaction fee can exceed the value of the speed.
Reconciliation complexity. Real-time transactions don't fit cleanly into daily batches. Reconciliation has to happen continuously, and accounting periods become fuzzier — when does a transaction "belong" to a day?
Operational continuous-attention. Real-time systems don't have a quiet period. Operations needs 24/7 monitoring, real-time alerting, immediate response capability. The operational burden is higher.
The choice depends on what you're settling
Different things need different settlement models, and conflating them is where mistakes happen.
Card transactions typically settle in batch by design. The card networks (Visa, Mastercard) operate on batch settlement schedules. Even if your bank is real-time-capable, the network leg is batch. "Real-time card settlement" usually means the platform fronts the merchant the funds and waits for the network's batch to clear behind the scenes.
Bank transfers (ACH, wire, SEPA) can be batch or real-time depending on the rail. ACH in the US is batch. FedNow and RTP are real-time. SEPA Credit Transfer is batch (T+1); SEPA Instant is real-time (10 seconds).
Internal platform settlements — moving funds between accounts within the same platform — are always real-time technically (it's a database update) but may be exposed as batch for consistency with external settlements.
Marketplace splits — paying out portions of a transaction to different recipients — depend on the underlying rails and the platform's risk appetite. Some platforms split in real-time (gig economy), others batch (most marketplaces).
The architecture decision isn't "are we real-time or batch?" It's "for each settlement flow, what model is appropriate?" A platform might use batch for card-to-bank settlements, real-time for instant payouts to workers, and a hybrid for marketplace splits. Each has its own logic.
When real-time makes sense
Real-time is the right choice when:
- The merchant or end-user values immediate funds enough to pay for it.
- Transaction values are high enough that the speed value exceeds the per-transaction cost.
- The platform can absorb or manage the increased risk window.
- The use case can't tolerate batch delays (e.g., emergency disbursements, gig payouts).
- Competitive pressure requires it (e.g., other platforms in the vertical offer it).
Concretely: gig economy platforms paying drivers daily, lending platforms disbursing loans, B2B payment platforms where invoice settlement is the customer pain point, marketplace platforms competing on payout speed.
When batch is the right answer
Batch is the right choice when:
- The merchant doesn't urgently need funds same-day (most retail, most B2B).
- Transaction values are low and per-transaction fees would dominate.
- Risk windowing has measurable value (fraud detection, dispute prevention).
- Reconciliation needs the structured periodicity batch provides.
- The platform has strong operational tooling for batch and would have to rebuild it for real-time.
Concretely: most card-based payment platforms, most subscription billing platforms, most restaurant POS systems, most e-commerce checkout. The merchant wants reliable T+1 settlement; they don't need T+0 enough to pay for it.
The default for most card-accepting merchants is batch, and that's not because they're behind the times. It's because the trade-offs work for them.
The hybrid model most mature platforms use
Real platforms rarely commit to one model exclusively. The mature pattern:
Batch for card-based settlements. Daily settlement to merchant bank accounts. Predictable, low-cost, well-tooled.
Real-time for instant features. Optional same-day deposits ("get your funds today for a small fee"), instant payouts to gig workers, emergency disbursements.
Internal real-time for platform mechanics. Within the platform's own ledger, all transactions are real-time. The platform settles externally on its own schedule.
Batch for compliance and reporting. Tax reporting, regulatory reporting, fee invoicing — all run on batch periodic windows.
The hybrid model gets the speed where it matters and the cost/risk benefits where speed doesn't add value. The key is being explicit about which is which.
Architecture differences
The architecture for batch and real-time settlements is genuinely different.
Batch architecture centers on the settlement file. Files arrive on a schedule, get parsed, matched against internal records, generate ledger entries, trigger downstream processes. The processing happens in scheduled jobs. Latency from transaction to settlement is hours.
Real-time architecture centers on event streams. Each transaction is a real-time event; settlement is a real-time response; ledger entries are written in the same transaction as the settlement. There are no files; there are no scheduled jobs; everything happens in microseconds.
You can't easily retrofit real-time onto a batch architecture, or vice versa. The data flows are different, the consistency models are different, the failure modes are different. Platforms that try to "add real-time" to a batch architecture end up with a parallel system that doesn't quite integrate, plus all the operational overhead of running both.
The smarter approach: design the orchestration layer to be settlement-agnostic. The orchestrator doesn't know whether settlement is batch or real-time; it just sees settlement events. The settlement adapter translates between the rail's behavior (batch file or real-time stream) and the orchestrator's internal event model. Adding real-time later means adding a new adapter, not rebuilding the orchestrator.
The risk shift
Real-time settlement shifts risk in subtle ways.
In a batch model, the platform holds funds during the settlement window. If fraud is detected, the platform reverses the entry before settlement. The merchant never sees the bad funds; the platform absorbs the operational hassle of the reversal but not the financial loss.
In a real-time model, the platform settles funds immediately. If fraud is detected after settlement, the funds are in the merchant's account. Recovering them requires the merchant's cooperation, a reversal request through the rail (which may or may not succeed), or absorbing the loss.
The shift looks small but compounds. A platform processing $1B annually with 20 bps of fraud absorbs $2M in losses if those frauds clear before detection. In batch, much of that $2M might be caught and reversed. In real-time, more of it sticks.
Mature real-time platforms invest heavily in real-time fraud detection — sub-second risk scoring, transaction-level holds before settlement, dynamic limits based on merchant risk profile. This is its own engineering project, with its own infrastructure cost.
Reconciliation in real-time
Reconciliation is the part where real-time gets uncomfortable.
In batch, reconciliation is a defined event. The day's settlement file arrives, you compare it to your records, you flag exceptions. The day's results are knowable and bounded.
In real-time, "the day" is a fuzzy concept. A transaction at 11:59:58 PM and another at 12:00:02 AM are sub-seconds apart but in different days. Reconciliation can't wait for the day to end because there's no end. Either you reconcile continuously (challenging) or you define artificial day boundaries that approximate batch (defeats the purpose somewhat).
Most real-time systems use a hybrid: real-time matching for individual transactions (each settlement event is reconciled against the corresponding internal record as it arrives), with batch-style summary reports for accounting periods. The continuous reconciliation catches anomalies fast; the batch summary supports financial reporting.
This is more infrastructure than batch alone. The reconciliation pipeline has to handle both the per-transaction stream and the periodic summary, and they have to agree.
Cash flow implications for merchants
For SMB merchants, the cash flow benefit of real-time is real. A retail merchant doing $200K/month in card volume, settling T+2 to T+0, gains roughly $13K in working capital (two days of receivables converted to cash). For a thin-margin business, that's meaningful.
But: real-time often costs the merchant something. Either explicitly (a fee per real-time transaction or per same-day deposit) or implicitly (a slightly higher overall rate to cover the platform's increased risk). The merchant's cash flow improves; their cost goes up.
Most merchants, given the choice, don't pay extra for speed. They take the standard T+1 or T+2. The cohort that does pay for speed is real but smaller than vendors marketing real-time would suggest. Platforms that build expensive real-time infrastructure on the assumption that all merchants will adopt it discover the demand isn't there at the price they need to charge.
The successful real-time products are the ones priced for the cohort that values it: gig workers wanting same-day payouts, contractors with cash flow stress, businesses with specific same-day operational needs. Pricing it for these segments and accepting that most merchants will stay on batch is the realistic stance.
The compliance overlay
Real-time and batch have different compliance profiles. A few highlights:
SAR filings (Suspicious Activity Reports). Both batch and real-time require SAR filing for suspicious transactions. In batch, you have hours to detect and file. In real-time, the transaction may have settled before you can review it, requiring after-the-fact filings and possibly fund recovery efforts.
Sanctions screening. Both models require OFAC and other sanctions screening. Real-time requires the screening to happen pre-settlement, which adds latency budget pressure. Batch can screen during the batch window, with more time per transaction.
Anti-money-laundering thresholds. Reportable transactions (typically $10K in the US) need handling. In batch, aggregation is straightforward. In real-time, structuring detection (multiple sub-threshold transactions designed to evade reporting) requires real-time aggregation across transactions.
Network rules. The card networks have rules about settlement timing, dispute windows, and chargeback eligibility. These rules assume batch in their structure. Real-time platforms have to layer on top of this, which can be awkward.
Looking forward
Real-time settlement is becoming the default in some geographies. Brazil's PIX has 80%+ adoption. India's UPI is the dominant rail. Europe's SEPA Instant is growing. The US is slower (FedNow launched in 2023, RTP earlier) but accelerating.
For platforms operating in these markets, real-time isn't optional anymore. Customers expect it. Competitors offer it. Regulators require it for some flows.
For platforms operating primarily in markets with strong batch infrastructure (US, much of Western Europe), batch will remain dominant for card transactions for years. The card networks aren't moving to real-time; their batch model is too ingrained. Real-time will be a feature alongside batch, not a replacement.
The architecturally smart position is to build for both, default to batch where it makes sense, offer real-time as a premium feature where it does. Don't commit ideologically to one model.
What I'd build today
If I'm designing a payment platform from scratch in 2026:
- Internal ledger is real-time, period. Every event is a real-time database write. Internal reconciliation is continuous.
- Card settlement to merchants is batch, T+1 by default, T+0 (same-day) as a paid premium feature.
- Real-time rails (FedNow, RTP, SEPA Instant, regional equivalents) are integrated as separate adapters in the orchestration layer. Same internal model, different external rail.
- Reconciliation is continuous matching plus periodic summary reports.
- Risk and fraud systems are real-time-capable. Real-time fraud scoring on every transaction, with the capability to hold transactions pre-settlement when needed.
- Reporting is batch by default (daily, monthly, quarterly summaries) with real-time dashboards for operational use.
The platform is real-time-capable but doesn't force every flow to be real-time. The merchant chooses the speed appropriate to their business and their willingness to pay.
The harder truth
The real-time vs. batch debate is often framed as a generational divide: old systems are batch, modern systems are real-time. This framing is wrong and leads to bad architectural decisions.
The right framing: real-time and batch are different tools, with different costs and different benefits. The mature platform uses both, deliberately, based on what each settlement flow needs.
The pressure to "be real-time" is real, but it's mostly marketing pressure. The actual customer demand for real-time at every settlement is limited and often overstated. The customer demand for reliable, well-reconciled, low-cost settlement is universal — and batch usually serves it better.
Build for the customer's actual needs, not for the slide deck. The slide deck says real-time; the merchant's operational reality often says batch. Listen to the merchant.
This is part of a series on payment systems architecture. See also the hardest part of payment systems is reconciliation and event-driven architecture for payment processing.