Smart contracts: a new era for derivative trading or a false dawn?
Monday 13 August 2018
The rise of new technologies and artificial intelligence has the potential to fundamentally reshape derivatives trading infrastructure, but will the derivatives industry decide to embrace innovation or is the technology too perilous in nature to facilitate large scale financial transactions?
The software available today can allow for the reduction of the inherent operational risks and streamline the increasingly cumbersome processes that are now commonplace in derivative transactions. Key to this potential derivatives upheaval are smart contracts and their ability to harmonise with Blockchain technology. It is these new technologies working in unison that can ultimately transform how derivatives are executed and how they are managed throughout their entire lifecycle. In this article, I consider the fundamental issues facing users of smart contracts and Distributed Ledger Technology (such as terminology, automation and enforceability) and discuss the possible uses of this technology in redesigning derivatives infrastructure.
What are smart contracts?
Nick Szabo, a computer scientist and legal scholar, first coined the term ‘smart contract’ in 1994. In essence a smart contract is a computer programme that allows a user to facilitate, verify and enforce the pre-requisite terms and performance of a contract. A smart contract is “automatable” rather than “automated” because in practice there may be parts of a legal agreement that require human input and control. However, to be a “smart contract” it requires that some part of the agreement is capable of being automated (otherwise it is not “smart”).
Smart contracts and Distributed Ledger Technology (DLT) are often talked about in the same breath but are in fact distinct technologies – albeit complimentary and, in some instances, symbiotically linked. Although DLT will be discussed later in the article, it is important to note that the advent of DLT has created a platform on which smart contracts can be hosted and executed, bringing smart contracts into the conventional thinking of both FinTech entrepreneurs and financial conglomerates.
Being best suited to platforms that are built on systems with clear rules and quantifiable terms of agreement, naturally this structure lends itself to the financial industry. For instance, a bond could have a smart contract attached to it that automatically executes interest payments on the payment date, and the amount to be paid is determined on the basis of data retrieved from a predefined, reliable source (a distributed ledger). Furthermore, parties might enter derivative contracts electronically; the relevant building blocks of that programme would automatically be taken and assembled from a library of predetermined contractual programmes. The smart contract could be designed so as to automatically cater for due payments to be executed and to adjust collateral levels between the parties. Upon termination of the contract, the programme could autonomously calculate the termination amount due to be paid. Again, these payment amounts would be calculated based on reference data sourced from a predefined, reliable data provider.
Blockchain and Distributed Ledger Technology
The term ‘Blockchain’ is often used as a synonym for Distributed Ledger Technology (DLT); however this is not strictly accurate as Blockchain itself represents just one type of DLT. A distributed ledger is a digital record that is shared instantaneously across a network of participants. It is ‘distributed’ because the record is held by each of the users on the network and each copy is updated with new information simultaneously. DLT also uses a consensus to ensure every user agrees on the data of the shared record. A key advantage of DLT is that there are not multiple competing sets of records that need to be reconciled but just one, albeit that this single record is maintained on [the servers of] multiple users. This one record represents the golden source of data for any business harnessing DLT in their infrastructure.
Distributed ledgers can either be ‘permissionless’ or ‘permissioned’, which usually also corresponds to being ‘public’ or ‘private’. It is probable that work in the financial markets that will involve distributed ledgers will have ‘permissioned’ (private) access for the market participants largely due to the commercial sensitivity of the data encompassed. Participants in transactions such as these do not necessarily want everyone else to be able to see every piece of data on the network and as a result the distributed ledgers in question have evolved so that the data on the ledger is masked in such a way that they only see the specific data relating to them and the respective transactions (although certain entities, such as regulators, might have access to all the data). While this is useful for ongoing management of the distributed ledger, it inevitably introduces a degree of centralisation to what is otherwise a ‘distributed network’.
The technology has not been without its teething issues. In June 2016, the Decentralized Autonomous Organisation (DAO), an investor-directed venture capital fund which ran on the Ethereum Blockchain, was hacked for 50 million dollars when vulnerability in its code enabled users to siphon one-third of the DAO’s Ether (the cryptocurrency used in Ethereum). In a controversial decision, the Blockchain community decided to ‘hard-fork’ Ethereum, essentially restoring all funds back to their place prior to the hack. This decision drew some scepticism about the reality of a distributed ledger being as ‘de-centralised’ as previously touted and many viewed it as a serious violation of the principles that underline the nature of Distributed Ledger Technology.
The complimentary relationship between smart contracts and DLT does however create new pathways that were never initially envisaged for smart contracts. The advent of computers has always allowed (or made possible) for contracting parties to program a computer to automatically execute an event, such as payment under a contract upon satisfaction of pre-defined conditions (for example, stock price hitting a predefined price/target). However, combining the two technologies renders transactions as traceable, transparent and largely irreversible, absent a change in the underlying rules of that Blockchain.
Operational versus non-operational
Before considering how smart contracts can facilitate legal documentation (and specifically, ISDA documentation), it is important to consider the different types of clauses within legal agreements. Not all clauses lend themselves to automation and self-execution. Even where a clause might technically be capable of being automated, it might not always be desirable to do so. Looking at a legal agreement in a purely linear perspective, it can be analysed as containing operational and non-operational clauses. Operational clauses are those which embed some form of conditional logic. For example, upon the occurrence of a specified event, or an event at a specified time, a deterministic action is required. These types of clauses are at the heart of any financial contract.
In contrast, non-operational clauses are those that do not embed such conditional logic but that, in some respect, relate to the wider legal relationship between the two contractual parties. Examples of these clauses would be: a clause specifying what jurisdiction any disputes may be brought in or a clause that dictates that when making a decision or a determination, the person making the calculation shall do so in good faith and in a commercially responsible manner. Instead of always being a matter of fact, or eventually giving a predefined or definitive answer, non-operational clauses are more in the domain of subjective outcomes rather than an objective one. Clauses less susceptible to being expressed in machine-readable code will subsequently require the greater need for legal interpretation or definition; herein lay the crucial challenges of smart contract implementation.
Although non-operational clauses are less susceptible to being expressed to conditional logic, this does not mean they cannot be expressed in some kind of formal manner that would allow computer software to be able to interact with them in a useful fashion. By modelling the information and relationships that are contained in a contract in a formal way or formal arrangement, it raises a wider range of possibilities for a useful application of computer technology to such a contract.
As previously discussed, derivatives contracts are a prime candidate for the application of smart contracts and DLT mainly due to the fact that the majority of their payment and deliveries functions are heavily dependent on conditional logic. If we were theoretically to implement smart contracts into a modern day derivatives framework, how can this be achieved?
Fundamentally, like any financial contract, derivatives operate from data or information between separate parties. Implementing a distributed ledger which could store data on the transactions between parties can provide the raw materials upon which the smart contract can subsequently perform. The smart contract element would relate to the legal agreement and the execution of operational flows and the DLT element relates to the recording and updating of a real-time single source of data and the hosting of the smart contracts.
The likely scenario is that the parties will still enter an ISDA Master Agreement and Schedule drafted in Conventional written text. However, parts of the ISDA Definitions booklets that set out the terms used in defining payments and deliveries would have to be re-written to a more formal representation of the computer code which underpins the derivatives agreement. Nevertheless; developing this set of code with explicit reference to the needs of ‘smart legal contracts’ has proven problematic. At a high level, the legal language in contractual agreements has been developed and formulated over generations, developing another gold standard is remarkably tough for lawyers, who are for the majority, without a coding background. Consequently there is a need for the development of a consistent, non-ambiguous language (code) used for the drafting of smart legal contracts.
The fundamental obstacle to widespread implementation of smart contracts in the near future is the lack of an industry standard of such a code. ISDA are for instance looking at utilising existing frameworks, including their financial products Markup Language (FpML), which is a business information exchange based on Extensible Markup Language (XML) that enables business-to-business over-the-counter (OTC) financial derivative transactions. Their CEO Scott O’Malia has indicated a positive outlook in relation to smart contracts when discussing their incorporation into ISDA documentation structure. O’Malia reiterated the viewpoint that ISDA believe smart contracts do have the potential to unlock value in the derivatives market by offering significant cost and efficiency benefits.
While the transition to formal implementation will not be straightforward, certain operational clauses – those related to payments or deliveries, for instance – might lend themselves to being automated in the near future. Other, more subjective clauses will require interpretation or discretion, and will therefore prove more challenging. ISDA now however is taking the critical step in the process by reviewing and updating the ISDA documents and definitions, with the aim of standardising and formalising certain clauses to enable them to be more easily represented and executed by smart contract code. This work to future-proof will start with the 2006 Definitions for interest rate and currency derivatives. To lead these developments, a new ISDA legal working group has been set up specifically to focus on smart contracts and distributed ledger.
O’Malia has since stated: “ISDA is working to educate the market, but also to establish industry consensus on the application of operational and non-operational contract elements. There will be instances where specific elements of the contract can be fully automated, but other elements where natural human language must be applied. Our working groups will unpack these issues, and ISDA is committed to developing industry consensus so there is continuity across platforms.”
Practical examples of smart contract implantation
A consortium of nine major European banks has chosen Dublin for the base of their Blockchain initiative. The We.trade group includes financial giants such as HSBC, Deutsche Bank and Santander. We.trade facilitates cross-border financial trades using its Blockchain platform. The decentralised ledger it uses records and verifies all transactions and currently trades across eleven European countries, the trades processed were the first “commercially viable open account trades” using Blockchain technology. We.trade facilitates the trades using smart contracts to launch and administer agreements between banks and clients, these allow the two parties to come to terms on an agreement that is written in code and thus logged on the Blockchain. The intrinsic smart contracts allow for each party to receive instant triggers that track how one side is following the agreement and ultimately when it is time for the other side to follow up their payment. We.trade’s chief operating officer has since said
“it is no longer proof of concept, it is no longer an experiment, the platform is now made available to the clients. They can find counterparts in other countries and start trading using the platform, creating a smart contract and then asking for financial services that the platform foresees, which can be financing an invoice or it could be a single payment.”
While the premise of smart contracts offers great potential, it is important to acknowledge that its development is still nascent. If there are to be smart contracts and technologies used for derivative contracts, it is crucial that ISDA and the global derivatives industry as a whole, work to develop the new set of standards and protocol needed for the technology. In order to proceed, progress needs to be made on developing a formal representation that can be used to re-write the relevant provisions of an ISDA Master Agreement and Schedule. Simultaneously, technology providers need to develop DLT implementations that would use such a formal representation. Standards need to be developed to ensure parties understand and incorporate certain smart contract parameters when negotiating with each other. ISDA will inevitably play a role in unlocking the value of smart contract technology, participating in the development of such standards and potentially fast-tracking FpML to do so. Adverse incidents such as the Ethereum ‘hard-fork’ are notable and must be something the industry can learn to circumvent, as the very nature of DLT lends itself to large scale, and very public embarrassments. Given the pace of today’s technology development, I do believe smart contracts working in unison with DLT are perfectly capable of having a positive impact on what is becoming an increasingly cumbersome and inefficient derivatives infrastructure. It is of course a big “if”, but with correct implementation and some clever programming, I believe smart contracts will become a secure, efficient and widely accepted form of contracting – particularly for cross-border and high frequency transactions.
 Section 13(b) ISDA Master Agreement.
 Section 4.14 2006 Definitions: “Whenever the Calculation Agent is required to act, make a determination or to exercise judgement in any other way, it will do so in good faith and in a commercially reasonable manner”
David joined FinTrU in October 2016 through our fourth Financial Services Academy after graduating from University of Ulster with an LLB in Law and Queen's University Belfast with an LLM in Corporate Governance.
At FinTrU, David works as part of the Fixed Income Legal Team for a Tier 1 Investment Bank. He is currently assigned to a BAU function and tasked to provide documentation and account coverage for large global asset managers. David also negotiates OTC derivatives documentation on behalf of his client. He has experience with ISDAs, CSAs and CDEAs and has recently worked on remediation projects brought about by MIFID II.
While at FinTrU, David has completed two modules of his Investment Operations Certificate with the CISI, studying an Introduction to Securities and Investments, UK Financial Regulation, and is preparing to complete his third module in Derivative Operations.