Abstract
The last two decades of the XX century marked the starting point for the central banks across the globe to move their payment and settlement systems into Real Time Gross Settlement (RTGS) mode. Despite the fact that RTGS systems can effectively eliminate the credit exposure between the paying bank and the receiving bank at the interbank level by means of fast final and irrevocable money transfer, there is another serious problem associated with these systems. RTGS systems turned out to be liquidity-demanding arrangements, as opposed to deferred net settlement systems. Thus, the efficiency of liquidity management arrangements is the precondition of smooth RTGS operation, especially in tough times when liquidity is a systemic shortage. If liquidity management is inefficient, the RTGS system may stop operating properly by terminating in the grid-lock state brining chaos to the national economy. In this research we suggest the practical approach to solve the problem of seeking the maximization of aggregate value of payment instructions under liquidity shortage, including the most severe scenarios. The classification of the RTGS queue statuses is suggested and discussed. Some complementary results are articulated, including: (a) the statement that the formal mathematical optimization problem lies in the NP class of the computational complexity (the class of problems solved in polynomial time by nondeterministic Turing machine); (b) the equivalence between MaxFlow-MinCost problem (from the network flow theory) and the dual linear problem of the linear program relaxation of the initial optimization problem; (c) the illustration that no optimization strategy, other than the suggested one, can deliver substantially better optimization results. Despite enormous efforts, there were no previous research results reasonably claiming the near optimality of liquidity optimization strategy in RTGS systems under severe liquidity shortages. The results of this research may help the central banks and other RTGS system operators to ensure the protection of their payment systems from future liquidity crises and bring the resilience of respective national economies to the next level of sustainability.
Highlights
We say that at the time when the settlement is triggered, the queue at the Real Time Gross Settlement (RTGS) system is in the “general” status, where it is possible to select the sub-collection of the payments and simultaneously execute them as a group
It demonstrates the unparalleled resilience to severe liquidity shortages, producing no headache to the payment system operator and participating banks, and can be called the gridlock-proof
Let us consider the payment instructions submitted for settlement procedure to the payment system by the participating banks
Summary
Back in August 1998 just after few days the Russian Government announced it’s default of State Short-Term Government Bonds the payment system of the Central Bank of the Russian Federation was pressed by the most severe shock in its history. We say that at the time when the settlement is triggered, the queue at the RTGS system is in the “general” status, where it is possible to select the sub-collection of the payments and simultaneously execute them as a group. We call the status of the queue as “gridlocked” when no further settlement is possible, provided that FIFO rule and priorities are respected. The transformation from the “general” status to “gridlocked” status will be the first type of the queue transition. We call the status of the queue as “deadlocked” when no further settlement is possible, with no requirement to observe the FIFO rule and priorities. We call the status of the queue as “minimally deadlocked” when the collection of the remaining payments is minimal across all “deadlocked” queues, to which the initial “general” status can transit. It demonstrates the unparalleled resilience to severe liquidity shortages, producing no headache to the payment system operator and participating banks, and can be called the gridlock-proof
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have