Back to Systemorph IFRS 17
Compliance Series

IFRS 17 heavy lifting: why ‘out of the box’ solutions are not realistic

By now, most insurers have gained extensive experience with their implementation attempts to achieve IFRS 17 compliance.

In this blog post, we want to share some of our key observations and offer actual solutions to the heavy lifting that is required to bring your IFRS 17 reporting process and system landscape to production level.

Despite the significant struggles in setting up an “out of the box” solution, many players in the vendor space still assert that a “compliance ready” solution can be imposed on historically grown system, data and methodology landscapes.

What ‘out of the box’ really means

Our experience shows that many insurers were tempted by the “out of the box” promise. It is attractive to think that you can simply install such a solution, feed it with data and customize it according to your needs. The outcome so far is a significant amount of money burned by many insurers without bringing the reporting processes and finance system landscapes to the required level for IFRS 17 compliance. In other words: sunk cost.

The misconceptions that we encounter in many client discussions often have three dimensions:

  • Getting a ”ready to go” data model will allow you to avoid internal discussions on how to approach the nuances of IFRS 17 modelling and reporting

  • Creating a “single source of truth” of input data would finally lead to alignment in the language and nomenclature used across the functional and organisational units

Trusting a “black box” solution is the way to go and it must be working because everybody else is using it or something similar.

Unfortunately, all of these misguided beliefs will lead to failed compliance implementations.

The most dangerous trap is to believe that complex data full of historical variations in nomenclature and differing interpretations (i.e. semantic versioning of attributes) can be squeezed into a ready-made data model, if only everyone would adhere to the newly introduced standard.

The reality is of course different. Even if you would manage to get everyone in the organisation to agree on this pre-set data model, not even a few months in the future the alignment would break down again. Organizations aren’t static entities but keep on changing constantly.

Moreover, the drawback we see from this approach is that the organization spends significant time in understanding a “foreign” data model only to conclude that it will not work. There will be too many exceptions and requirements within the organization to run a one-size-fits-all data model. As a result, the dream of a “single source of truth” is compromised as well. Especially functions that are closer to the front, such as underwriters, will have different needs to express their data than following a certain reporting language that is not first priority to their daily business.

What is the solution to this conundrum? It is the ability of your underlying financial data management  processes and systems to give everyone the freedom to speak in their own language. It is the ability to include these outliers and special cases with ease, not ignoring them to satisfy a certain data model.

Implementation of IFRS 17 data management does not follow a recipe

Fulfilling the compliance requirements of IFRS 17 even in their most basic form does not mean following a prescribed recipe. The principle-based nature of the standard and the complexities of historically grown actuarial models require a lot of thought when it comes to feeding your input data into a third-party vendor model.

Examples include the granularity and actuarial cashflow estimates versus the granularity of actuals recorded by technical accounting functions, the needs of forward-looking planning and the restrictions of available input data.

Many steering frameworks in the past relied on IFRS 4 accounting data and inputs from a chosen economic capital model. From a timing and data perspective it was possible to combine these metrics in rather simple models that did not consider significant interaction between accounting figures and economic capital. For example, accounting profit did not relate directly to parameter changes in economic capital.

Today effective steering under IFRS 17 requires the assessment of scenarios that heavily depend on a number of economic metrics and allocation keys directly within the accounting data.

As a result, your IFRS 17 calculation engine and data model need to provide you with this flexibility to run scenarios, planning and budgeting exercises directly within the calculation engine to capture the impacts on your balance sheet and P&L.

Systemorph: True ‘out of the box’ data management functionalities to implement customer specific approach

The Systemorph Platform has been developed to solve one key problem in your financial reporting  processes: Versioning and seamless administration of complex financial reporting data.

When we talk about “out of the box,” we are talking about a data management foundation, not a force-fit data model. We mean that the key is a mature and production-tested data management platform that can cope with the complex data landscape of multinational and global insurance organizations.

Of course, there are nuances to how to implement certain IFRS 17 methodologies with each new project. The ability to implement by factors faster than traditional vendor solutions comes not from a pre-defined IFRS 17 methodology engine but mostly form the power of a proven data management solution. Such a solution can actually orchestrate customized reports, changes to actuarial and reporting methodology, or onboarding of new entities within days. It does not require months of hardcoding a mapping to a so-called “out of the box” data model. If you would like to learn more on the possibilities to turn your IFRS 17 implementation into the right direction get in touch with us today to explore our IFRS 17 solution.

Contact us today to learn more about how Systemorph’s solutions
can help you achieve IFRS 17 compliance.