The Role of RITS in Supporting Settlement in a Tokenised Ecosystem 6. Tokenised reserves

Beyond synchronisation with traditional interbank settlement systems, Project Acacia also explored the use of tokenised central bank reserves (referred to in Project Acacia as wholesale central bank digital currency, or wCBDC) to support settlement in tokenised asset markets and exchange between forms of tokenised private money. Other central banks are similarly exploring tokenised reserves as an alternative or complement to synchronisation approaches. Compared with synchronised settlement models, tokenised reserves could potentially unlock additional benefits from tokenisation on a 24/7 basis, including enhanced programmability and composability of payments, and atomic settlement.

Depending on the enhancements required to enable current RITS or FSS services to support tokenisation use cases, the international experience suggests that it may be some time before formal decisions on the issuance of tokenised reserves are taken, and that in the interim, synchronisation-based approaches may be a more incremental way for tokenisation activity to gather momentum.

This chapter seeks to explore key design considerations for the issuance of tokenised reserves and how they could interact with existing RITS or FSS services and infrastructure, and ESA balances. Many of these design choices involve trade-offs between interoperability, liquidity management, operational resilience, access arrangements and implementation complexity. The considerations outlined below are intended to help identify which outcomes are most important to respondents, rather than to propose a preferred model.

6.1 Token issuance

There are a range of design considerations relating to the issuance of tokens representing central bank reserves.

6.1.1 Digital twin or digitally native tokens

One design choice is whether tokenised reserves would be structured as digital twins of existing balances or as digitally native reserves. Under a digital twin model, tokens represent a claim on reserves held within an existing RBA account structure. One implication of a digital twin model is the need to ensure ongoing two-way synchronisation between tokenised reserves and the underlying account balances.

Under a digitally native model, tokenised reserves would constitute a direct liability of the RBA, which could be separate from existing ESA arrangements.³⁹ A digitally native approach could offer greater flexibility in access arrangements, as eligible participants could potentially hold tokenised reserves without maintaining an ESA. It could also increase operational resilience by providing an alternative settlement service to RITS and the FSS. Depending on where it is issued, however (on an RBA-controlled or third-party platform, as discussed below) digitally native reserves may not overcome the need for synchronisation.

6.1.2 RBA-controlled or third-party platform

Another design choice is whether tokenised reserves are issued on an RBA-operated platform or on third-party platforms. The former approach was explored in the CBDC Pilot, while the latter (which has been less commonly used in international experimentation) was examined in Project Acacia.

An RBA-operated platform could provide a high degree of control over issuance, governance and settlement processes. However, if the platform operates independently of tokenised asset platforms, the benefits of tokenised reserves may be relatively constrained. In particular, settlement may still need to be synchronised across platforms, potentially reducing the opportunities that tokenised reserves could provide for atomic settlement, programmability and composability.

Tokenised reserves issued on an RBA-operated platform could be connected to external networks through bridging arrangements. This may preserve a centralised issuance model while improving access to multiple networks and enabling a greater degree of interoperability with asset platforms to support the benefits of tokenisation. However, it would require decisions about which networks can connect to the RBA platform, the rules governing those connections, and mechanisms to synchronise activity between the RBA-operated platform and external networks. It may also result in liquidity being distributed across multiple platforms, and introduce additional operational, governance and oversight considerations associated with the external networks and interoperability arrangements.

Issuance directly onto third-party platforms would enable tokenised reserves to reside on the same platforms as tokenised assets, readily supporting atomic settlement and enabling greater programmability and composability of payments. Similar to the bridging option, however, it would also distribute liquidity across multiple platforms, and require decisions about which networks are eligible to support final settlement in tokenised central bank reserves. As settlement would occur on infrastructure outside the RBA’s direct control, the RBA would need to establish sufficient assurance that the third-party platforms can consistently satisfy settlement integrity requirements, potentially necessitating a higher level of controls, monitoring and oversight.

6.1.3 Single-tier or two-tier distribution

A further consideration is the distribution model. Under a single-tier model, the RBA would issue tokenised reserves directly to eligible holders only, similar to current ESA arrangements. These eligible holders would use their tokenised reserves, while their customers continue to use (traditional or tokenised) commercial bank money.

Under a two-tier distribution model, the RBA would issue tokenised reserves to approved intermediaries, which would then distribute them to other eligible participants. This approach may be more scalable where there are larger numbers of tokenised reserve holders and was the model adopted in both the CBDC Pilot and Project Acacia. However, it would introduce an additional layer of intermediation, potentially increasing operational complexity and creating dependencies on intermediary arrangements.

6.2 Integration with ESAs

There are a range of considerations regarding how tokenised reserves would interoperate with RITS to prevent the fragmentation of liquidity, ensure there are efficient ways of allocating liquidity between different forms of central bank reserves, and enable entities to manage their total central bank reserves balance.

6.2.1 Funding and defunding tokenised reserves

Tokenised reserves could be funded and defunded through ESAs. In a digitally native model, funding would involve debiting a participant’s ESA balance and issuing an equivalent value of tokenised reserves (and defunding would involve redeeming tokenised reserves and crediting the participant’s ESA balance). Alternatively, tokenised reserves could be funded directly, for example, through transactions with the RBA settling in tokenised reserves. Direct funding would be required under a model in which participants who are permitted to hold tokenised reserves are not required to maintain an ESA balance.

In a digital twin model, funding tokenised reserves would require the segregation of ESA balances corresponding to the amount tokenised. This could be achieved, for example, through a reservation mechanism or by transferring reserves to a separate account held by the participant. Once the underlying reserves have been set aside, an equivalent value of tokenised reserves would be issued to represent those segregated balances.

6.2.2 Visibility and allocation of liquidity

Effective liquidity management across ESA balances and tokenised reserve balances will depend on participants having visibility of both individual balances and aggregate available liquidity across the two environments. This functionality could be provided within RITS or through a separate liquidity management solution integrated with RITS.

Effective liquidity management will also depend on mechanisms that enable the efficient allocation and transfer of liquidity between ESA balances and tokenised reserves. It will be important to consider whether tokenised reserve liquidity management, especially issuance and redemption of tokenised reserves, needs to be available on a 24/7 basis to match the operating hours of the tokenised platform. In addition, a liquidity management capability, similar to the existing RITS/FSS liquidity allocation arrangements, could use configurable thresholds and triggers to rebalance funds between the two environments. This would help ensure liquidity is available where needed, while reducing the need to maintain separate liquidity buffers across settlement environments. This capability could be more readily incorporated into RITS where tokenised reserves are issued on an RBA-operated platform. Automating rebalancing processes where tokenised reserves are issued on a third-party platform may give rise to additional operational, technical and governance considerations.