One claim that never reached a handler

A single first notice of loss walked through an automated path: intake, coverage check, triage, the adjudication threshold, the payment. Each gate is a policy decision the insurer made in advance, and the file records almost none of them.

Updated September 13, 2026 Advanced

Follow one claim through a path designed so that nobody handles it.

A policyholder reverses into a bollard in a car park. No other vehicle, no injury, a dented rear quarter and a cracked lamp. She reports it that evening through an app, and the repair is paid before anyone has spoken to her. No adjuster opened the file. What follows is where the decisions actually happened, and none of them happened while she was waiting.

Intake

The report is structured from the first screen. Rather than a free-text account the app asks a sequence — when, where, what was hit, who else was involved, anyone injured, is the vehicle driveable — and each answer is a field rather than a sentence. That design decision does most of the work of the automation that follows. A narrative has to be read; a field can be tested.

Alongside the answers the system collects what it already holds or can fetch: the policy record, the cover in force at the moment she gives, the vehicle from the policy and from a plate photograph, the location resolved to a place, and whatever telematics exist if the vehicle or a phone was recording. A reverse impact at low speed has a signature in that data, and the match between the signature and the account is a check that was never available to a handler on a phone call.

Then the photographs, which is where the estimating model runs and the companion piece on photo estimation applies in full. For our purposes it produces one output that matters here: a number, with a classification of the damage it thinks it saw.

The gates

Before any of that reaches a queue it passes a series of tests, and each test is an eligibility rule rather than a prediction.

Is there cover for this loss on this date, with no lapse, no cancellation, no exclusion that engages on the facts given? Is there exactly one vehicle and no third party? Is there no injury reported by anyone? Is the claimant the policyholder or a named driver, verified by whatever the insurer uses for identity? Is the loss location consistent with the account? Is the vehicle description consistent across the policy, the plate and the photographs? Is there a previous claim on the same panel?

Any of these failing routes the file to a person. That is the honest description of most of what looks like intelligence in an automated claims path: a stack of rules, each of which sends the exception to a human and lets everything else through.

Two scores then attach. One is a complexity or severity score — an estimate of how much handling this file will need, which is what decides the queue it lands in and how much authority the person taking it has. The other is a fraud score, which the fraud piece takes up in detail. Neither decides anything on its own. Each is compared to a line.

The line

The gate that matters is the last one, and it is arithmetic: if the estimate is below a value, and the complexity score is below a value, and the fraud score is below a value, pay it.

That sentence is the entire content of straight-through processing, and everything difficult about the practice is in how those values were chosen. They are not model outputs. They were set by people in an operating committee, from an argument about capacity, cycle time and loss ratio, and they can be moved in an afternoon. Nothing about the model changes when they move. What changes is which claimants get a decision made by a rule.

The vehicle in our example is below the value. The score is low. The system issues a payment to the claimant’s registered account, or an authority to a repairer in the network, sends a message that says the claim has been settled, and closes the file.

What the waiting was

Almost nothing, and this is the part worth sitting with. The automated decision itself is a matter of minutes. The days she experienced were a payment run, a repairer’s schedule, and the periods the insurer’s own workflow imposes — a cooling interval before payment, a batch that runs overnight, a verification step on the bank details. Automating the judgement does not automate the plumbing, and in most implementations the plumbing is the majority of the elapsed time a customer experiences.

Regulatory periods sit on top of that plumbing rather than inside it. Where a regulator fixes a window for acknowledgement, for a decision or for payment, an automated path clears it comfortably, and clearing a window is not the same as discharging the duty the window exists to enforce — a decision made inside the period on a record nobody examined satisfies the clock and not the obligation. Where periods have been recorded, the periods themselves are in the rules for your jurisdiction below. Whether any of them attaches a condition to an automated decision is a question this piece answers for nobody.

That gap is the reason cycle-time improvements from automation are easy to claim and hard to feel. It also creates a specific hazard: an insurer can report a dramatic reduction in touch time while the claimant’s experience is unchanged, and the reported figure will be true.

Where this file could have been wrong

Take the same claim and change one fact at a time.

The dent was deeper than it looked and the quarter panel needs replacing rather than filling. The estimate was low, the claim was still under the threshold, and she has been paid an amount that will not cover the repair. She discovers this at a body shop, after settlement, and now she is not a claimant with an open file but a customer disputing a closed one. The path back is longer than the path forward was.

Her cover had a condition she did not satisfy — a modification undeclared, a driver excluded, a wording about car-park manoeuvres. A rule tested the exclusions it was told to test; the ones expressed in prose rather than in fields were not tested at all, because nobody read the policy. That is a leakage of the underwriting kind and it is invisible in the claim file.

The impact was not a bollard. A claim that has been paid without a human ever looking at it is a claim where a score was the whole of the fraud control, and the score is a prior over patterns rather than a look at the evidence. The inverse error is more common and less discussed: the score fires on a legitimate claim and a person with a dented car is now being investigated by a unit that specialises in suspicion.

Every one of these is a threshold consequence rather than a model failure. The model behaved as described in all four versions of the story.

Leakage, in both directions

Claims organisations have a word for money paid that was not owed, and leakage is measured, reported and managed. Automation acts on it in both directions at once. It removes the leakage that came from inattention — the duplicate payment, the rate applied to the wrong schedule, the hire car nobody closed off — and it adds the leakage that comes from paying a rule’s answer rather than an investigated one.

The direction that gets less attention has no agreed name and is the one a lawyer or a regulator will eventually bring back through the door. Payment below what was owed is invisible in a loss ratio, because it improves it. It surfaces as a complaint, a reopened file, a claimant who has instructed representation, or a pattern that somebody outside the company notices before anybody inside does.

The instrument that sees both is the closed-file audit, read by someone who did not handle the claim, sampled from the automated population specifically rather than from the book as a whole. If the automated population is not sampled separately, the automation is being measured by the average of files that did not go through it.

Speed as a service, and speed as a trap

Speed in claims is a genuine good, and it is worth being clear about that before qualifying it. A policyholder with a damaged car and a repair she has to pay for is under financial pressure that grows daily. Same-week settlement of a small claim is worth more to her than a marginally larger settlement reached in six weeks, and the industry spent decades unable to offer it. The automation delivers it.

What is being traded is not usually accuracy on the file at hand. It is the investigation that would have discovered that the file was not what it appeared to be — and the set of claims where that investigation was needed is not the set the scores identify, because the scores were fitted on the claims where somebody noticed.

Nobody outside an insurer can distinguish a claim that needed no handling from a claim that got none. Both close quickly, both look identical in the record, and the difference shows up only in a sample somebody has to decide to read, after the money has gone.

Ariski's take

Straight-through processing is the clearest case in claims of automation doing something a human was never good at: applying the same rule to the twentieth simple file of the day with the same attention as to the first. Where a claim is genuinely simple, a handler adds delay and nothing else, and pretending otherwise defends a job description rather than a service. The argument we would make against most implementations is different and narrower. The threshold that decides which files go straight through is usually set by looking at what the automation handles well, and it should be set by looking at what a wrong decision costs the claimant. Those two questions have different answers, and only one of them is visible in the operating report. Augmentation means the handler is moved to where the cost of being wrong is concentrated — not that the handler disappears from the places where the cost is quietly borne by someone outside the company.

Rules in your jurisdiction

Deadlines, fault rules and minimum coverage differ by state and country. Pick yours to see the rules that apply to this topic.

Select a jurisdiction to see its rules.

Frequently asked questions

Where should the auto-adjudication threshold sit?

Wherever the cost of a wrong decision is still recoverable, which is usually lower than the level the automation can technically handle. The two useful tests are asymmetry and reversibility. Asymmetry: at this value, does an overpayment cost the insurer roughly what an underpayment costs the claimant? For small property-damage sums the answer is close to yes, and the case for the rule is strong. Reversibility: if the decision turns out wrong, can it be corrected before the claimant has acted on it — sold the vehicle, accepted a repair, given up? Once the claimant has acted, an error is no longer an accounting entry. A threshold set from throughput capacity optimises the first cost and ignores the second, and the second is the one that reaches a regulator.

Is a review queue enough to say there is a human in the loop?

Not by itself, and the reason is a prediction about people rather than a finding we can cite: a reviewer who sees mostly correct output drifts from reviewing into confirming, because confirming is what the work rewards. A loop that means something has three properties. The reviewer can see what the system used to reach its conclusion, not only its conclusion. Overriding is as cheap as agreeing, in clicks and in how it is measured. And the override rate is monitored as a signal about the system rather than as a performance problem in the reviewer. Where a queue exists and overrides are rare and slow, the honest description is an automated decision with a person attached, and it should be described that way internally before somebody outside the company describes it that way.

How do we know whether speed is costing us accuracy?

From closed files, sampled after payment, read by someone who did not handle them — which is the same instrument insurers have always used and the one automation makes more important rather than less. Two things are worth measuring separately, because they move in opposite directions and cancel out in any combined figure: payment above what was owed, and payment below it. The first shows up in your own loss ratio and gets attention. The second shows up as complaints, reopened files, late representation and, sometimes, as a regulatory enquiry, and it does not appear in the operating report at all until it has become one of those things.