Application Questions

Application questions are fields in the application that relate the insurance product to reality in concrete terms without affecting the premium. Classic application questions are:

  • The data of persons and their role in the contract

  • Collection information such as BIC and IBAN

  • Assignments as security

  • Named beneficiaries

By definition, they have no influence on the premium. This is why these fields are not part of a product configuration or calculation, but only part of the application and subsequently of the contract.

Application Questions and Risk Parameters

Risk parameters make it possible to validate product configurations and to carry out calculations without specifying the application questions. Despite this deliberate separation, certain risk parameters and application questions share an object. In personal insurance, for example, the date of birth is an important risk parameter of the insured person. First name and surname of the person are important application questions on the insured person, and all attributes are part of the same person object. Some risk parameters therefore abstract from the specific object properties for the purpose of premium calculation.

Different Ways of Handling Them in the Application Object

There are various ways in which application questions can be handled in the application object.

Elements of the Application Object

An obvious pragmatic option is to place the application questions in the application object next to the product configuration.

This is a good place, for example, for a binary document of the application that represents the entire application. Detailed questions that relate to the entire application, such as questions on data use or collection, can also be accommodated well in this way.

It is important that the questions have a 1:1 relationship to the application and the product configuration. If the information consists of specifications that relate to a particular place in the product tree, however, this solution is no longer so satisfactory. The solution becomes completely unsatisfactory if the cardinality is no longer 1:1, e.g. if a piece of information is to be used at several places in the product tree.

As an Extension of the Product Tree

If a circumstance needs to be specified at a very particular place in the product tree, placing it directly in the application object makes it harder to understand. In this case, an extension of the product element for the application is the better solution. The application questions can then be placed at the place where they belong in terms of content.

An extension of the root element of the product tree is, because of its 1:1 cardinality to the application object, very similar to the previously described solution of placing the application question directly in the application object. Here the decision whether the element belongs to the application or to the product tree should be made on the basis of its subject matter.

As Objects

If the same information is needed at different places in the product tree, as can be the case with personal information, for example, these objects can be placed next to the product tree and linked to it.

Objects Reference into the Contract Tree

This solution requires an unambiguous description of which element in the contract tree is meant. Depending on the shape of the product tree, this can be more or less demanding. In the case of a motor insurance application with only one vehicle, it is clear that an assignment to a leasing company relates to the one casco element. If it is an interchangeable licence plate with several vehicles insured under casco, this implicit solution no longer works. In general, this solution requires a local component ID or a way of specifying a path.

Objects Are Referenced from the Contract Tree

In this solution, the objects with the answers to the application questions are referenced from the product tree. For this, the product components need the type and the ID of the object. Number ranges are therefore required. The components must be extended compared with those in validation or calculation in order to hold a list of references.

Technology

The considerations on the representation depend on the technology used. In hierarchically organised documents such as XML or JSON, the hierarchy of the elements generally serves to represent the product tree. References to other objects are more difficult to introduce. This has to be done via IDs.

If a data format for linked data is used, it is much easier to communicate an object network.