Insurance Products as Rule Sets

An insurance product is a set of rules that describes the possible combinations of cover commitments: the so-called coverage or product tree. Which coverage components are available, which attributes with which value ranges do they have, and how can they be combined.

The rules for the product define the permitted configurations of the product. The coverage tree forms, as it were, the common backbone for a series of related objects:

  • Product configuration

  • Calculation

  • Offer

  • Application

  • Contract

The rules active in each case may additionally depend on the type of object and on its status. Business objects in the narrower sense are offer, application and contract.

The product configuration is intended to describe the abstract underlying model.

These objects in turn consist of object networks, at the centre of which is the hierarchical tree of covers, but which have many further sub-objects and references to objects:

  • Insurance premiums or contributions

  • Risk objects

  • Application or contract roles

  • Persons

  • Addresses

  • Payment details

  • Notes, warnings, error messages

  • Documents (as attachments)

Rules of Interaction

While insurance companies naturally think a great deal about business rules, in particular product rules, the interaction for manipulating the business objects takes place via one or more media. Each medium of communication has its own set of rules.

In today’s web-based interfaces, the objects above are manipulated via HTTP requests and responses. The objects are rendered or represented in a selectable media type. The representation of an application or contract can, for example, be in XML, JSON or as a PDF document.

Both sets of rules, the one for the product in the narrower sense and the one for the interaction, should ideally be expressed with the same technology.

The Product Definition as a Rule Set

The product definition determines in advance – a priori, independently of the individual customer – which product instances (application or contract configurations) are possible.

The rules for the product are embedded in further rule sets: regulation for insurance contracts such as the Austrian Insurance Contract Act (VersVG), rules against money laundering and on taxes, rules for business processes, in particular for submitting applications to a specific insurer. These rule sets are also regarded as given and describable a priori for an application process.

How changeable are these rule sets? Very different. The rule that the premium is due at the beginning of the insured period, for example, is very old. The German Insurance Contract Act (VVG) dates back to 1908. The Austrian VersVG was amended on this basis on 1 January 1959. The rules for specific insurance products often change annually. Premiums can change even more frequently, and overall one would like to be able to adapt products to market conditions as quickly as possible in future.

How Are These Rules Operationalised, in Particular for the Application?

  • Traditionally, these rules were recorded in product manuals and sales documents, distributed and then implemented in systems. Depending on the type of implementation, rules could be changed more quickly or were more firmly anchored in the systems.

  • Fixed, unchangeable rules make an IT system more stable and reduce errors.

  • Flexibility and optimisation for "time to market" should therefore only relate to rules that are relevant for market success. For example, it should be easy to publish new product generations and to introduce new product components. The premium will continue to fall due at the beginning of the insurance period, as has been customary for centuries for good reasons.

However, the requirements for handling rules have changed with the advent of web interfaces:

  • Whereas it used to be sufficient to implement these rules in the central system and to train the staff, today these rules have to be transmitted to client systems of business partners that are basically unknown.

  • Whereas changes of rules used to be organised via releases of the central system, this is no longer a desirable approach today:

    • Sales managers do not want to be tied to the release cycle of IT.

    • IT does not want to have to react to very short-term market contingencies.

    • Due to the large number of connected external partners, it is no longer possible to switch the interface at a specific point in time. Instead, a new version has to be offered in parallel.

  • While it is still predominantly programmed clients that address the interfaces today, a trend towards flexibility is also foreseeable on the client side:

    • So-called smart clients can consume rule sets at runtime if these are transmitted in machine-readable form.

    • AI agents interact only at runtime. To do so, however, they too must be able to understand the rule sets at runtime.

For the reasons presented, rule sets for the application process, and in particular for insurance products, will in future have to be expressed explicitly in formal languages.

The Paradigm Shift: From Implicit to Explicit

It used to be like this: the "unchangeable rules" (e.g. "a user must be of age") were in an if statement in the backend. If this rule changed, the code had to be changed, tested and redeployed.

If you now move these rules into a standardised language that can be interpreted at runtime, you fundamentally change the system design:

The Advantages of a Uniform Rule Language

  • Single source of truth (SSOT): If client and server speak the same rule language, validations can run in complete synchronisation on both sides. The client knows immediately why a button is disabled without asking the server, because it runs the same rule engine locally.

  • Auditability and compliance: In regulated industries (finance, medicine), it is invaluable if rules are not hidden in binary files but are available as readable "policies". It can be proven which rules were active at which point in time.

  • Decoupling of release cycles: You can update business logic (the "rules") independently of the infrastructure (the "API framework"). This reduces operational entropy, because changes can be made in a more targeted way and with less collateral damage to the system.

  • Symmetry: A client can even propose its own rules to the server ("process this batch only if condition X is met"), which enables extremely powerful, flexible interfaces.

The Risk: "Meta-Entropy"

Although this approach increases order at the functional level, it carries a risk at the architectural level:

Shift of complexity: You have less entropy in the business code, but extremely high entropy in your "rule engine" instead. If the language is too powerful (e.g. Turing-complete), you are essentially building a programming language within a programming language. This is hard to debug.

Performance: Interpreting rules at runtime is always slower than native code.

Types of Rules

The requirements for objects can:

  • be the same in request and response, e.g. the data of a vehicle in motor insurance

  • apply to the request: information that the server needs for the calculation

  • apply only to the response: e.g. the client expects information on the amount of the premium as the result of a calculation, otherwise it is not a successful calculation.

Application

What is needed, therefore, is a concept that can provide the rules explicitly and at runtime:

  • the rules for the insurance product in the narrower sense (risk description and configuration of the scope of cover for the calculation of the premium)

  • the rules for submitting applications (regulation and business processes also change faster today than in the past, and AI can react to this at runtime)

  • the rules for contract changes, such as a change of vehicle or the exclusion of casco insurance.

  • the rules for converting a contract into a new contract of a successor product.

Rules Defined in Advance

These rules exist in advance (a priori) for the individual transaction and can also be expressed in advance with suitable languages.

  • AI systems understand vocabularies based on knowledge graphs particularly well. These also make it possible to define terms across individual companies and consumers. JSON-LD provides a modern syntax.

  • With the Shapes Constraint Language SHACL, a W3C standard is available to transmit dependencies in insurance products on the one hand, and to formulate requirements of server and client for the communication on the other.

Ad hoc

In addition, possible changes to specific instances can also be transmitted ad hoc. If, for example, I have configured a rudimentary motor insurance application, the interface can offer me the inclusion of a further vehicle with an interchangeable licence plate. If I query a motor insurance contract that has already been issued, the interface can offer me the cancellation of the casco insurance.

Such flow controls depending on the current status are called hypermedia controls, and the concept for this is abbreviated as HATEOAS.

These are, for example,

  • explicit, through object descriptions and rules, e.g. RDFS definitions and SHACL constraints

  • implicit, through the implementation of web services and documentation.

Rules for the application can depend on the status. An incomplete application, for example, cannot be submitted.

Rules for contract changes can depend on the contract status; e.g. different rules may apply to a contract that is in premium arrears.