IFRS 17: How to approach the technology challenges

A new standard

As of April 2017, IFRS 17 for insurance contracts is final and official. It sets new standards for financial reporting bringing homogenization and comparability across the insurance market. It will be active from January 2021. In this post, we propose architectural approaches regarding data management requirements focusing on the financial management systems of insurers.


Insurers have often falsely considered digitalization linked mainly to customer-facing applications. Although many of these initiatives improved the organization’s digital capabilities and maturity, there is a part of the company which was often neglected and ‘stuck’ to older technologies; Accounting.

Solvency II has highlighted the need for consistent data across systems, but IFRS 17 explicitly imposes granularity and traceability requirements.

These requirements present unique challenges which can also lead to significant benefits, transforming the finance, risk, and actuarial functions to leaner, high performing entities with shorter closing, audit, evaluation and calculation times. They also empower the CFO role providing more decision-making capabilities, enabling the CFO to become a strategic business partner.

Approaches to solutions

There are two main approaches; One is to consider IFRS 17 an obligation and try just barely to meet its requirements. The other is to see it as an opportunity and lay the foundations for modernizing an aging and fragmented infrastructure, increase automation and potentially reach a state of operational excellence for accounting, risk, and actuarial functions. IT departments also have much to gain from a new systems architecture which is efficient and future-proof.

Every environment is unique.

Every technology landscape has evolved throughout the years, and technology decisions have created a unique situation for each insurer.  It is highly improbable that a combination of core, actuarial and financial systems is identical, even in companies operating within the same group.

Data in the spotlight

Until now, interfaces from insurance applications forwarded aggregated information to financial systems which were the only unified source of financial data. Regardless of a Data Warehouse is in place or not, financial systems use their own dedicated and always reconciled data stream. Due to their nature, data warehouses are often not 100% accurate, but accurate enough for decision making.

Insurers will eventually face the dilemma; Can I further exploit recent investments like a data warehouse or a new financial management system, or do I need a separate solution to integrate all financial and risk data in a timely and accurate manner?

Suggested Architectural Approaches

I. Data warehouse

Many insurers will choose to use a data warehouse as a primary data repository for IFRS 17. Data can be stored in a very granular level enabling data-driven decision making. This strategy is entirely plausible but has a caveat; The data warehouse cannot act as an active component. It is a data repository which can comply with reporting requirements but cannot perform transactions. Particular care should be taken when deciding to incorporate the data warehouse into the financial closing procedure. It could add significant time to the process, or it could cost a lot to provide 100% accurate data for related bookings since most of the times the data warehouse scope does not require real-time, full reconciliations like accounting systems do.

IIInsurance Subledger

A subledger adds specific business context to financial transaction bookings. Subledgers are de facto reconciled with General Ledgers since they are the ones that provide them with data. They become a data hub for all finance related information including the bookings produced from complex calculations like the ones needed for IFRS 17.

Additionally, a subledger is capable of executing financial transactions. Data can be gathered from various back-end systems and homogenized. Subledgers could become a central point of performing activities like collections, payments and provide customer and business partner 360 views. A subledger can perform these functions centrally, eliminating the need to execute them in each Line of Business application in a fragmented environment.

For more information, please see a previous post regarding subledgers here.

A workaround for compliance; General Ledger ‘thickening’

In case a modern financial management application is already in place, adding more business context and information to your general ledger could also be a viable option.

Given that the system is capable of handling the added detail, it could serve as a central repository, exchanging information with insurance and actuarial systems using meticulously designed and well-performing interfacing mechanisms. The majority of transactions would still be performed in the peripheral back-end insurance systems.

Reporting capabilities will be enhanced, but cannot match the ones a data warehouse or a subledger can provide. Granularity should be kept at the minimum level where compliance is achieved so that the data volume does not become a drawback.

It is possible though, that when the organization decides to perceive finance in a more strategic manner, additional work would be required and one of the aforementioned strategies would be probably realized.

Where to start

The first step is an assessment of your situation in regards to IFRS 17 requirements. The evaluation will help to shape the technology roadmap that one must follow without overspending or underinvesting.

But ROI calculation can be tricky. The total cost/benefit analysis must also include intangible benefits for the enterprise. If you invest as little as possible, it is very likely that even if you achieve compliance, the operational overhead will be higher from the moment of implementation and onwards.

If you need assistance, improvIT can help you undertake the IFRS 17 endeavor step-by-step, create a technology roadmap, make the right choices, and implement the required solutions.


Insurance accounting subledger; The missing piece?


The problem.

The insurance IT landscape is most of the times a very complex one. It consists of multiple policy management, claim handling, reinsurance, payments and other systems generating a huge number of daily transactions.

A common integration layer for all these sources, depicting their financial related transactions is the organization’s accounting system. But usually, it contains just enough information for high-level reporting and just the minimum in order to perform functions like third party payments. This is more or less expected since detailed business context information can’t be handled by a general purpose accounting system designed to serve any kind of industry.

Here is a non-exhaustive list of issues that are common is such architectures;

  • The IT landscape consists of multiple systems which feed a general purpose accounting system for which mapping of bookings to their originating business transactions is difficult.
  • Collections and disbursement processes are sometimes slow, inaccurate and fragmented resulting in customer, intermediary and vendor dissatisfaction.
  • Finance departments cannot easily create diversified statutory and regulatory reports due to lack of detailed information.
  • CFOs cannot play their intended strategic role since they do not have the required data foundation to build upon.
  • Audit cycles are taking too long and data consistency is a reoccurring issue.
  • Open items in core systems close after separating collection lots by line of business, distributing transactions back to core systems, making collections more complex than they should be.
  • Reinsurance departments deal with a pile of reports and have to perform manual calculations.
  • Commission and incentives calculations are hard since you have to combine information from multiple systems. Many times errors occur due to non-uniform application or rules and payments cannot be mapped easily to individual source records.

A solution.

An accounting subledger can help fix the problems related to lack of detail, ambiguity, and fragmentation. Like other accounting sub-ledgers which hold more detailed information than the General Ledger, an insurance subledger integrates detailed information from all source core systems in a specialized and flexible data layer.

It is by no means just a data storage layer but an active component performing many functions itself. Here are some examples;

  • Intermediary commissions calculations and clearings based on commission rules and commercial policies.
  • Reinsurance premiums, claims and commissions calculations based on reinsurance treaties. Generates all relevant reports and performs remittances.
  • Can be used for dunning, perform collections and disbursements utilizing various collection and payment methods across all lines of business.
  • Creates accounting postings with highly detailed information regarding business entities down to the cover level of a policy. This is quite important since it can overcome the inability of source systems to handle specific exceptions or agreements over multiple lines of business.

Does it fit a data warehouse architecture?

A subledger is not a data warehouse solution component, but it could add great value to a business intelligence project by being a reliable data source. It contains reconciled information from all lines of business with satisfactory detail levels.

Actually, many modern analytical tools like SAP BW, Microsoft Analysis Services, Tableau, Qlik, etc. could potentially be directly fed by the subledger repository, eliminating the need for an atomic data warehouse layer.

Is it a panacea?

An insurance subledger implementation is not the only strategy which can tackle the problems mentioned in this article but it seems to be a very good one, all things considered. Apart from its obvious benefits regarding financial accounting, it can become a catalyst for other initiatives regarding, for example, risk management, reporting & analytics, even CRM, by considerably shortening their implementation cycles. Taking these into account, a sublegder project can be easily justified.

Get more info on this subject.

If you found this topic interesting, please leave a comment with your point of view or questions and feel free to contact improvIT in order to schedule a more in-depth discussion regarding your own landscape. Our experienced consultants can answer your questions and help you formulate your implementation strategy.