Challenges of IFRS 17
2022 is getting closer and insurance companies still struggle with IFRS 17 implementation. They haven’t seen any results based on real data so far. In order to be ready for IFRS 17, they need to run IFRS 4 and IFRS 17 in parallel. What are the challenges and how are they overcome? The data management system Systemorph has the solution.
1. Data preparation and input
The challenges associated with IFRS 17 are not accounting or actuarial issues but related to data, as the new standard requires more granularity and strict data management control. Many insurance companies face a disparate data situation, as IT systems have often been developed in silos. This makes data exchange a laborious manual task, as granularity and data language must be aligned to produce the required reports. To remedy this, professional data integration and solid business processes are needed.
Let us first consider the issue of granularity. The main data granularity is coupled with the company hierarchy such as subsidiaries in different countries and divisions. This defines at which level data are provided. Nevertheless, it depends on how actuals were stored in the past, whether on the aggregated or on the policy level. It also depends on your data management policy and systems. You cannot change past data and get along with the actuals. But you can affect the granularity of the expected cash flows. Significant effort may be necessary, but this can be worthwhile for future accounting. You also profit from more flexibility in terms of setting the appropriate level of aggregation. Different aggregation levels for actuals and expected cash flows are a common hurdle (see example in figure 1). Thus, you need to bring your data to the same level. If you want to account on the more granular level, you have to apply an allocation key on actuals to distribute the amount reasonably to each policy (option 1). This is quite complex. Option 2, where the expected cash flows are brought to the same level as the actuals, is easier. The grouping follows the hierarchical structure.
Data analysis and data quality
It is an illusion to think that your captured data is 100% correct and that no analysis or quality checks are required. Therefore, you should validate your data before you start calculating. It will save last-minute troubleshooting and bug fixes that are nerve-racking and cost-intensive. With Systemorph’s solution, data cleansing is handled outside the system. This approach assures that the wrong data will not be uploaded. Furthermore, it prevents you from using the wrong data for your calculations. To achieve such a clear state, both soft and hard validation rules are necessary. Hard rules filter fatal errors out. These need to be checked manually and must be gathered again. Soft data validation rules lead to proper data entries. This approach ensures high data quality.
Storing and versioning
The IFRS 17 standard calls for strict requirements on audit trails, data lineage and versioning. This is an extra challenge to most of the existing systems. Only a few technologies can properly deal with such requirements. The technology for IFRS 17 implementation should not only perform the calculations and reports, but also guarantee that all data states are captured appropriately. This allows for easy retracing of every data version. Versioning is not only important from a compliance perspective, it also provides for data storing in an organized and structured environment. Only in this way can a proper comparison of different years be efficiently done. We have observed that where real data (i.e. actuals and expected cash flows) is concerned, decent data preparation and input is crucial to the success of your IFRS 17 implementation.
The data work is completed and now you are ready to start with the «actual work» of IFRS 17. You implement your methodology and get an idea about the magnitude of the IFRS 17 impact. But what if your results do not match your expectations based on the unit of account (UoA) you decided on? What if you do not know what UoA is best for your company?
2. Unit of account definition
Many insurers derive their UoA definition based on testing or simplified datasets. They are shocked when they see their IFRS 17 results based on real data. It’s therefore advisable to be proactive to avoid these nasty surprises. It is very important to see IFRS 17 results based on data from real portfolios. Although the individual IFRS 17 formulas are not very complex, our experience is that many of the calculations required by the standard produce unexpected results when the data is aggregated.
What’s wrong with testing your approach on mock data?
The standard prescribes general guidelines, meaning that insurers have a significant degree of freedom to decide how to define their UoA. You should base your initial approach on real portfolios to get an idea of the impact of IFRS 17 and to see that you are on the right path. It is too risky to extrapolate the results based on simplified data or individual policies and then expect those results to meet your expectations. To draw firm conclusions, you need genuine data. The sooner you get meaningful results, the more time you will have to adjust grouping parameters, to refine data granularity, and to reshape your UoA definition. In this way, you will benefit tremendously from early calculations based on true data and avoid unpleasant surprises.
How to find the ideal grouping
It’s challenging to find the ideal grouping of policies for each company. Once the grouping of policies into UoAs is defined, changing it is not that simple. It’s therefore important to consider different approaches, calculate and then find the UoA that suits best. To achieve this, the IFRS 17 solution must allow dynamic calculation of CSM/LC and P&L, depending on the properties chosen for the grouping. This is not easy, as millions of policies are potentially affected. Moreover, the IFRS 17 tool must offer the functionality to compare the results according to the multiple choices so that a reasonable decision can be made. Systemorph’s solution offers both a comparison view and formula debugger to help find the ideal grouping. The tool retraces every defined step, so you can thoroughly analyze your results (see fig. 1). You can also slice and dice the policies into different aggregations at the touch of a button and receive instantaneous results.
What makes the slice and dice functionality of Systemorph’s solution so valuable?
In one of our proof of concepts (PoCs), the IFRS 17 results according to what the client thought was the optimal UoA definition did not meet expectations. It was therefore crucial to rethink the UoA definition and compare alternative approaches. Fortunately, our client was able to produce expected cash flows and actuals at policy level. The exercise involved finding the best grouping of policies compliant with the standard principles and, in doing so, decrease the number of onerous UoAs. After a few trials with Systemorph’s IFRS 17 solution, they found the appropriate UoA. By the end of the PoC, the client was satisfied with the results and could proceed with developing their own IFRS 17 methodology.
You might believe that once the methodology is defined, you are ready for 2022. But have you thought about the business process and the governance? IFRS 17 isn’t just about finding the right methodology. From a compliance perspective, it must be clear who is responsible for the calculation and who is signing off on it. It’s a matter of traceability and transparency.
3. Business Process and versioning
In the last two sections we looked at the challenges involved in preparing the data and defining the UoA. These are the two things insurers tend to focus on when getting ready for 2022. But IFRS 17 is much more than an accounting and actuarial issue. It affects the whole insurance industry’s operating model and many other non-functional requirements.
In complying with IFRS 17, insurers will have to deal with bigger challenges than just accounting and actuarial issues. These challenges concern the business processes, versioning the data and meeting audit trail requirements.
Workflow and proper documentation
Finding the right IFRS 17 methodology is the initial challenge. But it’s important to realize that the business process itself can become a burden during reporting periods. This is especially true if you want to shorten the time and effort necessary for annual or quarterly reports. One should find a way of dealing with the strict requirements the new standard imposes for:
- Do data lineage and interfaces: where and how data is generated and transferred;
- auditability: who does what when;
- data quality: maturity and validation;
- ownership: approval, review and sign-off;
- transparency: proper process documentation.
In our view, technology will play a major role in addressing these matters and redefine most of the business processes of an insurer. For example, there will be no more exchanging spreadsheets for reporting purposes by e-mail, as this contravenes many of the principles. Systemorph’s solution enables you to handle these activities easily. You can comment on each step without the need for a long explanation as to what in the system your comment refers to. You can ask questions about specific numbers and results and answer them directly in the system. If you have additional information or files that promote understanding, you can simply attach them. Not only does this assure correct auditing, it enables you to easily retrace what you have done and why you performed certain tasks. All the related comments, questions, answers and files are easily accessible.
Handling versioning as per compliance requirements
Another annoyance is keeping track of the different versions of your results. A mess can be created when you save versions for test calculations and overall results in spreadsheets. It’s not easy to track your version history and keep the spreadsheet up to date while people are working on related tasks. It’s therefore crucial to choose the right technology for IFRS 17. Not only should it allow accountants and actuaries to define their methodology, but it should also provide all the relevant infrastructure, flexibility and governance that are compliant with IFRS 17 reporting. To reduce compliance errors and avoid messy version tracking, you need a fully operational system to explore historical data or alternative scenarios. Systemorph’s solution offers an audit trail that runs automatically and does not require any additional tracking from users.
Having worked on several PoCs in past years, we have seen seen that while the initial concern is calculation, the focus shifts to non-functional hurdles as the PoC progresses. This proves that one should not underestimate the importance of the business process and of versioning.