Understanding RTGS: Technical Architecture for IT Professionals

RTGS powers trillions in daily high-value payments with instant, irrevocable settlement. For IT professionals, the technical architecture behind these systems offers lessons in high availability, strong consistency, and real-time processing at scale. Here’s the technical breakdown: system components, message standards, performance requirements, and concepts you can apply to your own distributed systems.

1 Deconstructing RTGS: Three Words, Entire Financial Infrastructure

Let me tell you a story about three words that keep the global financial system from collapsing. RTGS — Real-Time Gross Settlement. Sounds like enterprise software jargon, right? But each of these three words represents a fundamental design decision that took humanity centuries to figure out. And as an IT professional, understanding these concepts will make you see distributed systems, databases, and transaction processing in a whole new light. Let’s break it down, one concept at a time.

1.1 Real-Time: The “Right Now” Problem

B1 — Immediate Processing Imagine you’re building a distributed system. User A clicks “Send $1 million to User B.” What happens next? In most systems you’ve built, the answer is: “We’ll process it soon™.”

• Your credit card transaction? Authorized now, settled in 2-3 days.
• Your ACH direct deposit? Submitted today, lands in your account tomorrow.
• Your wire transfer? “Same-day” means “within 24 hours.” RTGS says: No. Right. Now. When a payment hits the RTGS system, it doesn’t go into a batch queue. It doesn’t wait for a nightly job. It doesn’t sit in a “pending” state until someone’s cron job wakes up at 2 AM. The system validates it, checks liquidity, and settles it immediately — typically in 100-500 milliseconds.

IT Analogy: Think of the difference between:

• Batch processing (like nightly ETL jobs, ACH files)
• Stream processing (like Kafka Streams, Flink, real-time analytics)

RTGS is the ultimate stream processor. Every payment is an event that must be processed the moment it arrives.

B2 — No Waiting Period Here’s where it gets interesting from a system design perspective. In the old days (pre-RTGS, before the 1990s), banks would send payment instructions throughout the day, but nothing actually settled until end-of-day. The clearing house would net everything out, and banks would exchange the differences. This created what we call Herstatt Risk (named after a German bank that failed in 1974):

Timeline of a Herstatt-style disaster:
09:00 — Bank A sends $100M to Bank B (via netting system)
10:00 — Bank B sends $80M to Bank A (via netting system)
14:00 — Bank A goes bankrupt
15:00 — Bank B has already sent $80M but won't receive $100M
17:00 — End-of-day netting: Bank B was supposed to receive net $20M
Result: Bank B lost $80M, Bank A's creditors keep the $100M

RTGS eliminates this by saying: Every payment settles when it’s sent. No waiting. No “I’ll pay you later.”

IT Analogy: This is like the difference between:

• Eventual consistency (DynamoDB, Cassandra — “it’ll sync up eventually”)
• Strong consistency (traditional RDBMS with ACID — “it’s consistent NOW or it fails”)

RTGS chose strong consistency. The financial system couldn’t handle “eventual.”

B3 — Continuous Operation RTGS systems don’t process payments in batches. They don’t have “processing windows.” They run continuously during operating hours (often 18-24 hours/day for modern systems). Think about what this means architecturally:

IT Analogy: This is the difference between:

• Scheduled jobs (nightly backups, batch reports)
• Always-on services (API gateways, streaming platforms, real-time databases)

RTGS is an always-on, mission-critical service. When it goes down, trillions in transactions stall. Banks can’t move money. Markets freeze. This is why availability requirements are 99.99%+ during operating hours.

1.2 Gross: The “One by One” Problem

C1 — Individual Transaction Here’s where RTGS gets expensive (and why banks complained when it was introduced). Gross means: Each transaction is settled individually, on its own merits, without reference to any other transaction. Let me show you what this means with an example:

Three banks, three payments:
Bank A → Bank B: $100 million
Bank B → Bank C: $80 million
Bank C → Bank A: $90 million
NET SETTLEMENT (old way):
- Bank A: -$100 + $90 = -$10 million (pays $10M)
- Bank B: +$100 - $80 = +$20 million (receives $20M)
- Bank C: +$80 - $90 = -$10 million (pays $10M)
- Total money that actually moves: $20 million
RTGS GROSS SETTLEMENT (new way):
- Bank A → Bank B: $100 million (settles immediately)
- Bank B → Bank C: $80 million (settles immediately)
- Bank C → Bank A: $90 million (settles immediately)
- Total money that actually moves: $270 million

See the difference? In net settlement, the system only moves the net difference ($20M). In RTGS, it moves the full gross amount of each transaction ($270M).

IT Analogy: This is like the difference between:

• Delta sync (only send changed data)
• Full sync (send complete data every time)

RTGS does full sync. Every. Single. Time.

C2 — No Netting This is the controversial part. Before RTGS, banks could net payments against each other. If Bank A owed Bank B $100M, and Bank B owed Bank A $95M, they’d just settle the $5M difference. RTGS says: Nope. Pay the full $100M. Then get your $95M separately. Why would anyone design a system this way? Answer: Because netting introduces credit risk. In the netting example above, what if Bank A pays its $100M, but then Bank B fails before paying its $95M? Bank A just lost $95M. This happened. A lot. In 1974, Bankhaus Herstatt failed after receiving payments but before sending its outgoing payments. Counterparties lost hundreds of millions. The risk became known as Herstatt Risk or settlement risk. RTGS eliminates this by making every payment final and independent. No “I’ll pay you later.” No netting. No credit exposure between banks.

IT Analogy: This is like the difference between:

• Two-phase commit with rollback (if one part fails, everything rolls back)
• Saga pattern with compensating transactions (each step is independent, failures require explicit compensation)

RTGS chose: Each transaction stands alone. No rollbacks. No “oops, never mind.”

C3 — Full Amount Settled This is where liquidity becomes a problem. Remember the example above? Bank A needs to have $100 million available right now to send that payment. It can’t say “Well, I’m receiving $95M from Bank B in 10 minutes, so I only need $5M.” RTGS says: Show me the money. Now. This is why RTGS systems require banks to maintain large intraday liquidity balances. You need enough cash on hand to cover your outgoing payments before incoming payments arrive.

IT Analogy: This is like the difference between:

• Connection pooling (reuse resources, efficient but complex)
• Fresh connection per request (simple, safe, but resource-intensive)

RTGS chose “fresh connection per request.” Every payment must be fully funded. No recycling. No “I’ll use the incoming payment to fund the outgoing one.”

1.3 Settlement: The “It’s Done” Problem

D1 — Final Transfer When an RTGS payment settles, it’s final. Not “pending.” Not “subject to review.” Done. This matters because in banking, there’s a difference between:

• Payment instruction (“Please pay $1M to Vendor X”)
• Settlement (“$1M has moved from your account to Vendor X’s account”) In consumer banking, you can send a payment instruction and it might take days to settle. In RTGS, the instruction and settlement are the same event.

IT Analogy: This is like the difference between:

• Optimistic locking (“I think this will work, let me try”)
• Pessimistic locking (“I have the lock, the resource is mine”)

RTGS uses pessimistic locking. When a payment settles, the money is gone from the sender and arrived at the receiver. No take-backs.

D2 — Irrevocable Once an RTGS payment settles, it cannot be reversed. Not by the sender. Not by the receiving bank. Not even by the central bank (except in extraordinary circumstances like court orders or proven fraud). This is both a feature and a bug:

IT Analogy: This is like the difference between:

• Soft delete (mark as deleted, can be restored)
• Hard delete (gone forever, no undo)

RTGS payments are hard deletes. Once committed, they’re immutable. This is why RTGS systems have extensive validation, compliance checks, and confirmation steps before settlement.

D3 — Unconditional This is the subtlest but most important point. An RTGS settlement is not conditional on anything else. It doesn’t matter if:

• The sender changes their mind
• The underlying transaction is disputed
• There’s a legal dispute between the parties
• The sender goes bankrupt 5 minutes later The settlement happened. It’s unconditional. This is what makes RTGS systemically safe. When a bank receives an RTGS payment, it knows that money is theirs, full stop. They can lend it, invest it, send it elsewhere. No risk that it’ll be clawed back.

IT Analogy: This is like the difference between:

• Conditional commit (“I’ll commit if X, Y, Z all succeed”)
• Unconditional commit (“I’ve committed, it’s done”)

RTGS is unconditional commit. The transaction log is written. The ledger is updated. The money has moved. End of story.

1.4 Putting It All Together: Why This Matters for IT

Let me connect this back to your world as an IT professional.

2 RTGS in the Payment System Ecosystem

2.1 Payment System Hierarchy

2.2 Transaction Flow in RTGS

Complete Transaction Lifecycle:

• Note: The flowchart below illustrates a proposed conceptual transaction flow in an RTGS system. The specific steps, validation points, and queuing logic can vary based on the RTGS system’s design.

2.3 Participants in RTGS Systems

3 Technical Architecture Overview

Now that we’ve covered the why and how RTGS works at a business level, here’s the technical plumbing most of us end up integrating with or monitoring.

3.1 High-Level System Components

• Note: The diagram below presents a proposed high-level system component architecture for RTGS. The specific components, their responsibilities, and the layering can vary based on the system’s design and technological choices.

Layer Breakdown:

3.2 Core Technical Requirements

3.3 Message Standards

RTGS systems use standardized message formats for interoperability:

4 Real-World RTGS Systems

4.1 Major RTGS Systems Worldwide

4.2 System Comparison

4.3 Architecture Patterns by System

Different systems make different architectural choices:

5 Why IT Professionals Should Understand RTGS

5.1 Career Relevance

5.2 Transferable Concepts

RTGS principles apply to many IT domains beyond finance:

Specific Transferable Patterns:

6 Summary

Footnotes for this article:

Note: For a complete list of all acronyms used in the RTGS series, see the RTGS Acronyms and Abbreviations Reference.