2.1. Introduction All Finance Data Catalog

Context and history

The All Finance Data Catalog (AFD) forms the basis for the digital ecosystem (see also Introduction SIVI AFS). AFD determines how one denotes data (e.g. a date always in the same format) and how one groups this data in a structure (e.g. what data elements are relevant for a ‘car policy’ and how are they grouped). AFD is the data catalog for financial services. Originating from the Insurance Data Network (ADN) in 1990, AFD has become a general financial services standard. Figure 2.1-1 shows the growth over time. Currently AFD facilitates data modeling for a range of domains and processes.

Figure 2.1-1 AFD growth
With the development of the AFD SIVI recognizes three perspectives with regard to data modeling:

1. Exchange of data. This is the bulk exchange of messages. Hundreds or thousands of messages are sent in batches via often a mailbox structure. ADN messaging and GRS messages are important examples.
2. Registration of data. Nowadays, using semi-structured data, data often is not stored in a relational database, but stored as a document containing tags and markers (e.g. XML, JSON).
3. Development of services. This is the real-time exchange of data / real-time transactions.

The whole purpose of AFD is to record for a specific event which data elements play a role and how these data elements should be structured among themselves. An important reason for using a data catalog like AFD is the reduction of communication overhead and errors when parties want to exchange data or use services. There is no need to individually coordinate how data is delivered electronically. This saves a lot of time. For both the exchange and recording of data the standardized definitions prevent errors around the interpretation and processing of data.

Vision and objectives

SIVI has set out a clear route for AFD. The primary goal is to model for a specific event what data plays a role and how to structure this data. Doing this, two objectives play an essential role:

1. Optimal expression. AFD has many perspectives for use. It is used to model data of objects, persons, organizations, policies, contracts, events, processes, etc. It is very important that AFD is able to express the needs in these specific modeling domains.
2. Efficient and effective use of AFD. Being able to model data is one thing, but the value of the ability to model data is low if the effort to model data is (too) high. The aim within AFD developments is to keep the costs associated with the application of the standard as low as possible.
   

Development to AFD 2.0

Figure 2.1-2 Main objectives during the development of AFD 2.0
In recent years there has been an increasing demand for the modernization of the AFD standard. The development of AFD 2.0 addresses this demand (figure 2.1-2) and concentrates in three areas. First the ability to adequately express new events and situations with the AFD model, for instance a bread fund or corporate insurances. Second, being effective and efficient in the daily use by analysts and developers, such as offering a comprehensive entity structure and easy-to-read attribute names. The third area is the alignment with modern ICT technology.

AFD 2.0 consists of six building blocks (figure 2.1-3, figure 2.1-4).

Figure 2.1-3 AFD within the All Finance Standard

1. Structure: A structure is designed for a specific high level business domain (e.g. insurance or mortgage) and depicts the agreement how data (entities and attributes) is modeled for the specific domain. A structure can best be seen as a starting point when defining an AFD message and makes the AFD more comprehensible. AFD 1.0 did not explicitly include a structure. In AFD 2.0 this is made explicit, making it also easier to define for instance JSON Schema’s and ensuring a coherent view when using AFD.
2. Entity: An entity describes an object, person, event, etc. from reality, for example a policy, party or claim. An entity is a container for a specific set of attributes describing an object, person, etc..
3. Entity types: In AFD 1.0 there are for instance over 100 entities representing objects. From a modern modeling perspective this is complex. In AFD 2.0 there is one entity for object. Each entity has an entity type. By means of the entity type a specialization of an entity is defined, for instance for a ‘moped’ or for a ‘car’. First this enables generic operations related to for instance the value of an object, but secondly it enables to define specific characteristics to a ‘car’.
4. Attribute: An attribute describes one characteristic of an entity, for example the date of birth of the policyholder, or the expiry date of the policy.
5. Data type: The format of the value of an attribute is defined by the data type. An example is ‘integer’ for a number without decimal places or ‘date’ for a date of format CCYY-MM-DD.
6. Codelist: A codelist is an enumeration of possible values that an attribute can contain. For example, a list of possible colors for the ‘color’ attribute. Not all attributes are linked to a codelist: for many attributes (e.g. ‘surname’ or ‘city’) values can be entered freely. Codelists from AFD 1.0 are integrally included in AFD 2.0.
   

Figure 2.1-4 Building blocks of AFD 2.0

Conversion between AFD 1.0 and AFD 2.0

SIVI provides extensive conversion support from AFD 1.0 to AFD 2.0 and vice versa:

1. A mapping zip containing (both an XML and JSON file describing) the latest mapping for AFD 1.0 attributes and entities to their AFD 2.0 equivalents and vice versa.
2. A SIVI mapping-API offering multiple mapping services, including a mapping from AFD 1.0 to AFD 2.0. More information is available on the SIVI website.
3. Support on request if you are interested in existing mappings or want to get started with your own mapping.
   

Copyright SIVI 2024

Powered by