IFRS17 data staging platforms
André Erasmus??
IFRS17 ? Climate Change | IFRS S1 | IFRS S2 ? Actuarial Consulting ? Modelling Software ? Insurance | ORSA | MCEV | SII | SAM ? Banking | IFRS9
The IFRS17 data workstream
Data processing is probably the most costly and time consuming workstream in the IFRS17 implementation projects. For insurers looking towards IFRS17 compliance, there’s a magnitude of work lying ahead in building staging platforms, transforming data into required formats, and piping this data through the newly created IFRS17 systems.
The full data workstream is likely to consist of the following parts:
- Understanding the data requirements of your IFRS17 processes such as the accounting engine and actuarial models.
- Building a staging platform or adjusting the current staging system in order to make all required data available for upstream processes.
- Building transformations into the staging platform in order to get data into the required format for the actuarial models and IFRS17 accounting engines.
- Piping data through all the upstream systems such as the IFRS17 actuarial models and accounting engines.
Understanding vendor input requirements
Another article has been written solely on vendor input requirements, since there are so many areas to explore. At a high level, insurers first need to understand exactly what inputs are required by the vendor solutions such that the transformation logic can be designed and understood by the data administrators. Luckily this is something the vendor and the implementation partner could assist with. This will reduce the workload as well as the associated risks in delving into data definitions and spending months on getting a good understanding of the data requirements. When the insurer researches implementation partners, it is utterly important to find one with good IFRS17 transformation experience and with a clear understanding of data processes in general.
What is a staging platform?
A staging platform is an intermediate storage area used for data processing during the extract, transform and load (ETL) process. The staging platform sits between the insurer’s source systems and upstream systems like the actuarial models and IFRS17 accounting engines. This relationship may even be cyclic, since data from upstream systems may flow back to the staging area for further processing cycles. For example, the expected cash flows generated by the actuarial models may flow back to the staging platform where the data gets transformed into a format that could be used by the IFRS17 accounting engine. This is obviously also true for any additional results generated by the IFRS17 accounting engines.
The staging platform could, therefore, be seen as a large data warehouse which holds source data, processed data and, in fact, any upstream results. The typical data points are closing balances, locked in yield curves, closing expected cash flows, coverage units and any data necessary for IFRS17 calculations. There are various ways data could be stored, however keeping the data in a single database with coherent API access is potentially the best strategy. This will allow the insurer to most effectively leverage data administrator resources and software for managing their database, while spreading the data warehouse running costs over multiple processes and functions.
Building and adjusting the staging platform
The effort required to build the staging platform depends on how mature the insurer’s data management processes are and how easy it is for them to extract data from all the policy administration systems. Once the data is all in one place the insurer can transform it from there to get the data consistent and ready for transformations to upstream systems (like the actuarial models and IFRS17 accounting engine). Generally this is not an issue as insurers already collect all the required information and have it readily available in a database from where it can be transformed to the required input for upstream systems. However, for others there are a few reasons this could be an issue and might still need to work on their staging platform. Some examples are:
- Extracting data from the policy administration systems is strenuous and time consuming (especially if the insurer has legacy systems).
- The data required is not currently being extracted from the source systems.
- Data needs to be enriched for items that’s required but don’t exist in the systems.
- The data is not kept in a consistent format in one data warehouse.
- The insurer does not have the required resources (like database administrators) to assist with updates to the extraction process.
- The actuarial software used might not have the capability to automatically aggregate results to IFRS17 group level and an external tool is required to fill this function.
Data transformations
Transforming the data into the format required by the IFRS17 vendor solution is something that can essentially only really be started once:
- the vendor solution has been chosen,
- all the data is kept in a consistent format in the staging platform, and
- the insurer has a really good understanding of their own data as well as the data input requirements by the vendor.
Once the insurer has reached this point, data administrators can build in transformations in various programming languages aimed at handling large datasets. Insurers should utilise these data administrators who have the skills to quickly and efficiently transform data and set up automatic transformations to make the data processes as smooth and fast as possible.
Conclusion
The data workstream is daunting, however if insurers have a good strategy around how they plan to process data for the purpose of IFRS17 reporting, there’s no reason why this is not an opportunity to improve on current data management systems and automate the processes involved. A good strategy involves:
- the setting up or improvement of a staging platform that can manage all the data involved under IFRS17 reporting,
- fully understanding the IFRS17 vendor input requirements, and
- making use of data administration experts (people who have relevant experience with the required programming languages).
As the Roman philosopher Seneca said,
“Luck is what happens when preparation meets opportunity."
So let’s make sure we use the people who are prepared and have the adequate skill sets to flourish when given the opportunities where they could outperform and create immense value for Insurers on these workstreams.
Need help on your IFRS17 implementation project? Then contact me on LinkedIn to see how we at Virtual Actuary can assist.
Did you have any comments? Please leave a comment and let me know what you think.
Did you like this blog? Then follow me and Virtual Actuary on LinkedIn for more IFRS17 blogs and keep an eye out for the next one.
What should I write about next? Let me know what you’d like me to write about next in the comments below.
Have any questions about Virtual Actuary? Visit our website at https://www.virtualactuary.com/ for more information.
Founder of Data Symphony, Consulting Actuarial Process SME, FASSA, GIBS, Data Science (SQL, Python, Spark, R)
3 年Nice article André Erasmus, Malan Kriel and Simoné Streicher.