Marius Jurgilas, Ben Norman and Tomohiro Ota.
The final, practical determinant of whether a bank is a going concern is: does it have the liquidity to make its payments as they become due? Thus, the ultimate crucible in which financial crises play out is the payment system. At the height of recent crises, some banks delayed making payments for fear of paying to a bank that would fail (Norman (2015)). This post sets out a design feature in a payment system that creates incentives, especially during financial crises, for banks to keep making payments. This feature could address situations where banks in the system would otherwise be tempted to postpone their payments to a bank that is (rumoured to be) in trouble.
Context
With the main exception of Lehman’s failure in 2008, during recent financial crises the authorities have tended to prop up banks, fearing contagion otherwise from banks failing to meet payment obligations. As a result, more extreme financial crises than those witnessed recently have arguably been averted, often with a significant call on the public purse. Since 2008, the authorities have been taking many steps to address this, including introducing and enhancing bank recovery and resolution regimes, and, in the UK, implementing a “ring-fence” of the largest banks’ core services from certain riskier activities. The authorities’ current initiatives do not create incentives positively to encourage banks to continue making payments even during the height of a financial crisis.
A possible solution
Since their inception, a basic premise of systems that settle payments one-by-one in real-time (Real-Time Gross Settlement (RTGS)) has been that their member banks need to have sufficient liquidity in place in advance to make their payments. Obtaining such liquidity, whether via banks’ reserves balances and/or collateral repoed by the banks, is typically not costless (see e.g. Benos & Harper (2016)). So various RTGS systems have introduced designs to reduce the amount of liquidity needed (see e.g. Norman (2010); Jurgilas & Martin (2013); Seaward (2016)). Even with such enhanced designs, some counterparty credit risk – as mooted as the cause of payment delays in the UK’s CHAPS system in 2008 (Bank of England (2009); Benos, Garratt & Zimmerman (2012)) – would remain.
The design described here entails banks sharing some of the liquidity they use to make payments in a common pool. The pool can be used by any of the banks to make payments, provided that the sum of the net debit positions (i.e. where a bank pays out more than it receives in) across the system at any point in time does not exceed the amount in the pool. This condition ensures that the settlement agent (the central bank) is not exposed to credit risk when committing to settle payments made via the pool. Pooling reduces the cost for each bank to use this liquidity: whichever bank pays first uses (potentially all of) the pool to make its payment(s), whilst having had to provide only a fraction of the liquidity that contributed to the pool. This ought to lead to cascades of follow-up payments from other banks. In this way, the pool is potentially highly liquidity efficient.
So far so good. But what are the banks’ incentives to use such a pool during the height of a financial crisis? It turns out that, having committed to participate in the pool, these incentives are strong. The essence of the incentive structure is that banks participating in the pool want to reduce or eliminate other banks being in a net debit position: if a bank can choose to send payments early or delay, it sends early, as that reduces or extinguishes any net debit positions built up by the bank it is paying to.
As shown in the following link, let us suppose that there is a payment system with three banks, A, B and C, and each bank provides 1 unit of liquidity to the pool. Let us now suppose that A pays first and uses the pool to make a payment of all 3 units to B.
| Contribution to pool (£) | Net debit position (£) | Change in NDP | |
| A | 1 | 3 | 0 + 3 |
| B | 1 | 0 | n/a |
| C | 1 | 0 | n/a |
| A pays B 3 units | |||
What happens if A is (rumoured to be) in trouble? If it failed when it had already made its payment to B, then the central bank would need to settle A’s payment to B, and use the underlying asset generating the pooled liquidity to protect the central bank from credit risk. In such circumstances, the two surviving banks would have suffered a loss, each of a unit.
What is the best way that B and C can protect themselves from incurring this loss? It is to make payments themselves using the pool. B could make payments of (up to) 3 units from the pool to either (or a combination of) A or C; and/or C could make payments of (up to) 3 units from the pool to A. (For completeness, C could not, at this point, make a payment to B, until B had made payment(s) using the pool, since this would otherwise breach the system-wide net debit position constraint described above.) By making payments – in the example of, say, ½ and 1½ respectively – B and C are reducing their potential losses if A were to fail. Hence, there is a strong incentive, even at the height of a financial crisis, for banks to make payments using the pool, above all to any bank that may be (rumoured to be) in trouble.
| Contribution to pool (£) | Net debit position (£) | Change in NDP | |
| A | 1 | 1 | 3 – ½ – 1½ |
| B | 1 | ½ | 0 + ½ |
| C | 1 | 1½ | 0 + 1½ |
| A pays B 3 units, then B pays ½ to A; and C pays ½ to A | |||
Credit risk
One implication of this pool design is that it creates some credit risk for the banks (though not for the central bank). This credit risk exists even if a bank has not itself made a payment, as shown in the example above. Its amount is capped by how much a bank contributes to the pool. And a loss-sharing agreement could be structured such that a failed bank’s contribution to the pool is realised first, and only if that is insufficient to meet obligations due would the surviving banks’ contributions be realised. In short, there is a trade-off: in return for settlement efficiency generated by accessing the pool, banks take on some, limited, credit risk. Indeed this credit risk acts as the very device to incentivise early payments in all states of the world, including at the height of a crisis.
In addition to credit risk, there are potentially other risks to consider, such as adverse signalling effects if a bank were to increase significantly its use of the pool.
What about urgent payments?
It is also possible that a bank needs to make a payment urgently, but, under this design, the liquidity is in the “wrong” place in the pool for it to make that payment. (In the above example, C would be in this position if, following A’s payment of 3 to B, C needed to make an urgent payment to B.) To enable banks to make urgent payments, they could have their own separate liquidity in parallel to the pool, purely for their own use, just as they already do in RTGS systems. Taking an extreme example, if every single payment that a bank needed to make was urgent and it did not have access to the (shared) pool, it would be in no worse position than in an ordinary RTGS system.
Does such a liquidity pool exist anywhere?
Canada’s Large-Value Transfer System (LVTS) operates a liquidity pool similar to that described in this post, including with banks able to make urgent payments from separate liquidity reserved just for them. We are not aware of other case studies. Academic literature on liquidity pools in real-time systems is therefore concentrated on the Canadian LVTS: among others, McVanel (2005) and Ball & Engert (2007) simulate unanticipated defaults of one or several banks in LVTS; and O’Connor & Caldwell (2008) look at incentives to send payments to a bank expected to default.
Conclusion
An RTGS system incorporating a liquidity pool is both efficient and creates incentives for banks to make payments to each other even at the height of a financial crisis. There is some credit risk for the banks. This last feature is essential in creating the incentives to keep making payments throughout a crisis. Each bank’s credit risk is limited to the amount of liquidity it contributes to the pool. The pool can be used alongside a vanilla RTGS design (e.g. for urgent payments) and alongside other liquidity-efficient designs.
Whether the risks inherent in the pool design outweigh the liquidity benefits in all states of the world is a matter for central banks, supervisors and the banks to determine. It is also a parameter that can be varied: riskier banks could contribute a disproportionately higher amount of liquidity to the pool. Among other things, this will depend on risk appetites. At least one country (Canada) has, for many years, operated a liquidity pool in its main wholesale payment system. To avoid a situation where the integrity of the payment system could still be undermined at the height of a crisis by banks delaying making payments to each other, we think introducing a pool into RTGS systems in other countries too warrants serious consideration.
Ben Norman works in the Bank’s Major UK Retail Deposit Takers Division, PRA, Marius Jurgilas works at the Bank of Lithuania and Tomohiro Ota works at Goldman Sachs.
If you want to get in touch, please email us at bankunderground@bankofengland.co.uk. You are also welcome to leave a comment below. Comments are moderated and will not appear until they have been approved.
Bank Underground is a blog for Bank of England staff to share views that challenge – or support – prevailing policy orthodoxies. The views expressed here are those of the authors, and are not necessarily those of the Bank of England, or its policy committees.
Its a good idea. Anything that helps with Liquidity, in difficult times, for Banks. For the next crisis is going to be worse than 2008/9, for the system and Banks have not really recovered and the Central Banks have used up a lot of their tools and have taken on a lot on their own balance sheets.
When you refer to riskier banks, the pools should do a honest analysis, for some that may not look riskier may actually be riskier and charge the correct payments to the pool.