Background

Imagine: you are developing a web service for the acceptance and premium calculation of a car insurance policy. In the data catalog of SIVI AFS you found the underwriting entity with entityType underwritingQuestions. In this entity you will see two attributes that you need: 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 bonus depends on more details: for example, you have determined that it makes a difference whether the driving ban took place more than six years ago. In fact, you are looking for the drivingBanPastSixYears attribute. Unfortunately: you will not find it in the data catalog. But if you look a little further, you will find an application form for extensions and changes on the landing page of the SIVI AFS. This is how it has worked for AFD 1.0 for over twenty years, and that is how it has also worked 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 be representative of 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. That is why we do not include this data 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 above example 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

Attribute Required Data type or codelist Description 1.0 label
refKey O string Unique identifier to refer to.
customAttributeName R string Unique name of the customAttribute that is shown as a tag in the message.
customAttributeDescription O string Description of the customAttribute.
valueType R AFDDAT Data type that the value of the attribute must meet. Must be an AFD data type or code list. Refers to a schema definition of all data types and codelists.
valueSubset O [string] Subset of values, written as an array of strings, that the given value may meet.
value R in reply message valueType Given value for the customAttribute.

Feedback

Thanks for your feedback.

Post your comment on this topic.

Post Comment