Real Time Gross Settlement

Real time gross settlement, known as RTGS, settles each payment individually and immediately, as soon as it is received by the system. There is no netting and no waiting for a batch. Each payment is checked, and if the sending bank has enough funds in its central bank account, the funds move straight away and the payment is final. If the sending bank does not have enough funds, the payment is queued until funds arrive, or it is rejected depending on the system rules. RTGS is the standard model for high value and time critical payments in almost every country. The main advantage of RTGS is that it removes settlement risk for a payment once it has settled, because settlement in central bank money is final and irrevocable. It does not remove all settlement-related risk, and it creates liquidity risk, because a bank must hold enough central bank money to settle each payment in full as it arrives. Because each payment settles in central bank money the moment it is processed, the receiving bank does not have to wait and does not face the risk that the sending bank will fail before settlement. This is why central banks require systemically important payments, such as interbank loans, to go through RTGS. Foreign exchange settlements use payment-versus-payment settlement, most commonly through CLS, so that neither side pays unless the other side pays too, and securities transactions settle through a central securities depository. RTGS, CLS and securities settlement are three different settlement mechanisms, and a payment uses the one that fits its market. The trade off is liquidity. Because there is no netting, banks need far more funds in their central bank accounts to process the same volume of payments. RTGS systems manage this liquidity demand with tools such as queuing, liquidity saving mechanisms, intraday credit from the central bank and collateralised overdrafts. A payment that cannot settle immediately waits in a queue, and the system looks for opportunities to offset queued payments against each other. Modern RTGS systems also offer features such as prioritisation, where urgent payments jump the queue, and bilateral and multilateral offsetting, which find groups of queued payments that can settle together. These features keep the system flowing even when liquidity is tight. Watch a queue save a payment. At nine twelve in the morning Bank A sends a EUR 45 million payment, but its central bank balance is only EUR 30 million, so the payment cannot settle. In a system without queuing it would be rejected and Bank A would have to send it again. In an RTGS system it waits in the queue. At nine forty in the morning an incoming payment of EUR 25 million arrives, the balance rises to EUR 55 million, and the queued payment settles at nine forty-one in the morning. Now take gridlock, the harder case. Bank A owes Bank B EUR 60 million and Bank B owes Bank A EUR 58 million, and neither has enough balance to pay first, so both payments sit in queues. The liquidity saving mechanism spots the pair, offsets them, and settles both using only the EUR 2 million net difference. Without offsetting, both banks would have waited for funds that could only arrive from each other, and the queues would have stayed blocked. For an analyst, the queue is a feature to specify, not a detail to leave to the vendor. The requirements should state the queuing rule, what happens when funds are insufficient, whether the payment is queued or rejected, how priorities work, and who can reorder or cancel a queued payment. The monitoring dashboard should show the queue depth in real time, the oldest queued payment, and the total value waiting, because a queue that grows through the morning is the earliest warning that a participant is in trouble. The test pack should include a payment above the available balance that queues rather than rejects, a gridlock pair that resolves by offsetting, and an urgent payment that jumps the queue ahead of routine payments from the same bank.