The AFD model consists of a collection of entities and attributes. An entity describes an object or thing from reality, for example a policy, party or claim. An attribute describes a characteristic of an entity, for example the date of birth of the policy holder, the expiry date of the policy, etc. A single entity may contain multiple attributes. See AFD Online for the complete and up-to-date data catalog with all the attributes, as well as their characteristics and their respective entities.

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

Data types and codelists

The value of an attribute is of a certain data type. The AFD distinguishes between integers, decimals, strings, booleans, dates and times: see also the chapter on data types and arrays. There is also the possibility that the value of the attribute must be defined in a fixed list of options: see also the chapter on codelists. Finally, note that an attribute may have multiple values: Arrays are used to make this possible (see chapter on 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.

Using the customAttribute entity

The customAttribute entity enables a product provider to communicate data which is not standardized in AFD, such as underwriting questions. Often, these data are business or even product specific, and frequently adapted and/or expanded during the life cycle of the product. Because these data are so specific, they are less suitable for standardization across the entire insurance industry, and thus for inclusion in AFD. The customAttribute entity can be used within other entities, along existing attributes. See the chapter on the customAttribute entity for more detailed information.

Restricting attribute values with Schemas

In AFD 2.0, formats and data types are separated (see also the chapter about data types and arrays). Attributes can only 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. For these restrictions, AFD-definitions may be used to define these restrictions in SIVI 2.0. See chapter AFD-definition Standard) for detailed information. The following is an example of such a restriction in JSON Schema, with a matching sample message that validates against this Schema.

Example JSON Schema:

{
	...,
	"policy": {
		"type": "array",
		"items": {
			"type": "object",
			"properties": {
				"contractNumber": {
					"description": "The identifying characteristic that a company (or underwriting agent) assigns to the policy.",
					"type": "string",
					"minLength": 1,
					"maxLength": 30
				},
				"effectiveDate": {
					"description": "Date on which the data of this entity takes/took effect.",
					"type": "string",
					"format": "date"
				},
				"contractDurationInMonths": {
					"description": "Duration of the contract in months.",
					"type": "integer",
					"exclusiveMinimum": 0,
					"maximum": 120
				}
			},
			"required": [ "contractNumber", "effectiveDate" ]
		}
	}
	...
}

Example JSON message that complies with the Schema above:

{
	"policy": [ {
		"contractNumber": "C231-029-1",
		"effectiveDate": "2019-01-01",
		"contractDurationInMonths": 72
	} ]
}

Feedback

Thanks for your feedback.

Post your comment on this topic.

Post Comment