Application and Contract Roles
General
Persons can appear at several places in the application or contract in different roles. Since the same persons can appear in several roles, this is solved via references to person objects. A role usually carries additional information. In its general form it is therefore not merely a reference but an object. There are, however, simplifications that should be used so as not to make simple contracts too complex.
Person Objects, Contract Persons
Person objects should hold the data of the person itself: name, identification, addresses and accounts. Persons here are both natural persons and legal persons (organisations).
In the contract, this is a set of contract persons. To make them referenceable, they can, for example, have a local ID, or they are listed in a list and referenced via their position in the list.
The roles reference these persons and, where applicable, their sub-objects, in particular addresses. The reference can be local (list number of the person) or absolute (partner number, IRI). Persons in insurance administration systems usually have an absolute reference. The only question is whether they already exist in the insurer’s system and are known to the client when the application is made.
In practice, a person can have several addresses. A main address may be defined. If the address is treated as an object, the role can state which address is meant. If the address is treated as fields, the address is often a property of the role that must appear in the role. There is much to be said for treating addresses as objects. A distinction must be made, however, between a system-wide entity and merely a local object in the request or response. The address as a system-wide entity allows analyses based on the address.
The same applies to collection details such as bank details, credit card information and PayPal accounts as to the handling of addresses.
Telephone numbers and e-mails can also be represented either as referenceable properties of the person or as fields of a role. Here, however, the arguments for the referenceable property become weaker. Even if an e-mail address belongs to a person, it can be pragmatic to state it in the role rather than in the person and then link it into the role by reference, especially since the e-mail address itself is a globally unique ID.
Policyholder
This is probably the most important role. There is always at least one policyholder. There can be several policyholders. They can have equal rights, or there is a main policyholder.
Unless otherwise agreed, the address of the one (main) policyholder is the delivery address of the contract. If a person can have several addresses and the specific policyholder has several addresses, the correct address must be stated in the role, either in the form of fields or as a reference.
Since there is usually one (main) policyholder, the 1:1 cardinality to the contract allows information that is actually role information to be stored in the contract root. This is no longer possible only if there are several policyholders with equal rights and different information on the role, e.g. several policyholders whose different collection details are to be used.
Sometimes the distinction between role and person is unclear. Is the property "politically exposed person (PEP)", for example, a property of the role in the contract or a property of the person?
Delivery Address
The delivery address is sometimes defined as a separate role. In some cases also as a deviating delivery address: the address of the policyholder applies as the delivery address for contract notifications unless the role "deviating delivery address" is defined. This role is usually the same person as the policyholder, but with a different address.
In the application there is only one (deviating) delivery address. In the contract there is only one (deviating) delivery address at any one time.
Caution: deviating or general? It should be clear how to proceed!
Premium Payer
The premium payer is normally the policyholder. However, there are applications and contracts in which another person is defined as the premium payer. Collection data belong to this role. It may be that a premium payer always has to be stated, or that only a deviating premium payer has to be stated.
In the application there is only one (deviating) premium payer. In the contract there is only one (deviating) premium payer at any one time.
Caution: deviating or general? It should be clear how to proceed!
Insured Person
So-called personal insurance contains one or more insured persons in the contract whose life, ability to work or health is protected by the contract. Unlike the roles discussed so far, this role has a direct relation to the coverage tree. The cover of the person has a premium, there are risk characteristics that determine the probability of the risk occurring, and there are options regarding the cover.
The role must therefore be able to carry risk information as additional information: occupations, sports, health information that is relevant only for this contract and is not persisted with the partner.
The role is usually referenced only once in the coverage tree, which is why modelling it as an extension of a product component in the application is an option if the role data are relevant only in this application and do not exist independently.
It can, however, also be seen as an "insured interest" and then be treated like a risk object: reference into the coverage tree or reference from the coverage tree.
Like every role, it must refer to a person object, the contract person.
Assignment as Security
An assignment as security comes in various forms: assignment, pledge, restriction of payment (vinculation), and is made in favour of a person. An assignment as security can concern the whole contract or particular elements in the contract tree, e.g. in motor insurance with an interchangeable licence plate and two vehicles, one of the two casco covers. In addition to the beneficiary, an assignment as security may require further role data: start and end, information on the leasing or credit agreement.
An assignment as security can, however, also be seen as part of the component in the application, as long as it relates to a single component (and its sub-components) only.
Beneficiary in the Event of Death
Some beneficiary designations relate to specific persons. This can be represented as a role. They can either be represented directly in the component (e.g. main tariff of a life insurance, accident component accidental death) by a reference to a person. Or there is a list of beneficiary designations in which the components are referenced.