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. 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 prioritisation 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. 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.

Assumptions. Bank A has a balance of 100. Bank A then sends five outgoing transfer orders in the sequence T1 (value: 40), T2 (70), T3 (20), T4 (30) and T5 (10). For simplicity, no incoming transfers or central bank intraday credit are available during the time under consideration. The processing of the transfers depends on the queuing method used. FIFO: The first transfer order T1 is tested for cover and settled. However, the resulting balance of 60 is insufficient to settle the second transfer T2. Consequently, T2 and all other transfers are queued. (The number of settled transfers is one and the settled value is 40.) Bypass FIFO: T1 is settled (the resulting balance is 60) and T2 is queued exactly as in the case of FIFO. The system will then "bypass" T2 (since it is too large to settle with the remaining balance) and test T3 for cover. Since the balance of 60 is sufficient to settle T3, T3 will be settled (the resulting balance is 40). The system will then return to T2 to test for cover again, but T2 will still not be settled and will continue to be queued. (Note that in this example the balance cannot increase, by assumption. However, if that assumption were relaxed, T2 could be settled if the balance increased to 70 or more by the time of re-testing for cover.) The system will bypass T2 again and test T4 for cover. T4 will be settled and T2 will be re-tested. This iteration process will continue, enabling T5 also to be settled, leaving just T2 in the queue. (The number of settled transfers is four and the settled value is 100.) FIFO with prioritisation: Assume that Bank A can prioritise the transfers according to two priority classes (high and low) at the time of input, with the FIFO rule applying within each priority. Consider three cases: In Case 1, Bank A inputs T2 and T4 into the system as high­priority transfers and inputs the others as low­priority. T1 is settled even though it is low­priority because, being the first payment to be entered into the system, there are no other payments (high or low­priority) queued at that stage. The remaining balance of 60 is insufficient to settle the next payment (T2), which is therefore queued. All remaining payments are therefore also queued because T2 is high­priority: T3 and T5 are low­priority and will therefore not be settled while any high­priority payments are queued, and T4, although also high­priority, is behind T2 in the FIFO high­priority queue. The outcome therefore happens to be the same as with a simple FIFO queue with no priority facility. In Case 2, Bank A inputs T2 as low­priority and all the others as high­priority. Again, T1 settles and T2 is queued, leaving a balance of 60. However, because T2 is low­priority, high­priority payments T3, T4 and T5 will be settled (the balance of 60 being sufficient to do this). In this case, the outcome therefore happens to be the same as with bypass FIFO. In Case 3, T4 is high­priority and the others are all low­priority. Again, T1 settles while T2 is queued because of insufficient funds. Low­priority T3 will then also be queued behind T2, but high­priority T4 (value 30) can be settled with the balance of 60. Low­priority T5 will also be queued behind T2 and T3. This case therefore produces a different outcome.

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.

The following examples attempt to illustrate the essence of how reordering and a type of optimisation mechanism can solve a gridlock. It should be noted that, because the examples are for illustrative purposes, they abstract from some of the complications that may accompany gridlocks in practice. Assumptions. There are three banks, A, B and C, and all have a balance of 100. The following transfers are being held under FIFO queuing. Note that (Tij) indicates the jth transfer being processed by Bank i and "A B 120" means that Bank A will transfer 120 to Bank B. For simplicity, no central bank credit or other liquid funds are available during the time under consideration. Given the balances (100) and the order in which the payments are queued, none of the transfers can settle and the system is thus considered to be in gridlock. Optimisation: Assume that the system can activate a FAFO-type optimisation mechanism. The system will select (TA1) and (TA2) and settle them simultaneously with (TB1). Since Bank B's balance will then become 120 (100 + net transfers from Bank A of 20), transfers (TB2), (TC1) and (TC2) will subsequently be settled without further intervention. Alternatively, assume that the system's optimisation is based on simulated net balances. In this case, the banks' simulated net balances are as follows. Since simulated net balances are non-negative for all banks (i.e. net intraday liquidity including potential cover is sufficient to settle outgoing transfers), all transfers will be settled simultaneously. Reordering: Reordering could also solve this gridlock. Suppose that the system centre switches the order of (TA1) and (TA2). Bank A will now be able to settle (TA2) given its initial balance of 100. Bank B will then be able to settle (TB1) because its balance has increased by the incoming transfer from Bank A (i.e. the new balance = the initial balance of 100 + the incoming transfer from Bank A of 80 = 180). Subsequently, settlement of all the other queued transfers in the system will become possible in the following sequence: Bank A will settle TA1 (120) with the new balance (200 = 20 + 180). Bank B will settle TB2 (120) with the new balance (120 = 0 + 120). Bank C will settle TC1 (120) and TC2 (100) with the new balance (220 = 100 + 120).

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.