Actuaries and Data Scientists: The Handoff That Breaks Insurance Models

Walk into most insurers and you'll find two groups doing overlapping work who barely speak the same language. Actuaries have owned insurance's quantitative work for over a century — rigorous, regulated, accountable. Data scientists arrived more recently with machine learning, software tooling, and a different idea of what "good" looks like. When they collaborate well, it's powerful. When they don't — which is often — insurance models break in the gap between them, and the failure is organizational, not technical.

Two cultures, both right

The actuary's world prizes interpretability, regulatory defensibility, and stability. A rating model has to be explainable to a regulator, justifiable to a court, and consistent enough not to shock the book. That conservatism isn't timidity — it's the job. A GLM you can fully explain often beats a black box you can't, when someone can be asked under oath why a premium is what it is.

The data scientist's world prizes predictive accuracy, iteration speed, and modern tooling. A gradient-boosted model that predicts better is a win; the goal is performance on held-out data, shipped fast. That's also right — leaving accuracy on the table is its own kind of failure.

The trouble is each side quietly assumes the other's priorities are naïveté. Actuaries see data scientists as reckless with unexplainable models; data scientists see actuaries as stuck in the 1990s. Both caricatures are wrong, and the mutual suspicion is what breaks the handoff.

Where models actually break

  • The prototype that can't ship. A data scientist builds an accurate model; it dies in validation because it isn't explainable enough for pricing regulation. Months lost because the constraint wasn't agreed up front.
  • The "improvement" nobody trusts. A more accurate model is rejected because the people accountable for the book can't interpret its decisions and won't sign off on what they can't explain. Reasonable — and predictable, if you'd asked.
  • Two versions of the truth. Actuarial builds one number in one toolset; data science builds a different number in another. Both are defensible; they don't agree; leadership doesn't know which to believe.
  • Definitions that don't match. "Loss ratio," "exposure," "earned premium" — each team computes them subtly differently, so the models were never comparing the same things.

Bridging it is mostly about shared foundations

  1. Agree the constraints before modelling. Explainability requirements, regulatory limits, and stability needs are inputs to the project, not surprises at validation. Decide together what "shippable" means on day one.
  2. One definition of the metrics. Loss ratio, exposure, earned premium — defined once, computed from one governed source, used by both teams. A shared feature layer ends the two-versions-of-truth problem structurally.
  3. A spectrum, not a religion. Interpretable-but-simpler and accurate-but-complex aren't enemies; the right point on that spectrum depends on the use case. Match the model to the decision's need for explanation.
  4. Shared tooling and lineage. When both teams build on the same data foundation with the same lineage, "how did you get that number?" has one answer, and collaboration stops being a translation exercise.

Most of the fix is a common data foundation — shared definitions, a governed feature layer, lineage both teams trust — which is what turns two suspicious groups into one quantitative function. Building that foundation is exactly the work we do with insurers at IntelliBooks.

Your best actuaries and your best data scientists aren't in conflict because either is wrong. They're in conflict because they're standing on different data. Fix that, and the culture war quietly ends.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Straight-Through Processing: From 10% to 90%

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more