Insurance Fraud Detection Software Development: What to Build on Top of the Tools You Already Buy
Why a Red-Flag List Stopped Being Enough
In Verisk’s March 2026 study, 99% of insurers surveyed said they had encountered manipulated or AI-altered claim documentation, and 66% said digital media fraud often goes undetected. The cost was already high. Insurance fraud takes at least $308.6 billion a year in the US, and the Coalition Against Insurance Fraud puts fraud in about 10% of property and casualty (P&C) losses. In the last two years the shape of the fraud changed. A red-flag list written for staged accidents and padded invoices does not catch a receipt generated by an image model.
So the question a carrier faces in 2026 has shifted. Insurance fraud detection software development is now mostly a build-on-top decision: a scoring, reason-code, and routing layer over the industry data and vendor tools a carrier already licenses. In the US, most mid-size and larger carriers already have a claims database, a vendor scoring engine, or a rules module inside the claims core. The first decision is what to build on top of those tools and what to leave to them. The second decision is how to keep the result defensible when a regulator or a plaintiff’s lawyer asks why a claim was flagged. This article is for the claims technology lead or SIU head who owns both decisions.
What Insurance Fraud Detection Software Does Inside a Claims Organization
Insurance fraud detection software is a set of services around the claims core that scores every claim at first notice of loss (FNOL) and on each update. It explains each score with reason codes and routes suspect claims to the special investigation unit (SIU) before payment. The score compares the claim with the carrier’s own history and with industry data. Low scores pass to the adjuster, high scores go to the SIU with the evidence attached, and the middle band gets a targeted question before payment.
A score alone is a black box. Reason codes are what the adjuster acts on, what the investigator starts from, and what the carrier shows a regulator. Routing decides whether the score changes what gets paid. In the Coalition’s 2021 technology study of 80 insurers, only 39% got more than 30% of their fraud referrals from an automated system. At the other 61%, automation produced 30% or less, and most referrals still came from people on the claim. If the score never reaches the right desk, nothing changes on the floor.
The score and the reasons appear inside the claim file adjusters already work in. We cover the wider platform picture in our guide to custom insurance software development; this article stays on the decision layer: scoring, reasons, and routing.
Six Types of Insurance Fraud and the Layer That Catches Each
Fraud detection work is usually organized by fraud type, because each type leaves a different trace and needs a different detection method. The right-hand column points to the four layers described in the next section.
The Four Detection Layers, and the Loop That Makes Them Work
Rules are deterministic checks. A claim filed within days of policy inception, prior claims at the same address, a provider on a watch list, a repair estimate above the vehicle’s value. Rules are cheap, and a regulator can read them. They are also public knowledge to anyone who has worked in claims, so organized fraud is written to pass them. Rules are the floor, and they belong in your own code, under version control.
A model trained on the carrier’s own labeled history: claims the SIU investigated and how each one ended. Gradient-boosted trees are still the most common choice for tabular claim data. They handle mixed fields, and they give a ranked list of what drove the score, which an investigator can read. The model’s ceiling is the label quality. A carrier whose SIU outcomes live in free-text notes has no training set until someone builds one.
Fraud rings show up as a graph across claims rather than inside any one claim. The trace is the same body shop, attorney, clinic, or phone number across claimants who look unrelated one at a time. Graph features measure that: how many claims an entity touches, and how central it is to a cluster. In a 2025 study of its own model, CLARA Analytics ran an unsupervised approach over 2,867 P&C claims from 2020 to 2024, mapping provider and attorney connections. Its flags tracked the referrals adjusters later made, some of them two weeks after FNOL. Most mid-size carriers have never built this layer.
Metadata checks, image provenance, duplicate detection across the carrier’s own archive, and classifiers trained to spot generated or edited receipts, estimates, and photos. This layer was optional in 2023. In Verisk’s 2026 study, 76% of insurers surveyed said AI-altered submissions became more sophisticated in a single year. Its workload is now growing faster than any other layer’s.
Every SIU outcome has to flow back as a label: confirmed, cleared, inconclusive, with the reason. Without that loop the scoring model trains once and decays, and the rules never learn which flags produced nothing. The loop is a workflow and data-model decision, made in the case management design, long before anyone trains a model.
Build, Buy, or Assemble: Where Each Component Lands
No carrier builds all of this. The ones that buy all of it end up with a vendor’s view of their own book. The split that works has two halves. Buy the data you cannot collect yourself. Build whatever has to fit your products, your SIU, and your regulators. Verisk’s ClaimSearch, for example, holds more than 1.9 billion claim records contributed across the US industry; no carrier replicates that. A carrier can own everything that happens after the match comes back.
The assembled stack is two or three vendor services (industry data, document forensics, sometimes a network platform) under a custom decision layer. The decision layer owns the rules, the model, the reason codes, the routing, the case workflow, and the audit log. It is the product, and it is the part the regulator reads, because it holds the decisions.
A wrong split shows up in two ways. A scoring engine that cannot see your claim fields produces alerts nobody trusts and a referral rate that never moves. Building what specialists sell produces a slower copy of their tool that is out of date in a quarter. Before switching from a vendor score to your own, benchmark both on a held-out quarter of claims.
Where the Data Comes From, and Where Projects Stall
Labeled SIU history is the training set: each investigated claim needs an outcome code, a reason, and dates. Most carriers have this in investigator notes and spreadsheets, which means a two-to-three-month labeling project comes before the build timeline. Budget for it. In AML work, a few hundred cleanly coded outcomes are usually worth more than thousands of ambiguous ones. (The survey figures above: FRISS, March 2024.)
The claims core holds loss date, report date, policy inception, coverage, claimant and provider identifiers, payment history, and adjuster notes. Most projects stall on these fields. The claims core does not store what the model needs in the form the model needs it, and closing that gap consumes most of the integration budget. Free-text notes need extraction before they are features.
ClaimSearch matches, NICB referrals, state fraud bureau data, and provider registries, plus contextual feeds such as weather at the loss location, telematics, and public records. These arrive as match results, and the value is in how a match is weighted against the carrier’s own signals, which is a modeling decision. Each external feed also needs a contract and a privacy review, and the score has to work when the feed is down.
File metadata, hashes, duplicate matches across the archive, and forensic classifier outputs. This is new data for most carriers, and it needs its own storage and retention rules, because it is evidence.
ZIP code, name patterns, and the language of the submission all proxy for protected classes. Each one is either excluded or kept with a written justification and a proxy-impact test on record. The test is whether the flag rate differs by protected class once the legitimate signal is controlled for. That list is what an examiner asks for first. The same list applies to KYC and AML systems, where the monitoring model faces the same test.
What Regulators Ask of a Fraud Model
A fraud score is an automated assessment of a consumer. Where it influences a denial, it becomes a decision that regulators now scrutinize. The NAIC’s Model Bulletin on the Use of AI Systems by Insurers is adopted in 29 jurisdictions as of October 8, 2026. That is 27 states plus the District of Columbia and Puerto Rico. In adopting jurisdictions, the bulletin expects a written AI program covering governance, risk management, and third-party vendor oversight, and it places the obligation on the carrier. Under the bulletin, buying a vendor’s scoring engine does not move the documentation duty to the vendor.
Four states run their own guidance instead, and two of them matter most here. New York’s Insurance Circular Letter No. 7 (July 2024) formally covers only underwriting and pricing. We treat its tests as the sensible bar anyway, because nothing claims-specific has replaced them. Test for disproportionate adverse effects before production and at least annually. Keep an inventory of AI systems. Never cite a vendor’s proprietary algorithm as the reason a specific explanation cannot be given.
Colorado’s replacement AI law, SB 26-189, signed May 14, 2026, and effective January 1, 2027, excludes most fraud-prevention technology from its definition of a consequential decision. On our reading, the exclusion ends once the score materially influences a claim denial. That boundary, not the statute, is the design constraint. For EU carriers, the AI Act lists risk assessment and pricing in life and health insurance as high-risk. The Commission’s draft classification guidelines (May 2026) offer no fraud exclusion there. Under the draft guidelines, the clearest route out is a fraud system kept separate from pricing and risk assessment, with its own documented purpose. Our EU AI Act guide covers the timeline.
The litigation record shows what a court asks once an automated score sits in the denial path. In the Medicare Advantage case over UnitedHealth’s nH Predict tool, a Minnesota federal court ordered discovery in March 2026. The order covers how the algorithm works and how the insurer oversaw its use. The class action over Cigna’s PxDx process is still pending. It rests on ProPublica’s report of more than 300,000 denials in two months of 2022, at an average of 1.2 seconds of review each. Neither is a fraud model, and both sit in health, where review decisions touch care. They are the closest litigation analog so far: how the score works, who oversaw it, and whether a person reviewed the file.
Every score ships with reason codes a human can read, and every threshold change is versioned with an approver. Proxy features stay on the exclusion list described above, or carry their written justification. A high score routes to a person; the system itself never issues a denial. And the vendor contract gives the carrier audit rights over any model it did not build.
[DRAFT, awaiting Timur’s approval] A fraud model has one job: put the right claims in front of an investigator earlier than they would have found them. The moment it starts deciding outcomes, you have built a liability, not a detection system. We design the routing before we design the model.
Timur Iusubaliev, COO, Plus8Soft
What AI Changes in Fraud Detection, and What It Only Makes Costlier
The measurable gain is time. Claims that an adjuster would refer months into the claim get flagged in the first weeks, before the reserve is set and before the payment goes out. A model reads every claim on day one; no adjuster can.
Classifiers for edited and synthetic images are the only practical answer to AI-altered submissions. Buy them, then benchmark them on your own archive every quarter, because detectors trained on last year’s generators lose accuracy on this year’s.
Large language models summarizing a 300-page claim file, extracting entities from adjuster notes, and drafting the referral narrative save SIU hours. Keep them inside the investigator’s workflow, with the source documents one click away, and keep their output out of the score.
Unsupervised anomaly detection with no outcome loop produces a queue of unusual claims and no way to learn which ones mattered. Within a year the SIU stops reading it. Any design where the model’s output ends a claim invites the discovery order the UnitedHealth case shows, years later.
Integration With the Claims Core
The decision layer is only useful inside the claim file. The integration that survives contact with a claims core is event-driven. The claims core emits an event at FNOL and on every material update: new document, new party, reserve change, payment request. A scoring service consumes the event and enriches the claim with industry matches and external data. It runs rules, model, and graph features, then writes back a score, reason codes, and a routing recommendation. Batch re-scoring runs nightly for claims whose context changed because another claim did.
Guidewire, Duck Creek, and Majesco all expose claims APIs; Guidewire also publishes app events for event-driven integration. Its marketplace already carries vendor fraud add-ons, a useful reference for the data contract even when the decision layer is custom. For a carrier on a home-grown core, the first deliverable is often the event stream itself.
Teams postpone the audit log, the feedback path, and access control, and all three are expensive to retrofit. The audit log is one immutable record of every score, reason, routing decision, and threshold change across vendor and custom components. The feedback path writes SIU outcomes back to the training store with the identifiers the model used. Access control covers investigator evidence, forensic outputs, and model features, which hold personal data and need the controls in our DevSecOps guide from the first sprint.
The training side is the commodity part. Our open-source AML training pipeline shows the shape. Graph features (in and out degree, PageRank, running totals per party) and correlation filtering feed three tree-ensemble candidates: Random Forest, XGBoost, LightGBM. They are ranked on ROC-AUC with PR-AUC as the tiebreak, and the winner is saved with its metrics. With a claims schema in place of the transaction one, that is the training core. Real-time scoring, the investigator workflow, and the integration are the engagement work on top.
How the Build Runs: Six Stages
Two to three weeks on the claims data dictionary, the SIU history, the vendor tools already licensed, and the regulators the carrier answers to. The output is the build-or-buy split and the labeling estimate.
Two to three months if SIU outcomes live in free text: a labeling tool, a sampling plan, and coded outcomes for a few hundred investigated claims per line of business.
The versioned rules engine, the event stream from the claims core, and the immutable audit log, delivered before any model, so the SIU has something to work with in the first quarter.
One line of business, reason codes in the claim file, the proxy-impact test on record, and thresholds signed off by the SIU head.
One quarter beside the existing vendor score or the adjusters’ own referrals, measured on referral-to-confirmed ratio. The shadow run decides what goes live and at which threshold.
Routing switched on, the feedback loop writing outcomes back, quarterly threshold reviews, and the documentation the NAIC bulletin asks for, kept current from day one.
What Insurance Fraud Detection Software Costs to Build
Three build tiers, plus the ongoing cost, cover the scopes carriers ask for. Each assumes the carrier licenses industry data (ClaimSearch or the national claims database in its market) separately and already runs a claims core with an API. Figures are indicative, before discovery, for a nearshore or offshore team; a fully US-based team typically runs 2 to 2.5 times higher. Timelines assume a coded SIU history exists; add two to three months for the labeling project if it does not.
Published agency estimates ($200,000 to $800,000 and up over 9 to 15 months or more) overlap our middle tier. Maintenance runs lighter than on AML systems, where sanctions lists and filing formats change every year. The two line items that most often blow a budget are the labeling project at the start and the claims core integration. Both are visible in week one of discovery if anyone looks. For a number tied to your lines, data, and core, use our project calculator, or send us the claims data dictionary and SIU outcome fields. The first step with us is a scoping call on those two documents. It normally ends with the build-or-buy split and the labeling estimate.
Choosing a Development Partner for Fraud Detection
A team that has done this describes how a score is explained to an adjuster, an investigator, and a regulator, in that order. Only then does it describe which algorithm produces the score.
A credible answer names the labeling tool and the sampling plan, with dates. If they assume the training data exists, they have not done this before.
The exclusion list for protected-class proxies, the written justification for anything kept, and the proxy-impact test they run before go-live. A partner who starts from the exclusion list understands the regime.
Industry data, forensic classifiers, and graph platforms get swapped. A team that has run two vendors side by side on a carrier’s own archive, and replaced one without a scoring gap, has done the hard version of the job.
Ours is public: the AML training pipeline is the same graph-feature and tree-ensemble core we would point at your claims. Our hands-on fraud work so far is in fintech risk and AML, including the compliance build for FundingPips and our AI integration engagements. The claims-core integration, reason-code, and labeling patterns in this article come from those builds and from Guidewire’s published data contracts. This article does not draw on a named carrier engagement. Our fintech practice and dedicated teams pages list the other builds.
Insurance Fraud Detection Software Development: FAQ
It scores every claim at FNOL and on each update, using rules, a model trained on the carrier’s investigated claims, graph features across claimants and providers, and document forensics. Each score carries reason codes. Routing sends high scores to the SIU with the evidence attached, and the SIU’s outcome flows back as a training label.
Indicative, before discovery, for a nearshore or offshore team: a rules and scoring layer on an existing claims core runs $120,000 to $250,000 over 4 to 6 months. A full decision layer with network analysis, case management, and a feedback loop runs $250,000 to $600,000 over 6 to 12 months. Multi-line platforms with real-time scoring and document forensics start around $600,000. Industry data licenses are separate, and maintenance runs 15% to 25% of build cost per year.
Usually both. Vendors are strong on industry data, generated-media detection, consortium patterns a single book never sees, and a fast start when no labeled history exists. The rules, the model trained on the carrier’s own book, the reason codes, the routing, and the audit log are better owned. They carry the regulatory documentation duty, and they encode how that carrier’s SIU works. The build-or-buy table above splits it by component.
Less than most teams expect, and cleaner. A few hundred investigated claims with coded outcomes support a first supervised model for one line of business, with heavy regularization and a rules floor underneath it. Unlabeled claims support anomaly and link analysis only, and those flags need the same outcome loop to be worth anything. If the SIU history lives in free text, plan a labeling project of two to three months before training.
Three levers. A feedback loop, so the model learns which flags produced nothing. Thresholds tuned per line of business and reviewed quarterly. Routing that sends medium scores to a targeted question before any SIU referral. The metric that matters is the referral-to-confirmed ratio.
In practice, yes. The NAIC bulletin, adopted in 29 jurisdictions as of October 2026, puts the documentation duty on the carrier. In states that have adopted the bulletin or their own AI guidance, a score that influences a denial is likely to be examined as an automated decision. Reason codes per score, a written feature exclusion list, and versioned thresholds are the minimum.
The architecture is the same; the data and the rules differ. Health fraud is mostly provider billing (upcoding, unbundling, phantom services), so provider graph features and claims-line analysis do most of the work. In P&C the loss event is the unit, which puts the weight on document forensics, staged-event rules, and claimant networks. The regulatory exposure is higher in health, where automated denial litigation is already active.