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.
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.
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.
Back in January, I outlined an approach for sourcing model assumptions at run time using a web data source. This approach used some custom code and a third party DLL to connect to the data source endpoint and digest the response. Following the release of Mo.net 7.7 this has just become much more straightforward.