y 2035, no one in life insurance still talks about “running the model”.
That phrase belongs to an earlier era; a time when modelling was an event rather than a capability, when results arrived hours or days after questions were asked, and when insight lagged behind decision-making.
In 2035, modelling is simply there. Always on. Always available. And quietly shaping almost every material decision a life insurer makes.
Mention artificial intelligence in an insurance context and the conversation usually jumps straight to extremes. Either AI is about to replace actuarial judgement altogether, or it is dismissed as another technology trend that regulators will never fully allow into the heart of financial reporting.
Every few years, life insurance modelling circles back to a familiar idea: “Surely we can build this ourselves now?”
Open-source languages are mature. Cloud infrastructure is cheap and elastic. Numerical libraries are faster than ever. On the surface, the case for fully open-source financial modelling feels stronger than it ever has.
And yet, time and again, large-scale internal build attempts quietly stall, get re-scoped, or end up re-introducing vendor platforms through the back door. This isn’t because open source has failed actuarial modelling. It’s because life insurance modelling turns out to be much more than code.
For most UK life insurers, the last decade of financial modelling has been defined by regulation-driven urgency. Solvency II reshaped capital thinking. IFRS 17 then arrived and demanded industrial-scale reporting engines, new data flows, and an unprecedented level of modelling governance.
Over the last decade a number of free / open source database environments such as PostgreSQL and MySQL have emerged to challenge the traditional players like Microsoft SQL Server and Oracle. Like PostgreSQL and MySQL, SQLite has found favour with lone developers using limited data sets or developing lightweight applications. Even users of SQL Server Express Edition have moved to SQLite, where compatibility with the full edition of SQL Server isn’t a significant requirement.
Now that you’ve signed up for your Mo.net 30-day free trial, you may be wondering: what should I do next? Fear not, we have compiled an expert guide on the essentials you should focus on week-by-week to help you make the most of your Mo.net trial.
Since my series of articles last year on running Mo.net projections from within a Python script, I’ve had a couple of requests from clients who are keen to change the assumptions tables used by the projection at runtime. This short article explains how to do this, building upon the original scripts from last year.
The U.S. insurance industry is undergoing a major shift in how it calculates statutory reserves for fixed annuity products. Leading this transformation is VM-22, a new reserving standard that officially became mandatory in 2025 for many non-variable annuities. With its adoption, insurers are moving away from traditional formula-based methods and embracing a more nuanced, principle-based approach—one that better reflects the complexity and risks of modern annuity products.
In the life insurance industry, financial models—often built in complex spreadsheets—play a critical role in pricing, reserving, capital management, and strategic decision-making. These models are sophisticated, calculation-heavy, and require rigorous assumptions and projections over long time horizons. However, the very complexity that makes these spreadsheets powerful also makes them difficult to maintain, understand, audit, or transfer between teams—especially in the absence of proper documentation.
It is not uncommon for multiple model developers to want to work on the same project. Changes made by each developer need to be added in to a central codebase to ensure there is always one source of the truth. Another common requirement is to be able to carry out code reviews, to check how one version of a model differs from the previous version, or to peer review an individual’s model developments.