Why Most U.S. Banks Still Can't Send an Instant Payment

The Federal Reserve launched FedNow in July 2023. Three years later, fewer than 1 in 5 eligible financial institutions can send a payment on it. Here's the real reason why. The United States now has two instant payment networks. The Federal Reserve's FedNow Service launched in July 2023 [1]. The Clearing House's RTP® network has been running since 2017 [2]. Together, they form a modern real-time payment infrastructure that covers the entire country, operates 24 hours a day, 365 days a year, and settles in seconds. Yet as of early 2026, fewer than 1,700 of the nation's 10,000+ eligible financial institutions are connected to FedNow [3] — and participation in RTP is similarly limited at around 1,100 institutions [4]. The overlap between them is significant, meaning most banks and credit unions aren't fully connected to either network, let alone both. This is not a story about banks lacking interest. When researchers ask financial institutions why they haven't connected, 73% cite their existing core banking system as a moderate-to-severe obstacle [5]. The problem isn't willingness. It's a technical barrier that runs far deeper than it first appears. I know this problem from the other side. I spent two years at IBM working as the Application Architect and Technical Anchor for Santander Brazil's integration with PIX — Brazil's national mandatory instant payment system, which serves over 175 million users and processes more than 63 billion transactions per year [6]. The architecture we designed for that project is the same class of problem that every U.S. bank trying to connect to FedNow or RTP faces today. Let me explain exactly what the barrier is, and why none of the obvious solutions actually fix it. The four incompatibilities that block every bank Every U.S. bank runs on a piece of software called a core banking system. It tracks accounts, processes transactions, manages balances. The three vendors that supply these systems to the majority of U.S. banks — Fiserv, Jack Henry, and FIS — collectively serve around 72% of the market [7]. These platforms were engineered in the 1970s and 1980s for a world of batch processing: transactions accumulate during the day, then settle overnight in bulk. FedNow and RTP were designed for a different world entirely. They require four things that legacy core banking systems structurally cannot provide: 1. Per-transaction processing under 20 seconds. FedNow requires individual payment completion in under 20 seconds [8]. RTP settles within seconds, with a 5-second response window per message [9]. Legacy core systems process in nightly batches. These are not two speeds of the same thing — they are fundamentally different computational models. 2. 24/7/365 availability with no maintenance windows. Both networks operate continuously. Legacy core systems go offline periodically for maintenance, upgrades, and reconciliation. A system that goes down at 2 a.m. on Sunday cannot participate in a network that never goes down. 3. ISO 20022 messaging. FedNow and RTP both use the ISO 20022 international messaging standard — structured JSON (FedNow) and XML (RTP) with a specific schema for each message type. Legacy core systems use proprietary, vendor-specific data formats. They don't speak ISO 20022 natively, and adding an API endpoint doesn't fix the underlying translation problem. 4. High-volume concurrent transaction processing. Real-time payment volumes can spike sharply and unpredictably. Legacy cores were not designed for high simultaneous load — they were designed for controlled batch windows. None of these are minor adjustments. You can't patch your way out of them. Replacing the core system to fix them costs tens of millions of dollars and takes five to ten years, with substantial operational risk — that's a non-starter for the community banks and credit unions that make up the vast majority of unconnected institutions. Why the three existing solutions don't work When banks recognize this gap, they typically encounter three approaches. None of them solve the problem at scale. Approach 1: Custom point-to-point integration. Some banks hire technology firms to build a bespoke bridge between their core system and FedNow or RTP. This works, but it is expensive, applies to only one rail at a time, and cannot be reused by anyone else. Every bank that takes this route solves the same engineering problem independently. And if the bank later wants to add the second rail, the custom integration work starts over from scratch. Approach 2: Wait for the core vendor. In theory, Fiserv, Jack Henry, and FIS could update their platforms to natively support both rails. In practice, these vendors have enormous customer bases, long development cycles, and limited commercial incentive to move quickly. Many community banks have been waiting years for their core vendor to provide a usable FedNow integration path. Where vendor solutions do exist, they are proprietary, locked to that vendor's customers, and typically cover only one rail. Approach 3: Replace the core system. Newer cloud-native platforms support real-time payments natively. But migrating a bank's core system is a multi-year, multi-million-dollar transformation with significant regulatory and operational risk. For a $400 million community bank or a 12,000-member credit union, it is simply not a realistic option. The gap in the market is specific: there is no broadly available, vendor-neutral, open-source middleware solution that a financial institution can use to connect its existing Fiserv, Jack Henry, or FIS core to both FedNow and RTP without replacing it. The custom firms solve it once each, expensively. The vendors solve it slowly, proprietarily. No one has built the shared piece. What PIX taught me about solving this When PIX launched in Brazil in November 2020, Brazilian banks faced exactly this situation. Their core systems — many running on IBM z/OS mainframe infrastructure — were built for batch processing. PIX demanded 24/7 real-time ISO 20022 settlement from day one, under a Central Bank mandate [6]. The architectural solution we designed at Santander Brazil was a five-layer middleware framework. Each layer addressed one of the incompatibilities: An Anti-Corruption Layer that translated between ISO 20022 and the bank's proprietary internal data formats — without touching the core system itself A Shadow Ledger that maintained real-time balance tracking independently of the core, so the bank could continue processing payments even when the core was offline for maintenance A Synchronous-to-Asynchronous Bridge that absorbed FedNow's 20-second response requirement and the core's inherently slower processing cycle Saga orchestration to manage distributed transaction state across multiple systems, with compensation logic for rollbacks A processing engine with idempotency controls and circuit breakers The most important architectural insight wasn't any of these components individually. It was that approximately 85% of this work is identical regardless of which core banking vendor the institution uses, and regardless of which payment rail delivers the message. Only the vendor-specific adapter layer — around 15% of the total scope — changes between institutions. This means a single shared framework, built once and completed through bounded vendor-specific adapters, could serve thousands of institutions across multiple rails. The open-source gap-fill I've spent the past year building exactly this for the U.S. context. The result is OpenFedNow — an open-source middleware framework (Apache 2.0) that connects legacy Fiserv, FIS, and Jack Henry core banking systems to both FedNow and RTP, without requiring any modification to the existing core. The framework implements the same five-layer architecture validated in production at Santander Brazil, adapted for U.S. core banking vendors and the regulatory environments of the Federal Reserve and The Clearing House. All three vendor adapters are implemented and tested. Both rail gateways — FedNow (JSON/ISO 20022) and RTP (XML/ISO 20022) — are implemented in reference mode, with Layers 2 through 4 rail-agnostic by design: they operate on parsed ISO 20022 objects with no knowledge of which rail delivered the message. The dual-rail architecture matters more than it might seem. Among institutions that are already connected to instant payments, 58% participate on both FedNow and RTP [10]. Jack Henry — one of the three dominant core banking vendors — formally recommends that institutions receive on both networks as their baseline strategy [11]. A community bank that connects to FedNow today will likely want RTP connectivity tomorrow. OpenFedNow is designed so that adding the second rail requires only the remaining Layer 1 gateway components — the shared processing infrastructure is already there. The framework is publicly available at github.com/danielsmori/open-fednow under the Apache 2.0 license — free to use, evaluate, or build on, for any financial institution or technology vendor. What the path forward looks like The 8,300+ U.S. financial institutions not yet connected to either instant payment network are not going to connect by replacing their core systems or paying for expensive custom integrations. The path to broad participation runs through shared, reusable, vendor-neutral middleware infrastructure — the same approach that worked in Brazil, the UK, and every other country that has achieved high-coverage instant payment adoption. The technical barrier is real, but it is not unsolvable. The architecture is known, the vendor adapters are built, and the code is free. If you work at a financial institution evaluating FedNow or RTP connectivity — or at a core banking technology firm — I'd welcome a conversation. The framework is at the link above, and I'm reachable in the comments or via GitHub. Source List [1] Federal Reserve. "Federal Reserve launches the FedNow® Service." July 20, 2023. https://www.federalreserve.gov/newsevents/pressreleases/other20230720a.htm [2] The Clearing House. "RTP® Network." https://www.theclearinghouse.org/payment-systems/rtp [3] Federal Reserve Financial Services. "FedNow Participating Financial Institutions." https://www.frbservices.org/financial-services/fednow/fednow-participating-financial-institutions.html [4] The Clearing House. "RTP Participant Finder." https://www.theclearinghouse.org/payment-systems/rtp/rtp-participant-finder [5] U.S. Faster Payments Council / Finzly. "From Potential to Profit: Five Ways FIs Can Break Barriers to Benefit from Instant Payments." 2024. https://finzly.com/knowledge-hub/faster-payments-council-instant-payments-report-2024/ [6] Banco Central do Brasil. "Pix Statistics." https://www.bcb.gov.br/en/financialstability/pix_statistics [7] Federal Reserve Bank of Kansas City. "Market Structure of Core Banking Services Providers." April 2024. https://www.kansascityfed.org/research/payments-system-research-briefings/market-structure-of-core-banking-services-providers/ (Fiserv 42% + Jack Henry 21% + FIS 9% = 72%) [8] Federal Reserve Financial Services. "FedNow Service Operating Procedures." https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/fednow/fednow-operating-procedures.pdf [9] Finzly. "10 crucial questions about RTP technical certification every bank should know." https://finzly.com/resources/blogs/10-crucial-questions-about-rtp-technical-certification-every-bank-should-know/ [10] PYMNTS. "58% of US Banks Now Use Both RTP Network and FedNow." 2025. https://www.pymnts.com/real-time-payments/2025/58percent-of-us-banks-use-both-rtp-and-fednow-for-instant-payments [11] Jack Henry & Associates. "FedNow and RTP: How Do They Differ and How Do You Choose?" FinTalk. https://www.jackhenry.com/fintalk/fednow-and-rtp-how-do-they-differ-and-how-do-you-choose