Skip to content
QSWEQB
hardDesignCase StudyMidSeniorStaff

How would you detect insurance fraud, and how is detecting it at claim different from detecting it at application?

Application fraud is misrepresentation of the risk and is caught by cross-checking declared facts against external and historical data at quote. Claim fraud is caught by scoring the claim and by network analysis across parties, then routing a ranked, evidenced referral into a human investigation queue.

5 min readUpdated 2026-07-26

What the interviewer is scoring

  • Does the candidate separate application fraud from claim fraud instead of treating fraud as one problem
  • Whether they recognise the labels only exist for cases someone chose to investigate, and what that does to training
  • That they size the output to investigator capacity rather than optimising a threshold-free score
  • Whether organised fraud is described as a relationship problem rather than a per-claim classification problem
  • Can they explain what the investigator needs to see alongside a score for it to be usable

Answer

Two problems that share a word

Fraud at application is misrepresentation of the risk before any loss occurs. The declared main driver of a car is a parent when the real driver is the teenage son, which the trade calls fronting. The declared address is one with a lower rating area than the real one. Previous claims or convictions go undisclosed. A separate and organised variant is ghost broking, where someone sells policies they have obtained by falsifying the application, and the customer often does not know their cover is void.

Fraud at claim is a false or inflated claim against genuine cover. It spans opportunistic exaggeration, adding a pre-existing scratch to a genuine collision or inflating the contents of a burgled house, through to entirely fabricated events and staged or induced collisions arranged specifically to generate claims.

The distinction is not academic, because the detection signal, the timing pressure and the consequence all differ. Application checks run inside a quote flow with a latency budget measured in hundreds of milliseconds and against data you can verify externally. Claim checks have days rather than milliseconds, and the evidence is behavioural and relational rather than verifiable against a register. And the outcomes differ: an application finding leads to a re-rate, a referral, a declinature or, after a loss, a coverage dispute about whether the non-disclosure was material. A claim finding leads to an investigation and possibly repudiation and prosecution.

The application side

At quote time, the useful signals come from comparing what was declared against what can be established independently. Vehicle and address data can be checked against reference sources. Prior claims and prior policies can be checked against internal history and, in several markets, against industry-shared registers; the UK has the Claims and Underwriting Exchange for claims history and a fraud register operated by the industry, and the US has databases operated by industry bodies for the same purpose. What is available differs materially by country, so an honest answer says which market you are describing.

Beyond data cross-checks, the strong signals are behavioural. Quote manipulation is visible: the same broad risk quoted repeatedly with the date of birth or the occupation shuffled until the price drops is a pattern in your own quote logs, and it is one of the more reliable indicators you own outright. So is the reuse of a device, a payment instrument or a bank account across otherwise unconnected applications.

The claim side and network analysis

Per-claim scoring finds the opportunistic end. You build features from the claim itself and its context: the interval between policy inception and loss, the interval between loss and notification, the completeness and consistency of the account across retellings, the mix of injury heads claimed, whether the suppliers involved chose themselves, whether the damage described is consistent with the reported impact.

Organised fraud is a different shape of problem and per-claim scoring is systematically bad at it. Each individual claim in a well-run ring looks acceptable; what is unusual is the pattern of connections between claims. This is a graph problem. Build a graph whose nodes are the entities that recur across claims, people, addresses, phone numbers, bank accounts, vehicles, repairers, medical clinics, hire companies, solicitors, and whose edges are the claims that connect them. Then look for structure: communities that are far denser than the population baseline, individuals appearing as a claimant in one claim and a witness in another, a single garage or clinic appearing across a suspiciously connected set of unrelated losses.

Entity resolution is the whole ballgame and it is where these projects fail. If "A. Sharma, 14 High St" and "Anil Sharma, 14 High Street" are two nodes, the ring does not appear. If your matching is too aggressive, everyone at a large block of flats collapses into one node and the graph is a hairball of false structure. Budget serious effort for resolution, keep the matching decisions themselves auditable, and prefer conservative matching plus explicit "possibly same" edges over silent merging.

Feeding the investigator, not replacing them

An insurer's special investigations unit has a fixed and small capacity. That single fact should drive the design. The metric that matters is not the area under an ROC curve, it is how many confirmed frauds are found by the top N cases per day, where N is what the unit can actually work. A model that is theoretically excellent but produces four hundred referrals for a team of six is worse than useless, because the team stops trusting the queue and reverts to their own instincts.

So the output is a ranked queue with a capacity-shaped cutoff, and each item carries the reasons: which indicators fired, which connections were found, what the comparable population looks like. An investigator needs to open a case and see the evidence, not a number. A score with no reasons cannot be acted on, cannot be defended if the claim is later repudiated and litigated, and cannot be challenged by the investigator when the model is wrong.

The line to hold is that the model triages and the human decides. Repudiating a claim or voiding a policy on the strength of a score is both a regulatory problem in most jurisdictions and a reputational one, because false positives here fall on customers at the worst moment of their year. Fraud indicators should also be kept out of the pricing path unless you have thought hard about it, because an unproven suspicion silently affecting someone's premium is a different and less defensible thing than an investigation.

The label problem, which is the thing most candidates miss

You have outcome labels only for the claims someone investigated, and those claims were selected by the existing rules. Training on them teaches the model to reproduce the rules it was meant to improve on, and it never sees the fraud the current rules do not look at. Worse, the loop tightens over time: the model refers what the rules referred, those become the new labels, and the blind spot is baked in and invisible in every offline metric.

The countermeasure costs something and you should say so. Reserve a fraction of investigator capacity for randomly sampled or deliberately exploratory referrals, so you accumulate labels outside the current selection. Track outcomes with enough granularity to distinguish "investigated and found clean" from "not investigated", and never let the second collapse into the first. And measure the fraud that reaches settlement, through periodic retrospective review of paid claims, because that is the only estimate you get of what the whole system is missing.

Fraud detection is a workflow with a model inside it, not a model with a workflow bolted on. If the special investigations unit does not trust the queue, the model's accuracy is irrelevant.

Likely follow-ups

  • How do you stop a fraud model from decaying as the rings adapt to it, and how would you know it had?
  • What would you deliberately not automate here, and on what grounds?
  • How do you evaluate a fraud model when you can only ever observe outcomes for the cases you referred?
  • Where do industry-shared databases fit, and what changes about the design when you can query one?

Related questions

fraud-detectionnetwork-analysissiuentity-resolutionmodel-deployment