We then look at Szabo´s definition of smart contracts, especially the verifiability, observability, privity and the enforceability conditions. In the following we discuss Szabos conditions in the context of smart financial contracts and distributed ledgers. We especially enquire whether distributed ledgers are necessary and/or enough condition for the existence of smart financial contracts. The answer is rather no, if this does not coincide with an algorithmic standard. This leads to the conclusion, that mean a public or private ledger of my personal trust be it implemented with block-chain or another technology.
The next move of FinTech must be in the area of adopting such a standard in order to make progress. We believe that the combination of distributed ledger technology and an open, well documented and well tested algorithmic standard is the next logical step in FinTech. In order to understand the role of the financial contract within the system of finance we discuss in an excursus the meaning of the term “finance” and the role of a Touring complete language for the existence of smart financial contracts. The article does not discuss block-chains and distributed ledgers in detail. With distributed ledgers we Szabo introduced the term “smart contracts”, whose more precise definition we will see in the next section. In this paper we narrow down our focus on “smart financial contracts” due to their unique features within the universe of contracts.
The unique features of financial contracts are:
• The inherent mathematical nature of financial contracts. Financial contracts are like no other contracts definable and in practice defined in mathematical terms.
• Financial contracts are
• These features make financial contracts the prime candidates for smart contracts since the agreement can be represented by computer writable algorithms save for some cases of default. They are not only representable by algorithms, they are – since cash is exchanged for cash – in general also much simpler than other contracts. The set of existing financial contracts is also of high relative importance within the universe of contract which justifies taking a closer look at this sub-set which is another justification for taking a narrow focus on smart financial contracts only.
Szabos definition of Smart Contracts In his 1996 article , Szabo defined smart contracts as “a set of promises, specified in digital form, including protocols within which the parties perform on other’s promises”. He lists besides technical features, four conditions or objective for a contract to be a smart contract which are:
• Observability, the “… ability of the principals to observe each other’s performance of the contract”
• Verifiability, the “…ability of a principal to prove to an arbitrator that a contract has been performed or breached”
• “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”.
• Enforceability These are the conditions we will take a closer look at in the following The Enforceability and Privity condition Of the four conditions, the enforceability condition is the most difficult one to meet. Even Szabo recognizes it in his article. He introduces the term as follows: Enforceability, according to the statement, cannot be attained absolutely but can only be maximized by making the contract as verifiable as possible. We believe this to be true for all the contracts and especially true for the financial contract. Some examples of enforceability have been forwarded such as the car that cannot be started if the payments on the leasing contract have not been fulfilled. We doubt that even such a simple mechanism can be implemented in a realworld setting and legal system.
While this is in doubt even for straight forward contracts, it is clearly impossible for financial contracts if stated in an absolute form. Finance is cash today for cash tomorrow where the payback follows some rules, such as the amortization of a mortgage, the payment at the strike date of an option and so on. Such a promise can only be enforced with 100% certainty with a cash down-payment at the initiation of the contract. However, if the debtor must pay down 100% in cash then there is no reason to enter a financial contract, to begin with. Banks have solved the problem with solutions that come close to enforceability, however not absolutely. This is done with collateral such as a house which must say 125% of the value of the mortgage at the date of issue, cash-collateral as in future exchanges and guarantees. These mechanisms work almost all the time,
The smart financial contract will further minimize failures in enforceability, but not fully eliminate it. Regarding the privity condition we rather doubt, whether public distributed ledgers based on today´s blockchain technologies do fulfill it. There might be blockchains that are better in this respect. However, the two most wellknown examples Bitcoin and Ethereum do not fulfill this in a satisfactory manner. Once the public account ID is known all movements are known. Even if it is difficult to obtain the account ID, it is not impossible.
Even if distributed ledgers can fulfill the privity condition better than the current banking system, it is in doubt, whether this advantage will sustain over the long term, at least for the nonblack money part. Cryptocurrencies are facing problems because they are tainted with blackmoney. This makes it in many countries impossible and in the other countries at least very difficult to connect to the existing “fiat” systems. The price of connection to the fiat system is most likely less privity. Thus, regulation will rather make it more difficult for distributed ledgers, to keep an advantage in terms of privity. Conclusion: If we compare the current financial system with the distributed ledger technology regarding enforceability there is no advantage, since it is not attainable due to the logic of finance. In terms of privacy we see problems on both sides and we will have to see, whether distributed ledger, especially the public ones, will be able to keep an advantage.
In the next sections, we will focus on observability and verifiability within a distributed ledger framework. Are distributed ledger technologies necessary and or enough condi
Since – according to Szabo – enforceability is maximized through verifiability, the question is of great interest. Regarding observability, distributed ledgers offer indeed an unmatched insight to all participants. This high level of observability however can be an undesirable feature in the financial sector, at least with respect to public ledgers. Private ledgers however can avoid this disadvantage. Although it is a true advantage, it must be taken with a pinch of salt. As it stands currently, blockchains keep track of accounts in cryptocurrencies like what payment systems like Western Union, Visa, Postal Systems and of course also banks. When considering the performance of the financial system in terms of account keeping since the Middle Ages, it is astonishing, how reliable the system has been. Even in the late Middle age, it was possible to make the payment in Florence and to pay the cash in Bruges. Ledgers were kept with an astonishing diligence even then, making international trade possible. This has improved ever since. Personally, I do not know a single person, neither do I know a person who knows another person that has been deceived by a bank with regards to account keeping. The reasons why it functions so well are first the four-eye principle, secondly, the reputational damage to any bank or payment service provider, if records were not kept properly and finally the insurance of deposits.
Considering this excellent performance of the financial sector over the centuries, the advantage of the blockchain is less than it is commonly assumed. Nevertheless, we consider the impersonal trust offered by distributed ledgers as an advantage and, we could say, a necessary condition for smart financial contracts. This is especially true in areas, where trust in a financial sector continues to be an unsolved problem, leaving a large proportion of the population unbanked. What about verifiability. In order to discuss this question, we must make a little digression.
What is Finance? The role of a touring complete language. What is finance? We mentioned already, that the current state of distributed ledger or FinTech in a larger sense, is concerned with payments, a sector which is already well covered and efficiently solved by traditional systems. More importantly, payment systems can, at the best, only be considered a fringe activity of finance. Most of the payments are not even done through banks but other services: Western Union, PayPal, Visa etc. and of course cash payments. Finance means giving loans, Mortgages, depositing money for interest, issuing bonds, doing swaps, futures, and options. All these activities trigger and make possible real economic activities which otherwise would not happen. Houses are built, rail tracks are laid and so on. All these financial activities have in common, that they move cash over time following some rule. In a mortgage, as an example, the house owner gets money which must be paid back over time including interest. Smart financial contracts must represent these financial contracts. Thanks to the mathematical nature of financial contracts, they are the prime candidates – the low hanging fruit – to be represented as smart contracts. They are, in the language of Szabo “a set of promises, [that can be] specified in the digital form, including protocols within which the parties perform on the other promises”.of course also banks.
The proposed solution for blockchains with regard to smart contracts has been to offer a Touring complete language which means a powerful computing language with commands on the level of Java, C, and similar languages. Is this the solution? The answer is No. Yes, it is possible to program any financial contract and substitute most lawyers jargon with exactly defined algorithms. However, the problem with Touring complete programming language: they are too wide, too open. Financial contracts are well defined and follow a very limited however strictly defined set of mechanisms. Unnecessary openness can only lead to problems. The current observable chaos found in the financial sector is a consequence of the fact, that the problem is solved with open, Touring complete languages without any standard representation of the algorithms. The same bond, mortgage or loan is represented in different programming languages, different naming conventions for the attributes and differently programmed. This is the reason, why it is often almost impossible to reconcile data within banks. Reconciliation is associated with tremendous cost and induces low quality, a problem that should be solved by FinTech with the introduction of a smart financial contract based on a standard.
The tragedy is, that the banking business does, in fact, follow standards, however, the standard is unknown. How is this possible? Financial contracts are first written on paper in legal language. In order to manage them, they are represented in core banking or transaction processing systems. Each system is based on a Touring complete language and implemented in endless variations producing a chaos at the aggregate level. The good news however: the number of patterns of exchange of cash and their associated algorithms – let´s call them Contract Types is limited, and it can be handled. This is possible, because banks do follow standards in practice but not on the level of code. What is needed therefore is a standard representation of the algorithms that make up the financial contracts and the associated parameters. Space does not allow to go into further depth and we refer to the ACTUS website. Coming back to the question of verifiability: Financial contracts to be verifiable must be based on well defined, standardized, openly published and well tested reference code.
A Touring complete language does not fulfill this per se, but in combination with what we just said, can do so. Blockchains definitively will increase the verifiability of smart financial contracts based on a standard. However, to call it an absolute necessity would go too far. Such well-defined contract can live outside a blockchain as we will see in the last section. We will describe there also an optimal solution regarding on- and off chain implementation. Are distributed ledgers a enough condition for observability and verifiability? The general answer: It can be enough with a well-defined standard. As a corollary follows, it is not enough in absence of a standard. Having a standard representation or a Contract Type for every financial contract, we can imagine the following system:
Each Contract Type is implemented on a given blockchain Parties can now agree to enter in a financial contract on the blockchain according to following steps:
• Select the Contract Type, for example for a mortgage they would select an Annuity Contract Type which is capable to calculate the payments.
• Define the contract terms, such as national interest rates, maturity date and so on
• Since the code which generates all payments is knows, it would be possible to do a pre-deal checking by executing all hypothetical payments.
• Once both parties agree on the expected payments, the deal can be executed by signing it on the blockchain.
• Each payment would be calculated automatically
• Whenever the payment would be due, the payment could be automatically executed (depending on available funds however) or both parties could accept the new state manually
• The new state is recorded on the blockchain
• Would the mortgage be for example variable, the contract would update its state at each rate resetting date? This could happen via an oracle of a market data provider
• Since all events have been known beforehand, the verifiability condition has been met to the maximum level, leaving hardly a possibility for dispute except in the case of default.
• Such an architecture makes the contract observable, verifiable and enforceable to the maximum extend.
• While this is conceptually possible, it is at least currently – not a feasible solution at least on the public blockchains which are not scalable and too expensive to run. An efficient, scalable, pragmatic way forward Before sketching a pragmatic solution, we must expand yet the concept of finance. Further up we discussed finance on the level of financial contracts which are exchanges of cash over time following some rules of exchange. Would this be the only problem of finance, blockchains might be able to handle it at least in a foreseeable future. Banking however is more than executing and managing financial contracts. In addition, it is understanding the impact on liquidity, value and income along the timeline.
These are the management or analytic function of banking which can be grouped into:
• Finance: Accounting, profit loss analysis, budgeting and planning
• Risk management: All types of risks such as market, credit etc. and all sorts of techniques from stress scenarios to Monte Carlo calculation
• Regulatory reporting: All regulatory reports All these functions are based on the very same cash flow patterns or Contract Type logic as used on the transaction level. This feature which makes the expensive interfaces between all supplications superfluous is the main benefit and the big cost saver for the industry, since it will solve the reconciliation problem once for all. However, while based on the same data, code and logic, the necessary computing power is much bigger in these areas. Such calculations are only feasible off-chain. Also, it is very likely, that a specific bank would not execute all transaction on a single blockchain. This would again need an area, where all financial contracts are consolidated from the different blockchains and possible contracts managed entirely off-chain. These are the reasons that demand a more pragmatic approach.
The center of the approach is the Contract Type standard which makes a specific financial transaction equally understandable by all involved parties be it on or off-chain. The pragmatic solution could look as follows:
• The reference code per Contract Type can be stored on the block chain. This could be in form of a hash-code of the reference implementation or an implementation in the specific language
• The initial contract parameters are stored on the blockchain
• Calculation for transaction processing and analytics happen off-chain.
• Payments are executed on the blockchain
• Contract states are updated after each event By signing (either individually or bulk acceptance) the updated states, it becomes always clear that the parties agreed at latest to that stage. By having a reference to the Contract Type, it becomes virtually impossible to dispute the agreement. The center stage of this solution is a standardizer smart financial contract based. Combined with the single source of truth based on a distributed ledger can revolutionize finance. This is a necessary step with the potential to reignite Fintech, blockchains and digital ledgers and bring it to its full value.
1 Nick Szabo, Building Blocks for Digital Markets, (retrieved 20180822) http://www.alamut.com/subj/economics/ni ck_szabo/smartContracts.html
2 More detail can be found in Brammertz Willi, Mendelowitz Allan (2018) From digital currency to digital finance: The case for a smart financial contract standard “The Journal of Risk Finance” volume 19, issue 1.
3 These algorithms may contain links to external risk factors such as interest rates in a variable rate contract. In this case the links are known but the effective state will only be known at the time of the event.
4 Cash is a unit of account and thus one dimensional. Buying say a car involves hundreds of dimensions beginning with the color, the seats etc.
5 Nick Szabo, Building Blocks for Digital Markets http://www.alamut.com/subj/economics/ni ck_szabo/smartContracts.html (retrieved 20180822)
6 Szabo discusses additional considerations. We list here only the important ones for our argument. Especially we leave out the more technical considerations.
8 Which of course can be zero.
9. The most recent failure was the CDS´s issued by AIG after the Lehman collapse. Only a huge bail-out action by the US government could avoid it.
10. It is probably true that one of the reasons of the success of the blockchains is black money. It is probably also true, that it is not easy to find out the owner of an account. Nevertheless, there are possibilities to find out with sufficient efforts. Consider the case, where a bank does transactions on a public distributed ledger. Any employee involved in the transaction would know the ID and would be able to see all information even after leaving the bank. The many thefts also prove, that the system is not waterproof, even if in many cases some carelessness of the participants may be blamed.
11. This does not mean that banks do not fail and that everything banks are doing is perfect. However, account keeping is not a problem due to the stated reasons.
12. Interesting detail: The financial contracts handled in the core banking and transaction processing systems of the bank fulfill Szabo´s condition of being “specified in digital form, including protocols within which the parties perform on the other promises”. The protocol however only defines the payments, not the entire life cycle of the contract.
13. Banks follow standards implicitly but not consciously.
14 www.actusfrf.org. The ACTUS standard represents these financial contracts. Please note, that the standard is not an invention but a discovery since the banks do follow standards in practice but not on the level of code. The website is organized as follows: In the “Taxonomy” gives an overview on the different Contract Types or patterns of exchange. The “Data Dictionary” offers describes all attributes and the “Technical Description” the exact algorithms. In “ACTUS code” the code is downloadable based on some information and “Demo App” offers an easy way to test code.
15 There is a first implementation of a single contract Type on Ethereum. IT follows the ACTUS standard but needs yet to be accepted by ACTUS.
16. ACTUS has defined a validation process to do so.