Connecting blockchains:
Overcoming fragmentation
in tokenised assets
Swift’s interoperability experiments connecting
to public and private blockchain networks

Results reportAugust 2023

Contents

1

Executive summary

3

2

Business context

53

Our tokenisation journey to date7

4

Project workstreams and use cases

8

The project8

The set-up and preparation

9

Our solution

10

The solution process flow

10

Key solution components

126

Findings

14

7Conclusions and next steps

17

8

Appendix

18

Glossary of terms

18

Cross-Chain Interoperability Protocol (CCIP) mechanics

19

Test scenarios

20

Message standards: MT 543

20

Status confirmation codes

20

Acknowledgments

21

5

9

2

Swift’s blockchain interoperability experiments – Results report1. Executive summary

Most institutions would
prefer to evolve their
existing infrastructures
and applications toenable them to accesstokenised asset
markets.

Tokenisation is on the rise,
but fragmentation remainsa challenge

Swift is working to ensure global
interoperability of emerging
technologies and platforms

Global interest in tokenised forms ofvalue continues to intensify. Players
from across the industry highlight awide range of benefits that could be
gained through tokenisation – including
the potential to unlock market liquidity,
drive post-trade processing efficiencies,
enable automation, and increasetransparency. Market sentiment isstrong, with a recent survey showingthat 97% of institutional investors thinkthat tokenisation is set to revolutionise
asset management.

We’re focused on delivering instant andfrictionless cross-border transactions.
As part of our strategy, we’ve been
exploring how we can enableinteroperability between different
emerging platforms for some time. In
2021, we published an initial white paperthat assessed the potential impact of
CBDCs and how Swift could support thefinancial community as new currencies
are developed.

Significant challenges remain,
however, driven notably by the current
fragmentation in legal and regulatory
frameworks relating to tokenised
assets that exist around the globe. On
a technical level, the current lack ofinteroperability between the various
blockchain networks that host different
tokenised asset types presents anotherchallenge. When combined, thesehurdles threaten to prevent the market
for tokenised assets from reachingits potential.

There are multiple potential paths
toward the future of tokenisation
In a 2023 report on the topic, the Bankfor International Settlements (BIS)
highlighted two distinct approaches
that have the potential to define thefuture of tokenisation. The first moretransformational approach would
see Central Bank Digital Currencies(CBDCs), tokenised deposits, andtokenised assets brought together on
a common ‘unified ledger’. The second,
more incremental, path would see thecoexistence of multiple ledgers that areinterlinked with existing systems andinfrastructures.
The initial feedback we’ve received
from the community on this question
has indicated that most institutions
would prefer to evolve their existing
infrastructures and applications toenable them to access tokenised
asset markets – rather than having tobuild entirely new infrastructure andtechnology stacks from scratch.

3

In 2022, we conducted a series ofexperiments which tested how the Swiftnetwork could be leveraged to support
the seamless integration of both CBDCs
and tokenised assets into the existing
financial system. And, earlier this year,
we tested our new CBDC interlinking
solution with 18 central and commercial
banks in a sandbox environment.

We’ve worked on developing
a blockchain interoperability
solution as part of this new setof experiments
Our view is that a common connectivity
layer is critical to eliminating frictionand enabling interoperability between
the existing financial system andblockchains to create a unified
global market.
Therefore, as part of our current
project, we leveraged the Swiftnetwork, and the Chainlink
Cross-Chain Interoperability Protocol(CCIP), to create an experimental
solution. The goal was to test whether
we could enable financial institutions to
use their existing back-end
systems to interact with tokenised
assets and transact across both public
and private blockchains platforms.
We further collaborated with over adozen 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) –to discuss technical and non-technicalconsiderations that would need to beaddressed to make a proposed solutioncommercially feasible.

Swift’s blockchain interoperability experiments – Results report

The project proved successful
and yielded valuable insights
The experiments successfully
demonstrated that Swift connectivity
and messaging standards – in
combination with an interoperability
protocol such as the Chainlink CCIP –can be used to achieve interoperability
between traditional financial systems
and emerging blockchain networks. As
well as advancing our understanding oftechnical and business requirements,
the experiments have highlighted therole that a blockchain interoperability
protocol could play in transferring data
and value across blockchains.

The experiments havehighlighted the rolethat a blockchaininteroperability
protocol could playin transferring data
and value acrossblockchains.

The feedback gained from thecollaborative working group sessions
with the institutional participants –covering aspects such as data privacyand governance, business processes,
operational risk, and legal liability – will
be highly valuable as we iterate oursolution design and prepare to support
the transfer of tokenised value over the
Swift network.
The key findings can be summarised
as follows:

Technical findings– Token handling mechanisms
may vary by use case.
– Nonce management is criticalfor avoiding replay attacks.
– An abstraction layer isnecessary to manage thecomplexity of blockchains.

4

Business findings– A ‘Designated Depository’ roleis important to satisfy regulatory
obligations.
– Regulatory clarity remains themarket’s largest need.
– Data privacy is fundamental toany commercial solution.
– Liability and recourse must
be clearly addressed forcross-chain transfers.
– Cross-chain use cases lackmaturity, but development
is expected to ramp up.

We’re committed to continuing
our work to support tokenisation
and blockchain interoperability
Following the success of theseexperiments, and positive feedback
from project participants, we’recontinuing to work with the financial
services community to create an
approach to interoperability acrossmultiple blockchains that leverages
market participants’ existing
Swift capabilities and new open
interoperability standards.
Moving forward, we will expand
our exploration to different types ofblockchain ledgers, including public
permissioned ledgers, as well as
various on-chain and off-chain Delivery
versus Payment (DvP) payment options.
We will also explore other possibilities
to address institutional needs suchas transactional data privacy.

Swift’s blockchain interoperability experiments – Results report2. Business context

There is growing
belief across thefinancial industry thattokenisation has thepotential to becomea new source ofsignificant value.

The market trend towards tokenised assets has
gained significant traction in recent years. Thereis growing belief across the financial industry thattokenisation – the process of converting physicaland non-physical real-world assets such as stocks,
bonds, property, or even art into digital tokens – has
the potential to become a new source of significant
value, as well as driving greater efficiency, security
and transparency in post-trade processes.
Indeed, current market sentimentaround tokenisation is very positive:
97% of institutional investors believethat tokenisation will revolutionise asset
management1 , and 95% of capital markets
firms in the US, UK, and Canada believethat blockchain will play an important rolein settlement processes going forward 2 .
Furthermore, Boston Consulting Group has
projected the total market size of tokenised
illiquid assets alone will reach $16 trillion by
the end of the decade3 .

Tokenisation: The potential benefits
Institutions have identified a range of benefits that regulated tokenised assets could
offer, including:– Deliver increased liquidity: By enabling fractional ownership and facilitating
secondary market trading. This liquidity would, in theory, attract a broader range
of investors and enhance overall market efficiency and risk diversification.
– Offer cost-saving opportunities: By enhancing current value chains andstreamline the issuance, settlement, and transfer processes – reducing
administrative and operational expenses.
– Increase automation: By enabling programmability of functions which
could further reduce costs.
– Enhance transparency and security: By providing an immutable and auditable
record of ownership and transactions, reducing the risk of fraud, improving
compliance, and potentially enabling the development of new products.

1

B NY Mellon and Celent, ‘Migration to digital assets accelerates; 2022 Survey of Global
Institutional Clients | Asset Managers, Asset Owners, and Hedge Fund’

52

Accenture, ‘How your T+1 program could help pave the way to T+0’3

Boston Consulting Group, ‘Relevance of on-chain asset tokenization in ‘crypto winter’

Swift’s blockchain interoperability experiments – Results reportA significant hurdle
is the current lack of
secure interoperability
between the different
blockchain networks
that host the tokens.

Significant hurdles still need to
be overcome

There’s potential to leverage Swift tosupport blockchain interoperability

Given the optimism surrounding
tokenisation, and high levels of continued
investment, the wider adoption of
tokenised assets looks likely to continue.
Yet significant challenges remain that could
prevent the market from truly scaling.

The feedback we have received fromconsultations with our members todate has shown that the second, moreincremental, approach is likely to be themost plausible for market development in
the near-term.

For instance, with the legal andregulatory frameworks still evolving inthis domain, remaining compliant when
making tokenised asset transactions is
an extremely complex challenge
for institutions.

Most institutions have indicated they are
not inclined to build new infrastructure andtechnology stacks entirely from scratch.
Firms prefer to leverage their existing
infrastructure, message implementations,and proven business processes to connect
to blockchain ledgers, where tokens arerecorded in a way that is both compliant
and secure. This could help firms simplify
their architecture and operations, minimise
investment costs and reduce the risk oftechnology obsolescence.

Another significant hurdle is the current
lack of secure interoperability between the
different blockchain networks that host thetokens. This particular issue is leading tosignificant inefficiencies and a poor user
experience for current market participants.
It also has the potential to fragment market
liquidity moving forward.

The future of tokenisation is yet
to be fully defined
In its recent report on the topic, the BIS
described two broad approaches forbringing tokenisation to fruition in a futuremonetary system4 . The first approach
would involve a transformation that brings
together CBDCs, tokenised deposits, andtokenised assets on a common ‘unified
ledger’. Various industry efforts are
exploring how this could be done.

It is in this context that we are conducting
this set of experiments. The goal: to test
how Swift could support members in reusing their existing Swift infrastructure as asingle entry-point to the public and private
blockchain networks needed to transact
tokenised assets.

The second approach would entail
incremental improvements through theinterlinking of existing systems. In thiscase, market scalability would be achieved
by financial institutions connecting their
existing systems and applications tomultiple blockchain-based networks in asecure and trusted way – just as they dotoday when facilitating the trading andsettlement of traditional assets.

4

6

III. Blueprint for the future monetary system: improving the old, enabling the new (bis.org)

Swift’s blockchain interoperability experiments – Results report3. Our tokenisation
journey to date

There was strong
interest within
the community incollectively exploring
open questions aroundinteracting withpublic permissionless
blockchains.

As part of Swift’s vision to deliver instant andfrictionless cross-border transactions, we’ve been
focusing on how we can ensure interoperability
between emerging platforms that are at risk of
becoming unconnected ‘digital islands’. As well as
exploring how we can interlink the world’s central
bank digital currencies (CBDCs), we’ve conducted
experiments to test how we can enable interoperability
between multiple tokenised asset platforms.
Our first set of experiments on tokenised
assets in 2022 included major market
infrastructures and custodians. This work
demonstrated how our infrastructure could
serve to interconnect multiple private
tokenisation platforms and different typesof cash payments, offering a single accesspoint to institutions for tokenised assets.

Developing a blockchaininteroperability model
Following the completion of these initial
experiments, we received strong support
from the community to continue ourinnovation efforts and enable secureinteroperability in the tokenised asset
space more broadly. To inform our next
steps, we held consultations with over 20
global financial institutions and financial
market infrastructures. These resulted inseveral key insights:

Many of these findings reinforced ourexisting assumptions. However, a key
point of differentiation was the interestin extending the scope of interoperability
between platforms to include publicblockchains as an underlying
settlement layer.
As such, there was strong interest within
the community in collectively exploring
open questions around interacting withpublic permissionless blockchains, aswell as appetite for understanding how
this can be supported in a secure andcompliant manner.

– There is increasing investor
demand for both digitally native
and tokenised assets.
– The future is expected to be‘multi-chain’ and will require accessto a series of networks.
– There is broader preference for unlisted,
illiquid, or underserved asset classes.
– Institutions prefer to leverage existing
infrastructure and investments
wherever possible.

7

Swift’s blockchain interoperability experiments – Results report4. Project workstreams
and use cases

The objectives

The project

Based on the feedback we received fromour consultations, we set out to design
a set of experiments with the following
key objectives:

The experiments were structured into two
distinct workstreams:

Workstream 1: Solution design
The first workstream centred aroundthe business design and technicaldevelopment of a proposed solution. The
design of a solution was predicated on aset of critical requirements for participants.
For example, institutions needed to be able
to send and receive existing MT formatted
messages. Another requirement was thatblockchain wallet (see our glossary ofterms here) private keys would remain in
the possession of the asset owners or
their custodians.

– To demonstrate that there is a simple,
secure, and scalable way for financial
institutions to connect to multiple typesof blockchain networks leveraging
their Swift infrastructure and message
implementation.
– To advance industry understandingaround both the technical and business
requirements for interacting with public
and permissioned blockchain networks.
– To explore the value of using a
blockchain interoperability protocol
to securely transfer data between legacy
systems and an increasing numberof chains.
In line with our commitment to collaborative
innovation, we welcomed over a dozen
financial institutions and financial market
infrastructures from around the globe toco-develop a potential solution and debate
the associated considerations necessary
to deliver it.

Although the solution was designed
jointly with participants, the technicaldevelopment work was simulated entirely
by Swift and Chainlink. See Figure 1 for an
overview of the experiment design anduse cases tested.

The project participantsMore than a dozen major financial institutions and market infrastructures
joined the project, 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).
Chainlink, a Web3 services platform, provided connectivity across public andprivate blockchains for these experiments. Our experiments leveraged Chainlink’s
open-source protocol – the Cross Chain Interoperability Protocol – to enable thesecure and efficient transfer of asset tokens across multiple blockchain networks.

Figure 1: Experiment design
overview and use cases 5
Experiment use cases
1

Chain
eum)

Technical scope
Bank 1

Expe

Transfer of tokenised asset
between two wallets on same
public DLT network (Ethereum)

Public Chain(Ethereum)

MT 54x2

Transfer of tokenised asset
between two wallets on different
public DLT networks (Ethereum,
Avalanche)

3

Transfer of tokenised asset froma public DLT network (Ethereum) toa private DLT network (Quorum)

Chain
nche)

Chainlink CCIP
MT 54x

Chain
um)

2

Public Chain(Avalanche)
3Bank 25Note: Beyond the example blockchains used in this experiment,
Chainlink CCIP can be extensible to any public or private blockchain network.

8

1

Swift’s blockchain interoperability experiments – Results report

Private Chain(Quorum)

Workstream 2: Non-technicalconsiderations
The second workstream encompassed
working group discussions to identify anddiscuss non-technical considerations thatwould need to be addressed to make aproposed solution commercially feasible.

For example, focus was given to topics
such as data privacy and governance,
operational risk, and legal liability based onprioritisation results from the participating
institutions (see Figure 2 for the areas offocus for Workstream 2 in priority order).
Discussions related to regulatory and policy
considerations were deferred as they wereoutside the control of participants and thescope of the experiment.

Figure 2: The non-technical areas of focus in order of priority
Top Focus Areas
1

Data (privacy, interoperability, & governance)

2

Business process & operational risk

3

Legal liability & recourse
Regulatory clarity
Security
Issuer control & rights
KYC complianceMarket liquidity
Private key management

Set-up and preparation
To execute the experiment, Swift andChainlink simulated the technicalenvironments for financial institutions
and Swift itself, as well as for a wallet
infrastructure with various addresses. In
doing so, we simulated various processes
on behalf of financial institutions, including
but not limited to, the following activities:– Generating MT files– Integrating and enriching data forblockchain transactions– Integrating with blockchain wallets(held within simulated bank digital
custody platforms)

In combination with Chainlink CCIP, theEIP-712 standard was also used to simplify
integration with various blockchain
technologies. This enabled institutions
to create and sign a blockchain message
using their existing infrastructure andrely on a ‘trusted forwarder’ to process
messages on-chain without incurring‘gas fees’ (the amount paid to reward thecomputational effort required to executea transaction).
Swift and CCIP acted as the ‘trusted
forwarder’ that managed these gas
fees, and CCIP was responsible foradding the gas fees when creating theblockchain transaction.

Tokens also needed to be minted andissued to one of the wallet addresses
hosted and managed by Swift. DTCC
performed the minting and issuance
operations, creating the ‘BondTokens’ anddistributing them to Swift’s designated test
wallets. To ensure the tokens’ compatibility
with Chainlink CCIP, an extension was
included in the token contract.

9

Swift’s blockchain interoperability experiments – Results report

The proposed solution for this experiment aimed tominimise the level of investment and change required
for financial institutions to be able to instruct thetransfer of tokenised assets. It also sought to sustain
the key roles and functions that need to be performedin post-trade settlement as required by regulators.

5. Our solution

Throughout the course of the experiment,
we executed approximately 50 token
transfers across the three use cases using
the described solution. This involved thesingle leg delivery of BondTokens across
six unique wallet-private-key pairs for boththe sender (BondToken seller) and receiver(BondToken buyer). We also included
around 20 unhappy path scenarios thatprimarily tested single incorrect inputs
to confirm expected transfer failures –these included the reuse of the same
nonce (see our glossary here), passing an
incorrect token version, and insufficient
funds. Through CCIP, status updates weresecurely passed back to institutions using
existing Swift infrastructure.
By leveraging the existing Swiftinfrastructure in place today, our approach
minimises the need for substantial
additional investments, enabling financial
institutions to optimise their current
operations. As such, firms could reap the
benefits of Swift’s security and reliability, in
addition to the existing network effects inplace across 11,500+ financial institutions.

The solution process flow
The process steps below describe thesolution that was conceived by Swift incollaboration with the project participants.
In line with Swift’s aim to sustain the roles
and functions as required by regulation, it
was important to introduce the conceptof the ‘Designated Depository’ (see ourglossary here). It was also important toensure the role of a settlement systemowner, and to have a single, clearly
identified legal institution performing therole, irrespective of the technical constructused to do so (i.e. public vs. private ledger)
or the programmability of the assets.
Figure 3 provides a summarised viewof these steps in sequential order, witheach step explained in more detail in
the following section.

Figure 3: The solution process flow
1

Custodians

2

Swift
(on-premises or central)

7

Producesettlement
instructions
Builds blockchaintransaction andorchestrates signature

3

6

Requests
depository approval
for posting
5

Chainlink
4

DesignatedDepository

10

Receiveconfirmations
from Swift

Orchestrates
confirmations ofasset movement

Orchestrates
asset movement
on chains

Approves
posting oftransfer

Swift’s blockchain interoperability experiments – Results report

7

Receives
confirmations
from SwiftThe solution process flow: A step-by-step guide
1. Create the 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 to issue 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.
2. Build the blockchain transaction and orchestrate signatureThis 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 poston the blockchain ledger, and enhances the content with other potential specificitems 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.
3. Request 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 UniqueTransaction Identifier (UTI) tracked by Swift. Detecting that these instructions areblockchain-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 ensurecompatibility and minimal disruption with existing back-end systems, certain
functions might be required in the settlement instruction processing. Assuming thesefunctions can be technically defined, a range of entities could look at fulfilling the
Designated Depository role to ensure better interoperability with existing systems.
4. Record settlement instruction validation
At this point, the Designated Depository has received the two settlement instructions
from Swift, with a consistent UTI flagged for posting confirmation in the technicalheader of the instruction message. The Designated Depository ensures that therequired 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 andperformed by a technical provider that is delegated by the legally accountable
market infrastructure.

11

Swift’s blockchain interoperability experiments – Results report

5. Orchestrate asset movement on-chain
The Swift platform prepares the request to post the blockchain message onto thechain and sends it to CCIP as a secure abstraction layer for all blockchain interactions(see Figure 4 below depicting how the transaction is channelled from banks to CCIP
through the Swift platform).
CCIP validates the request, creates a matching blockchain transaction, and submits
it on-chain. CCIP then monitors the processing of the transaction on-chain andprovides secure status updates of the on-chain processing back to Swift via thecorresponding Swift API endpoint.
The resulting confirmations can cater for various statuses depending on the
chain type (a complete set of the potential status confirmations is provided in the
Appendix). These status updates are then mapped to ISO 15022 or ISO 20022 status
messages towards the financial institutions.
6. Producing confirmation of token movement
Using the received status updates from CCIP, the Swift platform prepares Swiftmessaging-compliant confirmation of movement for the Designated Depository, andsigns it. The confirmation is built leveraging the instruction payload and using the ISO
15022 or ISO 20022 standard.
7. Delivering confirmation of token movement as Swift messages
The confirmation messages can then be shared with the Designated Depositories
and custodians. As settlement finality remains a legal construct, the responsibility toconfirm as much would ultimately lie with the Designated Depository entity.
Once informed of the successful asset movement on-chain, custodians can thenrecord 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 theneed for back offices to build another parallel status integration layer, and thus
represents a significant cost saving.

Key solution components
To execute our proposed solution in
a way that met the needs of theparticipants, several key technicalcomponents were used:
The Swift experimental SDK
The experimental SDK was developed
to serve several important functions
and to minimise the amount of change
required from sending institutions. A key
design decision was to deploy this SDK
in the banks’ existing Swift connectivity
infrastructure (on-premise or in the Swiftcloud) to benefit from longstanding andtrusted security features.
The key process steps performed by theexperimental SDK include:– Constructing the blockchain message inadherence to the EIP-712 standard.
– Requesting the simulated wallet
infrastructure to sign the blockchain
message. The application communicateswith the simulated wallet infrastructure
through an API to request the signing of
the blockchain message. The response
received from the infrastructure is thesignature, which is integrated into the MT
field. Specifically, it is inserted under the
tag and Qualifier 70E /SIGN.
In the future, the process for extracting
data and constructing a blockchain
message could be enabled by the Swift
Translator, a widely used Swift solutionthat easily defines, maps, and validates
messages from and to any format.

– Intercepting the MT message generated
by the simulated back-office applicationand extracting the information requiredfor generating a blockchain message.
A dedicated parsing mechanism
was developed.

12

Swift’s blockchain interoperability experiments – Results report

The Chainlink Cross-Chain
Interoperability Protocol (CCIP)
Upon receiving the request from Swift,
which contains both the metadata andthe blockchain message signature, CCIP
is used as an abstraction layer to create
a blockchain transaction and securelytransmit the transaction to the
Forwarder Contract.
The Forwarder Contract address, which
was initially involved in creating theblockchain message, undertakes multiple
verification and validation processes,
before forwarding the request to thedesignated token contract where the token
transfer is initiated. This transfer can either
occur within the same blockchain or use
CCIP to securely reach the destination
blockchain’s wallet.
Throughout the cross-chain transfer
process, each step and any exception
returned by the smart contract while
processing the transaction are monitored
by CCIP as events. CCIP sends a status
update for each of these events to Swift,
which matches the received status updateto the relevant Swift message and informs
the relevant institutions of its progress.
Middle and back-office systems rely onthese updates for internal teams to provide
transparency, manage risk and reporttransaction progress to all relevant parties.

Depending on the specified configuration,
the CCIP router will immobilise a certain
quantity of tokens within a ‘token pool’(see our glossary here) on the source
blockchain. Concurrently, wrapped tokens
will be generated on the destination
blockchain. This process involves theinclusion of CCIP fees and the creationof a message that incorporates thepre-existing information.
The inherent nature of blockchaintransactions addresses the potential
issue of a race condition arising frominsufficient tokens in the token pool.
Since all the instructions mentioned above
are contained within a single transaction,
the transaction can only succeed if all
instructions are executed successfully.
Note that the detailed mechanics fora cross-chain transfer can be found in
the Appendix.
Messaging standards
To initiate the process of blockchain
message creation within the financial
institution’s infrastructure, it is essential
to gather a set of information in dedicatedfields of the MT 543 Deliver Against
Payment (detailed list described in
the Appendix).
The message standards used in
the example largely meet therequirements. However, a few new field
options should be created to capturesome blockchain-specific details formally,
instead of relying on a market practice
structure for a narrative field.

Figure 4: Overview of the architectural environments supporting end-to-end transaction flow
Financial
Institutions

MT

Blockchain
Transaction

MT with Signed
Blockchain message

Source Blockchain
Forwarder
CCIP Router

Swift SDK
Signed blockchain
message andmetadata
Transaction
Status Update

Chainlink
CCIP

Blockchain
EventsChainlink
CCIP

Transaction
Status Update
MT

Financial
Institutions

13

CCIP Router

Swift SDK

MT with Signed
Blockchain message

Destination Blockchain

Swift’s blockchain interoperability experiments – Results report6. Findings

The range and diversityof the feedback
received will enable us
to iterate our solution
design, and thereby
serve our customers.

Overall, the results of the experiment give confidence
that existing Swift connectivity and messaging
standards can be enhanced, enabling financial
institutions to transfer tokens within and acrossblockchain networks – all with minimal disruption
to operations.
Open questions remain around the overallmarket readiness for tokenised assets.
Nevertheless, the level of agreement about
the market need for a secure and trusted
cross-chain interoperability solution gives
us confidence that we are focused on theright area for the Swift community.

for us to consider as we continue our
preparations to support the transfer oftokenised value over the Swift network.
The range and diversity of the feedback
received will enable us to iterate oursolution design, and thereby serve ourcustomers.

Through the interactive collaboration
working group sessions focused on nontechnical considerations in Workstream 2,
participants provided valuable input

The box below gives an overview of
the key findings from the experiments
which are then detailed in the remainderof this section.

Overview of key findings
Commercial findings
A ‘Designated Depository’ (or‘central account keeper’) roleis important to meet regulatory
obligations
Regulatory clarity remains themarket’s largest need
Data privacy is fundamental to any
commercial solution

Technical findings
Token handling mechanisms mayvary by use case
Nonce management is critical foravoiding replay attacks
An abstraction layer is necessary
to manage the complexity ofblockchains

Liability and recourse must be
clearly addressed for cross-chaintransfers
Cross-chain use cases lackmaturity, but development is
expected to ramp up

14

Swift’s blockchain interoperability experiments – Results report

A ‘Designated Depository’ (or‘central account keeper’) role isimportant
While the latest regulations – e.g. the EU’s
Distributed Ledger Technology (DLT) Pilot
Regime – are relaxing the complexity of
trading in digital forms of regulated assets,
the licensed DLT market infrastructure (MI)performing settlement is still required to:– Monitor the recorded quantity ofassets on the blockchain to ensure
it matches the issued quantity of
securities, and prevent their deletionor improper creation.

All participants citedlegal and regulatory
clarity as arguably
the largest pending
hurdle for widespread
adoption.

– Ensure segregation capabilities andmanage participation to the settlement
ledger. Non-institutional investors
could be allowed to do this if they areknowledgeable about the risks andoperations, and have provided their
explicit consent.
– Prevent or address settlement fails,
and provide settlement finality innear-real-time, intraday, and no later
than the second business day after
the conclusion of a trade.
– Enable the clear and accurate
confirmation of transaction details,
including payments that are by
preference concluded in central bankmoney or in commercial bank money
through the account of the DLT MI.

Regulatory clarity remains themarket’s largest need
All participants cited legal and regulatory
clarity as arguably the largest pending
hurdle for widespread adoption.
Compounding the issue further is thebroad diversity of legal and regulatory
frameworks across different jurisdictions,which makes the environment even morechallenging to operate in a compliant
manner for participants. As legislativeand regulatory decisions are outside
our control, we deliberately focused our
discussions on other topics thought to be
more directly within our collective control.

15

Data privacy is fundamental to any
commercial solution
Participants noted that aside fromlegal and regulatory clarity, data privacy
was the top priority that needs to beaddressed in order to operate securely
in cross-chain processing.
There was general agreement thatdata privacy is as important on private/permissioned chains as on public networks.
However, there was no consensus among
participants about which data should be
stored on-chain vs. off-chain, as there
are competing motivations such as
scalability and performance, or automatedfunctionality of smart contracts withtransparent data.
For data that would be stored on-chain,various solutions are being consideredby participants. These include zeroknowledge proofs and roll-ups, stealthaddresses, and layered pseudonymity,
among others.
It was also noted that many smart contract
logs, which log the usage history andstore data off-chain, have higher levels ofvisibility, and therefore should be reviewed
with greater scrutiny.

Liability and recourse must be clearlyaddressed for cross-chain transfers
Participants agreed that decentralised
blockchain networks should be treatedsimilarly to open-source technologies. In
other words, one cannot attribute liability todecentralised public blockchain networks.
On the other hand, as soon as a token or
application is defined under a jurisdiction’s
legal or regulatory framework, those
associated definitions could invoke liability.
In the case of cross-chain token bridge
solutions – in which tokens on the source
chain are ‘locked’ in a smart contract
token pool – many institutions felt that the
responsibilities and related liabilities of thesmart contract owner were unclear. Someparticipants suggested that liability mightchange if the token bridge solution was
open-source code and had to be directly
incorporated by a token issuer. However,most viewed the lack of control as thedetermining factor.

Swift’s blockchain interoperability experiments – Results reportCross-chain use cases lackmaturity, but development is
expected to ramp up
Participants broadly felt that cross-chaintransfer use cases are still maturing, andheld a range of different views on theprioritisation of suitable asset classes.
But they did note that the need to support
cross-chain transfers is widely anticipatedover the next few years and is therefore
driving the preparatory work within
their institutions.

In the near-term,
most participants
expect there to be agreater focus on token
transfers between
private permissioned
chains.

In the near-term, most participants expect
there to be a greater focus on token
transfers between private permissioned
chains, with a longer-term direction of travel
toward public blockchain networks.

Token handling mechanisms mayvary by use caseParticipants expressed contrasting views
about the suitability of various token
handling mechanisms (see our glossaryhere), e.g. burn-mint versus lock-mint.
Some participants thought the lock-mint
mechanism to be more favourable forcross-chain visibility of total issuance– however, questions remain about thelegal basis of wrapped tokens and thevulnerabilities of collateral locked inbridging solutions.
Other participants suggested that theburn-mint mechanism may provide greaterlevels of control, but potentially at theexpense of higher operational complexity.
Another model to consider involves leaving
the issued token on its native network andorchestrating ownership changes withineach chain.
In any case, participants generally
agreed that token handling mechanisms
are likely to depend on specific use cases.
As these mechanisms may introduce
operational complexity, any solution should
be designed to support multiple token
handling mechanisms.

16

Nonce management is critical foravoiding replay attacks
Some participants suggested that
digital wallet infrastructure to createand sign blockchain transactions should
continue to be hosted and managedby financial institutions..
However, this increases the complexity ofdevising a solution to mitigate the risk ofreplay attacks that is inherent in blockchaintransactions. In a typical scenario, the‘wallet nonce’ (see our glossary here) canbe employed to prevent a transaction
from being executed multiple times within
a single blockchain, or from being reexecuted on another compatible chain.
To address this challenge, a potential
solution could involve the implementationof a randomised nonce stored on theblockchain. This randomised nonce ischecked during the processing of theblockchain message, thereby ensuring
the prevention of replay attacks.

An abstraction layer is necessary
to manage the complexity ofmultiple blockchains
Participants recognised that an abstraction
layer and interoperability solution such as
CCIP reduces the complexity of interactingwith various blockchains.
The ability to connect institutions tovarious blockchains through existing
infrastructure saves significant time andeffort as it shields banks from the variety ofsigning, transaction formatting, and other
differences between blockchains. And
fragmentation will remain for some time asvarious chains are being adopted by market
actors. Having the ability to keep internal
systems updated about the progress ofblockchain transactions across multiple
chains will remove risk and ease integration.

Swift’s blockchain interoperability experiments – Results report

7. Conclusions andnext steps

With interest in tokenised assets growing, institutional
investors – and the financial institutions serving them– require secure, scalable, and cost-effective ways ofinteracting with networks for post-trade processing
and settlement.
The collaboration between Swift, Chainlink, andthe financial community represents significant
progress towards enabling interoperability
between traditional financial systems andemerging blockchain networks as next
generation places of settlement. However,there is work to do to enable the broader
tokenisation of capital markets.

The collaboration
demonstrated theability to transfer
tokenised value
efficiently and securely
across public andprivate blockchains.

Demonstrating the value ofcollaborative innovation
By bringing together a range of industry
participants from multiple jurisdictions,and serving different parts of the value chain,
we were able to design a potential solutionthat could work for a larger portion of thecapital markets ecosystem. Participants
benefitted from the richness of experienceand expertise across the group, highlighting
the importance of our collaborative
approach to industry innovation.
By leveraging existing Swift infrastructure
and Chainlink CCIP, the collaboration
demonstrated the ability to transfer tokenised
value efficiently and securely across public
and private blockchains, using standardised
messaging formats and proven businessprocesses. These industry-wide trials haveresulted in a greater understanding of therelevant technical and business requirements.
They have also highlighted the potential valueof a blockchain interoperability protocol insecurely transferring data and value acrossdifferent blockchains.

Open questions remain
While the successful completion ofthese experiments represents progress
for the industry, a number of questions
remain open. Putting regulatory clarity
to one side, there are numerous areasthat the private sector can work on
together to advance the developmentof the tokenised asset ecosystem.

Want to learn more?
To provide feedback, or if you would
like to learn more about our blockchaininteroperability experiments and solutions,please reach out to your Swift accountmanager or contact innovate@swift.com.

17

Solutions will be needed to address
institutional requirements for adequatetransactional privacy, and clearly defined
liability within the tokenised asset value chain.
The clear articulation of relevant use cases
will be key in driving such solutions forward.

Swift’s strategy, we will invest in determining
an appropriate set of capabilities to support
the transfer of tokenised assets over the Swiftnetwork globally.

Areas for development
To tackle these challenges, Swift will continue
working with the community to understand themost concrete use cases for tokenised asset
adoption. We anticipate the most compellingbusiness case for tokenisation in the near-term
to be for the secondary trading of non-listed
assets and private markets, given the potential
for improvement in this area. We will therefore
prioritise our efforts accordingly.
We remain focused on enabling the financial
community to interact with tokenised
assets by providing standardised channels,
market guidelines, and orchestration offlows across networks. This will encompass
DvP orchestration across the spectrum of
payment leg types, including existing offchain payments (e.g. correspondent banking
and RTGS payment rails). To support market
demand in the near-term, we will also explore
on-chain payment methods (such as CBDCs
and deposit tokens) to facilitate instant atomic
settlement, as these channels becomecommercially available in the market.

Charting the future
Future work will require a heightened
focus on the institutional requirementsthat were identified in our experiment, suchas data privacy. To that end, we will continue
our exploration of various types ofblockchain implementations, with a greater
focus on public permissioned ledgers
that could provide the benefits of an open
ecosystem, while ensuring adequate levels oftransactional privacy.
We will also explore alternative possibilities,
such as the provision of a private transactional
data repository or the use of privacy-enhancing
technologies like zero-knowledge proofs.
Moving forward, Swift is committed
to remaining a key player in enabling
blockchain interoperability, and enabling
the widespread adoption of tokenised
assets in financial services.

Based on the perceived market potential of
tokenisation, and the broader alignment with

Swift’s blockchain interoperability experiments – Results report8. Appendix

Glossary of terms
Blockchain wallet: This is a piece ofsoftware that manages one or multiple
blockchain-specific public-private key
pairs. The software typically includes
functionality to generate and sign validtransactions for a supported blockchain
network, or receive tokens at a valid
address that is cryptographically linked tothe public-private key pair.
EIP-712: This is an Ethereum standard(Ethereum Improvement Proposal) for thehashing and signing of typed structured
data as opposed to just byte strings. It
aims to improve the usability of off-chain
message signing for use on-chain.
Designated Depository: This can be seenas the operational sponsor for a given
asset on a blockchain-powered Settlement
System, similar to the operational sponsor
role performed by T2S (TARGET 2
Securities) before committing settlementon the T2S Securities Settlement
ledger. Whilst we have classified it as
the ‘Designated Depository’, this role
could have various names dependingon the jurisdiction and settlement flows
encompassed, including ‘central securities
depository’, ‘central account keeper’ and‘registrar’, or ‘master bookkeeper’.
Token pool: An essential component
in the process of minting and burning
wrapped tokens, this is a smart contractthat keeps track of the assets depositedby users for creating wrapped tokens, andensures the proper allocation of thesetokens. The token pool also enables asecure and transparent auditing process
for the wrapped token supply, whichhelps to maintain the peg of the token
to its underlying asset. Overall, the token
pool is a crucial aspect of the wrapped
token ecosystem as it ensures proper
collateralisation and the stability of thetoken value.

18

Nonce (wallet nonce): This is introduced
to protect against the security risk ofreplay attacks. Via the bank wallet nonce,a blockchain message signed by thebank cannot be processed twice on theblockchain, whether submitted by Chainlink
or by an adversary. The second time asigned blockchain message is submitted,
the nonce validation in the smart contract
fails and the transaction is rejected. The
bank wallet nonce is validated by smart
contract logic.
Token handling mechanism: Transferringa tokenised asset typically involves sending
funds from sender to receiver. For token
transfers across blockchains, there are
two common mechanisms: (1) locking
the transferred (native) tokens on thesource chain and minting a representationof them on the destination chain, or (2)burning the (native) tokens on the source
chain and minting them natively on thedestination chain.
Wrapped token: This is a program orprotocol that ‘wraps’ or encapsulates
digital assets, such as cryptocurrencies
or tokens, in a new format that makes
them compatible with different blockchain
networks. This enables easier transfer andinteroperability between different platforms
and networks. The token wrapper typicallyadds metadata and functionality to thewrapped tokens, such as smart contract
capabilities or access control features. This
allows the wrapped tokens to be used indecentralised applications (dApps) andother blockchain-based systems that may
require additional functionality beyond
basic currency transactions.

Swift’s blockchain interoperability experiments – Results reportCross-Chain Interoperability
Protocol (CCIP) mechanics
In the event of a cross-chain transfer, therequest is directed to the CCIP router. The
below steps are taken to ensure tokens aresent securely to the destination blockchain:
1. Interface Interaction: The CCIP Routerprovides a user-friendly interface
to interact securely with the crosschain messaging system from existing
institutional infrastructure.
2. Source Chain Validation: The CCIP
Router validates the cross-chain message,
ensuring that the destination blockchain
is supported.
3. OnRamp Validation: If validation
passes in the CCIP Router, the message
is forwarded to the OnRamp, which
performs further validation. Each institution
can configure its preferred validation
criteria, such as value and rate limits
on specific tokens.

4. Token Handling: For each token includedin the message (could be a single transfer
or batch), the token handling mechanisms
set by the issuer are applied. This caninvolve actions like lock-mint or burn-mint.
5. Oracle Network Processing: The
OnRamp emits an event that triggers CCIP
to process the message securely. CCIP
works together with the additional Risk
Management Network — an independent,
secondary validation network — to ensurea robust and risk-mitigated approach tovalue movement across blockchains.
6. Destination Chain Validation: After
CCIP processing, the token undergoes
rigorous security and validation rules on thedestination chain.
7. Token Minting: Once all validations
are completed successfully, the token is
minted and sent to the desired recipient on
the destination chain.

Figure 5: The Cross-Chain
Interoperability Protocol

Risk Management
Network

Chainlink CCIP

OnRampSender
Data+Tokens

RouterCommitting DON

Lock/Burn

Source Blockchain

Token Pool

CommitStore

OffRamp

Receiver
RouterUnlock/Mint

Executing DON

Token Pool

Off-Chain

19

Data+Tokens

Swift’s blockchain interoperability experiments – Results report

Destination Blockchain

Test scenarios
During this experiment we also
tested several unhappy scenarios(non-exhaustive):– Reuse same Nonce– Expired ValidUntilTime– Mismatch public address (From)and private address– Send more token than available
on the Wallet– Wrong token name– Wrong token version– Wrong chain ID– Wrong Forwarder Address– Destination chain ID: ID of theblockchain to which the tokens
will be sent
– This data can be captured in themessage with a structure for :95Q::PSET– Valid until time: Timestamp after which
the transfer would no longer
be valid– This data can be captured in themessage with a structure for :70E:
Processing Instruction– Nonce: Random value (non-sequential)
stored on chain to avoid replay attacks– Mismatch API request payload withblockchain message data

– This data can be captured in themessage with a structure for :70E:
Processing Instruction

Message standards: MT 543– Signature: EIP-712 signature of theblockchain message– Quantity of the tokens which
will be transferred– This data can be captured in themessage with a dedicated field option:36D::SETT//DITU/– From: Wallet address the tokens will besent from– This data can be captured in themessage with a dedicated field option:97D::BCAW//– Receiver: Wallet address the tokens will
be sent to– This data can be captured in themessage with a dedicated field option:97D::BCAW//– Target: Address of the tokens which willbe transferred– The message can currently formallyhandle the DTI identifier. This data canbe captured in the message in :70E:
Processing Instruction as ADDR/– Target name: Name of the tokens which
will be transferred– This data can be captured in themessage with the /NM/ tag for :35B:
identification of the financial instrument– Target version: Version of the tokens
which will be transferred– This data can be captured in themessage with a /VRSN/ tag for :35B:
identification of the financial instrument– Chain ID: ID of the blockchain fromwhich the tokens will be sent20

– This data can be captured in themessage with a structure for :70E:
Processing Instruction– This data can be captured in themessage with a structure for :70E:
Processing Instruction

Status confirmation codes
When queried, the Chainlink API provides
detailed information regarding the current
state of transactions. An initial response isprovided as soon as a transaction has been
submitted to Chainlink. The information
returned includes:
chainlink_request_id: UUID. This is sameas request_id returned by Chainlink for
send_transaction API
status: status of meta-transaction. Can beone of the following:– CONFIRMED: blockchain tx has 1 block
confirmation on source chain– SOURCE_FINALISED: blockchain tx on
source chain is finalised (for cross-chaintransfers only)– FINALISED: blockchain tx finalised(on destination chain, for cross-chaintransfers)– FAILURE: failure– tx_hash: transaction hash on source
blockchain– ccip_msg_id: CCIP Message ID (forcross-chain token transfers only)– failure_reason: reasons for FAILURE
statusThe Chainlink status updates are mapped
to the MT 548 message towards thefinancial institution.

Swift’s blockchain interoperability experiments – Results report9. Acknowledgements

Swift team

Chainlink teamTom Zschach
Chief Innovation Officer

Sergey Nazarov
Co-founder

Nick Kerigan
Managing Director, Head of Innovation

Thomas Trepanier
Head of Capital Markets

Jonathan Ehrenfeld
Head of Securities Strategy

Ryan Lovell, Director
Capital Markets

Jack Pouderoyen
Innovation Market Engagement

Pieter Pauwels
CCIP Market Strategy Manager

Thomas Dugauquier
Tokenised Assets Product LeadCharles Vinet
Senior Innovation Engineer
Fabrice YansEnterprise IT Architect
Tom Alaerts
Principal, Standards
Wes Harmon
Innovation Engineer

Swift would like to give a special thanks to our colleagues from over a dozen financial
institutions that participated in these blockchain interoperability experiments.

21

Swift’s blockchain interoperability experiments – Results reportAbout Swift
Swift is a global member-owned
cooperative and the world’s leading
provider of secure financial messaging
services. We provide our community witha platform for messaging, standards forcommunicating and we offer products
and services to facilitate access andintegration; identification, analysis andfinancial crime compliance. Our messaging
platform, products and services connect
more than 11,000 banking and securities
organisations, market infrastructures andcorporate customers in more than 200
countries and territories, enabling themto communicate securely and exchange
standardised financial messages in a
reliable way.

As their trusted provider, we facilitate global
and local financial flows, support tradeand commerce all around the world; werelentlessly pursue operational excellence
and continually seek ways to lower costs,
reduce risks and eliminate operational
inefficiencies. Headquartered in Belgium,
Swift’s international governance andoversight reinforces the neutral, global
character of its cooperative structure.
Swift’s global office network ensures anactive presence in all the major financial
centres.

For more information, visit
Web: www.swift.com
Twitter: @swiftcommunity
LinkedIn: Swift

Copyright
Copyright © Swift — all rights reserved.

Disclaimer
Swift supplies this publication for
information purposes only. The
information in this publication may
change from time to time. You must
always refer to the latest available
version.