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 fully computable representation of insurance contracts and other products. To capture the wider benefits of these developments, however, there needs to be 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, the insurance product representation format needs to be fully computable by a computer. This should be in the form of a logic program. This means that as opposed to describing the way a product should behave in a certain situation, the format should contain all the data needed to address the specific 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 be considerate of all of the elements that compose 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 would be to identify the relevant prior work, either specific to the area, or more general, such as a broadly applicable legal specification protocol or LSP.
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 templating and internationalization of documents. Prior work includes the Accord Project’s Cicero, and Legal XML.
Product lifecycle information to drive policy management. In addition to addressing common, more granular terms 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). Prior work includes BPMN, DMN, and RuleML.
Description of what is covered in the contract to drive claim systems, analytics, and risk management. 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, Logical English, L4, and Blawx.
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.
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 and RDF.
What recognition is needed to succeed?
To gain adoption by relevant stakeholders, this standard needs to be free and open source - that is, publicly accessible and free of charge. It should also be sanctioned by a standardization authority. As insurance is now a multinational and global industry, with both the primary and secondary markets scattered around the world, an international standard would be most productive (ISO/IEEE). However, in order to achieve broad recognition, bodies such as NIST in the US may need to be persuaded 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 fuel uptake by a wide variety of industry players, from software vendors to secondary market-makers, and on to regulators and other state actors.
Where should such a standard be developed?
The general structure of insurance products is largely consistent across markets, and thereby arguably, this should become a global standard. Developing a global standard would then enable interoperability of software use across regions and facilitate their deployment.
Moreover, it is important that the standard is compatible provided that policies are frequently written in multiple languages. For example, this is a requirement for some jurisdictions (e.g., Switzerland, Canada), and across certain lines of business (large corporate multi-country contracts).
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. This could accelerate the deployment time for new projects in insurance, in turn, accelerating 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 be achieved. 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 and incorporates the latest innovations in computer science.
Insurance industry technology vendors to ensure the standard is documented in a way that can be implemented into new and existing offers.
Regulators to ensure the standard follows applicable law, including data privacy laws and regulations.
Conclusion
The insurance industry will benefit greatly from the development of an interoperable product standard. Such a standard should be computable, meaning that it describes the content of the product instead of the way it should be interpreted. This computable representation describes everything needed for product deployment, including text, lifecycle process, coverages, risk, pricing, and data used in the product. Such a standard would enable faster digitalization of the insurance industry, while reducing costs, increasing interoperability, accelerating automation, and provide for the emergence of new software solutions to better serve the industry and 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.
The CodeX Insurance Initiative has invited leaders from industry, academia, and the regulatory community to contribute short papers describing the author’s 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.
Pierre-Loïc Doulcet is a Fellow at CodeX — The Stanford Center for Legal Informatics and a Computable Contract Engineer at AXA
"circuit_5" by bittbox is marked with CC BY 2.0.