Skip to main content

Off-Us Transaction Architecture β€” Clearing, Settlement & Rails

An Off-Us Transaction is a payment where the payer (debtor) and the recipient (creditor) hold accounts at different financial institutions. Because funds must traverse organizational and sovereign boundaries, the transaction cannot be settled via a simple internal database write.

Off-Us payments require standardized messaging rails, multi-stage clearing pipelines, central bank liquidity reserves, and legal settlement frameworks. Understanding Off-Us architecture requires mastering the 4-Corner Model, the critical separation between Clearing and Settlement, and the trade-offs between Deferred Net Settlement (DNS) and Real-Time Gross Settlement (RTGS).


1. The 4-Corner Payment Model

All modern interbank payment systemsβ€”including retail wire transfers, automated clearing houses (ACH), instant payments (FedNow, SEPA Instant, NPP), and credit card schemesβ€”are structured around the 4-Corner Model:

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ THE 4-CORNER PAYMENT MODEL β”‚
β”‚ β”‚
β”‚ CORNER 1: PAYER (DEBTOR) CORNER 4: PAYEE (CREDITOR) β”‚
β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚
β”‚ β”‚ Alice (Buyer) β”‚ β”‚ Bob (Merchant/Seller) β”‚ β”‚
β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–²β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚
β”‚ β”‚ 1. Initiates Transfer β”‚ 6. Account β”‚
β”‚ β”‚ (pain.001 / Card Tap) β”‚ Credited β”‚
β”‚ β–Ό β”‚ (camt.054) β”‚
β”‚ CORNER 2: DEBTOR BANK (ISSUER) CORNER 3: CREDITOR BANK β”‚
β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚
β”‚ β”‚ Debtor Bank β”‚ β”‚ Creditor Bank β”‚ β”‚
β”‚ β”‚ (Alice's Bank) β”‚ β”‚ (Bob's Bank) β”‚ β”‚
β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–²β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚
β”‚ β”‚ β”‚ β”‚
β”‚ β”‚ 2. Validates & Debits Alice β”‚ 5. Credits Bob β”‚
β”‚ β”‚ 3. Dispatches Interbank Msg (pacs.008) β”‚ Post-Settlemβ”‚
β”‚ β–Ό β”‚ β”‚
β”‚ ─────────────────────────────────────────────────────────────────────────────────── β”‚
β”‚ CLEARING & SETTLEMENT NETWORK (INTERMEDIARY) β”‚
β”‚ (Central Bank RTGS / ACH / SWIFT / VisaNet) β”‚
β”‚ β”‚
β”‚ 4. Interbank Settlement across Central Bank Reserves β”‚
β”‚ DR Debtor Bank Reserve Account -$10,000 β”‚
β”‚ CR Creditor Bank Reserve Account +$10,000 β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

2. Fundamental Separation: Clearing vs. Settlement

A core tenet of payment systems engineering is that Clearing and Settlement are distinct processes that often execute at completely different times:

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ CLEARING VS. SETTLEMENT DECOUPLING β”‚
β”‚ β”‚
β”‚ CLEARING (The Exchange of Information & Obligations) β”‚
β”‚ ──────────────────────────────────────────────────── β”‚
β”‚ β€’ Message transmission, syntactic validation, and counterparty routing. β”‚
β”‚ β€’ Computation of net obligations: Bank A owes Bank B $5M; Bank B owes Bank A $3M. β”‚
β”‚ β€’ Result: Calculation of net balance owed ($2M). NO CENTRAL BANK MONEY MOVES YET. β”‚
β”‚ β”‚
β”‚ SETTLEMENT (The Unconditional Discharge of the Obligation) β”‚
β”‚ ────────────────────────────────────────────────────────── β”‚
β”‚ β€’ Irrevocable transfer of central bank reserves from Bank A to Bank B. β”‚
β”‚ β€’ Governed by central bank legal finality regulations (e.g. Fedwire, TARGET2). β”‚
β”‚ β€’ Once settled, the transaction cannot be unwound or reversed by insolvency. β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Deferred Net Settlement (DNS) vs. Real-Time Gross Settlement (RTGS)

Architectural DimensionDeferred Net Settlement (DNS) (e.g. Traditional ACH, BACS, SEPA Core)Real-Time Gross Settlement (RTGS) (e.g. Fedwire, TARGET2, CHAPS, FedNow)
Settlement FrequencyBatched at fixed cut-off windows (e.g. 1Β toΒ 3Β timesΒ daily1\text{ to }3\text{ times daily})Continuous, transaction-by-transaction in real time
Gross vs. NetNet Multilateral: Millions of payments offset into a single net settlement figureGross: Every single transaction transfers physical reserves individually
Liquidity EfficiencyExtremely High: Banks need minimal intraday cash buffers; incoming cancels outgoingLow: Banks must maintain massive cash reserves at the central bank
Settlement Risk (Herstatt Risk)High: If a participant bank defaults before the net batch settles, the entire batch must unwindZero: Settlement is instantaneous and final upon commit
Throughput & CostMillions of transactions per batch; fractions of a cent per paymentHundreds of transactions per second; higher fees ($0.10 to $15.00)

3. End-to-End Interbank Message Protocol Exchange

In modern ISO 20022 clearing architectures, an Off-Us payment executes through a deterministic multi-message choreography:

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ OFF-US ISO 20022 MESSAGE PROTOCOL CHOREOGRAPHY β”‚
β”‚ β”‚
β”‚ Debtor Debtor Bank Clearing System Creditor Bank β”‚
β”‚ β”‚ β”‚ β”‚ β”‚ β”‚
β”‚ β”‚ 1. pain.001 β”‚ β”‚ β”‚ β”‚
β”‚ │───────────────────>β”‚ β”‚ β”‚ β”‚
β”‚ β”‚ β”‚ 2. Debit Customer β”‚ β”‚ β”‚
β”‚ β”‚ β”‚ 3. pacs.008 β”‚ β”‚ β”‚
β”‚ β”‚ │────────────────────────>β”‚ β”‚ β”‚
β”‚ β”‚ β”‚ β”‚ 4. Liquidity Settlement β”‚ β”‚
β”‚ β”‚ β”‚ β”‚ 5. pacs.008 Dispatched β”‚ β”‚
β”‚ β”‚ β”‚ │────────────────────────>β”‚ β”‚
β”‚ β”‚ β”‚ β”‚ β”‚ 6. Posts β”‚
β”‚ β”‚ β”‚ β”‚ 7. pacs.002 (ACCP) β”‚ Creditβ”‚
β”‚ β”‚ β”‚ β”‚<────────────────────────│ β”‚
β”‚ β”‚ β”‚ 8. pacs.002 (ACCP) β”‚ β”‚ β”‚
β”‚ β”‚ β”‚<────────────────────────│ β”‚ β”‚
β”‚ β”‚ 9. pain.002 (ACCP) β”‚ β”‚ β”‚ β”‚
β”‚ β”‚<───────────────────│ β”‚ β”‚ β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
  1. Initiation (pain.001): Payer initiates a credit transfer. Debtor bank runs sanctions, AML, and balance availability checks.
  2. Debtor Ledger Posting: Debtor bank reserves or hard-debits the customer account, crediting an internal Due-To Central Bank Clearing Suspense Account.
  3. FI-to-FI Instruction (pacs.008): Debtor bank packages transaction details, including EndToEndId and UETR, and dispatches to the central clearing switch.
  4. Central Settlement: Clearing house debits Debtor Bank's reserve balance and credits Creditor Bank's reserve balance.
  5. Creditor Ledger Posting: Creditor bank validates beneficiary account details and posts credit to payee's balance.
  6. Technical Confirmation (pacs.002): Creditor bank returns an acceptance (ACCP) or rejection (RJCT) status report back through the clearing rail.

4. Resilient Gateway Design: The Transactional Outbox Pattern

Communicating with external clearing networks over WAN introduces network partitions, socket timeouts, and remote crash failures.

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ OUTBOX PATTERN FOR OFF-US CLEARING GATEWAYS β”‚
β”‚ β”‚
β”‚ PAYMENT APPLICATION DATABASE DEBEZIUM CDC ENGINE β”‚
β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚
β”‚ β”‚ BEGIN TRANSACTION; β”‚ β”‚ Scans Postgres WAL Log β”‚ β”‚
β”‚ β”‚ 1. UPDATE accounts SET balance = ...; β”‚ ─────> β”‚ Captures new Outbox event β”‚ β”‚
β”‚ β”‚ 2. INSERT INTO payments_outbox β”‚ β”‚ Emits to Kafka: β”‚ β”‚
β”‚ β”‚ (id, pacs008_xml, status='PENDING');β”‚ β”‚ topic: outbox.pacs008 β”‚ β”‚
β”‚ β”‚ COMMIT; β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚
β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”‚
β”‚ β–Ό β”‚
β”‚ CLEARING NETWORK (FEDNOW / SWIFT MQ) CLEARING ADAPTER SERVICE β”‚
β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚
β”‚ β”‚ Remote Network Host Gateway β”‚ <───── β”‚ Consumer Worker Pool β”‚ β”‚
β”‚ β”‚ Enforces Idempotency on EndToEndId β”‚ β”‚ β€’ TLS Mutual Auth / PKI Sign β”‚ β”‚
β”‚ β”‚ Acknowledges with pacs.002 Message β”‚ β”‚ β€’ Circuit Breaker & Retries β”‚ β”‚
β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Critical Gateway Invariants

  1. Guaranteed Exactly-Once Semantics via Clearing Idempotency:
    • Clearing networks reject duplicate requests based on the composite key: RailIdempotencyKey=(SenderBIC,MessageId,EndToEndId)\text{RailIdempotencyKey} = (\text{SenderBIC}, \text{MessageId}, \text{EndToEndId})
    • If an adapter worker times out waiting for an ACK, it must re-send with the exact same EndToEndId and UETR. Generating a new message ID risks executing duplicate interbank settlements.
  2. Nostro / Vostro Liquidity Monitoring:
    • For cross-border wires (SWIFT), banks maintain bilateral Nostro ("our money at your bank") and Vostro ("your money at our bank") accounts.
    • Outbound payment engines must monitor Nostro credit limits in real time; if an account drops below required intraday margins, outbound wires must pause in an authorized liquidity buffer queue.

5. Architectural Comparison Matrix: Payment Rails

Rail / ArchitectureGoverning StandardSettlement MechanismEnd-to-End LatencyOperating WindowTypical Use Case
FedNow / SEPA InstantISO 20022 (pacs.008)Real-Time Gross Settlement (RTGS)<3Β seconds< 3\text{ seconds}24/7/365 continuousInstant consumer & B2B retail transfers
Traditional ACH (NACHA)FedLine / Nacha FlatDeferred Net Settlement (DNS)1Β toΒ 3Β businessΒ days1\text{ to }3\text{ business days}Banking days / Batch cutsPayroll, bill pay, recurring subscriptions
Fedwire / TARGET2ISO 20022 / MT103Real-Time Gross Settlement (RTGS)1Β toΒ 10Β minutes1\text{ to }10\text{ minutes}Central bank operating hoursHigh-value wholesale & institutional settlement
SWIFT CBPR+ (Cross-Border)ISO 20022 / MT103Correspondent Nostro/VostroHours to daysMulti-jurisdiction timezonesInternational cross-border trade & remittances
Visa / MastercardISO 8583 / Single MessageDual-Message (Auth now, DNS settle later)Auth: <1.5s< 1.5\text{s}, Settle: 24h24/7/365Point-of-sale retail & e-commerce payments

πŸ“–
Track Page Progress0 / 635 Read
Knowledge Base Completion0%