Real-Time Payment Systems

Prerequisite: Payment Rails

Your platform launches in Brazil. Pix settles in 1.5 seconds. You launch in the US. RTP settles in under 5 seconds but your bank is not a participant — so your “instant” payment falls back to ACH and arrives tomorrow. You expand to the EU. SEPA Instant has a 10-second SLA, but only 60% of eurozone PSPs are reachable, and your recipient’s bank is not one of them. Three markets, three instant payment schemes, three different architectures, three sets of assumptions about what “real-time” means.

The engineering challenge is not “how do I send a fast payment.” It is how you build a platform that routes across schemes with different settlement models, addressing formats, transaction limits, and failure semantics — and makes the right choice for each payment without the sender knowing which rail carried it.

Settlement Architecture: RTGS vs DNS

Every payment scheme settles through one of two models. The choice between them determines latency, liquidity requirements, and counterparty risk.

Real-time gross settlement (RTGS) settles each payment individually, the moment it clears. The sending bank’s reserve account at the central bank is debited and the receiving bank’s reserve account is credited in real time. No netting, no batching, no delay. The payment is final the moment the central bank processes the instruction. The cost: every payment requires the sending bank to have sufficient reserves at the moment of settlement. A bank processing $500M in outbound payments per day must hold $500M in reserve, not the net position after inbound payments offset outbound.

Deferred net settlement (DNS) accumulates payments over a settlement window — typically 15 minutes to 24 hours — then calculates each bank’s net position and settles the difference. A bank that sent $500M and received $480M settles $20M. The capital efficiency is dramatic. The risk: if a participant fails between clearing and settlement, every payment in the batch is in question.

Model Settlement timing Liquidity requirement Counterparty risk Finality
RTGS Immediate, per payment Gross (full amount) None after settlement Immediate
DNS Deferred, net position Net (offset amount) Present until settlement At settlement window close

Modern instant payment schemes use a hybrid. Pix, UPI, and RTP clear in real time — the recipient sees the funds immediately — but settle in batches on a short cycle. The scheme operator or central bank guarantees the payment during the gap between clearing and settlement. The participant’s clearing obligation is backed by pre-funded reserves or collateral.

See Payment Rails. The handbook covers the spectrum from batch ACH to real-time rails. This chapter goes deeper into the architecture of each instant scheme and the engineering decisions that shaped them.

RTP: The Clearing House (United States)

RTP is the first new US payment rail in 40 years, operated by The Clearing House — a consortium of 25 large US banks. It launched in 2017 and processes credit-push payments 24/7/365 with a $1M per-transaction limit.

The architecture is credit-push only. The sender initiates every payment. There is no debit capability — you cannot pull funds from another account the way ACH debit does. This eliminates an entire class of fraud (unauthorized debits) at the cost of requiring the sender to always initiate.

The message flow follows ISO 20022:

  1. pacs.008 — the sending bank submits a credit transfer to the RTP network
  2. RTP validates the message, checks the sender’s prefunded balance, and routes to the receiving bank
  3. The receiving bank has 8 seconds to accept or reject
  4. pacs.002 — the receiving bank sends a status response (accepted, rejected, or pending)
  5. On acceptance, RTP debits the sender’s prefunded account and credits the receiver’s. Settlement is final.
<!-- Simplified ISO 20022 pacs.008 credit transfer -->
<FIToFICstmrCdtTrf>
  <GrpHdr>
    <MsgId>RTPUS-20261009-001</MsgId>
    <CreDtTm>2026-10-09T14:30:00Z</CreDtTm>
    <NbOfTxs>1</NbOfTxs>
    <SttlmInf>
      <SttlmMtd>CLRG</SttlmMtd>
    </SttlmInf>
  </GrpHdr>
  <CdtTrfTxInf>
    <PmtId><EndToEndId>E2E-REF-12345</EndToEndId></PmtId>
    <IntrBkSttlmAmt Ccy="USD">1500.00</IntrBkSttlmAmt>
    <DbtrAgt><FinInstnId><ClrSysMmbId><MmbId>021000021</MmbId></ClrSysMmbId></FinInstnId></DbtrAgt>
    <CdtrAgt><FinInstnId><ClrSysMmbId><MmbId>021000089</MmbId></ClrSysMmbId></FinInstnId></CdtrAgt>
  </CdtTrfTxInf>
</FIToFICstmrCdtTrf>

RTP also supports Request for Payment (RfP) — a payee sends a structured request to the payer, who can approve or decline. This enables invoice-style flows without debit authorization risk. The payer always controls the push.

The prefunding model means each participant maintains a balance with The Clearing House. Payments debit this balance in real time. If the balance hits zero, the participant cannot send. Banks manage their prefunded position through Fedwire top-ups, creating a dependency on the Federal Reserve’s operating hours for balance replenishment — one of the few non-24/7 constraints in a 24/7 system.

Pix: Banco Central do Brasil

Pix launched in November 2020 and reached 150 million registered users within two years — the fastest adoption of any payment scheme in history. By 2024, Pix processes over 4 billion transactions per month with an average settlement time of 1.5 seconds.

The central architectural decision: QR codes as the universal payment initiation method. Every Pix payment can be initiated by scanning a QR code — static (merchant-generated, reusable) or dynamic (single-use, pre-filled amount). This eliminated the need for the payer to know the recipient’s bank details. A street vendor, an e-commerce checkout, and a P2P transfer all use the same initiation mechanism.

Addressing uses “Pix keys” — aliases that map to a bank account. A user registers their CPF (national ID number), phone number, email address, or a random UUID as a key. The payer sends to the key; the central bank’s DICT (Directory of Transaction Identifiers) resolves it to the receiving institution and account in real time.

Key type Format Uniqueness Use case
CPF/CNPJ National ID One per person/company P2P, invoicing
Phone +55 mobile number One per number P2P
Email email@domain One per address E-commerce
EVP Random UUID Unlimited Privacy-preserving, temporary

Settlement uses a hybrid model. Clearing is instant — the recipient’s PSP credits the account within 1.5 seconds of initiation. Settlement between PSPs happens through the STR (Sistema de Transferência de Reservas), Brazil’s RTGS system, in cycles throughout the day. BCB guarantees the payment during the gap.

The mandatory participation rule is what drove adoption. BCB required every financial institution with more than 500,000 active accounts to offer Pix. This gave the scheme near-universal reachability from day one — a problem that RTP and SEPA Instant still face.

UPI: National Payments Corporation of India

UPI processes over 10 billion transactions per month — more than any other instant payment scheme globally. The architecture handles this scale through a federated model where NPCI operates the central switch and payment service providers (PSPs) handle the customer-facing layer.

The addressing innovation is the Virtual Payment Address (VPA): username@bankhandle. A user with HDFC Bank might have the VPA name@hdfcbank. The VPA decouples payment identity from account numbers. Users can change banks without changing their payment address — the VPA remaps to the new account.

The transaction flow for a UPI payment:

  1. Payer enters the payee’s VPA in their PSP app
  2. PSP sends a collect/pay request to NPCI’s UPI switch
  3. NPCI resolves the VPA to the payee’s PSP and bank
  4. The payee’s bank validates the account
  5. The payer authenticates (UPI PIN — a 4-6 digit code, not biometric)
  6. NPCI debits the payer’s bank and credits the payee’s bank
  7. Both parties receive confirmation

The entire flow completes in under 3 seconds. Settlement between banks happens in batches through RBI’s RTGS system, with net settlement cycles every 2 hours during the day.

UPI’s scale comes from three design choices. First, the two-tier PSP model: banks provide the account infrastructure, but third-party apps (Google Pay, PhonePe, Paytm) handle the user experience. This separated innovation speed from banking infrastructure speed. Second, the interoperability mandate: every PSP must accept payments from every other PSP. Third, the zero-MDR policy for person-to-merchant payments: merchants pay nothing to accept UPI, removing the adoption barrier that card interchange creates.

UPI’s zero-MDR model means the PSP ecosystem is subsidized — either by the government directly or by PSPs absorbing costs to acquire users. This model drives volume but creates sustainability questions for PSPs operating on zero transaction revenue.

SEPA Instant: European Payments Council

SEPA Instant Credit Transfer (SCT Inst) enables euro-denominated instant payments across 36 countries in the Single Euro Payments Area. The SLA is 10 seconds end-to-end, with most payments completing in under 5.

The scheme uses ISO 20022 messaging and settles through the ECB’s TARGET Instant Payment Settlement (TIPS) system or through EBA Clearing’s RT1 platform. TIPS is RTGS — each payment settles individually in central bank money. RT1 is a private-sector alternative with DNS in short cycles.

Settlement system Operator Model Settlement asset
TIPS ECB RTGS Central bank money
RT1 EBA Clearing DNS (short cycle) Commercial bank money

The reachability problem is SEPA Instant’s defining constraint. Unlike Pix (mandatory participation) or UPI (government-mandated interoperability), SEPA Instant adoption was voluntary until 2025. The EU’s Instant Payments Regulation now mandates that all PSPs offering SEPA Credit Transfers must also offer SCT Inst by 2025-2026, with full send-and-receive capability. Before the mandate, roughly 60% of eurozone PSPs supported instant payments. A platform sending an instant payment to a non-participating PSP had to fall back to standard SCT — which settles in up to one business day.

The transaction limit was originally €15,000, raised to €100,000 in 2020. The regulation removes the limit entirely for standard SEPA Credit Transfers, though individual PSPs may apply lower limits based on risk assessment.

Cross-border within SEPA adds a routing dimension. A payment from a French bank to an Estonian bank must traverse the scheme’s clearing infrastructure. Both banks must be reachable through the same CSM (Clearing and Settlement Mechanism) — either TIPS or RT1. If the French bank uses TIPS and the Estonian bank uses RT1, the payment must cross between systems, adding latency and operational complexity.

Scheme Comparison

Dimension RTP (US) Pix (Brazil) UPI (India) SEPA Instant (EU)
Launched 2017 2020 2016 2017
Monthly volume ~30M txns 4B+ txns 10B+ txns ~250M txns
Settlement time < 5 seconds ~1.5 seconds < 3 seconds < 10 seconds (SLA)
Transaction limit $1,000,000 BRL 500K (~$100K) ₹500K (~$6,000) €100,000
Addressing Account number / routing Pix keys (CPF, phone, email, UUID) VPA (user@bank) IBAN
Initiation Credit push only QR code, key, manual VPA, QR code, NFC Credit push (IBAN)
Settlement model Prefunded balance Hybrid (instant clear, batched settle) Hybrid (instant clear, 2h net settle) RTGS (TIPS) or DNS (RT1)
Participation Voluntary Mandatory (>500K accounts) Voluntary (effectively universal) Mandatory (from 2025)
Operator The Clearing House (private) Banco Central do Brasil NPCI (non-profit) EPC/ECB

Multi-Scheme Routing

A platform operating across geographies needs a routing layer that selects the optimal scheme for each payment based on the sender’s location, recipient’s location, currency, amount, and urgency.

The routing decision tree for a cross-geography platform:

payment_request(sender, recipient, amount, currency, urgency)
  → resolve sender jurisdiction
  → resolve recipient jurisdiction
  → if same jurisdiction:
      → select domestic instant scheme (Pix, UPI, RTP, SEPA Inst)
      → check recipient reachability on scheme
      → if reachable: route to scheme
      → if not reachable: fall back to domestic batch rail
  → if cross-border:
      → check if both jurisdictions share a scheme (SEPA)
      → if shared scheme: route to scheme
      → if not: select cross-border rail (SWIFT, correspondent, stablecoin)
      → apply FX if currency mismatch

The reachability check is the critical step. Knowing that RTP exists in the US does not mean the recipient’s bank participates. Maintaining a live directory of participant institutions per scheme — and keeping it current as banks join and leave — is operational overhead that compounds with each scheme you support.

Timeout handling differs across schemes. RTP gives the receiving bank 8 seconds to respond. Pix times out in 10 seconds. UPI has a 30-second window. SEPA Instant’s 10-second SLA is end-to-end. Your orchestration layer must handle scheme-specific timeouts and translate them into a consistent status model for the caller: pending, completed, failed, or timed-out.

The ISO 20022 Convergence

Every scheme described above uses or is migrating to ISO 20022 messaging. SWIFT’s cross-border messaging completed the MT-to-MX migration in 2025. RTP launched natively on ISO 20022. Pix and UPI use ISO 20022-derived message formats. SEPA Instant uses ISO 20022 exclusively.

The practical implication for engineers: a payment message from any modern scheme contains structured data in the same semantic model. A pacs.008 credit transfer carries the same fields whether it flows through RTP, SEPA Instant, or SWIFT gpi. The XML schemas differ in required fields, local extensions, and character set rules — but the data model is shared.

This convergence enables a single internal representation for payments regardless of the originating scheme. Your platform can normalize inbound messages from any ISO 20022 scheme into a canonical payment object, route through your ledger and compliance checks, and serialize back to the destination scheme’s format. The mapping is mechanical, not interpretive — field A in scheme X corresponds to field A in scheme Y because both derive from the same ISO 20022 message definition.

The fields that vary are the extensions. UPI adds VPA resolution. Pix adds QR code payloads. SEPA Instant adds IBAN validation. These scheme-specific extensions live outside the core message and are handled by scheme-specific adapters in your orchestration layer, not in the canonical payment model.