Real-Time Payment Rails & Settlement Infrastructure

The US payment system has operated on batch-processing infrastructure designed in the 1970s. ACH (Automated Clearing House) processes transactions in windows—typically four settlement windows per business day—with final settlement occurring 1-2 business days after initiation. Wire transfers via Fedwire provide same-day settlement but at $25+ per transaction and only during Federal Reserve operating hours. This batch-and-delay paradigm creates float (funds in transit that neither party can use), necessitates provisional credit risk management, and prevents real-time payment experiences that consumers and businesses increasingly expect.

The launch of FedNow (July 2023) and the maturation of The Clearing House's RTP network create the infrastructure for instant payments, but integration is technically demanding. Both networks require ISO 20022 message formatting—a structured XML schema that is fundamentally different from the fixed-width NACHA file formats and free-text Fedwire messages that existing payment systems were built to generate. ISO 20022 messages carry rich structured data (purpose codes, remittance information, creditor references) that legacy systems cannot populate without significant transformation logic. Additionally, real-time payments operate 24/7/365 with irrevocable settlement, requiring payment systems to maintain continuous availability and implement pre-validation controls that prevent erroneous payments from being sent on a network with no recall mechanism.

Cross-border payments add another layer of complexity. SWIFT gpi has improved international payment transparency with end-to-end tracking and the gpi Tracker, but the underlying correspondent banking model still introduces delays, deductions, and currency conversion at multiple hops. Emerging alternatives—SWIFT Go for low-value cross-border payments, central bank bilateral linkages, and stablecoin settlement rails—each require different integration approaches, message formats, and compliance workflows. A modern payment platform must orchestrate across these heterogeneous networks while presenting a unified interface to upstream applications.

The platform is built as an event-driven microservices architecture on Kubernetes, with Apache Kafka as the central nervous system connecting payment initiation, validation, routing, submission, and reconciliation services. Each payment enters through a unified REST/gRPC API that accepts a common payment instruction model. The ingestion service validates the instruction against schema rules, enriches it with routing data (receiving institution's FedNow/RTP participation status, cut-off times, amount limits), and publishes it to the payment processing topic. Downstream services subscribe to this topic and execute their responsibilities independently: the ISO 20022 transformer converts the internal model to the target network's message format (pacs.008 for credit transfers, pacs.028 for status inquiries, pain.013 for request-to-pay), the compliance screening service performs OFAC sanctions checks and fraud scoring, and the routing engine selects the optimal rail based on speed, cost, and receiver capability.

The FedNow integration implements the full FedNow Service message set over the Federal Reserve's secure FedLine network. Credit transfers use the pacs.008.001.08 message with all mandatory fields populated from the internal payment model and optional structured remittance data (invoice numbers, purchase order references) when available from the originating application. The platform handles the real-time positive acknowledgment flow: submission, receipt of the pacs.002 status message confirming acceptance or rejection by the receiving participant, and final settlement notification. For RTP, the integration supports both credit transfers (immediate settlement) and Request for Payment (RfP) workflows where a payee initiates a payment request that the payer approves from their banking application. The routing engine maintains a real-time directory of FedNow and RTP participant institutions, updated via the respective networks' directory services, and falls back to same-day ACH when the receiving institution does not participate in real-time networks.

The reconciliation engine provides continuous, transaction-level reconciliation between the platform's internal ledger and the settlement confirmations received from each payment network. For FedNow and RTP, settlement is immediate and irrevocable, so reconciliation is transaction-by-transaction in real time. For ACH, the engine matches outbound files against return files (R01-R85 return reason codes) and NOC (Notification of Change) files, automatically applying corrections and re-routing returned payments. Cross-border payments through SWIFT gpi are tracked using the UETR (Unique End-to-End Transaction Reference) with automated status polling via the gpi Tracker API, enabling the platform to provide real-time payment status to originators even as the payment traverses multiple correspondent banks.

The ISO 20022 message transformation engine is built on a canonical data model that maps the internal payment instruction to every target message format. The engine uses JAXB-generated Java classes from the official ISO 20022 XML schemas (maintained by SWIFT and published as the ISO 20022 message repository) to ensure strict schema compliance. For FedNow, the pacs.008.001.08 message requires specific Federal Reserve extensions: the FedNow-specific business application header (head.001), clearing system member identification using ABA routing numbers in the USABA clearing system ID scheme, and settlement method CLRG (clearing system settlement). The engine validates each outbound message against the FedNow ISO 20022 schema package and the FedNow validation rules document (over 200 business rules covering field presence, format, cross-field consistency, and value domain). Messages failing validation are rejected with structured error codes before submission, preventing costly network-level rejections.

The routing engine implements a decision matrix that evaluates each payment against the capabilities and constraints of available rails. FedNow supports credit transfers up to $500,000 (initial limit, configurable per participant) with 20-second end-to-end SLA; RTP supports up to $1,000,000 with 15-second SLA; same-day ACH supports up to $1,000,000 with same-day settlement in one of three daily windows; standard ACH settles next business day with no per-transaction limit; Fedwire supports unlimited amounts with same-day settlement during Fed operating hours. The router scores each eligible rail on a weighted function of: settlement speed (weight 0.4), transaction cost (weight 0.3), receiver confirmed participation (weight 0.2), and current network health/latency (weight 0.1). The receiver participation lookup queries a Postgres-backed directory that is synchronized every 15 minutes with the FedNow participant directory (via FedLine download) and the RTP participant directory (via TCH API). For cross-border payments, the router evaluates SWIFT gpi correspondent chains using BIC routing tables and estimated fee deductions, comparing total landed cost against alternative rails where available.

High availability is achieved through active-active deployment across three AWS availability zones with Kafka MirrorMaker 2 replicating the event log across regions for disaster recovery. The FedLine connection (required for FedNow access) terminates on dedicated HSM-backed infrastructure in a FedLine-certified environment, with automatic failover to a secondary FedLine endpoint. Payment processing achieves exactly-once semantics through idempotency keys at the API layer and Kafka transactional producers that atomically write to the processing topic and the idempotency store. Circuit breakers (Resilience4j) isolate failures in individual rail connectors: if the FedNow submission endpoint becomes unresponsive, the circuit opens and the router redirects eligible payments to RTP or same-day ACH without upstream callers experiencing errors. SLA monitoring tracks end-to-end latency (API receipt to network acknowledgment) at the P50, P95, and P99 levels, alerting operations when latency exceeds thresholds and automatically throttling submission rates to prevent network congestion during periods of degraded performance.