Based on the AFD-definition Standard, parties design schemas and AFD validation rules for a financial product for applicable services (e.g. premium calculation) and/or registration (policy recording). Schemes and validation rules are made available by the provider.
Once made available, the software developer can retrieve these AFD-definitions and process and/or store them within the application’s environment.
The Schemas and AFD validation rules provide support for developers to develop software in a structured and uniform way, for, for example, comparison or administration software. The goal is to create largely configurable software for:
- Setting up screen dialogs
- Validating web service calls
- Validating AFD messages for storage in the form of structured and unstructured data
Use within administration software
It must be clear to users – when performing a step within a financial process (such as calculating the premium or supplying policy data) – which data elements are mandatory and which values are permitted.
The use of the AFD-definition Standard makes it possible to configure the screen dialogues according to the structure as defined within the AFD-definition. This makes it clearer to the user of the software which data elements are mandatory, which values are allowed and which relations between the entered data apply. Any inaccuracies can be returned to and corrected by the user directly. Screen dialogs cannot be closed unless they are correct and complete.
Services – Avoiding failures
When calling a service, it is important that a call generates as little failures as possible. The use of the AFD-definition Standard makes it possible to validate data and relations between data elements immediately, even before a web service is used. Consequently, requesting results will generate much less failures and result in a higher outcome ratio.
Registration and storage
Only data that meet the requirements for storage in the database, can be submitted. The AFD-definition Standard offers a blueprint for the structure in which data should be stored. This is important in case of NoSQL databases. Storage can take place in the form of structured, semi-structured and non-structured data.
More and more often, databases are no longer fully organized at field level, but based on an XML or JSON structure. Only data elements that are important for the operational processes are included in the database. The other data, for example data important for acceptance, are combined and stored in a group. This is called (semi-)structured data.
Post your comment on this topic.