AI Adoption GuideInsuranceClaim
Real-time fraud pattern detection
ML monitors claims for duplicate submissions, staged losses, inconsistent billing, and other suspicious patterns before payment.
Insurance processQuoteUnderwriteBindIssueBillServiceRenewClaim
By Don, DoneThat’s AI coach · updated
Cite the claim fact and the rule vintage
A fraud pattern flag is usable only when it names the claim fact that tripped it and the pattern rule or history vintage that made that fact suspicious. A score without both is a rumor. The desk cannot explain it to a claimant, and SIU cannot open a file from a color on a dashboard.
The fact has to already exist on the claim or in the carrier's own history: a second FNOL on the same VIN while another claim is open, a billed code that does not match the injury notes, a loss location that repeats across unrelated policies, an estimate that mirrors a closed file line for line. The vintage is just as specific. It is the date the rule was last published, the date the watch-list was last refreshed, or the as-of date of the historical cohort used for the comparison. If you cannot point to that date, you do not know whether you matched a current ring or a retired heuristic.
Platforms in this class, including FRISS, Shift Technology, Guidewire, and Duck Creek, can sit on the claim and surface those matches. Treat them as a detection layer, not as a payment or denial engine. What you need from any of them is the same artifact: a flag a person can reconstruct.
This check sits downstream of ai FNOL intake and claim triage. Intake quality decides whether the VIN, loss date, and parties are even comparable.
Load the claim before any monitor runs
Load the claim first. Pull the structured fields and the documents that will be compared: FNOL, photos, estimate, medical bills, prior claims on the same identifiers. Do not score a stub. A detector that runs before VIN, policy, loss date, and payee are present will stay silent or invent a match from noise.
Once the file is loaded, run the monitors SIU has already defined for this line: duplicate submissions, staged-loss signatures, inconsistent billing, and the other pattern families on your list. Each hit writes three cells: the fact, the rule or history vintage, and the identifiers used for the join. If a monitor has nothing to say, it writes nothing. Do not fill the cell with a low-confidence guess so the grid looks complete.
Work one file the way a desk would. A collision claim arrives with a rear-end story, a VIN, a loss date, and a shop estimate. The duplicate-submission monitor joins that VIN to a claim closed eleven days earlier, same loss date, overlapping estimate lines for bumper, cover, and sensor. The flag cites those overlaps and the rule "same VIN and loss date on a recently closed file," with the date that rule last went into production. That package is enough for SIU to open the prior file. It is not a finding that the loss was staged, and it is not a reason to send a denial letter.
Photos and bills often arrive through computer vision damage assessment and medical and legal document synthesis. Vision that overstates a panel, or a synthesis that drops a billed code, will suppress a real inconsistency or create a false one. The fraud flag inherits those errors. Cite the source document, not only the model's paraphrase.
Thin history stays a blank cell
Empty stays empty. If the carrier has no prior claims on the VIN, the address, the provider, or the payee, the history vintage is missing. A duplicate or ring detector has nothing to compare. Writing that the monitor did not run is honest. Writing a score against a synthetic peer group is not.
Thin history is common on new policies, new vendors, and first-party losses with few similar files. The correct output is a blank cell and a note that the monitor was unscored. That note is itself citable. SIU and the desk both see that this file was not cleared; it was never compared.
A flag with no vintage is a defect, not a soft warning. If the UI shows elevated risk and the supporting pane has no rule date and no history as-of date, quarantine the flag. Do not let it enter the SIU queue as a completed detection. The same rule applies to a billing-inconsistency hit that cannot name the bill line and the clinical note it disagrees with.
Do not invent a fraud percent to fill the blank. A portfolio rate, a vendor range, or a desk's gut number does not belong on the claim. The claim either has a cited pattern or it does not. A percentage parked on the file becomes folklore, then a target, then a reason to deny.
SIU investigates; nothing auto-denies
The outcome of this check is file quality, not claim disposition. SIU still investigates. The desk still owns coverage and liability. The model does not auto-deny.
A hold is not a denial. It is a pause with a cited reason, visible to the desk, and reversible when SIU finishes. Hand SIU a package they can work: the cited facts, the rule or history vintage, the joined claim or provider identifiers, and the documents that contain those facts. SIU decides whether the overlap is coincidence, poor intake, a billing error, or something that warrants a recorded interview or a referral. Until that work is done, the claim stays in a hold a human can explain.
Treating the flag as a denial is a failure mode. A denial letter that says the system detected fraud will not hold up under a complaint or a regulator inquiry. The system detected a pattern. A person has to test that pattern against the rest of the file. If SIU clears it, document the clearance with the same cites so the next monitor does not re-flag the same overlap as if it were new.
Re-run as documents land, never pay around a flag
Run the monitors after intake has stabilized the identifiers, and before indemnity leaves. Too early and you flag noise. Too late and you are documenting a paid duplicate.
Do not route around an open flag to keep a file in straight-through claims payment. Straight-through payment is a separate decision. A silent override so the check does not block the pipeline is how a known duplicate still gets paid. If a flag is open, payment waits. If SIU later vacates the flag, payment can resume under the usual authority. What you must not do is suppress the flag so a straight-through path can fire, or convert the flag into a silent down-weight on the indemnity offer.
The facts this check needs often arrive in pieces. FNOL gives parties and loss date. The estimate and photos arrive later. Medical bills arrive later still. Re-run the relevant monitor when those documents land, still writing facts and vintage, still leaving thin cells blank. A one-shot score at first notice will miss the photo set that shows up with the supplement, and it will miss the billing inconsistency that only exists once the medical bill is on file.
When SIU returns a result, write it back in the same language as the flag: confirmed, cleared, or insufficient. Do not replace that language with a new unlabeled score. The next person on the file should see the original cite, the investigation outcome, and nothing that looks like a made-up fraud rate.
The working test is simple. Could an SIU investigator, six months from now, open this claim and reconstruct why it was held, what was compared, and how old that comparison was? If yes, the detection did its job. If they find a badge and an empty vintage, the detection failed even if the eventual outcome on the claim was correct.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first