The Role of RITS in Supporting Settlement in a Tokenised Ecosystem 3. How RITS or FSS could support cash settlement in tokenised wholesale asset markets

A foundational mechanism in wholesale asset markets is DvP, which links the transfer of an asset with the corresponding transfer of funds, thereby eliminating principal risk.¹⁸ RITS provides central bank reserves settlement for the interbank cash leg of DvP arrangements used in a range of Australian asset markets.

Importantly, the role of RITS in DvP is limited to the interbank cash settlement leg. It enables funds to be transferred between participating financial institutions conditional on the corresponding asset movement occurring in external asset registries and market infrastructures. However, RITS does not govern the end-to-end transaction or the sourcing or allocation of funds from or to customer accounts. Financial institutions and custodians remain responsible for posting, reconciling and maintaining the corresponding debits and credits in their clients’ accounts. Some payment scheme rules, such as the NPP, require funds to be made available to customers within a specified time.

Several key Australian market infrastructures use current RITS functionality to settle the interbank cash leg in central bank reserves as part of broader DvP arrangements. These include Austraclear for debt securities, CHESS for equities, and property settlement platforms such as PEXA and Sympli.

This chapter considers how existing RITS and FSS functionality can be applied to support DvP settlement (at the interbank level) of tokenised wholesale assets. It draws on learnings from Project Acacia, examines relevant international models, and explores how current capabilities could be adapted to enable settlement in a tokenised environment. Figure 2 summarises the options explored in this chapter.

3.1 Findings from Project Acacia

Two proofs of concept in Project Acacia investigated how existing RITS and the FSS functionality could support DvP settlement of tokenised assets. Neither identified changes to the current functionality; however, the proofs of concept did not involve testing in a RITS or FSS environment.

Northern Trust: This use case explored DvP settlement of tokenised carbon credits, with the asset leg recorded on a Northern Trust-operated tokenised platform and the interbank cash leg represented as settling in RITS via the Swift PDS feeder. DvP was coordinated by Swift acting as an orchestration layer: first sending an instruction to the asset platform to ‘lock’ or earmark assets (represented by tokens); then to the buyer bank to initiate the interbank cash leg in RITS; and finally (upon confirmation of RITS settlement) to the asset platform to complete the transfer of the asset to the buyer. Swift messages were used with minor adaptations to incorporate transaction identifiers, token references, and details of the asset wallets involved to enable pairing and coordination.

Westpac: This use case demonstrated how the NPP’s PayTo service could support DvP settlement of tokenised asset trades, with real-time cash settlement occurring in the FSS. DvP orchestration was undertaken by the asset platform, which initiated a PayTo request-to-pay message to the buyer’s bank. The buyer’s bank then initiated an NPP payment to the seller’s bank.¹⁹ The asset platform was notified once the NPP payment had settled through the FSS, which triggered the transfer of ownership of the tokenised asset to the buyer.

3.2 DvP synchronisation

3.2.1 DvP synchronisation models

Where assets and central bank reserves reside on separate platforms, a mechanism is required to synchronise the interbank cash and asset legs of a transaction so they are tightly coupled, ensuring that DvP (at the interbank level) is achieved and neither leg can complete without the other.

The effectiveness of any synchronisation arrangement will depend not only on operational processes, but also on the legal framework supporting settlement finality and the enforceability of transactions. Where tokenised asset platforms, synchronisation operators and central bank settlement services interact, stakeholders may wish to consider how responsibilities are allocated between parties and how confidence in final settlement outcomes can be maintained across the different platforms involved.

There are three broad types of synchronisation model that rely on interbank settlement in central bank reserves (Figure 3).

1. Asset lock. The asset is locked on the asset platform, the interbank cash leg is settled through the interbank settlement system, and the asset is transferred only after settlement across the interbank settlement system is confirmed. This model is widely used in existing market infrastructures, including Austraclear and CHESS for debt and equity settlement respectively. Within Project Acacia, this approach was applied in both the Westpac and Northern Trust use cases, demonstrating that it could potentially be supported by both the RITS System Queue and the FSS.

   Asset locks are also used in some of the international models exploring DvP settlement of tokenised assets through traditional payment systems. This includes the Banca d’Italia TIPS Hash-Link and the Swiss National Bank’s (SNB) Project Helvetia, which both rely on the locking of assets on a tokenised platform and the subsequent completion of the asset transfer following confirmation of settlement in central bank reserves (see Appendix B).

2. Central bank reserves lock. This model locks central bank reserves first (such that they cannot be used for other transactions), transfers the asset, then settles the reserves. It relies on a locking mechanism on the interbank settlement platform, rather than on the asset platform. While not explored in Project Acacia use cases, it is currently used by PEXA and Sympli for interbank settlement arising from property transactions settled in their electronic conveyancing platforms.

   The reserves locking approach is particularly suited to e-conveyancing platforms as they operate across multiple asset registries that do not have asset lock mechanisms, and property settlements usually involve several banks. The reserves locking model addresses this complexity by securing all required ESA funds upfront before proceeding with lodgement and settlement. The high-level flow is as follows:

   • The e-conveyancing platform submits a reservation batch to RITS to reserve funds in the ESAs of all banks with a net payment obligation in a given property transaction. If sufficient funds are available, they are reserved in the ESAs and can only be used for reservation transactions.
   • The e-conveyancing platform lodges the registry instruments with the relevant land registry.
   • Once lodgement is confirmed, the e-conveyancing platform submits a settlement request to RITS, and settlement occurs immediately using the reserved funds. If lodgement fails, the reservation can be cancelled, and the reserved funds released.

   Currently, reserves locking capability is available on the RITS System Queue only, and not on the FSS.

3. Asset and central bank reserves lock. A more advanced design would enable the locking of assets and central bank reserves, and then settling both legs simultaneously (or near simultaneously). Ensuring that both assets and reserves are available before proceeding with settlement provides additional confidence that settlement will complete as intended. Locking both legs also supports more complex transaction scenarios involving multiple assets and multiple paying institutions. This model is being considered in some international initiatives, including the Bank of England’s (BoE) Synchronisation Operator and the Bundesbank’s Trigger Solution (see Appendix B). While not tested in Project Acacia, this model could be achieved using an asset lock mechanism combined with the RITS reservation batch functionality.

The above models all assume that DvP at the interbank level would be achieved through real-time settlement in central bank reserves. A fourth option, which is explored, for example, by the Hong Kong Monetary Authority’s (HKMA) Project Ensemble, is for DvP settlement to occur on-chain in commercial bank deposit tokens, with only exchange between different banks’ deposit tokens being settled in the interbank settlement system (see Chapter 4 for a discussion of exchange).

3.2.2 Synchronisation providers

DvP synchronisation models rely on having a synchronisation operator – an entity that coordinates, or synchronises, the steps required to achieve DvP settlement. Depending on the design of the synchronisation arrangement, the synchronisation operator may simply coordinate participants’ settlement actions or, alternatively, have authority to perform certain locking and settlement actions on participants’ behalf.

Under any of the models, the synchronisation operator role could be performed by a range of different entities.

• Asset platform. Under this model, the asset platform acts as the DvP synchronisation operator. It is the model used by both Austraclear and CHESS today, with the asset platforms on which bonds and equities reside, respectively, coordinating the sequencing and conditional execution of the asset and interbank cash settlement legs. In Project Acacia, Westpac’s use case demonstrated asset platform-led orchestration for tokenised asset settlement. A similar approach is being explored in the SNB’s Project Helvetia (see Appendix B).

• Third-party provider. Under this model, a separate intermediary coordinates the sequencing of asset transfer and interbank cash settlement. PEXA and Sympli are examples of this approach in Australia. While operating independently of the underlying land or asset registries, they play a central coordinating role by managing lodgement workflows and synchronising property transfers with the settlement of interbank obligations in RITS.

  In Project Acacia, Northern Trust used a similar model, with Swift coordinating the sequence of steps to lock a tokenised asset, initiate interbank cash settlement in RITS, and then trigger the asset transfer. Westpac also observed that the synchronisation functions demonstrated in its Project Acacia use case could be performed by third-party providers, such as Swift or decentralised networks like Chainlink. A payment scheme operator could also act in a coordinating role. A similar third-party synchronisation model is being explored by the BoE through its proposed Synchronisation Operator (Appendix B).

• Central bank platform. A third alternative, not explored in Project Acacia, would be for the RBA to provide an orchestration layer that helps to synchronise settlement between external tokenised asset platforms and central bank reserves. The Bundesbank Trigger Solution and Banca d’Italia’s TIPS Hash-Link pilot relied on central bank-built infrastructure to help coordinate DvP settlement for tokenised asset platforms (see Appendix B).

3.3 Options for submitting synchronisation instructions to RITS or the FSS

Facilitating synchronised settlement requires an arrangement to submit settlement-related instructions to RITS or the FSS. Asset platforms and third-party synchronisation providers could potentially use existing feeder systems, batches or the LVSS, or consider a new feeder system. A range of factors may influence the suitability of a particular submission model. These include the settlement model being supported (e.g. RTGS, batch settlement, locking requirements), operating hours and liquidity requirements, participant access arrangements, and whether settlement instructions are submitted by participants themselves or by the synchronisation service on their behalf (i.e. whether the synchronisation operator can directly initiate locking and settlement actions or merely coordinates those actions). In addition to these model-specific considerations, synchronisation operators may wish to consider broader issues relating to connectivity, messaging, governance and operational resilience.

The following sections outline the principal options for submitting synchronisation instructions to RITS or the FSS and provide high-level information to support consideration of the factors that may influence the choice of model. Further details are in Chapter 2 and Appendix A.

3.3.1 Payment clearing system model

Under this model, synchronised settlement is supported using an existing payment clearing system connected to RITS or the FSS. In Project Acacia, the Northern Trust and Westpac proofs of concept explored the use of existing feeder systems (Swift PDS and NPP respectively) to support settlement on an RTGS basis. Under this model, the synchronisation operator would coordinate DvP settlement, but participants in the transaction would submit their own settlement instructions to RITS or the FSS and subsequently confirm settlement to the synchronisation operator. The key characteristics of the model are:

• Settlement. Both the Swift PDS (settling on the RITS System Queue) and the NPP (settling via the FSS) enable interbank settlement on an RTGS basis through existing payment system infrastructure. However, they do not support DvP models requiring the reservation of ESA funds.
• Operating hours. The NPP operates 24/7 whereas the Swift PDS is largely confined to RITS business hours. Access to after-hours liquidity is a consideration when using the NPP.²⁰
• Instruction origination. Instructions to RITS or the FSS would be sent by the participants in the synchronisation operator (or their settlement agents) rather than by the synchronisation operator itself.
• Participant access requirements. Participants in the synchronisation operator need to be members of the clearing system (i.e. the HVCS if using the Swift PDS, or the NPP) and ESA holders, or appoint a settlement agent.
• Synchronisation operator role. The synchronisation operator would coordinate DvP settlement but would not directly submit settlement instructions to RITS or the FSS. If the NPP is used, the synchronisation operator may consider becoming (or having a commercial relationship with) an NPP Connected Institution, which connects to the NPP infrastructure directly and can send payment initiation instructions to NPP participants to process payments.
• Control, governance and resilience. This model relies on the governance arrangements, participation requirements, operating rules, technology infrastructure and future development priorities of the relevant payment clearing system. This may reduce the operational burden on the synchronisation operator by leveraging established infrastructure but may also limit its control over participant access, new functionality or system changes, as these would be partly dependent upon the clearing systems.

3.3.2 Batch model

Under this model, a synchronisation operator could connect to RITS as a batch administrator, to submit multilaterally netted settlement obligations on behalf of its participants. This can include settlement-only batches or reservation batches. The synchronisation operator would need to apply to the RBA to become a batch administrator and meet a range of governance, legal and operational requirements.²¹

• Settlement model. This model supports multilateral net settlement, and DvP models requiring reservation of ESA funds. Reservation batches involving only two financial institutions could effectively be used for RTGS with reservation of ESA funds. Batches operate on the RITS System Queue only and are not currently supported on the FSS.
• Operating hours. Operation is largely confined to business hours. Settlement-only batches are tested for settlement at pre-specified times, whereas reservation batches are tested continually throughout the business day.
• Instruction origination. Settlement instructions are generated and sent to RITS by the synchronisation operator on behalf of its participants (or their settlement agents).
• Participant access requirements. Participants in the synchronisation operator would not need to join a separate clearing system but must hold an ESA (or appoint a settlement agent).
• Synchronisation operator role. The synchronisation operator would coordinate DvP settlement. It would also net obligations and submit settlement instructions to RITS on behalf of participants.
• Control, governance and resilience. This model provides the synchronisation operator with significant flexibility to design participant access, netting, reservation and settlement arrangements, and to evolve the service independently of a separate payment system. However, responsibility for operational resilience, governance and ongoing service operation would also primarily rest with the synchronisation operator.

3.3.3 LVSS

A synchronisation operator or its participants could submit settlement instructions to the RITS System Queue via the LVSS. The key characteristics of this model are:

• Settlement model. Transactions are tested for settlement on the RITS System Queue, either individually or as a multilateral group.
• Operating hours. Individual transactions are tested for settlement during RITS business hours. Multilateral grouped transactions are tested for settlement during the six multilateral group runs per day, with the first occurring at approximately 9am, and the last at approximately 9pm.
• Instruction origination. Settlement instructions may be submitted by the participants in the synchronisation operator (or by their settlement agents). Alternatively, the synchronisation operator could act as an LVSS agent, submitting settlement instructions on its participants’ behalf.
• Participant access requirements. Participants in the synchronisation operator would need to hold an ESA (or appoint a settlement agent). In models where participants submit instructions, they also need to become members of the LVSS and join the COIN or Swift FileAct service.
• Synchronisation operator role. The synchronisation operator would coordinate DvP settlement and may also act as LVSS agent to submit settlement instructions on behalf of participants. In the latter case, the synchronisation operator would need to join the LVSS, as well as the COIN or Swift FileAct service.
• Control, governance and resilience. The synchronisation operator would have flexibility over the design of its own participant access and orchestration arrangements, and be responsible for operational resilience, governance and ongoing operation of its service.

3.3.4 New feeder

If existing feeder systems, batches and the LVSS cannot support a synchronisation service, and cannot be readily enhanced to do so, a synchronisation operator could consider establishing a new feeder system that submits instructions to the RITS System Queue or the FSS. This could involve:

• Adapting the RTGS feeder built for CHESS. This may be suitable for feeder systems that wish to settle on an RTGS basis via the RITS System Queue, with the synchronisation operator submitting settlement instructions on behalf of participants. Similar to the existing arrangements for batch administrators, this option would give the synchronisation operator control over settlement design, participant access arrangements and future functionality of their feeder systems, but would also require them to meet operational resilience, change management, connectivity and compliance-related RBA requirements. It would also require RITS to establish an RTGS feeder interface independent of CHESS.
• New feeder built to submit instructions to the RITS System Queue or the FSS. This would require development in RITS or the FSS to build a new interface and connectivity to enable the receipt and processing of messages from the new feeder, as well as the provision of relevant acknowledgements, status updates and settlement notifications.

The eligibility, legal and operational requirements for a new feeder system would be assessed by the RBA on a case-by-case basis. As a minimum, a prospective feeder operator would be expected to demonstrate appropriate business rules, legal and operational arrangements, contingency and business continuity arrangements, financial and operational capacity, and the integrity and organisational capability necessary to operate its service.

3.4 Information and notifications from RITS

RITS and the FSS provide participants, feeder system operators and batch administrators (as relevant) with information relating to the status and outcome of instructions. Depending on the submission method used, this may include settlement confirmations, queue status information, reservation status information and batch settlement outcomes (see Chapter 2 and Appendix A for further details). Existing notifications may be sufficient, or enhancements may be required to support synchronised settlement of tokenised asset transactions.

3.5 Messaging and connectivity considerations

Existing feeder systems, batch arrangements and the LVSS rely on established connectivity and messaging frameworks to exchange payment, settlement, reservation and batch instructions, as well as settlement confirmations and status information. As outlined in Chapter 2, current RITS arrangements use a range of messaging standards, including ISO 20022 messages and proprietary XML-based message formats for various settlement streams. Connectivity is provided through a variety of network channels, including Swift network services and the COIN. Further details of existing connectivity and messaging arrangements are provided in Appendix A.

While existing arrangements may be sufficient for many synchronisation use cases, some may require enhancements, which could include, for example:

• Standardising networks and messaging formats. Respondents may wish to consider whether greater standardisation of networks/connectivity and messaging arrangements would simplify integration and reduce complexity.
• Additional connectivity options. For example, Application Programming Interfaces (APIs) could complement existing messaging arrangements, by supporting real-time submission of instructions, status enquiries and event notifications.²² API functionality is not currently available in RITS.