Real-time payments infrastructure gets budgeted, almost universally, as a technology build: settlement rails, API integration, a go-live date. The operational cost of actually running real-time settlement — the monitoring, the fraud detection recalibration, the liquidity management that real-time finality genuinely requires — is consistently underestimated in the initial business case.
Batch settlement gives institutions a natural checkpoint to catch errors before finality — a window, however brief, in which a mistake can be caught and corrected before money has genuinely and irreversibly moved. Real-time settlement removes that window by design, which means the fraud detection and error-checking that used to happen during the batch window now has to happen before the transaction, not after — a materially different, more demanding operational requirement.
Firms that budget real-time payments builds as a technology project, without separately budgeting for this operational uplift, consistently discover the gap after go-live, when transaction volumes reveal that pre-transaction checking wasn't resourced adequately for the finality guarantee the new system actually makes.
The build cost is usually the smaller number in a real-time payments programme. The larger, less visible cost is the ongoing operational capability — monitoring staff, recalibrated fraud models, liquidity buffers sized for a settlement pattern that no longer has a batch window to smooth it — and this cost needs to be in the original business case, not discovered as a post-launch surprise.
Institutions planning real-time infrastructure should budget the operational uplift with the same rigour as the technology build, because the technology, on its own, doesn't deliver the finality guarantee customers expect — the operational capability behind it does.