In addition to the All Finance Data Catalog (Introduction All Finance Data Catalog), the All Finance API-framework (AFA) forms the basis for the digital ecosystem (see also Introduction AFS). Within the digital ecosystem, the use of web services plays an essential role, whether it is exchange of data, performing functions or following a workflow within the distribution chain. The characteristic of a web service is that two machines communicate directly with each other (synchronous communication) to perform a service (function). For example, rate calculation from a comparator. The communication almost always takes place via a (secure) internet connection. Making one or more web services available to third parties is called an API (Application Programming Interface). For many organizations, APIs are essential for digital business. They provide a means to offer transactions (such as tariff, quote, application, …) and publish content (such as object data, weather data, …). An API-framework:
• Provides insight into which functions / services are currently pre-defined with the financial services industry.
• Where possible ensures unambiguous processes between parties.
• Ensures good accessibility of online services within the distribution chain.
• Enables co-creation whereby third parties can develop applications.
The SIVI All Finance API-framework partly consists of new functions, but is mainly a rearrangement of the previous ‘AFD webservices’ standard.
Figure 6-1 provides an overview of the building blocks of the API-framework within the All Finance Standard. The blue blocks are specific to the financial services industry. The yellow blocks are additional agreements made around the relevant generic standard for use within the domain.
Structure of the API-framework
The API-framework function hierarchy has been drawn up in line with processes within the distribution chain and is designed to support four domains (figure 6-2). With this, the API framework supports an important part of the work areas within financial services. The functions are grouped in 13 function groups. These functions groups can best been seen as application areas, most application areas have a specific AFD structure (see also AFD structures). Within the 13 function groups in total 22 functions are defined. The functions can be divided in three categories, based on the purpose for which they are intended:
- Functions that include
terminateare intended to perform classic CRUD-like (Create, Read, Update, Delete) operations on core entities. A set of data in one of the AFD structures is used to establish, consult, change or (potentially) eliminate a record in a system of record. Examples are adding a new policy, changing a claim or consulting a party.
- Procedural functions are designed to facilitate processes. They are not aimed at processing data for a system of record (such as a policy- or claim administration), but rather to process data in order to support a process. The data set may very well contain information on an (insurable) object like a car or a house, but the purpose is not to register that information in a policy or claim record. Instead, it is used in an operational process like calculating a premium for a quote, or performing a risk assessment as part of underwriting.
- Catalog functions are used to fetch master data as part of a business process. Examples are a product definition, or a set of conditions which can be used to present a choice.
Within the 22 functions in total 82 variants are defined. For example for
submitPolicy 8 variants are defined. By recognizing multiple variants, a very large collection of endpoints for functions is prevented.
Generic functional description, technical details based on JSON/REST
The objective for the API-framework is to describes functions as much as possible independent of their technical implementation. In general the functional requirements are more constant in time than the requirements around technical implementation. Therefore functions are described using system agnostic (architecture, application and platform neutral) terminology in order to avoid any dependencies on specific technology or architecture. Starting with SIVI 2.0 the more technical elaborations and examples are based on the general use of REST (web) APIs. Technical specifications are drafted according to the Open API Specification (OAS) 3.0 standard.
In the Function overview the functions and variants included in API-framework are listed.