Features of a message for storage in a database
AFD-definitions support transactions as well as data registration and storage in databases and semi-structured environments. In case of data registration or storage, the AFD-definition specifies which data must be stored (structure) and validation rules should apply. As in other applications, an AFD structure forms the basis for the structure applied here. For example, policy data is always stored in a policyStructure, and party data in a partyStructure. The use of keys and references (fully supported by AFD 2.0) is crucial for data storage – and for searching/retrieving stored data.
A specific variant in relation to data storage is the AFD-definition ‘Registratie Polis’. In this case, parties use the AFD-definition Standard to specify the policy data that a software supplier can register for a policy, based on the messages sent by providers. Software suppliers can automatically process the specifications in this AFD-definition and thus ensure that the policy data sent by providers ends up correctly in the policy screens. A similar special variant is the AFD-definition ‘Kunnen aanleveren’. This AFD-definition is also not linked directly to the storage of data, but it does specify what a party must be able to deliver from its database to the insurer.
Some parties also use AFD-definitions for data storage for product modelling. For example, ANVA is working on setting up internal product registration based on AFD-definitions. In this, the AFD-definitions ideally contain all product-related data: so not only coverages, objects and parties, but also all conditions, bm tables, acceptance questions and screen dialogues. SIVI is currently still working on the elaboration of this within the AFD-definition Standard and AOS.
Structured storage in a database with AFD-definitions
A message does not contain all data that are available in the database. Keys play a vital role in organizing and retrieving data within a database. Essentially, a key serves as a unique identifier for a set of data grouped in a specific manner within a database. In AFD 2.0, we utilize the refKey as the unique identifier. To refer to the refKey in a message, the [entity]Ref attribute is used. Each entity possesses this reference attribute. For instance, a party might have the refKey ‘party013579’, and its reference in a message would be denoted as partyRef ‘party013579’. Note: references can only be made from within the database.
In case of storage of claims, statusType values like 18 (In process), 19 (Repairer enabled), or 20 (File to expert) should generally be included within the claim entity. In cases of advanced storage in databases, statusType may also be included in all entities where a status code holds relevance.
Other elements used in case of storage in a database are the following attributes (both under the entity commonTechnical):
changedBy– Identifies the name of the person that made the last change to the AFD-definition.creationDateTime– Represents the creation date and time of the message as a timestamp.
A database message does not contain attributes related to transactions, only attributes related to storage.
The message below shows a party.policyHolder with refKey ‘party013579’ and a party.regularDriver referring to it with partyRef ‘party013579’.
{
"commonFunctional": [
{
"entityType": "default",
"afdDefinitionName": "Goed verzekerd op weg",
"afdDefinitionVersion": "001.00",
"businessLine": "020",
"porCompany": "A999",
"dataCatalogVersion": "42B"
}
],
"commonTechnical": [
{
"entityType": "default",
"creationDateTime": "2024-02-11 08:05:19",
"changedBy": "T.R."
}
],
"policy": [
{
"entityType": "policyDetails",
"contractNumber": "Polis-20220020512",
"refKey": "contract2024012345",
"externalIndicative": "TP-polis-245345",
"effectiveDate": "2024-06-01",
"renewalDate": "2025-06-01",
"paymentTermInMonths": 6,
"grossPremiumInstallment": 235.45,
"numberOfClaimFreeYearsOnStatement": 5,
"standardCommission": true,
"statusType": 39,
"party": [
{
"entityType": "policyHolder",
"refKey": "party013579",
"surname": "Verbeek",
"initials": "AA",
"birthDate": "1999-04-18",
"houseNumber": "15",
"houseNumberAddition": "a"
},
{
"entityType": "regularDriver",
"partyRef": ["party013579"]
}
],
"coverage": [
{
"entityType": "hullVehicle",
"coverageCode": "2002",
"sumInsured": 60000,
"deductibleAmount": 500,
"grossPremiumInstallment": 244.00,
"renewalCommissionPercentage": 10,
"numberOfMonthsPurchaseValueGuarantee": 3
},
..... AFD-definition for NoSQL storage in a database (following AFD-definition structure)
NoSQL represents a database design philosophy focused on providing a framework for storing and retrieving data using models different from the tabular relationships employed in traditional relational databases. NoSQL are also sometimes referred to as ‘Not only SQL’ to emphasize they may also support SQL-like query languages.
Advantages of NoSQL databases include:
- Flexibility:
- Not necessary to model and structure data in advance.
- Can handle various data types and sizes.
- Scalability:
- Horizontally scalable.
- Capable of managing big data.
Despite these advantages, it is not always recommended to use NoSQL databases. If your primary data processing involves structured data, a traditional relational database management system remains a better solution.
Increasingly, databases are structured not solely on the field level, but based on an XML or JSON structure. Only data elements crucial for operational processes are included in the database. Other data, such as acceptance-related data, is combined and stored in groups, known as (semi-)structured data.
To provide financial data effectively, it’s essential to supply data meeting the necessary requirements, making it suitable for storage in the database. Additionally, the AFD-definition Standard offers a blueprint for the structure in which data should be stored, particularly crucial in the case of NoSQL databases. Smart queries are used to unlock the data.
Special case: reference
Reference is a specific form of data storage. It does not take into account the requirements for general storage in a database. Data referencing involves storing data for a specific purpose. For example indicating which data elements should be displayed on a screen in a specific situation, as seen in AFD-definitions for UIP (Registratie Polis). Another example, the submission of product-specific data elements (kunnenAanleveren) can be found in AFD-definitions UIV. Click here for examples of AFD-definition for UIV and UIP.
A message for data references solely contains entities and attributes relevant for the specific purpose and does not include any entities or attributes associated with transaction execution. refKey and [entity]Ref are used for reference, but the scope is only the message itself, not other data in the database. Within the message the reference will work as expected, but a correct reference to other data in the database is not guaranteed, because they may contain different values than the references are referring to.
Example
In the example below, referencing pertains to a car policy. Alongside vehicle data, a set of insurance data is also included. As with other contexts, an AFD structure serves as the foundation for data references, as illustrated in the policyStructure example. The entity commonTechnical is not necessary in case of referencing and is completely omitted in the example.
{
"commonFunctional": [
{
"entityType": "default",
"porCompany": "Q001",
"businessLine": "021",
"functionVariant": "A0010",
"afdDefinitionName": "Gemak Verzekerd Generiek AFD 2.0",
"dataCatalogVersion": "42C",
"afdDefinitionVersion": "001.00"
}
],
"policy": [
{
"party": [
{
"entityType": "regularDriver",
"refType": "A",
"birthDate": "1980-08-12"
},
{
"entityType": "policyholder",
"collectionAccountIban": "NL98INGB0003856625",
"initials": "T.I.",
"prefixes": "van de",
"surname": "Velden",
"gender": "V",
"birthDate": "1980-08-12",
"street": "Pythagoraslaan",
"houseNumber": "101",
"houseNumberAddition": "A",
"city": "Utrecht",
"postalCode": "3584BB",
"telephoneNumber": "0306988090",
"email": "tvandevelden@sivi.org"
}
],
"object": [
{
"entityType": "motorVehicle",
"fuel": "B",
"make": "Mazda",
"model": "CX3",
"reportCode": "4583",
"weightInKg": 1130,
"licensePlate": "QQ999Q",
"annualMileage": 20000,
"constructionYear": 2020,
"initialListPrice": 30000
}
],
"premium": [
{
"entityType": "premiumDetails",
"totalInstallmentAmount": 26.91,
"insuranceTaxInstallmentAmount": 4.67
}
],
"coverage": [
{
"entityType": "thirdPartyLiability",
"coverageCode": "2001",
"deductibleAmount": 0,
"noClaimsPercentage": 55,
"grossPremiumInstallment": 22.24,
"noClaimsDiscountStepNumber": 8,
"noClaimsDiscountInstallmentAmount": 27.01
}
],
"entityType": "policyDetails",
"statusType": "18",
"renewalDate": "2025-04-01",
"effectiveDate": "2024-04-01",
"collectionMethod": "I",
"externalIndicative": "VP4321546",
"paymentTermInMonths": 3,
"renewalCommissionPercentage": 10,
"numberOfClaimFreeYearsOnStatement": 2
}
]
}
Post your comment on this topic.