Sebastien Rousseau
Get in touch ›

The Multi-Rail Bank in 2026: Cards, A2A, Stablecoins, RTP, FedNow, and Open Banking in One Strategy

Multi-rail strategy is a routing engine, a liquidity book, and an ISO 20022 translator stacked above the legacy core. Architects who treat it as a product launch will fund three rails and operate none of them well.

14 min read

The Multi-Rail Bank in 2026: Cards, A2A, Stablecoins, RTP, FedNow, and Open Banking in One Strategy

US wholesale payments now run across five live rails simultaneously. Cards have ridden the same Visa and Mastercard interchange tracks since the 1970s. ACH still moves the bulk of payroll and B2B at fractional cost with T+1 settlement. The RTP network ⧉ has been instant since 2017, 24/7, and runs through The Clearing House's joint account at the Fed. FedNow ⧉ came online in July 2023 with a parallel architecture and a separate liquidity pool. USDC and tokenised bank deposits clear atomically on Ethereum, Solana, and bank-operated permissioned chains.

None of these rails is replacing the others. The bank that picks one and bets the strategy on it will be wrong inside two product cycles. The bank that runs them all without an orchestration layer will discover, around year three, that it has built five integration projects and operates none of them efficiently.

This article is about how the orchestration actually works.

Executive Summary / Key Takeaways

  • The orchestration engine is the product. Routing logic that picks FedNow over RTP over ACH over USDC per transaction — on cost, finality, counterparty capability, and pre-funded liquidity availability — is what defines the multi-rail bank. Everything else is implementation detail.
  • Liquidity is the operating cost no one mentions. FedNow and RTP both demand pre-funded 24/7/365 balances in central-bank joint accounts. A naive multi-rail rollout doubles that capital trap. A netting-aware orchestrator collapses it back toward one pool.
  • ISO 20022 pacs.008 is the only viable bridge. Core banking systems emit MT103 or proprietary fields. A2A APIs and Open Banking endpoints consume pacs.008 structured data. The translation layer in the orchestrator is what carries debtor/creditor agent BICs, structured remittance, and purpose codes through without lossy mapping.
  • Atomic settlement on stablecoin rails reshapes correspondent banking. A USDC transfer between two wallets clears in seconds with no Nostro/Vostro reconciliation. That is a structural threat to the correspondent banking revenue line, not a fintech feature.
  • Open Banking APIs are the consumer-side mirror of A2A. The same orchestration engine that decides FedNow vs ACH on a B2B payment decides PIS (Payment Initiation Service) vs card-on-file on a consumer checkout — driven by the same routing facts.
  • The bank that owns the routing logic owns the margin. If the routing engine is rented from a vendor, the vendor sets the take rate on every transaction the bank books.

How an Orchestration Engine Actually Routes a $500 B2B Payment #

A US-domiciled mid-market corporate triggers a $500 supplier payment from its ERP. The payment lands in the bank's orchestration engine as an ISO 20022 pacs.008 message with structured remittance, the supplier's account details, a settlement window of "today if possible," and a stated tolerance of "next business day acceptable."

The engine reads four facts off the message and the bank's current state:

  1. Counterparty rail capability. The supplier's bank is a TCH RTP participant. It is also addressable on FedNow. It accepts ACH credits. It does not have a USDC wallet on file.
  2. Cost per rail. FedNow imposes a flat $0.045 sender fee. RTP imposes $0.045 plus the bank's internal liquidity cost on its TCH joint-account balance. ACH costs $0.0029 per credit, settled T+1. USDC: gas + the internal cost of holding stablecoin inventory, irrelevant here because the receiver has no wallet.
  3. Pre-funded liquidity availability. It is 11pm Eastern. The bank's FedNow joint account at the Fed currently holds $42m. The TCH joint account holds $61m. Both are above any plausible single-payment threshold. The marginal cost of using either rail right now is the foregone overnight earnings on the $500 used — measured in fractions of a cent.
  4. Settlement-window value to the payer. The pacs.008 declared "next business day acceptable." That is the routing signal that tilts the decision.

The orchestrator routes to ACH. The payer's tolerance for T+1 means there is no commercial reason to spend an additional 4.2 cents (FedNow fee minus ACH fee) for finality the payer has explicitly said is optional. The pacs.008 instruction is rewritten as a NACHA-format CCD entry, the structured remittance is preserved as an addenda record, and the transaction is queued for the next ACH window.

If the same payment arrives at 9am Eastern with "settle today" in the pacs.008 settlement-window block, the routing tilts to FedNow. If it arrives marked "atomic dollar settlement, wallet attached," the routing tilts to USDC. The engine does not have an opinion about which rail is "modern." It has an opinion about which rail minimises total cost — fee plus liquidity opportunity cost — at the finality the payer asked for.

That decision logic is the orchestration engine. Building it is the product.

The 24/7 Pre-Funded Liquidity Trap #

Every instant rail in production today operates on a pre-funded model. The Fed does not extend intraday credit to FedNow participants. The Clearing House does not extend it to RTP participants. Settlement on both rails happens against a pre-funded joint-account balance that the participating bank parks at the relevant operator — at the Fed for FedNow, at TCH for RTP — and replenishes 24/7/365.

The operational consequence is severe. A bank running FedNow for a $100m daily peak instant-payment volume holds tens of millions in idle balance just to cover intraday peaks. Running RTP in parallel adds a second idle pool. The two pools cannot net against each other because they sit at different operators. Each pool earns the relevant interest-on-reserves rate (FedNow) or zero (TCH operating account) and forgoes whatever the bank could earn on the same balance in repo, money market funds, or short-duration Treasuries.

That is the unspoken operating cost of multi-rail instant payments. A bank that funds two instant rails without an orchestration strategy is parking twice the idle balance for twice the foregone earnings.

The orchestrator minimises the trap in three ways:

Without the orchestrator, the bank funds for peak-of-peak demand. With the orchestrator, it funds for forecasted demand plus a margin. The difference, on a $5 B/day instant-payments business, is tens of millions in idle balance and seven to eight figures in foregone overnight earnings.

The ISO 20022 pacs.008 Bridge #

Core banking systems built in the 1980s and 1990s emit MT103 fields or proprietary internal formats. A2A APIs (Open Banking PIS, FedNow's FedLine endpoints, TCH's RTP messaging) consume ISO 20022 pacs.008. The translation layer in the orchestrator is what carries the structured payload through without losing the fields A2A consumers depend on.

A pacs.008 message carries — at minimum:

A naive translation from a flat MT103 payload to pacs.008 will drop or mangle most of those structured fields. Free-text remittance lands in the wrong block. Purpose codes get reconstructed from substring matches and arrive as OTHR (the catch-all). Regulatory reporting is dropped entirely because the source MT103 had no structured slot for it. The receiving bank — and the receiving treasurer's ERP — gets payment confirmation with no machine-parseable metadata. Reconciliation goes back to manual review.

The orchestrator's translation layer needs to do three things that off-the-shelf MT-to-MX converters do not:

Banks that skip this layer end up with rail-specific translation pipelines duplicated across three or four integrations. Banks that build it once, properly, route any payment to any rail without re-implementing the message logic.

Multi-Rail Architecture, By Technical Layer #

The architecture below replaces the generic "workflow, data, control" framing that suits a board deck. The layers that actually carry the load are these.

Layer What it does in production Failure mode if mishandled Architectural directive
API Gateway & Orchestration Engine Accepts payment intent from ERPs, mobile apps, and core systems. Reads counterparty capability, current liquidity state, scheme participation, and payer preferences. Decides which rail to use. The bank rents the routing engine from a payments vendor. The vendor sets the take rate on every transaction. The bank's margin disappears into the vendor's pricing. Own the routing engine. Build it as an in-house service with rail-specific drivers behind a stable internal interface. Vendor SDKs become driver implementations, not the engine itself.
Liquidity & Ledger Layer Manages pre-funded joint-account balances at the Fed (FedNow), TCH (RTP), card-scheme settlement banks (Visa, Mastercard), and on-chain wallets (USDC inventory, tokenised deposit positions). Sweeps idle balances into overnight repo. The bank parks idle balances at every rail operator simultaneously. Foregone earnings on a $5B/day instant-payments book run to seven or eight figures annually. Forecast instant-payment demand by hour. Fund the joint accounts to the forecast plus a margin. Sweep everything else. The Treasury function owns the daily replenishment policy, not the rail-product team.
Messaging & ISO Translation Layer Translates between the bank's internal payment format, MT103 (where still used), pacs.008 / pain.001 / camt.053 (ISO 20022), NACHA CCD/PPD (ACH), card-scheme ISO 8583, and on-chain transaction primitives. Enriches as it translates. Validates against the target scheme profile. Lossy translation drops structured remittance and purpose codes. Receivers cannot reconcile programmatically. Manual investigation backlog grows. Build a single enrichment-aware translator with target-scheme profile validation. MT-to-MX converters are an input, not the answer. Test against each scheme's reference profiles in CI.
Counterparty & Capability Registry Knows which rails each counterparty is addressable on, what scheme profiles they accept, what their per-transaction limits are, what jurisdictions impose what reporting. The orchestrator routes to a rail the receiver cannot accept. The payment fails or settles slowly with manual intervention. Maintain the registry as a first-class data product. Refresh it daily against scheme directories, central-bank participant lists, and Open Banking aggregator capability feeds. The registry is what makes the routing decision auditable.
Fraud, Sanctions & Authorisation Runs real-time screening on every payment intent against sanction lists, fraud models, authorisation rules, and consent records. Returns allow/block/escalate in milliseconds. Screening runs after rail submission. Sanctioned payments leave the bank and are recalled. Each recall is a regulator-reportable incident. Screen at the orchestration entry point, before rail selection. The same screening result must be valid across every rail the orchestrator may pick.
Settlement Reconciliation & Reporting Matches every outbound payment against settlement confirmations, status updates (pacs.002), and incoming camt.053 statements. Detects breaks within hours, not days. Reconciliation runs T+2 by spreadsheet. Settlement breaks accumulate. Customer disputes escalate. Reconcile per-rail with a unified data model. The same break-detection logic runs against FedNow, RTP, ACH return file, card-scheme settlement file, and on-chain transaction confirmation.

What This Means by Bank Type #

Global Banks #

Global banks already operate the most fragmented rail estate. Each region funded its own integrations under its own product P&L. The result is three or four parallel multi-rail rollouts, each running its own thin routing layer, each negotiating separately with the same vendors.

The directive: fund a single agnostic orchestration layer above the legacy cores, charged to platform engineering rather than to any product group. The orchestrator owns the routing decision globally; the regional product groups consume it as a service. The vendor SDKs that each region brought in become rail-specific drivers behind the orchestrator's internal interface, not parallel routing engines competing for the same payment.

The economic argument lands at the chief financial officer. A single global orchestrator captures every routing decision, every margin point, and every piece of structured payment data the bank generates. Three regional orchestrators capture none of those things at the group level.

Regional Banks #

Regional banks face a different problem. They have fewer rails to integrate but proportionally less capital to park in pre-funded joint accounts. A regional bank with a $500m daily instant-payments book is parking, conservatively, $30-50m at the Fed for FedNow plus another $20-30m at TCH for RTP — a meaningful share of its discretionary balance sheet sitting at zero or near-zero yield.

The directive: build a liquidity-aware orchestrator before adding the second instant rail. A regional that joins FedNow and RTP simultaneously without a netting strategy doubles the pre-funded balance trap without commensurate volume increase. The right sequence is FedNow first, instrument the demand profile, fund the joint account to the observed peak, then add RTP only when the orchestrator can route the marginal payment to whichever pool is better-funded.

The capital question dominates. Regional bank treasurers should be quantifying foregone earnings on pre-funded balances as a line item in the multi-rail business case, not absorbing it as an unstated cost of innovation.

Fintechs and PSPs #

Fintechs and payment service providers sit between the corporate or merchant and the bank rail. The competitive question for them is whether they add abstraction the bank cannot build itself.

The directive: ship the orchestration as a service to mid-market banks that cannot fund their own. Sell the routing engine, the liquidity forecasting, and the ISO 20022 translation as a managed platform. The fintechs that try to compete with global banks on routing logic will lose on the orchestration engine's margin economics. The fintechs that sell the same logic to banks too small to build it themselves will own the regional segment.

Corporate Treasurers #

Treasurers consume rail outputs through their ERP integrations. The 2026 question for them is whether the structured data their bank emits is rich enough to automate reconciliation without manual review.

The directive: demand pacs.008-rich remittance data in every incoming payment confirmation. Specifically, demand structured invoice references in RmtInf/Strd/RfrdDocInf, demand purpose codes from the ISO 20022 ExternalPurposeCode list rather than the catch-all OTHR, and demand status updates (pacs.002) on the same API endpoint as the confirmation. Banks that cannot provide that data are signalling that their translation layer is still doing lossy MT-to-MX conversion. That is the right RFP question for the 2026 bank-selection cycle.

The reconciliation argument lands at the treasurer's own desk. Automated invoice matching against structured pacs.008 remittance reduces the AP team's exception queue by 60-80%. That is the durable productivity gain the treasurer can demand and measure.

What Happens Next #

The visible 2026 milestones are scheme-level: FedNow and RTP rail-volume crossovers, Open Banking PIS coverage moving past 60% of UK consumer checkouts, the first US-domiciled bank running a bank-issued stablecoin in production for cross-border B2B. Those are the press-release facts.

The invisible 2026 work is the orchestrator. The banks that fund it in 2026 will be the banks routing 80% of US B2B payments by 2028. The banks that fund another rail integration without the orchestrator will spend the same dollars and end up where they started — running three or four rail products in parallel with no margin capture.

The multi-rail bank in 2026 is not a bank that operates more rails. It is a bank that built the routing engine, the liquidity book, and the pacs.008 translator that the rails sit on top of.

Questions? Answers.

Is FedNow or RTP going to win?

Neither. Both rails will run in parallel for the foreseeable horizon. The participant lists overlap significantly but not completely — there are banks on FedNow that are not on RTP and vice versa. Until the participant overlap is near-total, the orchestrator routes to whichever rail reaches the counterparty.

Should a mid-market bank build its own orchestration engine or buy?

Build the routing logic in-house if the daily payment volume is above roughly $1B. Below that, the engineering cost of building it does not amortise against the margin captured. Buy from a fintech that sells the orchestration as a managed service, and negotiate hard on the take rate per transaction.

What does atomic settlement actually mean for correspondent banking?

A USDC transfer between two custody wallets clears on-chain in 15-30 seconds with no intermediary Nostro/Vostro account. The same dollar movement across traditional correspondent banking touches three to five accounts, each with its own settlement timing, and reconciles over hours to days. For a corridor where both counterparties have wallet infrastructure, the on-chain path is structurally cheaper and faster. Correspondent banking revenue on those corridors will compress.

What is the right starting point for the ISO 20022 translation layer?

Start with pacs.008 outbound, pain.001 inbound (the customer credit transfer initiation), and pacs.002 status reporting. Those three messages cover 80% of the wholesale payment flow. Add camt.053 reconciliation and pacs.004 returns as the second wave. Do not start with the message library — start with the scheme profile each receiving rail requires and work backward.

How much pre-funded balance does FedNow actually demand?

It depends on participant volume. A bank seeing a $50m peak hourly instant-payment outflow needs roughly that order of magnitude in its FedNow joint account at the Fed, sized for the hour ahead. With sweep automation tied to forecasted demand, the steady-state balance can run closer to the median rather than the peak — but the peak still needs to be coverable on a few minutes' notice.

References #

Last reviewed .