Questions answered by the experts:

2:47 – Can you leverage pre-defined calculation rules to comply with IFRS17, or do they need to be tailored to the specific requirements of each insurer?
5:15 – We have a specific set of reporting requirements that impacted the implementation of our IFRS17 solution. How can we avoid discrepancies at the end of the project?
7:32 – What are some of the challenges around Data-sourcing?
11:33 – We only have one or two products under GMM. What is the best way to prioritise aspects of our project to meet IFRS17? Is this something to worry about?
13:45 – What are examples of controls over data governance?
18:21 – What are some of the other challenges of project delivery?
21:41 – How do we align our project during busier periods, such as end-of-year reporting, where we as the client might be less available?
25:10 – Testing has been more difficult for us than we thought. Why is testing during IFRS17 projects so much harder?

Transcription of the session:

Nicolas:
Good morning, good afternoon and good evening to everyone. I’m pleased to welcome you to this month’s Meet the Experts live event. I’m joined today by Tommy Grantley, our Technical Business Analyst at Legerity to discuss IFRS17 implementation. Hi, Tommy, how are you doing today?

Tommy:
Hi, Nicolas. Yeah, really happy to be here excited for the live stream this morning

Nicolas:
Yeah, definitely, it’s going to be a good one. And we are going to focus on IFRS17 project deliveries. We’ve received actually a number of questions around the subject in the past few months during our webinars, and also some questions via email. So, as a reminder, you can ask all your questions here live in the comments section, or you can drop us an email at info@legerityfinancials.com. We will do our very best to answer all your question during the event. But if we cannot, we’ll make sure to come back to you after via email or via phone call. So let’s start. So I have the first question I received in a past webinar, and it’s about leveraging pre-defined calculations. So here’s the question. Can you leverage pre-defined calculation rules to comply with IFRS17? Or do they need to be tailored to the specific requirements of each insurer?

Tommy:
Yeah that’s a really interesting question, Nicolas. So I suppose with IFRS17, you know, it requires some quite complex calculations, some are quite simple, of course, but there are some complex calculations and these calculations can be based on a variety of inputs. So some of those inputs might be, you know, mapped from various source systems, some might be you know, other calculated values need to be calculated in the solution you’re using for IFRS17. So we’re talking things here you know, things like interest calculations, maybe the release of CSM, maybe experience in the future service adjustments, even sort of the acquisition cost amortisation or revenue recognition in each period, each reporting period. And sometimes even things like the testing of contracts to test that they’re onerous, and even allocation of expenses down to a group level, all these things need to be sort of captured by a solution. And yes, you know, leveraging sort of pre-defined calculation rules can be key to sort of having success in that.There might be a number of reasons you want to do this. So firstly, the really important thing is to ensure compliance. So having these pre-defined rules allow you to ensure that those are going to be compliant with the standard itself. And the other thing that we notice in the projects that we work on is that it kind of puts the client focus on the data rather than a calculation. So having a solution and having a team of people that you’re working with who have already put a lot of thought into those calculations and present to you the data that’s required for those calculations. It really sort of helps enable our customers to meet the calculations they need. So for example, with FastPost Express we’ve worked over the last few years in our IFRS17 projects to define and sort of fine tune our solution to make sure that all the necessary calculations are now IFRS17 compliant, and we fully integrate all of that with the data requirements that we give to the clients as well as you know, downstream in the solution for our accounting hub and into the reporting there as well, making sure that’s all integrated with those calculations.

Nicolas:
Yeah, no, that’s very good and the, yes, so definitely the power of pre-defined calculations help streamline the project and also achieving therefore, the outcome of ensuring compliance. That actually brings me to, to the next question. We, you know, some people have a specific set of reporting requirements that impacted the implementation of an IFRS17 solution. So the question is, how can we avoid the discrepancy at the end of the project? And how do we ensure the level of detail is meeting the reporting requirements? So, thinking at the beginning about that.

Tommy:
Yeah, and it kind of is about that. So we kind of follow this, what we’re calling, a right to left approach we talk about a lot, and we kind of see this as kind of the really success to implementation. And what we mean by when we say right to left is we mean, thinking about the end the reporting requirements to final, the final, the final product, I suppose, you know, what’s actually being generated from the solution. Because, you know, thinking about that, understanding that is, is going to influence, you know, the decisions that are made for the parts that precede that. So, you know, the accounting that produces the reports, and then the data that feeds the calculations, and that then feeds the accounting, it’s really important to understand the end goal, whilst, you know, before we consider the other parts, and as you say, level of granularity is really important. You know, we see that it’s important to have a solution that provides a framework, which you can make these decisions in. But the level of granularity, of course, can vary from project to project. So it’s really important to understand that as early on as possible. And that, you know, that’s kind of key to really having a successful project.

Nicolas:
Definitely, definitely, and I think the right to left approach is something which we discuss with every one of our customers. And when we look at the first projects that were happening a few years back, people were first starting with the data and IFRS was really seen as a data project. Now, they understand that it’s the reporting and disclosure, and actually thinking about that first enables you to narrow down the only data you require. Yeah, that’s very good thank you, some very good insight. Now, you know, we touched a little bit on the reporting, we say that, how important is the data? So it’s bringing me to the next question that we received, and it’s what are some of the challenges around data sourcing?

Tommy:
Interesting, I suppose I suppose, from our experience, actually, data is one of the biggest challenges that we see, you know, we try and make that as easy as possible, but, you know, defining clear definitions and, and being very transparent about what data is required to meet our solution. But we, we do see that this is a particularly challenging point that for many of our customers, mainly, we see things like missing, incorrect or incomplete data. So obviously, you know, the thing with IFRS is that the data has to come from a variety of sources, maybe sort of actuarial systems, or policy, governance systems, whatever it could be. And this can often lead to there being some data that is hard to source or has to come from different places, right. So we try and mitigate against that in various ways. You know, firstly, we try and make data an early focus, you know, much as we said, we do with the reporting, we also try and make data an early focus, we always try and have people in the project, both from our side, and on the customer side, you know, some kind of experienced resource that really understands, you know, data and what is what is required. It’s important to, you know, develop a sort of comprehensive delivery plan as well, which really takes into account the time that’s necessary to source data, and to understand the requirements of the solution that you’re using. And, and finally, you know, you really want to identify any gaps or issues as early on as possible in a project, you don’t really want to be left with those later on in the project where they could manifest themselves in more challenging ways. So identifying those issues as early as possible, understanding, you know, the roadmap to mitigate against those issues. And then as you move forward with the project, you’re much more likely to have I think, success. And then finally, I suppose the other thing we see, I suppose maybe poor data quality. Often we see sometimes customers using kind of a centralised data store before, you know earlier on in the in the upstream from FastPost. This isn’t always necessary. But again, yeah, what we’re really talking about here is thinking and planning for data as early on in a project as possible to mitigate against any potential issues later on.

Nicolas:
Yeah. Thanks. Any specific data that is particularly challenging?

Tommy:
Yeah, that’s a good question. I think, I think there’s some data it’s obvious where it comes from. You know, the actuarial projections, for example, you know, the discounted data that’s going to come from your, from your actuarial systems and your information about grouping contracts and policy expecting the policy and the systems. The kind of main change we see sometimes is with kind of granularity, especially when it comes to things like expenses. So, under IFRS17, you have to measure your liability under certain measurement models, per sort of group of insurance contracts and sometimes its quite difficult to take an aggregate expense like your rent, or your, you know, some something else, any other type of standard expense, and break that down so that it can be applied to the individual groups of insurance contracts. So within FastPost, we kind of have like a built in allocations tool, which I’m sure you’re aware of which we can use to break down those in aggregate expenses into more sort of granular, discrete parts that can then be associated with each of the group insurance contracts, so that the liability can be sort of measured correctly. So that’s one example of what we see quite often.

Nicolas:
Okay, yeah, no, very good. Very good. And yeah, definitely granularity is key. And we spoke about it before, spoke about it here. It’s a key component of IFRS17. So understand why it can be challenging for some people. Now, that question actually, from a number of conversations that I had with with some prospects that were asking me, we only have a little bit of GMM were mostly PAA, that’s mostly for general insurance, and what is the best way to prioritise our project to meet IFRS17? Is that something to worry about? Or how can we approach a minimum GMM requirement?

Tommy:
Interesting, yeah. So I suppose we, you know, we see often that various customers have different requirements when it comes to
measurement models, some are really focused on GMM, some really focus on PAA, some might make sure it’s through VFA as well. Generally, PAA is kind of a sort of a simpler model to implement because the complexity is a little less in terms of the components, you need to actually build up the solution, it’s a little bit less. So it can be delivered in a sort of slightly more, I suppose quicker way. So usually, we you know, in our project, we like to start with PAA. And as I said, it’s a little bit simpler. And also it gives the opportunity for the team, in the IFRS17 team, from the client and also from our side to familiarise themselves with each other, the process they need to go through, familiarise themselves with the solution as well. And then when it comes on to GMM, of course, there’s a question of materiality. And whether PAA can be applied to certain scenarios, obviously that’s a question really, for the auditors and not usually, for us. But what is a question for us, and what is important is that we can provide the actual framework to support other measurement models, if needed, even if that isn’t the initial focus of the project, you know, having a solution like FastPost Express, which can be used across multiple models, providing a framework to deal with GMM even if it is for a small amount of products, that’s really important. So you’ve got that flexibility if you need it going forward.

Nicolas:
Yeah. Great, great. Thanks. And actually, we received a question from Asna and not sure if this is your area of expertise, but what are some examples of controls of a data governance?

Tommy:
What are examples of controls over data governance? Yeah, good question. So, as I spoke, I think that from our experience, and you know, the thing is with data it has to be very clearly defined, right. So defining the data, firstly, initially in the project is really important. So as I said, previously, you know, we try to, we have our sort of data structures, we know about in FastPost, we define them very clearly. And then having some kind of change management progress to governance process over that is obviously is obviously key. So, you know, early on the project, we engage sort of senior people from across IT and Finance, we want to be very clear what’s required for our solution, understand what they can provide from their various teams and then going forward in projects any changes that need to happen should be controlled you know, quite strictly and any changes the requirements from our side any movement in what can be provided, etc. throughout the projects, you know, we want to make sure that’s very tightly controlled. And anything that’s suppose you know, inside or outside the scope is very clearly flagged, etc. So that we know exactly what, you know, at all points of the project, whatever topic we’re dealing with if its a measurement model or if it’s a certain area within IFRS17, it’s important to know exactly what is going to change and when.

Nicolas:
Yeah, I think, also maybe one aspect of the control, which is it’s a key requirement when, when discussing the data integration is actually  how you’re going to provide the data and what’s the, what’s the integration with the differential systems, because some people will provide the data via their data warehouse, and they will have a strong ETL solution that allows this governance, and some people would provide it via a CSV file, where they just bring all the data together, they restructure themselves some of the data and then, you know, there is a requirement of the data governance, which needs to be discussed in a deeper discussion, also, but we have our data manager that’s helps actually making sure that testing all the data, when it’s received, do you have anything on the under Data Manager maybe?

Tommy:
Yeah, so we within FastPost we obviously have we want to make sure the data is good quality to kind of mitigate against those things we discussed earlier, missing data, incomplete data, etc. So, you know, we often we obviously sort of test the data before or as it comes into the solution. So as you said, we’ve got our sort of Data Manager tool, which is the first component really in our architecture. And that focus is really on validating the data to make sure that you know, anything, any data that’s required is, is present. And also that any and all the data is in the sort of right format. So if it’s a date, it’s going to be a date, if it’s, if it’s a ratio, has it got the correct number of decimal places, if it’s a provided, you know, monetary amount transaction amount, does it need to be rounded to the correct decimal places of the currency. So these kinds of things, we need to do checks for as the data flows into FastPost so that we don’t have any issues later in the process. And when that happens, and if there are any sort of outliers or issues, then we you know, we have a kind of an error management tool, really, I suppose that sits in the application as well, which will report back any issues to the, to the upstream systems or to the end user to alert them to any issues, so they can go in and manage any changes that needs to happen. And often, as we go through sort of testing phases, with customers, it brings out any any potential issues with the, with the data quality, quite early on. And one of the things we say is that we should always try and use real data as soon as possible. So early in the project, of course, using mocked up data can be valid for the testing, but we will we want to always encourage our customers to try and use real data that they have sourced from their systems as early on as possible, and then you know, that always brings out any potential issues that we can work around.

Nicolas:
But at the same time, we can always use our own data, or we have like some sample data that we can use in order to progress with a project because we understand that data is something difficult to provide.

Tommy:
Yeah, sure.

Nicolas:
Actually, that’s a, that’s maybe a good switch to the next question, which is a very general one, which is, what are some of the other challenges of project delivery?

Tommy:
Yeah, interesting. Big question. I suppose that there’s you know, there’s different there are different areas, different challenges, we’ve discussed data. From kind of the actual, you know, the way the projects are structured, obviously, scope is very important. So it’s very important to really, you know, comprehensively define the scope, at the project initiation and get this confirmed, you know, by sort of the senior people, might be the steering committee within the customer’s organisation as early as possible, you know, have that as an early milestone. Yeah, really clearly defined a scope where the remit of the project sits within the entire IFRS17 transformation place. And if that’s part of a bigger financial transformation, where that where we can sit within that scope as well. You know, it’s very, it’s quite easy for us because in our in our sort of pre-configured solution, we have all the various elements that’s needed for IFRS17 compliance, and we can build up those parts as necessary. So if we know that we need GMM or PAA or we need GMM and reinsurance. You know, or we need GMM and we need some FX because there’s multiple currencies and these kind of things, we kind of have the building blocks. And, you know, for us, it’s easier to kind of put the menu together, I suppose, and the things we might need for the project. And once you’ve got that scope, then, you know, that allows for a much more efficient project. Obviously, there has to be some room for a bit of flexibility within that as well. Otherwise, you know, you’re not working in a very agile manner. You need to have some flexibility within that and obviously change processes scope can change, but I mean, that initially defined is obviously really important. And then I suppose sort of thinking about kind of planning, you know, the execution of your project plan, you know, making sure that your sort of your delivery plan is comprehensive and realistic in terms of the timeframes. And as I said, you know, keeping agile in mind, so, you know, organising it to have some flexibility, because, you know, with IFRS17, it is a complex standard, and there’s bound to be sort of twists and turns in the road. You know, making sure that you’ve got kind of the adequate resources in your, in your teams. And the final thing, we probably see quite a lot as a challenges is maybe this sort of testing of IFRS17. So, you know, as I said, IFRS17 can be quite complex, and therefore testing it is then also complex. And it’s important to have a kind of a comprehensive, I suppose, approach to testing. Early agreement and buy-in from the from the, from the end users and from the people on the flight side, who are going to be testing the solution. And that also comes through from the scope, from the scope and execution, if you have a clearly defined scope, and you’ve got a good plan, then testing then falls out of that because you know exactly what you’re testing, you know, when you’re testing, you’ve got the right people to do the testing. So it kind of comes together under really what we’ve just mentioned.

Nicolas:
Yeah. And definitely testing has been something very often overlooked. And people had a few surprises. But yeah, we can guide our customers through you how to approach the testing phase in the most efficient way. Now, I have a have a question actually, for you. Because we’re getting closer to a very busy period with the end of year reporting. How do we align projects during those busier periods, such as end of year reporting where clients might be less available?

Tommy:
Well, I suppose yeah, the the, as I said in the previous question, having a really good plan will be key to this. So first of all, understanding what key stakeholders are going to be busy and when, both on the client side and the different teams. They might have IT, Finance, Actuarial, Accounting teams, understanding when they’re going to be busy, obviously, we’re in January now so people that are running, who have run sort of a December to December financial year, those customers are quite busy at the moment doing their year end. So it’s something that we’re very aware of, and something that we know, we deal with, you know, these busy periods are inevitable. What I would say is that you can try and use them to your advantage, understanding what teams are busy when and planning well means that sometimes, I don’t want to call them lulls, but you know, sometimes when having a time when things are a little bit quieter from one team allows you to put more focus elsewhere, where you couldn’t before. So if you know that, you know, we need to do some testing on our side, or the maybe the finance or IT teams need to have a little think, you know, or a little plan for something specific that’ll come up in the project. Using those, you know, using times where one team might be busier, allows us to put a little bit more attention elsewhere, where previously, we wouldn’t have been able to so trying to use them to your advantage I’d say.

Nicolas:
Yeah, and I think you spoke about some examples, like testing, but when we were speaking before about data, and there is a difference between the IT and the Finance department. The Finance department, will be very much busy doing the end of year reporting but do you find it easy, therefore, to work and to switch therefore your focus to discuss these topics such as data with the IT department? Do you find that’s something that’s achievable?

Tommy:
Yeah, that data is the one where it really does intersect between the sort of Finance and IT teams. Finance teams will understand sort of, you know, functionally, what data needs to be provided. And, you know, they’ll have some knowledge of the systems that do that, but the actual process of mapping that data through and the kind of technical challenges that presents and also the, you know, I suppose the infrastructure side of things that obviously comes under the IT remit. So, you know, we’re obviously comfortable with working with those teams. And we and, you know, we try to have very regular meetings with with all the key stakeholders, including those teams, and when there’s questions from either team we can kind of, you know, sometimes operate as maybe as a middleman if we think there’s something that we need to refer back to their own IT teams etc, we can really be part of that kind of, you know, flexible process where we, you know, have a really good engagement with all the relevant people.

Nicolas:
Yeah, yeah. Thanks. Thank you very much, Tommy. I think that the last question that we received, was part of like, I think it’s following the Question not the last one, the one before, it was about testing. And as, as we said, testing is something to think about. And here, they were saying, testing has been more difficult for us than we thought, why is testing during IFRS17 projects so much harder?

Tommy:
You know, we did, we did touch on this, but the underlying reason really is because IFRS17 has complexity. And that doesn’t mean it can’t be tested, but of course, that presents some challenges which need to be overcome. So I suppose the main challenge of IFRS17 is that there’s lots of different components that are related to each other. So usually, in testing, that unit testing, you try to sort of testing to discrete units, and then build those up, etc. It’s a little bit more difficult for IFRS17. Because there is a lot of relationships between the different components. From a FastPost perspective, we use the term ‘business events’ and business events are sort of anything that happens that need some kind of accounting treatment. So you know, a new group of insurance contracts is incepted, and the cash flows are received or interest on a group or something or anything like that. And what we see is that these, these sort of groups of events need to be tested together to really make a suppose give an answer, that gives some kind of meaningful results. So you know, testing is difficult, but breaking first, breaking it down, and then breaking it down and grouping up sounds like a bit of a conflict, but what you really need to do is look at it in some fashion where you can break things down. But don’t look at things in complete isolation, because otherwise your results won’t be terribly meaningful. And the other challenge we see is that it can be difficult sometimes to kind of model or generate expected results, which you can test upon. Because, you know, there’s a reason that people you know, customers need IFRS17 solutions. That’s because, you know, there is, it is difficult sometimes to do this kind of stuff. You know, it’d be based on some kind of model. But again, as I said before, by breaking things down into more reasonable sized chunks, then you can sometimes then generate results for that, and then that, that whole process becomes a little bit simpler. So yeah, we do see it’s difficult and challenging, but that doesn’t mean it’s impossible. And we, you know, we have good, you know, a good process that we’ve developed over the last, you know, last few years of doing these projects that, you know, definitely works and has allowed us to, you know, have some really successful projects.

Nicolas:
Yeah. And I think I think what you just said, is quite true. One of the one of the reasons why we still say to people, even if they’re suddenly one year until compliance, that is still a good time to start an IFRS17 project is because you can do an implementation within six months, that’s achievable. We even did an implementation within three months. But the value of coming now is that you have a number of companies that have been through a full implementation have been through the testing phases that have identified those challenges. And so we can use all this experience now in order to accelerate the implementation. I think  the risk of failure with a solution such as FastPost is very, very limited. Actually, we didn’t miss any projects. And that’s something we’re quite proud of. I think it’s by using those experiences and bringing it now to each implementation and always learning. Yeah, thanks Tommy. I think that brings us to the end of todays Meet the Experts session. So I just want to say a big thank you for all your insights. And maybe do you have any concluding thoughts or views that you want to share with the audience?

Tommy:
Well yeah I just want to thank you everyone. It’s been a pleasure to take part and enjoy the rest of your day.

Nicolas:
Great, thanks. So just now to finish a quick word about Legerity. As many of you know, at Legerity we developed an award winning FastPost expert IFRS17 solution based on three principles; entreprise-grade functionalities, out of the box configuration, and fast-tracked implementation. Legerity FastPost has been recognised by InsuranceERM as the leading solution for IFRS17 compliance in 2021. And we believe that tackling IFRS17 in the right way, will help you streamline and de risk your project, as well as delivering transformational benefit that will go far beyond IFRS17, which is key because it’s a trigger for finance transformation. So if you’re interested in hearing more about Legerity FastPost Express for IFRS17, you can contact us on our website to arrange a call with one of our experts – somebody like Tommy, Mark Miller, or any of our staff to really discuss your own project. We also invite you to follow us on LinkedIn to receive notifications for future events, webinars, as well as any other IFRS17 or finance transformation related material. On this note, I just want to thank you all for attending today’s event and have a great rest of the week. Thank you.