Matthieu Soulas and John Bowers reveal the main sticking points with IFRS 17 implementation and discuss strategies for a smooth completion
Partnered content
It is said that preparation in business is crucial, and this is certainly the case when it comes to implementation of the new accounting standards for insurers.
As the deadline for IFRS 17 looms, global implementation is progressing at varying paces – with insurers in Europe reporting intermittent challenges, and those in Latin America and only just starting to implement and apply the new accounting standard.
The picture looks very different in Asia, which is leading the way, and in South Africa, insurers are also successfully implementing processes in-house, rather than relying on third parties. With time running short in other regions, however, the challenges experienced by insurers as they implement IFRS 17 are continually evolving.
Perhaps unsurprisingly, one of the most considerable 'pain points' is around data – and specifically the interpretation of the regulation as it relates to data. As the standard is principle-based, there is no one 'out-of-the box' methodology for carrying out all parts of the calculations.
As Matthieu Soulas, Associate Director Consulting at RNA Analytics, explains: "IFRS 17 is quite unlike the Solvency II Standard Formula, where every calculation was predefined," and companies don't have the option of changing the prescribed formula – other than taking steps to move towards different internal models.
Soulas explains that from the outset, the implementation project always starts with the same questions: Do you have a methodology requirement document? Or, do you know which methodology you want to implement? Do you know how to identify your group? And has the implementation strategy been decided at the board level? Only then, he says, can you start to implement the calculation. At RNA, we have solutions which include generic calculations, and which are common across different markets. Consequently, the only changes necessary are those relating to the methodology point in certain packages, for individual customers.
"If an insurer is working with a 40-year-old contract, they need to find the data from across 40 years, and in this scenario, it would not be possible to collate full records spanning this length of time." This requires considerable time and resources for companies to not only identify which methodology would best fit their IFRS 17 portfolio, but also to source the data availability linked to such requests - and identify the group of insurance contracts - which then links to the implemented formula.
John Bowers, Director of Consulting, EMEA, RNA Analytics, says IFRS 17 has added an "extra level of intensity" as far as data requirements are concerned. "One of the major areas of focus that IFRS 17 brings about is that of an even greater reliance on credible data – and on policy level data in particular – with the need to move to much more granular calculations, which places a much greater emphasis on the quality of the data," he explains.
"For this reason, a lot of companies are having to spend investment time and money on tidying up their data – both the actual quality of the data and also the means of obtaining those data extracts."
"With IFRS 17, there will be two or three weeks to do all the calculations and produce the report, whereas Solvency II is closer to a couple of months. Naturally, therefore, there are different requirements for the data, pressures on teams and varying results of readiness can cause disruption to customer projects both immediately and in the long term" Soulas explains. "And, as you might expect, communication can be a compounding factor for many firms. Making sure you've got accurate and effective communication between actuaries and across internal processes is vital to ensure the right information is conveyed at the right time. Not only do all teams need to produce and manage all types of data (actuarial, finance, accounting) but they must also realise the impact one has on another. Also, if one team produces incorrect results, the final result is impacted. I'd go as far as saying this is one of the biggest pain points customers need to manage today."
On the plus side, companies that have already implemented Solvency II have found themselves in a much more advantageous position when it comes to IFRS 17. As Bowers puts it: "Businesses that have implemented Solvency II already, have found themselves much better placed to implement IFRS 17 – both from the actuarial model and infrastructure perspectives, and having generally more robust processes in place for solvency to assist them with IFRS 17.
"I think one of the greatest challenges with IFRS 17 for companies that have not already undertaken Solvency II or a similar variant is the need to calculate realistic liabilities. The best estimate liability calculations, which are safe from an actuarial perspective, can be a large shift if they've only previously been carrying out deterministic modelling, and they now need to move to stochastic.
"Insurers that have already completed Solvency II will see a huge overlap in terms of the best estimate liability calculations that are required for IFRS 17, especially from a model code perspective. There may be some assumptions – maybe slightly different yield curve definitions – that may necessitate separate runs of those models, but ultimately, very little actual development work on the model code would generally be expected for companies that have already done Solvency II, and that's a big win."
That said, there's no getting away from the need to implement IFRS 17 calculations, regardless of whether or not a company has implemented Solvency II, or not. For Soulas, one of the main links between Solvency II and IFRS 17 lies in risk adjustment, as one of the possible methodologies for calculating risk adjustment under IFRS 17 is to leverage the risk margin calculation from Solvency II. "The best estimate is also a link; however this relates more to the company cashflow models than it does to the actual regulatory constraint," he explains. But there are some differences between the two.
"What I've seen through my work with clients is that most have been looking at using the Solvency II methodology, because it's faster for them to take the risk margin and calculate the factors between Solvency II to IFRS 17. The basis of both calculations is an insurer's cash flow modelling, as my colleague John explains previously, which is somewhat independent of Solvency II and IFRS 17 because regardless of Solvency II or IFRS 17, insurers need that cash flow model as it forms the basis for the valuation of their products and portfolio".
"From my experience, insurers have not really been focusing on cost saving, but rather on getting IFRS 17 done, and done right. Once IFRS 17 is in place, then companies may start looking at cost saving by reducing the number of individual software systems in place to run such calculations. At RNA, for instance, our Software Suite platform comprises the ability to measure Life, Nonlife, Solvency II, IFRS 17, and so on. Next, they may start looking for more granular figures within said calculations, gathering lessons learned, and improving the process. Right now, though, with ongoing operational pressures relating to the pandemic, and with the implementation deadline approaching, the focus is on getting the job done."
A combination of approaches
As has been widely reported, many re/insurers are using a combination of the Building Block Approach (BBA), Premium Allocation Approach (PAA) and Variable Fee Approach (VFA) across their portfolios, which is a challenge without the use of software designed specifically for the task.
Whilst IFRS 17 calculations are not overly complicated to carry out in terms of the form that builds up the calculation, the real complexity comes from the need to do those calculations in a robust way and using an auditable process – as well as doing those calculations again, separately, by the individual reporting cohorts and the reliance on lots of different input sources (including actuarial feeds, accounting feeds and historical data feeds).
"I would say that the IFRS 17 process is 'subtly complex', and when you start factoring in BBA and VFA, obviously there is a great deal of overlap, and there are quite notable differences between those methodologies. If you're doing that internally, on an internal system or not a dedicated tool, then making that fully auditable as well as fully traceable, is going to be a considerable challenge," Bowers explains.
"There are considerable differences between the PAA and the other two methods. So, again, making that process auditable and transparent, as well as being robust and reliable, is going to be somewhat of a struggle for companies that do try to attempt the task without the use of specialist software that has been specifically designed for these purposes. I think what it really comes down to is the amount of different data inputs and the volume of data outputs that are going to be created in terms of managing that 'in and out' through an efficient calculation kernel that sits in the middle – and one that's at the same time auditable, traceable and reliable."
With the deadline for implementation looming, are all approaches still viable?
"From a systems selection perspective, for a company looking to go down the road of internal or bespoke software development, if they're not very well advanced in those projects already, then timescale is going to be a major issue," Bowers warns. "I might even say that the window for doing bespoke software development is probably past, and that companies in that position should really be looking for an off-the-shelf solution. But within the solutions themselves, there is still time to implement either the BBA, VFA or PAA models at this stage.
"Possibly if we extend it to consider transition, and the different methods of transition, then it's probably worth considering that transition models have varying dependencies on past data availability and quality.
"For transition design there is potentially a closing window when it comes to the full retrospective approach – and potentially even the modified retrospective approach. For companies that haven't yet given this considerable thought, they're probably looking at fair value transition routes, which would probably be the quickest to implement. Obviously, it's not ideal to be choosing methods based on deadlines, and ideally, companies want to do what's most appropriate for the business."
Identifying and dealing with onerous contracts
The topic of onerous contracts has been identified as one of the more challenging areas when it comes to the implementation of seamless end-to-end design for IFRS 17.
The regulation itself sounds very simple and clear, but the nuances of the third category in particular (where a contract may be onerous) immediately throws up questions around interpretation, in terms of the way an insurer decides to define a contract that may be onerous.
"It will be interesting to see how similar those definitions turn out to be in practice across the markets," Bowers says. "As a software provider we are sometimes asked why we haven't got a completely off-the-shelf solution for this, and the honest answer to that is because it's not something that we as a software provider can dictate through our library code."
Bowers says that whether or not a contract is deemed onerous is simple in terms of looking at the best estimate liability and perhaps also the risk adjustment at inception. If it is the case that a contract may be onerous, an additional cash flow model run may be needed – perhaps on slightly less than best estimate assumptions – to provide some margin of whether it is still going to be profitable or not.
"But then by implementing that in an overall end-to-end process, you've immediately introduced two versions of your cash flow model, so you've got two different sets of cash flow model results to then consider, or to compare and combine, at policy level ideally, to work out whether each individual policy is going to be labelled as onerous, potentially onerous or not onerous. All of this must take place before you feed in the calculations for the next stage of the process, which is the IFRS 17 calculations – both the initial recognition and then subsequent measure reporting runs as well. So, the technical challenge is really about managing or creating an end-to-end design that best fits the overall running and management of those models," he explains.
For some companies the cashflow model may be very simple and reasonably quick to run, so adding in a rerun of that model is not considered to be a huge issue. For the larger, stochastic models, running those once on best estimate and again on a slightly less than best estimate assumption, adds up to quite significant computational execution time.
"While that's easier now in the cloud, and with distributed computing than it would have been a few years ago, it's still a significant consideration because all these definitions ought to be done at a policy level, and if you've got a large product block and stochastic models, it's a huge output data file you have to then manage and to use to work out how best to do what is ultimately a relatively simple calculation of seeing whether the discounted cash flow in your best estimate liability is positive or negative under those different things," Bowers explains.
"But first you have got to average the stochastic scenarios and then compare overall individual results to then come up with these flags for the onerous type. When it comes to the kind of system that is best placed to do that, and how to best implement that within the different stage of running of the IFRS models,
the cash flow models and the IFRS 17 calculations, I don't think there is any one-size-fits-all. Each client is going to have a slightly different optimal design for that. We have been able to support different clients with this in different ways."
RNA Analytics has enjoyed continued development, market and customer growth during the past 18 months, assisting customers throughout the disruption caused by Covid-19, the global IFRS 17 implementation, and the accelerated development of digital transformation within the insurance and risk management sectors.
To learn more about RNA Analytics' consultancy products, IFRS 17 technical services and actuarial solutions, visit www.rnaanalytics.com or follow the company on social media @RNAAnalytics.
Channels:IFRS 17
