Realtime Gross Settlement
A comprehensive explanation of how RTGS facilitates immediate and individual settlement of transactions
In our ongoing quest to unravel the intricacies of modern payment systems, we've embarked on a journey exploring bilateral and deferred net settlement in our previous article. Today, we shift our focus to a pivotal player in the world of financial transactions: real-time gross settlement (RTGS).
Just like a fast and reliable express delivery service, RTGS ensures that financial transactions are swiftly and securely processed. Imagine you're ordering a much-anticipated gadget online. When you select the "RTGS" option at checkout, it's like choosing a premium shipping service. Instead of waiting days or weeks for your package to arrive, RTGS expedites the process. To better grasp the advantages of RTGS, let's compare it to other settlement methods. Think of traditional settlement systems like deferred net settlement (DNS) as a slow-moving train carrying numerous passengers, where payments accumulate throughout the day before being settled in bulk at the end. On the other hand, RTGS operates like a fleet of high-speed trains, individually processing each payment as soon as it's initiated. This ensures quicker access to funds and immediate finality, reducing the risk of delayed or uncertain payments.
With RTGS, banks can effectively manage their funds, as each payment is settled individually and immediately.
This allows for enhanced liquidity control, ensuring that banks have a clear understanding of available funds and can better allocate resources for lending, investments, and other financial activities. Most central banks around the world have implemented real-time gross settlement systems, however, we can also find realtime settlement in domestic SCMs like SIC (Swiss Interbank Clearing), SORBNET in Poland and RT1 and TIPS at pan-european level whose operating model is based on pre-funded accounts. One example of RTGS at the central bank level is CHAPS in the UK. CHAPS is the large value payment system used for interbank and same-day payments exceeding £250,000. We will dedicate an article to fully explain CHAPS. This models allows to exchange and settle payments in realtime between participants within central bank accounts directly.
On the other hand, the pre-funded accounts model is based on liquidity accounts held at the clearer infrastructure, requiring participants to proactively fund and diligently maintain them in fulfillment of their participation obligations. By strategically colocating liquidity close to where the clearing process takes place, the CSM is effectively able to settle transactions individually in realtime.
A simplified sequence of the clearing and settlement process in those models is depicted above:
The originator participant Bank1 sends payment to the CSM
CSM validates the message structure and its values, checks that Bank1 current liquidity can cover the transaction and routes the payment message to the beneficiary participant Bank2.
Beneficiary bank screens the payment and either accepts or rejects the transaction.
Confirmation message is returned to the CMS, in case of acceptance the payment is settled (booking inserted in bank accounts with opposite signs) and finally the confirmation is propagated back to the originator.
Rulebooks for realtime payment schemes establish Service Level Agreements (SLAs) that define the maximum allowable execution time for these flows, which participants are obligated to comply with. For instance, in the case of SEPA Instant, this timeframe is set at 10 seconds, although typically the entire process is completed in less than 2 seconds. As the SCM has a pre-funded account with liquidity as part of the instruction validation phase the infrastructure will check whether there is enough liquidity to cover each transaction individually. If the initiating participant lacks sufficient funds in its settlement account, the payment will result in an error, as depicted below.
As a consequence of the elimination of settlement and credit risk between participants in deferred net settlement systems, RTGS demands larger amounts of intraday liquidity to support payment obligations. This makes RTGS better suited to handling high-value transactions, as the larger amounts of intraday liquidity required could be impractical for smaller transactions.
RTGS systems require relatively large amounts of intraday liquidity to support payment obligations in comparison with DNS systems.
This means that while RTGS eliminates settlement and credit risk between participants, it also carries a cost of liquidity proportional to the amount being exchanged. To better understand the liquidity implications let's analyse it with an exercise. Suppose three banks, Gold, Diamond and Silver Bank, make payments to each other at the indicated times (Figure A).
Under the DNS model, and assuming that all the payments are processed in the same clearing cycle, only the net obligations resulting from the payments would be settled at the end of that cycle. These end-of-cycle positions are calculated in the following table: payments sent by a bank are shown as a negative figure, while payments received are shown as a positive figure (Figure B).
Banks Gold and Diamond have end-of-cycle net obligations of 2 and 5 respectively, while bank Silver has a net claim of 7. Settlement on a multilateral net basis would therefore consist of the following transfers across the accounts the banks hold at the settlement infrastructure (Figure C). For settlement to occur, banks Gold and Diamond need only have balances of 2 and 5 respectively on their accounts at the start of the day, while Silver bank needs no balance at all. The liquidity usage under the DNS model would therefore be 2 + 5 + 0 = 7
Alternatively, suppose that the payments settle under the RTGS model. Assuming each bank has a sufficient balance on its account, each payment would settle individually at the time it is made. If banks Gold, Diamond and Silver start the day with balances of x, y and z respectively, then hourly snapshots of the balances on their accounts at the settlement infrastructure, just after each payment has settled, would be as follows (Figure D)
If Gold and Diamond begin the day with a lower starting balance than 7 (x-7 = 0) and 5 (y-5 = 0) respectively, then at least one of the payments would not be able to settle, as there would be an insufficient balance on the payer’s account at the time the payment was to be made. The liquidity usage under the RTGS model is therefore 5+7+0=12.
And that's a wrap, folks! We have left some advanced topics like liquidity recycling for another post. Until next time, take care and stay curious!
