2.3.2. Custom attributes

Background

Standard attributes do not always cover all situations, required by parties or processes. For example the development of a web service for the acceptance and premium calculation of a car insurance policy. In the data catalog of SIVI AFS you can find the underwriting entity with entityType underwritingQuestions. This entity contains two relevant attributes: claimInPastThreeYears (has the applicant of the policy reported a damage in the past three years?) And drivingBan (has the applicant’s driver’s license been (un)conditionally denied?).

But the premium can depend on more details: for example, it makes a difference whether the driving ban took place more than six years ago. But the data catalog does not contain a drivingBanPastSixYears attribute. For these situations an application form for extensions and changes is available on the landing page of SIVI AFS. This is how it has worked for AFD 1.0 for over twenty years, and that is how it also works for AFD 2.0: partly thanks to these requests from the industry, the data catalog remains up-to-date and comprehensive. However, the starting point of SIVI AFS is that AFD 2.0 must represent the entire chain. In this case, this means: attributes must be generally applicable, and not focused on one company and/or one product. Attributes such as drivingBanPastSixYears do not belong in the broad AFD 2.0 standard.

In order to contain the proliferation of attributes within the AFD, it is possible to define attributes within SIVI AFS: the customAttribute construction. This construction enables a user to communicate data in a standardized manner that is not included within AFD 2.0. In practice, these are acceptance questions in almost all cases. These data are often company or even product-specific, and an organization revises it several times during the life cycle of the product in question. Because these data are so situation-specific, they are not suitable for standardization for the entire sector. As a consequence, SIVI does not include them in AFD 2.0.

What does this customAttribute construction look like? Within AFD 2.0, the afsElement entity has been included for this type of specifications, with, among other things, the customAttribute as entityType. You can use this entity within other entities, in addition to existing attributes. Two mandatory attributes determine the definition of a customAttribute: the customAttributeName and the valueType. The latter attribute determines which data type the self-defined attribute can be filled with. With the (optional) customAttributeDescription attribute it is also possible to add a description.

Example

The example above of drivingBanPastSixYears within an underwriting entity would be defined as follows:

{
	"underwriting": [ {
			"entityType": "underwritingQuestions",
			"afsElement": [ {
				"entityType": "customAttribute",
				"customAttributeName": "drivingBanPastSixYears",
				"customAttributeDescription": "Is het rijbewijs (on)voorwaardelijk ontzegd in de afgelopen zes jaar?",
				"valueType": "04"
      			}
		]
	}]
}

In this way you can easily use company and/or product specific elements within the context of SIVI AFS, without overloading the AFD 2.0 data catalog with overspecific attributes.

Attributes

Apart from the attributes above, the more generic attributes entityType (required and set to customAttribute), sequenceNumber (optional) and processingCode (optional) occur within this entityType. Always refer to AFD 2.0 Online for the latest version of the data catalog. More documentation on the use of SIVI AFS is available in chapter Where to find elements of SIVI AFS.

Implementing custom attributes within AOS

Custom attributes can not yet be implemented in our online modeling tool AOS. While this is under construction, you are able to select custom attributes like any other entity and fill the customAttribute entity manually in your messages.