Thibault, before we look into the results of Swift’s experiments – is Swift the natural home for solutions around digital payments?
First of all, we should mention that this is not limited to payments – which would suggest a unidirectional flow of data - there is in fact a little more to it than that. In addition, Swift is neither involved in the booking of payment transfers – it just provides the relevant technical infrastructure and the messaging transmission taxonomy – nor does it offer clearing or settlement services. One could also say that while FIX2 is the messaging standard at trade level, Swift is the back-office messaging standard. But back to your question, one would have expected that Swift would be timely in introducing a solution for connecting fiat currency payments’ messaging infrastructures with CBDC networks. There will soon be relevant use-cases, as central banks are progressing with developing digital currencies. It is fair to say that creating a link between the existing Swift platform and CBDC is probably not the most challenging task from a technical standpoint; the complexity in this case will arise from the heterogeneity of CBDC platforms. And this complexity will rise exponentially with the number of different CBDC platforms involved.
Could you please explain why?
Classic transaction lifecycles involve a multitude of messages that need to be sent between counterparties while their proper processing requires a common understanding of what a specific data field refers to at any time. Currently, the Swift MT3 standard is used for international payments, cash management, trade finance and in treasury operations. Starting in March 2023, Swift will kick off the migration from MT to ISO 200224 for cross-border payments and reporting with a coexistence period with MT messages until November 2025. Keep in mind, Swift has conducted its experiments based on ISO 20022 which is not yet an industry-wide adopted standard. MT knows ten main message text categories with dozens of sub-categories and up to 150 fields per message depending on a transaction’s complexity and there will be a transition period of two and half years. But let’s assume ISO 20022 is adopted at the time of a CBDCs introduction and there are no data consistency issues left. Still, this would leave conflicting conceptual design specifications and legal aspects of different CBDCs unconsidered. Non-compatible regulatory technical standards, different technical platforms and multiple interfaces would still remain serious challenges.
Are there additional aspects to consider and what has been Swift’s approach to solve these issues?
In its simulation, Swift used two different DLT networks5 to demonstrate the interlinking between different CBDC networks and an RTGS6 network to show the flow between a CBDC and a fiat currency network. They also did this on a cross-border basis. In addition to the standardisation and connectivity issues discussed, payments will always involve personal data, triggering applicable regimes such as AML/CFT7 legislation with all their associated processes, simultaneously with potentially conflicting data privacy laws. Hence, the prerequisites Swift set were, on top of using ISO 20022, that connector gateways were run and operated by the network operators. These gateways were run on a regulator node and worked as interface for the traffic between the CBDC network and Swift. The operators had to implement the Swift rulebook and adaptors, too, to communicate with their network participants. In the experiment, these were a bank and an intermediary for each network and Swift PKI, a proprietary certification service, in order to safeguard interoperability. The execution of payments within a CBDC network was based on smart contracts, implemented by the network operators. Thinking of the digital euro project – which will not be implemented based on decentralised ledgers – it is important to mention that Swift said it successfully tested the implementation of the connector gateway in non-DLT infrastructures, too.
Swift made another announcement concerning the interlinking of multiple tokenisation platforms…
Although from today’s perspective the relevant use cases seem a bit more remote than cross-border CBDC payments, facilitating interoperability between tokenisation platforms can have a significantly bigger impact in the long run. Swift tried to use its infrastructure to simulate primary market issuance and secondary market transfers of tokenised equity and debt instruments and cash using different tokenised assets and cash settlement environments. In other words, proving their ability to create, transfer and redeem tokens including updating multiple client wallets. Here, the aim was again to include interoperability between old and new settlement infrastructures and between real assets and tokenised assets. However, Swift did not just want to demonstrate whether it is possible to facilitate interoperability at all, but also whether a number of features attributed to DLT will really materialise. Among those features are fractionalisation, which is very relevant to retail investors as it enables, for instance, systematic regular investments for savings purposes, ownership of high-value securities or illiquid instruments, thus increasing liquidity in low turnover asset classes. Swift also tested tokenised assets’ programmability, the extent to which end-of-day reconciliations can be removed or reduced and some more: most notably from my perspective, the token-inherent feature of instant settlement. Swift showed atomic settlement is possible even in the case of tokenised assets being settled against CDBCs and even across platforms, i.e., where issuance, trading and settlement take place on different platforms.
How do you rate the results of Swift’s experiments?
In extremely simplified terms, you may say that you have a multitude of different technical ecosystems which are unlikely to sufficiently converge anytime soon. Plus, there are as yet no signs of one DLT platform becoming a common standard for application throughout money and capital markets and across various transaction types, let alone for use cases beyond finance. Consequently, standardisation can only work in a kind of bottom-up approach, i.e., where there has been a natural need for standardisation before and where single knots and endpoints can switch to a new technology platform without undue disruption. ‘Undue’, in this context, refers to the fact that a new technology may promise tremendous progress and workflows which are hundreds of times more efficient, however, as long as too many upstream and downstream processes must be changed, with many implications being unaddressed – this promising use case will have to wait. Like the idea of parcel delivery via drones or robots or city skies full of helicopter taxis.
The innovation brought forward by Swift has to be seen in this light. The multitude of DLT and CBDC projects underway and the different paces of their adoption has been threatening to move opposite to one of the technology’s goals, which is reducing fragmentation. In demonstrating the feasibility of a defined standard which doesn’t constrain the development of other ecosystems, it can amplify progress in exactly these ecosystems, thus leading to a faster overall adoption of DLT.
Thank you very much!
1. Central Bank Digital Currencies
2. Financial Information Exchange
3. Swift message text
4. Standardisation approach (methodology, process, repository) to be used by all financial standards initiatives developed by the International Organization for Standardization
5. Corda and Quorum
6. Real Time Gross Settlement (such as the ECB’s TARGET2)
7. Anti-Money Laundering and Countering the Financing of Terrorism
