Swift

Solutions Providers

There are a few reasons why SWIFT is investing resources in exploring crosschain interoperability:

Enabling existing infrastructure for new assets: SWIFT's existing network and messaging standards are deeply embedded in the financial system. By adapting them/ISO 15022/ISO 20022 to support tokenised assets on blockchains, SWIFT could allow its members to leverage their existing infrastructure and capabilities for new digital asset use cases. This would provide a smooth transition path.
Interoperability between traditional and blockchain systems: A key challenge is connecting traditional financial systems with emerging blockchain networks in a standardized way. By participating in industry initiatives and by developing solutions like the Swift SDK and CBDC connector, SWIFT aims to provide interoperability and make it easier for institutions to interact with various blockchains.
Remain relevant in the evolving landscape: As blockchain technology and digital assets continue maturing, SWIFT risks becoming less relevant if it does not adapt. By investing in this space, SWIFT can retain its central position in global financial messaging and settlement. It allows members to benefit from innovation while leveraging trusted infrastructure.
Alignment with member needs: Major SWIFT members like banks and central banks are exploring use cases for blockchain and CBDCs. By developing solutions tailored to their needs, SWIFT ensures its network evolves with member requirements.
Industry standards and collaboration: SWIFT is collaborating with stakeholders to develop industry standards and frameworks for blockchain interoperability. Given its central role, SWIFT can help drive common standards to benefit the wider financial ecosystem.

In summary, SWIFT intends to retain its relevance while meeting member needs and shaping the responsible evolution of the financial system as new technologies emerge.

1. Problems/Challenges it aims to solve

The aim is to enable financial institutions to use their existing back-end systems to interact with tokenised assets and transact across both public and private blockchains platforms. A key challenge is creating an approach to interoperability across multiple blockchains that leverages market participants' existing Swift capabilities and new open interoperability standards. The goal is for Swift to support members in re-using their existing Swift infrastructure as a single entry-point to the public and private blockchain networks needed to transact tokenised assets.

--> Transfer of tokenised value over the Swift network.

2. Solutions

Swift SDK: Swift connectivity and messaging standards – in combination with an interoperability protocol such as the Chainlink CCIP – used to achieve interoperability between traditional financial systems and emerging blockchain networks. To address the technical and non-technical considerations that would need to be addressed to make a proposed solution commercially feasible, discussions have been held with over a dozen financial institutions and financial market infrastructures including Australia and New Zealand Banking Group Limited (ANZ), BNP Paribas, BNY Mellon, Citi, Clearstream, Euroclear, Lloyds Banking Group, SIX Digital Exchange (SDX) and The Depository Trust & Clearing Corporation (DTCC).

CBDC Interlinking solution: Swift network used to support the seamless integration of both CBDCs and tokenised assets into the existing financial system. Early 2023, Swift tested their new CBDC interlinking solution with 18 central and commercial banks in a sandbox environment.

Swift CBDC connector: which enables the use of central bank digital currency for cross border payments.

3. Target Customers

Members of the Swift network.

4. Key points

[Swift Interoperability experiment workflow]

Custodians: Produce settlement instructions

The settlement posting process is triggered by producing two settlement instructions: one from the buyer’s custodian, and one from the seller’s custodian. These instructions are sent using common standards – expected to be ISO 15022, but ISO 20022 is also possible – and are exchanged using the custodians’ existing Swift infrastructure. This activity is very similar to the existing process of issuing instructions. However, custodians need a digital custody solution to hold the investors’ private keys. They also need the right set of data to target the corresponding token, wallet and smart contract addresses, and blockchain network. These message types are largely suitable for the task but would require some additional blockchain data in a narrative field with custom codes. In a future standards update, these elements could be formally captured in dedicated fields.

Swift: Builds blockchain transaction and orchestrates signature

This activity prepares the information required to post the settlement on one or two ledgers, depending on the specific flow. Swift’s experimental Software Development Kit (SDK) digests the settlement instruction in the form of a Swift message, extracts the specific fields needed to post on the blockchain ledger, and enhances the content with other potential specific items derived from the destination chains (e.g. nonce to prevent replay attacks). The SDK would be deployed within the banks’ secure Swift environment. It then orchestrates the signature of the resulting payload with the relevant private keys held by the custodian (defined by the target wallet of the instructing institution). The outcome of this activity is a formed payload that can be captured by Swift’s platform to process the settlement. By signing the blockchain message with private keys, banks ensure no one can tamper with the message content, thereby achieving non-repudiation.

Swift: Requests depository approval for posting

In this step, Swift transports the two incoming instructions from custodians, which we’ve assumed for this experiment to be matched, with a consistent Unique Transaction Identifier (UTI) tracked by Swift. Detecting that these instructions are blockchain-related, the Swift platform adds a request to trigger the settlement posting confirmation recorded by the Designated Depository. Although the DLT ledger allows banks to post directly on-chain, to ensure compatibility and minimal disruption with existing back-end systems, certain functions might be required in the settlement instruction processing. Assuming these functions can be technically defined, a range of entities could look at fulfilling the Designated Depository role to ensure better interoperability with existing systems.

Designated depository: Approves posting of transfer

At this point, the Designated Depository has received the two settlement instructions from Swift, with a consistent UTI flagged for posting confirmation in the technical header of the instruction message. The Designated Depository ensures that the required validation steps have been performed (e.g. business validation, pairing, settlement eligibility), and confirms posting of the delivery settlement instruction. There are multiple options for how these validation steps could be performed. For example, it is conceivable that deterministic rules could be defined and performed by a technical provider that is delegated by the legally accountable market infrastructure.

Chainlink: Orchestrates asset movement on chains

The Swift platform prepares the request to post the blockchain message onto the chain and sends it to CCIP as a secure abstraction layer for all blockchain interactions. CCIP validates the request, creates a matching blockchain transaction, and submits it on-chain. CCIP then monitors the processing of the transaction on-chain and provides secure status updates of the on-chain processing back to Swift via the corresponding Swift API endpoint. The resulting confirmations can cater for various statuses depending on the chain type. These status updates are then mapped to ISO 15022 or ISO 20022 status messages towards the financial institutions.

Swift: Orchestrates confirmations of asset movement

Using the received status updates from CCIP, the Swift platform prepares Swift messaging-compliant confirmation of movement for the Designated Depository, and signs it. The confirmation is built leveraging the instruction payload and using the ISO 15022 or ISO 20022 standard.

Custodians & Designated Depository: Receive confirmations from Swift

The confirmation messages can then be shared with the Designated Depositories and custodians. As settlement finality remains a legal construct, the responsibility to confirm as much would ultimately lie with the Designated Depository entity. Once informed of the successful asset movement on-chain, custodians can then record the transaction in their off-chain book of records and pass confirmations on to their customers. Translating on-chain events back into standardised message formats averts the need for back offices to build another parallel status integration layer, and thus represents a significant cost savings.