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. A bank had to remain liquid -critical if
it were to enjoy the confidence of its depositors - but this
criticality was an after the event issue.
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
propsed by a group of major international banks was for the CLS
(continuous linked settlement) system which won the approval of
the major central banks. Again the RTGS system was pressed into
use to provide the secure payments leg.
Additional factors such as straight through processing (STP)
provided the reward of error free transactions. All this 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 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 is
quoted below in full, and 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.
Bank liquidity management 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.
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 other. They are all being played at the same time
and each game is affected by and interacts with each of the
others. Checkmate on any one level can lead to checkmate on all
the others. In essence one is forced to play a game of
3-dimensional chess, replacing the traditional one.
To successfully manage intraday payment liquidity involves a
high degree of technical and analytical skill. 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 needs not only 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 attle 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.
