The same loss opens two claim numbers before anyone notices

Two claim numbers on one loss almost never come from someone opening a file carelessly. They come from 2 notices arriving through channels that do not consult each other: the insured phones the claims line, the agent emails the loss notice the same afternoon, and neither intake path looks for a file that already exists. By the time anyone notices, there are 2 adjusters, 2 sets of diary entries, 2 reserves against the same exposure, and — in the cases that hurt — 2 payments.

The confirming step is a candidate-pair report, and you can run it retrospectively over last quarter before you change any intake screen. Do not run it as an equality match. Score every pair of claims that share a policy and fall within a date-of-loss window, then look at the distribution. The output tells you how big the problem is, which channel combinations produce it, and where your thresholds should sit — three answers for one query.

Build the candidate-pair report before you change any screen

1. Block on the policy identifier, normalised. Strip prefixes, suffixes and punctuation first, because the same policy is written 3 different ways by 3 different channels. Blocking is what keeps this from comparing every claim to every other claim.
2. Widen to a date-of-loss window rather than an exact date. A window of 3 days either side catches the overnight loss reported as Tuesday by one party and Wednesday by another, which exact matching drops entirely.
3. Score each pair on the 5 fields below and record the score, not a verdict. You are calibrating, and a verdict discards the information you need.
4. Pull 50 pairs from across the score range and adjudicate them by hand. This is the only step that cannot be skipped: your 2 thresholds come out of this sample, not out of a default.
5. Plot the adjudicated pairs against their scores. The band where true and false duplicates overlap is your human-review band, and its width tells you whether the match key is good enough to automate anything at all.

The match key, field by field

The vehicle identification number deserves its position at the top of that list. It is fixed-length at 17 characters and deliberately excludes the letters I, O and Q so they cannot be confused with 1, 0 and 9 — it has been the required format on road vehicles in North America since 1981. That makes it both highly discriminating and cheap to validate at capture: a 16-character entry, or one containing an O, is a typo you can reject in the form rather than a matching problem you inherit downstream. Names have none of those properties, which is why a party-name comparison — even a good one, using an edit-distance or Jaro-Winkler measure — belongs in the corroboration column.

4 ways a second notice gets written for one loss

• The insured and the agent both report it. The most common pair by a distance, and the one with the widest time gap — often the same day, sometimes 48 hours apart, which is why a same-day-only check misses them.
• The third-party claimant reports separately. This one is not always a duplicate and must not be treated as one by default; see the boundary below before writing any rule that touches it.
• A dropped call and a call back. The first notice created a partial record and the caller redialled to a different handler. These pairs are usually minutes apart and are the easiest to catch in real time — if the intake tool searches while the handler types, which most do not.
• A re-open recorded as a new loss. Someone opens a fresh notice because the closed file cannot be worked. Reopen handling has its own rules and its own page — what happens to the automation when a claim reopens — and merging a reopen into the original is not the same operation as merging a duplicate.

The channel pattern in your own report is the actionable finding. If 80% of duplicate pairs are insured-plus-agent, the fix is a lookup on the agent-facing intake path, not a general deduplication project. If most are dropped-call pairs, the fix is a search-as-you-type against open notices in the handler's tool. Those are different builds, and the report tells you which one to fund. Channel behaviour also differs by capture design, which is the trade-off argued in guided form or voice capture for first notice.

Auto-merge, soft-link and review: where to put the 2 lines

1. Auto-merge only on identity-grade evidence: the same policy, the same vehicle identification number or schedule row, and a date of loss inside the window. Everything else waits. The population that qualifies will be smaller than you expect, and that is the correct outcome.
2. Soft-link the middle band. Both files stay open, each carries a visible pointer to the other, and neither adjuster can set a reserve without seeing that a related file exists. A soft link costs nothing if it is wrong and saves the duplicate payment if it is right.
3. Route the ambiguous band to a person with both files side by side and a 1-click decision. Not a report, not an inbox — a queue with the comparison already rendered.
4. Log every merge and every soft link with the score, the fields that contributed, and who confirmed it. A merged claim that later turns out to be 2 losses has to be separable, and separability depends entirely on that record.
5. Re-adjudicate a sample monthly. Thresholds drift as channel mix and book composition change, and the only way to know is to keep sampling.

A soft link is the cheapest control in claims intake. It costs nothing when it is wrong, and it stops the second payment when it is right.

The pairs that must never merge, however well they score

A third-party claimant reporting the same accident as your insured will score extremely well on a naive match key: same date, same location, same vehicle, overlapping party set. Merging those 2 records is not a data cleanup, it is a confidentiality failure — the claimant's file must not expose the insured's policy, prior losses or reserve position, and the insured's file must not become the claimant's status page. Keep them as separate files linked by a shared loss event, which is the model set out in taking a loss notice from someone who is not your insured.

• Different claimants on one loss event. Link at the event, never at the file, and give the event its own identifier so both files can point at it.
• Two coverages triggered by one occurrence. A property claim and a business-interruption claim may run as separate files under different adjusters by design, and merging them collapses 2 reserving decisions into one.
• One notice, 2 policy terms. A loss near a renewal boundary can genuinely attach to either term; that is a coverage question for a person, not a matching question for a rule.
• A file with a recorded statement already taken. Merging discards or duplicates evidence with its own handling requirements — the constraints are in transcribing recorded statements and what that creates.

What the report tells you about everything upstream

A high duplicate count is rarely a standalone defect. If the policy identifier is missing on one side of most pairs, the real finding is that intake could not resolve the policy and carried on anyway — the failure examined in when the policy lookup returns nothing for a covered loss. If the pair sits in 2 different queues at 2 different severities, routing produced 2 answers from one event, and the decision log that explains why is the subject of low-severity files landing in the complex queue.

The build itself is modest and it is almost always internal: a normalisation step on policy identifiers, a scored pair report, a review queue with both files rendered side by side, and a merge that writes an audit record. That is the shape of internal tools and ops work, and it usually pays for itself on the first prevented double payment. The rest of the ground between a loss happening and a file reaching a queue is in claims intake, FNOL and triage, inside our insurance and claims work.

• FNOL
• claims intake
• record linkage
• data quality