By Ronald Richman
One of the largest numbers on any insurer's balance sheet is an estimate of claims that have already happened but have not yet been paid. Some are reported and working through the pipeline. Some have not been reported at all: the crash was last week, the lawyer's letter arrives next year. Insurers must hold reserves for all of it, and the unreported part goes by the acronym IBNR, incurred but not reported.
Here is the part that surprises people from outside the industry. That number, frequently in the billions, is typically estimated from a dataset called a loss triangle that might contain fifty cells. Rows are accident years; columns show how each year's claims have paid out as they age; the recent rows are unfinished and must be projected to their ultimate cost. And when the estimate is done, a specific, named actuary signs it, with professional obligations attached to the signature. A loss triangle is a small dataset with an outsized job.
Now look at how the number is usually produced. Pick a method: Chain Ladder, Bornhuetter-Ferguson, perhaps Cape Cod if the premium data cooperates. Pick a few development factor averages: all years, last five, last three excluding the diagonal everyone mistrusts. Argue about the last origin period. Overlay judgement, document the selection, sign. The judgement in that process is real, and it is the most valuable part. But notice when it arrives: after a single specification has been fitted, supported by a handful of sensitivities run in whatever time was left before the deadline. That is judgement after a specification, not evidence before it.
In 2020, Caesar Balona and I published The Actuary and IBNR Techniques: A Machine Learning Approach, which made a point that now feels obvious: the classical reserving techniques are not single methods but large families of models. Every choice inside them (which averaging period, which factors to exclude, how to treat the tail, how much weight to give the prior) is a hyperparameter. And hyperparameters do not have to be chosen by habit. They can be chosen the way machine learning chooses them: hold out the recent diagonals, back-test each candidate specification on data it had not seen, and let out-of-sample performance narrow the field before judgement selects from it.
A paper is one thing; a production system a reserving team will trust with a statutory number is another. We founded insureAI in November 2024 and have been building that system since. ReserveAI is the result, and it is now in production with several insurers across three continents. To be clear, it is not the 2020 paper wrapped in an API. Making the approach survive real portfolios (messy, heterogeneous, full of the pathologies papers politely ignore) pushed us well beyond what we published: how the engine generates, evaluates, and ranks its candidate models is new work, and those enhancements are patent-pending. The paper is the idea. The product is what it took to make the idea safe to sign against.
The phrase that guided the build is reserving as code. Load a triangle. Run the methods you already trust. Then, instead of one specification, back-test thousands of variants of those methods on your own data; a typical run currently evaluates around 8,000 candidate models. Rank them. Read the diagnostics. Select. Sign.
If your first reaction is that fitting thousands of models to fifty data points is a multiple-comparisons horror show, good. That is the correct first reaction, and it shaped the design. The candidates are not arbitrary flexible learners; they are constrained variants of methods with a century of practice behind them. Evaluation is out-of-time: models are scored on held-out diagonals they never saw, the way you would judge any forecaster. Ranking is multi-dimensional, because in reserving "good" is not simply low back-test error; any experienced reserving actuary can name several other properties a defensible basis has to show, and the engine scores its candidates against a battery of them. Which properties, how they are measured, and how they trade off against each other is the part of the work we keep to ourselves. And the top of the leaderboard does not book itself. What comes back is a ranked, evaluated field of models with projections and performance metrics attached: evidence laid out for a person whose job is to choose, not an argmax wearing a suit.
Why does a person still choose? Because that is what the regime demands, and the regime is right. Reserving opinions, IFRS 17, Solvency II: all of it requires a basis a named human can defend to a reviewer, an auditor, and a regulator. Those frameworks want a basis you can defend, not a black box you can demo. The closest analogy is the structural engineer stamping drawings: software runs the finite element analysis, and a person remains on the hook, by design. Software that tries to make the signature unnecessary has misunderstood whose name is on the opinion.
The client is reserveai on PyPI. It speaks pandas and polars, moves triangles between long and wide views, plots the pictures reserving actuaries actually look at, and exposes Chain Ladder, Bornhuetter-Ferguson, and Cape Cod. One call runs the whole field of variants. Computation is server-side, and the package is deliberately thin. Part of that is engineering: a search across thousands of specifications should be reproducible, version-pinned, and auditable, which is far easier to guarantee on one engine than across a hundred desktop Python environments. Keep the client version, keep the run ids, and when a reviewer asks in eighteen months why this ultimate and not that one, the paper trail is the answer rather than the start of a search for one. And part of it, plainly, is that the enhancements are the company; we are not shipping them as a wheel file.
None of this asks a reserving team to abandon current practice. You can still do the manual link ratio work you would do in Excel on the same triangle, and I would expect any sensible team to keep doing it as a cross-check. You can request a stochastic distribution when a measurement basis needs one. You can put the whole exercise on a schedule so the quarterly refresh runs itself. And because the SDK ships with a CLI, coding agents can drive it: we use it from Claude Code and Codex, and that agentic path still terminates, deliberately, in a number a person signs.
I want to be precise about intent, because "AI for reserving" invites the suspicion that the actuary is being engineered out. The opposite is true. Reserving is one of the few places in finance where expert judgement is not a gap in the data but the actual product: the opinion exists because someone weighed the evidence and put their name to the result. My complaint was never that actuaries exercise judgement. It is that we have historically given them so little evidence to exercise it on: one specification, a few sensitivities, and a deadline. ReserveAI fixes the evidence: more of the specification space searched, all of it comparable, and an audit trail for whoever asks why.
The method paper is Balona and Richman (2020), linked above. The software is reserveai on PyPI, with pre-rendered tutorial notebooks so you can see a full run before writing any code. If you work on or near this problem, I would enjoy the discussion in the comments.