Case Study: Improving Models & Automating Processes for IFRS 17

Author: Lisa Accos, Hachschara

2023 is the year Israel will have to start reporting the accounting balance sheet under the new accounting standard IFRS 17. This new accounting regulation relies on future cash-flows estimation (while IFRS 4 was a reserve level reporting). This means that this new accounting regulation requires a lot of data from predictive models. While Solvency II was also based on future cash flows, generally only the present values of those cash flows were reported, reducing the amount of data required to extract from the predictive model. 

Our Requirements

Hachshara, like all other Israeli companies, chose to use software for IFRS 17 that would take care of the actualisation of those cash flows. This also meant that we would need to feed several cash flows into the system.  We quickly understood that this new regulation presented not only actuarial and accounting challenges but also data challenges.

The Life and Health department at Hachshara has been using to implement its actuarial model for solvency and other purposes. We have a small life portfolio, so until we had to report under Solvency II, using excel met our requirements. Once again, the level of reporting was actualized values on a risk level, meaning calculating and reporting present values for 12 groups of risks as an average.

In comparison, with IFRS 17 the reporting level is very different; all the cash flows must be provided on at least an accounting group level. The accounting groups include year of production, profitability, and contract boundaries. This combination leads to a huge quantity of groups, that will only grow over the years. Using excel was definitely not an option!

While can easily be used to group data using many different variables, we then needed to work with Software Alliance to understand how to best manage the results that we received at a group level. We wanted to write all of our cash flows directly in SQL, in a very specific format, that would also be easy for our data team to use. Writing to SQL is available as standard functionality with so that part was easy. We just needed to write some bespoke code to merge together the results for the groups so they were present as distinct output groups but within one database table.

Building the Solution

Once an initial solution had been provided, this project took a second direction. IFRS 17 is a quarterly accounting report so compared to Solvency II, which was only semi-annual and has a longer deadline, IFRS calculations will have to be provided faster and more often. As a reminder, for actuarial models IFRS 17 does not require only one “set” of cash flows but several. We then wanted to think of ways to improve our model to run all the sets automatically, in order to reduce possible operational mistakes, and to produce the cash flows faster. Software Alliance provided us with a solution in order to automate our model runs for all sets of cash flows.

As if this was not complicated enough, we also decided to preserve the exact same model for solvency and IFRS calculations. In addition, between all the sensitivities and the ORSA arriving, we also needed to find faster and more automated ways to perform all our runs for solvency purposes. Without touching the actuarial aspect of the model, Software Alliance helped us to develop the appropriate code in the running of the Group Projection task in order to make that possible.  This involved a significant amount of 2-way conversations and collaborative thinking between Hachshara and Software Alliance, but together we were able to improve the model and automation of the of the process.

The final task was to combine both of those solutions; executing automated runs, for either solvency purposes or IFRS projections, and storing the appropriate cash flows in the required way. The solution had to work equally for Analysis of Change runs moving from one date to another changing assumptions/rates/portfolio one at a time, and for solvency runs where we need to carry out runs on several scenarios allowing for the different insurance and market shocks. We also needed to combine these so that we could run an analysis of change for each scenario. Clearly with the volume of runs to be carried out this all had to be automated and then the results and audit information written to an SQL database. Having such a level of automation forced us to ensure those runs were correctly performed, with the correct rates, assumptions, date, shocks and so on. There were a significant number of steps to work out here but after working back and forth with Software Alliance, we finally succeeded in this last part of the project.


All these changes represent a huge improvement for the Hachshara model. The changes were almost mandatory given the level of requirements required with the new regulations. The changes also allow us to have an easier model to use as a user because it means we have more control over each of the parameters of the model, and we can configure all the different runs much faster. We also made our runs resilient by adding all the different checks that were relevant for us.

For further information regarding the Financial Modelling Platform and to discuss how can form part of your IFRS 17 solution, please get in touch.

Additional Resources
Was this article helpful?

Your email address will not be published. Required fields are marked *