Computable contracts: paving the way for a digital insurance industry?
What are computable contracts?
Somewhat confusingly, the term ‘smart contract’ has been and continues to be defined and used in various ways. In commercial settings, it has largely been used to describe contracts with terms that are executed by a computer with automated payments being a common application. This modern conception is typically reliant on distributed ledger technology (DLT). DLT describes a database where transactions or events relating to the contract are recorded on tamper-proof ledgers that are replicated on all participants’ IT systems. These participants could be a party to the contract or simply involved in a specific part of the contractual process. An update to the database such as human input signifying completion of contractual works could trigger automatic performance of contingent contractual terms such as payment. Successful automation saves time and money but the insurance market, which has a reputation for being old-fashioned, has been slow to adopt this technology compared to others in finance.
Whilst many computer scientists are quite content with the idea of increasing automation, some claim that this hitherto conception of smart contracting imposes unnecessary limits on the role of computers. They point out that although the computer code automates performance, it does not code for the contractual terms themselves. Conversely, the contract, in its written and legally enforceable form, cannot be processed by code.
In other words, what makes a contract ‘computable’ is that the code that generates its automation (subject to some parts requiring human input and control) also underpins its enforceability both through legal enforcement of rights and obligations and via tamper-proof execution of computer code. To put it succinctly, a computable contract will be one that is understandable both to humans and computers. In academic circles, the terms ‘smart’ and ‘computable’ are increasingly being used interchangeably whilst mere automation, as the joke goes, is sometimes dismissed as ‘neither that smart, nor a contract’.
How does a policy writing agent or lawyer draft a computable contract?
A contract only works in its drafting and operation if it is written in a language that is commonly understood by humans. To make it computable, this language must be directly translated into the relevant code. The question is: how?
According to Christopher Clack and his team of researchers at UCL, the answer is to create a standardised and structured natural language. Lawyers and policy writing agents will think that they are drafting in a language such as English, for example, albeit in a highly structured way. They’ll have a restricted choice of available words and phrases. They’ll be slightly constrained in the way they can put sentences together. But it will still look like English.
This language will be ‘domain-specific’ meaning that it would be engineered specifically for the insurance sector. It will draw upon terms and phrases that are, or will need to be, standardised throughout the industry. Once it is in place, there can be automatic translation from contract to code and automatic validation of the code – it will be correct by construction.
How can this language be created?
Research on the construction of a domain-specific language has been underway for several years and is still in its early stages. Multi-disciplinary teams of lawyers, linguists, logicians and computer scientists are working together alongside innovators in industry to find ways of coding for the full range of contractual variables. This requires a complete understanding of the complex meaning of contracts, specifically the rights and obligations they confer, the time aspects (including past, present, future, fixed, floating, conditional, contingent and even deemed time) of different terms and the nature of their required actions. The newly designed domain-specific language will require formal syntax and semantics as this is what will make it understandable to computers.
The whole concept, however, is contingent on the industry-wide adoption of standard terms for contracts and policies. The Lloyds wording repository, a database of vetted policy wordings and clauses, is an encouraging starting point, but there will need to be a consensus on further standardisation of these terms to eliminate unintended ambiguities.
What will the benefits be?
In combination with enhanced AI technologies, computable contracts should enable automation of performance to be more intelligent and wider in scope. For example, with many ordinary objects and sensors likely to be computerised and interconnected in years to come, specified data sources could feed directly into distributed ledgers containing an insurance policy’s code. This setup would enable decisions on policy payment, for instance, to be based on a variety of real-world events. It is worth noting that these inputs would likely have to pass through a single point (an oracle) to avoid contradictory input.
The combination of AI and the domain-specific language could also have implications for the policy drafting process. Underwriting decisions and calculations could be automated, drawing upon real world data analysis. Standard terms could be tagged with metadata, derived from AI-driven analytics, which give information about the text and connect the contract to the insurer’s other business systems. It could be linked to algorithms that highlight drafting errors such as missing or conflicting provisions and others that reveal the contract’s commercial implications. A more revolutionary result of this connectivity could be the establishment of algorithmic standards for pricing, negotiation, payments, policy administration, portfolio management, risk management and many other aspects of the insurance value chain with the contract being a data-rich object at the centre of these operations.
Given the industry consensus required on construction of the domain-specific language’s standard terms, it is hoped that dispute resolution will be sped up and, in many cases, avoided. It is also expected that the enhanced automation of contractual performance will make breach or default less likely to occur.
At this stage, only rough estimates can indicate the costs savings computable contracting could make for the whole London market. To provide some perspective, however, Lloyds of London’s savings target for the next two years is £800 million which is around 3% of total costs. It is highly unlikely that computable contracting will be commonly implemented during this time, but it may start to be within the next ten years. By then, and because of these advancements, savings relative to current costs could be much more significant, perhaps into the billions per annum.
What about the drawbacks?
In the insurance and legal sectors, there has been mixed reaction to the idea of computable contracting. To many lawyers and policy writers, drafting is an art and a skill they have honed for years. The idea of restriction in the drafting process seems to minimize the breadth of thought required and therefore narrow the scope to truly excel at their craft. However, this is not necessarily the case. The nuances of what is required for a specific contract or policy can only be determined with a ‘human’ understanding of the relationship between the parties and of past, current and potential real-world events. The domain-specific language will need to be used creatively to accommodate these nuances. Furthermore, it is desirable to involve as many policy writers and lawyers as possible in the process of designing a language that gives them flexibility. Ultimately, however, the prospect of improved customer experience and efficiency will likely override any emotional objections.
It is, however, important to highlight the limitations of computable contracting. A common query is how contractual vagueness could be computed. Well, it can’t. Not all parts of a contract can be reduced to Boolean logic and only those that can be are computable. Terms containing deliberate vagueness will continue to be drafted with complete flexibility and won’t be executed by tamper-proof code. However, as was made clear by the Court of Appeal in Legg v Sterte Garage Ltd [2016], insurers and policyholders must ensure that their policy wording is clear and unambiguous. Of course, this is not always possible and unforeseen circumstances or allegations of bad faith may warrant a court’s judgment. But the beauty of insurance underwriting is that even the unlikeliest of risks, which in a normal legal contract may not be worth paying lawyers to draft for precisely, must be carefully evaluated and quantified. In this way, the insurance sector could be a natural starting point for the commercial application of computable contracting.
It is also worth reiterating that years of challenging research and testing will need to be done before computable contracts are commonplace. There is a significant body of useful academic work to draw upon, especially in law concerning contract interpretation. But, for the moment, it remains a futuristic concept.
Conclusion
Given both the urgency and long-term ambition of Lloyds to reduce costs through digitization, computable contracting represents an exciting opportunity for the insurance market to take the lead in adopting and integrating emerging technologies. The idea of a contract or policy as a detached, unstructured, ‘unintelligent’ document, perhaps with some simple automation, may be replaced as its potential to draw upon external systems and connect disparate parts of the insurance value chain is realised. Furthermore, the comprehensive and often exhaustive way in which risks are addressed in an insurance policy makes it an ideal platform for the Boolean logic of computable contracting. It is, however, crucial that lawyers, policy writers and others in industry who will work closely with computable contracts are at the centre of the design and development of its standard terms. Only with their cooperation can the multitude of potential benefits, including those that are not currently foreseeable, be realised in years to come.