Real-time payments have moved from novelty to necessity. But behind the clean “instant payment successful” screen is a messy infrastructure challenge that banks, fintechs, and regulators are all scrambling to solve at once.
The real-time moment: why infrastructure suddenly matters
For decades, payments moved at the speed of the banking day: batch files, end-of-day settlements, cut-off times, and “T+1” that nobody seriously questioned. That world is disappearing fast.
Real-time payment schemes such as India’s UPI, Brazil’s Pix, the U.S. FedNow and RTP networks, and the U.K.’s Faster Payments have pushed expectations toward “instant by default” across P2P, bill pay, merchant payouts, and increasingly B2B.
In the U.S., the Federal Reserve launched the FedNow Service in July 2023 to provide 24/7 instant payments between banks. By early 2025, more than 1,000 financial institutions had joined the network, a clear signal that FedNow is moving from early adoption to mainstream infrastructure. Real-time is no longer an innovation side project – it is becoming a core capability of modern banking.
The strategic question for banks, processors, and fintechs is now brutally simple: is your real-time payments infrastructure genuinely designed for instant, always-on money, or are you layering a slick instant UX on top of batch-era plumbing? The answer will determine your cost base, risk posture, and competitiveness for the next decade.
What actually counts as “real-time payments infrastructure”?
“Real-time payments infrastructure” is not just a faster switch or a new mobile app. It’s an integrated stack of capabilities that must work together in seconds, reliably, 24/7:
- Payment rails & scheme connectivity: Direct or indirect access to schemes like UPI payments, FedNow, RTP, Faster Payments, Pix, or local instant rails.
- Clearing & settlement engine: Real-time routing, posting, and confirmation logic, including updates to core banking or ledger systems.
- Messaging & data standards: Increasingly ISO 20022-based messages carrying rich, structured data for every instant payment.
- Fraud, AML, and sanctions controls: Risk engines that can score and respond in milliseconds rather than minutes.
- Liquidity and treasury tools: Intraday liquidity monitoring, funding of settlement accounts, and tools to manage 24/7 outflows across multiple instant payment rails.
- Access and experience layer: APIs, mobile apps, corporate banking portals, and embedded finance partners that originate payment instructions.
If any layer is stuck in a batch mindset, the overall experience ceases to be truly “real-time,” even if the external scheme technically is.
Inside the stack: an infographic-style view of real-time payments infrastructure
| 1. Customer channels (apps, portals, APIs) capture and display instant payments. 2. API and orchestration layer authenticates, routes requests. 3. Payments hub applies rules, ISO 20022, orchestration. 4. Risk layer runs real-time fraud, AML, sanctions, step-up checks. 5. Scheme gateways manage rail-specific formats, SLAs, and testing. 6. Settlement/core and observability handle liquidity, posting, monitoring, incident response. 7. Observability & operations, End-to-end payment tracking, real-time monitoring. |
Key architectural patterns for real-time payment rails
Supporting instant payments is less about vendors and more about architecture that delivers speed, resilience, and decoupling. Five patterns matter most.
1. Event-driven and API-first
Real-time payments are event streams, not batch jobs. Event buses and clear APIs make the flow observable and adaptable.
- Easier to add new rails
- Safer place to plug in monitoring and fraud
2. Decoupled payments hub
A scheme-agnostic hub breaks the spaghetti of channel-to-rail integrations and becomes the control point for all payments.
- One canonical payment model
- Central rules for routing, pricing, and limits
- ISO 20022-normalised data
3. High availability by design
Instant rails are always-on; downtime is no longer acceptable “maintenance.”
- Active–active / active–standby deployments
- Automated failover and resilience drills
4. Latency budgeting and performance
To hit sub-10s SLAs, each step must work in milliseconds. That drives disciplined engineering:
- Caching for limits and reference data
- Queues and back-pressure for spikes
5. Co-existing with legacy cores
You can’t swap the core overnight, so you shield it.
- Asynchronous updates from the real-time hub
- Shadow or modern ledgers for instant products
The aim: protect the instant experience now while gradually retiring batch-era constraints.
ISO 20022 and interoperability: the common language of instant payments
If real-time is the speed, ISO 20022 is the language that makes it scalable.
ISO 20022 is a global standard for financial messaging that defines richer, more structured payment data than traditional formats. Instead of squeezing information into free-text fields, it offers dedicated elements for payment purpose, remittance details, debtor and creditor information, and many other attributes. That structure matters when you are trying to automate processes in an always-on environment.
For real-time payments infrastructure, ISO 20022 enables higher straight-through processing rates, fewer repairs, and much smoother reconciliation. Corporate treasurers can match incoming instant payments to invoices more easily. Banks can automate exception handling and reduce the manual work that silently eats into the economics of instant payments.
As more high-value payment systems, cross-border networks, and domestic instant payment schemes migrate to ISO 20022, banks have an opportunity to converge on a single internal data model rather than maintaining a patchwork of legacy formats. A truly ISO 20022-native payments hub can normalise data once and then route it to different schemes without repeated translation. That simplifies the architecture and sets the stage for better analytics, fraud models, and customer insights.
It also improves risk and compliance. Richer structured data gives fraud and AML engines better signals, from payment purpose codes to counterparty details, which helps distinguish risky behaviour from normal activity. For cross-border corridors, ISO 20022 is increasingly seen as the common language that can link domestic instant schemes and correspondent banking networks, reducing friction for international commerce.
The strategic takeaway is simple: ISO 20022 migration should be treated as a core part of your real-time payments strategy, not a stand-alone compliance deadline.
Risk, compliance, and 24/7 fraud controls
Real-time payments compress the window for managing financial crime and operational risk. In a batch world, there was time to investigate suspicious items before final settlement. In an instant world, once the funds are gone, they are often gone for good.
That forces a shift from post-transaction investigation to in-the-flow decisioning. Fraud and AML checks must be completed within milliseconds and integrated directly into the real-time payment path. Rules engines are still useful, but they need to be augmented with machine learning models that look at behavioural patterns across devices, merchants, and networks. Dynamic limits, velocity checks, and step-up authentication have to be applied selectively so they control risk without frustrating legitimate customers.
Sanctions and watchlist screening must also keep up. Relying on slow list updates or crude fuzzy matching either blocks a large number of legitimate instant payments or lets risky ones through. Institutions are investing in real-time list management, smarter matching algorithms, and risk-tiered strategies that can treat low-value domestic payments differently from high-risk cross-border ones.
Operational resilience is no longer just an IT concern; it is a regulatory focus area. In many markets, major instant payment rails are viewed as critical national infrastructure. Outages, cyber incidents, or misrouted real-time payments can trigger supervisory reviews, mandated remediation programmes, and in some cases fines. That pushes boards and executives to pay closer attention to observability, incident management, and the division of responsibilities between first and second lines of defence.
Business case and operating model choices
It is easy to treat real-time payments infrastructure as a cost of doing business. In practice, there are clear value levers that can justify the investment if they are planned and measured properly.
The first lever is revenue and retention. Instant payments enable premium treasury services such as just-in-time supplier payments, instant payroll, and real-time liquidity sweeps across accounts and entities. They unlock embedded finance use cases like real-time marketplace payouts or instant withdrawals for gig workers. Customers who experience reliable instant payments through their primary bank are also less likely to migrate day-to-day activity to competitors or non-banks.
The second lever is cost and efficiency. Better data and higher automation reduce exception handling and manual reconciliation effort. Over time, as volumes shift to instant payment rails, there may be opportunities to simplify or retire some legacy infrastructure, lowering the overall cost-to-serve.
Risk and capital form the third lever. Rich ISO 20022 data, combined with behavioural models, can reduce fraud losses and improve the quality of AML and sanctions controls. That can translate into fewer write-offs and lower regulatory penalties. Real-time visibility into flows also helps treasury teams make more precise decisions about intraday liquidity and collateral.
The operating model choices sit on top of these levers. Institutions must decide how much to build, how much to buy, and where to partner. Many start with processor-based connectivity to schemes like FedNow or RTP to get to market quickly and then gradually bring orchestration, data, and risk capabilities in-house through a payments hub. Others aim to own the full stack from day one for differentiation, especially where instant payments are central to their strategy.
There are also choices about whether to connect directly to schemes or rely on aggregators, and whether to charge for instant payments as a premium feature, bundle them into existing packages, or offer them free as table stakes. The right answer varies by market and segment, but the key point is that commercial strategy should be designed alongside architecture, not bolted on at the end.
What to do next: a roadmap for banks and fintechs
If you’re planning or scaling real-time payments infrastructure, a practical roadmap looks like this:
- Baseline assessment
- Map end-to-end payment flows and systems
- Identify where batch dependencies, manual steps, or legacy formats block instant payments
- Target architecture & ISO 20022 strategy
- Define your payment hub and API gateway patterns
- Decide whether ISO 20022 will be a translation layer or a native internal schema
- Regulatory and scheme alignment
- Understand scheme-specific rules (limits, SLAs, settlement mechanics) across UPI, FedNow, RTP, Pix, etc.
- Clarify expectations on resilience, fraud controls, and data retention
- Pilot high-impact use cases
- Start with focused journeys: instant payouts, P2P, bill payments, or specific B2B corridors
- Use them as testbeds for architecture, risk models, and liquidity tools
- Scale and optimize
- Add more rails and corridors
- Tune fraud/AML models using real transaction data
- Expand liquidity dashboards and tooling
- Productise the infrastructure
- Expose developer-friendly APIs for partners and fintechs
- Launch real-time treasury and cash management products
- Package insight dashboards around real-time payment flows
The institutions that win in real-time won’t just be the fastest to connect to a rail. They’ll be the ones treating real-time payments infrastructure as a strategic asset, with clear architecture, governance, and monetization – not as an invisible back-office utility.