The Stanford CodeX Insurance Initiative.
R.Ancellin, P. Carlson, PL.Doulcet

Abstract

This discussion paper aims at giving an understanding of contract automation technology options to a non-technical audience. We articulate the differences between NLP applied to contracts, Large Language Models (LLMs), Computable Contracts and Smart Contracts hosted on a public Blockchain, as well as attempt to summarize the main benefits and downsides of each approach.

1. Introduction: Software will eat the world^[1] and insurance contracts are no exception.

While contracts are important in many economic sectors, they generally serve a secondary role, regulating the delivery and payment for the actual products or services offered^[2]. In contrast, in insurance, the policy can be considered as the product, precisely describing the contours of the service to be provided.

However, insurance contracts are written in natural language “by lawyers for lawyers” and are hardly understandable to customers^[3].  Because the contracts remain in natural language text, the insurance policies they represent are difficult to automate. Insurance contracts contain the information necessary to execute the promises of service of the product. It includes multiple components: the risk model (what is the risk?), the pricing model (how much should the coverage cost?), the life cycle (renewal, billing amount), the consideration/bargain (description of the coverage, limits and exclusions) and the text (all the previous elements translated into legalese).

Such traditional, word-based contracts are a significant roadblock against streamlining insurance business processes through automation to bring more transparency for customers, and more efficiency in operations.

In this discussion paper, we will discuss technologies that could contribute to automating consideration/bargain definition and calculation.  Such automation, if successful, would lead to solving the most substantive use cases in insurance: the combination of a coverage check and a coverage calculation.

The coverage check is the capacity to determine whether a given real or hypothetical situation is covered by the contract. Coverage calculation is the capacity to calculate precisely a claim payout given all the necessary information. These systems generally run alongside a disambiguation process that identifies missing information so that it can be gathered in order to proceed to the calculation.

These are fundamental capabilities that enable critical use cases for all parties in insurance^[4], including the ability of a customer to better understand their coverage (what is my coverage if X happens) or of an insurer or a regulator to detect or simulate risk exposure or concentration at portfolio level.

In order to fit with the insurance industry needs, the technological solution must be reliable, explainable (the results must be auditable), scalable (the marginal cost to set up and operate needs to decrease significantly with the number of contracts handled on the platform) and future proof (an insurance contract can be active for years). Ideally, since insurance works in a pre-existing technological ecosystem the solution should also foster interoperability across systems and companies.

What if instead of being text first, contracts could be designed in code or structured data first – and then translated to text when required? What if this representation could power the coverage calculation in a reliable and auditable way, enabling insurance process automation?

2. Contract as code

The code and data first approach reimagines the nature of contractual structure. A contract is not necessarily a word-based artifact – rather it is a conceptualization and representation of a chain of linked events and behaviors that set out the pathway of a commercial interaction between the parties.  The pathway itself exists outside of the world of words, and the conceptualization and representation can be outside of words as well. It can be represented, as a primary expression, as a computer-readable combination of data and code.

This approach consists of a comprehensive representation of all the rules and data of the contract as a computer program. It enables the automatic execution of various operations including coverage calculations.

2.1 Using imperative programming

Imperative^[5] types of programming languages (Java, Python …) allow programmers to specify how a contract should operate in a given situation. Developers must anticipate many types of queries, as the Imperative program must be written with specific code to execute each specific use case. The program will be written for a specific contract, with each step represented explicitly in code. As a result, the code written for each particular step is rarely reusable. This lack of flexibility can be a barrier to easy deployment. Last but not least, by not separating the data from the software this approach could make interoperability challenging.

The automation of some specific insurance processes leveraging imperative programming (e.g. rules or code are used to model a First Notification Of Loss process does work, but with the limits on scalability and flexibility mentioned above.

While there are some ongoing prototyping efforts to apply this technique to insurance contracts, to the best of our knowledge there is no current deployment of this technology that permits representation of full contracts, at scale, at industry level today.

2.2 Using Smart Contracts^[6]

They are based on languages like Solidity and can be considered as imperative programming. However, public Blockchains are not a computable contract technology per se,  rather, they can act as the host to pieces of software.  When this software represents some portion of an agreed bargain, such as the trigger for a cryptocurrency transfer, the resulting code is often called a Smart Contract. These Smart Contracts can generally only be authored in languages that can be compiled to the machine language supported by the targeted blockchains. Moreover, the size of a contract hosted in a blockchain is limited, restricting the usage of blockchain records to very specific small contracts^[7]. Finally, the useful aspects of lodging material on a blockchain generally involve the necessity of having public information armored against tampering – a combination not generally required for most insurance contracts.

2.3 Using Declarative programming

At the Stanford Center for Legal Informatics, the research has focused on a Declarative programming-based approach, rather than an Imperative approach, in its work to develop automated insurance contracts and processes. “In declarative programming, programmers explicitly encode information about the application area and the goals of the program, but they do not specify internal processing details.”⁹ When using logic programs to automate insurance contracts, this means specifying the data relevant to the coverage check and calculation as a collection of facts, then using a collection of logical rules to represent the contracts’ logic.

2.3.1 Hierarchical data model

Traditionally, insurance companies seeking to automate portions of their bargains have represented insurance products and policies in a tree-like structure called hierarchical models^[8]. This is the most common approach today in the industry. This type of model enables reasonably accurate underwriting automation by clearly setting out the type of risk included in the contract. However, such modeling typically extracts only part of the contractual logic and is not able to represent the full content of an insurance policy wording. Indeed, the full representation of a commercial property and casualty insurance contract can easily contain billions of unique conditions that can lead to a payout, and the hierarchical representation does not allow proper factorisation. As a result, insurance companies only model a few dimensions (peril, sub peril, object) to avoid the challenges of maintaining such a large model. This results in incomplete representation of the contract that can’t support a proper coverage check and, since the model is not fully standardized, has a limited interoperability of the model across systems.  All of the necessary detail continues to reside in the traditional word-based contract.

2.3.2 Logical Data Model

In order to support claim automation more fully, an alternative consists in defining specialized Logical Data Models^[9] allowing a full representation of the rules of the bargain of the contract modeled as a series of risk chains (chain of situations, such as: an earthquake leading to a building collapse leading to an injury leading to payouts).

From an insurance business point of view, this representation of the contract comes with multiple benefits: (i) nontechnical authors are capable of drafting these contracts; (ii) it supports interoperability because data is separated from the software; and (iii) the data model can be reused across different use cases or applications written in different programming languages. Last but not least.

This approach has been deployed at scale by some insurance companies to automate the FNOL process and perform coverage checks. More time is required to demonstrate that the solution can address more complex use cases (e.g. defining the coverage for a specific object or calculating cumulative risk in US dollars for peril X in portfolio Z if event A and/or B happens).

2.3.3 Logic programming

The primary advantages of representing contracts as logic programs include: (i) the inherent explainability of the programs’ results (e.g. empowering an automatic insurance claims determination system that is able to explain why a given claim was paid or declined); (ii) the ease with which their behavior can be audited or formally verified due to the programs’ well-defined logical semantics; (iii) the ability to design logic programs for contracts with extremely specific coverage(s) for clients automatically (the behavior of which are easy to verify due to (ii), and (iv) the characteristic that, once created, the logic program is “use-case agnostic.”This means that it allows a large degree of flexibility around the types of information that can be queried from the contract (e.g. whether a claim should be paid or declined, whether a certain situation is covered, what the payout should be, which combinations of situations may be covered up to a given payout amount, etc.).

Also, since the field of logic programming has been the subject of active research for over 50 years, the technology is mature and well tested. There are, however, some barriers to adoption of logic programming techniques, such as the lack of modern and/or entry-level tooling, the limited use of logic programming in highly visible non-legal applications (i.e. general lack of popularity/salience in the software community), and few experts with logic programming experience. The latter can be explained by the fact it is a relatively niche paradigm.

The ongoing R&D effort at Stanford CodeX and at other academic centers such as Singapore Management University are aiming to demonstrate the reliability, auditability, scalability, and interoperability across multiple use cases from the contract formation to the automation of the coverage calculation or other risk analytics simulations at contract or portfolio levels and the limits to be addressed in a specific insurance context.

3. Wording-based approach to Contract Automation using AI

 Today, with most insurance contracts still being designed and operated under a “text/paper first” approach, it can be tempting to proceed directly from the .pdf or Word documents with techniques that can directly analyze written texts with a probabilistic approach.

3.1 Natural Language Processing 

Document parsing tools (i.e., those that are powered by Natural Language Processing (NLP) solutions) were producing satisfactory results in certain kinds of analysis. In particular, they were known to be useful for: (i) extracting well defined, specific data points (e.g. the policy number, or the name of insured company); (ii) classify policy clauses at a relatively high level (e.g. this given clause is likely to concern a fire liability); (iii) enable full text search for particular words in a portfolio of contracts or (iv) classify types of documents (e.g: is it a policy, an endorsement, a slip…). However, NLP/AI techniques were failing a significant number of analytical and reasoning tasks. For instance, applying NLP to answer a coverage check/calculation question like “What is the amount to be paid for this claim that occurred in specific situation X to customer Y”  or “What is the cumulative risk in US dollars for peril X in portfolio Z if event A and/or B happens?”, yielded deceptive results. In order to move from the collection of the data points to an accurate coverage calculation requires a granular understanding of the full contract including the relationship between clauses. For instance, one clause can describe a coverage in page X and then 10 pages later, the contract can include another mention excluding that specific situation).

3.2 Using Large Language Models

Since November 2022 and the release of Chat GPT 3, no AI powered solution was able to automatically determine both reliably and at scale whether a situation will be covered or excluded by an insurance contract. They were simply not able to conduct this kind of coverage calculation. NLP solutions were helping accelerate more analytic processes as long as there is a human in the loop to make the final judgment.

It changed with the onset of Generative AI and rapid advancements in the competence of the Large Language Models (LLMs) to resonate. In fact, early prototypes done at Stanford CodeX using LLMs are showing impressive results in extracting data from .pdf contracts to populate a logical data model with limited or no human intervention.

Furthermore, early prototyping efforts using Open AI GPT 4 with a token window of 32k have led to unprecedented results in proceeding to coverage check operation directly from the .pdf contract – without any intermediary data model. Bigger context windows are expected to make the reasoning even more accurate by leveraging hundreds of pages of documents. However, this probabilistic technique is still at an early stage and critical challenges including model hallucinations must be addressed before envisioning fully autonomous systems. The whole business model, including the inference cost at scale must be figured out as well.

4. Conclusion

 Automation of insurance policy bargain calculation is critical for enhancing efficiency and transparency, and computable contracts seem to be a viable solution. The Declarative approach, under the Contract as Code concept, appears more promising than the Imperative programming due to its ability to code policies to address a multitude of use cases. Logical Data Model-based solutions have demonstrated success in automating coverage checks, yet further time is required to confirm their effectiveness in handling complex coverage calculations for risk analytics at a portfolio level. Logic Programming, despite its labor-intensive nature, shows promise in providing full contract representation with utmost expressiveness, and prototypes confirm its competence in coverage checks and product/coverage benchmark^[10].

By automating the conversion of legacy .pdf contracts into logic programs, Large Language Models (LLMs) can expedite the adoption of this deterministic and cost-efficient approach.

With the rapidly advancing reasoning capabilities of LLMs, performing coverage calculations directly from the contract text is becoming a plausible reality. However, the infancy stage of this probabilistic approach presents challenges to be addressed before realizing enterprise garde type of applications.

——————————————————————————————–

^[1] Why Software Is Eating the World, by Marc Andreessen,

^[2] Computable Contracts and Insurance: An Introduction, Stanford CodeX

^[3] Eight out of 10 people cannot understand UK insurance policies, Financial Times

^[4] Computable Contracts and Insurance: An Introduction, Stanford CodeX

^[5] Imperative programming, Mcgill University

^[6]An Introduction to Smart Contracts, Harvard University

^[7] AXA Fizzy product launch

^[8] Hierarchical Database Model, Pen University

⁹ Introduction to Logic Programming, Stanford CodeX

^[9] Logical Data Models, https://en.wikipedia.org/wiki/Logical_schema

^[10] Insurance Portfolio Mnagement, Stanfrod CodeX

https://law.stanford.edu/2022/07/30/insurance-portfolio-management/