Insurance Claims Automation: Build, Buy, Or Neither Until The Policy Versions

A vehicle was added to a fleet policy on the twelfth. The endorsement was recorded on the twentieth. The accident happened on the fifteenth, and the claims system, asked what was covered, returned the policy as it stands today rather than as it stood on the day of the loss.

That single failure is why most insurance claims automation programmes stall. Not the model, not the workflow engine, not the vendor. A claim is judged against a version of the policy, and a system that stamps changes with entry time rather than effective date has already lost the fact the adjudication turns on.

The prerequisite nobody prices

Run this query against your own estate before reading any vendor material.

For policy X, reconstruct the full coverage position as at any arbitrary past date, including limits, deductibles, endorsements, named insureds and exclusions, and show which change produced each element.

If your system answers that in one call, you can automate. If the answer involves an export, a spreadsheet and somebody who has worked there for nine years, you are not ready to automate adjudication, and no amount of software will change that until effective dating exists underneath everything else.

This is the single largest swing in any claims programme we are asked to price, and it is not a feature. Retrofitting effective dating into a system that stored one current state means re-deriving history, not adding a column. Nothing else on the cost table below costs more to add late.

Claims made wordings make it harder again. An occurrence policy resolves on when the loss happened. A claims made policy resolves on when the claim was notified, bounded by a retroactive date, which is a second axis entirely. A data model built for occurrence business handles claims made business by accident, badly, and usually nobody notices until the first coverage dispute.

There is a quieter version of the same problem in the mid market. A carrier running 4 products on 1 policy administration system will often find that only 2 of them version properly, because the other 2 were configured later by a team that did not know the convention. The reconstruction query has to be run per product, not per system, and running it once against the flagship line is how a programme discovers in month 5 that a third of its book cannot be adjudicated automatically.

Timescales, so this is not abstract. Introducing effective dating into a policy model that lacks it is a 300 to 900 hour piece of work on its own, and the calendar cost is larger than the hours suggest because the migration has to re-derive every in-force policy's history and be reconciled against the current state before anyone trusts it. Budget 3 to 6 months of elapsed time and a parallel run, not a sprint.

What can actually be automated, and what cannot

Automation vendors quote rates in the high tens of percent. Those numbers are real and they describe a subset that is worth naming precisely.

Genuinely automatable: first notification of loss capture and validation, coverage confirmation where the policy versions cleanly, duplicate and prior claim detection, document classification, reserve setting within band for known claim types, payment release under a threshold, and status communication.

Automatable with a human in the loop: damage estimation from photographs, fraud scoring, subrogation identification, and reserve movements outside band. Each produces a recommendation and a confidence, and the value is the triage rather than the decision.

Structurally not automatable: coverage disputes, bodily injury quantum, anything where the wording is ambiguous, and any claim where the facts are contested. These are the ones that consume adjuster time, and they always will.

The honest framing is that automation removes the volume so that adjusters spend their time on the claims where judgement changes the outcome. A programme sold as removing adjusters is being sold dishonestly, and it will be measured against a promise it cannot meet.

Straight through processing is a rate, not a feature

Every carrier wants a straight through processing number. Very few define the denominator, and the denominator is where the argument lives.

Straight through on claim count flatters heavily, because low value high frequency claims dominate the count. Straight through on claim value is the honest number and it is far lower everywhere. Straight through on eligible claim types only is the operationally useful one, because it tells you whether the rules are working on the population they were written for.

Publish all three or the number means nothing. A carrier reporting 62 percent straight through on count and 9 percent on value has a working programme and a misleading headline.

One more measure belongs alongside them: leakage. A claim paid automatically that should have been queried costs more than the handling time saved. Sample the automated population monthly and re-adjudicate a slice by hand, commonly 50 to 100 claims, and publish the error rate next to the automation rate. If nobody is doing that, the automation rate is a productivity metric with no quality control attached.

The arithmetic is unforgiving and worth doing before the programme is approved. If automating a claim saves 25 minutes of handling time, and 2 percent of automated claims leak an average of a few hundred currency units each, the leakage can exceed the saving on a low severity book while looking like a rounding error on a high severity one. Which way that goes depends on your severity distribution, not on the technology, and it is the single most useful number to compute in week one.

Cycle time deserves a place too, measured from notification to closure rather than from notification to first touch. First touch improves the moment anything is automated. Closure only improves if the exceptions clear, which is why the exception queue is the part of the programme that decides whether the headline number means anything.

Build, buy, or neither

Three answers, and the third is not a delay tactic.

Buy when you are a general carrier on a mainstream line, your policy model already versions, and your claim types are well understood. Guidewire ClaimCenter, Duck Creek, Sapiens, Majesco, FINEOS and Insurity exist because most carriers' claims problems genuinely are the same shape, and configuring one of them is cheaper than reproducing twenty years of domain modelling. The work is integration and extension rather than replacement, and the constraint that decides your plan is which extension points the vendor supports at your version, not at the version in the current documentation.

Build when the line is unusual, when you are an MGA whose product is the claims experience itself, or when the automation is the differentiator you sell rather than the cost you carry. Building also makes sense where a configurable platform would need so much extension that you are writing the software anyway with a licence fee attached.

Neither, yet when the policy model does not version. Spend the money on effective dating first. This is the answer no vendor will give you and it is correct more often than the market admits. A carrier that automates on top of an unversioned policy model builds a machine that produces confident wrong answers at speed, which is worse than the manual process it replaced.

The hybrid is common and worth naming, because it is what most carriers end up with rather than what they plan. Configurable platform for the foundational modules, custom build for the 2 or 3 capabilities that differentiate, and a clear line between them that somebody owns. The line is the hard part: every extension you write against a vendor platform is a dependency on that vendor's upgrade path, and a heavily extended platform eventually costs more to upgrade than it did to configure. Ask any prospective vendor how many of their customers are more than 2 major versions behind, and why.

Reserves are where the audit lands

Claims automation touches the reserve ledger, and the reserve ledger is where actuarial, finance and the regulator all look.

Three requirements that are not negotiable and are routinely discovered late.

Every reserve movement is an entry, never an edit. The history of what was reserved, when, by whom or by which rule, and why, has to survive. A reserve figure that was overwritten cannot be defended.

The rule version is part of the record. If an automated reserve was set by rule set 14 in March, and rule set 19 is live in November, the March decision has to be explainable against the rules that were live in March. This is the same versioning discipline the policy model needs, applied to your own logic.

Automated and manual movements are distinguishable. Actuarial reserving analysis is distorted if it cannot separate the two populations, and the first time somebody asks is usually during a reserve review with a deadline attached.

There is a fourth that only bites later. Automation changes reserving patterns, and the actuaries need to know when it started. If in-band reserves begin being set within minutes rather than after 3 days of adjuster review, the development pattern of the book shifts, and a triangle built across the change reads as a deterioration or an improvement that has nothing to do with underlying loss experience. Stamp the go-live date on the data and tell the reserving team before they find it themselves, because the alternative is a quarter spent explaining an artefact.

The same applies to any rule change large enough to move behaviour. Treat a rule set version as a dated event on the book in exactly the way a rate change is, and keep the list somewhere actuarial can read it without asking IT.

What it costs, with the hours shown

Published rates, published hours, arithmetic you can argue with.

Component	Hours	Note
Effective dating on the policy model	300 to 900	Only if it does not exist, and it dominates everything
FNOL capture and validation	180 to 380	Channel count drives it
Coverage resolution service	220 to 450	The heart of it, and useless without versioning
Rules engine with versioned rule sets	200 to 420	Version the rules, not just the data
Reserve ledger and movement history	250 to 480	Append only, with rule attribution
Exception and referral queues	160 to 320	Where most of the value actually lands
Core system integration, per system	80 to 200	At your version, not the documented one

At $40 to $100 per hour by role, blending to around $65, a claims programme on a core that already versions lands near 1,090 to 2,250 hours, so roughly $71,000 to $146,000. Where effective dating has to be introduced first, add the 300 to 900 hours at the top of the table and expect the calendar to move more than the budget does.

Phase one for the worked example on the industry page runs 16 to 24 weeks, and the constraint that moves it is a regulatory date belonging to somebody else's calendar rather than anything in your plan.

What goes wrong

1. Automating the happy path only. The exception catalogue is the specification. Returns, partial payments, reopened claims, recoveries, salvage, subrogation and provisional payments all rewrite the model if they arrive after launch.

2. Rules in application code. Claims rules change on a regulatory calendar. Rules embedded in code change on a release calendar. Those two calendars do not match, and the mismatch is discovered at the worst moment.

3. No confidence threshold. A model that always answers is a model that answers wrongly under uncertainty. Route low confidence to a human and record the threshold as a configurable number rather than a constant somebody chose.

4. Adjuster tooling left until last. The people absorbing every exception get whatever screen is left over, which is how a programme that works on paper produces a slower operation.

5. Document classification treated as solved. It is good, not perfect, and a misfiled document in a claims file has consequences an misfiled document elsewhere does not.

6. The loss run cannot be produced. If the system cannot output a clean loss run on demand, brokers and reinsurers will keep asking your team for it manually, and none of the promised time saving materialises.

7. Payment rails treated as a late integration. Claim payments touch the same idempotency, reversal and reconciliation problems as any other money movement, and a duplicate payment on a claim is considerably harder to recover than a duplicate charge. Every mutating payment call needs an idempotency key and an explicit state machine, and reconciliation has to exist before the first automated payment rather than after the first complaint.

8. Nobody owns the rules. A rules engine with no named business owner drifts within 2 quarters, because changes get made by whoever is available and the reasoning is not recorded. Name an owner, require a written reason on every rule change, and keep the change log where claims operations can read it.

A sequence that survives a regulator

First, run the reconstruction query. One page, one answer, dated. It determines whether this is a claims project or a policy data project.

Second, if versioning is missing, do that and nothing else. Resist bolting automation onto it in the same phase. This is unpopular and it is the difference between a system that can be defended and one that cannot.

Third, coverage resolution as a service, callable, versioned, and tested against historical claims where the answer is already known.

Fourth, one claim type end to end, including its exceptions, to a real payment. Resist the second type until the first has run for a month.

Fifth, the exception queue and the adjuster tooling, in the same phase as the automation rather than behind it.

A note on the pilot. Choose the claim type by data quality rather than by volume. The highest volume type is tempting and it is usually the one with the messiest history, so the pilot spends its first 6 weeks on data remediation and reports back that automation is hard. A mid volume type with clean records proves the machinery faster and gives you something to point at.

Before anyone writes a rule, run the reconstruction query against ten real claims from last year where the policy changed mid term. If the system returns the right coverage position for all ten, you have a claims project. If it does not, you have a policy data project wearing a claims costume, and the sooner that is named the cheaper it is.