Real-Time Gross Settlement Systems: Principles and Design

1. Overview of RTGS systems

1.1 Main features of RTGS systems

Definition. An RTGS system is defined in this report as a gross settlement system in which both processing and final settlement of funds transfer instructions can take place continuously (i.e. in real time). As it is a gross settlement system, transfers are settled individually, that is, without netting debits against credits. As it is a real-time settlement system, the system effects final settlement continuously rather than periodically at pre-specified times provided that a sending bank has sufficient covering balances or credit. Moreover, this settlement process is based on the real-time transfer of central bank money. An RTGS system can thus be characterised as a funds transfer system that is able to provide continuous intraday finality for individual transfers.

Payment processing. Within this broad definition, the operational design of RTGS systems can differ widely. In particular, important differences may arise in the approaches to payment processing when the sending bank does not have sufficient covering funds in its central bank account. One possible way of treating transfer orders in such circumstances is for the system to reject the orders and return them to the sending bank. The rejected transfer orders will be input into the system again at a later time when the sending bank has covering funds. Until that time, sending banks may keep and control the pending transfers within their internal systems (internal queues). Alternatively, the RTGS system may temporarily keep the transfer orders in its central processor (system or centrally located queues) instead of rejecting them. In this case, the pending transfers will be released for settlement when covering funds become available on the basis of predefined rules, agreed between the system and the participating banks.

In many cases the transfer orders are processed and settled with the extension of central bank credit, normally provided for a period of less than one business day (intraday credit); in other words, the central bank provides banks with the necessary covering funds at the time of processing by extending such credit. The central bank could take a range of approaches to the provision of intraday credit in terms of (a) the amount of credit (including a zero amount), (b) the method by which credit is extended (e.g. overdraft or repo), (c) the terms on the credit (e.g. free or priced) and (d) the collateral requirements (if any).

These possibilities of payment processing (i.e. rejected, centrally queued, settled with central bank credit) are not necessarily mutually exclusive. For example, when the provision of central bank credit is constrained in some way, the transfer orders for which the sending bank could/would not obtain central bank credit will be rejected or centrally queued. In recent years, new or planned RTGS systems have tended to apply a combination of these possibilities rather than being based on only one form of payment processing.

Ability to limit payment system risks. RTGS systems can contribute substantially to limiting payment system risks. With their continuous intraday final transfer capability, RTGS systems are able to minimise or even eliminate the basic interbank risks in the settlement process.

More specifically, RTGS can substantially reduce the duration of credit and liquidity exposures. To the extent that sufficient covering funds are available at the time of processing, settlement lags will approach zero and so the primary source of risks in interbank funds transfers can be eliminated. Once settlement is effected, the receiving bank can credit the funds to its customers, use them for its own settlement purposes in other settlement systems or use them in exchange for assets immediately without facing the risk of the funds being revoked. This capability also implies that, if an RTGS system were linked to other settlement systems, the real-time transfer of irrevocable and unconditional funds from the RTGS system to the other systems would be possible. The use of RTGS could therefore contribute to linking the settlement processes in different funds transfer systems without the risk of payments being revoked.

As a corollary of the benefits of RTGS in interbank funds transfers, applying RTGS to funds transfers in an exchange-for-value settlement system can contribute to the reduction of the credit risk (principal risk) that may arise in such a system. Since RTGS permits the final transfer of funds at any time during the day (subject to the availability of covering funds), the final transfer of funds (the payment leg) can be coordinated with the final transfer of assets (the delivery leg) so that the one takes place if and only if the other also takes place. It is in this context that RTGS can provide an important basis for a DVP or PVP mechanism, thereby contributing to the reduction of settlement risk in securities and foreign exchange transactions.

Importantly, RTGS systems can offer a powerful mechanism for reducing systemic risk. As central banks have a common interest in limiting systemic risk, this capability has often been the key motive for many central banks to adopt RTGS in large-value transfer systems. The appeal of RTGS in terms of systemic risk containment may be better understood by breaking it down into separate elements. First, the substantial reduction of intraday interbank exposures could significantly lower the likelihood that banks may become unable to absorb losses or liquidity shortfalls caused by the failure of a participant in the system to settle its obligations. Second, RTGS precludes the possibility of unwinding payments, which can be a significant source of systemic risk in net settlement systems. Third, since banks can, in principle at least, make final funds transfers at the time of their choice during the day, settlement pressures are not concentrated at particular points in time. This makes it likely that banks will have more time to cope with problems (for example, a liquidity or solvency problem of a participant in the system), possibly by raising alternative funds or through the receipt of incoming transfers from other participants.

Intraday liquidity requirements. Provided that there are no legal problems with regard to settlement finality, the only structural impediment to continuous intraday finality is any liquidity constraint a sending bank may face during the day. A liquidity constraint in an RTGS environment has two basic characteristics, namely that it is a continuous constraint for settling funds transfers and that intraday liquidity requirements must be funded by central bank money; banks must therefore have sufficient balances in their central bank accounts throughout the processing day.

Intraday liquidity requirements raise important issues for both the central bank and the private sector. Central banks, for their part, face a choice as to whether or not to provide banks with intraday liquidity and, if so, what form that provision will take (e.g. by what mechanisms and on what terms the credit will be provided, and how any resulting exposures will be managed).

From the perspective of individual banks, intraday liquidity requirements may lead to concern about the associated costs. Such "liquidity costs" may include direct funding costs (interest paid or any other explicit monetary costs such as charges/fees on central bank credit), opportunity costs of maintaining funds in central bank accounts (e.g. interest forgone), or opportunity costs of tying up collateral or securities in obtaining central bank credit. Furthermore, banks may have to be actively involved in the management of their payment flows in order to use intraday liquidity effectively. This could require investment in the internal systems that they use to control payment flows, as well as entailing running costs.

The intraday liquidity requirements under a particular RTGS system depend critically on (a) the structure of financial markets and systems (e.g. the adequacy of private sector sources of liquidity, the amount of collateral/securities available, reserve requirement regimes) and (b) the central bank’s policy regarding the provision of intraday credit. The means by which intraday liquidity is provided can significantly affect the extent to which immediate, or at least very timely, final settlement occurs, and, ultimately, it can influence the balance between the potential benefits and costs of RTGS systems.

1.2 Overview of G-10 RTGS systems

In the G-10 countries, the first automated RTGS system was Fedwire in the United States. The modern version of Fedwire, based on a computerised, high-speed electronic telecommunications and processing network, was launched in 1970. By the end of the 1980s, six G-10 countries had introduced RTGS systems or large-value transfer systems with an RTGS facility. These systems were FA in the Netherlands (1985), RIX in Sweden (1986), SIC in Switzerland (1987), EIL-ZV in Germany (1987), BOJ-NET in Japan (1988) and BISS in Italy (1989). In the 1990s, further new RTGS systems have been introduced, while some of the existing systems have recently upgraded their risk management capabilities and system architecture. For example, the Federal Reserve started charging a fee for intraday (daylight) overdrafts in Fedwire as from April 1994, while SIC was updated to introduce prioritisation facilities into the centrally located queuing in July 1994. New RTGS systems include CHAPS in the United Kingdom, which previously operated as a net settlement system but became an RTGS system in April 1996, and ELLIPS in Belgium, which came into operation in September 1996. In France TBF is under development. In Italy and the Netherlands the existing systems (BISS and FA) will be replaced by completely redesigned systems known as BI-REL and TOP respectively. According to current plans, RTGS systems will eventually be in operation in all G-10 countries except Canada by late 1997.

As summarised in the comparative table in Annex 1, the design of G-10 RTGS systems differs considerably. For example, the systems can be divided broadly into two groups – systems without a central bank intraday credit facility and systems with a central bank intraday credit facility. The systems belonging to the former group are SIC (Switzerland) and BOJ-NET (Japan). In SIC, transfer orders are temporarily held in the centrally located queue if covering funds are not sufficient and are processed on the basis of the FIFO ("first in, first out") rule subject to assigned priorities upon the availability of funds, while in BOJ-NET uncovered transfer orders are rejected and returned to the sending bank.

In the remaining G-10 RTGS systems, central banks (will) provide intraday credit. In ELLIPS (Belgium), EIL-ZV (Germany), BI-REL (Italy), TOP (Netherlands), RIX (Sweden) and Fedwire (United States), intraday credit is or will be extended through intraday overdraft facilities. Intraday overdrafts must be fully collateralised in all of these systems except Fedwire. In Fedwire an institution that incurs an overdraft is charged a fee based on its average daily overdraft and the size of the overdraft is limited according to a predetermined cap; collateral is required in certain rare cases and when an institution frequently exceeds its cap by material amounts solely on account of book-entry securities transactions. In CHAPS (United Kingdom), the central bank does not allow overdrafts but instead provides intraday liquidity through intraday repos; a similar approach will be adopted in TBF (France). In both these cases repos have been chosen largely for reasons associated with the legal status of the central bank’s claim on the securities provided.

Besides SIC, centrally located queues are or will be provided in ELLIPS, EIL-ZV, TBF, BI-REL, TOP and RIX, although their architecture shows considerable diversity. CHAPS is based primarily on internal queues; it is for each bank to decide the nature of the payment flow control process (and any associated algorithm) to be applied to transfer orders in an internal queue. Anecdotal information suggests that internal queuing arrangements are also used by some larger participants in Fedwire. Furthermore, it is also reported that many large banks use internal queuing processes even in RTGS systems with centrally located queuing (e.g. SIC and BI-REL). This suggests that participants in RTGS systems often actively manage their own payment flows.

2. Components, measures and management of liquidity in RTGS systems

This section looks at issues relating to liquidity in RTGS systems. It first describes each of four possible components of liquidity available to participants in RTGS systems and then considers the different measures of liquidity that can be constructed from these components. It then discusses the management of liquidity from, respectively, an individual bank’s point of view and the system’s point of view. Finally, it looks at how structural factors can affect liquidity and its management.

2.1 Components of liquidity in RTGS systems

In general terms, for an individual participant in an RTGS system the four possible sources of funds are (a) balances maintained on account with the central bank, (b) incoming transfers from other banks, (c) credit extensions from the central bank and (d) borrowing from other banks through the money markets.

Balances maintained at the central bank can be a basic source of liquidity for the purpose of making funds transfers during the day. At a given point in time during the day, the level of the balance for an individual participant is determined by the starting/overnight balance and any payment activities (including both RTGS payments and any other transactions across the account), credit extensions by the central bank and central bank monetary operations that have taken place by that time.29 Starting balances may be generated by reserve requirements that are usually imposed for monetary policy reasons. Provided they are available for payment purposes during the day, required reserves can be a helpful source of intraday liquidity, as has proved to be the case in several G-10 countries. The importance of required balances may, however, vary between countries, depending on the nature of the reserve maintenance regime(e.g. the level of the required reserve ratio and any averaging provisions).

Incoming transfers can also be an important source of intraday liquidity. The importance of incoming transfers depends on the patterns and predictability of payment inflows and outflows. If, for instance, payment flows tend to result in a specific pattern for a particular bank (such as net payment outflows) or if the intraday timing of incoming and outgoing transfers tends to be asymmetrical, incoming transfers may be less reliable as a funding source for outgoing transfers. Furthermore, the usefulness of incoming transfers may also be affected by the availability of information on them; the more information that is available in real time, the more effectively banks may be able to use incoming transfers in their liquidity management.

Intraday liquidity may be provided by the central bank through credit extensions. As described in Section II.1, many central banks provide intraday credit, typically free of interest charges, through fully collateralised intraday overdrafts or intraday repos. As already noted, Fedwire charges a fee for the use of the uncollateralised intraday overdraft facility that it provides up to a limit based on a bank’s creditworthiness and capital. Central banks may also have some kind of overnight central bank liquidity facility that RTGS participants may access under certain conditions. However, overnight credit extensions from the central bank (e.g. overnight loans or overdrafts) may be considered a relatively costly funding source to support intraday payment activities, because the funds only needed for an intraday period must be borrowed overnight and they can in some cases incur an implicit or explicit extra cost (e.g. penalty rate) in addition to the discount or market rate.

Banks in an RTGS system may also be able to obtain funds by borrowing from other banks through the interbank money markets. Money market credit extensions such as overnight and term loans may allow banks to fund intraday payment flows, depending on the time of day that market conventions set out for loans to be arranged, made available and repaid. For example, if banks can borrow from overnight interbank markets throughout the operating hours of the RTGS system, the loan proceeds could be available to fund transfers intraday (i.e. depending on when the funds are credited to the borrowing bank’s account). While credit extensions from the central bank can be regarded as external liquidity support that injects additional liquidity into the system, money markets can only serve to redistribute funds already within the system, although that may nevertheless make an important contribution to reducing the reliance on banks’ reserve balances and central bank credit extensions.

Intraday money markets could also act as a private sector liquidity source in the RTGS environment. In such markets banks would lend reserve balances on an intraday basis provided that the intraday timing of loans being arranged and repaid could be assured and the transaction costs of such arrangements were not prohibitive. If such a market existed, banks could operate with lower balances because of the ability to redistribute balances across banks during the day. At the moment, however, the only example of an intraday money market in the G-10 countries that has developed from an RTGS environment seems to be that in Switzerland, and even that is a very limited market for special time-critical payments in connection with securities transactions. An intraday interbank market also exists in Japan but this market is not directly related to the intraday liquidity needs under RTGS but rather to the need for bridging liquidity between four designated net settlement times in BOJ-NET. The possibility of the development of intraday money markets in an RTGS environment is considered in more detail in Section III.2.

2.2 Measures of intraday liquidity

On the basis of the four components discussed above, liquidity as applied to the operation of RTGS systems may be measured both from an individual bank’s perspective and from a system perspective. From a bank’s perspective, intraday liquidity may be taken to be the bank’s ability to settle a given value and number of transfers within a given time constraint.

One way to characterise this concept would be to define so-called "net" intraday liquidity on the basis of actual cash flows. As already noted, a bank’s actual balance at the central bank at a given point in time during the day is determined by the starting balance as well as any payment or monetary activities and credit extensions that have taken place by that time. This actual balance, however, may not necessarily represent the liquidity immediately available for the bank to initiate new outgoing transfers at that time, because some or all of the transfers that it has already initiated may be queued within its internal system or in the centrally located queue. A bank’s net intraday liquidity, which may correspond more closely to its ability to settle its outgoing transfers at a given point in time, could be defined as the actual balance minus the value of all pending transfers.

Alternatively, a bank’s net intraday liquidity could be defined on the basis of the sum of actual and potential cash flows. Such a concept has been adopted in some RTGS systems as a measure of available liquidity, although in some other cases it has been felt that incorporating potential cash flows may be too difficult. Potential cash flows refer to potential funds which a bank could mobilise or use for cover. For example, a bank might include queued incoming transfers as a source of liquidity that it expects to be available shortly for its own outgoing transfers. In this case, a bank’s net intraday liquidity is defined as the actual balance plus the value of queued incoming transfers minus queued outgoing transfers. As potential sources of liquidity, a bank might also include, for example, unused credit lines or liquid collateral.

Concepts of illiquidity. If net intraday liquidity is negative, the bank can be viewed as being illiquid in the sense that it is unable to settle some or all of its queued outgoing transfers. However, care needs to be taken in interpreting the concept of a bank’s illiquidity. Although transfers processed over an RTGS system have some degree of time-criticality, not all transfer orders are time-critical in the sense that they must be settled either at or by a specific point in time during the day or within a specified and limited interval of time during the day. Some funds transfer orders may be time-critical only in a same-day sense even in an RTGS environment. Time-criticality and intraday time constraints may be influenced by the nature of the transfers, transaction pricing policy (see below) and rules relating to end-of-day closing procedures. Accordingly, even if a bank becomes illiquid, it may be able to delay certain less time-critical transfers in order to allow subsequent incoming transfers to provide the necessary liquidity. The scope for such liquidity management will vary, and typically will narrow towards the end of the day. In practice, therefore, for illiquidity to have a significant impact on a bank, it must occur over some "significant" interval of time.

System liquidity and gridlock. From a system perspective, the concept of intraday liquidity could be related to the "amount" of funds that enables the system to process transfers between all or most of banks in a timely manner. However, it is more difficult to analyse system liquidity because it is not simply the sum of each bank’s net intraday liquidity as defined above. Whether the system is liquid or not also depends crucially on the distribution (or concentration) of liquidity among banks in relation to their payment needs. For instance, gridlock could be characterised as a case of system illiquidity in which the failure of some transfers to be executed prevents a substantial number of other transfers from other participating banks from being executed. Of course, gridlocks could occur when the aggregate liquidity is insufficient, but they might occur even if the liquidity in the system, taking into account all queued incoming and outgoing transfers, was adequate overall but poorly distributed. Suppose two systems had the same aggregate sum of bank liquidity: one might be liquid while the other might be in gridlock if liquidity was concentrated among a few banks in that system (see Box 2). Because of this, some systems provide banks with ways of breaking gridlock.

Another important issue in connection with system liquidity is that there might be negative externalities relating to the use of a bank’s liquidity. For instance, a bank may deliberately be slow in processing transfers in order to economise on its own liquidity by relying on the receipt of incoming transfers from others. If such behaviour is widespread, there is the potential for a kind of self-imposed gridlock as each bank delays sending its payments until others do so, with the result that (in an extreme case) none are sent.

2.3 Management of intraday liquidity: an individual bank’s perspective

The need to have intraday liquidity typically entails a positive cost for banks in the form of funding costs and/or opportunity costs. Banks therefore have incentives to manage intraday liquidity by attempting to minimise it subject to certain constraints. Constraints on intraday liquidity management vary from system to system. In general, banks are likely to try to avoid undue delays in time-critical transfers (both because of customer relations and on account of possible legal liabilities) as well as to try to minimise end-of-day overdrafts or processing penalties. For these purposes, for example, banks may hold precautionary balances to guard against urgent and unexpected transfers. Reserve requirements could also be a constraint, particularly if the requirement has to be met each day.

An optimal level of intraday liquidity for an individual bank may be determined by the balance between the costs of obtaining or maintaining liquidity and the costs of delaying settlement. As noted in subsection II.1.1, the former (liquidity costs) may include direct funding costs, opportunity costs of maintaining funds in the central bank accounts and opportunity costs of tying up collateral or securities for central bank credit. The opportunity cost associated with collateral for obtaining intraday liquidity could be relatively low if banks already hold the relevant types of asset in sufficient quantities, which they might do as part of their portfolio strategy or for other reasons. Although it may not be easy to measure in practice, from an analytical point of view the concept of "settlement-delay costs" could be defined as the potential or actual economic costs incurred if the settlement of funds transfer orders were delayed. The degree of settlement-delay cost in a particular RTGS system may depend on the time-criticality of the underlying transactions, transaction pricing policies as described below and, more generally, market practices. Given the level of liquidity costs, banks are likely to have stronger incentives to obtain or maintain intraday liquid funds as delaying settlement becomes more costly.

With a given starting balance, banks may operate intraday by adjusting the use of intraday or overnight credit, sequencing incoming and outgoing transfers or, in limited circumstances, selling assets for same-day settlement. Of these possibilities, sequencing transfers is a way of controlling intraday payment flows by scheduling the timing of outgoing transfers according to the supply of liquidity provided by incoming transfers. Importantly, to the extent that incoming and outgoing transfers are successfully sequenced, it could generate virtual "offsetting effects" on RTGS payments and hence contribute to substantially reducing the necessary liquidity. The most common way of sequencing is to use queuing arrangements. Regardless of whether it is centralised or decentralised, queuing allows banks to sequence transfers in a systematic way. Queuing is described and discussed in detail in Section II.4.

Another method of sequencing transfers may involve message codes indicating the time of day that an individual outgoing transfer should be settled. Such time-of-day message codes may be used to store transfer orders within the central processor in the system or within the internal system of the sending bank.39 Time-of-day message codes might allow banks to better forecast liquidity requirements by increasing the certainty of the timing of debits and credits associated with transfer orders involving a standard time-lag between the transaction date and the settlement date (e.g. securities and foreign exchange transactions), intraday and overnight loans and other time-critical transfers such as those for the settlement of balances in net settlement systems.

Even if they attempt to coordinate incoming and outgoing transfers as closely as possible, banks may still face several limitations in minimising intraday liquidity requirements. First, as noted above, if transfers are time-critical, that limits the extent to which banks can delay them. Second, individual transfer orders are often very large. Breaking down a particularly large transfer into two or more smaller amounts may facilitate sequencing, and in some RTGS systems this is actually done as a standard means of liquidity management. Nevertheless, the resulting transfers can still be large, which would make closer sequencing difficult. Third, banks cannot have complete information about the transfers they are due to receive and send on that day, so that they have to sequence transfers more or less on the basis of predictions.

2.4 Management of intraday liquidity: a system perspective

The management of intraday liquidity from a system perspective may concern both management of the aggregate level of liquidity relative to payment requirements in the system and management of the distribution of liquidity among banks. For the former purpose, the central bank may typically provide individual banks with credit directly for settlement purposes or indirectly through monetary operations according to its policy.

It is possible that the optimal liquidity management from an individual bank’s perspective may not necessarily be best for the system as a whole. As noted earlier, a bank may make a deliberate attempt to delay the processing of transfers to economise on its own liquidity by relying on the expected receipt of liquidity from others. To minimise the possible negative effects of such behaviour on system liquidity, RTGS systems sometimes incorporate mechanisms to discourage "selfish" behaviour and to encourage early processing and/or settlement of transfers. One way is to lay down rules governing banks’ outgoing payment flows, such as guidelines requiring banks to send a certain proportion of their daily payment messages by specified times. Such a rule would discourage banks from delaying transfers. However, it may be inappropriate in some cases; for instance, some banks may have atypical intraday patterns of transfers, making it unrealistic for them to observe such a rule. Or it may be that the rule is incompatible with the pattern of transfers deriving from DVP or (future) PVP arrangements, where the timing of transfers is critical. At the least, therefore, some flexibility may be needed in setting and applying such a rule.

An alternative method may be to apply a transaction pricing policy that would encourage the early processing (input) and settlement of transfer orders. For instance, SIC applies a pricing schedule for sending banks that penalises (i.e. sets a higher charge on) late input and settlement of transfer orders, while the receiving bank is subject to a flat pricing schedule. This has led banks to send and settle their bulk low-value payments as early as possible, ahead of large-value funds transfers. Some proposed systems are also considering the possibility of adopting a pricing policy that would set a higher charge on queued or late transfers (i.e. transfers that are entered only shortly before the close of the system). Charging a penalty fee on the transfers that remain unsettled at the end of the day could be used to complement such a transaction pricing policy.

Monitoring system liquidity. Central banks (or system centres) are in many cases concerned with monitoring and managing liquidity in RTGS systems so as to maintain a smooth flow of payments and to detect and prevent possible gridlocks. There are significant differences in central banks’ technical approaches to monitoring system liquidity. For example, the Bank of Italy envisages an "indicator approach" to real-time monitoring whereby the central bank will pay particular attention to synthetic indicators calculated on the basis of several key parameters such as the total amount of liquidity available in the system, the volume of transfers entered into the system and the volume of settled transactions. The indicators will be used to observe the queues and intraday liquidity in the system as a whole and also to identify any potential gridlocks which may require further investigation of an individual bank’s net liquidity position. On the other hand, the Bank of France will take a more "micro approach" whereby it will monitor in real time each bank’s net intraday liquidity. In contrast, the Swiss National Bank does not systematically monitor system liquidity in SIC. This reflects its view that monitoring liquidity is mainly the responsibility of participants and that there should be no intervention by the central bank or the system in the centrally located FIFO queue.

2.5 Structural factors affecting liquidity requirements and management

There are various structural factors that may affect liquidity requirements and management in an RTGS system. First, the number of participants may be of significance. Compared with a system with a larger number of participants, an RTGS system with relatively fewer participants might internalise a greater proportion of third-party payments and therefore have a lower level of interbank transfers sent over the system; as a result, less intraday liquidity might be required at the system level to process a given volume of payments. Such a system may also have more concentrated, offsetting payment flows between banks and thus incoming transfers would be a relatively more important source of liquidity. Furthermore, it might technically be less complicated for banks to monitor, control and sequence payment flows in a system with relatively fewer participants.

Second, the relative market size (in terms of payment activity) or asset size of participants may affect liquidity. An RTGS system with a mixture of large, medium and small participants may have a different set of intraday liquidity requirements from a system consisting of participants of broadly equal size. Larger banks, for instance, may have a more balanced intraday flow of incoming and outgoing transfers, so that incoming transfers can provide the liquidity needed to fund outgoing transfers, while smaller banks may process fewer transfers or tend to be net senders/receivers of funds in the RTGS system. Larger banks may also find it easier to obtain the necessary liquidity if they have better access to funding and credit markets or a larger deposit base than smaller banks.

Third, participants’ areas of specialisation may matter. If an RTGS system is composed of banks that specialise in a variety of different market segments (such as merchant banking, credit card transactions, deposit-taking, clearing activities, foreign exchange transactions and securities transactions), payment flows and patterns and the resulting liquidity requirements may differ from those in systems where participants tend to offer a more uniform range of products and services.

Fourth, the structure of the payment systems and flows outside the RTGS system may affect RTGS liquidity. Non-RTGS payments can be an important "exogenous" factor affecting a bank’s RTGS liquidity. In practice, the mechanism through which non-RTGS payments influence RTGS liquidity may take a variety of forms. Typically, net settlement obligations resulting from other settlement systems (e.g. cheque clearing, other large-value transfer systems, ACH transactions and securities settlement systems) are settled periodically over the RTGS system or at least processed through the same central bank account as that on which the RTGS system relies for intraday liquidity (see Section III.1). In such circumstances where RTGS payments and the settlement of non-RTGS payments are interrelated and "competing" uses of liquidity could therefore arise, banks may use internal systems capable of integrating their RTGS and non-RTGS payment activities on an intraday basis to manage their overall liquidity. At the same time, since the settlement of foreign exchange transactions accounts for a substantial part of the total value handled by many RTGS systems, existing or proposed netting arrangements for such transactions (e.g. FXNET, ECHO and Multinet) may, by requiring only the net value of the transactions to be settled, also have an effect on the value and timing of transactions, and consequently on the liquidity, in some RTGS systems.

Fifth, the structure of central bank accounts may be an important factor influencing RTGS liquidity. As the comparative table in Annex 1 shows, there are differences between G-10 countries in the way central bank accounts are organised: central bank accounts for RTGS may be unified with or segregated from central bank accounts for other purposes, for example for required reserves. Moreover, central bank accounts may be centralised (i.e. banks hold accounts for making transfers at only one office of the central bank) or decentralised (i.e. they are permitted to hold accounts at more than one office).

One question is whether, under a decentralised account structure, banks are able to monitor balances and shift them efficiently between accounts on a real-time basis for liquidity purposes. In general, the structure of central bank accounts in a country is determined by a number of different considerations and therefore an optimal account structure will not necessarily depend only on the settlement arrangements for RTGS systems. However, in countries that have a decentralized account structure and where RTGS systems are operating or planned, there seems to be a broad tendency to centralise/consolidate central bank accounts, or at least to centralise the arrangements for processing the account data. This may suggest that a more centralised structure is sometimes a more efficient and straightforward structure for an RTGS environment, in particular in terms of liquidity management. For example, in preparation for TBF, the Bank of France is moving from a decentralized account structure in its branches to a centralised one at the head office. In Germany the Bundesbank has so far provided several facilities to help banks manage liquidity in a more centralised way in EIL-ZV under the decentralised account structure. In addition, it plans to convert the current decentralised electronic data-processing structure into a new centralised one and to take further steps to provide more comprehensive information about queued payments with a view to enabling banks to conduct more efficient liquidity management. In the United States the Federal Reserve is taking the approach of using centralised accounts but with distributed sub-accounts to provide for segregation and flexibility as regards transaction information.

3. Message flow structures

As noted earlier, a lag between the time at which information is made available to receiving banks and the time at which settlement takes place may have important risk implications in large-value funds transfer systems. Even in the RTGS environment, where both processing and final settlement are made in real-time, several circumstances can be identified in which the treatment of payment messages or the associated information could be a source of risk. This section looks at four different types of message flow structure.

To initiate a funds transfer the sending bank dispatches a payment message which is subsequently routed to the central bank and to the receiving bank as the system processes and settles the transfer. Arrangements for routing payment messages in the majority of RTGS systems are or will be based on a so-called V-shaped message flow structure. In this structure the full message with all the information about the payment (including, for example, the details of the beneficiary) is initially passed to the central bank and is sent to the receiving bank only after the transfer has been settled by the central bank (see Box 3).

Some G-10 RTGS systems, and particularly those that use the S.W.I.F.T. network, apply an alternative structure, known as a Y-shaped structure. In this case, the payment message is transmitted by the sending bank to a central processor. The central processor takes a subset of information that is necessary for settlement from the original message and routes this core subset to the central bank (the original message being kept in the central processor). Upon receipt of the core subset, the central bank checks that the sending bank has sufficient covering funds on its account and informs the central processor of the status of the transfer, for instance queued or settled. Once settled, the full message containing the confirmation of settlement is rebuilt by the central processor and sent to the receiving bank. The business information exchanged between the sending and receiving bank (such as the identity of the beneficiary) is therefore not known by the settlement agent.

So far only CHAPS has adopted an L-shaped structure, which is conceptually similar to a Y-shaped structure. This configuration was chosen because it could be implemented by modifying rather than rewriting the software supporting the previous DNS arrangement. The payment message dispatched by the sending bank is held at a system "gateway" attached to the sending bank’s internal processing system and a subset of information contained in the original message (a settlement request) is sent to the central bank. If the sending bank has sufficient covering funds on its account, settlement is completed and the central bank sends back a confirmation message to the sending bank’s gateway. Upon receipt of this confirmation (and only then), the original payment message is released automatically from the gateway of the sending bank and sent to the receiving bank.

In part, these different structures reflect differences in both the network configuration of the system and the operational role of the central bank. In both the V and Y-shaped structures, all messages from the sending bank are routed first to a central entity (S.W.I.F.T., a central processor or the central bank itself) and, after settlement, all messages to the receiving bank are sent by that central entity. By contrast, there is no central entity for delivering messages in the L-shaped structure, where message routing is based on the bilateral exchange of information between banks, reflecting the decentralised architecture of the CHAPS system. In terms of its operational role in the system, the central bank is directly involved in both the settlement and processing of payment messages in the V-shaped structure, while in the Y and L-shaped structures the process of message routing can be handled by the network operator or the banks themselves, with the central bank only acting as the settlement agent.

It is important to note, however, that these three types of structure all share the common feature that the receiving bank will receive the full payment message only after the transaction has been settled by the central bank. In these structures, therefore, the message flow structure per se cannot give rise to the possibility that the receiving bank will act upon unsettled payments.

Alternatively, RTGS systems could apply a T-shaped structure, in which the sending bank routes payment messages directly to the receiving bank (through the message carrier), with copies (made by the message carrier) sent simultaneously to the central bank. This means that the receiving bank will first receive the full, unsettled payment message immediately after the sending bank has dispatched it and will subsequently also receive a confirmation message from the central bank once settlement has taken place. The T-shaped structure has generally been viewed as being incompatible with the basic principle of RTGS that a funds transfer should be passed to a receiving bank if and only if it has been settled irrevocably and unconditionally by the central bank. The receiving bank may not easily be able to distinguish between settled and unsettled payment messages at the time of receipt of the (unconfirmed) messages; even where it can make the distinction, competitive pressures may cause it to credit the funds to the beneficiary customer on the basis of the unsettled message or it may anticipate the arrival of the funds in other ways (e.g. by reducing the liquidity it obtains from other sources). To the extent that this happens credit and liquidity risks would be generated in the system in a manner analogous to that discussed in Section I.2. As this aspect has been recognised as a drawback in the RTGS environment, no planned or existing G-10 RTGS systems are based on the T-shaped structure.

4. Queuing arrangements

Broadly defined, queuing refers to an arrangement whereby funds transfer orders are held pending by the sending bank or by the system in a certain order so as to prevent any limits set against the sending bank from being breached or to manage liquidity more generally. In RTGS systems, queues are most commonly generated when sending banks do not have sufficient covering funds in their central bank account. As described in Section II.1, individual banks’ queues may be held at the system’s central processor (system or centrally located queues) or they may be held within the banks’ internal systems (internal queues). These two broad possibilities according to the location of the queues are not mutually exclusive; banks may maintain internal queues in addition to the queues at the centre, as is done in some RTGS systems with centrally located queues. Queuing can also differ according to the management of the queues, that is, how an individual bank’s queue is controlled. The management may be carried out by the centre (centralised management) or by banks individually (decentralised management). Irrespective of whether the queues are physically located at the centre or within banks’ internal systems, the management of queues could in principle be either centralised or decentralised. Combinations of these possibilities in terms of the location and management can thus lead to various forms of queuing.

This section looks at queuing in RTGS systems. It first provides an overview of the key design features that are typically seen in centrally located queuing, then considers the information facilities provided under such arrangements (and in particular the degree of "transparency" of queued incoming transfers), and finally discusses the possible implications of different approaches to queuing.

4.1 Key components of centrally located queuing

Methods of queue processing. To date, most centrally located queuing arrangements have adopted a form of FIFO ("first in, first out") rule for queue processing. Where the FIFO rule is applied, funds transfer orders are held in the order in which they are dispatched by the sending bank; the payment at the top of the queue is released and settled when covering funds become available, and only then is the payment behind it in the queue considered for settlement. Some systems apply variations on the strict FIFO rule; for example, ELLIPS uses a "bypass FIFO" rule under which the system tries to process the first transfer in the queue, but if that cannot be executed owing to lack of funds it then tries to settle the next transfer instead.

It seems that the FIFO rule (or a variation on the FIFO rule) is the predominant method of centrally located queuing because of its simplicity. Moreover, although non-FIFO rules or more sophisticated mathematical algorithms might be more efficient in settling a greater number of transfers, the same efficiency may be achievable in a more straightforward way by combining simple FIFO with facilities such as prioritisation, reordering or optimisation as described below.

In practically all centrally located queuing arrangements, the system provides facilities whereby priority codes are attached to the funds transfers. Where this is the case the transfers are placed in the queue on the basis of the assigned priorities and are released for settlement on a FIFO basis within each priority level (i.e. no transfers of a particular priority will be settled until all those of a higher priority have been settled). In some systems, the priorities are chosen by the sending banks according, for example, to their assessment of the urgency of the transfer, whereas in other systems transfer orders are prioritised automatically by the system according to the type of transaction. In the latter case, a high priority tends to be attached to transfer orders relating to central bank operations or settlement obligations stemming from other systems such as securities DVP systems and netting systems. The use of priorities helps banks to achieve greater flexibility in FIFO processing.

Queue management or intervention facilities. In addition to prioritisation facilities, centrally located queuing arrangements in recent or planned systems sometimes include queue management or intervention facilities that allow the system centre (i.e. the central bank or system operator) and/or individual banks to control the number/value of queued transfers.48 One approach to queue management is reordering. Such facilities are designed so that the system centre and/or individual banks can reorder the transfers in the queue by changing the original order of receipt or priorities with a view to minimising the number/value of queued transfers. While prioritization facilities allow banks to sequence their transfers before they put them into the system, reordering can be characterised as a facility for managing queues with discretion after the transfers have been placed in the queue. Typically, where reordering is allowed, it can only take the form of moving a payment to the end of the queue or changing its priority code (in both cases the effect being similar to that of cancelling and re-entering the payment). See Box 4 for examples of queue processing and reordering.

Another approach to intervention is to use so-called optimisation routines.49 The term "optimisation" is used in a number of different ways, sometimes even in a broad sense to refer to any form of intervention by the system centre to minimise the number/value of queued transfers. In this report, optimisation routines are more narrowly defined as any pre-specified procedures or algorithms that the system centre can activate to minimise the number/value of queued transfers given available funds at designated times or if gridlock occurs. Optimisation routines typically attempt to settle queued transfers simultaneously rather than settling in sequence as in the case of reordering (see Box 5). As noted earlier, the accumulation of queues or gridlock can occur in a situation where funds transfers cannot be settled in sequence owing to the distribution of liquidity among banks (also sometimes referred to as a "circle situation"), even though overall system liquidity including all queued transfers is sufficient. Optimisation routines may be able to provide an effective solution in such situations, although, as discussed below, they may also have some disadvantages.

Several methods of optimisation have been proposed. In some systems, optimisation will be based on a concept of "simulated net balance" that incorporates the net balance of queued transfers (i.e. queued incoming transfers minus queued outgoing transfers) in addition to the actual cash balance. Such a concept of simulated net balance corresponds to the potential cash flow model of net intraday liquidity in which queued incoming transfers are regarded as "potential cover" for outgoing transfers. In calculating simulated net balances, some systems will also count the net positions (which are not yet settled) in other systems such as securities settlement systems or retail payment systems. An optimisation routine will then attempt to settle as many of the queued transfers as possible subject to the condition that the simulated net balance for every participant is within the limits set (e.g. if it is non-negative). Other systems will apply methods that will not calculate the simulated balance explicitly, but will search for transfers in the queue for which offsetting transfers can be found; for example, the search could be based on a FAFO ("first available, first out") rule whereby the transfer that can find an offsetting transfer or transfers will be executed first.

Revocability of queued transfers. Another important aspect of queuing is whether or not the sending bank can cancel queued transfers. Although end-of-day revocability typically applies automatically in RTGS systems to those transfers that have failed to settle by the close of the system, intraday revocability is in most cases not allowed and in some others is restricted to exceptional circumstances such as input error. However, in SIC and (at a later date) in EIL-ZV the sending bank can revoke queued transfers without the consent of the receiving bank, but in SIC only until a certain cut-off time.

4.2 Issues arising in connection with the transparency of queued incoming transfers

RTGS systems provide online, real-time information facilities whereby banks can obtain data on the status of transfers, accounting balances and other basic parameters. An important element that helps to define the operational environment of queuing is the information available to banks or the system centre with regard to queues. Under centrally located queuing, the system centre normally provides banks with a range of information not only on outgoing transfers in their own queues but also on any incoming transfers being sent to them that are held in other banks’ outgoing queues; indeed, all existing or planned G-10 RTGS systems with centrally located queues allow real-time access to the information on queued incoming transfers in some form or other (in other words, queued incoming transfers are to some degree "transparent"). However, the information about such queued incoming transfers and the conditions under which it is provided to banks vary significantly across systems.

The key issue concerning the transparency of queued incoming transfers is its effect on the risk and efficiency of the process. One view is that transparency could induce the receiving bank to act upon queued incoming transfers which by definition remain unsettled, thereby potentially generating risks in RTGS systems. According to this view, this is another case in which risks may arise from a lag between the time when information about the payment is received and the time when the payment is actually settled. For example, on the assumption that incoming transfers held in other banks’ queues will normally settle in due course, a receiving bank might use the information about these transfers for liquidity management purposes in order to reduce its precautionary balances of liquidity or to minimise the liquidity it needs to raise from other sources; however, if the queued transfers did not in fact settle, the receiving bank could face a liquidity shortfall. Particularly if this occurred close to the end of the day, it might then be difficult for the bank to raise the liquidity it needed from alternative sources. The bank would thus be exposing itself to possible liquidity risk. Perhaps more importantly, the receiving bank might credit its customers’ accounts in advance in anticipation of queued incoming transfers. In this case, credit risk could arise. These risks might also have systemic consequences, particularly if a large number of banks or a major bank with a relatively large amount of queued transfers adopted such behaviour. These possible liquidity, credit and systemic risks are similar in nature to those associated with conditional transfers in unsecured DNS systems and the T-shaped message flow structure described above.

An alternative view stresses the possible advantages of transparency in reducing liquidity risk rather than increasing it. Better information on expected payment flows implies - other things being equal - a smaller probability of a liquidity shortfall. Even after any resulting adjustment of precautionary balances, the net effect of better information might be an overall reduction of liquidity risk. Another possible advantage of transparency could be a reduction in liquidity curves if, as a result of improved information, banks do choose to hold smaller precautionary balances. Greater transparency might also enable banks to sequence incoming and outgoing transfers in a more efficient way, thereby additionally improving their liquidity management. Furthermore, to the extent that banks view the information as important, they might set up their own advice-of-payment arrangements outside the system if the information was not provided within the RTGS system itself.

Others feel that the advantages of transparency can outweigh the disadvantages provided that restrictions are placed on the release of the information. For example, it may be that the more detailed the information (e.g. if it includes beneficiary details), the greater the likelihood that the receiving bank will credit funds in advance. Recognising this, some RTGS systems allow banks to look at aggregated information such as the total number and/or amount of transfers but not at the detail of individual transfers. Another issue relates to the way in which access to the information is granted - more specifically, whether it is released automatically or only on request. Considering that the automatic release of the information might involve greater risks, some RTGS systems provide the information only on request. There is also the view that receiving banks will be discouraged from acting imprudently on incoming queued transfers if sending banks have the ability to cancel such transfers - that is, the sending banks’ ability to cancel will serve as a "warning signal" to the receiving banks, making it less likely that they will place undue reliance on the information. SIC, as noted above, permits the sending bank to cancel queued payment messages at any time up to a certain cut-off time partly on these grounds.

The costs and benefits of information on queued incoming transfers may depend on how important incoming transfers are as a source of intraday liquidity and whether the system typically operates with long queues. If other sources of intraday liquidity are relatively scarce and the queues tend to be long, then the real-time availability of such information may be much more critical to the system’s efficiency. However, at the same time, the longer the queues, the greater the associated risks if banks do not use the information prudently. The usefulness may also depend on the operating environment of the RTGS system, such as the number of participants and the central bank account structure. For instance, under a decentralised central bank account structure, the transparency of the information could in some cases help banks to monitor balances and use them efficiently across accounts.

4.3 Assessments of different approaches to queuing

As noted earlier, different approaches to queuing have been taken in G-10 RTGS systems. The types of centrally located queue range from arrangements in which the system centre actively intervenes in the queues by reordering and/or optimisation, to "no-management" types in which there is no intervention by the system centre or banks. At the other end of the spectrum, there is "fully decentralised" queuing in which the responsibility for queuing is left entirely to individual banks, with the system centre having no queues. There are also a number of hybrid arrangements.

In considering various approaches to queuing, one potentially important aspect is whether the system centre or the individual banks manage the queues. From the viewpoint of reducing the need for liquidity, the more the system centre can intervene in the queues by reordering and/or using optimisation routines, the more efficient the queuing should in principle be because the centre can observe the queued transfers of all banks and thus maximise all available information to rearrange the transfers in the queue into an order that minimises liquidity needs. To the extent that it succeeds in reducing the number and value of queued transfers, such centralised management can contribute to efficiency and the realisation of early settlement in RTGS systems.

At the same time, if centralised management is adopted, several important issues may need to be addressed. First, there could be legal issues: if, for example, some transfer orders were placed lower down in the queue by the centre and then failed to be executed because the sending bank defaulted, the centre might be held liable (e.g. for any consequential damages). Such legal issues may be more acute if the system centre has discretion in its management rather than processing transfers according to an algorithm agreed between the system centre and participating banks. The question is then how easy it is to devise and agree on an appropriate algorithm. Because of this, centrally located queuing arrangements often only process transfers in FIFO order within a given priority. Second, if centralised management is conducted regularly during the day or is expected to occur in certain contingency situations, banks may come to rely on it as an alternative to their own active payment flow or liquidity management. One view is that such "moral hazard" problems could be a particular disadvantage of optimisation routines if the latter induce banks to reduce liquidity holdings, which might lead to longer queues and even increase the potential for gridlock. Third, a balance may need to be struck between the control of the queues by the centre and the scope for competition by banks. Banks may feel that it would be inappropriate for them not to have full control over their queued transfers, not least because from the perspective of individual banks the effectiveness of queue management should be evaluated in terms of how speedily they are able to make transfers relative to other banks. Centralised management could narrow the scope for such competition.

Decentralised approaches to management, whereby banks manage their internal queues or their queues at the centre, can provide banks with greater flexibility in managing their queues and greater scope for competition. However, the use of decentralised management also raises some issues. First, compared with centralised management, decentralised management might be less efficient if each bank had to manage its own queue with insufficient information about what was being held in other banks’ internal queues. Furthermore, aggressive behaviour by banks could increase negative externalities as described earlier, perhaps even leading to settlement delays and gridlocks. Third, there may be complications if the system is "linked" to other settlement systems. For example, if fully decentralised queuing included funds transfers related to a DVP securities settlement system, the requests for those transfers would first have to be routed through the internal systems of the individual banks so that they could manage them. This could affect the efficiency of the DVP process. It may therefore be necessary in the context of decentralised management for system operators and participants to consider these issues and, where appropriate, address them through relevant operating procedures and/or changes to participants’ behaviour.

In practice, the choice regarding queue management techniques may be determined primarily by the system’s technical requirements or by the cost of providing and operating centrally located queues. The choice may also be affected by differing views about the importance of centrally located queuing. On the one hand, the existence of centrally located queuing enables the system to incorporate a system-wide, built-in mechanism for sequencing transfers that could offer "offsetting-like" efficiency. Centrally located queuing could thus be viewed as a critical design feature affecting the efficiency of an RTGS system and could also serve as an important basis for introducing more sophisticated liquidity-saving mechanisms into the architecture of RTGS systems. On the other hand, the existence of centrally located queuing might imply that the system itself potentially encourages settlement lags by allowing "processed but unsettled" payment messages to stay in the system. Some feel that this may not be fully compatible with what they consider to be the core feature of RTGS, namely the ability to provide continuous settlement. According to this line of argument, the responsibility for queuing could be left to banks or the role of centrally located queuing could be marginal even if it is provided.

5. The design of RTGS systems: concluding remarks

As the above analysis has shown, the concept of RTGS is straightforward but the systems themselves can take many different forms. These differences partly reflect the fact that circumstances vary from country to country, so that arrangements that are appropriate for one country may not be relevant for another. In many cases a pragmatic approach has been adopted to certain design features. Finally, as mentioned earlier, RTGS systems are on the whole a relatively recent concept and thus there has often been little operational experience on which to base comparisons between different options.

Given these factors, while it may be difficult to draw any universally applicable conclusions about the merits of particular features of RTGS systems, it might be useful to set out the key criteria that are likely to be used when choosing between different options. Following the presentation of Part II, RTGS systems can be categorised according to three main considerations, namely (a) whether the central bank provides intraday credit to participants in the system and, if so, on what terms, (b) the message flow structure and (c) the facilities, if any, available for queuing. Although there are many other ways in which systems differ, these three areas seem to capture the most important aspects.

Whether intraday credit is provided or not may depend partly on whether interbank funds transfer systems are seen simply as mechanisms that enable settlement to take place, in which case it may be decided that no specific liquidity facilities will be provided, or whether the provision of intraday liquidity is seen as being a straightforward extension of a central bank’s existing role as a provider of liquidity to the banking system. The decision to extend intraday credit may also reflect a view that intraday credit is necessary to enable the system to function smoothly. Where credit is provided, there are variations in the terms set (e.g. whether the credit has to be collateralised and what fee or interest rate, if any, is charged), reflecting a number of important considerations. For example, central banks differ in the way they prefer to manage any risks associated with providing credit. Moreover, in some systems a key consideration may be a desire to keep the cost to banks of obtaining intraday liquidity as low as possible, while in other systems this may be less critical or a positive cost may be seen as a useful way of encouraging banks to economise on their use of any central bank liquidity facility.

As far as the message flow structure is concerned, the key choice is often between the V-shaped and Y-shaped structures, and an important consideration here is the role of the central bank relative to the private sector in the day-to-day operation of the system: for some, the attraction of the Y architecture is that it enables a distinction to be drawn between the central bank’s core role as settlement agent and the rest of the system processing, which can be a separate, private sector function. Whether this is an issue typically depends in part on the nature of the arrangements in place before RTGS was introduced (i.e. the extent to which the central bank was involved in the day-to-day operation of the previous non-RTGS system) and thus on what has come to be regarded as normal or desirable in the market concerned. Other relevant factors may include potential risks associated with the message flow (which is why the T-shaped structure has been criticised) and the design of the existing system (in those cases where the new RTGS system is being adapted from a previous system and thus where particular architectures, such as the L-shaped structure, may be used).

Approaches to queuing may depend importantly on views about the relative roles of the private sector and the central bank, the central bank’s policies regarding the granting of intraday credit and the extent to which banks can obtain liquidity easily from their own sources. If, as noted above, an interbank funds transfer system is seen as being simply a settlement mechanism, then it may also be that no centralised queue management facilities are provided beyond basic FIFO processing. Or the balance between centralised and decentralised queue management may depend on the extent to which banks see such management as a competitive issue rather than one on which they want a standard approach to be adopted. Consideration of the balance to be struck between risk, cost and liquidity may also determine whether queued incoming transfers are transparent or not. More generally, queue management may be an area where the relative novelty of RTGS systems is particularly relevant: key policy considerations apart, differences in queue management techniques may simply reflect the fact that so far there is not enough experience to judge how desirable the different methods are.

Finally, it is important to stress that, in designing an RTGS system, attention must be paid to the wider environment in which the system is to operate. Mention has already been made of the fact that circumstances vary from country to country, and this is true not just of the payment system environment itself but also of the wider financial system: for example, the RTGS system may have to interact with other systems such as securities settlement systems, or its introduction may have some monetary policy implications. Moreover, while RTGS is one approach to managing payment system risks, there are also other approaches such as the introduction of secured DNS systems.

Source: BIS