Reform of the Payments System A Proposal for Implementing Real Time Gross Settlement in Australia

April 1995

The Reserve Bank is exploring with banks the option of moving directly to a real-time gross settlement (RTGS) system. The Reserve Bank's reasons for favouring RTGS over the alternative of a deferred net settlement system are set out in a companion paper.

This paper looks at how such an RTGS system could be implemented. It is being circulated as a basis for discussion with banks, other market participants, and APCA. The paper is in two parts. The first outlines changes to the Reserve Bank's market operations which would be required to support the operation of an RTGS system. These are substantial, but the Reserve Bank believes it would be necessary to make these changes in order to achieve its goals for payments system reform. The second part of the paper outlines the way in which payments would be processed in the RTGS system and how this could be achieved.

The proposed system builds on the existing electronic systems for managing exchange settlement accounts (RITS), and is intended to be introduced in stages which would adapt the existing system to the more stringent requirements of fully-fledged RTGS. The system the Reserve Bank is investigating would form the core of the payments system, and would be complemented by development of existing or new payment delivery systems by the banking industry.

I RTGS AND THE RESERVE BANK'S MARKET OPERATIONS

Impact of RTGS

The implementation of RTGS would impact on the way the money market works and, therefore, the environment in which the Reserve Bank conducts its domestic market operations.

Under RTGS, payments would be settled across exchange settlement (ES) accounts as they are made. This has two important implications for market operations. First, unlike now, the Reserve Bank would not know at the start of each day the exact size of the shortage or surplus of funds for the day. (This is known currently because of the one-day lag in settlements.) The Reserve Bank would forecast the daily shortage or surplus of funds on the basis of regular government payments and tax collections but this would be less accurate than the present system allows. On the occasions when the forecast did not meet the required degree of accuracy, the Reserve Bank would need to deal more than once a day if market pressures turn out to be different from expectations.

Second, the distinction between same-day and next-day funds, central to the present system, disappears with RTGS. The market would no longer be able to use next-day funds to balance the supply of and demand for liquidity on a day. Given that the market accesses next-day funds through the authorised money market dealers, it follows that authorised dealers would no longer have any special role in balancing the supply and demand for cash. Also, dealers would have no special role as repositories for banks' ES funds, as banks would have equal access to their funds no matter to whom they lend — the special role of dealers at present, stems from their ability to transfer funds to and from banks on a same-day basis, but under RTGS this is true for all parties.

Under RTGS, there probably will be a need for banks to make more use of “safety valves”, because the system will not be able to take advantage of the float opportunities provided by next-day funds. The extent of use of the “safety valves” would depend on the relative cost of funds obtained in this way compared to the cost of maintaining larger buffer balances of ES funds. The next section outlines the Reserve Bank's proposal for an additional “safety valve” to augment the existing one provided by the Treasury Note rediscount facility.

Market operations under RTGS

Proposed changes to procedures for market operations to address the implications of RTGS are as follows:

(a) Arrangements for banks' settlement funds

The present requirement that banks maintain their ES accounts in credit at all times would be retained under a RTGS system. It would defeat the aim of the RTGS reform if banks were allowed to overdraw these accounts.

The aim would be to have banks hold a buffer of settlement funds in their ES accounts, on which they could draw instantly to make payments. Specifically, the proposal envisages that funds currently held as banks' loans to authorised short-term money market dealers would be held in ES accounts. The Reserve Bank would propose paying interest on balances in ES accounts at the cash rate it announces from time to time.

The supply of ES balances would continue to be controlled by the Reserve Bank through its domestic market operations, and would be adjusted to generate the desired outcome for market interest rates. It is envisaged that overnight funds in the market would trade at an interest rate marginally higher than the rate the Reserve Bank pays on ES balances (in the same way as there is now a difference between the official and unofficial cash rates).

(b) Dealing counterparties and processes

With RTGS, dealing with banks or non-banks would be equally as effective in influencing banks' exchange settlement balances. The Reserve Bank would therefore propose to deal, for liquidity management purposes, with all RITS members. To smooth the transition process, this broadening of dealing counterparties beyond the authorised money market dealers would take place ahead of the scheduled introduction of RTGS.

It should be possible to preserve much of the present timing of the Reserve Bank's daily operations. At 9.30 in the morning, the Bank would publish the system cash figure. Unlike now, where this is a firm number, the figure published would be an estimate based on the Reserve Bank's forecast for tax collections and Government payments. At the same time, the Reserve Bank would announce its dealing intentions in the way it does now. Counterparties would be asked to submit bids/offers by 10.00 am, and the Reserve Bank would then process these in the form of mini auctions (as now). The aggregate volume of funds transacted at these auctions would be decided by the Reserve Bank; as is the case now, there would be no guarantee to offset fully the market position.

On most days one round of dealing should suffice – small discrepancies between the forecast and actual cash position which emerged later in the day would be absorbed in the balances in banks' exchange settlement accounts at the end of the day. In the event of a major discrepancy, as can occur sometimes because of unscheduled Government payments or tax collections, the Reserve Bank would engage in a second round of dealing. This would be undertaken at 3.00 pm, by which time a good reading of the day's likely outcomes should be possible. The Reserve Bank would publish a revised system cash figure at that time.

(c) Dealing instruments

There would be no need under these new arrangements to make any changes to the instruments in which the Reserve Bank deals. It would continue to deal in CGS up to one year to maturity.

(d) Safety valves

It is proposed to retain the existing Treasury Note rediscount facility. Recent changes to the penalty arrangements for this facility, which cap the penalty at a cost equivalent to that on 7-day Treasury notes, make the facility more accessible.

In addition, it is proposed to introduce a new facility whereby the Reserve Bank would respond to requests to provide intra-day funds by means of repurchase agreements. The cost of these funds would incorporate a penalty, the existence of which should encourage the growth of the interbank market, and ensure that the Reserve Bank window was a “second” resort.

II. HOW PAYMENTS WOULD BE PROCESSED UNDER RTGS

The Reserve Bank already operates, as part of the Reserve Bank Information and Transfer System (RITS), an electronic system for the real-time management of exchange settlement (ES) balances. All ES transfers are made in this system, and the paying bank must have the funds before a transfer will be effected. RITS is therefore already an RTGS system for ES cash transfers; it is, however, on a small scale because few transactions are settled using ES funds under present market conventions.

Implementing a fully-fledged RTGS system based on RITS would involve changing payment conventions so that a much greater range of transactions are settled using ES funds. In addition, RITS would need to be upgraded to give it the capacity to handle the necessary volume of transactions and to ensure that the levels of security meet the required standards for such systems. Existing RITS procedures for cash transfers, which require that the transfer details be entered by both parties and matched before execution, would be inefficient when trying to cope with a substantial increase in transaction volumes. Some enhancements to RITS functions for queueing and reporting would also be appropriate.

Preliminary investigation points to development costs which are much less than those which were identified for PRESS. The proposed system would use the existing RITS infrastructure, which is already a real-time system for ES funds transfers, and the costs of developing the additional queueing and reporting features would be small. The main costs of establishing the proposed RTGS system would be in improving capacity and backup (especially establishing a secondary site) and in enhancing security on RITS. There would, of course, also be costs involved in modifying BITS and individual banks' proprietary systems, which would require modification to work with the proposed RTGS system.

Key features of the system being proposed by the Reserve Bank are outlined in the following paragraphs.

Payment processing

High-value payments would be settled across ES accounts as they are being made. There are two broad categories of payments:

  • Bank-initiated payments. With these payments, the paying bank would initiate a transfer of ES funds to another bank. This message would include both the payment instruction and relevant customer information. RITS would process the payment transfer if the paying bank has sufficient ES funds; if not, the payment would be queued. Processing would involve debiting the paying bank's ES account and crediting the receiving bank's ES account by the amount of the payment. Customer details and confirmation of payment would be passed to the receiving bank.
  • Customer-initiated payments (eg purchase of bonds by a non-bank member of RITS). As happens now, these payments would first be tested against the cash limit which the customer's bank has set within the RITS system. If the payment passed this test, it would then be tested against the bank's ES account balance. If it passed the customer limit and if the bank had sufficient ES funds, the payment would be processed. If either test failed, the payment would be queued. (See below for more details on queue management.)

    When the payment is processed, the customer's cash account in RITS would be debited and the paying bank's ES account would be debited by the amount of the payment. Corresponding credits would be made to the receiving bank's ES account and the receiving customer's RITS cash account. Where securities are involved, ownership of the securities would be transferred simultaneously with the cash — ie DvP will be provided.

Limits and queue management

Limits

In the Reserve Bank's proposal, banks will set limits on the use of cash by their customers in the system, which may permit their customers to use overdraft funds, and the system would ensure that these customers' RITS cash accounts remained within these limits. Banks would themselves have limits set on their ES accounts by the Reserve Bank at zero — ie ES accounts would not be able to be overdrawn. This is essentially how RITS operates now.

To provide members with an additional degree of control over their use of limits, the system would allow customers to set a sub-limit. The sub-limit would have to be within the limit set by the member's bank.

As an example of how the sub-limit might be used, a member with a limit of $20 million might be required to make a payment of $50 million in half an hour. Thus, by this time it would need to acquire a credit balance of $30 million, but in the interim it may want to allow any payments that would not compromise this objective to pass through the system. This could be achieved by setting a sub-limit at Credit $30 million — this would prevent any payment that would take its RITS cash account balance below a credit balance of $30 million, but would allow other payments to proceed. Once the $50 million payment was processed, the sub-limit could be re-set to Debit $20 million — the same as the overdraft limit.

A bank might also use the sub-limit if it wished to ensure that its ES account remained in credit at a particular level, eg if it wished to reserve ES funds for a particular purpose later in the day.

Queue management

When a payment instruction is accepted by the system, it would be placed in the system queue. Payments in the queue would be ordered in a first in, first out (FIFO) basis. Securities transactions would be added to the queue in the order they were matched, or when the securities became available to the seller if that occurs later. Payments in the queue would be processed automatically, without need for further action by the member.

Although payments would be queued on a FIFO basis, members would have some power to override the order in which their own payments settle, by assigning transactions a status of “active”, “pending”, or “priority”. Assigning a status of “pending” would defer processing. Assigning a status of “priority” would make the system ignore any sub-limit and test the transaction directly against the member's main limit — this would be used to put through payments for which funds were being reserved using the sub-limit facility.

It should be noted that if a customer payment passed the customer limit test but the customer's bank assigned a “pending” status to the associated transfer of ES funds, the payment could not proceed until the status was changed by the bank. Members would be able to choose which status would be used as default for their payments, and banks would be able to choose which status level would be used as a default for the ES transfers arising from customer payments.

Security

The central core for the system would consist of RITS running at an upgraded DEC-based site. RITS terminals would be upgraded to provide for enhanced security appropriate to the core of the payments system. A capability would also be provided for sending cash payments (with associated customer information) on a one-sided basis — ie without the need for both sides of the transaction to enter details. (Securities settlements would continue to require matching of details input by both parties to the transaction.)

The proposed security regime would conform to the PRESS/PDS Security Working Group standards. This approach would involve hardware encryption and a form of digital signature. Key exchange would be automated. All third party payments would be subject to this security regime.

Any interface to banks' proprietary payments processors (PPPs) would be established at a basic level, to reduce both complexity and cost, while still meeting anticipated business needs. For example, it is not envisaged that the interface be complicated by handling a wide range of commands and enquiries — the PPP interface would receive payment messages from the PPP and would advise the PPP of payment messages received and of changes to the status of payment messages sent. Other enquiries could be handled directly through a RITS terminal. Over time, and if there were a need, there would be scope for expanding the functionality of the interface.

Disaster Recovery/Business Resumption

RITS would continue to be based on DEC hardware and Oracle software. The hardware would be upgraded.

The central site would operate through two geographically-remote sites linked by dual optic fibre. There would be two computers at the prime site and one at the back-up site, with the discs (and therefore the databases) across all machines synchronised in real time. In the unlikely event that both prime site machines were to become inoperable, the back-up site would be available immediately.

It is proposed that each upgraded RITS terminal would have a database synchronised with the central site. In the event of any disturbance, the databases would automatically check for discrepancies. Any adjustments required would be advised to the user of the terminal for authorisation before execution.

Banks could have upgraded RITS terminals as back-up if they wish. Alternatively, each Reserve Bank branch would have facilities available that may be used by a bank if needed for back-up.

Links to other clearing or payment delivery systems

While the RTGS system would eventually process all high-value payments in real time, payments taking place through the low-value clearing streams — cheques, direct entry, EFTPOS, etc — would still be settled in multilateral net batches. This would mirror the settlement of overnight obligations under present arrangements, but involve much smaller aggregate values.

Participating banks due to pay funds arising from a multilateral batch would have to ensure that adequate funds are available. They would be advised of the amount due ahead of settlement time. They may then set a sub-limit with a credit balance high enough to ensure that the multilateral batch can proceed. At settlement time, the system would test each transaction in the batch against each bank's limit (not the sub-limits — the transactions would be treated as having “priority” status).

It is important to note that the part of the system which the Reserve Bank proposes to build does not provide a fully-featured payment delivery mechanism. It would have facilities for delivering high-value payments which may be adequate for those banks with lower volumes of payments to use as a payment delivery system. Others — particularly larger banks — may want to have more elaborate delivery arrangements. Any such arrangements would be required to meet the standards adopted for the RTGS system, including being able to interface to the RTGS system in real time, but other design features and operational matters would be for the industry to determine.

Connections with the existing Austraclear and BITS systems are especially important. The Reserve Bank and participants in the securities markets see considerable potential benefit in integrating the securities settlement operations of RITS with the Austraclear securities settlement system (Fintracs); accordingly, the Reserve Bank is discussing this potential integration with Austraclear. While this appears attractive, the use of RITS as a platform for the RTGS system is not dependent on such an integration. If integration does not occur, Austraclear settlements would be passed through the RTGS system in the same way as all other high-value payments.

For BITS transactions, a transition period is envisaged during which they could continue to be settled on a deferred net basis. It would be necessary, however, to bring these net settlement forward from next day to same day; BITS member banks may want to arrange frequent within-day settlements to assist their management of liquidity once other payments are moved to RTGS. It is expected that each BITS payment would be routed to the RTGS system for real-time processing by mid 1997.

Both prudential and liquidity management considerations also indicate that bank warrants and other high-value paper transactions would need to be moved to the RITS system as soon as feasible.

Implementation schedule

If it is decided to go ahead after consultation with the industry is completed, the Reserve Bank would propose to implement the move to RTGS in stages. The following table gives an outline of the main steps involved and an indicative timing for each step. Precise timings will be finalised after discussions with banks and other participants.

Until changes in market operations and ES account arrangements would be introduced in mid 1996, the Reserve Bank would maintain in full its existing facilities for authorised short-term money market dealers and continue to support the authorised dealers through those arrangements.

Reserve Bank of Australia
April 1995

Indicative timing Upgrading of RITS Market arrangements Securities settlements BITS settlement Other high value payments Low-value clearing streams
From now   Banks can make ES payments using RITS     Warrants, etc now issued manually can be migrated to RITS whenever banks are ready Will continue to enter RITS multilateral net batches next morning
June 1995     Decision whether integration of RITS and Fintracs will proceed      
September 1995 Full specifications released for upgraded RITS software          
December 1995 Full specifications released for upgraded RITS terminal and interface          
March 1996   Reserve Bank widens dealing to RITS members        
June 1996 RITS hardware enhanced Interest paid on ES accounts        
July – September 1996 RITS software upgraded   Fintracs activities migrated to RITS (if merger proceeds)      
September 1996   Intraday liquidity arrangements introduced Earliest possible date for RTGS for RITS transactions Earliest possible date for within-day batch settlement across ES accounts    
December 1996 Upgraded terminal linkage to RITS available

Backup enhanced
         
December 1996 – March 1997 Testing of upgraded terminal linkage and interface to banks proprietary systems       Remaining warrants and high-value customer cheques migrated to RITS, BITS or new electronic system  
March 1997     Final date for cutover to RTGS Final date for cutover to RTGS Final date for cutover to RTGS