As of April 2026
Every bank running both RTP and FedNow eventually hits the same incident. The dashboard shows the payment settled, the customer says it never arrived, and the ops team cannot tell which rail to investigate first.
Multi-rail used to be a strategy debate. Per the US Faster Payments Council’s 2025 Faster Payments Barometer, 58 percent of US banks that have enabled instant payments now use both rails. The debate is over. The cost just moved from the strategy deck to the operations floor.
Three things change the moment you cross from one rail to two. Exception handling becomes a decision tree, because ACH return reason codes do not map to RTP reject reasons, and neither maps to FedNow’s response codes, and a FedNow Request for Return of Funds is not a wire investigation. Reconciliation becomes real-time position-keeping across two liquidity models, because RTP runs against The Clearing House’s prefunded joint account while FedNow settles directly against your Fed master account, both around the clock, so there is no end-of-day position anymore. And routing stops being configuration: it is a per-transaction decision across cutoffs, limits, beneficiary preference, and bank capability, all evaluated in milliseconds.
Adoption
58%
of US banks enabling instant payments now run both RTP and FedNow (FPC 2025 Barometer).
Liquidity
Two pools
RTP against TCH's prefunded joint account, FedNow against your Fed master account, both 24/7.
Exceptions
No shared map
ACH return codes, RTP rejects, and FedNow response codes do not map to one another.
A control plane, not a router
The architectures that scale share one pattern: a rail abstraction layer that owns routing, exception classification, and reconciliation state. It is a control plane, not a switch statement, and it is what makes two rails behave like one to the customer.
What the layer has to own
It has to translate between exception vocabularies so an operator sees one classification, not three code sets. It has to keep a live position across two liquidity pools that never close, so reconciliation is a moving target rather than an end-of-day file. And it has to make the routing decision per transaction, in milliseconds, against cutoffs, limits, beneficiary preference, and each rail’s capability. Build that once, centrally, and the operational complexity of multi-rail stops leaking onto the customer and the ops floor. In the instant-payments deployments I have seen reach production, this is the dividing line between the banks that scale and the ones that firefight.
