2.3.1. Standard attributes

If attributes are sufficiently generic across the entire financial industry, they are suitable for standardization, and thus for inclusion in AFD. These attributes are standard attributes.

Entities can be filled from a list of associated attributes. For example, the address entity has (among others) the attributes houseNumber, street and city. Not all attributes are mandatory when filling an entity, and some attributes can occur in multiple entities.

See AFD 2.0 Online for the complete and up-to-date data catalog with all available entity types and associated attributes. More documentation on the use of SIVI AFS is available in chapter Where to find elements of SIVI AFS.

Data types and codelists

The value of an attribute is defined as a certain data type. The AFD distinguishes between integers, decimals, strings, booleans, dates, times and timestamps (date and time combined): the chapter on data types and arrays gives a more detailed overview. Another possibility is that the value of the attribute must be defined in a fixed list of options: the chapter codelists gives a more thorough explanation. Finally, note that an attribute may have multiple values: arrays are used to make this possible (see chapter data types and arrays).

Adding attributes to the data catalog

Insurers and intermediaries affiliated with SIVI and suppliers cooperating with SIVI (suppliers authorized to use the AFD) can submit a formal request to SIVI for the functional modification of the AFD data catalog, or the addition of new attributes. See the support chapter for more information on how to request additional attributes.

Restricting attribute values with Schemas

In AFD 2.0, formats and data types are separated (see also the chapter data types and arrays). Attributes can be subdivided into strings, integers etc., but the data catalog itself no longer stores – in contrast to AFD 1.0 – the string length, or the integer value range. AFD-definitions may be used to define these restrictions in SIVI AFS. In chapter AFD-definition Standard more detailed information is available.

The following example shows some of the standard data types in JSON Schema, with a matching sample message that validates against this Schema. In this example, the attributes entityType (as the constant string policyDetails), renewalDate (as a date), contractNumber (as a string) and paymentTermInMonths (as an integer) are defined within the policy entity of entityType policyDetails.

Example JSON Schema:

"policy": {
	"type": "object",
	"properties": {
		"entityType": {
			"type": "string",
			"const": "policyDetails",
			"description": "Unique identification of an entity. (NL: De unieke identificatie van een entiteit.)"
		},
		"renewalDate": {
			"format": "date",
			"description": "The upcoming renewal date ('contract anniversary'). (NL: 'Verjaardag van het contract'. Hier wordt de volgende (eerstkomende) hoofdvervaldatum opgenomen.)"
},
                "contractNumber": {
			"type": "string",
			"description": "The identifying characteristic assigned by a company or underwriting agent. (NL: Het identificerende kenmerk dat een maatschappij (of gevolmachtigde agent) toekent.)"
		},
		"paymentTermInMonths": {
			"type": "integer",
			"description": "Duration between two consecutive premium payments (whole number). (NL: Tijdsduur tussen twee opeenvolgende premiebetalingen (geheel getal).)"
}
},
	"required": [
		"entityType"
	],
	"additionalProperties": false
}

Example JSON message that complies with the Schema above:

{
	"policy": [ {
		"entityType": "policyDetails",
		"renewalDate": "2022-08-01",
                "contractNumber": "P865480",
		"paymentTermInMonths": 3
	} ]
}