3.3. Insuring multiple objects

SIVI designed agreements and principles for the insurance of multiple objects as part of one policy. Within this scope, we specify three different policy constructions:

1. Single policy: a separate or single policy per object, each with its own coverage, clauses and/or conditions. In addition to the main object, associated objects can be insured, we will return to this with an example later.
2. Collective policy: a policy with (reference to) multiple objects. All objects have the same coverage(s) and conditions, possibly with the option to select (turn on) coverage or not. An example of this is a policy for an Owners’ Association, in which each residential property – including its own address details – is included separately but has the same coverage.
3. Package policy: a combination of one general cover and multiple policy components. Each policy component can be a single policy or a collective policy. Within a package policy, single policies and collective policies can coexist. For example, in the case of business premises of a company, each with different security requirements and coverage in separate (in this example separate) policy components.
   

Figure 3.3-1 Overview of a single policy, collective policy and package policy

Default: nesting under policy

We model single policies and collective policies in AFD 2.0 with the policyStructure. For package policies we use the masterAgreementStructure. We then always nest objects, coverages, clauses and other entities under the policy: in the policyStructure immediately under the policy at the main level, and in the masterAgreementStructure per policy component under the relevant policy entity. See chapter 3 for an explanation of policyStructure and masterAgreementStructure.
A single policy for a building insurance for a building and annexes in the policyStructure looks like the example below. For the example, we limit ourselves to objects, coverages and the mandatory commonFunctional for metadata:

Multiple objects with the same coverage(s)? No nesting, coverage at the same level

Another example is a collective policy for a building insurance for companies. The company in this example insures multiple buildings, all with the same coverage: buildings and glass. Now it is not logical to nest the coverage under each building: with n buildings you will receive the same coverage in the message once. For these situations, where the same coverage(s) apply to multiple objects, the coverage entity(ies) are at the same level as the object entities – and therefore not nested below them as in the previous example. See below a schematic example limited to objects, coverages, two parties and the mandatory commonFunctional for metadata:

Multiple objects and multiple coverages? No nesting, but referral

But it is not possible to solve everything with nesting, as in previous examples. Take a collective policy as in the previous example, where all buildings have the same building and glass coverage. But now we also want to insure annexes with their own building and glass coverage. The example below shows how we solve this in AFD 2.0: using the refKey and Ref-attributes:

Package policies: masterAgreementStructure as the basis, but the parts act like single or collective policies

Finally, the package policy. As mentioned, this can consist of combinations of single and collective policies, with a cover for generally applicable agreements (such as discounts and invoices). In line with previous examples, you could think of a fourth example: a package policy with multiple buildings and outbuildings, each with a different coverage. The elaboration of the package policy is in fact not that different from that of the individual policy and the collective policy: apart from the package (at masterAgreement level), we now only see multiple policy entities for each set of object coverage. In fact, we see here one package policy with three policy components. The first policy component contains two buildings with building coverage and glass coverage, which are the same for both buildings. The second policy component contains a building and an annex with building cover and glass cover, which are the same for both building and annex. The last policy component is a collective policy with two buildings and two annexes, two different building coverages and two different glass coverages: through objectRef, each of these coverages is linked to (the refKey(s) of) the objects to which it applies.