IFRS 17: Are you underestimating the impact on data?
11 June 2021
From time to time, we underestimate. The time expected in lockdown. The number of trophies our football club will win this season. The reliability of wifi during important calls. But underestimating the IFRS 17 impact on data could scupper your transition plans entirely.
The Standard itself brings about some obvious challenges but many don’t arise from the IFRS 17 calculations themselves. Instead the issue is an assumption that data quality is appropriate (when it isn’t) coupled with poor knowledge of existing data, transformations and processes. Whether extending an existing data solution, or developing something new, these five data challenges should not be underestimated.
Manipulating IFRS 4 with caution
IFRS 17 must be implemented alongside IFRS 4, which creates complications when organisations extend their existing data warehouses. The design must consider how the existing financial reporting process works while any development to the data warehouse must not compromise the integrity of IFRS 4. As a result, organisations may need to create mechanisms that can handle dual parallel mapping of transactions - with additional testing effort. For example, certain transactions that are classified as premium refunds, claims or commissions under IFRS 4 could be classified as investment components under IFRS 17. Other clients want to retain multi GAAP or IFRS 4 data for KPI reporting. To avoid affecting the stability of IFRS 17 processes, sequencing is an important consideration.
Sourcing from a ‘black box’
Multiple legacy systems are common, typically with some form of data consolidation. Many IFRS 17 programmes replicate what’s in place when building new data lakes or warehouses. But the effort involved in this is frequently underestimated - as source systems have different codes and there’s a lack of knowledge available on existing consolidation transformations and derivations. It can take many weeks to map source data to your target data model - so it’s important that the effort is understood early in the programme planning.
Knowing the Minimum Viable Product
Before your bold ambitions can bear fruit, you need to ensure you have what’s needed for IFRS 17 minimum compliance. The complexity of data sourcing involved with new data lakes or warehouses means it is critical to prioritise sets of attributes from each source system. Documenting the data lineage for your IFRS 17 reporting is one way to realise your MVP. Do you know what’s needed for minimum compliance today? If not, then working this out later in the programme may take additional effort.
Classifying can be complex
Under IFRS 17, insurers need to separately identify non-distinct investment components to apply the appropriate accounting treatment. In practice, these can be hard to distinguish because they’re not identifiable by a simple query. It takes a considerable amount of time to review transactions individually to determine if transactions fall under investment components - effectively delaying the build and increasing complexity.
Saving time for impact analysis
If you’re designing a new data model or extending an existing one, consider setting aside time to make availability decisions. Core books of business now often sit in newer source systems which may inform your data modelling and downstream analysis. Issues can arise with meeting these requirements from older systems with simpler data models. As a result, some data attributes may need to be non-mandatory and the impact of data sourcing on your requirements must be clearly tracked and managed.
In conclusion, IFRS 17’s impact on data is often initially underestimated. Resolving your data challenges is critical to the success of your programme.
