Pierre-Loïc Doulcet, Fellow, CodeX – The Stanford Center for Legal Informatics; Computable
Contract Engineer, AXA
CodeX Insurance Initiative Discussion Paper
NOTE ON THE DISCUSSION PAPERS: The CodeX Insurance Initiative has invited leaders from industry, academia, and the regulatory community to contribute short papers describing the authors’ views on important issues relating to the application of computable contracting in the insurance industry. The development of computable contacting for insurance is still a work in progress, and the sharing of ideas and approaches within the community of interest is a major goal of the Insurance Initiative. As a part of this conversation, these papers present the views of their authors, and do not necessarily reflect the views of CodeX, of the Insurance Initiative, or of any of its participants.
Computer-enabled automation has brought impressive gains in efficiency, capacity, and participant satisfaction to many economic sectors. The insurance industry is in the early stages of a transition to greater automation, moving from improved communications and data collection to sophisticated analytics and the fully computable representation of insurance contracts and other products. To capture the wider benefits of these developments, however, there needs to be the means for the products to be processed and assessed by more than just the originating insurer, or even the original team in charge of developing the product, and for the analytics to go beyond the text of the contract itself; there needs to be sufficiently standardized approaches in the industry to allow full interoperability of products across the insurance sector and over time.
The insurance industry needs product interoperability standards
Today, insurance products are described in different formats inside the insurance IT ecosystem with little interoperability between the different stacks. It is generally expensive to migrate a product from a claim or offering system to another functional stack or enterprise. This lack of interoperability has led many insurers to postpone updating or migrating their IT systems to more modern technology, or unifying systems following an acquisition. Lack of product interoperability mean high maintenance, migration, and integration costs, with high risk of project delay or failure.
A standard that allows the description of insurance products and everything that is needed to operate them, from offering to claim, will enable all these systems to communicate with each other. This, in turn, allows interoperability and portability of insurance products across IT systems, thereby reducing migration and maintenance costs while facilitating the introduction of technology across the insurance IT ecosystem.
To achieve this goal, I believe that the insurance product representation format needs to be fully computable. Instead of describing the way a product should behave in a certain situation, the format should contain all the data needed to address the situation without being prescriptive, allowing the system interacting with the product to “compute” it for the task at hand. This will allow reusability of the product description in contexts beyond the initial ones envisioned when the product description was created.
The remainder of this paper provides a brief overview of considerations for the development of such a standard.
What needs to be in the standard?
As stated above, the standard will need to provide for the description of everything that composes an insurance product and that is used to operate it, consisting of, at minimum, the five major areas outlined below. One of the first tasks for addressing each area would be to identify what might be drawn from the relevant prior work either specific to the area, or more general such as a broadly applicable legal specification protocol or LSP(1).
- Legalese (natural language wording) of the product, containing the different wordings that make up the contract, to drive the document generation systems. The standard should enforce the representation of such text in a layout-neutral format (such as Markdown). The format should support templatization and internationalization of documents. Prior work includes the Accord Project’s Cicero(2), and Legal XML(3).
- Product lifecycle information to drive policy management. While addressing common, more granular elements such as the policy validity period, the standard should also provide for, at a general level of abstraction, the description of a state machine representing all possible major states of a contract (e.g., payment default)(4). Prior work includes BPMN(5), DMN(6), and RuleML(7).
- Description of what is covered in the contract to drive claim systems, analytics, and risk management. I believe that the description of the actual insurance contract coverages, limits, deductibles, and exclusions (the risk umbrella) should be described as a logic program to provide for a fully interoperable model. Prior work includes Epilog(8), Logical English(9), L4(10), and Blawx(11).
- Risk and pricing model of the product to drive offering systems and renewal. The standard should provide for the description of steps in the step pricing, and encapsulation of the needed General Linear Models or actuarial tables so that the pricing can be calculated by different offering systems in an interoperable way. Prior work includes ASB and ASOP(12).
- Description of reference data used in the product to promote compatibility among the different data models described in the standard. I recommend that the text template and pricing model use the same nomenclature for the same variables/concepts. It should be discussed whether this standard should also cover an ontology or only the technical means to describe it. Prior work includes ACORD(13) and RDF(14).
What recognition is needed to succeed?
To succeed and gain adoption, this standard needs to be free and open source – that is, publicly accessible and free of charge. I also believe that it needs to be sanctioned by a standardization authority. Because insurance is now a multi-national and international industry, with both the primary and secondary markets scattered around the world, I believe that an international standard will be most productive (ISO/IEEE). However, to arrive at a global standard, recognition through bodies such as NIST in the US may need to be tackled first. Regulatory acceptance, occurring jurisdiction by jurisdiction, will also be necessary.
Once such recognition occurs, it will allow procurement teams to drive adoption and enforcement inside insurance companies. This will likewise drive adoption by a wide variety of industry players, from software vendors to secondary market-makers, and on to regulators and other state actors.
What would be the benefits?
The implementation of interoperability through a sufficient level of standardization will provide many benefits for direct and indirect participants in the insurance business: insurance companies, reinsurers, brokers, customers, technology providers, and any others. The major benefits include the following:
- Lower IT project costs, as interoperable standards should reduce the configuration/integration
effort needed. Acceleration of deployment for new projects in insurance will, in turn, accelerate
return on investments.
- Improved analytics and understanding of risk, resulting from standardization of data across the
value chain (pricing/offering/renewal/claim).
- Faster digitalization and spread of innovation by lowering the entry barrier for startups deploying
new solutions for the insurance industry. A standard product representation will also be used as a
platform to build new product offerings that can scale/deploy easily across the industry.
- Allowing forward compatibility of the product portfolio.
Who should participate in this standardization effort?
Standards are infamously difficult to create. That said, with enough participation by key stakeholders and with acceptance by key authorities, standard setting can succeed. The internet industry, for instance, provides voice, video, and data interoperability around the world through standardization processes. Key players for an insurance industry effort would include the following:
- Insurers, reinsurers, and brokers, to ensure that the standard covers the needs of the industry.
- Academics, to ensure that the standard is scalable, generalizable, and adaptable to future use cases by incorporating the latest innovations in computer science.
- Insurance industry technology vendors, to ensure the standard is documented in a way it can be implemented into new and existing offers.
- Regulators, to ensure the standard follows applicable law, including data privacy laws and regulations.
The insurance industry will benefit greatly from the development of an interoperable product standard. Such a standard should be computable: describing the content of the product instead of the way it should be interpreted – that is, it describes everything needed for product deployment, including text, lifecycle process, coverages, risk, pricing, and data used in the product. Such a standard will allow faster digitalization of the insurance industry, while reducing costs, increasing interoperability, accelerating automation, and provide for the emergence of new software solutions to enable the industry to better serve its customers. Finally, development of this standard should engage a broad range of participants from within and outside the insurance industry, including academics, technology vendors, and regulators.
1. LSP Working Group, Oliver Goodenough & Susan Salkind, Developing a Legal Specification
Protocol: Technological Considerations and Requirements, CodeX – The Stanford Center for Legal
2. Linux Foundation, Accord Project, https://accordproject.org/
3. Legal XML, http://www.legalxml.org/
4. Mark D. Flood & Oliver R. Goodenough, 2015. Contract as Automaton: The Computational
Representation of Financial Agreements, Working Papers 15-04, Office of Financial Research, US
Department of the Treasury.
5. BPMN, https://www.bpmn.org/
6. DMN, https://www.omg.org/dmn/
7. RuleML, http://wiki.ruleml.org/index.php/RuleML_Home
8. Epilog, http://epilog.stanford.edu/homepage/index.php
9. Kowalski, Robert. (2020). Logical English. https://www.researchgate.net/project/Logical-English
10. L4, https://legalese.github.io/doc/dsl
11. Blawx, https://www.blawx.com/
12. ASOPS, http://www.actuarialstandardsboard.org/standards-of-practice/
13. ACORD, https://www.acord.org/
14. RDF, https://www.w3.org/RDF/