How a New Type of Software is About to Revolutionize Business Contracts
Smart contracts will combine (1) the efficiency of automation with (2) the adaptability of traditional legal contracts, but we'll need complete rethink of how we create contracts.
Blockchain Smart Contracts will bring massive savings and benefits over traditional contracts by replacing cumbersome, labor-intensive processes with automation, but to get there we are going to need to build contracts in a more systematic way
ISDA, the trade association for the Derivatives Industry, is thinking hard about this problem and developing a systematic approach to building smart contracts that work with traditional contracts
The “ISDA Approach” involves a multi-step process for creating a digital representation of each component of a contract, and this approach will be helpful to every industry
Using software to automate contracts will bring massive benefits in the form of reduced costs, improved efficiency and faster transactions. (See the report by Linklaters, one of the “Magic Circle” of London-based global law firms, on how the derivatives industry is exploring Smart Contracts to “streamline increasingly cumbersome and time-consuming processes, and cut costs.”)
But, as we’ve discussed previously, getting the automation right is a hard problem because almost without exception, no real-world contract can be automated completely – in other words, every contract needs a “human in the loop”.
The good news is that our friends in the derivatives industry, through their trade association, ISDA, have been working hard to tackle these challenges, and the approach they are developing – what we are calling the “ISDA Approach” will be helpful to every other industry.
Case study: a Contract for Hedging Foreign Exchange Risk
To illustrate the ISDA Approach, let’s start with our favorite, a Foreign Exchange derivative contract, better known as an “FX Swap.”
Understanding FX Risk
Here’s a simplified version of how it works. Big Company Inc. is a company based in the United States who just landed a new customer in France. The French customer will be paying Big Company in Euros. Great news, but it's also a potential problem. Big Company has to pay all its expenses in dollars. And so if for example, the price of Euros drops substantially, then Big Company will be making a lot less than expected when it converts the Euro payment to US dollars. This is known as “FX Risk” and Big Company can hedge this FX Risk by entering into a contract called a FX swap.
Understanding FX Swaps for Hedging FX Risk
Here’s a simplified version of how an FX Swap works. Big Company enters into a swap contract with Huge Bank. And under the terms of that swap contract, Huge Bank agrees – in exchange for a hefty fee – to take on some of the risk that the Euro will drop in value against the dollar. The way that gets implemented is complicated, but the main point is that Huge Bank agrees that, if the value of the Euro drops, Huge Bank will make up the difference. For ease of explanation, let’s say that, on the first of each month, the parties will look at the exchange rate of the Euro against the US Dollar, and if the Euro drops in value, then Huge Bank will make a payment to Big Company based on a formula agreed to in advance by the parties.
Today, handling this contract is pretty labor-intensive. The staff at Big Company and at Huge Bank check the exchange rate and calculate the amount, if any, that is due. There are a lot more steps that we are skipping over here, but the point is, given the huge volume of these contracts out there, it is a big task to check and triple-check each one. And it is high stakes given the huge amount of money involved.
It would be great if we could use software to make these calculations, but that brings us to the first problem.
Problem #1: Who Controls the Software?
Our first problem is, if we are going to calculate and handle the payment through software, who is going to control the software? Neither Big Company nor Huge Bank trusts the other enough to have sole authority to make the monthly calculation. Have you ever reviewed a hospital bill and noticed that all of the mistakes on the bill seem, by sheer coincidence, to be in the hospital's favor? If so then you get the idea. So we’re left with the situation today, where each side runs its calculations, and if there are any discrepancies, they fight about it.
The good news is that we have a solution to this “who controls the software problem”. It’s blockchain. Specifically, a smart contract running on a blockchain. A blockchain, you’ll recall, is a network of computers, where each computer makes the necessary calculations, and each computer on the network watches to confirm that all the other computers calculated correctly.
In other words, a blockchain smart contract uses decentralized automation – the calculation and the payment are not controlled by Big Company or by Huge Bank, but by the decentralized network.
Good news so far, but now we hit the second problem: what do we do about the parts of the contract that can’t be easily reduced to computer code?
Problem #2: How to Handle the Parts of the Contract That Can’t be Automated?
Our second problem is that any real-world contract is going to have components that we can’t handle using software. Most contracts include provisions that can be set forth in “if-then” logic, e.g., “if it is the first of the month, pay $X to account Z” but every contract will also include provisions that aren’t so easy to state precisely. See our earlier piece on this
As Ciarán McGonagle (@CPMcGonagle) of ISDA explains:
Consider, for example, a clause that allows (but does not require) a party to take a specific action upon the occurrence of a certain event, provided they do so promptly
McGonagle, Translations: creating legally effective smart derivatives contracts (emphasis added)
We don't have a precise definition of “promptly” and it would almost certainly be more trouble than it was worth to come up with a precise definition that we can reduce to computer code.
Under the ISDA Approach, we can solve this second problem, the “Human in the Loop” Problem, by separating out the provisions that can be automated – the ones that can be expressed in “if-then logic” from the provisions that can’t: those provisions that include terms like “promptly” or “reasonable notice.” We wind up with a list of certain parts of the contract that can be automated, and a separate list of parts that can’t. This second list is going to include provisions that we will handle using the traditional legal system and traditional contracts.
So, we are making progress, we’ve solved problem 1 and problem 2, but now we hit the third problem: how to make sure that the automated provisions work correctly with the non-automated provisions.
Problem #3: How to Get Automation to Work Well with a Traditional Contract – the Separability Problem.
The “Separability Problem,” a term coined by McGonagle and his co-author Christopher Clack, refers to the difficulty of separating automated provisions from the other parts of a contract. See Smart Derivatives Contracts: the ISDA Master Agreement and the automation of payments and deliveries.
The automated provisions are always tangled up with the other non-automated provisions.
See the example just discussed where a party can take a certain action but only if they do so “promptly.” The “if-then” provision is tangled up with the, necessarily vague term “promptly”.
So if we can’t untangle the “automatable” and the “non-automatable” parts of the contract, how can we make sure that they don’t interfere with each other? This is a hard problem, and under the ISDA Approach, it requires a rethink of how we create contracts. The good news is that this rethink has been long overdue, and will lead to a ton of benefits. In fact, ISDA has put together a whole white paper on how to deal with this problem for our FX Swap. ISDA Legal Guidelines for Smart Derivatives Contracts: Foreign Exchange Derivatives
Here’s the essence of how it works. In order to make sure the automated provisions of our FX Swap work with the non-automated provisions, we need a way to represent the whole contract – both automated and non-automated provisions – in digital form. Under the ISDA Approach, we get there through a two-step process.
While we’re calling this the “ISDA Approach” now is a good time to make clear that ISDA is building on earlier great work by Ian Grigg, who presented the idea of a Ricardian Contract in 1996, and Helena Happio and James Hazard, who presented the idea of the “Wise Contract” in 2017.
In order to get to this digital representation of the whole contract, under the ISDA Approach, we take a two-step approach:
Standardizing the terms of each contract, using a library of clauses called the ISDA clause library and
Digitizing those same terms, using a digital framework called the Common Domain Model.
ISDA has done a lot of greater work on each of these steps — nearly all of it applicable to every other industry. Next time we’ll do a deep dive on this and talk about lessons to be learned.
Is your Problem #3 an actual problem?
Contracts happen in three phases - the negotiation, the execution, the dispute. The context of the Separabilty Problem would seem to be between phases 1 and 2. The Intent is established and agreed at the conclusion of phase 1, hopefully captured in a written document.
Then the parties move to the execution, Phase 2. There is nothing to untangle - the parties pursue their best efforts to follow the Intent recorded in phase 1, or fail in the attempt. The code in the (so-called) smart contract assists in that endeavour. There is of course divergence in these phases, but that's real life! Is there an assumption here that because we can code phase 2, we can necessarily capture phase 1 perfectly? Tricky...
(If their failure crosses some threshold, they move to phase 3 - the dispute. The courts are always at the service of those who didn't capture their intent in execution...)