Production-Grade Fraud Pattern Detection for Insurance Claims

Insurance fraud is not a single event to catch but a continuous signal to score. Staged accidents, inflated repair invoices, phantom passengers, duplicate first-notice-of-loss (FNOL) submissions, and organized provider rings all leave statistical residue in the same claims data your pipeline already handles — but that residue is faint, adversarial, and expensive to misread in either direction. For the InsurTech engineers, SIU analysts, and compliance officers who build these systems, fraud detection is best understood as an engineering domain layered on top of the claims pipeline: a fraud-scoring service that consumes the same event stream as triage, runs several complementary detectors in parallel, fuses their outputs into a single governed score, and refers suspicious claims to human investigators without ever auto-denying a payout. This section frames that architecture and routes into the focused implementation guides for each detection engine. It sits alongside the Claims Triage & Routing Engines, Policy PDF Parsing & Extraction Workflows, and Core Architecture & Compliance Mapping sections; together those areas describe the full path from an inbound claim to an adjudicated, auditable, and defensible decision.

The most consequential architectural decision in claims fraud detection is what the system is allowed to do with a suspicious claim. A fraud scorer that can automatically deny or delay a payout is a legal and reputational liability: it exposes the carrier to bad-faith and unfair-claims-settlement claims, it discriminates in ways that are hard to audit, and it makes an irreversible decision on a probabilistic signal. Production systems therefore treat fraud detection as a referral layer rather than an adjudication gate. The scorer’s only output authority is to route a claim to human investigators — the Special Investigations Unit — with an explained, evidence-backed rationale. Payment decisions remain with adjusters and the SIU, governed by the same Claims Lifecycle Architecture that manages every other state transition on the platform.

This framing has a direct engineering consequence: the fraud score is a peer signal, not a superseding one. It rides alongside the Automated Severity Scoring Models that triage already computes, sharing the same feature substrate but answering a different question. Severity asks “how large and urgent is this loss?”; fraud asks “how likely is this loss to be misrepresented?” A high-severity, low-fraud claim wants a senior adjuster fast; a low-severity, high-fraud claim wants a quiet SIU review before any payment. Fusing these signals at the routing layer — rather than letting one overwrite the other — is what keeps both objectives legible.

The scorer consumes the same event stream that drives triage. When a claim reaches a scorable state, the triage pipeline publishes an event; the fraud-scoring service subscribes to it exactly as the severity and assignment engines do. This shared-substrate design avoids a second ingestion path, guarantees the fraud score sees the same canonical policy and claim data everyone else does, and means fraud scoring inherits the platform’s existing durability, replay, and audit guarantees rather than reinventing them.

The fraud-scoring service is an event consumer that turns one inbound scored claim into one composite fraud score plus, when warranted, one SIU referral. Internally it is organized as a fan-out/fan-in fabric: feature assembly first, then several detectors running in parallel, then score fusion, then a referral gate, with an append-only audit tap on every stage.

Every detector operates on the same assembled feature vector, built once per claim so that expensive joins are not repeated three times. Feature assembly pulls the FNOL narrative and structured fields, the bound policy (limits, deductibles, effective dates, endorsement history) produced upstream by the Policy PDF Parsing & Extraction Workflows pipeline, and the party graph — claimant, insured, providers, repair shops, attorneys, and their prior-claim history. Assembly is where derived features live: days from policy inception to loss, claim amount as a multiple of the historical mean for that peril and geography, submission velocity for the claimant over a rolling window, and normalized text fingerprints of the loss description used later for duplicate detection.

Because these features reach across regulated data, assembly is also where data-boundary discipline is enforced. Party identifiers, contact details, and financial fields are handled under the field-level controls described in Data Boundary Enforcement: PII used for matching is tokenized or hashed where possible, sensitive attributes that could drive disparate impact are excluded from model inputs, and every read is scoped to the tenant and jurisdiction that owns the claim.

No single technique catches insurance fraud, because fraud is not one phenomenon. Production systems run several detectors whose failure modes are uncorrelated, so that a fraud pattern invisible to one engine is caught by another. Three families cover most of the operational surface:

• A statistical anomaly detector flags individual claims that sit far from the learned distribution of legitimate claims — an implausible repair cost for the vehicle, a loss reported within days of policy inception, a submission velocity that no honest claimant produces. This is the domain of Statistical Anomaly Scoring.
• A duplicate detector catches the same loss submitted more than once — resubmitted FNOLs, the same damage claimed across two policies, or an incident recycled with lightly edited details. Exact keys miss these; fuzzy matching over normalized fields is required, as covered in Duplicate Claim Detection.
• An entity-network detector surfaces the organized fraud that per-claim scoring cannot see: rings of claimants, providers, and vehicles that co-occur across many claims in statistically improbable ways. Modeling claims as a graph and scoring its structure is the work of Entity Network Analysis.

The detectors are isolated by cost and blast radius, exactly as extraction pools are in the parsing pipeline. Anomaly scoring is CPU-light and runs inline. Duplicate detection is memory- and index-bound. Network analysis is the most expensive — graph queries and community detection over a large, evolving graph — and is often computed on a slight delay against a materialized graph rather than synchronously. Running them in parallel means the composite score is available at the latency of the slowest required detector, and a detector that degrades or times out fails open (see the error taxonomy below) rather than blocking the claim.

Each detector emits a normalized signal in the range 0–1 with an explanation, not a raw model output. Score fusion combines these into a single composite fraud score, typically a governed weighted combination with a hard-override channel: some signals (a confirmed duplicate of an already-paid claim, a claimant on a sanctions list) should dominate regardless of the others. The weights are configuration, not code — versioned, auditable, and retuned by the calibration loop — because the relative value of each detector drifts as fraudsters adapt.

The threshold that decides which claims cross the referral gate is the single most important tuning parameter in the system, and it is governed by an asymmetry that must be made explicit rather than left implicit in a model’s default cutoff. The two errors have radically different costs and different victims.

A missed fraud — a fraudulent claim scored below threshold and paid — costs the indemnity amount plus the downstream cost of a fraud ring that learns the carrier is soft. A false positive — an honest claim referred to SIU — costs investigator hours, delays a legitimate payout, and, if handled clumsily, damages the customer relationship and risks an unfair-claims-settlement complaint. Crucially, the false-positive cost is not a denial: because the scorer only refers, a false positive is a review that clears the claimant, not a wrongful denial. That is precisely why the fail-open, refer-only design is defensible — it caps the downside of a false positive at investigative overhead rather than a wrongful outcome.

The right operating point is therefore not “maximize accuracy” but “set the referral threshold where the marginal investigator hour is worth the marginal fraud caught,” subject to SIU capacity. This is a capacity-constrained decision: SIU throughput is finite, so the threshold is often tuned to keep the referral rate near the volume investigators can actually work, and the detectors are ranked by precision@k on confirmed-fraud labels so that the most likely fraud fills that fixed capacity first. Calibrating this cutoff against historical loss and confirmed-fraud outcomes is a continuous exercise, closely analogous to the Dynamic Threshold Tuning that governs triage cutoffs — and, like those thresholds, it is environment-driven and carrier-overridable rather than a hardcoded constant.

A single referral threshold treats fraud as binary — refer or don’t — but the composite score is continuous, and collapsing it to one cutoff wastes information at both ends. Production systems tier the response so that the strength of the signal matches the cost of the action it triggers, exactly as triage routes claims to different handling paths by severity rather than to a single queue.

At the low end, claims well below the referral threshold proceed through normal handling untouched, but their scores are still recorded — they are the negative labels that calibration and fairness testing need. In the middle band, claims that are elevated but not conclusive are routed to a lightweight desk review: an adjuster is prompted to verify a specific flagged detail (a suspicious inception-to-loss gap, an unusually round repair estimate) before payment, without opening a full investigation. Only claims that clear the top threshold, or that trip a hard override, become full SIU referrals with an investigator assigned. This tiering keeps the most expensive response — a human investigation — reserved for the strongest signals, and it lets the desk-review band absorb the large population of ambiguous claims that would otherwise either flood SIU or leak through unexamined.

The tier boundaries are configuration, versioned alongside the fusion weights, and they are the primary lever for matching referral volume to SIU capacity. When investigators are backlogged, raising the SIU threshold shifts marginal claims into desk review rather than dropping them; when capacity opens up, lowering it pulls more borderline claims into full investigation. Because both boundaries are audited and both bands are labeled by outcome, the calibration loop can measure the precision of each tier independently — a desk-review band whose confirmed-fraud rate approaches the SIU band’s is a signal to lower the SIU threshold, while an SIU band whose rate collapses toward the desk band’s means the top cutoff has drifted and needs retuning.

A fraud model that influences claim handling is a regulated decision system in every U.S. jurisdiction, and its governance obligations shape the architecture as much as its detection accuracy does. Three constraints dominate.

Fair-claims-settlement and adverse-action rules. Because a referral can delay a payout, it brushes against unfair-claims-settlement-practices statutes that require prompt, good-faith handling. The refer-only design keeps the carrier compliant by ensuring no automated system denies a claim, but the referral itself must be timely and documented. Where a fraud signal ever contributes to an adverse action against a consumer, the carrier may owe an adverse-action notice with specific reasons — which is impossible to produce from an unexplainable model. Jurisdiction-specific handling requirements are mapped through State Regulation Mapping, since what counts as a permissible delay and a required disclosure varies by state DOI.

Disparate impact. A model trained on historical fraud labels will happily learn proxies for protected classes — ZIP code, surname patterns, provider networks that correlate with ethnicity — and reproduce discriminatory referral rates even though no protected attribute is an explicit input. Governance requires testing referral rates across protected groups, excluding proxy features that fail a fairness screen, and monitoring for drift in group-level referral rates over time. This is not optional diligence; it is the difference between a defensible SIU program and a regulatory finding.

Explainability. Every referral must carry a human-readable rationale — the specific signals and feature values that drove the score — for three audiences: the SIU investigator who needs a starting point, the compliance officer who must defend the referral, and the regulator who may audit it. This constraint pushes the design toward inherently explainable detectors (anomaly scores traceable to specific features, duplicate matches traceable to the matched claim, network signals traceable to the ring) and away from opaque end-to-end models whose outputs cannot be decomposed.

Governance does not end at deployment. Any change to a detector, a fusion weight, or a tier boundary is a model change subject to review before it can affect live referrals. Production programs run new configurations in shadow mode first: the challenger scores the same live claims as the incumbent but its referrals are recorded rather than acted on, so its precision@k and group-level referral rates can be compared against the incumbent on identical traffic before any switch. A challenger is promoted only when it improves precision without worsening disparate impact, and every promotion is an audited configuration-version bump — the same version that later stamps each decision record. This champion-challenger discipline is what lets a team retune aggressively against an adapting adversary without ever shipping an unvalidated, unexplainable, or discriminatory change into the payment path.

The contract between detectors and the fusion stage is a small, explicit structure. Each detector returns a FraudSignal carrying its normalized score, its confidence, and — non-negotiably — the human-readable reasons and the feature evidence behind it. Fusion combines signals into a composite, records the decision, and never decides more than “refer or not.”

Copy
from __future__ import annotations

from dataclasses import dataclass, field
from decimal import Decimal
from enum import Enum

import structlog

log = structlog.get_logger("fraud.fusion")


class Detector(str, Enum):
    ANOMALY = "statistical_anomaly"
    DUPLICATE = "duplicate_claim"
    NETWORK = "entity_network"


@dataclass(frozen=True)
class FraudSignal:
    """One detector's contribution to the composite score."""
    detector: Detector
    score: float                 # normalized 0.0–1.0
    confidence: float            # 0.0–1.0; low confidence dampens weight
    reasons: tuple[str, ...]     # human-readable, for the referral rationale
    evidence: dict[str, str] = field(default_factory=dict)
    hard_override: bool = False  # e.g. confirmed duplicate of a paid claim

    def __post_init__(self) -> None:
        if not 0.0 <= self.score <= 1.0:
            raise ValueError(f"score out of range: {self.score}")
        if not 0.0 <= self.confidence <= 1.0:
            raise ValueError(f"confidence out of range: {self.confidence}")


@dataclass(frozen=True)
class FusionConfig:
    weights: dict[Detector, float]
    referral_threshold: float          # composite score gate
    carrier_id: str
    config_version: str                # versioned, auditable


@dataclass(frozen=True)
class FraudDecision:
    claim_id: str
    composite_score: float
    refer_to_siu: bool
    signals: tuple[FraudSignal, ...]
    rationale: tuple[str, ...]
    config_version: str


def fuse_signals(
    claim_id: str,
    signals: tuple[FraudSignal, ...],
    cfg: FusionConfig,
) -> FraudDecision:
    """Combine detector signals into one governed, refer-only decision.

    Never denies or delays a payout — its sole authority is to refer to SIU.
    """
    if any(s.hard_override for s in signals):
        composite = 1.0
    else:
        weighted = 0.0
        total_weight = 0.0
        for s in signals:
            w = cfg.weights.get(s.detector, 0.0) * s.confidence
            weighted += w * s.score
            total_weight += w
        composite = weighted / total_weight if total_weight else 0.0

    refer = composite >= cfg.referral_threshold
    rationale = tuple(r for s in signals for r in s.reasons)

    decision = FraudDecision(
        claim_id=claim_id,
        composite_score=round(composite, 4),
        refer_to_siu=refer,
        signals=signals,
        rationale=rationale,
        config_version=cfg.config_version,
    )

    log.info(
        "fraud_scored",
        claim_id=claim_id,
        carrier_id=cfg.carrier_id,
        composite_score=decision.composite_score,
        refer_to_siu=refer,
        threshold=cfg.referral_threshold,
        config_version=cfg.config_version,
        detectors=[s.detector.value for s in signals],
        hard_override=any(s.hard_override for s in signals),
    )
    return decision

Note the invariant encoded in the type itself: a FraudDecision has a refer_to_siu boolean and a rationale, but no field that could deny, delay, or reduce a payout. The scorer’s authority is bounded by its data model. Currency-bearing evidence uses Decimal, never float, so that a claim amount surfaced as evidence in a referral is exact.

A fraud-scoring system that cannot reconstruct why it referred a specific claim eighteen months ago is indefensible. Every scored claim — referred or not — produces an append-only audit record, and every referral produces an additional, richer one. A complete record captures the claim identifier and version, each detector’s normalized score and confidence, the exact reasons and feature evidence, the composite score, the referral threshold and configuration version in force, the fusion weights applied, and a UTC timestamp. Records are chained: each entry references the hash of the prior entry, so any retroactive edit is detectable, which is exactly the tamper-evident structure detailed in Audit Log Schema Design.

This audit trail does double duty. For compliance, it lets an officer answer “why was this claimant referred, and was that referral consistent with how we treated similar claims?” with specific evidence rather than a shrug. For governance, the same records are the labeled substrate for fairness testing and calibration: joining referral records against confirmed-fraud outcomes is how precision@k and group-level referral rates are computed. The regulatory sync that keeps the underlying rules current — updated fair-claims-settlement provisions, new mandatory disclosures — flows through the Regulatory Sync Pipelines that version those obligations, so the audit log can always be interpreted against the rules that were actually in force when a decision was made.

Fraud detection degrades silently and adversarially. Fraudsters adapt to whatever the model catches, so a detector that performed well last quarter can quietly rot without any code change — the world changed, not the code. Observability therefore centers on a handful of signals that surface degradation before it becomes a loss.

Score drift. The distribution of composite fraud scores, tracked per carrier and per detector over time, is the earliest warning. A leftward shift means the detectors are finding less signal — possibly because fraud moved to a pattern they do not model. A rightward shift means either a genuine fraud surge or a broken feature (a join returning nulls that read as anomalies). Either way, a distribution alert fires before any individual decision is provably wrong.

Precision@k on confirmed-fraud labels. Because SIU capacity is fixed, the metric that matters is not overall accuracy but the precision of the top-k referrals: of the k claims the system was most confident about, how many did investigators confirm as fraud? This is measured by joining referral records against SIU outcomes once investigations close, and it is the primary input to calibration. A falling precision@k means the system is spending investigator hours on false positives and the threshold or weights need retuning.

Referral-rate monitoring by group. As governance requires, referral rates across protected groups are tracked continuously; a divergence triggers a fairness review, not just an accuracy review.

These signals feed the calibration loop drawn in the overview diagram. Confirmed-fraud outcomes flow back from investigators, precision@k and drift are recomputed, and detector weights and the referral threshold are retuned — a closed loop that keeps the system tracking a moving adversary rather than a fixed one. The full mechanics of turning outcomes into thresholds live in SIU Referral Orchestration.

The governing principle of fraud-scoring resilience is unusual: when the scorer fails, it must fail open. A claim that cannot be scored — because a detector timed out, the graph store was unavailable, or feature assembly hit a missing dependency — must proceed through normal claims handling, not be blocked. Blocking a payout because a fraud detector crashed is exactly the unfair-claims-settlement exposure the whole design exists to avoid. Failures are categorized so the system knows which response each one warrants.

Recoverable transient faults include timeouts to the graph store, rate-limited enrichment APIs, temporary broker disconnects, and slow feature joins. These warrant bounded retry with exponential backoff and jitter, governed by a per-claim scoring budget. If the budget is exhausted, the missing detector fails open: fusion proceeds with the signals it has, records that a detector was unavailable, and the claim is scored on partial evidence rather than held. A degraded score is explicitly flagged so that a later re-score can run when the dependency recovers.

Fatal scoring faults are properties of the input: a claim missing the canonical fields feature assembly requires, a malformed party graph, or a configuration version that no longer exists. Retrying these is waste. They route to a dead-letter queue with full diagnostic context — the claim reference, the exception chain, the stage and detector that failed, and the configuration version in force — so an engineer can reproduce the failure and an analyst can decide whether the claim needs manual fraud review. A burst of the same fatal fault from one carrier usually indicates an upstream contract change, not a scoring bug.

Silent-degradation faults are the most dangerous because nothing errors. A feature that quietly starts returning defaults, a detector whose model file loaded stale — these produce plausible-looking wrong scores. The score-drift and precision@k observability above is the only defense: silent degradation is caught statistically, in aggregate, not per claim.

This section breaks fraud scoring into four focused implementation guides, each owning one part of the fabric from feature vector to SIU referral.

Statistical Anomaly Scoring covers the per-claim detector — learning the distribution of legitimate claims and flagging the ones that sit far outside it. It walks through isolation forests for outlier claim amounts, velocity checks for rapid-fire submissions, feature normalization that keeps scores comparable across perils and geographies, and the calibration that turns a raw anomaly score into a governed 0–1 signal with an explanation.

Duplicate Claim Detection handles the same loss submitted more than once. It covers normalized field fingerprints, fuzzy matching of FNOL submissions with rapidfuzz, blocking strategies that keep pairwise comparison tractable at volume, and the hard-override path that fires when a claim duplicates one already paid.

Entity Network Analysis models claims as a graph of claimants, providers, vehicles, and addresses to surface organized rings that per-claim scoring cannot see. It covers building claim-provider graphs with networkx, community detection and centrality signals that flag improbable co-occurrence, and turning graph structure into an explainable, per-claim fraud contribution.

SIU Referral Orchestration is where the composite score becomes an action. It covers scoring claims against capacity-aware referral thresholds, the append-only referral audit record, routing referrals into the SIU workflow with their rationale attached, and closing the calibration loop by feeding confirmed-fraud outcomes back into threshold and weight tuning.

Fraud scoring is one signal in a larger decision system, not a system of its own. It consumes the same triage event stream that computes severity, so its output rides alongside the Automated Severity Scoring Models into the routing layer, and it depends on the structured policy and party data produced by the Policy PDF Parsing & Extraction Workflows upstream. Treating fraud detection as a governed, refer-only layer over the existing pipeline — sharing its data, its audit fabric, and its observability — rather than a bolt-on gate is what lets InsurTech teams catch organized and opportunistic fraud without trading away the fair-claims-settlement compliance, explainability, and customer trust that make a claims operation defensible.

• Statistical Anomaly Scoring — per-claim outlier and velocity detection with explainable scores
• Duplicate Claim Detection — fuzzy matching that catches resubmitted and cross-policy FNOLs
• Entity Network Analysis — graph modeling that surfaces organized fraud rings
• SIU Referral Orchestration — capacity-aware thresholds, referral audit, and the calibration loop
• Automated Severity Scoring Models — the peer signal fraud scoring rides alongside at routing
• Data Boundary Enforcement — PII handling for the party data fraud scoring consumes