Feature Stores for Insurance ML: The Point-in-Time Correctness Problem

Every insurer building machine learning models eventually discovers the same quiet bug: the model that scored 0.87 AUC in the notebook is mediocre in production, and nobody can explain why. Nine times out of ten, the culprit isn't the algorithm. It's training-serving skew — the features you trained on were computed differently, or from a different point in time, than the features you serve. A feature store is the discipline that fixes this, and in insurance it isn't a nice-to-have. It's the difference between a model you can defend and one you can't.

The problem a feature store actually solves

Say you're building a claims-severity model. One of your features is avg_claim_amount_12m — the policyholder's average claim over the trailing year. In your training pipeline, a data scientist writes a SQL query against the warehouse. In production, an engineer re-implements that logic in the scoring service. These two implementations agree 95% of the time. The other 5% — edge cases around claim reopenings, currency conversions, the boundary of the 12-month window — is where your model silently degrades.

A feature store gives you one definition of each feature, computed once, and served identically to both training and inference. Write the logic for avg_claim_amount_12m exactly once. Train on it. Serve from it. The skew disappears because there is only one implementation.

Point-in-time correctness: the part everyone gets wrong

Here is the subtle trap that ruins insurance models specifically. When you build a training set, each row is a decision made at a moment in the past — a claim scored on 3 March, a policy underwritten on 12 August. The features for that row must reflect what was known at that moment, not what is known now.

If your training query joins today's avg_claim_amount_12m onto a claim from six months ago, you have leaked the future into the past. The model learns from information it will never actually have at scoring time, its offline metrics look fantastic, and it collapses in production. This is called label leakage via non-point-in-time features, and it is endemic in insurance because so many of our features are time-windowed aggregates.

A proper feature store enforces point-in-time correctness with an as-of join: for each training row, it retrieves the feature value as it was at that row's timestamp. Doing this by hand in SQL is possible but error-prone, and one wrong join invalidates the entire model. Getting this right is unglamorous plumbing, and it is exactly the plumbing that separates a model that survives audit from one that doesn't.

Why insurance makes this harder than most industries

  • Long time horizons. A liability claim can develop over years. Your feature windows are measured in months and quarters, so point-in-time errors compound over a long tail.
  • Regulatory scrutiny. When a regulator asks how a premium was set, "the feature was computed slightly differently in training and production" is not an answer you want to give. A feature store gives you a single, versioned, auditable definition.
  • Slow-moving ground truth. You often don't know if a claim reserve was right for years. That makes training-serving consistency more important, not less — you can't afford skew on top of already-noisy labels.

What to build, and what not to

You do not need to buy a heavyweight platform to start. The minimum viable feature store is three commitments:

  1. A feature registry. Every feature has one name, one owner, one definition, one version. If two teams compute "customer tenure" two ways, you don't have a feature — you have an argument.
  2. Point-in-time retrieval for training. As-of joins, enforced, so no future data leaks into historical rows.
  3. A serving path that reuses the same definition. Online lookups hit the same logic, not a re-implementation.

What you should not do is treat the feature store as an infrastructure project that has to be "done" before any model ships. Start with the five features your first model needs, get point-in-time correctness right for those, and grow the registry as you go.

The foundation under the model

The pattern here is the same one that shows up everywhere in insurance AI: the model gets the attention, but the data foundation decides whether it works. A feature store is not a modeling technique — it's a data-engineering commitment that makes modeling trustworthy. Insurers who skip it ship models they can't reproduce, can't audit, and can't explain when the loss ratio moves the wrong way.

If you're wrestling with training-serving skew, point-in-time joins, or just trying to get two teams to agree on what "tenure" means, this is the kind of foundational data work we spend our days on at IntelliBooks — getting the data right so the AI on top of it can actually be defended.

Build the feature store before you need it. The alternative is discovering you needed it during an audit.

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