3.10. masterAgreementStructure

General properties

The masterAgreementStructure can be used to define a collection of contracts which are linked to each other by a master agreement, for example a package policy, or a framework pension contract. A masterAgreementStructure always consists of a single master agreement, plus one or more components. These components may be loans, pensions and/or policies. The main characteristics of the masterAgreementStructure are the presence of one masterAgreement entity of the relevant entityType (package, framework or collectiveDiscount) and one or more policies, loans and/or pensions.

There are different types of master agreement practices, ranging from closely connected policy packages to more loosely coupled framework or cloak agreements.

Package
The policy package is a commonly used format to group individual product policies for consumers and small and medium enterprises. It is a form of cross-selling where products from business lines like motor vehicles, property, liability, legal assistance, travel are combined. The most common advantage of combining individual policies in a package is premium rebate, with a rebate percentage that increases when more products are added. But there may also be other advantages like additional or enhanced coverage, or additional payment options like monthly installments.
A common feature of a package is a single invoice for all policies in the package, including the quantity discount based on the number of policies or product groups represented in the package.
Some carriers position the package as a product of its own, but a package itself does not provide insurance coverage, this is done only through the underlying policies.
Other carriers consider the package more as a CRM/customer loyalty arrangement with additional services and/or conditions for grouped policies.
Both types of implementation are supported by the masterAgreementStructure.

Framework
A master agreement can also be used as a cloak agreement which represents a template for policies which are linked to the agreement. Specific coverage, deductibles, conditions and clauses are governed by the master agreement. Individual policies under the agreement inherit these, and are completed with specific information about the object and the insured.
Another form is an agreement for collective insurance. In this case, the master agreement describes the general conditions, and participants receive an individual policy. Pension arrangements are a typical example of this type of master agreement.

Discount
A simple form of a master agreement is a discount that has been negotiated for a certain target group.

Usage
The top level of the masterAgreementStructure contains the details of the arrangement itself. In a loosely coupled setup the policy refers to a masterAgreementStructure by using the refKey.
Optionally, all policies or policy details can be embedded in the masterAgreementStructure itself to provide an overview of all policies which are part of the agreement.

Mandatory components

The table below lists the mandatory entities and attributes of the masterAgreementStructure. Please note: these are only the mandatory components; in this case only the presence of a masterAgreement. In many functions and messages, the message will be more extensive, including one or more policy, pension and/or loan entities. An additional commonFunctional entity for meta-data may also be included. See the detailed example in the section below. More information about functions related to master agreement is available in chapter Domain specific functions under Contract.

See AFD 2.0 Online for the complete and up-to-date data catalog with all entities, entityTypes and attributes, associated with the masterAgreementStructure. More documentation on the use of SIVI AFS is available in chapter Where to find elements of SIVI AFS. A general description of AFD structures is provided in Introduction to AFD structures, while information on details of AFD structures is available in chapter Where to find details about AFD structures.

JSON example

Below is an example of a masterAgreementStructure, used for a package policy. Note that at the top level within JSON, the masterAgreementStructure entity is not explicitly mentioned. In XML, the structure is always explicitly defined (as masterAgreementStructure) at the highest level as well.
If the attributes businessLine and porCompany apply to the entire message they should be part of the commonFunctional entity. If these attributes are subject to domain-specific agreements or if they apply to a specific contract, they should be included in that entity (policy, loan, masterAgreement, pension).

{
	"commonFunctional": [ {
		"entityType": "default",		
		"refKey": "cf001",
		"businessLine": "021",
		"porCompany": "Q001",
		"functionVariant": "A0100",
		"dataCatalogVersion": "41F",
		"afdDefinitionName": "PakketPlus",
		"afdDefinitionVersion": "001.05"
	} ],
	"masterAgreement": [ {
		"entityType": "package",
		"commonFunctionalRef": ["cf001"],
	        "refKey": "pack83178210",
		"contractNumber": "P20190101-010",
		"renewalDate": "2024-02-01",
		"party": [ {
			"entityType": "policyHolder",
			"firstName": "Maria",
			"surname": "de Jong"
		} ],
		"financialTransaction": [ {
			"entityType": "booking",
			"packageDiscountInstallment": 230.23
		} ]
		"policy": [ {
			"entityType": "policyDetails",
			"contractNumber": "P20190101-010_SI-VI-20",
			"masterAgreementRef": ["pack83178210"],           
			"object": [ {
				"entityType": "motorVehicle",
				"licensePlate": "SIVI20"
			} ],
			"coverage": [ {
				"entityType": "thirdPartyLiability",
				"coverageCode": "2001",
				"deductibleAmount": 400.00
			} ]
		} ]
	} ]
}