Teaching Actuarial AI to Think Like Actuaries

The Formula Is Easy

The first time I watched an LLM compute an indicated rate change, it divided written premium by reported losses, ignored two years of loss development, and declared the book profitable. Every number in the output looked reasonable on its own. The complete picture was wrong. And the model had no mechanism to notice. That gap is the central problem of actuarial AI.

It was trying to apply the indicated rate change formula, one every practicing actuary knows:

That denominator, \((1 - V - Q)\), is the share of each premium dollar available to cover both losses and fixed overhead, after you subtract variable costs and the carrier's profit target. The numerator loads in those fixed expenses alongside the projected loss ratio. The whole formula is asking: given what we expect to pay in losses and fixed costs, how does that compare to the premium available to cover them?

Ask an LLM to produce this and it will, instantly and correctly. It can explain what each term means and cite Werner & Modlin's Basic Ratemaking (the standard CAS exam text). If you're grading on memorization, the model gets full marks.

Now give it real data. A triangle of paid losses by accident year. Earned premium at current rate level. A rate change that took effect last October. A coverage where claims take four years to fully develop. Ask it to compute the indicated rate change.

It will produce a confident, wrong number.

The gap between knowing the formula and applying it correctly is the entire actuarial profession. That gap is also where LLMs fail in ways that reveal something fundamental about how they process information, and why we had to build something different.

---

Five Ways an LLM Will Confidently Get It Wrong

These aren't hypothetical. They're failures I've seen firsthand while building our platform, across models and prompting strategies. Each one follows directly from how language models process sequences of tokens, and each one maps to a piece of actuarial judgment that can't be expressed as a text pattern.

1. Basis mismatch

The model sees a column labeled "Premium" and a column labeled "Losses." It divides one by the other. Loss ratio computed, task complete.

Except the premium is written and the losses are incurred. Written premium is recorded when a policy is issued. Earned premium is the portion recognized over the coverage period. Incurred losses reflect the full estimated cost of claims: paid amounts plus outstanding case reserves on known claims plus IBNR (incurred but not reported) estimates for claims that haven't surfaced yet. These quantities are measured at different points in the policy lifecycle: dividing one by the other on mismatched bases produces a ratio that is actuarially meaningless.

An actuary's first instinct when handed a loss ratio is to check the basis: are the numerator and denominator on the same footing? LLMs don't have that instinct. They pattern-match "premium" and "losses" into a division operation without tracking the accounting basis of each quantity. The tokens look right; the computation is wrong.

2. The development trap

A 12-month-old accident year shows a 50% loss ratio. The LLM reports it as favorable experience. An actuary knows that accident year is still developing. For a long-tail liability line like general liability or medical malpractice, 12 months of maturity might represent less than 40% of the ultimate loss. Apply a development factor of, say, 2.5× or more and the true loss ratio, once all claims have been reported, litigated, and settled, is well above 100%.

Loss development is a temporal process: insurance claims emerge over years, sometimes decades. The LLM has no internal state tracking where a given accident year sits in its development lifecycle. It sees the number at face value because, at the token level, "50%" looks like any other percentage. There's no mechanism in the architecture to flag it as incomplete.

3. Missing on-leveling

The loss ratio dropped 15 points year-over-year. The LLM interprets this as improved experience. An actuary asks: did rates change?

If the carrier implemented a 25% rate increase last year, then this year's earned premium is inflated relative to the prior year's. The loss ratio looks lower not because losses improved, but because the denominator got bigger. To make a valid comparison, you need to restate all historical premiums at the current rate level by using on-leveling techniques like the parallelogram method or extension of exposures, depending on data availability. (The parallelogram method is named for the geometric shape formed when you plot rate changes against policy effective dates on an earned premium diagram: a visualization that makes the math intuitive but that no language model can reconstruct from tokens alone.)

This failure is especially hard to catch because the LLM's answer is directionally plausible. Loss ratios can improve without rate. Without on-leveling, the model can't distinguish a loss ratio numerator effect from a denominator effect, and it won't volunteer that the distinction matters. It doesn't know what it doesn't know.

On-leveling isn't the only temporal judgment LLMs miss. Trend selection has its own trap: the trend period doesn't run from the most recent data point to today. It runs from the midpoint of the experience period to the midpoint of the prospective rating period. Get the endpoints wrong and you shift the entire indication. An LLM has no concept of "midpoint of experience period" as a temporal anchor.

4. The expense allocation trap

The indicated rate change formula splits expenses into two categories for a reason. Fixed expenses (home office overhead, employee salaries, IT infrastructure) don't scale with premium. They go in the numerator as a ratio to premium, added alongside the loss ratio. Variable expenses like commissions and premium taxes scale with every dollar of premium. The target profit and contingencies provision operates the same way economically. All three go in the denominator, subtracted from 1.

An LLM can easily put fixed expenses in the denominator or combine all expenses into one term. It pattern-matches the formula structure without understanding the economic reasoning: fixed costs must be recovered by the rate level regardless of volume, while variable costs are a marginal cost on each premium dollar. The resulting bias is systematic rather than random, and it compounds across every policy in the book.

The ULAE problem is a variant of the same failure. Unallocated loss adjustment expenses (claim department overhead) are economically a cost of settling losses, not a cost of writing premium. They should be modeled as a multiplicative factor on losses: \((1 + \text{ULAE Ratio}) \times \text{Losses}\). LLMs often treat ULAE as a premium-based expense, producing a rate indication that is structurally misallocated even when the arithmetic is correct.

5. The credibility blind spot

An actuary reviewing a small book, say 50 claims over three years, knows that the observed experience is statistically thin. You can't take a 40% loss ratio from 50 claims at face value the way you would from 50,000. The standard actuarial response is to blend the observed experience with a complement (industry data, prior selections, or a Bühlmann credibility estimate), weighted by statistical reliability. LLMs have no concept of this. They treat every dataset as equally authoritative, whether it contains 15 data points or 15,000.

Side by side, the pattern is clear: each failure skips a check that actuaries treat as non-negotiable.

Failure	The check it skips	The consequence
Basis mismatch	Premium and loss on the same accounting basis	A loss ratio that means nothing
Development trap	Loss development to ultimate	Immature years read as favorable
Missing on-leveling	Premium restated at current rate level	Rate changes mistaken for loss improvement
Expense allocation	Fixed vs. variable split in the formula	A systematically biased indication
Credibility blind spot	Experience weighted by statistical reliability	Thin data treated as gospel

---

Why Prompting Can't Fix This

The immediate reaction to these failure modes is to add instructions. Tell the model to check the premium basis. Remind it to apply development factors. Add a verification step for expense allocation.

This works for one check at a time, in isolation, on a single example. It does not scale.

An actuary reviewing a rate filing makes a long chain of implicit judgments: checking the basis of every quantity, tracking the development maturity of every accident year, verifying on-level status, validating trend selections, questioning credibility assumptions, confirming that the experience period aligns with the rating effective date. These judgments are contextual (the right check depends on what you're looking at) and they compound across computation steps. The output of step three becomes the input to step seven, and if step three silently used the wrong basis, step seven inherits the error with no signal that anything is off.

Every additional instruction you add to a prompt competes for a bounded budget of attention with the actual computation. Add enough guardrails and the model starts ignoring some of them, or gets confused about which check applies to which step. You're using the model's limited reasoning bandwidth to do bookkeeping that shouldn't require reasoning at all.

An actuary's instinct is to blame the training data. An ML engineer's instinct is to write a more detailed prompt. When you understand both the domain requirements and the architectural constraints, you see that neither approach addresses the real problem: these are stateful invariants that need to be enforced mechanistically, not checked probabilistically.

The fix has to live in a different layer of the system entirely.

---

Encoding Judgment as Types

Instead of teaching the LLM to be careful, we built a typed computation layer that eliminates entire categories of common errors at construction time.

Consider the core indicated rate change function in our actuarial library:

indicated_rate_change(
    reported_losses: Loss,
    earned_premium: Premium,
    ldf: Factor,
    on_level_factor: Factor,
    loss_trend_factor: float,
    credibility: CredibilityWeight,
    complement_loss_ratio: float,
    fixed_expense_ratio: ExpenseRatio,
    variable_expense_ratio: ExpenseRatio,
    profit_and_contingency: ExpenseRatio,
    premium_trend_factor: float = 1.0,
) -> WaterfallResult

The core quantities carry domain types: Premium, Loss, Factor, ExpenseRatio, CredibilityWeight. The parameter is named earned_premium, not "premium." The type system enforces that the value is a valid dollar amount; the explicit name is what surfaces a basis mismatch, making it visible in review before a single computation runs.

The function takes reported_losses and a separate ldf factor; the library develops losses to ultimate internally. You can't pass undeveloped losses and have them silently treated as ultimate. The type system and the function contract work together: the name tells you what to provide, the types enforce what's valid, and the computation handles the rest.

The ldf parameter, the loss development factor, encodes development awareness directly. You can't compute an indicated rate change without explicitly providing the development factor, which forces the upstream pipeline to select and apply one. Every path through the computation requires an explicit development assumption.

The on_level_factor works the same way: an indication requires it. If you haven't computed one, the library includes a parallelogram_factor function: give it each rate change's position in the experience period and the cumulative rate level it produced, and it returns the on-level factor. The chain of dependencies is explicit in the type signatures. Skip on-leveling and you get a type error instead of a silently wrong answer.

Expenses are separated in the function signature: fixed_expense_ratio and variable_expense_ratio are distinct parameters. There's no total_expense_ratio parameter that lets you smuggle in a combined figure. The formula itself enforces the economic distinction (fixed in the numerator, variable in the denominator) because the function's implementation puts them where they belong. The API design makes it hard to get expense allocation wrong.

The output is a WaterfallResult, not a bare number. It carries every intermediate computation: the developed loss ratio, the on-leveled loss ratio, the trended loss ratio, the credibility-weighted ratio, and the final indicated change. When an actuary reviews the output, they can see exactly what happened at each stage. That is the audit trail a reviewing actuary or regulator wants to see, and a bare "the indicated change is 8.3%" can never provide it.

A worked example, with illustrative numbers: raw reported loss ratio of 52%. Apply a 1.35 LDF; developed loss ratio becomes 70.2%. On-level the premium with a 1.08 factor; on-leveled loss ratio drops to 65.0%. Apply a 1.03 annual trend factor; trended loss ratio is 67.0%. Blend at 85% credibility with a 72% industry complement; credibility-weighted loss ratio lands at 67.7%. Plug that into the formula with \(F = 12\%\), \(V = 25\%\), \(Q = 5\%\); indicated rate change is +13.9%.

The design goal is simple: make invalid actuarial inputs hard to express. The LLM never needs to remember to check the basis, because the type system won't let it proceed without one.

The same architecture handles the pure premium method, where projected ultimate losses per exposure are compared directly against the current rate. Choosing between the two methods is itself an actuarial judgment the LLM makes from data availability and line characteristics; the library executes whichever path is chosen correctly.

Ratemaking is actually the straightforward case. The same judgment failures compound when you move into specialty lines and reinsurance. The actuarial reasoning only gets harder in those domains.

Take claims-made pricing, the structure used for D&O, E&O, medical malpractice, and most professional liability. An occurrence policy covers events that happen during the policy period; a claims-made policy covers claims reported during it. The pricing relationship between the two depends on step factors derived from loss development patterns, retroactive date exposure, and the five principles of claims-made pricing laid out in the CAS literature. An LLM asked to price a third-year claims-made policy will pattern-match "multiply by a step factor" without understanding that the step factor encodes the fraction of ultimate losses not yet reported at that maturity, or that a year-one cancellation tail commonly runs 75–80% of the occurrence premium, because a first-year claims-made policy has covered only a small slice of the occurrence-equivalent exposure and the tail picks up the rest. These aren't edge cases. They're core to how tens of billions of dollars of professional liability premium are priced every year.

Reinsurance compounds the problem further. Treaty pricing layers judgment on top of judgment. Experience rating blended with exposure rating. Loss corridors that exclude attritional losses. Reinstatement provisions that change the effective price as losses emerge. Catastrophe loads built from stochastic models where a single assumption about demand surge or secondary uncertainty can move the price materially. Each of these is a domain where an LLM's surface pattern-matching breaks down, and where typed computation with enforced constraints becomes essential.

The typed library handles these too. Claims-made step factors are derived from the same LDF patterns the library already enforces. Tail premiums are computed mechanically from the unreported percentage at policy maturity. The architecture doesn't care whether you're pricing a personal auto book or a $50M excess D&O layer. The judgment enforcement works the same way.

---

How the Role Changes

The system splits responsibility cleanly. The LLM decides what to compute: which accident years to include, which development method to apply, how to weight the experience. It gathers inputs, interprets context, and explains findings in natural language. Language models are good at those tasks. The typed library handles the how: executing the computation correctly, enforcing constraints, rejecting invalid inputs before they produce invalid outputs.

The actuary's role expands. When the mechanical work is handled reliably, the actuary stops spending days assembling exhibits and starts spending that time on the judgment calls that actually move the needle.

The practical target is a tenfold shift: an actuary who once reviewed three state filings a quarter can cover thirty instead, because the system handles the data assembly, development selections, on-leveling, and expense allocation automatically. The actuary's time shifts to the questions that require genuine expertise: Does this trend selection make sense given the legal environment in this state? Is the credibility complement appropriate for a book that's shifting mix this quickly? Should we be filing at all right now, or is the regulatory climate better six months from now?

The same pattern applies to product design and strategic pricing. Instead of spending weeks building a single rate indication from scratch, actuaries can explore dozens of scenarios (different trend assumptions, alternative credibility complements, varying expense allocations) and understand how each one changes the answer. The analysis that used to take weeks compresses into days, sometimes hours, and the actuary's time goes to the harder question: what should we actually do with these results?

The regulatory angle matters here too. Actuarial Standards of Practice (ASOP No. 23 on data quality, No. 25 on credibility, No. 12 on risk classification, No. 41 on communications, and No. 53 on ratemaking cost estimates) require documentation of exactly these decisions. The WaterfallResult provides that documentation automatically. Every rate indication produced by the system carries its own audit trail: the kind of exhibit package state regulators routinely ask for in rate filings. The actuary reviews and signs off on a complete, traceable analysis instead of building it by hand.

The layer sits inside the larger system: our multi-agent runtime orchestrates the agents that invoke these computations, while the actuarial judgment layer keeps the domain logic itself sound.

An actuary's expertise, encoded once as typed computation, runs behind every analysis the system produces. That leaves the actuary's time for the decisions no formula can make.

---

What's Next for Actuarial AI

We're building ActuaryBench, an evaluation framework that measures how well AI systems handle real actuarial reasoning: the multi-step, judgment-heavy analysis working actuaries do every day, rather than pattern recognition on textbook problems.

The five failure modes in this post are the seed of that benchmark. Each one becomes a family of test cases: basis traps, immature accident years, unannounced rate changes, expense allocation puzzles, thin-data credibility calls. If an AI system claims actuarial competence, those are the questions it should have to answer under scrutiny. More on that soon.

---

References: Werner, G. & Modlin, C., Basic Ratemaking (5th ed.), Casualty Actuarial Society, Chs. 5–8, 12, 16 · Marker, J. & Mohl, F., “Rating Claims-Made Insurance Policies,” CAS Discussion Paper Program, 1980 · Friedland, J., Estimating Unpaid Claims Using Basic Techniques, Casualty Actuarial Society · Actuarial Standards Board, ASOP Nos. 12, 23, 25, 41, 53 · Liu, N. F. et al., “Lost in the Middle: How Language Models Use Long Contexts,” TACL 2024.

---

We are building toward actuarial AI that can be tested against real judgment-heavy workflows, not textbook formulas. If that is the standard your team needs, let's talk.