Teams spend a decade improving fraud detection — better models, more signals, graph analytics for organised rings. The models got genuinely good at one thing: raising a flag. Then the flag lands on an investigator's desk with almost none of the context that justified it, and a skilled human starts gathering evidence from scratch. The detection got smart; the handoff stayed dumb. And the handoff is where the ROI leaks out.
Detecting fraud and proving it are different jobs
A model flagging a case as suspicious is a probability, not a case. Someone still has to pull history, resolve the parties against known networks, review documents, corroborate against external data, and build something that supports a decision. That's slow, manual work — and here's the dirty secret: the model can flag far more than the investigation team can work. So most flags are never actioned, and the ones that are begin with re-assembling evidence the model already had.
Where the value dies
-
The "why" is lost. The model flagged for specific reasons — a shared bank account, an implausible timeline, a document anomaly. The investigator often receives
score: 0.91and none of the reasons, then rediscovers them by hand. - The evidence isn't assembled. Everything needed exists across systems, but nobody pre-packages it. Scarce investigator time goes to gathering, not judging.
- Capacity is the real bottleneck. Flag 500, work 50 → 450 potential frauds paid for lack of time, not because they were cleared. More detection without more throughput just grows the ignored pile.
- No feedback loop. Investigation outcomes rarely flow back as training labels — the one dataset that would make detection smarter is left on the floor.
Engineer the handoff, not just the model
The highest-ROI move is usually the plumbing:
- Ship the reasons with the flag — the driving signals in plain language, so the investigator starts with a hypothesis.
- Assemble the case file automatically — history, resolved party links, prior claims, external matches, pre-gathered into one view. Hours of collection → minutes of review.
- Triage by workability, not just score — prioritise cases that are high-risk and investigable within capacity.
- Close the loop — feed confirmed/cleared outcomes back as labels.
Notice the leverage isn't the algorithm — it's entity resolution, data integration, and workflow engineering around it.
flag ──► [enrich: reasons + resolved entities + prior claims + external]
──► [triage: risk × workability × capacity]
──► investigator (judges, doesn't gather)
──► outcome ──► back to training set
Full write-up:
The Fraud Model Flags It. Then What? The SIU Handoff Nobody Designs →
From IntelliBooks' series on the data foundation under insurance AI.
Anyone actually feeding investigation outcomes back into the model? That loop seems rare in practice.
Top comments (1)
The lever most teams miss on a capacity-bound queue isn't ranking the 500 better, it's shrinking the 500 before a human ever opens one. A decent slice of those flags aren't really 0.7 probabilities — they're decidable from cheap infra signals the model just folds in as more features: a signup from a hosting/datacenter range on a throwaway email domain is an auto-action, not a judgement call, and the same is true on the other tail for the obviously-clean ones. Auto-resolve both tails and your 50-case budget goes entirely to the ambiguous middle, which is the only place a human's time actually pays back. Nice side effect for your feedback-loop point: the labels get cleaner too, because investigators stop burning cycles rubber-stamping the easy stuff. (I keep ipasis.com/scan open just to eyeball whether an IP is residential vs datacenter/proxy before it even reaches the scoring step.)