There are many articles and discussions on IFRS 17, but each tends to touch on very specific issues rather than show the big picture and help understand the changes coming for the actuary and the decisions which must be made. This article discusses the changing demands of the actuary, the flow of actuarial aspects of IFRS 17, data and assumption challenges, actuarial valuation software, CSM and sub-ledger calculation engine and going beyond compliance.

The changing demands of the actuary:

Traditionally under IFRS 4, the actuarial department would use our actuarial models to produce the actuarial liabilities as of the reporting date. The total actuarial liabilities would then be provided to the finance department, which would then be included as part of the balance sheet and change in actuarial liabilities in the Profit & Loss Statement. The finance department is happy to use draft reserves in their work whilst waiting for us to finish our analysis. Our work is just one small part of the financial statements with disclosures such as gross liabilities and reinsurance assets by type of contracts and sensitivity analysis for key assumptions on gross and net liabilities, surplus, and profit before taxation and shareholder’s equity.

Under IFRS 17 all of this changes. Instead of premium income (something which back-end systems can directly calculate, and the finance team put into the accounts) there is expected benefits and expenses, a purely actuarial calculation. There are also insurance finance expenses (required investment income), risk adjustment and contractual service margins (CSM) which must be released over time. Also, the disclosures required under IFRS 17 are very extensive which include (but not limited to):

• Reconciliation between the opening and closing balances of the future cash hows, risk adjustments and CSM
• Analysis of insurance revenue by comparing with the changes in Liabilities of Remaining Coverage
• Analysis of insurance contracts assets/liabilities for group of contracts that are onerous (separately from other groups)
• Expected recognition of CSM

All of this means a lot more runs of our actuarial software and less ability to hide problems. Remember all the trouble the finance department goes through because of the yearly audit? This trouble is now passed to us!

The flow of actuarial aspects of IFRS 17:

Our actuarial work starts with the collection of policy data and assumptions, which how into our actuarial valuation software. This software produces cash flows which are used in the IFRS 17 calculations. These cash flows are split by cohort, which is according to year of issue, whether they are onerous (loss making) or not, and major product type. We then need to use these cash flows to accumulate the contractual service margin, which is a fancy way of saying the remaining profit which has not been released yet. In IFRS 17 a main goal is the release of profit gradually over time as work is performed. This accumulation takes into account actual payments of benefits and expenses over time and is then used for several purposes including:

• Journal entries for the accounts and disclosures
• Data required for the internal audit, external audit and risk management assessment.
• Output needed for business projections.
• Management analytics

This is shown in the graph below:

These points will be discussed in the following sections.

Data and assumption challenges:

For insurers who have been reserving under Gross Premium Valuation (GPV) most required data to perform IFRS 17 calculations will be already available. We will need to understand which policies belong to which cohort though, so an extra field may be required. We will also need to store profit carrier results, but it is likely this will be based on existing data fields. One data challenge we have seen though is with some reinsurers who have long term guaranteed reinsurance under their treaty business, i.e., reinsurance where the rates are guaranteed. These plans may not have been reserved under a GPV approach in the past so data is likely going to be a challenge.

Most assumptions we will be able to use similar to what we do for GPV. The locked-in rate (discount rate for CSM) though will need to be set by cohort and remains fixed through the duration of the policy. This is likely to be the biggest challenge. We need to balance the desire to be consistent with GPV calculations for statutory reserving and the desire for simplicity as we will need this for every issue year. As an example, if we decide to use the risk-free yield curve and we still have policies in-force from a 1950 issue year do we really want to have to find and store the discount rate from 1950? For multinationals, there is also the challenge of maintaining consistency of the risk adjustment by country. For instance, if the insurer has operations in Malaysia, Thailand and Singapore, the risk adjustment might be different for each country, and perhaps different when doing the calculations at a holding company level (due to diversification).

Actuarial valuation software:

Most larger insurers already perform reserve movement analysis which captures the impact of change in reserves due to model, data and assumptions. This is not the same as the various calculations of IFRS 17, but it is conceptually similar. For IFRS 17, CSM has to be calculated retrospectively using locked-in rates (for BBA), hence a few extra runs using the locked in rate would be required to quantify the change in CSM over the reporting period.

The following run list table outlines the minimum runs required to perform the IFRS 17 calculations:

Step 8, 9 and 11 might be further split into more sub-runs if the impact of each assumption change needs to be quantified separately.

For those of us performing GPV already, it will be much of the same cash flows, but now we will need to keep track of cohorts and save the cash flows (including profit carrier) accordingly. Furthermore, we also need to keep track of changes in IFRS 17 liabilities into different dimensions. For example, we need to keep track of the changes in BEL, RA, CSM and loss component for each step as this would be fed into the reconciliation of liabilities in the disclosure. This process of writing and saving these cash flows can easily cause memory problems, so this is one concern. In the past we might just save the actuarial reserves or a few key values by plan code, so this is a major change.

There are very few formal comparison sites for actuarial software, so we took a simple survey, with 37 respondents: 21 Life insurers, 9 General insurers and 7 others (investment and pensions). The main respondents were from Malaysia but there were respondents from Thailand, Singapore, Indonesia and around the developing world. The life insurers used the software mainly for valuation, but also some business projections and pricing, whereas for general insurers the software was used more heavily for pricing.

Life actuarial software used:

Comments on Prophet:

Run efficiency is considered the most important characteristic, with some respondents happy with Prophet and others unhappy. The reality is that good actuarial programmers will be needed to ensure the coding results in efficient runs. Prophet is considered expensive by many. A reality unfortunately, in developing markets especially. Respondents were happy with the flexibility of Prophet as well as the availability of the libraries and the responsive developer team. The ability to run on the cloud is mixed as this is a new feature. As our runs become longer and longer, it will be important to have very powerful computers, which can get expensive. An alternative is to run on the cloud and pay to use very powerful computers when needed.

Un-modelled business:

For life insurance un-modelled business tends to be group term life, yearly riders and longer-term plans with inadequate data. Yearly riders might be a challenge under IFRS 17 as policies must be modelled on a contract level, implying that riders must be modelled with the corresponding base plan. For say yearly medical riders, we will need to incorporate medical inflation as well as company repricing behavior. There is also other business such as personal loans, which are greater than one year but typically less than five years that might currently be reserved for on a simplified basis. This might not be allowed under IFRS 17.

Life insurer IFRS 17 budget:

Whilst some insurers are still unsure of their IFRS 17 budget, for others, the range for IFRS 17 implementation can be quite wide. Note that these are all for insurers in the developing world, with the largest budget being for a Thai insurer who is currently using excel for actuarial valuation.

General insurer IFRS 17 budget:

For general insurers as well, the variation in budget can be quite large. Those general insurers with long term business of course will face more significant costs, but even for general insurers with only yearly business, there can be reinsurance which extends beyond one year and yearly business as well must be modelled in order to prove the simpler PAA approach is acceptable.

The decision of which valuation software to use is a complex one. For most insurers, there will be a combination of greater memory issues and much longer run times. Considering that for most IFRS 17 valuations there will be 14 times more runs, this can be used to determine if you can live with your existing software. We will also still need to do statutory reserving and maybe tax reserving.

It will be important to experiment with different software if possible. Our experience is that some software is very fast for traditional or straightforward plans, whereas when including more complex options such as having separate unit funds or Takaful funds, some software works significantly better than others.

The elephant in the room is that the finance department will now be waiting on the actuarial calculations in order to put their accounts together, so we will need our programs running very efficiently! It is likely there will be actuaries within the finance team, perhaps called the Finance Actuarial Team (FAT).

CSM and Sub-ledger calculations engine:

What is a CSM and sub-ledger calculation engine? There are many names we can call this new aspect of our work, but the underlying need is for something which will collect the cash flows by cohort and incorporate into the contractual service margins (CSM). Things such as expected cash flows and required interest are also saved for use in the accounts. These will then be incorporated into journal entries which will be used in the various lines of the accounts.

For an insurer who has been around for 20 years writing various types of business, there are likely to be hundreds of cohorts. The challenge is that each cohort must be accumulated forward, under base conditions as well as under the various conditions used in the disclosures. We will need both actuarial cash flows as well as actual accounting items such as claims and investment income. The disclosures are similar to our analysis of surplus calculations in the past, where we show step by step how our reserves change due to assumption and methodology changes and whatnot. The information in this engine is fed directly into the accounts via journal entries. Most likely a sub-journal will be created for IFRS 17 specific entries and that will need to be integrated into the main journal of accounts. Thus, this will be a key focus in the audit process. Our methodology and audit trail needs to be robust in order to make this a smooth process. We may also need to push the CSM back into the actuarial software in order to perform budget projections, normally on a yearly basis for management purposes as well as Financial Conditions Reporting.

CSM and sub-ledger calculation engine solutions can be actuarial based, accounting driven or an intermediate solution. An actuarial based solution would be something along the lines of the FIS Prophet system (combined with SAP). An accounting driven solution would include SAP Insurance Analyzer (MSG Global) and Oracle Insurance IFRS 17 Analyzer. An intermediate solution would include Moody’s Risk Integrity IFRS 17, SAS and Aptitude IFRS 17 Solution.

The advantage of an actuarial based solution is that with CSM development embedded within actuarial calculations model office capabilities such as embedded values, projections and appraisal valuations should be straightforward. Our concern with such a system is that an ‘all in one’ solution is likely to get rather unwieldy, especially as only subsets of the entire process might be needed for a particular use. This could result in ‘light’ and ‘heavy’ versions of the software.

The advantage of an accounting-based solution is that it is an all-in solution, built especially for the particular insurer. Costs as well are one off rather than recurring. Our concerns with such a system are as the rules under IFRS 17 get fine-tuned over time, these solutions are likely less flexible and would require reworking by the vendor (who you are hostage to). This flexibility is important at transition as many CEO’s don’t care about the inner details of IFRS 17 but want no additional capital injections due to IFRS 17 and shareholders transfers under IFRS 17 to be similar to the current basis. Achieving this will require significant testing of various methods and choices.

An intermediate solution could also be called a ‘minimum disruption’ approach. With such a solution, we collect the actuarial cash flows from any actuarial software and outputs results into sub-ledger journal entries for the accounting system to pick up. Thus, this leaves the actuarial and accounting systems relatively untouched. Such a solution would ideally be cloud based, so as IFRS 17 rules change, the system changes will be made automatically with little fuss or headaches. There will also not be the need to maintain the IT infrastructure required under IFRS 17.

A hybrid to the intermediate solution is likely to be the service bureau approach, where one company runs the actuarial software and data warehouse internally and simply provides the sub-journal entries to the insurer. This minimizes strain on the insurer’s actuarial resources, which can be extremely important for small to medium sized insurers. It also allows the insurer to take a wait and see approach before investing in expensive internal systems.

Going beyond compliance:

Whatever system choices we make (existing versus new actuarial system, building or buying a data warehouse system), we are going to have an amazing amount of data at our disposal. IF we can also split our actual claims and expenses by cohort, then we have very detailed profitability indicators for the company and can use this to design management analytics to assist management and the board in its decision making. We will no longer be looking at top line growth and position as there is no more top line! Decision makers will need to have new information available to them, which will be the job of the actuary. This is where management analytics come in, using information from our IFRS 17 calculations.

Putting it all together:

The actuary is entering a new world, where our work is central to the development of the financial statements of the insurance company rather than simply being one line and a footnote. We have all had our experiences with systems which simply did not do what we needed it to do and had numerous manual calculations required. With such complex calculations required of us, we simply must have systems which work for us rather than us working for the system. With a strong understanding of IFRS 17 and its nuances, we can ensure whatever systems we choose are right for us or we can choose an intermediate solution and take a wait and see approach until the dust settles for IFRS 17.