The Role of RITS in Supporting Settlement in a Tokenised Ecosystem 4. How RITS and FSS could support at-par exchange of private tokenised money

RITS plays a foundational role in supporting the exchangeability of private money at par in Australia by providing for settlement in central bank reserves. This underpins confidence in private money and the singleness of money, allowing different forms of private money (e.g. deposits at different commercial banks) to be converted on a one-to-one basis. Private money exchange can occur as part of asset settlement, or as a stand-alone exchange.

Tokenised forms of private money (e.g. stablecoins and commercial bank deposit tokens) issued by a range of financial institutions are emerging alongside traditional commercial bank money held in deposit accounts. Efficient mechanisms for conversion and exchange between these forms of money will be important to support the singleness of money and the ability of different forms of private money to be exchanged at par value, reducing the risk of fragmented liquidity across separate payment and settlement ecosystems.

As with existing payment arrangements, settlement in central bank reserves will continue to play a fundamental role. This chapter examines how existing RITS and FSS functionality could support at-par conversion between commercial bank deposits and tokenised private money, as well as exchange between tokenised private money issued by different institutions. Drawing on learnings from Project Acacia and relevant international developments, it explores how current RITS and FSS capabilities could be adapted to support these arrangements. Figure 4 summarises the options explored in this chapter.

A range of exchange models may emerge over time. The consultation does not propose or seek feedback on specific solutions. Rather, it considers how RITS and/or the FSS could support different models and use cases should they develop. While many use cases remain at an early stage of development, respondents are encouraged to consider how requirements may evolve if tokenised forms of private money become more widely used.

4.1 Findings from Project Acacia

Several use cases in Project Acacia examined exchange models, with settlement supported by central bank reserves. This included the conversion between traditional commercial bank deposits and private tokenised money, as well as the exchange of tokenised private money issued by different institutions.

4.1.1 Conversion between traditional commercial bank deposits and tokenised private money

AP+ considered how the purchase of a stablecoin or deposit token could be funded from an NPP-connected bank account, and later redeemed back into a bank account, using the 24/7, real-time payment capability of the NPP. The design involved two legs: payments of traditional commercial bank money held in deposit accounts processed via the NPP and settled through the FSS, and token operations (minting, burning or transfer) on a tokenised platform. A synchronisation operator (provided by Swift) coordinated the two legs. While the use case did not identify any required changes to FSS functionality, exploration was limited to a conceptual desktop exercise and no testing was conducted.

4.1.2 Exchange between different forms of tokenised private money

Several Project Acacia use cases demonstrated exchange between private money tokens, with central bank reserves serving as the common settlement asset. While these use cases used pilot tokenised central bank reserves issued for the purposes of the project, several participants noted that existing ESA balances could perform a similar role.

• In the ANZ and Fireblocks use cases, a payer’s private money tokens were redeemed by the issuer. The issuer (or its settlement agent) then made an interbank transfer in central bank reserves to the issuer of the payee’s preferred private money tokens (or that issuer’s settlement agent). Upon receipt of the reserves, the receiving issuer issued corresponding private money tokens to the payee. CBA demonstrated a similar model in a repo transaction, with one counterparty holding central bank reserves rather than privately issued tokens.²³
• AP+ created and managed digital twin representations of central bank reserves on a public tokenised platform to facilitate settlement through an industry-wide exchange utility.²⁴ A synchronisation coordinator kept the digital twins and actual central bank reserve holdings aligned by updating each when changes occurred.

4.2 Simple exchange models

Some exchange models could rely on a simple payment process that closely mirrors today’s account-to-account payment arrangements. Under the current model, where a customer of Bank A wishes to pay a customer of Bank B, Bank A debits the payer’s account and makes an interbank payment to Bank B, which subsequently credits the payee’s account on its own books.

In a tokenised money environment, where customers hold deposit tokens issued by their bank rather than balances in traditional deposit accounts, a similar process could be followed. Bank A would redeem or burn the payer’s deposit tokens and make an interbank payment to Bank B via RITS or the FSS. Upon receipt of the interbank payment, Bank B would issue its own deposit tokens to the payee customer. The interbank settlement instruction could be sent to RITS or the FSS using existing methods, such as the Swift PDS, NPP or BECS.²⁵

4.3 Exchange models with synchronisation

4.3.1 Synchronisation models

Other private money exchange models may require a more complex orchestration, with synchronisation between the various elements of the exchange to ensure that they occur simultaneously or are tightly coupled, such that no part completes without the other parts also completing. An example could be where one bank is buying stablecoins from another bank using its ESA balances. In this case, the bank buying stablecoins would want to ensure that it makes the interbank cash settlement if, and only if, it is certain that it will receive the stablecoins (and vice versa). Furthermore, the various elements of the exchange may also need to be synchronised as part of an asset settlement, which would involve additional orchestration with required actions on the asset platform.

Synchronised exchanges could be designed in a variety of ways to serve different use cases. Similar to the DvP models described in Chapter 3, there are three broad approaches to synchronising interbank settlement with the other actions required to complete an exchange:

1. Locking the private money tokens. Under this model, private money tokens are locked on external tokenised money platforms. Resulting obligations between issuers (or their settlement agents) then settle in the interbank settlement system. Once settlement has been confirmed, the tokenised money platforms release, transfer, issue or redeem the money tokens as required to complete exchange. This is analogous to DvP settlement models using an asset-lock mechanism (see Chapter 3).
2. Locking of central bank reserves. Under this model, the first step is to lock reserves in the interbank settlement system. The required token transfers, issuances or redemptions are then executed on the relevant tokenised money platforms. Once these actions are completed, the reserved funds are released to complete the interbank settlement. This is a similar concept to the reservation of funds for asset settlement, like in the e-conveyancing settlement model currently supported by RITS (see Chapters 2 and 3).

3. Locking of both tokens and central bank reserves. Under this model, the tokens are locked on the tokenised money platform and corresponding funds are locked in the interbank settlement system. Once both locks have been established, the token transfers and interbank settlement are completed in a coordinated manner, such that they occur simultaneously or near simultaneously. In RITS, this model could be achieved by combining an external token locking mechanism with the RITS reservation batch functionality.

   This approach is similar to existing and experimental arrangements for payment-versus-payment (PvP) settlement of FX transactions, where funds are committed or reserved prior to coordinated settlement. For example, CLS requires participants to pre-fund their net short currency positions in central bank reserves before those balances are used for settlement of individual FX transactions across CLS’s books, effectively committing the funds needed to complete settlement. The Bank of International Settlements (BIS) Innovation Hub’s Project Meridian FX explored the synchronisation of interbank settlement systems for PvP settlement by reserving funds in each system and settling both sides in a coordinated manner.²⁶

4.3.2 Synchronisation providers

For exchange models that require synchronisation and locking of either tokenised money or central bank reserves, the synchronisation role (whether limited to orchestrating participants’ actions or extending to directly initiating locking and settlement actions) could be performed by a range of entities. One option may be for individual institutions to orchestrate exchange between themselves and submit any required settlement instructions to RITS or the FSS. Based on the evidence in Project Acacia and international models, however, a model using a central synchronisation operator, which can support multilateral exchange between tokenised money from a range of issuers, is likely to emerge. There are two options for this central synchronisation operator:

• Third party platform. Under this model, an independent intermediary coordinates the sequencing and synchronisation of the stages involved in money exchange between participants. The synchronisation operator may have different levels of involvement in the settlement process. At one end of the spectrum, it may act solely as a neutral coordination layer that orchestrates settlement actions across the interbank settlement system and tokenised money platforms, without itself becoming a settlement venue. This approach is demonstrated in initiatives like Project Meridian FX and the AP+ use case in Project Acacia.

  In other models, the intermediary may perform additional roles. In the Swift DLT platform (currently a minimum viable product), obligations accruing from token exchange are recorded on the Swift DLT ledger, with Swift periodically requesting participants to submit net interbank obligations to the interbank settlement system. CLS represents a model where the third-party intermediary performs settlement functions on its own platform or books, in addition to coordinating payments.²⁷

• Central bank platform. As an alternative to a third-party, synchronisation services could be provided by the central bank. An example of this approach is the HKMA’s RTGS pilot solution as part of Project Ensemble, which provides an interoperability layer between commercial bank deposit tokens and the interbank settlement system (see Appendix B).

4.3.3 Options for submitting instructions to RITS

The options and considerations for submitting reservation or settlement instructions to RITS or the FSS for the purpose of facilitating exchange are similar to those discussed for the synchronisation of DvP asset settlement in Chapter 3. The information, connectivity and messaging considerations outlined in Chapter 3 are also relevant in this context. See Sections 3.3 to 3.5 for details.

4.4 DLT exchange models

Exchange could also occur directly on a tokenised platform using a tokenised exchange asset that is issued by a private entity and fully backed by central bank reserves, similar to the approach demonstrated in the AP+ token exchange pilot.²⁸ To support this model, the central bank reserves backing the tokenised exchange asset would need to be segregated from the issuer’s other reserve holdings (e.g. through an escrow or dedicated settlement account arrangement). A synchronisation mechanism would also be required to maintain alignment between the quantity of the exchange asset on the tokenised platform and the underlying central bank reserves. RITS does not currently provide this functionality.