11th February, 2022|Ralf Kubli, Board Member at Casper Association
By Ralf Kubli, Board Member at Casper Association
Blockchain-based financial applications are considered to be the future of the financial system. Switzerland has the best prerequisites for assuming a leading role in future global capital markets. However, this requires further thinking than ever before.
From banking the unbanked to lower fees and personalised, consumption-based insurance, blockchain-based applications are intended to renew legacy systems and replace all intermediaries.
The solution to this should lie in the tokenisation of everything. Cars, Picassos, videos, blueprints and digital art are just some of a long list of assets that may be tokenised, resulting in easier trading and securitisation. But while the boom around Non-Fungible Tokens (NFTs) proves that there is a market for native digital art in the form of tokens such as CryptoPunks or Autoglyphs the tokenisation of financial instruments is still in its infancy.
This is astonishing, given that the financial industry is in the best possible position to benefit from blockchain technology, thanks to the algorithmic nature of financial contracts. The benefits derive from the way blockchain (and Distributed Ledger Technology DLT) works. These include instant settlement (also pointedly described as “the trade is the settlement”), optionally programmable transparency or confidentiality, automation of processes and verifiability.
Nevertheless, there is a great deal of blockchain activity in the payment area and in the custody of digital assets, where Swiss companies are global leaders both technologically and because of their location.
Meanwhile, the infrastructure for blockchain-based money and capital market transactions is still in its infancy. Secondary markets for tokenised financial instruments are just emerging, and there is still little momentum developing on the primary issuance market. With the Distributed Ledger Technology (DLT) Act, Switzerland has laid the foundation for a global leadership role in the future blockchain-based capital market.
Although the legal requirements have now been met with the legal register value in Switzerland for the tokenisation of financial assets, the technical and content-related implementation at the core falls far short of the mark. In fact, there is a risk that the new infrastructure will result in an even more chaotic and fragile system than we have in place today.
Insufficient machine readability produces Dumb Tokens
Most security tokens that represent financial assets are very limited in functionality, some would even say dumb. Issuers and trading venues mostly focus on technical questions about the token itself: How can the token be traded? How and where is it kept? Who has access to the register in which ownership is recorded, when and how? What about delivery vs. payment? What denominations are allowed?
These are all important questions for the functionality of the new infrastructure. However, these tokens usually say nothing or very little about the nature and properties of the actual financial value that is exchanged on these trading venues. In order to realise the potential for fundamental innovation of the new DLT-based capital markets, the technical implementation of a security token must be more than just an entry in a DLT register that points to an electronically stored piece of paper, like a term sheet in PDF.
The following three scenarios show what the situation looks like today, the confusion that results from the individual programmability of tokens and what the future should look like with smart financial contracts on blockchains.
The current reality in the world of security tokens
Let's take a bond that is offered as a security token on a trading platform as an example. Thanks to the properties of the blockchain, a buyer can now buy a token with T+0 (i.e. immediately). However, how the future cash flows of this bond are defined and what valuation results from them must be compiled by analysts in detail from the written term sheets and then calculated (mostly in excel).
This calculation and reconstruction of future cash flows to determine a financial value under certain assumptions is also the norm in mature and existing markets. Only here, with Telekurs, Bloomberg, Refinitiv and the likes, there are already suppliers of information who relieve buyers of a certain part of the tedious detailed work in return for payment of fees.
The future will be more complex than the present
As a second example, let's assume that an issuer of security tokens - in addition to technical aspects such as custody, trading, denomination has also given a description of the cash flows in digital form, i.e. formulas (e.g. interest payments in a bond, amortisation for an annuity). Numerous attributes such as day count method, interest calculation, terminal value calculation, cap and floor would then have to be defined here and linked consistently with the cash flow generating algorithms.
It is doubtful that inexperienced blockchain programmers can consistently map all aspects of a financial instrument here. Even if a complete description were given, there is a risk that each tokenisation platform or even each issuer or programmer will design the description of the cash flows of the respective instrument (e.g. a bond) according to its own definition. Each security token would then be like a small core banking system with its own definitions and calculation methods for itself. The result would be thousands or millions of differently defined bonds, listed on DLT-based trading systems, impossible to understand for the professional user.
Such complexity is not manageable for man or machine with reasonable effort. And in such a world, the Big Four among the accounting firms would then have to be hired again as assurance service providers (e.g. is Bond XYZ consistently programmed? How are Cash Flows calculated? What terminal payment amount is due when?). Likewise, the long-serving and new information suppliers would have to step in as translators of term sheets.
In such a scenario, security tokens would only be comparable with great effort and would not be interoperable. A denomination and securitisation of portfolios from different issuers at lower costs than in today's complex legacy world would be simply unrealistic. The result would be a lack of liquidity on DLT-based trading venues. The new tokenised version of the capital markets would thus be a bad and much more chaotic copy of the current system. The adoption of the new infrastructure financed by investors would be called into question, because why should financial market players switch to these new systems at all if no lower costs and no higher degree of automation can be achieved?
Unfortunately, there is no prospect of a substantial automation and complexity reduction of the financial instruments traded on the currently planned and existing DLT systems. This is not due to the technology providers, but to the players in the financial world who are missing or have not yet discovered the core of their task: the exchange of value (calculated from cash flows over time) by the means of a financial contract. The return to this fundamental component of finance must also be the basis for innovation in the new DLT and blockchain-based world (see an introduction to smart financial contracts here).
The smart financial contract on the blockchain
The term smart contract is used imprecisely in the blockchain world. Anything programmed on a blockchain is called a smart contract. Vitalik Buterin himself, one of the co-founders of Ethereum, regretted introducing this term in 2018. A programming language is a necessary but not sufficient condition to define smart contracts. In order for a piece of software (e.g. a token) to actually become a smart contract, programmability alone is not enough. In addition, Nick Szabo's terms and conditions for Smart Contacts must be observed. One can speak of a smart contract when the following four conditions are met: observability, verifiability, privacy and enforceability.
The efficiency of the new infrastructure results from the observability on the blockchain and the verifiability of the contractual agreements on the basis of a standardised, well-defined, published, programmed and independently verifiable financial smart contract.
Applied specifically to a bond, this means that past payments must be verifiable. Likewise, the expected cash flows in the future (e.g. when an interest payment from one party to another party is due) must be machine-readable and machine-executable in the smart contract. Otherwise, a review of the terms of the contract cannot take place automatically. This verifiability of the cash flows results from the properties of blockchains and the use of the open source ACTUS standard which defines the cash flows. Based on these cash flows, all relevant financial information can be derived, such as financial values under different valuation methods, income, sensitivity and risk.
The intelligent security token
In addition to the misconception that the programmability of a token is sufficient to generate a smart contract, the "tokenisation of assets" causes confusion. What exactly is tokenised? With a CryptoPunk, it is the native digital art that one owns through the token. With a bottle of wine offered on a marketplace, possession of the token controls a defined right to it. For investments such as real estate, the token often represents shares in a special purpose vehicle. In all of these cases, only the asset side is shown.
In the case of financial contracts, which are represented by means of an intelligent security token, it is about the agreement of counterparties to exchange cash flows over time. In finance, therefore, the presentation of the liabilities and assets side is mandatory. In order for DLT and blockchain-based systems to really deliver on the promise of innovation in finance, at least three requirements must be met:
1) Information about which party holds the liability.
2) The information which party holds the asset side.
3) A definition and algorithmic description (i.e. mathematical representation) of the contractual arrangements from which the future paymentss are derived (e.g. through the ACTUS standard)
The key to the success of the new DLT-based infrastructure of the capital markets lies in the complete readability and executability of these contracts by machines. Combined with the properties of blockchains, there is always clarity as to which parties are obligated to make payments and which parties have the right to receive the payments. Thanks to the algorithmic definition of the cash flows by the ACTUS standard, the value of the financial instrument can be determined at any time in near-real time, taking into account external risk factors (market risks, counterparty risks, behavioral risks).
The promise of automation reducing complexity and costs, especially in trading and in the securitisation of DLT and blockchain-based financial instruments, can only be fulfilled with smart financial contracts that have these properties.
Conclusion
With the focus of blockchain applications on payments and the confusion arising from the tokenisation of assets, there is a risk that the emerging blockchain-based infrastructure of capital markets will degenerate into a poor copy of today's financial system.
Instant settlement and transparent ownership of tokenised financial instruments on DLT platforms only, will not be sufficient for widespread adoption of this new technology.
Smart financial contracts, which verify the current state of payments, future cash flows and the ownership of the asset and liability side for machines to process and execute, are the decisive prerequisite for achieving the expected advances through the blockchain in finance.
Notes and further reading
This formulation comes from Guido Bühler, CEO of Seba Bank AG, who describes the blockchain-driven transformation in the finance sector with the following aspects: 1) Blockchain is the most efficient transfer of ownership 2) The trade is the settlement 3) The private key is the perfect collateral, and 4) tokenisation is originationNick Szabo on Smart Contracts, 1996: http://www.alamut.com/subj/economics/nick_szabo/smartContracts.html
A smart contract exists when the following four conditions are met: observability, verifiability, privacy, and enforceability )
1) Observability, the ability of the principals to observe each other's performance of the contract, or to prove their performance to another principal
2) Verifiability, the ability of a principal to prove to an arbitrator that a contract has been performed or breached, or the ability of the arbitrator to find this out by other means
3) Privity, the principle that knowledge and control over the contents and performance of a contract should be distributed among parties only as much as is necessary for the performance of that contract
4) Enforceability, and at the same time minimizing the need for enforcement. Improved verifiability often also helps meet this fourth objective
On the subject of Actus and Smart Contracts: Dr. Willi Brammertz, presentation at the UZH Blockchain Center of the University of Zurich: https://www.blockchain.uzh.ch/events/industry-talk-actussmart-financial-contracts-the-future-of-capital-markets/
Open source algorithmic financial contracts : www.actusfrf.org
On the topic of DLT law: developments in Swiss blockchain law. Edited by Rolf H. Weber, Hans Kuhn, 2020. https://www.helbing.ch/de/detail/ISBN-9783719044251/Entwicklungen-im-Schweizer-Blockchain-Recht
On the subject of delivery vs. payment and settlement - Jura project: https://www.bis.org/about/bisih/topics/cbdc/jura.htm
Introduction to tokenisation: University of Basel Center for Innovative Finance. Prof. Dr. Fabian Schär https://www.youtube.com/watch?v=kcpZd3QqS4Q&list=PLoVRRjQbqYFyV6DQtoNlCbnp3QrvSITPi&index=15
Federal Council report: Federal Council, Legal basis for distributed ledger technology and blockchain in Switzerland. An overview with a focus on the financial sector (Bern, December 14, 2018). «DLT report» https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-73398.html