Why is IFRS 17 Insurance Contracts so difficult?

[Music] Hello everyone and welcome to EWY's IFRS 17 podcast series. A series that brings you the news and views on IFRS 17, the new international accounting standard on insurance contracts. My name is Brendan Council, I'm an actuarial partner based in Sydney. I'm currently working with a number of national and multinational clients on IFRS 17 implementation projects. Throughout this podcast series we'll be asking a number of our global insurance professionals to discuss key topics and interpretive issues in IFRS 17 and to consider the implementation approaches and challenges the new standard presents. [Music] Implementing IFRS 17 with EWY. The podcast series aiming to help you understand the possible technical and operational issues of the new international accounting standard of insurance contracts. In this podcast we will discuss why IFRS 17 is proving so difficult to implement. Joining me is Alex Abirli, a senior manager in our actuarial team who has worked across APAC on IFRS 17 implementation projects. Hello Alex and welcome. Thanks Brendan. Alex, I think we all agree that the IFRS 17 standard is a complex accounting standard. There are various challenges that arise when an entity implements IFRS 17. Maybe can you outline the key challenges that are creating additional risks to implementation programs and causing them to take longer than expected? Of course, I've seen three key challenges emerge which have increased the delivery risk of IFRS 17 implementation programs. I think firstly IFRS 17 requires companies to use interpretation and judgment to apply its principles to their circumstances. Secondly, IFRS 17 is more than accounting change. It requires greater interaction between the actuarial and finance functions and is challenging the financial reporting operating model. Third and most importantly, insurance companies identify that their data quality and systems are not fit for purpose for IFRS 17. I'm actually finding that companies recognise these challenges but because IFRS 17 is new, strong project management discipline and experienced subject matter experts with real implementation experience are needed to efficiently navigate APAR through. Thanks Alex, that's a good summary. So maybe let me start with your first observation. IFRS 17 is a principle based accounting standard. So companies will need to interpret and apply the standard to their facts and circumstances, right? Maybe to bring this to life, Alex, can you give me an example? Sure, Brendan. One area of concern raised by many stakeholders was the treatment of the third acquisition costs on the IFRS 17, for instance. At the time we are recording this podcast, the ISP board have discussed this topic but have only expressed a tentative decision. However, at the same time, the ISP staff noted that the final wording in the upcoming amended IFRS 17 standard might still slightly change, right? So there are markets like Australia or the UK, where this topic is a big one and hence the residual implementation on certainty that may impact accounting treatment and system design until the final wording is known. This is one of many examples and where we see it becomes a problem is if programs stop until such uncertainties are 100% resolved. So this is a classic program management decision where in the interest of moving forward, you may trade off perfection in the short term. I would actually argue that you should land on an informed interpretation acknowledging and documenting the risk of later changes. This allows the program to progress while recognizing you will need to revisit the interpretation as industry practice develops. Thanks, Alex. So maybe on your second observation that IFRS 17 is more than just an accounting change, I've heard that a few times. What do you actually mean by that? It's a good question, Brandon. I mean IFRS 17 has impacts across organizations. It introduces new financial reporting metrics, it also introduces new KPIs and potentially changes to short and long-term management incentives. In particular, the measurement and disclosure requirements of IFRS 17 will have significant implications for the financial reporting operating model. So what type of implications and how are our clients responding to those, Alex? Well, Brandon, let me give you some context. IFRS 17's role forward mechanism disclosures mean that if there are reconciliation differences at an insurance group level between say you're general ledger, the cash flows and actual evaluation, you won't simply be able to produce financial statements that balance and are internally consistent. Many of our clients recognize that this requires greater collaboration between the accounting and actual functions than historically has happened. They've been determined that the legacy approach with limited alignment and interaction is not suitable under IFRS 17, so are challenging their operating model as a consequence. Yeah, so I agree. And I'd probably add that clients we've seen who are the most inspired and motivated are those where we have helped them reimagine their financial and actual operating model to make it more dynamic and future-proof. So let me ask you about the third and most important challenge you mentioned, Alex, data and systems. Oh yes, absolutely, Brandon. The data and system challenge really highlights why IFRS 17 is so difficult to implement in my view. This is the challenge that is the most likely to have surprises once you move into the detail leading to a rebalancing of efforts toward addressing data and system gaps. Okay, so Alex, clients who are only in the early parts of their implementation program may not understand why this is the case. Don't companies already have the data somewhere? You're a correct, Brandon, but the reality is that until you perform a detailed analysis, you won't have answered the following questions. One question is, is all the data captured in your source systems and referable to individual contracts or groups? Premium cash flows is a nice example of where we often find it isn't referable and this becomes a problem. Then the other question is, even if the data is there, can you actually easily extract it from all your legacy systems or is some additional build required? Another question that you will ask is, where will your group and store the data from period to period actually? Another one is, is the data good quality and consistent with your actual cash flow transactions and general ledger? And the last one I would like to mention is, if you currently use manual adjustments to resolve data quality issues, is that sustainable on the IFRS 17? I could keep going, but hopefully these questions show that the devil really is in the detail. As a result, we are seeing more progressed implementation programs actually reallocating a substantial amount of their IFRS 17 budget and resources to their data and system work stream. I personally strongly recommend analyzing the data requirements and gaps early in your program, so you understand the challenges that you're actually facing. This also gives you the information you stakeholders need, so they can appreciate the data and system issues the program needs to solve. Okay, Alex, so perhaps for further context, can you explain why IFRS 17 presents such a different challenge to current valuation approaches? So I know that actually is adept at addressing these types of data challenges already, surely under their current valuation approaches. Sure, Brandon, happy to expand a bit here. The calculations introduced by the IFRS 17 standard are both complex and demanding in terms of both the quantity and granularity of the data required. Now, mapping and maintaining contract data in the new groupings of IFRS 17 is proving to be difficult without significant changes to the source product systems. That's one thing. But additionally, as I've already mentioned before, it's not just about having access to this very granular data. It's also about the quality of the underlying data. If your data quality is poor, then even very sophisticated IFRS 17 calculation and posting engines will not be able to create a meaningful set of financial statements. A successful IFRS 17 implementation requires you to understand the end-to-end flow of decisions and interreprensions. In summary, I would say, your IFRS 17 accounting policy decisions will drive your measurement methodology, which requires you to source specific accounting entries, expected cash flows and also contract data. You then need to group at a certain level, which you then use to produce a roll forward reconciliation across the different components of the liability. You need to ensure this is internally consistent across all the insurance contract groups and aggregate to produce your external financial statements. This is a complex series of interdependencies, which will require excellent data quality and controls to be successful, Brendan. Yeah, that makes sense, Alex. So, let's focus on the contract data then, which seems to be the heart of the challenge. What sort of data do I need and where would I find it? That is a very good question, Brendan. Let me first say that data is proving such a significant issue that many clients stand up a program workstream dedicated to data identification, sourcing, extraction and transformation, actually. The obvious starting point is to identify all source systems that contain critical data fields required to be done. to measure an insurance or re-insurance contract on the RIFR-17. Such soul systems are often policy administration systems, for instance, claims handling systems, but from a re-insurance perspective, obviously re-insurance systems, you have to look into investment systems, et cetera. So once you have identified the soul systems and actual data fields, such as premiums received, claims paid, expenses paid, and I could name others, you still need to be able to source and extract all the data fields. Often, you also need to convert some of the data fields for further processing, because they are not machine readable, such as male and female, that the odd or often mapped to one and zero. A similar approach applies to what I call expected data, which is often created by actual projection models today. Importantly, the actual and expected data needs to be collated and processed together, so that the income statement and the role forward analysis hangs together as well. This is very different to how we view and process actual and expected transactions today, where they are very much maintained in separate systems. Yeah, now like we know, sourcing and extracting data from decades old legacy systems isn't straightforward, right? That is totally right, Brandon, and the effort involved shouldn't be underestimated at all. So now we have the data. Let's put the question aside, where you would store all these actual and expected data for now, and just assume that you have created a standardized flat file or flat files in many cases for just one product. You now must get this file into an IFRS 17 calculation model, which might be internally developed, however many clients are buying a sub-ledger solution to provide this calculation. For that, you often need to use extract transfer load or ETL processes as we call it. And I can tell you, do not underestimate the ETL work required to make everything work between source systems and IFRS 17 sub-ledges. Yeah, good, Alex. So assume that we've bought an IFRS 17 sub-ledger. Does this solve all our problems then? That's a good question, and you're not the only one asking it. Sub-ledges certainly can provide an IFRS 17 compliant solution. However, to be very clear here, significant effort is still required to configure these solutions to your specific products and accounting policies and interpretations. In particular, a tight data lineage within an IFRS 17 sub-ledger is essential. That is, where the data originates, what happens to it and where it moves over time. There are so many instances where things can and certainly will go wrong, but the exact scenarios are obviously very dependent on the source data provided. So a well-designed data lineage will increase transparency and greatly simplifies the ability to trace errors back to the root cause, really. You will need to map the outputs to your general ledger at whatever level of detail is desired, considering management information, KIPIs and so on. All of these present data issues and some strategic decisions for the business. Yeah, interesting. So Alex, given the amount of change, do you see insurers using IFRS 17 as a catalyst for change to address issues they always wanted to fix, such as building a data warehouse or cleaning up their IT landscape, for example? Good question, Brandon, and I absolutely do. I mean, once insurers realize the real effort required to achieve just minimal compliance, really, they start to ask how they can get extra value out of the money spent. So for example, set up an IFRS 17 data work stream that aims to design, build and implement a whole new data warehouse, or as we call it as well, a single source of truth within the existing IT landscape. I think that's a great example we see actually happening. There are other systems and application initiatives that insurers may want to address on the back of IFRS 17. So examples I've seen in the past few years include upgrading the policy administration systems, upgrading or even replacing claim systems, executing new general ledger strategies, upgrading or changing actual systems, introducing new consolidated systems to name a few. But Brandon, you see it's a broad range of initiatives. And almost all direct insurance with significant reinsurance are improving their reinsurance data and storage, by the way, as well. Yeah, so Alex, you mentioned earlier the significant configuration work required to implement sub-ledger solutions. Some people believe that the out-of-the-box solution will be plug and play. Can you explain what configuration is actually required? Yes, Brandon, absolutely. There is in my view no out-of-the-box solution at the moment because every insurer has different products, different features and different objectives in the program, and the way they wish to present their result. This means that a certain amount of configuration and or even customization is required to meet an insurer's specific needs and its fit for purpose to cater for an insurer's suite of product. From the life examples I've seen so far, there is no one size fits all IFA-17 system solution available in the market really. Whatever IFA-17 solution and insurer chooses, substantial tailoring is normally required at the cost for the insurer, of course. Perhaps surprisingly though, Brandon, it is usually not so much the IFA-17 engine itself that poses the biggest IFA-17 implementation challenge. The larger overall technology change originates from correctly managing the highly complex and interconnected systems landscape and increasing volume of data to be processed. Just to achieve minimal IFA-17 compliance actually. This links back to the earlier discussion, Brandon, that the key challenges the companies are facing are really aligning existing and future data models and managing the data flow between the different systems. The other key challenge, Brandon, I would like to mention that I often observe, is configuring the new accounting rules engine and subsequently achieving the right external and internal reporting requirements. From an overall existing IT infrastructure perspective, it is easy to see the importance of interoperability between all different IT systems when choosing an IFA-17 solution to solve IFA-17 problem. - Yeah, okay, so thinking out loud a little bit here, Alex, and having in mind what we just discussed, why can't insurers just use what they have today and cobble it together then, so to speak, say on existing systems with a few spreadsheets? - I mean, the answer is yes, of course, they could Brandon, that's not a problem. However, from an end to end, IFA-17 solution point of view with specific consideration of auditability, traceability, and speed as well as run-time limitation. This is probably not the best solution to produce a set of IFA-17 compliant financial statements under typically very tight reporting timeframes. - Okay, but if an insurer just wants to get over the minimal compliance line, such an approach could be adopted, right? - Yes, yes, of course, Brandon, I completely agree with you. But the issue to be in mind is that an implementation program with the objective of minimal IFA-17 compliance is still going to be a significant exercise in itself, even if cobbled together, and insurers still needs the same set of actual and expected data. The insurer just processes this dataset in a different, more manual way, and is accepting ongoing additional costs and opposite operational risk associated with it. - Okay, so what are the operational risks associated with choosing an approach that cobbles it together, so to speak? - Well, Brandon, the obvious risk is that you might not be able to meet your tight reporting time frame, simply because you have to perform a lot more calculations and reconciliations manually in an IFA-17 world, as compared to the current reporting process. Let's think about how much time insurers already spend on the current reporting frameworks to investigate and understand irregularities or results that just don't make sense and create issues. Maybe they deal with exceptions with a top-side manual adjustment, and it all gets lost in a couple of line items. On the IFA-17, the role forward disclosures are detailed, right? And will make highly visible any inconsistencies between the different data sources. Any manual adjustments will give you a hard time to fulfill these disclosure requirements in an IFA-17 world. My observation across various markets is that years of under-investment in the finance and especially IT departments have resulted in many manual and entry-porting processes and work around that presumably won't be sustainable in the new IFA-17 world, especially again, with a view on the disclosure requirements that require robust reconciliation. Hence, as an insurer, you are probably better off in having a robust and better controlled end-to-end solution in place, rather than driving everything manually, my view. Thanks, Alex. So there's no doubt about it. It does present once in a generation opportunity for finance and actual systems to invest and improve their data systems and processes. So just to wrap up, Alex, what would be your three key takeaways for insurers as they continue their IFA-17 implementation journey? Sure, thanks, Brandon. I think my three key takeaways would be firstly, adopt the pragmatic and agile approach to interpretation uncertainty, so this does not hold up the progress of your implementation program. Secondly, consider your finance and actual operating model and how it will change on the RIFE-17. And I think the third point I want to mention is establish a specific date and system workstream and assess your data early in your eye for 17 journey. Great, thanks for your time, Alex. This has really provided some insight into why eye for a 17 is so complicated to implement and thank you to everybody for listening. As always, we'd welcome feedback and suggested topics for future eye for a 17 podcast. You can email us at [email protected]. Thanks again for listening.