Insurance claims fraud detection

Fraudulent and inflated claims raise premiums for every policyholder, yet most claims are honest and should be paid fast. AI scores every claim at first notice of loss and again as documents arrive, combines tabular models, network analysis and document forensics, and hands only the small suspicious fraction to trained investigators with an explanation. The goal is twofold: catch more fraud per investigator-hour and stop treating honest customers as suspects.

Problem & value

• Today: rule engines ("claim within 30 days of inception", "known garage") plus adjuster intuition and a special investigation unit (SIU, Special Investigations Unit / Betrugsabwehr) working a few referred cases. Rules generate many false positives and miss organised, multi-party schemes (staged accidents, provider fraud, "ghost" claimants, inflated repair invoices).
• AI value: (1) better prioritisation of SIU time, (2) detection of linked claims across people/vehicles/addresses/providers, (3) detection of manipulated evidence, which generative AI has made cheap, (4) straight-through processing for the clearly honest majority.
• Sourced vendor-reported figures (not independent): FRISS states its Claims Analytics gives 75% fewer false positives and 90% of honest claims fast-tracked (no baseline stated), and cites UNIQA reporting about USD 21 million fraud savings in its first two years live, with savings per investigator rising from USD 550,000 to USD 2 million [1]. Shift Technology reports 120+ customers in 30+ countries and 4B+ policies, claims and documents analysed [2]. Treat these as marketing claims; measure your own baseline.
• Scope boundary: this entry covers P&C, motor, property, travel and life/accident claims at insurers. Health-insurance billing fraud by providers is ANOM-007; forged supporting documents in general is ANOM-017; APP scams and mule accounts are ANOM-022.

Variants

• Motor claims: staged and induced accidents, repair-invoice inflation, vehicle-identity fraud, fictitious theft; photo forensics plus garage/expert network analysis.
• Property and household: inflated contents lists, duplicate claims across insurers, arson indicators, falsified invoices.
• Bodily injury / liability: repeat claimants, claims-farming networks, medical report patterns.
• Application ("underwriting") fraud and premium leakage: the same scoring applied at quote/renewal (FRISS markets one score across quote, renewal and claim [1]).
• Industry data pools: claim-history exchanges (e.g. national insurer databases such as the German HIS of informa HIS, US Verisk ClaimSearch) as additional signals; access is legally restricted.
• Private use: none as a use case; consumers only meet it as the affected party (see Risks).

How it works

1. FNOL / claim intake (portal, app, phone transcript, broker)
2. ingestion + identity/entity resolution (person, vehicle, address, IBAN, provider)
3. document & media forensics (OCR, metadata, edit/AI-generation detection, duplicate-image search)
4. feature building (claim, policy, history, text-derived signals, external data)
5. scoring: supervised model (gradient boosting) + anomaly detection + rules
6. network analysis (entity graph, community detection, shared-attribute links)
7. LLM layer: summarise file, explain reasons, draft investigation plan
8. routing: fast-track | standard | SIU referral (human decision)
9. investigation outcome fed back as labels (confirmed fraud / cleared)

• Tabular models: gradient-boosted trees remain the workhorse; labels are scarce and biased (only investigated claims have outcomes), so semi-supervised and anomaly methods complement them.
• Graph analytics: claims, persons, phones, IBANs, garages and experts form a graph; shared attributes and dense clusters reveal rings that single-claim scoring cannot see.
• Document and image forensics: detect edited PDFs, reused or AI-generated damage photos; VLMs compare photo, estimate and narrative for consistency (see VIS-023, ANOM-017).
• LLM/agent layer: summarises long files, explains the score in plain language, proposes next investigative steps. It supports the investigator and must not decide.
• Human-in-the-loop: a score alone never leads to denial. A qualified claims handler or SIU investigator reviews the evidence, and the policyholder can contest (see Risks).

Data preparation

Data needed: claims records (first notice of loss, payments, adjuster notes), policy data, claimant and provider history, attached photos, invoices and reports, plus investigation outcomes as labels. They sit in the claims core system, a DMS, mail inboxes and with external experts or repairers. Typical gaps: confirmed-fraud labels are sparse and biased toward what was investigated, adjuster notes are free text with varying quality, attachments are scans or photos without metadata, the same party appears under several IDs, and health data requires strict access rights.

Preparation steps: unify party and claim identifiers (PREP-005, PREP-011), harvest labels from closed investigations (PREP-020), define fraud categories (PREP-019), OCR and index document attachments (PREP-006; see DOC-014), build an expert-reviewed test set (PREP-018) and pseudonymise training extracts (PREP-022). Clean access rights before any assistant touches claim files (PREP-023). See DATA-003.

Rough share of effort: 50-60 percent of the project.

Implementation paths

Which path for whom

• Enterprise: Path B, because claims fraud is core to underwriting economics and data is sensitive (health, liability); combining a specialist platform with own models and APIs on the claims data keeps know-how in-house. Pure buy (Path A) stays valid for carriers without data-science staff.
• Developer: Path C, because open-source tabular and graph ML plus self-hosted document analysis keep claimant data inside your infrastructure.

Path A — Buy (off-the-shelf)

• Specialist fraud platforms: Shift Technology (Paris, EU-founded; products incl. Fraud & Risk, Insurance Data Network; customers listed include AXA, Assurant, Markerstudy) [2]; FRISS (Trust Automation: Claims Analytics, Investigations, Media Check for manipulated and AI-generated images/PDFs; 300+ insurers in 45+ countries; Netherlands-based, EU) [1]; Verisk ClaimSearch and analytics (US, claims-history database); SAS Fraud Management, FICO and Guidewire-ecosystem add-ons for larger carriers.
• Core-system add-ons: many policy/claims suites (Guidewire, Duck Creek, Sapiens, Majesco) offer integrations to the platforms above.
• Choose A when: you are an insurer or MGA without a data-science team, need proven models plus pooled cross-customer intelligence, and can accept a vendor's data processing agreement (check EU hosting, sub-processors, model transparency and your right to explanations).

Path B — Build on cloud APIs

• Models: managed AutoML / gradient boosting (e.g. Azure ML, Vertex AI, SageMaker in EU regions) for scoring; graph database services; LLMs (Claude, Gemini, GPT, or EU provider Mistral) via EU-region endpoints for file summarisation, narrative-consistency checks and reason-code explanations; document AI (Azure Document Intelligence, Google Document AI) for extraction.
• Orchestration: event-driven pipeline on the claims system (queue, scoring service, case-management integration), n8n/Camunda for referral workflows.
• Choose B when: you have in-house engineers, want custom logic on top of your own claims data, and need only the LLM/forensics parts from the cloud while scoring stays in-house.

Path C — Self-host (open source)

• Scoring: scikit-learn, XGBoost/LightGBM, PyOD for anomaly detection, SHAP for reason codes; MLflow for model governance.
• Graph: Neo4j Community, Memgraph or Apache AGE (PostgreSQL) with NetworkX/PyTorch Geometric or graph-data-science libraries for community detection.
• Documents/images: Docling or PaddleOCR for parsing; open VLMs (Qwen-VL family) via vLLM for consistency checks; C2PA tooling (c2patool) to read provenance credentials; perceptual hashing for duplicate-image search.
• Hardware: HW2 covers a mid-sized insurer's claims volume; the tabular and graph parts run on CPU servers. HW3 only if running larger VLMs on high document volumes.
• Why self-host: claim files contain health, financial and location data; on-prem keeps them inside the insurer's control.

Path D — Custom training

Worth it for mid-to-large insurers with years of labelled SIU outcomes: train company-specific gradient-boosting models and graph neural networks on your own fraud patterns, and fine-tune image-forensics models on your claim photo types. Needs thousands of confirmed fraud cases plus cleared negatives; beware label bias (only referred claims are labelled), and use active learning or randomised audits to obtain unbiased samples. Fine-tuning LLMs is rarely needed.

State of the art (2026)

• Network-centric detection (entity resolution plus graph analytics) is the main step beyond rules; vendors market "hidden fraud networks" as a core capability [1].
• Generative-AI evidence fraud (edited receipts, AI-generated damage photos) has pushed vendors to ship media-forensics modules (e.g. FRISS Media Check [1]). Detection is an arms race: detectors generalise poorly to new generators, so provenance (C2PA) and consistency checks across documents, plus metadata and source-channel controls, matter more than a single "AI-or-not" classifier.
• Agentic investigation support: vendor material describes AI agents that assess fraud, assign cases and guide investigations [2]. In practice they draft summaries and plans for a human investigator.
• Explainability by design: reason codes and score transparency are now expected by supervisors and regulators.
• Limits and failure modes: label scarcity and selection bias; concept drift as fraudsters adapt; false positives that delay honest claims and harm customers; proxy discrimination (postcode, name, nationality-correlated features); model scores treated as accusations. Published vendor percentages come without independent benchmarks; no public benchmark for claims fraud exists because data are confidential.

Shared resources & combinations

• Same stack (tabular-ml + anomaly-detection + graph-ml): ANOM-001 (payment fraud), ANOM-002 (AML), ANOM-007 (healthcare billing fraud), ANOM-009 (expense/procurement fraud) share feature stores, graph database, model-governance tooling and case management; a single graph platform can serve several fraud lines.
• Document stack (ocr-docparse + vlm): ANOM-017 (document tampering), ANOM-014 (identity documents), DOC-001 (invoice processing, since repair invoices feed both) and VIS-023 (damage assessment from photos, the natural upstream providing estimates and image authenticity checks).
• Process neighbours: AGENT-014 (end-to-end claims handling) is where scores trigger fast-track or referral; PRED-010 (underwriting and pricing) uses the same history and shares application-fraud signals; ANOM-022 covers payout-side mule accounts.
• Hardware: CPU cluster for scoring and graph, one HW2 GPU shared with other document/VLM use cases.

Effort, cost & KPIs

• Path A: 3-9 months from contract to production at a mid-size insurer (data integration into claims system is the main effort); licence typically by claim volume.
• Path B: 6-12 months with a small data/engineering team; cloud cost is modest, people cost dominates.
• Path C/D: 9-18 months including data engineering, labelling process, model validation and SIU workflow; ongoing MLOps staff.
• Cost drivers: data integration, labelling/feedback loop, investigator capacity, regulatory validation.
• KPIs: confirmed-fraud hit rate of referrals (precision), fraud euros avoided or recovered per investigator, false-positive rate on honest claims, share of claims straight-through processed, time to settle for honest claims, customer complaints about delays, drift and fairness metrics across protected groups.

People & change

Involve management for the fraud strategy and customer-experience trade-offs, the claims department lead and the special investigations unit as process owners, claims handlers as daily users, IT, the DPO, legal and compliance, and the works council from the concept stage.

Works council: yes. Claims handler queues, scores per adjuster and case-handling analytics make the system suited to monitor performance (§87(1) no. 6 BetrVG); §90(1) no. 3 requires timely information on AI-based work processes, §80(3) allows an AI expert, and a works agreement on AI use is advisable. Public-sector insurers involve the staff council.

Data protection: health and other special-category data, plus profiling of claimants, make a DPIA very likely (Art. 35 GDPR); automated rejection of claims must stay with a human (Art. 22 GDPR). AVV with every vendor. AI literacy: support handlers with training on scores, bias and limits (Art. 4 AI Act). Pilot in one line of business, scoring in the background without changing decisions, then compare against investigator findings. Typical concerns: false suspicion against honest customers and handler surveillance; address with referral-only use (the score never denies a claim), explanations and audit of outcomes. See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: claims fraud detection is not listed as high-risk by itself. Annex III point 5(c) lists AI used for risk assessment and pricing for natural persons in life and health insurance, and point 5(b) lists creditworthiness scoring but explicitly excepts AI used for detecting financial fraud [3]. Fraud detection in non-life claims is therefore normally minimal-risk, but the classification depends: if a system's output feeds life/health risk assessment or pricing, or becomes the effective basis for denying benefits, treat it as high-risk and apply Arts. 9-15 and deployer duties (human oversight, logging, impact assessment). Have counsel confirm the classification per system.
• Prohibited practices: Art. 5(1)(d) bans assessing whether a person will commit a crime based solely on profiling or personality traits; it allows tools that support human assessment based on objective, verifiable facts linked to the activity [4]. Design scores around claim-specific facts, not personality or social-behaviour profiles; Art. 5(1)(c) social scoring (unrelated-context unfavourable treatment) must be avoided, e.g. by not importing social-media behaviour scores.
• GDPR: Art. 22 restricts decisions based solely on automated processing with legal or similarly significant effect, with exceptions for contract necessity, law, or explicit consent, and always requires safeguards including human intervention and the right to contest [5]. Keep a human decision on every denial or fraud accusation. Further: legal basis (legitimate interest in fraud prevention, Art. 6(1)(f); health data needs Art. 9 basis), DPIA, purpose limitation for shared industry databases, transparency and data-subject access to scores where applicable, retention limits.
• Sector law: German VVG (duties of the policyholder, burden of proof), VAIT/BaFin supervisory expectations for IT and outsourcing, DORA for ICT risk and third-party providers (vendor register), EIOPA's guidance on AI governance for insurers (fairness, explainability, human oversight), and Solvency II governance. Fraud accusations carry defamation and bad-faith-claims risk.
• Mitigations: reason codes for every referral; random audit sample to measure true precision and recall; bias testing on protected attributes and proxies; separate investigation from claim-payment decision; red-team the image-forensics layer; vendor due diligence on data pooling and model transparency.

Getting started

1. Baseline: pull 2-3 years of claims with SIU outcomes; measure current referral precision, fraud loss, honest-claim delay and false-positive cost.
2. Run a data-readiness check on entity keys (person, vehicle, IBAN, address, provider) because graph value depends on clean entity resolution.
3. Pilot in one line (e.g. motor): shadow-mode scoring for 3 months against current rules, review referrals with the SIU, and compare precision per investigator-hour.
4. Add document/image forensics on the same line, using provenance checks first and ML detectors second.
5. Complete DPIA, AI Act classification memo and Art. 22 human-review procedure before switching scores into live routing.

Sources

1. FRISS, Trust Automation platform and Claims Analytics (product claims, UNIQA case, customer-reported figures): https://friss.com/
2. Shift Technology, insurance AI platform (products, customers, scale figures): https://www.shift-technology.com/
3. EU AI Act, Annex III (high-risk systems, point 5 insurance and fraud-detection exception): https://artificialintelligenceact.eu/annex/3/
4. EU AI Act, Article 5 (prohibited practices, incl. 5(1)(c) and 5(1)(d)): https://artificialintelligenceact.eu/article/5/
5. GDPR Article 22 (automated individual decision-making): https://gdpr-info.eu/art-22-gdpr/