Actuarial-Modeling | Remotely Actuarial

AI assisted Actuarial Modeling, who owns the key ingredient?

Wed, 19 Mar 2025 00:00:00 +0000

The sad news about Montoux

The recent news that was sad to see. There are not many companies trying to innovate in the Actuarial modeling space and now there is one less. Innovation and disruption almost always lead to good things for customers and so the customers (Actuaries building models) are really one of the biggest losers with this news. Some people are reporting that this was “lawfare”, see .

From the link above it seems that Fidelity National Information Services, Inc. (FIS), the owners of the Prophet modeling system, who are a massive company brought a lawsuite against Montoux that they knew would bury them in legal costs. Maybe Montoux pushed the envelope too much (as startups sometimes do) and opened themselves up to this risk (i.e. they were in the wrong), you can decide this for yourself.

Regardless, Montoux going under is unfortunate and will set innovation in Actuarial modeling back significantly. Every small startup in this space is trying to find the one large customer that will take a chance on them. From what I heard Montoux did make some progress at cracking into larger insurers. However, now those insurers are left high and dry which will make them more risk adverse. This will lead to carriers playing it safe and larger monopolies when it comes to vendor supplied Actuarial modeling software. In turn this, unfortunately, will lead to less innovation and worse tools for Actuaries.

So, there is one less innovator and one more cautionary tale for insurers when they think about taking a chance on a small innovative solution. The real loser? Actuarial modeling.

The story within the story

This post is not about Montoux, FIS or who is right or wrong. For me, the Montoux story has another layer to it. According to the lawsuit Montoux got into trouble for a “Model Replication Module” that would aid potential customers in migrating off Prophet to Montoux. Switching costs in Actuarial modeling are very high so this technology would help existing insurers reduce these costs.

In Prophet there is a standard library of sorts. You use “indicators” to bring in product features when you begin building an insurance product. Based on these indicators you get a “template” for the product and then you customize from there. The thing that is interesting about Prophet is that you can edit all the code once a product is built.

In my experience, it’s normal to heavily customize the code after first creating a product template. Then the question is “who owns the code you write?” Is this code written by FIS that you tweaked or did you start from some very basic template and build your product (I know some people that don’t use the template at all)? Where you are on this spectrum depends on how you use the product. However, from the lawsuit that was filed it seems that FIS might believe that they own the code written in Prophet or at the very least that you can’t separate the part they own (the DSL and the “template” code) from the part that users likely believe they own.

Why is “ownership” important?

I think this is a question that will become more and more important in the near future. I was very skeptical of the whole “AI will replace everyone” narrative, and to some degree I still am. However, something that is very clear is that software development is going to transform. Building software is fundamentally about solving problems, AI will not replace (good) developers but it will change the tools they use to solve problems and as a result the cost of software development will reduce (potentially dramatically).

I believe this could completely change the “Build vs Buy” trade-off when it comes to Actuarial modeling. The biggest downside to the “Build” option to this point has been the cost of engineers to build and maintain the software but with this cost reducing this will become less of a downside. This process could also be accelerated if some strong open source modeling libraries take off or if we, as a community, can agree on some .

Add to this that the negatives of the “Buy” side will become more pronounced also. There are many tried and tested solutions to problems encountered in building software, things like version control, CI/CD, cloud management, etc. However, due to the incentives at play, vendors are more likely to try and build their own custom solution (and charge you for it) than to integrate with industry standard solutions. However, the new wave of AI enabled tools will likely be designed to integrate with these industry standard solutions as many of them are open source. This means there is a lot of data on how to use these tools freely available, i.e. training data.

Vendors will try to add the same AI enabled productivity gains to their software and hope the switching costs are too high. They do have some advantages. One is that they could specialize their AI solution to the insurance domain via fine tuning their AI models. It’s easy to see that an AI that understands insurance product design could be better for Actuaries than one that knows how to “just code”.

Now we can get to the important point. If vendors believe they own your code or it’s not clear you own it, can they use it to fine tune their AI solutions? I’m not saying they will, I’m just saying that it’s not something people were thinking about when they signed contracts, potentially years ago. Also, there would be no “smoking gun” as there was in the Montoux case. Software communicates back to the vendor for all kinds of reasons, license servers, telemetry, etc. In this case, there will be no evidence that your code was used, no marketing material to point to like the Montoux case. Just millions of trained parameters.

Conclusion

Things are changing very quickly on the AI front and companies need to foresee the challenges that are coming because when change comes it will be rapid.

In the new world of AI solutions the foundation models will become commodities, available from the big tech companies, and fine-tuning for specific domains will become the differentiator (some recognise this and are targeting the fine tuning step of the process). When this becomes the case, having access to the domain specific data to fine tune on will be the competitive advantage.

Actuarial modeling software is generally slow to adopt new technology and the agreements you originally signed might not be considering where the industry is going…

Disclaimer

To be clear, I am not anti vendor supplied Actuarial software. I am pro user centric software. I have used many vendor supplied solutions and can see the value they bring, including Prophet. However, I also think that larger vendors need to be pushed by smaller innovators to ensure the best outcomes for end-users.

Could the Actuarial community benefit from an open Actuarial Intermediate Representation?

Sat, 18 May 2024 00:00:00 +0000

Note, when I talk about Actuarial modeling below I’m referring to long term insurance, not P&C.

What is an “Intermediate Representation”?

Programming languages make different trade-offs, some are high level, some are low level. I might consider Python to be high level and Rust to be low level. However, this classification depends on your perspective.

Modern compilers are made up of many layers of “programming languages”, it’s just the ones under the hood are not designed for humans. In fact, several compilers for modern languages use the same backend to , i.e. they use the same internal “programing language” or intermediate representation.

An intermediate representation (IR) is a standard representation that is designed with the next phase of compilation in mind. When you run cargo build (for Rust) you don’t see any of this, you just get a nice new optimized binary but your code can pass through many layers of IR before the final binary is created.

Why are open standards important?

Open standards help spur innovation. The Rust compiler is a very sophisticated piece of software but if it could not rely on the it would have taken much more effort to realize. At some point it became obvious that it did not make sense for every programming language to rebuild how to optimize code for specific hardware targets while also supporting a wide range of targets. Programming languages “compete” on other things, like the experience for developers. Investment in LLVM, for example, benefits all the languages that use LLVM as a backend and the entire developer community is better off as a result.

set out to do something very simple. It set out to align the community on how to lay out tables of data in memory (down to the bits and memory alignment). This is a very simple concept but has had major impacts, for example see . As a result, Arrow is seeing major adoption in data systems. With Arrow establishing itself as the foundation it has allowed other projects to be realized such as which builds on Arrow to define a kind of IR for relational algebra (i.e. database systems).

The competition in the database space is intense, new databases are popping up all the time to the point that it’s hard to keep up. However, there is more and more of a trend toward less vertically integrated systems. and this is only possible due to open standards like Apache Arrow and Apache Substrait.

What would an Actuarial IR look like?

I’m not sure, but I’ve thought about this alot. Actuarial modeling is interesting as it’s quite varied. Regular valuation type runs are alot like batch processing, on the other hand other types of jobs involve path dependent benefits, etc. and can’t be parallelized in the same way. However, this would be the whole point of a single IR representation. You represent the logic via one IR and you could deploy and optimize the logic for the specific use case and computation patterns.

There is alot of prior art to pull inspiration from. From Substrait mentioned above to which allows , this would be a very useful feature in Actuarial models.

“Community over Code” is the mantra of the Apache Software Foundation, and it’s especially true for projects around open standards. The concept of Arrow is quite simple, the technical details are quite complicated, but its success as an open standard is dependent on the community that supports it.

If an Actuarial IR could be developed it would have to be a community effort.

Why is now the time?

The Actuarial profession and community is being forced to evolve. Actuaries were the original data scientists. However, the rise of the data scientist / Machine Learning / AI, etc. is challenging the Actuarial profession. On this front, the SOA is recognizing the challenge and .

However, on the technology side I don’t think we are evolving the way we need to. Machine learning / AI evolved from computer science and require a strong technology foundation (both the skills of the practitioners and the tools available). We also need to free up Actuaries to allow them to work in the areas that have the most impact for the businesses they serve. We need to reduce the cost of Actuarial modeling and provide access to new technologies.

I believe that the status quo of vendor supplied vertically integrated systems is holding us back on this front (this is my experience, if you feel your system is different please reach out! I would love to be proved wrong 😄).

What could the future look like?

Let’s assume we have defined our new IR called Actuarial IR (AIR), it was a community effort and is seeing broad adoption, what would be different today?

Each modeling system could focus on what they believe is their competitive advantage, they could focus more on the experience for Actuaries who build models and less on how to optimize their custom domain specific language to the new accelerator of the day. Or they could target a different part of the stack like program analysis to identify inconsistencies in models across an organization, etc.

We could develop a common infrastructure for deploying and optimizing AIR for different hardware targets. This would turn into a common challenge and insurers don’t compete in this domain, so they could collaborate to reduce the cost of insurance for the industry.

We could define how to serialize AIR so compute plans could be sent to different machines efficiently allowing all systems that adopt the standard to run in a distributed fashion.

It would allow us to define new reporting standards in a single place as a reference implementation for all the community to use. i.e. the specification for common reserving approaches could be written in AIR.

It would support the modularization of Actuarial models. In YouTube video on Actuarial transformation the speaker dreams of a more modular Actuarial modeling infrastructure (starting at 22:20). This would be possible with AIR.

We could build a variety of “front-ends”. For a small insurer they could use Excel with a plugin that exports their Excel model to AIR. From there the ecosystem of tooling around AIR could be used.

Actuarial software vendors would be pushed to innovate! Vendor lock-in would no longer be the reason to stay as there would be pressure to support an export (and import) to AIR. Some Actuaries may not like this (if they work for Actuarial software vendors) but I believe the benefits to the community as a whole could be immense. Also, there could be a huge new opportunity for software vendors, they could focus less on major parts of the Actuarial modeling stack and instead could focus on innovation and incorporating new technologies like advances in AI, etc.

Summing up…

Actuarial models are becoming more and more complex
different models require different compute patterns
new regulations are pushing us and our models to deliver more in less time
all these pressures leave no room for pushing forward the state of the art in Actuarial modeling/science
we need to reduce the burden
I believe that defining and adopting community driven open standards could do this

A similar path has been followed in the database community, and it has led to new innovation in database development. YouTube video (though technical in parts) is only 15 minutes long and provides a good summary of the changes in that domain. I can see so many parallels in Actuarial modeling…