What is the purpose of composing AFD-definitions UIP?
Advisors and service providers in the ‘Intermediaire Distributie’ (classic distribution through independent agents) receive millions of digital messages from insurers and service providers, mainly ADN booking messages, GRS document messages and transaction messages. In many cases, policy details do not appear correctly on the screens of advisors, leading to additional work for advisors and deteriorating service to customers. To address this issue, SIVI has developed an industry agreement. The AFD-definition Standard is used to specify policy data based on digital messages from insurers. The AFD-definitions and specifications composed by the insurers, can be automatically processed by the software suppliers of advisors and service providers. This ensures that the policy data is accurately displayed on the screens. More information about the use of AFD-definitions in the case of ‘Intermediaire Distributie’ is available in the manual AFD-definitie Registratie Polis (in Dutch).
What is an AFD-definition UIP?
An AFD-definition for a product or service in the ‘Intermediaire Distributie’ is called UIP and can be recognized by the value PROV in the AFD-definition tag attribute. An example of an AFD-definition UIP is available in paragraph XML Examples.
AFD-definition ‘LIGHT’
SIVI has initiated the design and rollout of the AFD-definition for the Policy Registration function (Registratie Polis). The specifications of this function are based on registering and displaying policy details from various types of messages, sent by insurers to advisors and service providers. Since it involves processing data solely from incoming messages, an AFD-definition ‘LIGHT’ version suffices.
A ‘LIGHT’ version of an AFD-definition entails processing data from incoming messages for registration and display purposes only. Consequently, the JSON or XML Schema with minimal value restrictions (including only applicable coverage code values for the coverage code attribute) is essential for the AFD-definition. Setting up validation rules for the ‘LIGHT’ version is unnecessary since all required data is contained in the supplied messages. Similarly, except for the entities mandated by AFD rules (General Message (AL_) and Contract Part (PP_)) and attributes (coverage codes), entities and attributes can be designated as optional. The data is simply conveyed through messages from insurers.
The rollout of AFD-definitions for Policy Registration begins with the AFD Policy Registration Definition – Basic (Registratie Polis – Basis):
- Only value restriction for coverage codes
- No value restrictions for other attributes
- No validation rules
Software vendors can process the XML schema automatically, facilitating the setup of registration and screens within their software with minimal effort.
In case a provider offers a more extensive service for a product in the ‘Intermediaire Distributie’, such as premium calculation, validation rules can be incorporated into the same AFD-definition and more detailed considerations come into play:
- Value restrictions for attributes are feasible
- Ability to specify whether entities and attributes are mandatory or optional
- Composing this AFD-definition requires more analysis
- Principle: no composition of validation rules
This approach allows advisors to address customer inquiries based on various product input options (e.g., deductible or coverage variants). Software suppliers can also automatically process this XML Schema with the specified value constraints.
Messages from insurers
Currently, advisors and service providers can receive five different messages from insurers:
| Message type | Description |
| ADN-PPR (prolongatieberichten, renewal messages) | Dispatched by the due date (typically monthly). Includes booking data, rudimentary policy information and indexed data such as. no-claims discount step (Bonus/Malus) or rebuild value. |
| ADN-PMB (mutatieberichten, change messages) | Sent when initiating new insurance, making changes, or cancelling policies. Contains booking details and policy specifics (generally outlining the main features of the policy). Not all providers supporting ADN-PPR messages support ADN-PMB messages, as well. |
| GRS-documentbericht (document message) | Involves the large-scale transmission of digital documents to advisors for (fully) automated processing primarily associated with renewal processes. |
| SKP-Uitgebreid resultaatbericht (before: Start Extranet resultaatbericht) (Extended result message) | Dispatched after taking out a new insurance policy or altering an existing one in the extranet. Usually, it contains the main policy features. |
| SKP-Compleet resultaatbericht (before: GIM resultaatbericht) (Complete result message) | Sent following the issuance of a new insurance policy or modification of an existing one on the extranet. Usually, it contains the main policy features. |
Mandatory attributes
The AFD-definition must include the following attributes to enable the unique identification of the product:
- AFD-definition name (AFD-definitienaam)
- AFD-definition version number (AFD-definitie versienummer)
- Business line (Branchecode)
- POR company (POR-code)
These attributes are also present in the file name of the AFD-definition.
Additionally, the following attribute is mandatory:
- AFD-tag (filled with PROV)
According to AFD rules, the following attributes/entities are mandatory, as well:
- Message general (Bericht Algemeen, AL_)
- Contract(part) (Polis/Onderdeel, PP_)
- Coverage code with the applicable code values (Dekkingscode)
Other entities and attributes are optional.
Post your comment on this topic.