DEV Community

Vishal Kumar
Vishal Kumar

Posted on

Building Fraud Detection That Separates Flagging From Acting

The number that should make you slow down, not speed up

Healthcare fraud costs the U.S. somewhere between 3% and 10% of total healthcare spending, according to the National Health Care Anti-Fraud Association — at the high end, more than $300 billion a year. A more conservative estimate from the Coalition Against Insurance Fraud puts it around $105 billion annually. Either way it's a huge number, and it's part of why 35% of insurance executives now rank fraud detection among their top AI investment priorities (Deloitte, 2025).

The instinct that number produces is "move fast, automate the response." I think that's backwards, and here's the architecture argument for why.

The asymmetry a lot of fraud-detection systems ignore

A missed fraud case is a cost. A false fraud accusation against a legitimate provider is a different kind of event entirely — reputational damage, a payer relationship at risk, potentially a legal dispute, and it burns your credibility the next time you flag something real. Those failure modes aren't symmetric. A system that treats "flag and act" as one atomic operation is implicitly treating a false positive and a false negative as equally costly. They're not, and pretending they are is what leads teams to over-trust automation on exactly the decision where they shouldn't.

Also worth naming: legitimate providers can look anomalous for entirely legitimate reasons — a sicker patient population, an unusual specialty mix, a billing pattern the model just hasn't seen enough of. Anomaly ≠ fraud, and a model trained mostly on "normal" billing patterns will find a lot of statistically unusual, perfectly legitimate providers.

The architecture: separate flagging from acting

This isn't an argument for slower detection — detection can and should run in real time on every claim. It's an argument for a hard boundary between scoring and acting:

  • Scoring — every claim gets a fraud-risk score continuously. Fast, automated, no human bottleneck.
  • Tiering — only the highest-risk tier gets held for review. Everything else flows through normally.
  • Human review before action — a person sees the case, the evidence, and the model's reasoning before payment is held, a provider is notified, or an investigation is triggered. The model doesn't get to unilaterally do any of those things.
  • Append-only audit log — what was flagged, what evidence the model cited, who reviewed it, what they decided, and when. Not editable after the fact. If a decision is ever challenged, there's an actual record of who saw what.

The failure mode to design against isn't "too slow to catch fraud" — real-time scoring solves that. It's "acted on a wrong flag with nobody in the loop," which is a much harder mistake to walk back.

Why this matters more here than almost anywhere else in healthcare AI

We build governed agents across claims, prior auth, denials, and fraud detection at IntelliBooks Studio, and fraud is the one domain where we push hardest against full automation — not because detection quality is the problem, but because the cost of being wrong is so lopsided. Happy to get into the scoring-vs-tiering design or the audit-log schema in the comments if useful.

Top comments (0)