Real-Time Payments Infrastructure: Architecture for ISO 20022 and Instant Settlement

Real-time payments have moved from pilot project to board-level mandate. FedNow is live, the RTP network keeps adding participating institutions, and ISO 20022 is now the messaging standard underneath both rails as well as the SWIFT CBPR+ migration. For banks and payment processors, the hard part was never deciding to support instant payments — it was re-architecting core systems built for overnight batch cycles to operate where a payment must be validated, screened for fraud, posted, and made final in seconds, every second of every day.

This article lays out the architecture we typically recommend when a bank or processor builds for real-time rails: how ISO 20022 migration actually works, what settlement finality means operationally, how fraud screening changes when the decisioning window drops to milliseconds, and the integration patterns that let a real-time payments engine plug into a core banking stack without becoming its own point of failure.

Table of Contents

• ISO 20022: The Messaging Standard Behind Instant Payments
• Migrating from MT and NACHA Formats to ISO 20022 XML
• Settlement Finality: FedNow, RTP, and Legacy Rails Compared
• Fraud Screening at Sub-Second Speed
• Integration Architecture for Banks and Payment Processors
• Operational Resilience in a 24x7x365 System
• Governance and Rollout Strategy

Key Takeaways

• ISO 20022 replaces flat legacy formats such as MT103 and NACHA batch files with structured XML carrying richer remittance and party data, which requires a data model change across core banking and screening systems, not just an edge translation.
• FedNow and the RTP network both deliver payment finality within seconds but differ in mechanics: FedNow uses real-time gross settlement against Fed master accounts, while RTP settles through pre-funded joint accounts, changing how each participant manages liquidity.
• Fraud screening on instant rails typically needs to complete in under 300-500 milliseconds end to end, pushing architectures toward pre-computed risk features, tiered decisioning, and in-memory lookups rather than batch-oriented rules engines.
• Most core banking platforms were not built for synchronous, always-on posting, so a real-time payments hub is commonly deployed as a decoupled layer in front of the core, reconciling asynchronously rather than writing to the ledger on the critical path.

ISO 20022: The Messaging Standard Behind Instant Payments

ISO 20022 is not a payments rail; it's the messaging standard that FedNow, RTP, SWIFT CBPR+, and a growing number of real-time gross settlement systems have converged on. Where legacy formats squeezed payment data into fixed positions or terse tags, ISO 20022 defines payments as structured XML messages built from reusable components — a pain.001 for a customer credit transfer initiation, a pacs.008 for a financial institution credit transfer, a pacs.002 for a status report. The benefit is richer, structured data: full remittance information, structured party fields, and purpose codes carrying far more signal than a SWIFT MT message or NACHA record ever did. The catch is that it's a superset of the formats it replaces, not a strict translation, so fields optional in legacy formats can become mandatory structured elements. Treating the migration as a syntax swap rather than a data model change is commonly where these projects lose months.

Migrating from MT and NACHA Formats to ISO 20022 XML

A message format migration typically involves three layers of work, and conflating them is a common source of delay. Syntactic mapping — converting MT103 fields or NACHA record types into the corresponding ISO 20022 schema — is the part most vendor tools already handle well. Semantic mapping is harder: deciding what happens when a legacy field has no clean equivalent, such as an unstructured name-and-address block that has to become distinct debtor and creditor identification schemes. Getting this wrong means downstream sanctions screening and fraud models receive incomplete party data, a compliance risk rather than a cosmetic one. The third layer is truncation and enrichment, since ISO 20022 messages are commonly richer than legacy core systems can consume. We generally recommend a canonical internal payment model, aligned to ISO 20022, with adapters that translate to MT, NACHA, and ISO 20022 as needed, avoiding a rebuild of core logic every time a new rail or format version arrives.

Settlement Finality: FedNow, RTP, and Legacy Rails Compared

Settlement finality is where legal and technical architecture have to agree exactly, because a mismatch here is a direct financial risk. FedNow settles using real-time gross settlement directly against Federal Reserve master accounts — each payment settles individually and instantly, with no netting window and no pre-funded pool, so a participant's core ledger needs to reflect a final position essentially the moment the message is confirmed. The RTP network, operated by The Clearing House, settles through joint accounts pre-funded by participants at the Federal Reserve Bank of New York; payments are still final within seconds, but they run through this pooled balance, so participants need processes to monitor and replenish it, since running low can affect their ability to send payments. Traditional RTGS and ACH, by comparison, settle only during operating hours or on a deferred net basis with a business-day lag — neither carries the always-on finality FedNow and RTP require, which is why a real-time engine needs continuous liquidity monitoring that ACH and wire processing never demanded.

Fraud Screening at Sub-Second Speed

Fraud screening is typically the hardest non-negotiable in a real-time payments build, because the payment is irrevocable once settled. Unlike card transactions, where a chargeback exists as a backstop, or ACH, where a return window gives a few business days to catch fraud, instant payments generally cannot be pulled back once settled, pushing the entire fraud burden onto the pre-settlement window — commonly a budget of well under a second. Architectures that hold up maintain continuously updated risk features in in-memory stores rather than calculating velocity signals live, use tiered decisioning where a fast rules-based first tier clears low-risk transactions in single-digit milliseconds, and run sanctions, fraud, and balance checks in parallel with pre-agreed fallback behavior for a slow dependency. ISO 20022's structured purpose codes give these models more signal than legacy formats did, which is why several institutions treat the migration and the fraud model rebuild as one coordinated project.

Integration Architecture for Banks and Payment Processors

A recurring mistake is treating the payments hub as a thin pass-through that writes directly to the core ledger on the critical path, coupling the entire payment's latency to the core's own response time. A pattern that holds up better puts a dedicated real-time payments hub in front of the core, handling FedNow/RTP connectivity, ISO 20022 parsing and validation, fraud and sanctions checks, and provisional ledger entries in its own fast data store, then reconciling to the core asynchronously shortly after confirmation. An event-driven API layer exposes payment initiation, status inquiry, and notification services to channel systems — mobile banking, treasury workstations, merchant-facing processor APIs — decoupling those channels from the specifics of the FedNow or RTP protocol, while a separate exception queue handles cases that don't clear automatically. Processors serving multiple bank partners typically need a multi-tenant configuration layer that lets fraud thresholds and liquidity policies vary per partner without forking the integration code.

Operational Resilience in a 24x7x365 System

A system with no overnight maintenance window changes how resilience gets engineered. Deployments and failovers that once happened safely in a low-traffic overnight window now have to happen live, without a customer-visible outage. This generally pushes real-time payments infrastructure toward active-active deployment across regions, canary releases, and circuit breakers on every external dependency — fraud services, sanctions screening, the network connection itself — so one slow dependency degrades gracefully instead of taking down the payment path. Monitoring shifts from end-of-day reports to real-time observability, since a five-minute detection delay is a real incident on these rails, not a blip caught in tomorrow's batch report.

Governance and Rollout Strategy

Given the irrevocability of settled instant payments, testing strategy deserves as much attention as the runtime system itself. We typically recommend a phased rollout: receive-only capability first, then low-value or internal-account send testing, then a limited external send pilot with tight limits before full production. Each phase should exercise ISO 20022 mapping, fraud screening, and settlement reconciliation end to end, and a conformance suite should validate generated messages against the scheme's published schemas before they reach the network, since both FedNow and RTP reject malformed messages and a rejected instant payment is a customer-facing failure in a way a rejected batch file typically isn't.

Real-time payments infrastructure sits at the intersection of message format engineering, settlement mechanics, and split-second risk decisioning, and none of the three can be a bolt-on to existing systems. Institutions that get this right start with a canonical ISO 20022-aligned data model, build a decoupled payments hub rather than wiring straight into the core, and invest early in the fraud and liquidity architecture a 24x7x365, irrevocable payment rail demands. If your team is evaluating a FedNow or RTP integration, or working through an ISO 20022 migration for SWIFT CBPR+, our engineering team can walk through the architecture options against your specific core banking stack — you can get in touch with Halkwinds to start that conversation.

Frequently Asked Questions

Do we have to migrate to ISO 20022 if we only participate in FedNow or RTP and don't use SWIFT?

Yes. ISO 20022 is the native messaging format for both rails, so any institution connecting to either is working in ISO 20022 regardless of SWIFT usage. The CBPR+ migration is a separate, parallel driver for institutions also processing cross-border wires, not a prerequisite for domestic instant payments.

Can a fraudulent real-time payment be reversed after settlement?

Generally, no. Once a FedNow or RTP payment settles, it is final and irrevocable in a way a card chargeback or ACH return is not. Recovery depends on cooperation between the sending and receiving institutions, since there is no scheme-level clawback. That is exactly why pre-settlement fraud screening carries so much architectural weight.

How long does message format migration to ISO 20022 typically take for a mid-size bank?

It varies with the number of legacy formats in play, but in our experience the semantic mapping and testing phases, not the initial syntactic conversion, consume the most calendar time. Institutions that start with a clear canonical data model and a conformance test plan generally move faster.

Do we need a completely new core banking platform to support real-time payments?

Not necessarily. Most institutions we work with keep their existing core and add a dedicated real-time payments hub in front of it, reconciling asynchronously rather than posting synchronously on the critical path. This is usually faster and lower-risk than a full core replacement.

What's the biggest architectural mistake you see in real-time payments projects?

Underestimating the fraud screening latency budget. Teams commonly design a fraud process built for card-not-present or ACH timeframes and discover during testing that it doesn't fit inside a sub-second transaction. Fraud architecture needs to be designed alongside the payments hub from day one, not retrofitted afterward.