## What RTGS Is **RTGS** stands for **Real-Time Gross Settlement**. It is a way for banks to move money between each other **one payment at a time**, with each transfer settled **immediately** in **central bank money**. You can think of it as the banking system’s version of handing over cash and finishing the transaction on the spot—except the parties are banks, and the “cash” is their reserve balances at the central bank. This matters because not all payment systems work that way. Some systems collect many payment obligations and sort them out later through **netting**, which is efficient but leaves a period where payments are still effectively promises. RTGS is designed for situations where speed, certainty, and low settlement risk matter most. **Click the labels** to unpack the three words in the name and see why the combination is powerful. <viz id="0"></viz> **Click each label**—**real-time**, **gross**, and **settlement**—to reveal its meaning. Then **watch the RTGS payment animation** and compare it with the delayed net settlement example. **Notice** that the RTGS payment completes as a single transfer instead of waiting to be bundled with others. The key idea is that RTGS is not just “fast payments.” Its defining feature is that each payment is settled **individually and finally** between banks. That combination reduces the build-up of unsettled obligations that can appear in batch or net systems. In the next slide, you’ll follow one payment from the customer instruction all the way through to the reserve transfer that actually settles it between banks: <ref slide="2">How a Transfer Flows</ref>. ## How a Transfer Flows When you send a high-value payment through your bank, the money does not usually leap directly from your account to the other customer’s account by magic. Instead, there is a chain of updates. In **RTGS**, the crucial step is the transfer of **reserves** between the sending and receiving banks at the **central bank**. A helpful intuition is to separate **customer money** from **interbank settlement**. Your bank can debit your account and the receiving bank can credit its customer, but the payment is truly settled only when Bank A’s settlement balance falls and Bank B’s settlement balance rises. That is the layer where RTGS operates. **Step through the flow** to see which parts are customer-facing and which part creates actual interbank finality. <viz id="1"></viz> **Click Send payment** to advance the transfer. **Watch each stage** in order: the customer instruction, the bank message, the reserve movement at the central bank, and the receiving customer credit. **Observe** which balances change before and after settlement. The most important observation is that the decisive moment is not the message itself—it is the reserve transfer. Messages tell the system what should happen; the settlement entry at the central bank is what actually discharges the obligation between the two banks. That is why RTGS is so closely tied to the central bank. To understand why the central bank is the anchor of the whole system, continue to <ref slide="3">Why Central Banks Matter</ref>. ## Why Central Banks Matter At the center of RTGS is the **central bank**, because that is where commercial banks hold the settlement asset used to pay each other: **reserves**. These reserves are a form of **central bank money**, which is different from deposits that a private bank owes to its customers. Why does that distinction matter? Because the choice of settlement asset affects **trust**, **credit risk**, and **finality**. If banks settled large obligations using only private claims on one another, every participant would have to worry more about whether those claims would still be good under stress. Central bank money is used as the common, system-wide anchor precisely because it is the most trusted settlement asset in the domestic currency. You can think of the central bank as the hub that gives all banks a shared reference point. That does not eliminate every operational problem, but it greatly reduces the risk that settlement itself depends on the health of one private institution. <viz id="2"></viz> **Toggle between** private bank money and central bank money. Then **click** **settlement asset**, **reserves**, and **lender of last resort**. **Notice** how the risk and confidence indicators change when settlement relies on the central bank versus a private claim. The main takeaway is that RTGS is not just a payment messaging channel. It is a settlement arrangement built around a particular asset: central bank reserves. That is what supports strong confidence that a completed payment is truly complete. With that foundation in place, you can now compare RTGS with a different design choice: settling payments one by one versus offsetting them later through netting in <ref slide="4">Gross vs Net Settlement</ref>. ## Gross vs Net Settlement The word **gross** in RTGS means each payment is settled at its full amount, one by one, without first being offset against incoming payments. By contrast, **net settlement** waits, gathers many obligations, and then settles only the **net** amount owed after offsetting flows in both directions. Netting can save liquidity because fewer funds need to move at the end. But that efficiency comes with a tradeoff: before the net settlement happens, obligations can pile up. Those unsettled claims create **exposure** between participants. RTGS avoids that build-up by settling each transfer individually as it arrives, assuming sufficient liquidity is available. A good intuition is to compare two ways of paying back friends after a group trip. In one version, everyone waits until the end and calculates who owes whom overall. In the other, each person settles each expense immediately. The first may use less cash overall; the second leaves less uncertainty along the way. <viz id="3"></viz> **Switch between Gross and Net modes** and **play the timeline**. **Watch** whether payments settle immediately or accumulate first. **Pay attention** to the exposure indicator as obligations build up in net mode and then collapse when the batch settles. This is the core tradeoff: **gross settlement** reduces unsettled exposure, while **net settlement** economizes on liquidity. RTGS chooses immediate, transaction-by-transaction settlement because for high-value and time-critical payments, reducing settlement risk is often more important than minimizing reserve usage. That leads directly to the next question: what exactly do banks gain when a payment becomes final right away? Explore that in <ref slide="5">Why Finality Matters</ref>. ## Why Finality Matters **Settlement finality** means a payment is complete in a way that is not merely provisional. Once settled, the receiving bank does not have to wonder whether the transfer might later fail because of problems elsewhere in the system. In RTGS, finality is one of the biggest benefits. Why is this so important? Because financial systems are networks. If one institution gets into trouble, uncertainty can spread quickly through outstanding obligations. A payment that is only a promise until later netting still carries risk during that waiting period. A payment that has already settled in RTGS is much harder to unwind conceptually: the interbank obligation has already been discharged. You can think of finality as the difference between “I will pay you at the end of the day” and “I have already handed over the money.” During calm periods, those may feel similar. Under stress, they are very different. <viz id="4"></viz> **Advance the timeline** in both scenarios, then **trigger the stress event**. **Compare** what happens to a payment that is still awaiting net settlement versus one that has already settled in RTGS. **Notice** which claims remain exposed and which do not. The insight here is that finality turns a network of promises into completed transfers, shrinking the channels through which distress can spread. That is why RTGS is especially valuable for large-value payments where uncertainty can have system-wide consequences. But this safety comes with an operational demand: banks must have enough reserves at the right time to settle payments individually. That is the liquidity challenge you’ll explore next in <ref slide="6">Liquidity and Queueing</ref>. ## Liquidity and Queueing RTGS lowers settlement risk, but it does not make funding constraints disappear. Because payments settle **one by one**, a bank needs enough **liquidity**—usually reserve balances at the central bank—to send each payment when it is due. If it does not have enough, the payment may have to wait in a **queue**. This creates an important operational problem: even a healthy bank can face timing pressure if many outgoing payments arrive before enough incoming funds do. In other words, RTGS trades some of the liquidity savings of netting for stronger payment finality. Banks therefore manage their reserve balances carefully throughout the day. A useful intuition is to imagine a to-do list with a limited budget. You may be able to complete all tasks eventually, but the order matters if each task consumes scarce resources before more resources arrive. <viz id="5"></viz> **Adjust the reserve balance** with the slider, then **drag payments** to change their order in the queue. **Watch** which payments settle immediately and which must wait. **Try** creating a low-liquidity situation and **observe** when delay or gridlock warnings appear. The big lesson is that RTGS is safest when each payment can settle right away, but that requires active liquidity management. Payment order, incoming funds, and reserve availability all affect whether the system flows smoothly or clogs temporarily. Now that you’ve seen the mechanics and tradeoffs, the final step is to place RTGS in the wider payments landscape: <ref slide="7">Where RTGS Fits</ref>. ## Where RTGS Fits RTGS is only one part of the broader payments ecosystem. Different systems are built for different jobs. **Card payments** emphasize convenience at the point of sale. **ACH** or other **batch systems** are often used for recurring or lower-priority transfers. **Correspondent banking** helps move money across institutions and borders when direct access is limited. **RTGS** is the option designed for **high-value, urgent, and final** interbank settlement. The key is not that RTGS is “better” in every situation. It is better for particular use cases—especially where immediate final settlement in central bank money is worth the higher liquidity demands. A salary batch, a coffee purchase, and a large time-critical interbank transfer do not all need the same settlement design. As you explore the map, focus on matching each payment type to its strengths: speed, value, risk profile, and typical purpose. <viz id="6"></viz> **Click each payment type** to compare its typical use. Then **complete the checklist** by choosing which scenarios call for RTGS. **Look for** situations where urgency, high value, and immediate finality matter most. You should now have a practical mental model: RTGS settles payments **in real time**, **one by one**, using **central bank money**, which gives strong **finality** but requires careful **liquidity** management. That makes it a cornerstone of high-value payment infrastructure rather than an all-purpose replacement for every other payment system. If you can explain why gross settlement reduces exposure, why central bank reserves matter, and why queued payments reveal liquidity pressure, then you’ve captured the essence of RTGS.