SIVI AFS contains a lot of attributes. A description of each attribute is available in AFD 2.0 Online. But it is not always clear, which attribute to use in which situation. This paragraph gives some guidelines.
What date to use?
Start/change of a contract
In SIVI AFS various date attributes are used for to define start dates or change dates. Particularly the following dates need some extra clarification:
- effectiveDate (INGDAT in AFD 1.0): Date on which the data of this entity will take/took effect. (NL: Datum waarop de gegevens van deze entiteit van kracht worden/zijn geworden.)
- effectiveChangeDate (INGDATW in AFD 1.0): Effect date of the change itself. Not intended as registration date of the change on the contract/by the carrier. (NL: Datum waarop de wijziging ingaat/is ingegaan. Niet bedoeld voor de datum waarop de wijziging door de maatschappij is geregistreerd/is aangetekend op het contract.)
- initialEffectiveDate (INGDATO in AFD 1.0): Original effective date. (NL: Oorspronkelijke ingangsdatum)
effectiveDate
The attribute effectiveDate is the original start date of the contract, This date does not change during the duration of a contract
effectiveChangeDate
The effectiveChangeDate is the date the changes to that contract start effectively. This is not necessarily the same date as the date the changes are registered.
initialEffectiveDate
The attribute initialEffectiveDate is hardly used. For example, in case of a transition of an insurance portfolio from one intermediary to another, this attribute might be used.
Expiration/renewal of a contract
In SIVI AFS various date attributes are used to define the end or renewal of a contract:
- expiryDate (EXPDAT in AFD 1.0): Date on which the contract is terminated or tacitly extended (contract expiry date or expiration date). Upon renewal, the new expiration date will be included. (NL: Datum waarop het contract beëindigd of stilzwijgend verlengd wordt (contractvervaldatum of expiratiedatum). Bij verlenging wordt de nieuwe vervaldatum opgenomen.)
- In case of a short-term contract (policy), it is recommended to enter an expiryDate, but it is not required.
- If coverages under a contract (policy) are terminated before the next renewal date, it is recommended to enter the expiry date of that coverage.
- renewalDate (HVVDAT in AFD 1.0): The upcoming renewal date (‘contract anniversary’). (NL: ‘Verjaardag van het contract’. Hier wordt de volgende (eerstkomende) hoofdvervaldatum opgenomen.)
- It is recommended to enter a renewal date, unless the contract is a short-term contract.
Carrier specific attributes
Carrier specific attributes (or company-specific attributes) can be used by insurance companies (carriers) to fulfill some carrier specific needs that are not provided for by generic attributes. SIVI AFS contains two types of carrier specific attributes: attributes with and without a codelist.
Carrier specific attributes without a codelist
In the overview below some examples of company specific attribute without a codelist are shown. These attributes indicate how many objects of a certain category are stored. A company can replace the generic description below by its own description. For example: category 1 = boats, category 2 = cars, category 3 = mobile homes.
| Attribute | Description | Label AFD 1.0 |
|---|---|---|
| numberOfDisplayedObjectsFirstCategory | Number of category 1 objects stored. This is a carrier specific category. | AANGOB1 |
| numberOfDisplayedObjectsSecondCategory | Number of category 2 objects stored. This is a carrier specific category. | AANGOB2 |
| numberOfDisplayedObjectsThirdCategory | Number of category 3 objects stored. This is a carrier specific category. | AANGOB3 |
Carrier specific attributes with a codelist
In case of carrier specific attributes that are connected to a codelist, carriers can request their own codes and description. These requests are always granted. In case of carrier specific attributes and codelists uniformity is not required. The example below shows the carrier specific attribute carrierProductCode, connected to codelist ADNMSP (Company specific product code).
| Attribute | Description | Codelist | Label AFD 1.0 |
|---|---|---|---|
| carrierProductCode | Product code as used by the insurer. | ADNMSP | PRODUCC |
Other questions
Where to use applicationSenderName?
The attribute applicationSenderName contains the name of the application that sends the data in a message. It can appear in entity commonTechnical or in entity party, entityType sender. It can be applied under both entities and it depends on the preferences of the user which one to use. If only the applicationSenderName is needed, then we recommend to use commonTechnical. If more data of the sender are needed then use the entity party, entityType sender.
How to use deductibleAmount?
SIVI AFS allows a deductible amount to be configured either at the policy level or at the coverage level. However, it is not possible to use both attributes simultaneously. When configuring the deductible amount at the policy level (deductibleAmount under the entity policy (AFD 2.0) or PP_ERB (AFD 1.0)), this amount applies to all coverages within the policy. For example, if a deductible of 1.000 is set at the policy level, this deductible applies to all coverages under the policy. Therefore, if there are three coverages under the policy, the deductible will amount to 1.000 for each coverage. It is also possible to configure the deductible at the coverage level, but in that case, it cannot be set at the policy level.
Post your comment on this topic.