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. Part III therefore looks at some of these wider issues concerning RTGS.