Insurance & Claims
Insurance Fraud Detection API
Opportunistic fraud is annoying and expensive. Organised fraud is the one that costs real money, and it is invisible at the level of a single claim.
- General insurers
- Claims administrators
- MGAs
- Health insurers
- Counter-fraud teams
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
A counter-fraud team looking at one claim at a time will catch the obvious exaggerations and miss the thing that matters. The organised cases look entirely normal individually: a modest soft-tissue injury claim, a credible repair invoice, a plausible witness. They only become visible as a pattern — the same medical practice appearing across unrelated policies, the same mobile number on claims from four different households, a repair garage whose invoices cluster suspiciously close to the policy excess.
Most insurers have the data to see this and no practical way to look. Claims sit in one system, policy data in another, supplier payments in a third, and the relationships that define an organised network run across all of them. The team ends up relying on referral from handlers, which catches what a handler happens to notice and nothing else.
Network analysis is the right shape of tool for this, with two caveats that are easy to get wrong. A graph of shared attributes generates enormous numbers of innocent links — shared addresses are flats, shared phone numbers are workplaces, shared garages are simply popular — so link scoring matters more than link detection. And a fraud score attached to a named individual is sensitive personal data with real consequences for the person, which makes explainability and human adjudication requirements rather than refinements.
Who buys this
General insurers, Claims administrators, MGAs, Health insurers, Counter-fraud teams
What the API returns
What comes back
- Claim-level fraud risk score with the specific indicators that produced it
- Network graph linking claims, policies, claimants, suppliers and contact details
- Link scoring that distinguishes meaningful connections from coincidental shared attributes
- Duplicate and reused evidence detection across images, invoices and documents
- Supplier and provider pattern analysis, including invoice clustering around policy limits
- Timing and sequence anomalies such as claims shortly after policy inception or cover upgrade
- Narrative inconsistency flags between the claim description and supporting documents
- Case package for referral with the full evidence trail and reasoning
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/claims/score | Score a claim with indicators and network context |
| GET | /v1/claims/{id}/network | Network graph around one claim with scored links |
| POST | /v1/evidence/duplicates | Check submitted images and documents against prior claims |
| GET | /v1/suppliers/{id}/patterns | Pattern analysis for one repairer, clinic or provider |
| GET | /v1/networks | Detected clusters ranked by aggregate exposure |
| POST | /v1/outcomes | Record investigation outcomes to calibrate scoring |
Request and response
illustrativeRequest
{
"claim": {
"claim_id": "CLM-2026-991204",
"policy_id": "POL-884120",
"peril": "motor_third_party_injury",
"reported_on": "2026-10-18",
"incident_on": "2026-10-11",
"amount_claimed": { "value": 7400.00, "currency": "GBP" }
},
"entities": {
"claimant": { "name_hash": "sha256:a41f\u2026", "phone_hash": "sha256:88c0\u2026",
"address_hash": "sha256:1b72\u2026" },
"suppliers": [{ "type": "medical", "id": "sup_2210" },
{ "type": "repairer", "id": "sup_8841" }]
},
"evidence": [{ "type": "image", "id": "ev_1", "hash": "sha256:7d31\u2026" },
{ "type": "invoice", "id": "ev_2", "hash": "sha256:5c90\u2026" }],
"include_network": true
}Response
{
"claim_id": "CLM-2026-991204",
"fraud_score": 81,
"band": "high",
"recommended_action": "refer_to_counter_fraud",
"indicators": [
{ "code": "SUPPLIER_NETWORK_CONCENTRATION", "weight": 0.29,
"detail": "Medical provider sup_2210 appears on 34 injury claims across 29 unrelated policies in 90 days" },
{ "code": "POST_INCEPTION_CLAIM", "weight": 0.18,
"detail": "Claim reported 21 days after policy inception" },
{ "code": "SHARED_CONTACT_ACROSS_POLICIES", "weight": 0.16,
"detail": "Claimant phone matches 3 claimants on unrelated policies" },
{ "code": "INVOICE_AMOUNT_CLUSTERING", "weight": 0.11,
"detail": "Repairer invoices cluster within 4% below the policy excess threshold" }
],
"evidence_checks": [
{ "evidence_id": "ev_1", "result": "near_duplicate",
"matched_claim": "CLM-2025-440122", "similarity": 0.97,
"note": "Same damage image, different claim and vehicle registration" }
],
"network": {
"cluster_id": "net_1182",
"claims_in_cluster": 34,
"aggregate_claimed": 248600.00,
"scored_links": 61,
"discounted_links": 184,
"discount_reason": "shared multi-occupancy addresses and a commercial switchboard number"
},
"requires_human_review": true,
"audit_reference": "scr_2026102112040118"
}Where the data comes from
| Your claims history with investigation outcomes | Claims with confirmed fraud, confirmed genuine and withdrawn outcomes — the only label worth training on, and sparse in every insurer’s data |
| Policy and underwriting records | Inception dates, cover changes and prior declinatures, which carry much of the timing signal |
| Supplier and provider payment records | Invoices and payments to repairers, clinics and hire firms, which is where organised patterns are most visible |
| Submitted claim evidence | Images, invoices and documents with perceptual hashes, enabling reuse and duplicate detection across claims |
| Industry counter-fraud databases | Shared sector databases where you are a member; participation rules strictly limit what may be contributed and how results may be used |
| Public registry and insolvency data | Company and officer records for supplier network analysis, which is lawful, open and frequently revealing |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Graph construction across claims, policies, people, contact details and suppliers, with entity resolution applied before any link is scored
- Link scoring that penalises high-degree coincidental attributes — a switchboard number or a block of flats generates hundreds of links and almost no signal
- Community detection to surface clusters, followed by cluster-level scoring rather than treating each claim independently
- Perceptual hashing and near-duplicate detection on images, which catches reused damage photographs that an exact hash match would miss
- Supervised scoring on confirmed outcomes combined with unsupervised anomaly detection, because confirmed fraud labels are far too sparse to rely on alone
- Supplier-level pattern analysis including invoice value distributions, treatment frequency and clustering near policy thresholds
- Per-indicator attribution on every score, retained in full, because a referral that cannot be explained cannot be acted on and may be unlawful to act on
- Calibration against investigation outcomes with explicit false positive tracking, since the cost of wrongly accusing a genuine claimant is not symmetrical with a missed fraud
What it changes for the business
Organised fraud visibility
Network analysis surfaces clusters that claim-by-claim review cannot see, which is where the large losses sit.
Earlier intervention
Scoring at first notification allows investigation before payment rather than recovery afterwards.
Focused investigator time
Ranked clusters with evidence packages replace handler referral as the main source of investigation work.
Supplier management
Provider-level pattern analysis supports evidence-based decisions about panel membership and invoice scrutiny.
How it fits into your product
How it embeds
- Scored at first notification and re-scored as evidence and supplier invoices arrive during the claim
- Referral packages pushed into your existing counter-fraud case management system with the full evidence trail
- Network visualisation components for investigators, which is how cluster findings are actually communicated internally
- Outcome feedback so confirmed investigations continuously recalibrate both scoring and link weighting
- Batch retrospective scanning across closed claims, which typically surfaces clusters that were invisible claim by claim
- Deployment inside your infrastructure, which is effectively required given the personal data involved
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Does this decide to reject claims?
No, and it must not. The API produces a score, indicators and a referral recommendation. A human investigator decides. Automated rejection of an insurance claim on a fraud score is poor practice, in several jurisdictions is a regulated automated decision with specific rights attached, and would be indefensible when the score is wrong. The response carries an explicit human review requirement for exactly this reason.
How do you avoid flagging innocent claimants?
Mostly through link scoring rather than link detection. Shared addresses are usually flats, shared phone numbers are often workplaces or brokers, and a popular local garage appears across many unrelated claims. The model discounts high-degree coincidental attributes explicitly and reports how many links it discounted and why. We also track false positives against investigation outcomes, because the asymmetry matters: wrongly suspecting a genuine claimant has consequences a missed fraud does not.
How much confirmed fraud data do you need?
More than most insurers have, which is why the design does not depend on it alone. A few hundred confirmed cases makes supervised scoring viable; most insurers have fewer, with inconsistent recording. The practical approach combines unsupervised network and anomaly detection, which needs no labels, with supervised scoring that strengthens as outcomes are recorded properly. We would also usually recommend improving outcome recording as part of the project.
Can we contribute to or query industry fraud databases?
Only within the membership rules, which are more restrictive than people expect. Shared sector databases typically govern what may be contributed, the purposes results may be used for, and whether results can be retained or redistributed. Those terms shape the architecture, and we check them in discovery rather than assuming a shared database is simply another source.
What about data protection on the fraud scores themselves?
A fraud score attached to a named person is sensitive personal data with real consequences for them, and it carries obligations: lawful basis, retention limits, accuracy, and in many jurisdictions rights of access and explanation. We design for those from the start — full attribution per score, defined retention, human adjudication before action. It is a genuine constraint on the design rather than a note in the documentation.
Related blueprints
Claims Document Extraction API
Structured fields pulled from invoices, medical bills, repair estimates and policy documents, with a confidence value on every field.
Medical Claims Anomaly Detection API
Billing outliers, duplicate submissions and unusual service patterns surfaced across health claims, scoped firmly to billing rather than clinical judgement.
Vehicle Damage Estimation API
Damage detection, parts identification and a repair cost range from claim photographs, for motor insurers and claims administrators.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.