FedNow Was Just the Start: Why Your Legacy Core Can’t Handle the "Request for Pay" Wave

In 2025, the volume of settled payments on the FedNow Service surged by nearly 460% year-over-year, clearing over 8.4 million transactions . While significant, this volume is merely the proving ground for a far more disruptive mechanism currently gaining traction in the B2B and bill-pay sectors: Request for Pay (RfP).

According to a 2025 survey by the U.S. Faster Payments Council, 34% of businesses are actively seeking instant methods for recurring bill payments, citing "Request for Pay" as a high-priority adoption target. However, the same data reveals a critical friction point: RfP adoption faces challenges not because due to technical unreadiness at the receiving institutions.

For decades, core banking architectures were designed for an asynchronous world. They operate on the assumption that payments are "pushed" by the sender and settled in batches during quiet hours. RfP inverts this logic. It allows a biller to "pull" funds (with payer consent) in a synchronous, real-time environment. This inversion exposes a fatal flaw in legacy core systems: they cannot validate, process, and settle inbound requests within the millisecond-level timeout windows required by modern payment rails.

Financial institutions (FIs) that view FedNow and RTP merely as faster versions of ACH are missing the structural threat. The issue is not the speed of money movement; it is the speed of logic validation.

When "Real-Time" Meets "Batch"

The defining characteristic of an RfP message (technically, a pain.013 message under ISO 20022 standards) is its requirement for immediate deliverability and validity checks. When a utility company sends an RfP to a customer’s bank app, the network demands an instant confirmation that the account exists, is active, and is eligible to receive the request.

Most legacy cores, however, run on "memo posting" logic during the day and "hard posting" during overnight batch cycles. They are not designed for read/write intensity in real-time.

• The Conflict: To validate an RfP, the payment gateway must query the core. If the core is locked for a batch update, or if the mainframe is prioritized for other tasks, the query queues.
• The Consequence: Real-time networks like The Clearing House RTP and FedNow have strict timeout thresholds (often under 5 seconds for total round-trip). If the legacy core takes 6 seconds to wake up and validate the account status, the transaction fails.

This latency gap creates a poor user experience, phantom declines where the customer has funds but the bank’s infrastructure cannot confirm it fast enough. As volumes scale, this shifts from a nuisance to a systemic operational risk.

The ISO 20022 Data Payload Problem

The core value proposition of Request for Payment (RfP) for corporate clients extends beyond mere speed; its crucial benefit is reconciliation. Standard ACH transfers offer limited remittance information, but an RfP message is designed to carry rich, structured data essential for accounting, such as invoice numbers, due dates, and line-item specifics. This comprehensive data payload is facilitated by the ISO 20022 standard, which employs XML syntax.

Legacy cores, typically built on COBOL or early-generation SQL architectures, rely on fixed-width fields. They often have strict character limits for transaction descriptions (e.g., 18 or 40 characters).

• Data Truncation: When a data-rich ISO 20022 message hits a legacy core, the system must either reject the message or truncate the data to fit its database schema.
• Value Erosion: Truncating the data strips the invoice details. The money moves, but the automated reconciliation—the primary reason the corporate client chose RfP—breaks.

Institutions are forced to build complex "translation layers" or middleware to store the full data payload outside the core, associating it with the transaction ID. While functional, this adds another "hop" to the processing chain, further increasing the latency mentioned in the previous section.

The Micro-Bursting Threat

The introduction of the "Request for Pay" model significantly changes the transaction volume and traffic patterns directed at a bank's ledger. Unlike the traditional push-payment system, where transaction volume is somewhat dispersed or managed according to the bank's own batch schedules, the pull-payment model results in volume being determined by the biller's schedule.

Consider a scenario where a major telecom provider sends 500,000 RfP messages to its subscribers at 9:00 AM on the billing due date. This creates a "micro-burst"—a massive spike in Transactions Per Second (TPS) hitting the bank's validation logic simultaneously.

Legacy mainframes have a hard ceiling on concurrent connections. A micro-burst of RfP validation queries can effectively DDoS (Distributed Denial of Service) a bank’s own internal ledger, slowing down not just payments, but mobile app logins and branch teller systems. Modern cloud-native cores mitigate this via auto-scaling (spinning up new instances to handle the spike), a capability that monolithic mainframes fundamentally lack.

The Integration Tax

The immediate reaction from many FIs is to wrap the legacy core in APIs—a strategy often termed "hollowing out the core." While this extends the life of the asset, it introduces an Integration Tax.

Every layer added between the payment rail (FedNow/RTP) and the system of record (the Core) adds processing time and failure points.

1. Translation Layer: Converts ISO 20022 XML to Core-friendly formats. (+Latency)
2. Orchestration Layer: Decides if the transaction is fraud-checked, sanctioned-screened, and posted. (+Latency)
3. API Gateway: Manages traffic and security. (+Latency)

In an asynchronous ACH world, this latency was invisible. In a synchronous RfP world, where every millisecond counts against the timeout clock, this tax becomes visible as failed transactions.

Decoupling Logic from the Ledger

Architectural agility, rather than mere speed, is now the core focus of payment modernization. The successful banks in the current wave of Requests for Proposals (RfPs) are not focused on immediate core replacement, but on separating payment logic from account storage.

To address the demands of "Request for Pay" (RfP), banks are implementing modern, cloud-native solutions like Sidecar Cores or dedicated Payment Hubs. These systems operate alongside the existing legacy core, taking on critical tasks such as high-speed validation, management of ISO 20022 data, and handling the sudden, micro-burst traffic associated with RfP. The legacy core is only updated during periods of lower activity through batch or asynchronous synchronization, thereby alleviating performance pressure.

Moving toward a decoupled architecture requires a precise understanding of where your current technical debt lies. It demands a rigorous audit of existing dependencies, latency thresholds, and data schema limitations. To assist technical leaders in this evaluation, we have codified the essential criteria for this transition in the Devsu App Modernization Checklist. This framework provides the baseline necessary to identify structural friction points before they manifest as operational failures in a real-time environment.