Architectural (Enterprise/Solution) Perspectives for a Regulatory Change (IFRS 17)

If you work in the insurance industry you are probably aware or have been informed about the forthcoming International Financial Reporting Standard (IFRS) 17, which replaces IFRS 4 and extended to come into force on 1st January 2023.

IFRS 17 will allow investors, the public and analyst to assess an insurance business using a common comparable reporting standard that aims to normalize recognition, measurement, presentation and disclosure of information for insurance contracts by offering a transparent consistent framework across the industry. 

Whilst the ‘go live date’ is now set at Jan 2023, most organisations will need to conduct some form of data gathering, analysis and ‘integrity checking’ to produce a full set of accounts and ensure service margin calculations are correctly administered. Which realistically will most organisations to be ready by 2022 enabling the support and necessary comparisons required to address any adverse impact on their accounts.

In this short blog I will explore some of the ramifications of IFRS 17 viewed from an architectural systems perspective by addressing the following; 

·      A brief overview (primer) of IFRS 17 for non-accountants 

·      The architectural challenge

·      Potential Issues to consider and address

There is no shortage of tutorials for IFRS 17 on the web and the underlying principles are well documented elsewhere e.g. the IFRS Website, however, to fully grasp the enormity of the standard one should have a basic understanding of accounting principles. 

A  brief overview of IFRS 17

IFRS 17 is intended to provide a baseline approach for transparent and consistent reporting across the insurance industry, where profits can no longer be booked on day one and the insurance contract liability now includes a liability for coverage, which is released as insurance services are provided along the term of policy which is referred to as the Contractual Service Margin(CSM) and is calculated at the inception of the contract.

The CSM represents the expected profit from the insurance contract over the life of that contract and takes into account the overall fulfilment of the contract which considers the following in the;

  • Future Cash Flow i.e. the inflows from things such as premiums and the miscellaneous outflows e.g. the claims, admin expenses and other costs associated with the policy.
  • Discounting the above to represent a present value (PV) 
  • Any miscellaneous adjustments for risks associated with the contract 

As one would expect the risk calculations associated with the contract will require input from other parts of the organisation primarily the Actuarial[1] Systems.

It is worth mentioning that IFRS 17 provides three models for insurance companies to address / calculate liability measurement, which supports the type of Insurance business they write (GI,Life etc) which are;

  • General Measurement Model (referred to as the Building Block approach) the default model.
  • Variable Fee Approach
  • Premium Allocation Approach 

The adoption of any of the  above allows and supports insurance companies  to tailor their liability calculations during the coverage period and further depicted below with some of the variables which affect the models.

Above, we have touched on a single insurance contract, however insurance companies will have thousands, if not hundreds of thousands, of contracts. IFRS 17 allows grouping of the profitable and non-profitable policies, with similar risks, written more than a year apart to be clustered into what the IFRS 17 refers to as cohorts.

Cohort grouping supports a simplified approach to accounting in terms of reporting for profitability and time on a portfolio. It must be noted that once a policy is assigned to a group it cannot be reassigned at a future date.

IFRS 17 presents a major opportunity for insurance companies to update legacy accounting systems and to streamline inefficient business processes on the premise that there is now a need to modify ledgers to accommodate a new global chart of accounts (COA) which now considers the CSM calculations.

The above was a very quick introduction to IFRS 17 aimed to highlight the changes required when a new regulation is introduced and especially when one must now report on risks, liabilities and the characteristics of those liabilities amongst other things during the life of the contract. 

More information can be found at the IFRS 17 website regarding the standard, example calculations and accounting impacts (link below).

The Enterprise / Solution Architectural challenges

As a regulatory change goes, IFRS 17 presents a typical scenario for Architects, in that they must consider both the macro and micro impacts on the systems landscape. 

Architects will initially view these impacts with two lenses;

  • The enterprise lens i.e. the macro impact/ governance view
  • The solution lens with its focus on introduction, modification or amendment to existing or new capabilities to deliver the desired outcomes.

Both perspectives/views are discussed briefly below

🌏 The Enterprise Architectural (EA) View 

IFRS 17 is now a reality for most Insurance businesses across the globe i.e. a variable in their business operating model (BOM) that has subsequent downstream impacts and effects on the technology estate.

IFRS 17 on the one hand can be perceived  as very much data centric, with its extensive demands for the level of granularity of data required  and thus deep routed  across the enterprise data & Information technology layers. However, as with most regulatory changes there will be impacts on other areas of the stack e.g. information exchanges, configuration changes in reporting applications amongst other things will need to be addressed.

An example of some of the areas from an enterprise perspective from this regulatory change are highlighted below i.e. the black shaded areas on the ESA Stack below.

Figure 1 The EA View of of Change

For more Information on the ESA Stack and its use see the ESA Book

The enterprise systems view, as one would expect, should initially focus on collection, processing and analysis of policy data and the flows (upstream/ downstream) between the various internal & external systems.   

Realistically, from an Enterprise Systems perspective, there is minimal impact on the macro technology business landscape, as IFRS 17 is mainly a data structure/reporting change and hence should leverage existing internal systems capabilities. It must be noted that there is a need for Finance and Actuarial to undertake greater collaboration something previously a loosely coupled activity.

The existing capability maps will remain very much unchanged however there will be a need for a new CSM capability, which will be required to support the calculations applied to the accounting ledgers.

The main impact, other than the CSM, would at the Solution Architectural layer which is discussed below.

🏗 The Solution Architecture View  

In real terms, most organisations should not expect to see any major physical[i] changes to the overall technology estate. Accounting System will require bespoke changes (chart of account, ledgers etc.) with the introduction of a CSM and cohort component representing the significant change. 

Changes will require Solution Architect input to support the design, validation and integrity of the existing and new systems which should be divided into the following four categories; 

  •  Source systems - Policy Admin and related transactional systems
  • Tools and stores for the extraction and manipulation of data sets
  • Accounting systems and the rules for postings to and from the relevant data stores and ledgers.
  • The various regulatory and organisational reporting BI/MI components.

The above four areas are depicted with some of the additional key elements highlighted and discussed further below;

Figure 2 One of many Solution Views

The above diagram depicts the typical systems and components found in an Insurance IFRS 17 data / reporting flow (left to right) where;

·      Transactional / Source Systems relate to the core Insurance systems found in many organisations such as:

o   Policy Administration systems responsible for managing the administration of the insurance contract during its term and any associated transactional information (premiums / discounts etc.) that relate to the contract.

o   Claims systems which capture, record and manage the claims lifecycle i.e. the information relating to claims made against the insurance contract 

o   Actuarial systems which manage the assigned risks associated with the contracts. 

o   For multi-national organisations that operate in different markets across the globe then it will be important to maintain a currency exchange rate set of figures to enable calculation of a unified NPV for all contracts 

o   As with most organisations there is always bespoke accounting systems with a on a specific function e.g. tax or disclosure. 

·      Data and in some cases granular will be sourced from the systems listed above. This extracted data should be ringfenced and stored in a single separate container, maybe its own data lake away from the source systems. The data may arive in multiple formats and needs to be cleaned, aggregated and structured to conform to the master data structures i.e. the corporate data model which highlights how data is produced, consumed and associated (related/linked) between the data objects.

Reference Data such as country codes, postcodes, transactional codes etc. i.e. information variables that will not change during the life of a contract should be stored independently from the master transactional data as these are tables that will not change frequently.

Data movement between systems and stores (staging areas, transformational stores, audit stores etc.) will require secure exchange mechanism or Application Programming Interface (API) to expose information between systems, either way you will need to create the mechanisms to extract and ingest the relevant transactional data between these systems. 

The amount of effort required for Extraction Transformation and Load (ETL) which should be automated so conversion of raw data from external systems into the desired data format for import into the downstream systems should not be underestimated.

·      Core Accounting provides the capabilities to manage the accounting information, manage postings of entries to the various ledgers (accounts payable, accounts receivable, cash management, fixed assets, purchasing, projects etc.) which ultimately post to the central repository for all accounting data i.e. the General Ledger (GL).

The new variable is the Cohort and the ‘Service Margins’ for the insurance contracts. The cohorts and CSM will introduce new accounting modules/services or applications that will require deploying on the technology estate in a controlled safe way ensuring the integrity of all the accounting systems.

·      Reporting as the name suggest relates to the components used to deliver the reporting capabilities to the organisation. These capabilities should already be pervasive in the organisation and reuse will require reconfiguration 

The frequency of internal and external reporting should not be underestimated. Insurers will need the flexibility to audit results to the data’s point of origin which needs to be factored into any architectural solutions.

The above briefly highlights changes that will need to be made to data, systems, processes and we should not ignore the people element which unfortunately is out of scope for this blog.

Solution Architects will need to understand the source and destination systems ensuring that the integrity of the data remains constant as the data is moved between systems in a secure auditable way.

Potential Issues to consider and address

On the face of it the above seems quite simple i.e. moving data from system x to system y. This is far from the truth as there are major challenges to face when discussing adopting this new standard, some of which are listed below;

·      Transition i.e. period when existing business needs to be transitioned into the new IFRS 17 standards to create the opening balance sheet and comparatives insurers will need to do a retrospective analysis of previous years and allows for assumptions hence the first challenge is completing everything within a specified time period.

IFRS 17 requires actuarial and finance teams to work together closer as the need for granular data relating to risk and ongoing liabilities are understood so that there is a consistent, fair  and detailed allocation of expenses over contract periods. 

·        Data Management - A holistic approach needs to be taken to address the data issues at an enterprise level to reach a target operating model that considers capture, quality checks, management of cohorts, calculation of CSM and CSM release – including General Ledger and report production

With data volumes under IFRS 17 being immense and the level of granularity required for analysis of current, historical information for policy, premiums information, exchange rates which represents a significant challenge.

·      Reporting – will require an integrated data model which if absent will present a major challenge. Day one reporting for measurement standards will be a key challenge under IFRS 17.

 If data is fragmented, automation is lacking then the reporting process can be time-consuming, prone to human error and not cost-efficient hence poses a significant challenge.

·      Automation – For any process to be successful and minimize any potential bottlenecks or areas of failure it is important to automate the end-to-end process as much as possible

It is may not be possible to achieve within the time constraints, especially if you are a global organisation. However, systems tasks e.g. data ingestion, management of cohort allocation, CSM analysis and output processes to the relevant ledgers and reports should be automated 

Above we touched in a somewhat simplistic manner the impact from a new regulatory requirement, however this is far from a simple set of tasks as any changes will affect the technology estate. Major changes will be driven by the desire to  collect, store, analyse and report on data to a granular level which is a huge undertaking and should not be underestimated. 

If you work in the Insurance sector then it would be prudent to be familiar with the new changes  before they arrive or you are asked to design or deploy any components or systems.

Useful URLS 

IFRS  17 - https://www.ifrs.org/issued-standards/list-of-standards/ifrs-17-insurance-contracts/

IFRS 17 The Accounting Explained – https://www.youtube.com/watch?v=p-Mv3O_w-1s



[1] Actuaries compile and analyse statistics to calculate insurance risks and premiums associated with an Insurance contract.

 [i] Additional processing capacity and data persistence may be required to compute CSM, metrics e.g. estimate cashflows, risk adjustments, discounting and allocations resulting large volumes of data, including granularity and complexity of the calculations


Comments

Popular posts from this blog

Solution Design - Table of Contents

Enterprise Architecture, Digital Transformation and ICT Strategy - Seminar Video Presented at the AUC Egypt

Reflecting on Error Management and listing HTTP Status Codes