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.

Systems with:	Centrally located queue	No centrally located queue
Central bank intraday credit	ELLIPS (Belgium) TBF (France)1 EIL-ZV (Germany) BI-REL (Italy)1 TOP (Netherlands)1 RIX (Sweden)2	CHAPS (UK)3 Fedwire (USA)
No central bank intraday credit	SIC (Switzerland)	BOJ-NET (Japan)
1  Under development. 2  Centrally located queuing is being designed. 3  See footnote 26.

The comparative table in Annex 1 also highlights some key differences other than intraday liquidity facilities and queuing arrangements, which could have important implications for the working of the RTGS system.

1. Ownership and access policies. Most systems are owned by central banks. ELLIPS and CHAPS are owned by an association or a company whose members are the direct participants and the central bank; the systems are connected to the central bank's internal real­time accounting system. Access policies also differ. In principle, direct access to RTGS systems requires participants to hold their accounts at the central bank, which may raise issues regarding the conditions under which participants can hold central bank accounts. In the majority of systems direct access is open to all banks (or credit institutions or depository institutions as applicable). Additional criteria such as financial strength and technical requirements are applied in several systems. In the European Union the central banks have agreed that, with limited exceptions, direct access should be confined to credit institutions. Partly reflecting the differing access policies, the number of direct participants varies across systems; some systems have large numbers of direct participants, whereas other systems are two­tiered systems with a more limited number of direct settlement members, although indirect participation in the system can be wide.

2. Message flow structures. The majority of systems are based on so­called V­shaped structures, whereas others use Y­shaped or L­shaped structures. Section II.3 discusses message flow structures in more detail.

3. Reserve requirements and central bank account structures. Countries vary in the extent to which required reserves are imposed and are available for use as intraday liquidity in the RTGS system. Central bank account structures also vary in terms of whether the RTGS accounts are separated from the accounts used for required reserves or other purposes (i.e. unified or segregated accounts) and whether banks can hold RTGS accounts at more than one office of the central bank (i.e. centralised or decentralised accounts). Section II.2 discusses these variations in more detail.

4. Relationships with other systems. In Germany, Japan and the United States, RTGS systems coexist with net settlement systems for large­value transfers, and this will also be the case in France. In other countries RTGS systems are or will be the only large­value funds transfer system. RTGS systems are also used for the settlement of retail payments in various ways and in several countries RTGS systems support real­time DVP systems for securities transactions.