Connect Digital Islands: Tokenized Assets
Contents
1
Executive summary
3
2
Introduction: A growing brand
5
A growing market
5
Open hurdles
6
The experiment
7
Use cases
7
Roles and responsibilities
8
Design decisions
8
3
2
4
The experiment results
10
5
Conclusion and next steps
14
Connecting digital islands: Tokenised assets
Executive summary
Financial markets, which operate to provide financing
and stability, are by nature built on deep liquidity. The
tokenisation of assets, or creating “records of value held
on and transferred across a shared cryptographically
secured ledger1,” is a new and growing trend in financial
services and other industries alike, specifically targeting
those legacy assets with limited liquidity and multiple
layers of disintermediation.
Like all new technology, tokenisation raises
challenges and opportunities. These are
specifically around both how the growth of a
relatively untapped market can be enabled,
accelerated and leveraged as well as how
interoperability and communication can
take place between on-chain markets for
tokenised assets and off-chain legs.
While it’s possible that over time digital
assets will only be traded and settled on
ledger, there’s currently a need to support
the coexistence of new “tokenised assets”
and existing “traditional assets,” the
interoperability between the platforms on
which they exist, and the ability for financial
market participants to access them. As a
neutral, global cooperative, Swift was created
almost 50 years ago to enable economic
interoperability around the world and set
standards across the financial services
industry – and we are uniquely placed to help
1
3
find solutions in this new landscape too.
The successful experiments described in this
report are the next stage towards developing
interoperability solutions for tokenised assets.
Since 2020, our strategy has been heavily
influenced by the emergence of digital
assets. In May 2021, we published a white
paper ‘Exploring central bank digital
currencies: How they could work for
international payments,’ in which we explored
the impact of Central Bank Digital Currencies
(CBDCs) and digital currencies on Swift and
on our members. We showed for the first
time how interoperability could be achieved
between a CBDC network and a non-CBDC
payments network, and between two CBDC
networks on different technologies. Since
then, we have expanded our exploration of
use cases for digital assets, which will help
our securities clients to innovate in
this space.
See the Swift Institute paper ‘Defining Digital Assets’: https://swiftinstitute.org/research/defining-digital-assets/
Connecting digital islands: Tokenised assets
connectivity channels.
About our experiments
In December 2021, together with Northern
Trust, Clearstream, Citi and technology
partner SETL, we evolved our innovation
work and initiated a new set of experiments.
These explore the feasibility and benefits
of Swift acting as an interconnector and
‘single access point,’ linking up multiple
tokenisation platforms and various cash
leg payment types – Swift global payments
innovation (gpi), Real-time Gross Settlement
(RTGS) system and CBDC2 – with the
clients interacting with tokenised assets via
Swift, similar to the way they do today with
traditional securities assets.
With these key industry players representing
different parts of the tokenised and
traditional asset ecosystem, we aimed
to simulate primary token issuance and
secondary market transfers of tokenised
bonds/equities and cash, using a number
of different tokenised assets and cash
settlement environments. Our aim was to
show the ability to create, transfer, and
redeem tokens and update balances
between multiple client wallets.
What’s next?
Based on industry consultation on our
experiments, we will explore further
development areas, the feasibility of
offering the solution demonstrated in
the experiments as a service to Swift
customers, a next set of experiments
for expanded use cases, and how we
can evolve our data dictionaries.
Our vision is to enable instant and
frictionless transactions anywhere in
the world, regardless of the form they
take. We’re confident that the insights
from these experiments and the
solutions being developed will help
the post-trade industry realise this for
tokenised assets and deliver seamless
services for end customers.
The results
We’ve now completed the experiments
and technically tested the solution with
all participants involved, with 70 test
scenarios. These successful experiments
have demonstrated the feasibility of our
solution across both the primary and
secondary market use cases, single and
multiple tokenisation platforms, bond/
equity tokens, and multiple cash leg types
in different combinations, and with a
representative number of transactions. The
experiments also demonstrated multiple
benefits of the solution, including some of
the efficiencies that can be achieved through
accessing tokenised assets via existing Swift
2
4
Swift gpi, RTGS and CBDC were all simulated in these experiments.
Connecting digital islands: Tokenised assets
Introduction:
A growing trend
In Defining Digital Assets, a recent report published
by the Swift Institute, Alistair Milne, Professor at the
Loughborough University School of Business and
Economics, defines digital assets as “records of value
directly held on and transferred across a shared
cryptographically secured ledger.” In that context,
digital assets can be new digital constructs or
tokenised assets. The latter are simply token
representations of things that exist today – financial
assets like stocks and shares or even ownership of a
piece of artwork. In the future, it could theoretically be
possible to tokenise anything. This could have a huge
impact on finance, and on our lives more generally.
A growing market
Relative to cryptocurrencies and stablecoins,
the current market capitalisation of tokenised
assets is small, but momentum is expected
to accelerate rapidly in the coming years.
By some estimates, volumes of tokenised
assets could reach 24 trillion USD by 2027.3
This is leading many securities market
participants to actively assess how they
could tap into – and accelerate – the growth
of this market. Banks, securities firms and
financial market infrastructures (FMIs) have
been responding to this trend by exploring
digital asset servicing capabilities and
how they could support the full lifecycle
of digital native or tokenised securities.
There are a number of potential benefits to
tokenisation. One is fractionalisation, in which
larger assets can be split into smaller parts,
spreading ownership across more people. In
a tokenised future, investing could become
3
5
more accessible to people who have
never had the resources to do so.
Fractionalisation is not only relevant
for individual investors. It is relevant for
financial institutions as well. In a tokenised
future, investments could become more
diverse than ever before, resulting in the
potential for stronger portfolios, spreading
risk across a combination of tokenised
and traditional assets, and enabling the
creation of more sophisticated trading
and investment strategies.
Other potential benefits include compressed
settlement times or even real-time or
atomic settlement, a reduced need for
reconciliations, the enablement of a single
source of truth, the opening of new forms
of automation, greater transparency, and a
reduced risk of fraud.
See for example: https://www.gbm.hsbc.com/-/media/gbm/insights/attachments/potential-of-tokenisation.
Connecting digital islands: Tokenised assets
Open hurdles
There are many open hurdles that need
to be addressed before tokenised assets
can be actively traded by securities market
participants. For starters, we know that with
market players moving at different speeds,
tokenised assets will need to co-exist with
traditional assets. For that, and to enable an
impact on liquidity, ensuring interoperability
and communication between participants
and systems (traditional and new), as well as
on-chain and off-chain markets during the
transaction lifecycle of tokenised assets, will
be key to ensuring success. Furthermore,
solutions will need to ensure that they
provide the ability to use multiple cash leg
methods, including new forms of currency
such as CBDCs or stable coins, alongside
fiat currencies.
Fragmentation, due to a variety of conflicting
or different technologies, platforms,
and regulatory environments can create
inefficiencies for the market, including lack
of standards, market conventions and an
inability to scale. So the ability to easily
access multiple tokenised asset types
residing on multiple different platforms will
be key. This means that to allow for the
seamless use of digital assets, securities
participants will have to integrate with each
platform directly and independently. As such,
there’s a need for standardisation in this
space so that these new ways of working
can be seamlessly integrated using existing
communication channels and networks.
For securities markets this also means that
current communication standards, such as
6
Connecting digital islands: Tokenised assets
ISO 15022 and ISO 20022, which encapsulate
current business requirements, will need
to evolve to cater for the particularities
of new digital asset classes. Although
communication with Distributed Ledger
Technology (DLT) platforms often happens
through APIs, there’s also a need to update
existing data dictionaries and even existing
messaging standards and develop market
practices so that institutions that wish to
reuse these data dictionaries to create API
contracts or continue to use messages to
interact with DLT platforms can do so.
Today, Swift provides
a single access point
for securities players
throughout the posttrade lifecycle across
many asset classes
(equities, fixed
income, derivatives).
As institutional investors increasingly expect
access to all asset classes (both traditional
and digital) which belong to various service
providers, we have begun to explore the
extension of our role to include tokenised
assets – leveraging our community APIs to
connect data consumers and providers in
a harmonised way (enabling data models,
identity management frameworks, as well as
security and encryption to be standardised).
The experiments
Our experimentation aimed to validate two
key areas. The first was to demonstrate
the technical capabilities of enabling the
use of the Swift infrastructure as a means
of simulating primary market issuance and
secondary market transfers of tokenised
bonds/equities and cash using a number
of different tokenised assets and cash
settlement environments. This includes:
– The ability to create, transfer, and redeem
tokens4 and update balances between
multiple client wallets; and
– Showing how interoperability between
the “old” and “new” worlds can
be achieved: RTGS/gpi and CBDC
settlement, real traditional assets and
the analogous tokenised asset. We also
aimed to show interoperability between
different tokenisation platforms that have
been developed.
The second was to understand whether
the experiments could provide evidence to
support some of the claimed benefits of
tokenised asset securities, such as:
– Atomic settlement: Token exchange
represents instant settlement, reducing
counterparty risks.
– Fractionalisation: Fractional ownership
makes it easier for more retail investors
to purchase high-value assets or illiquid
instruments. This could facilitate greater
liquidity, even across very illiquid assets.
– Programmability: Deliver new forms of
automation with ‘smart contracts’.
– Shared golden copy: Single sources of
truth replace siloed ledgers across firms.
– Removal or reduction of end-of-day
reconciliations.
– Cost savings and processing
acceleration.
Use cases
Our experiment comprised seven different
use cases:
1. A bond/equity tokenisation –
Tokenisation is the process of
representing traditional assets such as
bonds or equities in token form, which
are available on a blockchain.
2. A bond/equity de-tokenisation –
De-tokenisation is the opposite of
tokenisation, whereby a token will be
redeemed for a traditional asset such as
bonds or equities.
Delivery versus Payment (DvP)5 transactions
over different scenarios that also include
split settlement scenarios (where cash and
securities settle at two different times and
environments):
3. A DvP transaction where the asset is
a tokenised bond/equity, the payment
in fiat currency is on Swift gpi or the
enhanced Swift platform, and the
buyer and seller are using the same
tokenisation platform.
4. A DvP transaction where the asset is
a tokenised bond/equity, the payment
in fiat currency is on Swift’s simulated
RTGS platform, and the buyer and seller
are using the same tokenisation platform.
5. A DvP transaction where the asset is
a tokenised bond/equity, the payment
in fiat currency is on Swift’s simulated
CBDC platform, and the buyer and seller
are using the same tokenisation platform.
6. A DvP transaction where the asset is
a tokenised bond/equity transferred
between two tokenisation platforms on
different blockchain environments and
the payment in currency is on Swift gpi or
the enhanced Swift platform.
7. A DvP transaction where the asset is
a tokenised bond/equity transferred
between two tokenisation platforms on
different blockchains, and the payment of
the fiat currency is on Swift’s simulated
RTGS platform.
In addition, we tested the following
exception flows:
DvP and Receipt versus Payment (RvP)
instructions do not match
– Insufficient balance in custody account to
tokenise
– Insufficient tokens to de-tokenise
– Insufficient tokens to complete DvP
4
5
Here we define redemption as de-tokenisation: the surrender of the token for the traditional asset.
Delivery versus Payment: settlement which ensures that the transfer of securities is only
performed once the payment has been received.
7
Connecting digital islands: Tokenised assets
Roles and responsibilities
Design decisions
Within these experiments, Swift provided the
integration layer for all inbound and outbound
connections to all systems, developed the
routing logic to outbound connections by
authentication and routing API requests, and
implemented the MT creation and parsing
programmatically. In addition, Swift was
responsible for emulating the three types of
cash legs involved (RTGS, gpi, and CBDC),
comprised of both API and CBDC networks.
The following design decisions were made in
order to enable our experimentation:
The SETL PORTL technology platform was
used to orchestrate and execute the flows,
creating and parsing MT messages, and
providing a user interface for the creation,
status and details of the transactions and
tokenisation platforms. In addition, the
SETL matching engine was used to match
instructions, based on pre-defined
matching criteria.
SETL and Northern Trust provided
tokenisation platforms for the
experimentation, with two additional Citi and
Clearstream tokenisation platforms hosted
by SETL. One of these hosted platforms was
based on SETL’s blockchain and the other
on a Digital Assets DAML implementation.
All of the platforms were designed to
support Swift messaging. A combination
of Swift messaging and API calls formed
the integration between the various
DLT environments and with transaction
orchestrations using their respective
capabilities, including holding the bookings
of different amounts of tokenised securities
and wallets via exposing APIs.
In the experiments, Clearstream, Northern
Trust and Citi represent key parts of
the tokenised − and traditional − asset
ecosystem, including securities market
infrastructures, global and sub-custodians,
playing the role of Asset Owner (owns
a security or a tokenised version of the
underlying security); Custodian (assists the
asset owner with executing the securities
settlement, including forwarding the
instructions to the depository or initiating
the cash movements or payments); and
Depository (holds the booking of securities
and owners). Each of these institutions
played these roles in different capacities, per
each use case, as detailed in the experiment
flow explanations below.
8
Connecting digital islands: Tokenised assets
Messages
The ISO 15022 MT messages are well
established for securities settlement and
reconciliation, but in the past did not have a
dedicated functionality for tokens or digital
assets. New token-related features will be
added for the upcoming Standards Release
2022 in November, including the addition of
a 30-digit accuracy number to allow for the
granularity needed for fractionalisation, and
the option to use a wallet blockchain address
instead of a safekeeping account: these
changes and features were utilised in
our experiments.
For the purpose of this experiment, we
created a market practice template that
allows:
– Swift to simulate secondary market
transfers of tokenised bonds/equity and
cash 24hrs a day.
– Swift users to transfer tokens and update
balances between multiple client wallets.
– Simulated settlement using CBDC.
– Simulated settlement at RTGS.
– Simulated settlement using Swift gpi or the
enhanced Swift platform.
– Blockchain specific details to be captured
(a code to clarify the operation workflow,
blockchain addresses, system specific
technical attributes).
The proposed market practice templates
demonstrate that the rich MT messages only
need a handful of additional refinements to
make tokenisation, de-tokenisation and the
processing of token settlements possible.
These messages included a mock-UTI
(Unique Transaction Identifier) for tracking
purposes.
In addition, the following existing MT
messages are in scope for the experiment:
MT 101, MT 103, MT 199, MT 540-548, MT
524, MT 508.
Fractionalisation
We enabled assets to be fractionalised to
six decimal places, adding a field into the
ISO 15022 messages to capture the agreed
amount (up to six decimal places) to be
traded by an asset owner.
Connectivity
Orchestration
The experiments involved the passing of
messages between a variety of applications:
some built specifically for this project, while
others required a delegation of the workflow
to legacy systems. In order to enable the
interaction of these systems and allow for
scalability, we used APIs, in which every
party exposed their APIs hosted on their
own cloud. Swift’s simulated environment
was used to create inbound and outbound
connections to all the systems involved. It
exposed an API to facilitate sending of MT
messages (passed as Base64 encoded JSON
payloads) to any specified recipient, as well
as methods to interact with the tokenisation
platforms and to start the cash leg flows.
The experiments ensured successful
orchestration in the case of tokenised assets
being settled against different cash leg
types, even across multiple platforms (i.e.
when the token is issued, traded and settled
on different platforms).
Audit trail functionality
While each component logs inbound API
calls, in order to ensure a sufficient audit trail,
the SETL PORTL tracked each step in the
flow. This includes the status of the API call
(success, server error, client error, etc.), the
sender of the API call, the receiver of the API
call and the contents of the API call. All of
this information was displayed via the SETL
user interface.
Security types
For the purpose of the experiment, we tested
each use case with three different securities:6
1. Ordinary Equity: DE0005810055: Deutsche
Börse AG
2. Corporate Bond with Coupon:
DE000A3H2465: DeutscheBörse 0,125%
22/02/2031
3. Government Zero Bond: DE0001142263:
Bundesrep.Deutschland Anl.v.05 (4.1.2037)
o.Zinssch
Out of scope
The following were out of scope in our
experiments:
– FX rates and cross-currency settlement
– External wallet and key management
Identity
Identity for our experiments was established
through a combination of API keys, client
certificates and (wallet) private keys.
The logic behind each connection was
implemented at the level of the Swift
environment, as it is highly configurable to
the target’s desired means of authentication/
authorisation.
6
The securities mentioned are for illustrative purposes only and not a recommendation to buy,
sell or hold a particular security type.
9
Connecting digital islands: Tokenised assets
The experiment results
For testing purposes, we ran each of the seven use
cases (described in detail below) multiple times, varying
the amounts and using three types of securities
(Ordinary Equity, Corporate Bond with Coupon,
Government Zero Bond). In total, 70 test scenarios took
place. The success of the use cases was ensured by
verifying that the balances were correctly updated, and
that statuses and acknowledgements were conveyed
to the Asset Owners.
Experiment 1: Tokenisation
Objective
This experiment aims to model the case
where a holder of a bond/equity (held
in custody at the custodian) wishes to
exchange the bond/equity for equivalent
tokens on the tokenisation platform.
Figure 1: Experiment flow – Tokenisation
Asset
Owner
Northern Trust
(Custodian)
Instruct to tokenise
securities
SWIFT
Tokenisation
Platform
SETL
Sent tokenisation
instructions
Sent tokenisation
instructions
Request movements
of the securities
Confirm securities
moved
Request movements
of the securities
Confirm securities
moved
Tokenisation
instruction
Inform token created
Notify token created
Issuance token
created
Issuance token
created
The experiment flow
This diagram above illustrates the following
steps:
1. The Asset Owner instructs the Custodian
(Northern Trust) to tokenise the securities.
2. The Custodian instructs this operation to
SETL PORTL via Swift.
3. The Custodian transfers the traditional
asset on its custody platform.
10
Token
creation
Connecting digital islands: Tokenised assets
4. Once SETL receives the confirmation of
the asset movement, SETL instructs the
tokenisation platform to create the token.
5. The token is generated on the tokenisation
platform.
6. SETL informs the Custodian that the
tokenisation is completed.
7. The Asset Owner is informed that the
operation is completed.
Experiment 2:
De-tokenisation
Objective
This experiment aims to model the
case where a holder of a bond/
equity token (held on the tokenisation
platform) wishes to exchange the
bond/equity token for the underlying
bond/equity equivalent in custody at
the custodian. The experiment also
attempts to estimate other areas for
potential cost savings
Figure 2: De-tokenisation
Asset
Owner
Northern Trust
(Custodian)
Instruct to de-tokenise
securities
SWIFT
Sent de-tokenisation
instructions
Tokenisation
Platform
SETL
Sent de-tokenisation
instructions
Request movements of
the securities
Request movements of
the securities
Confirm securities
moved
Confirm securities
moved
Lock token
De-tokenisation
instruction
Inform token burnt
Issuance token burnt
Token
burnt
Issuance token burnt
Notify token burnt and
securities are available
The experiment flow
This diagram above illustrates the following
steps:
1. The Asset Owner instructs the Custodian
(Northern Trust) to de-tokenise the asset.
2. The Custodian instructs this operation to
SETL via Swift.
3. SETL locks the token on the tokenisation
platform where it is registered.
4. The Custodian transfers the traditional
asset on its custody platform.
11
Connecting digital islands: Tokenised assets
5. Once SETL receives the confirmation of
the asset movement, SETL instructs the
tokenisation platform to burn the token.
6. After receiving confirmation that the token
has been burnt, SETL informs the Custodian
that the de-tokenisation is completed.
7. The Asset Owner is informed that the
operation is complete.
Experiments 3,4, and 5:
DvP transactions via one tokenisation platform
Objective
This experiment aims to model a situation
whereby both market participants have
a wallet on the same platform (using one
tokenisation platform). We aimed to show this
via three different cash legs – Swift gpi for
global fiat payments, Swift simulated RTGS
for domestic fiat payments, and Swift CBDC
platform (CBDC infrastructure implemented
and managed by Swift using Corda) for CBDC
payments in which the flows could run over.
The experiment also aimed to show that
because of improved information between
participants, reconciliation can be enhanced.
Finally, it attempted to estimate other areas
for potential cost savings and processing
acceleration. Note that as the bond/equity
ownership does not change, there are no
interactions at the Depository level and thus
there is no need to depict the role of the
Depository in this scenario.
Figure 3: DvP transactions via
one tokenisation platform
Seller
Buyer
Citi
(Cust. A)
Northern Trust
(Cust. B)
Instruct to sell securities
SWIFT
DvP instructions
CBDC
Network
SETL
Tokenisation
Platform
DvP instructions
Instruct to buy securities
RvP instructions
RvP instructions
Matching
instructions
Process seller’s
instruction
Lock token
Request payment
Request payment
Payment transfer
Payment transfer
Confirm payment
received
Notify process
completed
Notify process
completed
Inform process
completed
Inform process
completed
Confirm payment
received
Inform process
completed
The experiment flow
This diagram above illustrates the following
steps of use case 5 (the payment of the fiat
currency is on Swift’s simulated
CBDC platform):
1. The Seller instructs the Custodian (A – Citi)
to sell the tokenised asset and the Buyer
instructs the custodian (B – Northern Trust)
to buy the asset.
2. Instructions are sent by both Custodians
to SETL via Swift, and SETL matches the
information received.
3. SETL processes the Seller’s instruction to
the CBDC platform hosted and managed by
Swift (note: this step is not necessary in
the case of RTGS and gpi use cases).
4. SETL locks the token on the tokenisation
platform (Northern Trust’s) where it is
registered.
5. Once the payment over CBDC has been
confirmed and received by the seller’s
Custodian, SETL instructs to change the
owner of the asset.
12
Connecting digital islands: Tokenised assets
Transfer to buyer’s
wallet
Change
owner
Asset on buyer’s
wallet
6. Once the token’s owner has been
transferred, SETL informs the Custodians
via Swift that the process is completed.
The Buyer and Seller are notified by their
Custodians.
Note, the cases in which we used one
tokenisation platform over gpi and RTGS
are not depicted here for the sake of
simplicity and similarity. However, it is worth
noting that the roles of Custodians and the
tokenisation platforms have been altered for
each use-case:
– In the gpi use case, Citi played the role
of Custodian A, Northern Trust played the
role of Custodian B, and the Northern Trust
tokenisation platform was leveraged.
– In the RTGS use case, Clearstream
played the role of Custodian A, Northern
Trust played the role of Custodian B, and
the Clearstream tokenisation platform
was leveraged.
Experiments 6 and 7:
DvP transactions via two tokenisation platforms
Objective
will show that the need for end-of-day
reconciliation is removed and attempts to
estimate the other aspects of the ensuing
cost savings and processing acceleration in
a more complex environment by using two
tokenisation platforms.
This experiment modelled a situation in which
both market participants have a wallet on
different platforms, and aims to show this via
two different cash legs, Swift gpi for global
fiat payments and Swift simulated RTGS for
domestic fiat payments. The experiment
Figure 4: DvP transactions via two
tokenisation platforms
Seller
Buyer
Northern Trust
(Cust. A)
Instruct to sell securities
Clearstream
(Cust. B)
SWIFT
DvP instructions
Instruct to buy securities
Tokenisation
Platform A
SETL
Tokenisation
Platform B
DvP instructions
RvP instructions
RvP instructions
Request payment
Request payment
Matching
instructions
Lock token
Payment transfer
Payment transfer
Confirm payment
received
Inform asset
de-tokenised
Notify asset
de-tokenised
Notify asset
tokenised
Inform -asset
de-tokenised
Confirm payment
received
Inform asset
de-tokenised
Instruct tokenise
asset
Instruct tokenise
asset
Inform asset
tokenised
Inform asset
tokenised
The experiment flow
The diagram above illustrates the high-level
process for use case 6 (two tokenisation
platforms on different blockchain
environments while the payment of the fiat
currency is on Swift gpi or the enhanced Swift
platform, with the following steps:
1. The Seller instructs Custodian (A – Northern
Trust) to sell the tokenised asset and
the Buyer instructs the Custodian (B Clearstream) to buy the asset.
2. Instructions are sent by the Custodian
to SETL via Swift, and SETL matches the
information received.
3. SETL locks the token on Platform A
(Northern Trust’s) where it is registered.
4. Once the payment has been confirmed and
received by the seller’s custodian, SETL
instructs to de-tokenise the asset and
then informs the Custodians via Swift that
the asset has been de-tokenised.
The Seller is notified of this operation by
their Custodian.
13
Connecting digital islands: Tokenised assets
De-tokenise asset
De-tokenisation
Asset de-tokenised
Tokenise asset
Tokenisation
Asset tokenised
5. The Buyer’s Custodian instructs SETL via
Swift to tokenise the asset on a second
platform (Tokenisation Platform B – SETL’s).
6. Once the token has been created, SETL
informs the Buyer’s Custodian via Swift that
the asset has been tokenised on Platform
B. The Buyer is notified of this operation too
by their Custodian.
Note, the cases in which we used two
tokenisation platform over RTGS is not
depicted here for the sake of simplicity
and similarity. However, it is worth noting
that the roles of Custodians, and the
tokenisation platforms have been altered for
each use-case:
– In the RTGS use case, Northern Trust
played the role of Custodian A, Citi played
the role of Custodian B, and Northern
Trust’s and SETL’s tokenisation platforms
were leveraged.
Conclusion
and next steps
Through these successful experiments, we were able to
simulate primary token issuance and secondary market
transfers of tokenised bonds/equities and cash using
a number of different tokenised asset platforms and
cash settlement types (gpi, RTGS and CBDC), utilising
Swift’s infrastructure as a means of accessing these
platforms and orchestrating transactions. This illustrates
that we can achieve interoperability between “old” and
“new” payment worlds – namely RTGS/gpi and CBDC
settlement, real traditional assets and the analogous
tokenised asset, etc.
In addition, we demonstrated that we can
enable the creation, transfer, redemption of
tokens and update of balances, irrespective
of the platform in which a wallet is held. We
were also able to explore and show some of
the theoretical benefits of digital assets and
tokenised securities, such as
fractionalisation, increased transparency,
programmability and automation, faster
and more efficient settlements, easier
reconciliation and greater liquidity.
Centered around interoperability and
standardisation, our key findings were
as follows:
Interoperability can be achieved without
being prescriptive on technology. In this
series of experiments, we used four different
DLT environments – three for securities and
one for CBDCs. By clearly defining standard
operations, we were able to execute a wide
variety of use cases based on business
outcomes rather than technical compatibility.
To achieve an interoperable tokenised
assets market, consistent messaging
is vital as the preferred option of
communication for interoperating between
traditional and tokenisation platforms and
traditional and new securities processes.
Standards play a crucial role in
interoperability. When dealing with new
ways of representing cash and securities,
it is essential that a common naming
14
Connecting digital islands: Tokenised assets
convention and meaning is adopted between
participants. A token represents a right
conferred to the holder and for tokens to be
fungible between market participants there
must be an assured understanding that
those rights transfer between a buyer and
seller.
Messaging standards may need to
continue to evolve to support tokenised
assets. The messages used in the
experiments benefited from the upcoming
2022 Standards Release changes for
settlement and reconciliation messages.
New field formats give much higher precision
to the decimals needed when an asset is
fractionalised into smaller units. The new field
option allows users to have wallet addresses
instead of safekeeping accounts.
Standardised APIs can easily emulate ISO
15022 message interactions in a faster and
more flexible manner, without compromising
security, authentication, encryption or
standardisation.
Split settlement (when cash and securities in
a DvP transaction happen separately in two
different locations and timings) can be fast,
secure and reliable in hybrid configurations.
This is both in a RTGS cash settlement or a
regular cross-border cash movement, even
when multiple correspondent banks are
involved, thanks to gpi.
Atomic settlement can happen in the
case of tokenised assets being settled
against CDBCs, even across multiple
platforms (e.g. when the token is issued
in a platform, traded in another one and
settled in yet another one).
Fractionalisation can be successfully
demonstrated, with assets fractionalised
through tokens that were then able to be
used in transactions in the same way as
non-fractionalised tokens.
Next steps
As a next step, we would like to
invite the community’s feedback on
these experiments.
In the experiments, Swift users benefitted
from the single connectivity window and
leveraging the same core components
of the Swift network to transact with
multiple asset classes and with multiple
payment options, co-existing with
new assets and processes linked to
tokenisation.
15
Connecting digital islands: Tokenised assets
Possible options that Swift is evaluating for
further development include:
1. Offering the services demonstrated in
the experiments as a product to Swift
customers.
2. Initiating a follow-on set of
experiments to test additional use
cases, such as exploring reporting or
asset servicing scenarios.
3. Evolving data dictionaries for API
connectivity for tokenised asset
platforms so that firms can benefit
from standardised communication.
Want to learn more?
To provide feedback, or if you would like
to learn more about our tokenised assets
experiments and solutions, please reach
out to your Swift account manager or
contact innovate@swift.com.
Acknowledgments
Swift Team
Tom Zschach,
Chief Innovation Officer
Nick Kerigan,
Managing Director, Head of Innovation
Rachel Levi,
Head of Innovation Engineering
Charles Vinet,
Senior Innovation Engineer
Vikesh Patel,
Head of Capital Markets Strategy
Jonathan Ehrenfeld,
Securities Strategy
Tom Alaerts,
Principal, Standards Engagement
16
Connecting digital islands: Tokenised assets
About Swift
Swift is a global member-owned
cooperative and the world’s leading
provider of secure financial messaging
services. We provide our community with
a platform for messaging, standards for
communicating and we offer products and
services to facilitate access and integration;
identification, analysis and financial crime
compliance. Our messaging platform,
products and services connect more than
11,000 banking and securities organisations,
market infrastructures and corporate
customers in more than 200 countries and
territories, enabling them to communicate
securely and exchange standardised financial
messages in a reliable way.
As their trusted provider, we facilitate
global and local financial flows, support
trade and commerce all around the world;
we relentlessly pursue operational
excellence and continually seek ways to
lower costs, reduce risks and eliminate
operational inefficiencies. Headquartered in
Belgium, Swift’s international governance and
oversight reinforces the neutral,
global character of its cooperative
structure. Swift’s global office network
ensures an active presence in all the major
financial centres.
