3.5.3. Message specifications

The structure and content of specific message specifications can also be drawn up using AFD definitions. For example, SIVI designs the specifications of protocols such as the NVGA Protocol and VBPUO using the AFD-definition Standard. This makes it easier for providers (sending parties in the protocol) to automatically compose messages that comply with the protocol. For processors (receiving parties in the protocol), it is easier to set up automated processing and to automatically validate and process incoming messages.

…
"commonTechnical": [
	{
		"entityType": "default",
		"creationDateTime": "2024-02-18 08:05:19",
		"senderId": "S-HB350012",
		"receiverId": "R-BB715400"	
	}
],
…

Batch messages

Another example of message specifications using AFD-definitions is the composition of batch messages, which allows users to send large quantities of messages at once. Effective use of keys and references enables the combination of multiple messages, such as contracts, objects, or parties, into a single message for simultaneous transmission.

A batch message contains identifying information for the entire message, such as sender (senderId) and recipient (recipientId) addresses, total message count, or a unique identifier. A batch message goes one way. A message is sent, not returned. Therefore the response (error message or notification) should be part of the same AFD-definition.

Other characteristics of a batch message are:

• Less transaction related information.
• Less logging information (examples of logging information: creationDateTime or changedBy).
  

These characteristics, combined with AFD-definition features like the AFD-definition name and version number, define batch messages as processed in an AFD-definition.

AFD 1.0 vs. AFD 2.0

In AFD 1.0, a batch message (Batchbericht) can combine different message types, such as Contractbericht and Schadebericht, but it can also contain multiple messages with the same message type. In AFD 2.0, the afsStructure allows the combination of various message types within a single message. The afsStructure, a generic AFD structure, permits parties to organize entities according to their requirements. It supports modeling multiple entities at the highest level, offering flexibility in structuring messages. However, it differs from the construction of a batch message in AFD 1.0, as it combines different entities rather than different structures.
Currently, batch messages cannot be modeled in the AOS tooling to compose AFD-definitions, but preparations are underway to enable this functionality.

Examples of batch messages in AFD 1.0 include:

• ADN booking messages (ADN-boekingsberichten: prolongaties (PPR), mutatiebevestigingen (PMB))
• GRS-documentation (GRS-documentberichten: Polis documentatie, Borderellen, Overige documenten)
  

Guidelines for batch messages using the afsStructure in AFD 2.0

• The highest level of the structure includes at least one commonFunctional entity, with the option to add more.
• An afsStructure can contain different masterAgreement and/or policy entities at the highest level, each specifying its insurance contract type through the businessLine attribute in the commonFunctional entity.
• An afsStructure can contain more party entities, for example if each policy is connected to a different policyholder.
• The combination of multiple entities on the highest level may require the use of references for clarity and organization.

Example

In the provided AFD-definition example, one party (policyholder) has two single policies (one for third party liability coverage and one for building coverage) with different effective dates and two different commonFunctional entities.

commonFunctional

• Contains a refKey, a unique reference key facilitating references from other entities.
• Examples:
  • commonFunctional.default-refkey = cmf01.
  • commonFunctional.default-refkey = cmf02.

policy 1 (third party liability coverage)

• Refers to the commonFunctional entity using the commonFunctionalRef attribute, which holds the same value as the refKey of the referenced commonFunctional entity.
• Example: policy.policyDetails-commonFunctionalRef = cmf01.
• Can have its own refKey.
• Example: policy.policyDetails-refKey = policy2131.
  

policy 2 (building coverage)

• Refers to the commonFunctional entity using the commonFunctionalRef attribute, which holds the same value as the refKey of the referenced commonFunctional entity.
• Example: policy.policyDetails-commonFunctionalRef = cmf02.
• Can have its own refKey.
• Example: policy.policyDetails-refKey = policy2531.
  

party

• In this example there is one party.policyHolder for both policy and commonFunctional entities, so no references are required for the party entity.
  

{
	"commonFunctional": [
		{
			"entityType": "default",
			"refKey": "cmf01",
			"porCompany": "Q001",
			"businessLine": "021",
			"functionVariant": "A0010",
			"afdDefinitionName": "Gemak Verzekerd Batch AFD 2.0",
			"dataCatalogVersion": "42C",
			"afdDefinitionVersion": "001.00"
		},
		{
			"entityType": "default",
			"refKey": "cmf02",
			"porCompany": "Q001",
			"businessLine": "055",
			"functionVariant": "A0010",
			"afdDefinitionName": "Gemak Verzekerd Batch AFD 2.0",
			"dataCatalogVersion": "43A",
			"afdDefinitionVersion": "002.00"
		}
	],
	"party": [
		{
			"entityType": "policyHolder",
			"collectionAccountIban": "NL98INGB0003856625",
			"initials": "T.I.",
			"prefixes": "van de",
			"surname": "Velden",
			"gender": "V",
			"birthDate": "1980-08-12",
			"street": "Pythagoraslaan",
			"houseNumber": 101,
			"houseNumberAddition": "A",
			"city": "Utrecht",
			"postalCode": "3584BB",
			"telephoneNumber": "0306988090",
			"email": "tvandevelden@sivi.org"
		}
	],
	"policy": [
		{
			"object": [
				{
					"entityType": "motorVehicle",
					"fuel": "B",
					"make": "Mazda",
					"model": "CX3",
					"reportCode": "4583",
					"weightInKg": 1130,
					"licensePlate": "QQ999Q",
					"annualMileage": 20000,
					"constructionYear": 2020,
					"initialListPrice": 30000
				}
			],
			"premium": [
				{
					"entityType": "premiumDetails",
					"totalInstallmentAmount": 26.91,
					"insuranceTaxInstallmentAmount": 4.67
				}
			],
			"coverage": [
				{
					"entityType": "thirdPartyLiability",
					"coverageCode": "2001",
					"deductibleAmount": 0,
					"noClaimsPercentage": 55,
					"grossPremiumInstallment": 22.24,
					"noClaimsDiscountStepNumber": 8,
					"noClaimsDiscountInstallmentAmount": 27.01
				}
			],
			"entityType": "policyDetails",
			"refKey": "policy2131",
			"statusType": "18",
			"commonFunctionalRef": [
				"cmf01"
			],
			"renewalDate": "2025-04-01",
			"effectiveDate": "2024-04-01",
			"collectionMethod": "I",
			"externalIndicative": "VP4321546",
			"paymentTermInMonths": 3,
			"renewalCommissionPercentage": 10,
			"numberOfClaimFreeYearsOnStatement": 2
		},
		{
			"object": [
				{
					"entityType": "building",
					"constructionOfRoof": "H",
					"postalCode": "3359JB",
					"homeType": "1"
				}
			],
			"premium": [
				{
					"entityType": "premiumDetails",
					"totalInstallmentAmount": 25.79,
					"insuranceTaxInstallmentAmount": 3.81
				}
			],
			"coverage": [
				{
					"entityType": "building",
					"coverageCode": "5004",
					"deductibleAmount": 0,
					"grossPremiumInstallment": 21.98
				}
			],
			"entityType": "policyDetails",
			"refKey": "policy2531",
			"statusType": "18",
			"commonFunctionalRef": [
				"cmf02"
			],
			"renewalDate": "2025-10-01",
			"effectiveDate": "2024-10-01",
			"collectionMethod": "I",
			"externalIndicative": "VP43221465",
			"paymentTermInMonths": 3,
			"renewalCommissionPercentage": 12
		}
	]
}