Real time versus batch payments

Real time payments settle individually, within seconds, at any time of day, including weekends and holidays. The payer receives immediate confirmation that the beneficiary has been credited, or that the payment has failed, and there is no waiting for a batch window or a cut off time. Real time systems are now available in many countries, and they are used for person to person transfers, urgent supplier payments, and any payment where the recipient needs immediate access to funds. The speed is a major benefit, but it also means that errors are hard to undo, and that fraud detection must happen in milliseconds before the payment is released. Batch payments are processed in groups at scheduled times. A company may submit a file of salary payments in the morning, and the file is validated, cleared, and settled in a batch later that day or overnight. Batch processing is efficient for high volumes, it allows for corrections before the batch is released, and it fits well with end of day reconciliation and liquidity management. Most traditional clearing systems, including many domestic automated clearing houses, are batch based. The trade off is that the beneficiary does not receive funds immediately, and the payer must respect cut off times or the payment will move to the next batch. A business analyst must be able to explain when to use each model and what the customer should expect. A salary run of ten thousand employees is well suited to batch, while a single urgent payment to release goods from a port needs real time. A payment product may offer both, with different pricing, different cut off times, and different service levels. Your requirements must state the expected processing time, the availability window, the cut off time, and the behaviour when a payment misses the cut off. Those details are often where customer complaints originate, and they are easy to get wrong if the distinction between real time and batch is not made explicit. Worked example with real numbers: a corporate must pay EUR 2 million in salaries on Friday. By SEPA Credit Transfer as a batch file, the file is uploaded at 08:00, cleared through STEP2 at 14:00, settled through T2 at 16:00, and the employees are credited by the end of the next business day at the latest, under the EPC SCT Rulebook 2025, version 1. 1, effective 5 October 2025. By SCT Inst the same EUR 2 million would need 500 separate instant payments, but the corporate would pay a higher per-payment fee and would need to fund each payment in real time, so the batch route is cheaper and simpler for salaries. The choice is therefore by use case, not by fashion, and the analyst must quantify the cost and the timing for both routes before recommending one. Failure and recovery: a real-time payment fails fast, within 10 seconds, with a pacs.002. A batch payment fails slowly, because the file is validated, cleared and settled in cycles, and a file error rejects the whole file, while a payment error rejects only that payment, and the corporate must be told which payments failed and why, by a pain.002 status report. A batch payment that misses its cut-off is value dated the next day, and the employees are paid late, while a real-time payment that misses its 10-second window is rejected, not delayed, and the customer must retry. Each failure has a different customer message, and the product must not tell a batch customer that the payment is instant, or an instant customer that the payment is queued. For a business analyst, product owner or subject matter expert, the test is to state, for every payment type, whether it is real time or batch, what the cut-off is, what the value date is, what the maximum execution time is, and what happens when the deadline is missed. The ISO 20022 pacs.008 carries both, but the scheme rules differ, and the requirement must cite the scheme: Regulation (EU) 2024/886 and the SCT Inst Rulebook for instant, and the SCT Rulebook for batch. A requirement that says fast, without naming the rail, the cut-off and the deadline, will be interpreted differently by every stakeholder, and the product will fail its first service level test.