I. EXECUTIVE SUMMARY
I. Executive Summary This smart contract Primer (referred to henceforth as this "Primer") provides an initial overview of what smart contracts are, how they are being implemented within financial services and proposes how to apply existing legal and regulatory frameworks to mitigate risks from utilizing such technology. Developed by the members of Global Financial Markets Association ("GFMA") and Global Digital Finance ("GDF"), this Primer represents the broad perspectives of industry practitioners who are pioneering both research as well as the real-world implementation of distributed ledger technology ("DLT") and smart contracts within business models across the globe.
In May 2023, the GFMA together with Boston Consulting Group (BCG), Clifford Chance, and Cravath, Swaine & Moore LLP, published a seminal report, "The Impact of Distributed Ledger Technology in Global Capital Markets1 " referred to henceforth as 'The DLT Report', which evaluates the opportunities and risks of DLT and DLT-based securities, and assesses the applicability of existing legal, regulatory, and risk management frameworks. Building upon the findings in this report, as well as the findings from GDF reports and technical programs, GFMA and GDF are partnering to provide this Primer as a next step towards supporting consistent and responsible implementation of smart contracts within capital markets infrastructure. This Primer does not intend to cover all uses of smart contracts, rather, it primarily assesses smart contract usage within the regulated financial services industry to identify best practices as a first step towards global interoperability of DLT and standardization of smart contracts.
Smart Contracts are a Key Concept for the Evolution of the Financial System
Smart contracts are fundamentally software code. The standardization and ledger interoperability of smart contracts will be critical factors in the digitization and evolution of financial services. Crucially, as DLT scaling is already underway across financial services, this Primer also sets out practical examples of best practices within the industry, including how existing regulation for operational and technology risk management can be utilized to mitigate risks. The best practices presented are technology-neutral and supportive of appropriate future-proof regulation.
As regulators globally are forming policy to govern smart contracts as a technical aspect of the ecosystem, it is essential that policymaking works towards appropriate outcomes that mitigate risks, while also encouraging innovation and the updating and improvement or transformation of existing processes where new, enhanced outcomes can be achieved with technology.
This Primer advocates that regulators need not start from scratch when building frameworks for smart contracts. Market participants clearly articulated through the course of the engagement on this Primer that similar to implementing other new technologies through the years (e.g., cloud) there are tried and tested methodologies in place for change management and technology transformation. As with any technology change management program, this Primer acknowledges that there will be some risks unique to smart contracts needing specific mitigations. It is this Primer's aim, however, to discuss how both traditional technology risks and unique challenges are already being addressed, and can be comprehensively covered through existing regulatory frameworks, to support smart contract and DLT scaling in the financial services ecosystem in a compliant and responsible manner.
I. A. Scope
This Primer explores what smart contracts are and the role they play in scaling DLT within regulated financial services. It then proposes next steps for standardization and interoperability of smart contracts, as well as how regulators can utilize existing guidance and frameworks to mitigate risks. This Primer's key recommendations and findings are:
Recommendation #1: Prioritize key drivers of smart contract interoperability through technical standards and develop a template-based approach to smart contract standardization.
Recommendation #2: Support for utilization of existing technology and operational risk frameworks to regulate smart contract implementation.
Recommendation #3: Look to futureproof legal and regulatory regimes by providing clarity and support for responsible innovation, addressing where unique risks arise without creating special new regimes for smart contracts.
These recommendations are supported by legal and regulatory analysis throughout the paper and further expanded upon in our Conclusion and Call to Action in Section IV.
II. SMART CONTRACTS OVERVIEW AND THE CRITICALITY OF INTEROPERABILITY AND STANDARDIZATION
II. A. What is a Smart Contract & Why Does It Matter?
The term "smart contract" is now widely used across industry. Prior to commencing this Primer, the legal teams aimed to conduct a literature review of previous work done on this topic, and where relevant have been noted in the footnotes. Following this review, for the purposes of this Primer, the term "smart contract" is defined as:
software code that is designed to automatically execute upon the occurrence of predefined conditions, deployed within a distributed ledger technology environment, and may be executed within the context of a binding agreement between the counterparties of a transaction.
The role of smart contracts may vary, depending upon the context, and may include (among other things) enabling automation of operational processes, allowing for automated registration of securities ownership, and establishing the mechanisms needed to efficiently and effectively memorialize and effectuate the requisite mutual agreement necessary to arrive at binding contractual terms.
This definition was developed noting that this Primer's context largely refers to financial institutions implementing smart contracts for enhancing existing workflows via the broader transformation and scaling of DLT-based technologies and systems. This includes, for example, DLT-based recordkeeping, tokenization of regulated financial instruments, and DLT-based clearing and settlement, as opposed to its use in various decentralized finance (De-Fi) arrangements.2This Primer acknowledges that broader uses and definitions may be implemented and utilized elsewhere and that smart contracts are also widely used in public networks, but puts forward this definition as a foundation for discussions to drive interoperability and standardization, as well as regulatory clarity and legal guidance.3
This definition also refers to the use of smart contracts "within the context of a binding agreement between the counterparties of a transaction"—it is worth clarifying that smart contracts utilized on internal DLT- or blockchain- based books and records systems of one or more financial institutions (collectively, "Books and Records Smart Contracts") have a fundamentally different risk profile to smart contracts utilized in the context of a legal agreement between counterparties of a transaction. Books and Records Smart Contracts serve the same function, albeit more efficiently, as operational lines of code in traditional books and records systems. As Books and Records Smart Contracts control and mitigate risks, as they are part of internal functionality, they should be subject to the same regulatory regime that applies to any other books and records system of the financial institution, the design, adoption, and maintenance of which is subject to the financial institution's internal risk, technology, operational, and security standards as well as the existing supervisory oversight of financial institution's systems by its regulators.
It is also important to delineate the "smart contracts" referred to in this Primer from what may be referred to as "smart legal contracts" (e.g., International Swaps and Derivatives Association ("ISDA"),4 the Law Commission of England and Wales5), which generally refers to legally binding contracts in which some or all of the contractual terms between counterparties are defined in and performed automatically by a computer program. In other words, as explained in ISDA's guidelines: 'when lawyers speak about smart contracts, they may be referring to a "smart legal contract", which envisages a written and legally enforceable contract where certain of the obligations may be represented or written in code. Computer scientists may interpret the term more narrowly as a piece of "smart contract code", which is designed to execute certain tasks if pre-defined conditions are met.6'
The term "smart contract" is therefore broader than a "smart legal contract" as defined by ISDA, given that a smart contract may also be used to execute internal functions, and therefore does not inherently require the mutual consensus needed for bespoke terms that remain necessary to establish a contractual agreement between two parties. As stated, smart contacts are fundamentally software code. This is in line with industry and international policymaker usage of the term.7 Accordingly, smart contracts supporting DLT-based recordkeeping, accounting, reporting, and other back-office functions that are centrally administered by a financial entity are to a large extent akin to any other software code used by financial institutions to support traditional books and records systems.
The definition proposed by the Bank of International Settlements ("BIS") ("self-executing applications of programmable platforms that can trigger an action if some pre-specified conditions are met")8 is consistent with this separation between code and legal contract but, importantly, also points to the underlying characteristic that distinguishes smart contracts from other code and highlights the critical role of smart contracts in a DLT-based financial ecosystem: "programmability."
What is meant by "automatic execution"?
The definition of smart contracts in this primer refers to software code that is designed to "automatically execute" upon the occurrence of predefined conditions. It is worth noting that "automatic execution" does not necessarily mean that a smart contract "waits or "listens for" the occurrence of an event, and then self-executes upon the occurrence of such an event. Technically, execution of a smart contract on a blockchain may be initiated by (i) an external component or third party (which may be a human or a system), or (ii) by another smart contract.
For example, Smart Contract B can be set to be triggered by Smart Contract A. In this case, Smart Contract B does not simply "observe" the performance and outputs of Smart Contract A, and then self-initiate or self-execute accordingly. Rather, Smart Contract A initiates the execution of Smart Contract B as part of its processing, and passes on the relevant data to Smart Contract B.
In summary, on an individual level, each of these smart contracts do not automatically self-execute upon the mere occurrence of an event, without being triggered in accordance with pre-defined conditions. On an overall system level, smart contracts can be made to execute based on pre-defined conditions, through the use of off-chain components or by being initiated by another smart contract.
Programmability refers to the ability for smart contracts to be pre-programmed to automatically execute a logical process, where a given input will lead to a defined output. This does not mean that code is left entirely to its own devices, as human input will remain crucial in terms of ongoing code development, audits, and ensuring continued regulatory compliance, as well as any manual intervention contemplated by relevant governance for the smart contract. Programmability has the potential to revolutionize financial services in a number of ways, including:
- streamlining processes and reducing costs through automation;
- saving time and facilitating simultaneous actions and value transfers, as well as enabling new financial products and services;
- mitigating human error during processing through programmatic instructions;
- enhancing trust between contractual parties, reducing the likelihood of disputes, and mitigating the need for intermediaries, by objectively and programmatically determining whether obligations were met and automatically executing desired outcomes;9 and
- increasing transparency and security through tamper-proof records and through attaching additional terms as metadata.
More specifically, as noted in a recent report on programmability in the context of commercial banking and payments (authored by Onyx by J.P. Morgan and the Massachusetts Institute of Technology's ("MIT") Digital Currency Initiative ("DCI")),10 a key feature of programmability is to allow (corporate) clients or users of banks' services to deploy self-contained executable instructions which reside on the same environment as the bank and that would interact or compose directly with the services of the bank. This model could provide benefits over the conventional model (i.e., where code is typically deployed and executed within a client's environment, such as its own applications, which then interacts with the bank's systems through APIs or other channels). These benefits include:
1. Faster, more responsive transactions: By performing triggers, logic and actions within a single environment, programmability reduces both the technical lag of cross-platform communication and the business lag of batch updates or limited polling frequency.
2. Improved operational reliability and predictability: Instructions are housed and executed within a single environment, reducing dependency on clients' systems and minimizing the risk of failures.
3. Clearer and more reliable transaction audit trails: Use within a single environment ensures that data is maintained in a consistent format, enhancing traceability and auditability.
4. Expanded range of programmability: Access to previously unavailable data and event triggers allows for more sophisticated programmable instructions to be embedded directly into payments. Improved execution time and certainty enable these instructions to be processed within the payment flow, rather than afterward, without negatively impacting overall processing time.
5. Increased operational hours: Programmable instructions can be used with higher certainty and lower failure rates, which allows for payment instructions to be performed close to or even after typical bank cut-off times. This flexibility reduces the need for extensive time buffers and external inputs
6. Support for complex use-cases and composability: Programmable instructions can interact with each other, supporting more complex financial operations. Atomic operations— those program operations that run completely independently of any other processes—ensure that linked instructions either completely succeed or fail, which is crucial for transactions like delivery-versus-payment (DvP) or payment-versus-payment (PvP). This minimizes counterparty risk and ensures consistency, reducing system complexity and the need for manual reconciliation and recovery processes.
To read the full article click here
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.