3.15. policyStructure

General properties

The main characteristics of the policyStructure are the presence of the policy entity, a party entity with entityType policyHolder, an object entity to record the insured object, and a coverage entity to describe the protection provided by the policy against a certain risk. On top of that, all relevant entities are available to elaborate on any aspects of policy related information.

Mandatory components

The table below contains the mandatory entities and attributes of the policyStructure. Please note: these are only the mandatory components; in this case only the presence of a policy. In many functions and messages, the message will be more extensive, including party, object, financialTransaction and coverage entities, and often a commonFunctional entity for meta-data. See later in this section for a more detailed example. More information about functions related to policy 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 policyStructure. 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 the 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 policyStructure, including hull coverage on a motor vehicle. Note that at the top level within JSON, the policyStructure entity is not explicitly mentioned. In XML, the structure is always explicitly defined (as policyStructure) at the highest level.
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 (in this example policy).

{
	"commonFunctional": [ {
		"entityType": "default",
		"businessLine": "021",
		"porCompany": "Q001",		
		"dataCatalogVersion": "34C"
                "afdDefinitionName": "Goed verzekerd op weg",
		"afdDefinitionVersion": "001.00",
	} ],
	"policy": [ {
		"entityType": "policyDetails",
		"contractNumber": "P20190101-010",
		"party": [ {
			"entityType": "policyHolder",
			"firstName": "Maria",
			"surname": "de Jong"
		},
		{
			"entityType": "premiumPayer",
			"firstName": "Dennis",
			"surname": "de Jong"
		} ],
		"object": [ {
			"entityType": "motorVehicle",
			"licensePlate": "SIVI20"
		} ],
		"coverage": [ {
			"entityType": "hullVehicle",
			"coverageCode": "2002",
			"deductibleAmount": 400.00
		} ],
		"financialTransaction": [ {
			"entityType": "booking",
			"effectiveDate": "2023-03-01",
			"collectionAccountNumber": "NL12BANK034567892"
		} ]
	} ],
	"document": [ {
		"entityType": "default",
		"sequenceNumber": 1,
               "contentEncoding": "base64",
		"contentType": "text/xml; charset=cp858",
		"fileName": "afd001.xml",
		"fileExtension": "xml",
		"content": "VGhpcyBpcyBhIGJhc2U2NCBlbmNvZGVkIGV4YW1wbGUg"
	} ]
}

Special case: coverage only applicable for one insured person or object

If a policy contains more objects or more insured persons (for example the policyholder and his partner), it is possible to add an extra coverage to the policy that only applies to one object or to one insured person (for example the partner). In AFD 2.0 there are two ways to structure this. The first option is nesting. You put the applicable coverage under the according object or insured person (and put that object or insured person under the policy). Nesting is still the primary guideline for relatively simple messages.

The example below shows a policy with a policyholder and an insured person, in this case the partner of the policyholder. On top of the policy the partner also has a supplementary dental coverage in case of accidents. This supplementary coverage does not apply to the policyholder. This example shows the use of nesting.

{
	"policy": [
		{
		"entityType": "policyDetails",		
		"party": [ 
			{
			"entityType": "insuredPerson",			
			"coverage": [ 
				{
				"entityType": "accident",
				"coverageCode": "1245",
				"productDescription": "Tandongevallen Plus",
				}
			]
		},
		{
			"entityType": "policyHolder",						
		}
	]
}
]
}

The second option is more suitable in case of insuring multiple objects (or insured persons) and uses references. Within the applicable coverage you refer to the (unique id of the) of the object or insured person, using the attribute objectRef or partyRef.

The example below shows the same situation as above, but uses references instead of nesting.

{
	"policy": [
		{
		"entityType": "policyDetails",		
		"party": [ 
			{
			"entityType": "insuredPerson",
			"refKey": "partij1",
			},
			{
			"entityType": "policyHolder",
			"refKey": "partij2"			
			}
		],
		"coverage": [ 
			{
			"entityType": "accident",
			"partyRef": [
				"partij1",
				],
				"coverageCode": "1245",
				"productDescription": "Tandongevallen Plus",
			}
		]
	}
]
}