12 December 2016
The future of RTGS
The introduction of Real-time gross settlement (RTGS) systems has been a uniform process in most of the world’s major economies over the last 30 years. RTGS ensures wholesale obligations between financial institutions, typically high in value and low in volume are settled in a way that eliminates risk between those institutions, whilst through more complex processing (such as scheduling and liquidity management) ensures that the flow of funds between these organisations is managed intra-day to optimise efficiency and avoid a national cash flow crisis. RTGS is essentially electronic book keeping of funds held on behalf of the Financial Institutions by the Central Bank.
Traditionally RTGS has been used to settle “bulk”, retail payments in aggregate. Such systems used either a “settle before release” (SBR) or Deferred Net Settlement” (DNS) model where the aggregate sum of all transactions in a “batch” was settled together as single RTGS debits and credits either before (SBR) or after (DNS) the batch of payments were paid into individual beneficiary accounts.
Such systems operate on a periodic cycle of between several hours and several days. Both processes have shortcomings: SBR creates a delay in funding beneficiary accounts and inhibits multilateral netting (a process used to maximise efficient use of liquidity), whilst DNS payments create a “settlement risk” between participants until the corresponding bulk settlement has occurred. Various means of dealing with this risk are put in place such as guarantees, loss sharing agreements “unwinding” facilities etc. Few have ever been called into operation and it is not even clear that they would work.
As retail payments meet the 21st century, the requirement has been for speed, robustness, 24/7 availability and certainty. This has led to the rise of real-time payments. Typically smaller in value and higher in volume, such services meet the need for digital transfer of value instantly and irrevocably from bank customer to bank customer. Such payments cannot be conveniently batched and settled across RTGS in the old way as they have no concept of a “payments cycle”.
Early adopters used a “quick-fix approach” to solve this problem: in the UK a “loss sharing model” was put into place which was tied into hard caps in the Risk management of the real-time retail Faster Payments (FP) system. This ensured that settlement would always occur on a DNS basis, by calling on assets of the surviving Banks. In Mexico, the SPEI system, with relatively low volumes, has adapted the RTGS system to accommodate retail payments during working hours. Neither of these settlement methods has proved ideal or promises to be scalable.
The UK has now moved to a much more flexible model of “pre-funding” by which sums deposited by banks into a central bank account are reflected in values within the FPS risk management system, providing banks with a retail balance. From that point on, the FP system records the change in ownership of these balances between participants – effectively acting as a delegated mini RTGS system (although operating much faster and with much higher volumes). Designated settlement points enable banks to re-set their positions, either extracting excess value or inputting to re-set working balances.
In Sweden this model has been developed even further, such that the BiR real-time retail system operated by Bankgirot has its risk management functionality more tightly integrated with that of the Swedish Riksbank’s RIX RTGS system – to the degree that it is effectively legally recognised as part of that system. Recently both the Bank of England (BoE) and the ECB (ECB) have put into place reviews of their respective RTGS services. One key question is how far should they go in supporting real-time retail or instant payments. Whilst the BoE has recently said that whilst extending opening hours may be on the cards (to enable working balances to be adjusted more frequently), they have also indicated that settling each retail transaction separately is not for their RTGS system – effective connection to ancillary retail systems will enable these huge volumes to be managed effectively elsewhere, leaving the RTGS system to manage the more systemically significant funds flows between institutions. But the systems will be much more tightly connected, closer to the Swedish model. The ECB, however, is considering a range of future options (under the working title of TIPS – Target Instant Payment Service) which could see a new addition to its infrastructure, providing instant settlement of low value retail transactions directly to banks and other PSPs, as well as CSMs, 24 hours a day.
Such a model, if priced attractively would offer a viable alternative to existing Euro area CSMs, substituting central settlement for key elements of CSM functionality (the risk management element and network addressability). Some areas (e.g. messaging and network, the equivalent of a retail version of the UK’s current CHAPS scheme) may continue to rely on the existing national clearing organisations. It would also be a potentially massive undertaking for the ECB, if, as VocaLink expects, many existing transactions migrate to a real-time model – perhaps as many as 44 billion across Europe by 2027. Contrastingly in Canada, a recent review of payments services has suggested that a new system be built which treats replacement RTGS as an extension to a new real-time retail service.
The actions of Central Banks in reviewing their RTGS systems will shape the future retail payments landscape. Tighter integration between retail and wholesale systems will be a certain outcome. Whether this is achieved by greater centralisation by central banks, or by an approach which enables better interoperation with a synchronised commercial system will depend on decisions within each community, but the need to provide effective and irrevocable instant payments in high volumes will be top of the list of required outcomes.
 In view of the exponential increase this represents over existing euro RTGS volumes, together with different processing priorities, such a solution would more than likely require dedicated, separate infrastructure.