SWIFT for CBDC

SWIFT for CBDC

There is a growing momentum towards exploring Central Bank Digital Currencies (CBDCs) amongst central banks globally. A recent report from the Bank for International Settlements (BIS) observed that nine out of 10 central banks are now exploring CBDCs – covering economies that account for more than 90% of global GDP. An increasing number of these central banks are in the advanced stages of exploration, with nine countries already live with their own digital currency, most notably Nigeria and The Bahamas. Others meanwhile are researching, developing and experimenting as they seek to understand and make design choices for future CBDCs.

Swift’s Phase 1 experiments (2021)

Swift has completed two experiments for models 1 and 2.

Experiment A1: Value transfer between traditional payments system to CBDC system:

The objective of this was to test and showcase Swift’s ability to use innovative DLT features to orchestrate a cross-border transaction between two entities on two different networks:  a traditional payment system (e.g. an RTGS system) and a DLT-based CBDC system. Using a settler on the DLT network, funds were locked until settlement was on the DLT. Transaction settlement was triggered by a successful transfer of funds on the traditional payment system. In doing so, the technology eliminates counterparty risk, exposure of default by the involved parties, and a third-party escrow.

Experiment A2: Value transfer between two CBDC systems, orchestrated by Swift

The objective of this was to test and showcase how a cross-border transaction between two parties on different DLT networks could rely on Swift’s ability to orchestrate a cross- border, multi-currency transaction through the correspondent banking system, by using an HTLC model to execute value transfer between two DLT networks

Swift’s Phase 2 experiments (2022)

Based on the first phase of experiments, Swift wanted to explore, namely:

Rich data and standards — The ability to carry data about the payment in a standardised form, which can be readily understood and reported is crucial, and ISO 20022,

Digital identity — If fraud is to be combated, then secure identity is crucial.

Core payment system requirements — The core requirements (fraud prevention, Know Your Customer (KYC), Anti-Money laundering (AML), security, integrity, transparency, data privacy, and, internationally at least, Financial Action Task Force (FATF) recommendations and sanctions screening of a payment will need to apply. Interoperability and integration within domestic infrastructure. CBDC-based systems must co-exist and be integrated with other payment systems. This is a vital part of making different forms of money useful in practice.

– Implementation generality Ensuring simplicity in effort for various network providers regardless of technology choices. The solution is to be agnostic to technology and processing rules.

As part of these experiments, Swift wanted to ensure the following:

– Use of ISO 20022 standards to communicate between gateway connectors attached to the CBDC network. The gateway will convert to protocol required by the local CBDC network.

 – Use of Swift PKI to enable interoperability trust between networks.

– Network operators to implement the rulebook/policy and adaptors to communicate with their network; and provide that implementation as a pluggable module to the gateway to conduct the local orchestration.

– The Connector Gateway is run and operated by the network operator. Network operators can implement the message processing rules per the policy of their network, thus keeping the knowledge of processing cross-border payment messages local to their network and in their control within the network. This approach encapsulates how a cross- border payment needs to be initiated from the sender of the payment.

-Smart contracts developed by the network operators will be used for payment   execution, as defined by the rulebook implementation, thus hiding the local tricaines from the initiator of the payment.

– Payment orchestration within a CBDC network will be executed using innovative technology chosen by the CBDC network. Swift will play no role in intra-CBDC orchestration.

Solving the interlinking challenge

The goal is to ensure seamless cross-border interlinking between various CBDC and RTGS networks. While CBDC networks will be implemented by each CBDC network operator, to demonstrate the concept, Swift built a reference implementation based on the following components:

– CBDC Networks: The solution consists of two simulated CBDC networks, one implemented on R3 Corda, and another on Quorum. CBDC network regulators will run and govern a “trusted DLT node” created as part of Swift’s solution.

– RTGS Simulator: As the adoption of CBDCs will be gradual, Swift assumes that it will be necessary to transact between a traditional RTGS and CBDC network – and thus simulated an RTGS environment for this case.

– Swift CBDC Connector Gateway: A CBDC Connector Gateway was built to facilitate seamless interactions between various networks via the Swift platform simulator. This gateway acts as a standardised interface for all traffic between the CBDC network and the Swift platform simulator, a single entry and exit point for cross- border payments to and from the CBDC network. The gateway is run on a regulator node, and provides

the flexibility for network operators to implement their connection to the gateway, based on their specific network design, - including flexibility around smart contract protocols, conditional payment protocols, messaging formats, etc. While the network operators would be required to implement this adaptor, the gateway would provide a seamless linking with the rest of the Swift ecosystem, including the Swift platform simulator and its associated value-added services, such as the use of the Unique End-to-end Transaction Reference (UETR) to track an entire transaction. Note that in addition to the DLT-based CBDC networks connected here, the Connector Gateway could also be implemented in non-DLT technology based CBDC solutions.

– Swift platform simulator: The fundamental premise of Swift’s transaction management vision is that it allows interoperability between different standards, channels, protocols and across currencies, while embedding adjacent services to make the payment safe, secure, and complete. In order to leverage these capabilities, a simulator of the platform was used, which adds the potential for extensibility of value-added services, such as KYC, AML, security, integrity, transparency, sanctions screening, etc

Experiment Scenario 1: CBDC-to-CBDC This experiment took advantage of the innovative capability of DLT networks for intra-DLT transactions, in which the Swift platform simulator and Swift Gateway are leveraged to enable interlinking. To achieve this, Swift implemented a standard escrow mechanism to prevent double spend.

The experiment flow is depicted here in 10 steps:

1. Debtor Corp submits a credit transfer request to Bank A

 2. Bank A initiates the credit transfer by creating a payment message and makes a call to the Swift platform to identify the cross-border payment route. The message follows the ISO 20022 format and is signed using Swift’s PKI-based encryption. The signed message is then sent to Intermediary A using a messaging smart contract.

3. Intermediary A then sends a payment message to Intermediary B by using the messaging smart contract. The Regulator Node of Country A intercepts the message and forwards it to Country A’s Swift CBDC Connector Gateway (Swift Gateway).

4. Country A’s Swift Gateway then sends the message to the Swift platform which identifies the corresponding Swift Gateway in Country B to receive the payment instruction.

5. Country B’s Swift Gateway then converts the ISO 20022 message into the local DLT format and executes the messaging smart contract with Intermediary B.

6. Now Intermediary B creates a conditional payment for Bank B by escrowing the tokens with the Regulator Node. The funds will not be released until the Regulator Node in Country B receives a release funds notification from Intermediary A

7. Next, Intermediary B sends the payment message to Bank B using the messaging smart contract

8. Bank B then sends the message acknowledgement to Intermediary B using the messaging smart contract. Intermediary B performs the same action to inform Intermediary A via the Regulator Node.

9. Intermediary A then receives the notification of the creation of a conditional payment smart contract via the Swift Gateway, and the Swift platform. Intermediary A then settles by updating the nostro account for Intermediary B. Intermediary A sends a release funds notification using the messaging smart contract to the Regulator Node.

10. Country A’s Regulator Node then sends the release funds notification to the Regulator Node in Country B via the Swift Gateway and Swift platform. The conditional payment smart contract is executed, and the funds are released to Bank B, and ultimately sent to Creditor Corp.

This experiment shows the following:

1 Payment path: Sender Bank made a call to the Swift platform simulator, which was able to identify the cross-border payment path.

2 Payment execution: The CBDCnetwork was able to transfer messages from one node to another with the help of the node address.

3 Messaging: The ISO 20022 message format can be used for communication.

4 Transaction status: The Swift Gateway has the capability to propagate the transaction status within the DLT to the tracker so that the global status of the transaction can be ascertained at any time. The network should provide the cross- border transaction message and status to the gateway. In addition, many exception use cases were tested. For example, exception at creditor agent; exception at debtor agent; exception when payment initiated by Creditor Corp; Credit reversal (crediting back to debtor), etc.

Experiment Scenario 2:  Fiat-to-CBDC

This experiment explored fiat to CBDC payment transactions, in which a regulator node was used to validate payment notifications from fiat to CBDC. This experiment took advantage of the innovative capability of DLT networks for intra- DLT transactions, leveraging the Swift platform simulator and Swift Gateway.  The experiment flow is depicted here:

1. Debtor Corp submits a credit transfer request to Bank A.

2. Bank A initiates the credit transfer by creating a payment message and makes a call to the Swift platform to identify the cross-border payment route. The message follows the ISO 20022 format and is signed following PKI- based encryption.

3. The signed message is then sent to Intermediary A via the Swift platform. The Swift platform provides payment orchestration within the RTGS side.

4. Intermediary A then sends the message to Intermediary B via the Swift platform.

5. The Swift platform identifies the corresponding Swift Gateway in Country B to receive the payment instruction.

 6. Country B’s Swift Gateway then converts the ISO 20022 message into the local DLT format and executes the messaging smart contract with Intermediary B. 7. Now Intermediary B creates a conditional payment for Bank B by escrowing the tokens with the Regulator Node. The funds will not be released until the Regulator Node in Country B receives a release funds notification from Intermediary A 8. Next, Intermediary B sends the payment message to Bank B using the messaging smart contract.

 9. Bank B sends the message acknowledgement to the Intermediary B using the messaging smart contract. Intermediary B will perform the same to inform Intermediary A via the Regulator Node.

 10. Intermediary A receives the notification of the conditional payment smart contract creation via the Swift Gateway and Swift platform. Intermediary A settles by updating the nostro account for Intermediary B. Intermediary A then sends a release funds notification via the Swift platform

11. The release funds notification is received by the Regulator Node in Country B via the Swift Gateway. The conditional payment smart contract is executed and the funds are released to Bank B, and ultimately sent to Creditor Corp.

This experiment shows the following:

1 Payment path: Sender Bank made a call to the Swift platform simulator to identify cross-border payment path.

2 Smart-contract execution: Once the Regulator Node receives payment confirmation from the fiat side, a smart contract was auto-executed to move the fund.

3 Messaging: The ISO 20022 message format can be used for communication.

4 Transaction status: The Swift platform simulator continues pulling the current payment status. This payment status is made available to all banks through the Swift platform simulator API calls.

 Conclusion and next steps

With the Phase 2 experiments proving to be successful, Swift has demonstrated the technical feasibility of our CBDC interlinking solution – using standards and using a gateway in each network, which greatly simplifies interlinking CBDCs with other financial networks. It provides a highly scalable solution that solves the ‘one-to-many’ challenge not addressed by bilateral connectivity, while more closely replicating the flows familiar to commercial banks from established cross-border payments.

Incorporating multiple blockchain technologies, the sandbox not only provides the ability for bilateral testing, but also facilitates real-time feedback opportunities for our customers to share their challenges with Swift and contribute to the next generation of CBDC solutions. Swift plans to use this feedback to shape our strategic approach for digital currencies moving forward, providing valuable solutions for the entire Swift community.

                       **********************************************

Source: Swift.com