Maintaining real-time control over a bank's liquidity

Maintaining real-time control over a bank's liquidity

Just a decade ago, the bank regulator was the only one who had to worry about the idea of bank liquidity. There is no doubt that a bank's liquidity is essential if it is to maintain the trust of its depositors, but this is more of an "after the event" problem than a live drama that unfolds in real time.

At that time, banks had a lot of freedom and privacy when it came to managing their liquid assets. This was due to the methods of paying interbank commitments that were in use at the time. Some of these methods have been around for at least two or three centuries. It was a world that depended on human transaction processing for items like checks. A batch processing system was first used to automate the manual method of bank computerization. In other words, it was only at the conclusion of a trading day that the "ins" and "outs" of a bank could be matched up that a bank's liquidity could be assessed. As long as the central bank was willing to pay any deficit and then backdate this protection to the previous trading day, a bank had a safety net.

In order to mitigate settlement risk and the potential for systemic collapse, central banks have virtually universally implemented payment mechanisms that guarantee finality of settlement. For high-value transactions, Real Time Gross Settlement (RTGS) has become the acknowledged method of assuring the national payment systems' safety.

Furthermore, it was essential that all stock market transactions be settled in a safe and irreversible manner to guarantee that the distribution of shares was based on the exchange of a final and irrevocable payment. The RTGS method was an excellent match for this need.

Settlements in foreign currencies were the next issue. When Herrstadt Bank went down, there were serious consequences. A PvP, or Payments against Payments system, similar to a domestic RTGS system, was developed by a consortium of big multinational banks as a safe way to settle one currency against another. Many of the world's leading central banks have agreed to adopt the CLS (continuous linked settlement) system, which they proposed. The RTGS system was once again called upon to deliver the safe payment leg of the transaction.

Additionally, the concept of straight through processing (STP), which aims to guarantee that transactions are completed without any human involvement, was a consideration in the decision-making process. Error-free transactions provide enormous benefits.

Real-time transaction processing and straight through processing (STP) have, of course, increased the requirement for real-time liquidity management.

It becomes more difficult to solve the issue with each new payment method that is introduced (e.g. RTGS, DvP, CLS). Domestic, international, and security payments are all necessary components of today's financial transactions. Other dimensions, such as ACH operations or check clearing activities, may need real-time and RTGS settlement as well, depending on local arrangements and requirements.

The Evolving Payment System: A Study of the Effect of Euro, CLS Bank, and CHIPS Finality was the topic of extensive research by the Federal Reserve Bank of New York's Payments Risk Committee in 2000. The research looked at the possible effects of proposed changes to payment systems in the United States and worldwide on US dollar intraday liquidity issues. "Intended to generate discourse on this problem and to recommend some potential best practices," was how the committee described the report. There are universal issues and answers for banks, no matter where they are located or how much money they have. According to the committee's findings, bank liquidity management has been headed in a certain direction.

"These changes need improved monitoring of payments flows, use of queuing methods to govern payment flows, greater communication, and a general knowledge by treasury managers of improvements in the payments processing operations." Real-time measurement will be necessary to analyze the accumulation of imbalances inside systems, detect gridlocks within and across systems, and construct more sophisticated contingency plans in payment operations, as in continuous industrial processes. In order to deal with the unanticipated volume and system changes, the linkages between systems will need new control mechanisms.

A bank's liquidity management is a vital part of its business operations. The impact of real-time money transfers on bank operations has yet to be completely appreciated by many financial institutions, however. Most of them have only been concerned with the local RTGS system until recently.

A bank's primary challenge will be different depending on its size. Trying to match the magnitudes of inflows and withdrawals "about" in real time, for example, could be a challenge for a smaller bank. Larger banks don't have to worry about this issue since they send and receive a lot of money all day long, every day. A natural flow of cash aids in the matching process, making it easier for them. A new dimension to real-time banking has emerged in nations where CLS is now fully operating. RTGS and the CLS systems have interacted to create a variety of new situations, which is real-time Forex settlement. The interplay between the RTGS and the security system is another illustration of this process.

Imagining a game of chess is one method to approach the issue. A two-dimensional game of chess may be used to describe the real-time liquidity difficulty faced by an RTGS system on its own. A chessboard is only complete when it includes the inclusion of CLS, securities, and other real-time money flows. It's possible to imagine these additional boards as stacking up like chessboards in three dimensions, one above the other. Each game has an impact on and interacts with the others since they are all being played at the same time. At least one level can be checked, which can lead to a checkmate on all the other levels as well. Instead of playing standard chess, you're forced to play a 3-dimensional version.

A high level of technical and analytical complexity is required to properly manage intraday payment liquidity. Until recently, it was impossible to overcome the technological challenges of properly adopting such a system throughout a bank. This is evolving as a result of new technology.

The underlying premise of such a system is to accurately simulate the timing of payments throughout the trading day. In order to simulate these fluxes, three important sources of information are needed.

using real-world examples. Payouts that have previously been received or made are "In the Pipeline" statistics. Data pertaining to "unpaid" invoices Payments in an internal RTGS queue or CLS or any other obligation may be the subject of this. Certain inbound payments, such as CLS settlements, may also be predicted with confidence.

Predicted paymentsIn some cases, unaccounted paymentspayment flows for the rest of the trading day may need to be estimated. For example, historical data may be used to determine the day of the week, month, and fiscal calendar events.

If you're using RTGS, the timing of these different flows may either be completely arbitrary, such as in the case of an RTGS system, or it can be connected to pre-defined settlement timings, such as for ACH, Securities, and CLS. There is a wide variety of payments that need to be handled by the bank's clearing activities. All or most of the following may be present in a conventional bank:

The RTGS network

Conventional foreign currency flows or CLS obligations as a direct participant or a sponsor

Settlements of securities claims

The "credit" flow of money is all that is involved in these three flows, making them simple to understand. This indicates that payments are created by the payee bank.

The standard debit and credit payment flows, as well as Giro type payments, will be included in the ACH operations.

EFTPOS transactions would also fall under the category of credit/debit card clearing procedures.

Banknote withdrawals and deposits may also be included in this category of transaction flows.

Aside from the fact that they require both credit and debit transactions, these four situations are the most difficult. ACH transactions that include both credit and debit payments would be an illustration of what is intended. To complicate things even further, many transactions are returned for various reasons (checks can't be paid; credit transfers won't work because the account has been canceled, etc.).

The usefulness of these latter four systems is sometimes cited as a reason not to include them in a bank's overall liquidity management system, despite the fact that they represent a large number of transactions. This all depends on the banking norms and practices in the nation where the transaction is taking place. Cheques and non-RTGS electronic payments may be worth more than RTGS payments in certain countries. The amount and value of cheques, for example, are still relevant in certain contexts.

In theory, the method for handling intraday payment flows is straightforward—but it is more complex to implement.

In the following sections, we'll explain how some of the world's largest banks manage their total liquidity situation in terms of assets and liabilities, which is a well-established practice. Over a period of weeks or months, banks use this strategy or a version of it. A bank's intraday and end-of-day payments flow may be managed using this method.

Methods like this one concentrate on bigger banks, but they may be used to assess and regulate bank payment liquidity even in smaller, more localized banks that only deal in domestic transactions. Management, information systems, central liquidity control, and the analysis of net financing needs under various scenarios are the essential concepts.

Preparation for the worst-case scenario

Regardless of the size or extent of a bank's activities, good payment liquidity management is essential.

A smaller, more local bank or a bank that participates in fewer payment systems is likely to be able to apply the technique more easily than a larger, more international bank.

The "Treasury Manager" of a bank is comparable to the general in a war zone. His forces are the liquidity that he has at his disposal; domestic balances, credit lines, foreign balances. As long as his institution's liquidity isn't compromised, he'll be fighting a fresh "war" every day. He must not only have the necessary funds on hand, but he must also have a variety of tactics at his disposal in order to wage this "war." Repurchase agreements and derivatives are only some of the tools he plans to use.

The Treasurer's office has taken on the role of command post in this new "war" for liquidity, and the information he needs for day-to-day operations is a critical component. Current day transactions and flows will be included in this information.

Some extremely intelligent computer that combines all of these sources of information into a single scenario that the bank treasures can effectively use for transactions that have not yet reached the "pipe-line," but are based on known occurrences, trends, and previous data.