In addition to the All Finance API-framework (Introduction All Finance API-framework), the All Finance Data Catalog (AFD) forms the basis for the digital ecosystem (see also Introduction AFS). The 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). The AFD is the data catalog for financial services. Originating from the Insurance Data Network (ADN) in 1990, the AFD has become a general financial services standard. Figure 2-1 shows the growth over time. Currently the AFD facilitates data modeling for a ranges of domains and processes.

Figure 2-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. Recording of data. Using semi-structured data, data is not stored in a relational databases, 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 the 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 as the 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 prevents errors around the interpretation and processing of data.

The AFD does not specify how you record messages. Generic and global standards such as CSV, EDIFACT, XML and JSON apply to the notation of messages. Which variant is used often depends on the technical setting. Only where necessary additional guidelines are provided. For example, how you deal with EDIFACT or XML within the ADN standard.
Also the AFD does not specify how you exchange messages. The exchange of data can be completed in many ways. SIVI has developed protocols for data exchange. A protocol is a collection of agreements on how a combination of standards is used. In this case for the purpose of moving messages from A to B. The currently used transport protocols are: SIVI SOAP web service protocol, GRS protocol and the SKP protocol.

SIVI has set out a clear route for the 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. The AFD knows many perspective of use. It is used to model data of objects, persons, organizations, policies, contracts, events, processes, etc. It is of eminent importance that the AFD is able to express the needs in these specific modelling domains.
  2. Efficient and effective use of AFD. Being able to model data is one, 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 are as low as possible.

AFD 2.0

Figure 2-2 Main objectives during the development of AFD 2.0

Over the recent years there was an increasing demand for the modernization of the AFD standard. The development of AFD 2.0 addresses this demand (figure 2-2) and concentrates in three areas. First the ability to adequately express new events / 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 programmers, such as offering a comprehensive entity structure and easy readable attribute names. The third area is the alignment with modern ICT technology.

AFD 2.0 consists out of 6 building blocks (figure 2.3, figure 2.4).

Figure 2-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 been seen as a starting point when defining an AFD message and makes the AFD more comprehensible. The 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 ensures a coherent view when using the 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 modelling 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. Code list: A special data type is the code list. A code list consists of list of codes and corresponding values. For instance ‘B’ for ‘Benzine’ and ‘D’ for ‘Diesel’. Although all documentation is written in English, code lists will of course remain in Dutch.

Figure 2-4 building blocks of AFD 2.0

AFD 1.0 vs AFD 2.0

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

  1. A XML file containing the mapping for AFD 1.0 attributes and entities to their AFD 2.0 equivalents and vice versa.
  2. The C# code to perform mappings based on the XML file above (under construction at this moment).
  3. A SIVI API offering service to convert AFD 1.0 and AFD 2.0 messages (under construction at this moment).


Thanks for your feedback.

Post your comment on this topic.

Post Comment