Swift
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.
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.
Members of the Swift network.
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.
Tom Zschach - Chief Innovation Officer
Nick Kerigan - Managing Director, Head of Innovation
Jonathan Ehrenfeld - Head of Securities Strategy
Jack Pouderoyen - Innovation Market Engagement
Thomas Dugauquier Tokenised - Assets Product Lead
Charles Vinet - Senior Innovation Engineer
Fabrice Yans - Enterprise IT Architect
Tom Alaerts - Principal, Standards
Wes Harmon - Innovation Engineer
Last modified 10d ago