Just a decade ago the concept of bank liquidity was for all intents and purposes only one for the Bank Regulator to really concern himself with. Certainly, a bank had to remain liquid – a critical factor if it were to continue to enjoy the confidence of its depositors – but this criticality was more an “after the event” issue than a live drama that unfolds in real time.

Then banks enjoyed a high degree of anonymity and choice in how it managed its liquidity. This was as a result of the techniques then used for settling interbank obligations. These techniques had been devised and refined over two or more centuries. They had come from a pre-computer world that relied on manual transaction processing of instruments such as cheques. Early moves at computerization of bank processes simply mechanized the manual approach by using the batch processing system. So the critical factor that related to the measuring of a bank’s liquidity could only be determined after the end of the trading day had been completed and all the “ins” and the “outs” were matched up. Even then, a bank had a safety net, provided by the central bank, which in most countries was prepared to cover any shortfall, and then to backdate this cover to the previous trading day.

A growing understanding of settlement risk and the possible contagion to systemic failure led central banks, almost without exception, to implement payment systems, usually under their own direct control that ensured finality of settlement. Real Time Gross Settlement (RTGS) especially where high value payments were involved has become the accepted mechanism of ensuring safety in national payment systems.

This was followed by the need to ensure that the settlement of stock exchange transactions also took place in a secure manner and that delivery of the shares was only against the exchange of a payment that was final and irrevocable. The RTGS approach fitted this need admirably.

Foreign exchange settlements were the next problem. The collapse of the Herrstadt Bank had caused major problems. The solution was provided by a group of major international banks who devised the continuous linked concept of settling one currency against another (a PvP or Payments versus Payments system) in a secure environment, not unlike a domestic RTGS system. Their proposal for the CLS (continuous linked settlement) system won the approval of the major central banks and has been implemented for a number of major currencies. Again the RTGS system was pressed into use to provide the secure payments leg.

Added to this was an additional factor, that of straight through processing (STP), where the ideal is to ensure that transactions right form their initiation in the clients office to their ultimate destination can be achieved no human intervention. The rewards, of error free transactions are immense.

Of course this shift to real-time transactions and transaction processing and straight through processing (STP) has added to the need to manage liquidity in real time.

Each new payment dimension (i.e. RTGS, DvP, CLS) adds to the complexity of the problem. Funds flows now involve domestic, foreign and securities payments as a minimum – each flow is really dependent on the other flows. There may be other dimensions too, depending on local arrangement and conditions, where other settlements may be require to be settled in real-time and on RTGS principles, such as ACH operations or cheque clearing operations.

The looming complexity of these requirements was the subject of an intensive study in 2000 by the Payments Risk Committee of the Federal Reserve Bank of New York (“Interday Liquidity in the Evolving Payment System: A study of the impact of the Euro, CLS Bank and CHIPS finality”). The study examined the potential implications for US dollar intraday liquidity risks that would come about from planned changes to payment systems in the US and elsewhere. In the words of the committee the report was “intended to stimulate dialogue on the issue and to suggest some possible best practices”. Even though the main focus was on the liquidity effect to banks in the US, the problems and the solutions are applicable to banks everywhere. A key finding of the committee is quoted below in full, as it clearly illustrates the direction in which bank liquidity management has been heading.

“These changes will create a need for better measurement of payments flows, use of queuing techniques to regulate payment flows, better communications, and a generally higher awareness by treasury managers of developments in the payments processing functions. Payment operations will assume some of the characteristics of continuous industrial processes where real-time measurement is required to assess the buildup of imbalances within systems, identify gridlocks within and between systems, and establish more elaborate contingency plans. The interconnections between systems will also require new control processes in order to cope with unexpected volume and systems changes.”

The liquidity management aspects of a bank’s operations is a critical area. However, up to the present time, many banks have not yet fully realized the effects that the real-time flows of funds have on their operations. Up to now, most of them have only worried themselves with the effects of the local RTGS system.

Depending on the size of the bank, the basic problem that is faces will be different. As an example, in a smaller bank, the problem could well be one of trying to match the magnitudes of the inflows and the outflows in "approximate" real-time. This sort of problem does not arise in the case of the larger banks simply because they send and receive high volumes of payments almost continuously throughout the day. So essentially they have a natural flow of funds that helps with the matching process. In countries where CLS is now fully operational banks have found that they have another dimension to this real-time aspect. What has happened is a whole range of fresh scenarios as a result of interactions between the liquidity side of the RTGS system (which one must remember are real-time domestic payments) and the CLS system (which is real-time Forex settlement). A further example of this process is the RTGS interaction with the securities system.

One way to view the problem is to envisage a game of chess. The real-time liquidity challenge presented by an RTGS system alone, can be viewed as a game of chess, in two dimensions. However once one adds CLS, Securities and other real-time funds flows one begins to add additional “chessboards” to the first. One can visualize these extra chessboards as being stacked vertically so that in reality there are a number of games in three dimensions, one above each

The approach and the concept to successfully managing intraday payment liquidity involves a high degree of technical and analytical complexity. Until recently the technical complications of successfully implementing such a system on a bank wide basis have been difficult to overcome. New technologies are changing this.

The basic principle of such a system lies in the effective modeling of payment inflows and outflows on a timed basis throughout the trading day. To model these flows three key information sources are required:

• Actual data. Actual data relating to payments that have already been received or made

• “In the Pipeline”. Data relating to “pending” payments. This may be payments in an internal RTGS queue, or scheduled to be made in terms of CLS or any other commitment. In certain cases inward payments may also be modeled with certainty such as CLS settlements due

• Forecast of payments flows. In some cases an estimate will need to be made of unaccounted for payment flows that are anticipated for the remainder of the trading day. This information may be based on historical data adapted in terms of day, the time of the month, fiscal calendar events and so on.

The timing of these various flows may be entirely random, as in an RTGS system or it may be to a specific schedule linked to pre-defined settlement times such as for ACH, Securities, CLS, Cheque and other similar settlements. The range of payments that need to be covered is essentially the whole range of payments that the bank is involved in clearing. For a typical bank this may involve all or most of the following elements:

• The RTGS system

• CLS obligations either as a direct participant or as a sponsored member or conventional foreign exchange flows

• Securities settlements

These three flows are relatively straightforward as they only involve the “credit” flow of funds – this means that payments are generated by the paying to the payee bank.

• ACH operations which will include the conventional debit and credit payment flows as well as Giro type payments

• Cheque clearing operations

• Credit/ Debit card clearing operations which would include EFTPOS transactions

• Other transaction flows such as the settlement of actual banknote withdrawals and deposits with the central bank or other parties.

These four scenarios are more complex in that they involve the processing of both credit and debit transactions, usually in the same systems. An example to illustrate what is meant would be a bank sending out both credit and debit ACH transactions – Credit payments would be an outflow to the bank, while debit transactions would represent an inflow of funds. The process is made more complex by the fact that very often transactions are returned for one reason or another – cheques will not be paid; credit transfers cannot be applied because the account has been closed etc.

An often heard criticism against including the flows for these last four systems in an overall liquidity management system is that while they represents high volumes of transactions their value tends to be insignificant and hence irrelevant to the overall position of the bank. This depends entirely on the customs and practices of the banking operations in the country concerned. In some countries values of cheque and non-RTGS electronic payments may exceed the total of RTGS values. In others cheques, as an example, still represent a significant volume and sometimes significant values.

The technique in managing intraday payment flows is relatively simple in principal – more difficult though in practice.

The techniques described below are based on the well-established process used by many of the world’s larger banks to manage their overall liquidity position in terms of assets and liabilities. Banks use this technique or a variation of it over a period of weeks or months. This technique can be adapted to manage the specific requirements of a bank intraday and end-of-day payments flow.

While this technique focuses on the use of the framework by larger banks in-so-far as the range and diversity of the various payment systems used, this approach is equally applicable to bank payment liquidity measurement and control, even for local, strictly domestic banks. The basic principles revolve around:

• Good management

• Information systems

• Centralized liquidity control

• Analysis of net funding requirements under alternative scenarios, and

• Contingency planning

All these are crucial elements of strong payment liquidity management at a bank of any size or scope of operations.

The information systems and analysis needed to implement the approach, however, can probably absorb fewer resources and be much less complex at a local bank or a bank that is active in fewer payment systems than the large, internationally active banks.

A bank’s “Treasury Manager” is similar to the commander on a battlefield. His forces are the liquidity that he has at his disposal; domestic balances, credit lines, foreign balances. With this basic force he has to fight a new “battle” each and every day to ensure that his institution has the liquidity to run its operations. Not only does he need to have the appropriate liquidity available, but also he needs to have a range of strategies to help him fight this “war”. The strategies and techniques that he will use will include derivatives, swaps, repurchase agreements etc.

The Treasurer’s office has become the command post in this new liquidity “battle” and a key element is going to be the information that he will need for each day’s operations. This information will include details of:

• Current day transactions and flows

• Details of transactions that are still in the “pipe-line”

• Estimates of expected transactions (for those transactions that have not quiet reached the pipeline), but based on know events, trends and historical information.

• Some very intelligent computing that combines all these sources of information into a single scenario that the bank treasures can use, effectively.

About The Author

Stanley Epstein is a Principal Associate and Director of Citadel Advantage Ltd., a consultancy dealing in bank operations and specializing in Operations Risk and Payment Systems. Further information and details can be found at http://www.citadeladvantage.com.