How RTGS Reduces Settlement Risk

Real time gross settlement reduces settlement risk by settling each payment immediately and individually in central bank money. Because settlement is immediate, there is no waiting period during which the sending bank could fail after the receiving bank has already acted on the payment. Because settlement is in central bank money, the receiving bank does not face credit risk on a commercial bank. And because settlement is gross, there is no net position that depends on other payments settling successfully. Each payment stands on its own, and once it has settled it is final. This does not mean RTGS eliminates all risk. A payment that is queued because the sending bank lacks funds has not yet settled, and the receiving bank is still exposed until it does. Operational risk remains, because a system outage or a processing error can delay settlement. Liquidity risk also remains, because a bank that cannot fund its payments will see them queue. What RTGS does eliminate is the specific risk that a payment is treated as settled before the funds have actually moved, which is the core weakness of deferred net settlement. That is a major improvement, and it is why regulators favour RTGS for high value payments. RTGS systems also include features that further reduce risk. Many systems settle payments on a delivery versus payment basis for securities, and on a payment versus payment basis for foreign exchange, linking the two legs so that one cannot settle without the other. They provide real time information on balances and queues, so banks can manage their liquidity proactively. And they operate under settlement finality legislation, so that once a payment has settled it cannot be unwound. Together, these features make RTGS the safest widely used settlement model, at the cost of higher liquidity requirements. Compare the same payment under two models. A bank lends EUR 80 million to another bank for one day. Through RTGS the payment settles at 10 in the morning in central bank money and is final immediately, so the lending bank knows the money has moved and the borrowing bank can use it. Through deferred net settlement the borrowing bank might credit its own customer at 11 in the morning, because it expects the EUR 80 million, but settlement does not happen until 4 in the afternoon. For five hours the borrowing bank has paid out money it has not received. If the lending bank failed at 2 in the afternoon, the borrowing bank would be out EUR 80 million with no payment to show for it. That five hour gap is the risk RTGS removes. Now take the edge case that RTGS does not remove. The EUR 80 million payment is queued at 10 in the morning because the lending bank is short of funds, and it settles at eleven fifteen in the morning when funds arrive. Until eleven fifteen in the morning the receiving bank must not release anything against it, because a queued payment is not a settled payment, and treating it as settled is exactly the mistake RTGS is designed to prevent. An analyst writes the funds availability policy from the settlement status, not from the message status. The rule should be simple. Customer funds are released only when the payment has settled, never when the message has merely arrived or been validated. The test pack should include a payment that queues for lack of funds, asserting that no customer credit is released while it is queued, and a payment that settles, asserting that the credit is released immediately after. The reconciliation design should keep three separate queues, validated but not settled, settled but not credited, and credited, because mixing them hides exactly the exposure this chapter is about.