Enhanced Batch Processing in RITS – January 2020 3. Description of Batch Functionality

This section provides a high-level description of the RITS batch processing functionality that pertains to both Settlement-only Batches and Reservation Batches.

3.1. What is a Batch in RITS?

A Batch is a group of interbank ESA credits and debits that the Batch Administrator submits to RITS for settlement via one of the two batch settlement processes available in RITS (Settlement-only Batch and Reservation Batch). The group of payment obligations must sum to $0 (i.e., the sum of the debits equals the sum of the credits).

All of the obligations that make up a Batch are settled simultaneously and irrevocably, as credit and debit postings to the ESAs of the Members who are participants in the Batch.

Both batch processing models supported by the RITS batch settlement facility operate on the basis of an ‘all or nothing’ principle: a Batch cannot settle unless all of the payment obligations in the Batch are fully funded.

For Settlement-only Batches, funds availability for all participating Members is checked during settlement testing on the RITS System Queue. Settlement of the Settlement-only Batch can only occur if funds are available for all paying Members participating in the Settlement-only Batch.

For Reservation Batches, funds availability for paying Members participating in a given Reservation Batch is checked at the time of reservation. Reservation can only occur if funds are available for all paying Members participating in the Reservation Batch. Those funds are set aside at the time of reservation. When the Reservation Batch is subsequently placed on the RITS System Queue for settlement testing, it settles almost instantaneously as the funds required from paying Members have been reserved previously.

In both batch processing models, if a batch is recalled, none of the payments in the batch is settled. Multiple batches can be settled in one day.

3.2. Batch Stream

The enhanced batch processing facility has the capacity to accept and process batches from a number of upstream businesses. Each upstream business that is channelled into RITS by a Batch Administrator is termed a Batch Stream.

A Batch Stream is defined in RITS in such a way that batches in the stream are processed independently of other Batch Streams and other transactions, and RITS business rules can be independently applied to each stream.

Each Batch Stream is identified in RITS by a four-character alphanumeric Batch Stream ID. This Batch Stream ID is used to identify batches in the enquiry function in RITS and in reports.

In defining the Batch Stream, the RITS System Administrator records the details of the Batch Administrator, the type of batch (central party or multilateral; see below) and the name of the central party, if applicable, as well as session eligibility for batches.

3.3. The Batch Administrator submits the Batch

The Batch Administrator is the party that sends Batches for a given Batch Stream to RITS to settle. The Batch Administrator must be a Member. The Batch Administrator sends Batch information to RITS, in the form of a message appropriate to the batch process used, which contains the net interbank obligation for each Member participating in the Batch. Depending on the business arrangements for each Batch, these figures are submitted to RITS by the Batch Administrator as either a central party or multilateral batch (see below).

3.4. Who can participate in a Batch

The group of Members that the Batch Administrator has assessed as eligible to participate in its service offering, and thus to be paying or receiving participants in Batches submitted to RITS, constitute a Closed User Group. Only the Members that have been set up by the RBA in RITS as members of the Closed User Group can participate in the Batches submitted by the Batch Administrator for a particular Batch Stream.

Not all financial institutions that might participate in a Batch's Upstream Business are Members. Interbank settlement in RITS only occurs across ESAs – and so the interbank payment obligations that make up a Batch, which are sent to RITS for settlement together as a Batch, can only involve Members. For a financial institution that does not have (or chooses not to use) an ESA to participate in the Batch, its net obligation would be included in the position of a Member with which the financial institution has an appropriate arrangement in order for the amount to be settled across ESAs in RITS.

The RBA maintains a list of Members in RITS.

RITS ensures that only transactions of institutions in the relevant Closed User Group can be entered into RITS via a Batch.

3.5. Multilateral and central party Batches

Both multilateral and central party batches can be processed in RITS. A Batch Administrator for a Batch Stream must elect to use one of these two methods. A Settlement-only Batch can be defined as either a multilateral or central-party batch. Reservation Batches can only be multilateral batches.

If a central party is used, the Batch Administrator provides details of the central party in RITS when the Batch Stream is defined. The central party must hold an ESA. In a Settlement-only Batch that requires a central party, the individual Batch settlement instructions are between the central party and each participating Member. In a Settlement-only Batch or Reservation Batch that does not use a central party, individual payment obligations occur between the participating Members and the ‘system’: this is a multilateral Batch. When a Batch is submitted, RITS extracts payment details and constructs the individual settlement instructions.

3.6. Data entry conventions

Members may wish to be advised by RITS when a batch has settled. RITS will show no record in User Interface (UI) enquiries, and the Post-Settlement Advice (over the AIF) will not be generated, for a Member that is not included in the Batch message.

To generate a record in the enquiry functions in RITS and to trigger a Post-Settlement Advice, the following entry conventions will need to be applied by the Batch Administrator:

  • $0.00 to be entered for a Batch Participant if its net position in the Upstream Business nets to zero; and
  • for non-zero net amounts in the Batch, that amount is entered.
  • no entry is to be performed for Batch Participants that have no position (intra- or inter-bank) in the Upstream Business and therefore are not participants in that Batch.

3.7. Zero sum

The amounts submitted for a Batch must sum to zero. Batches that do not sum to zero are rejected by RITS.

3.8. How Batches arrive at RITS

The Batch Administrator submits the Settlement-only Batch via a SWIFT message, or enters it directly into RITS via the RITS User Interface.

Requests relating to Reservation Batches are submitted by the Batch Administrator to RITS as XML-formatted messages transferred in a file over the Community of Interest Network (COIN).[1] It is possible to send many requests in a single file, though each file may contain only one type of request. Each request message within a file concerns a single Reservation Batch.

In a contingency affecting file transfers via the COIN, the Batch Administrator may upload request files into RITS via the RITS User Interface and may manually request, via the RITS User Interface, that one or more batches in a status of reserved be settled.

3.9. Validation on entry to RITS

Batches are validated against message content and business rules when they are received by RITS.

An error in a Reservation Batch or a message-entered Settlement-only Batch is indicated to the Batch Administrator in the response message, which contains an appropriate reject code.

For Settlement-only Batches entered in RITS directly via the User Interface, errors are indicated on screen and RITS will not accept the Batch until corrections have been made.

Batches are again validated against the session access rules when received by the RITS System Queue for settlement testing.

3.10. No warehoused Batches

Batches must be submitted to RITS on the day of settlement. Batches submitted for other settlement dates are rejected by RITS.

3.11. Batch Identification Number

Each individual batch is given a Batch Identification Number (BIN). It is the responsibility of the Batch Administrator to generate BINs.

The BIN is a 16-character alphanumeric value. The first 4 characters must be the Batch Stream ID and the last 12 characters are a free-form identifier for the particular Batch.

RITS validates the BIN to ensure that it is unique within the last 14 days.

If RITS identifies a non-unique BIN, the batch is rejected.

3.12. Access to RITS

The terms of access to RITS for Batches from a particular Batch Stream must be agreed with the RBA.

If a Batch arrives at RITS during a session in which it is not eligible to settle, it will be rejected. There is an exception to this rule: if a Settlement-only Batch that is defined as ineligible for settlement in the Morning Settlement Session (i.e. from 7:30am – 8:45am) arrives at RITS during this session, it will not be rejected, but will be queued for settlement testing in the Daily Settlement Session.

Any Batches that remain unsettled on the RITS System Queue at the end of the processing day for that Batch Stream (which may vary, depending on agreed access for that Batch Stream) will be removed. Reservation Batches for which a Settlement Request has not been received by end-of-day are ‘unwound’, meaning funds reserved in the ESAs are released and are no longer set aside to be used for Reservation Batches.

Batches received by RITS outside the agreed hours are rejected.

3.13. Processing on the RITS System Queue

All of the necessary message format and business validations are completed before the Batch is passed to the RITS System Queue for settlement testing.

However, on arrival at the RITS System Queue, the Batch is validated again in case some of the parameters used to initially validate the payments have changed. All transactions in the Batch are tested and if one transaction cannot be funded, the Batch is rejected. A response message is generated with the relevant reject code for transmission to the Batch Administrator.

If the Batch type is ‘central party’, transactions are two-sided and the central party is automatically made the counterparty in all of the transactions in the Batch.

If the Batch type is ‘multilateral’, there is no counterparty and individual obligations are against the system.

For Settlement-only Batches the RITS System Queue applies default ESA, Credit, and Cash Account statuses set by Members in RITS. For Reservation Batches the RITS System Queue always applies ESA, Credit and Cash Account status of Priority.

Pre-Settlement Advices (MT198 SMT028, MT198 SMT029 and MT198 SMT 041) are generated for individual transactions if requested by a participant Member (regardless of the Batch type, i.e., Reservation or Settlement-only). A central party may elect to receive these advices. For details about these Advices, see RITS/SWIFT Interface User Guide.

For Settlement-only Batches when all transactions in the batch have Active or Priority ESA, Credit, and Cash Account statuses the RITS System Queue tests each payment against the Cash Account Sub-limit or Limit and the ESA Sub-limit and Limit. For Reservation Batches, the RITS System Queue settles the transactions using previously reserved funds.

All transactions that make up a specific Batch are tested as a group. If one transaction is not able to settle, then the entire Batch cannot settle. If all transactions pass settlement testing, all transactions are settled simultaneously. For Reservation Batches, settlement is almost instantaneous due to prior reservation of funds.

Upon settlement, the ESAs of all participating Members are updated.

If selected by a participant Member, Post-Settlement Advices (MT198 SMT036 and MT198 SMT037) are generated for individual transactions (regardless of the Batch type, (i.e., Reservation or Settlement-only). For details about these Advices, see the RITS/SWIFT Interface User Guide.

3.14. Enquiring on Batch and payment status

The Batch Administrator can obtain status updates on Batch progress by using enquiry functions accessible in the RITS User Interface. For further information on enquiry functions, see the Batch Administrator User Guide.

Settlement-only and Reservation Batch data submitted to RITS by the Batch Administrator are available via the RITS User Interface for the current day and the last five business days.

The Batch Administrator can view details of all data the Batch Administrator has entered and Members can view their own transactions. Batch Administrators do not have access to information concerning an individual Member participant's ESA balance.

Member participants can enquire on their own payments in the RITS User Interface. Once the Batch has been sent to the RITS System Queue, payments are also displayed in the queued transactions enquiry functions available to Members.

Depending on the Member's settings, they can receive updates by AIF message, for example, the Post-Settlement Advice.

3.15. Reports

Reports are available to the Batch Administrator and participant Members.

For the Batch Administrator:

  • The RITS Member Report ‘Batch Administrator Transactions Enquiry Report’ shows the transactions in the Batch and the status for each Batch entered by the Batch Administrator.
  • The ‘Batch Feeder Audit Report’ tracks user actions in relation to Settlement-only Batches (but not Reservation Batches).

For participant Members:

  • The RITS Member Report ‘Batch Participant Transactions Enquiry Report’ shows details of the participant's transaction in each Batch.

Endnote

Community of Interest Network (COIN) is a network for secure transmission of payments files and messages between payment participants. The COIN is administered by the Australian Payments Clearing Association (APCA). [1]