All Finance Data Catalog
English as official language
The demand for English documented SIVI standards is increasing. The first reason is that software development activities at for instance insurers, service providers and suppliers are increasingly (at least partly) outsourced. The effect of these ‘nearshore’ and ‘offshore’ models is that the main language in projects is English. The second reason is that due to shortage of good programmers, organizations hire foreign employees. Therefore, all SIVI All Finance Standard documentation is in English.
Entity and attribute names are written in full and according to the camelCase capitalization typography. All names and descriptions are in English. camelCase is the practice of writing phrases such that each word or abbreviation in the middle of the phrase begins with a capital letter, with no intervening spaces or punctuation.
See also the Wikipedia entry on camelCase.
Codelists do not change significantly in AFD 2.0. Codelist descriptions are translated into English (for example Coverage code instead of ADN Dekkingscode). The codelist names (the six letter abbreviations), code values and code descriptions stay as they were in AFD 1.0. New in AFD 2.0 is the introduction of hierarchical codelists. Many codelists actually represent a taxonomy with various levels (e.g. AFDSCL). A hierarchical codelist enables the representation of hierarchical structures. The hierarchy is represented in an additional JSON file to the standard codelist. Regarding the use of the hierarchy you can change your software on an ‘if wanted’ basis. For more information, see the hierarchical codelists chapter.
Data exchange & data storage
The All Finance Data (AFD) catalog lays the foundations for structured data exchange and storage in the financial services industry. Please note that storage is a new area of attention compared to AFD 1.0. We respond to the increasing use of semi-structured data where data is stored in JSON or XML format in ‘BLOBs’ (data containers) instead of for instance tables in a SQL-database. Unambiguous data definitions are essential to be able to follow the structure data approach reliably and on a large scale. The AFD data model (both definitions and structures) offers a very good starting point for the storage of data based on structured data. It is already used for this purpose within the insurance industry. In the further development of the AFD this perspective of use will be an important factor.
JSON support
For many years XML was the dominant syntax to represent data for instance messages. Around 2015 the JSON syntax took over definitively. Driven by its simplicity and the rise of the new REST architecture, the JSON syntax has become dominant. AFD 2.0 is – just like AFD 1.0 – a syntax-independent model, but has been explicitly developed with JSON and XML support in mind. Examples of specific AFD messages in this manual will be in JSON. Note however that the XML-syntax will also be supported by AFD 2.0. More information about JSON can be found in this manual, on Wikipedia and on json.org.
New data types
AFD 2.0 introduces Separation of data types and format restrictions. Restrictions on data formats were included in the data model in AFD 1.0. As a result, a distinction was made between (for example) alphanumeric strings of 34, 12 or 3 characters, and between numbers with 2, 3 or 5 decimal places. Within AFD 2.0 we separate data types and format restrictions. Instead of distinctions between alphanumeric strings of 34, 12 or 3 characters, the data catalog only specifies an attribute as being of type string . The format restriction on the number of characters or decimal places takes place in the AFD-definition Standard, by means of XSD or JSON Schema.
Consequently, AFD 2.0 only has seven native data types: integer, decimal, string, date, time, timestamp and boolean. The inclusion of boolean instead of ADNLOG implements a long-overdue wish from the industry. In terms of format, time and date are adapted to the applicable standards within XML and JSON: Within AFD 2.0, date is written as CCYY-MM-DD (with dashes), and time as hh:mm:ss (with colon). timestamp was introduced to facilitate the use of timestamps. See the chapter about data types for more information.
Another innovation is the addition of arrays. By reducing the number of entities in AFD 2.0, entities – more often than in AFD 1.0 – occur repeatedly in a message or function. In AFD 2.0 messages all entities are represented as an array by default, even if only one instance of the entity occurs.
Building on this development some attributes are also optionally used as an array. This assists in the elimination of redundancy in the data catalog. Example attributes are coverageAreaCode (_GEBIED) and companyTypeSpecification (_SBISPCC): a coverage can apply to multiple areas (codelist ADNDKG) and a company can have multiple company types from the corresponding codelist (ADNABS).
Explicit referrals
New in AFD 2.0 is the possibility to explicitly refer to another entity. For example, within a policy component, an explicit reference can be made to the corresponding package policy. In this way, the relationship no longer needs to be implicitly derived from the hierarchy – although hierarchies are still allowed. New attributes for these references are included in the data catalog. For example, within a policy component, the explicit reference to the relevant package can be established using the new masterAgreementRef attribute. See also the Unique identifiers and referrals chapter.
Custom attributes
Within AFD 2.0 it is possible to define attributes that are not necessarily included in the data catalog, but are valid within the context of the relevant message exchange or storage. These custom attributes enable one to communicate data which is not standardized in AFD, such as underwriting questions. Often, this data is business or even product specific, and frequently adapted and/or expanded during the life cycle of the corresponding product. Because this data is so specific, it is less suitable for standardization across the entire industry, and thus less suitable for inclusion in AFD. The customAttribute entityType of the afsElement entity can be used along existing attributes within other entities. See the chapter about custom attributes for more detailed information on how to define and use them.
AFD-definition Standard
Proper and manageable handling of specifications has become essential. With the system of XML templates currently widely in use in the sector, only the maximum allowed set of AFD attributes and AFD entities and their nesting can be checked. Additional specifications are generally supplied in text, which is laborious and error-prone. Taken together, this offers insufficient support for effective validation of messages and recording of data. The new AFD-definition Standard provides a framework for specification and validation in two parts based on industry standards:
- JSON Schema: for defining specifications of messages regarding structures, entities and attributes. The use of JSON Schema promotes the preparation of unambiguous specifications. In addition, JSON Schema can be used as a basis for automated checking of messages, databases and dialogues.
- JSONPath: for defining specifications of relationship checks between attributes that cannot be specified in JSON Schema. The use of JSONPath definitions promotes the creation of unambiguous specifications. In addition JSONPath can be executed by using specific libraries, preventing the need for coding and resulting in less labor and error.
See the chapter about the AFD-definition Standard for more information.
All Finance API-framework
Starting from the late 90’s SOAP/XML was the leading protocol/syntax combination for deploying services on internet. In 2004 SIVI launched the GIM webservice standard. However, technology evolves. Services on internet are no longer depicted as rocket science. Deeper insights led to simplifying the protocol and syntax. In the last decade REST/JSON became rapidly the dominant protocol/syntax combination for deploying services on internet. From now on the REST/JSON protocol/syntax combination will be the default for the SIVI All Finance Standard.
The API-framework is intended to serve as a reference for developing an own API as organization. The API-framework will give guidance around design and supports the development of uniform processes in the distribution chain. In the API-framework existing ADN and GIM functions and new functions are grouped in function families and described independent of specific technology and architecture solutions. In addition, technical specifications are provided in Open API Specification (OAS), following the REST/JSON protocol/syntax combination. With this approach we step into the new world and simultaneously leverage the existing knowledge and experience around ADN and GIM functions.
Feedback
Powered by
Post your comment on this topic.