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.
II. Insurance 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.