The defining feature of this work is that you usually cannot say what the right answer was. A model flags a thousand transactions; some are investigated, most are not; and of those never looked at, nobody knows how many were genuinely wrong. You are hiring somebody to build a system whose accuracy is, in the strict sense, unmeasurable.
Fraud is the commonest commercial application and the one that funds most of these roles, so much of what follows uses it as the example. The same structure applies to equipment failure, network intrusion, quality defects and payment abuse.
Ask how they got labels, and what the labels were worth
This is the question that separates people who have done this from people who have read about it.
The honest answers are all partial. Confirmed cases arrive late — a chargeback lands months after the transaction, so today’s model is trained on a version of the world that has moved on. Investigator decisions are labels of a sort, but they only exist for cases the previous system flagged, which bakes that system’s blind spots into the next one. And the absence of a complaint is not evidence of legitimacy.
A candidate who describes these limitations without prompting is somebody who has had to make decisions on incomplete evidence. One who describes a clean labelled dataset has either worked on a research problem or is describing the part of the job that was already done for them.
The alert budget is the real design constraint
Every detection system is bounded by how many alerts humans can actually review. If you have four investigators, you can action perhaps a few hundred cases a day, and a model that surfaces ten thousand is useless regardless of how good it is.
So ask what their alert volume was and who handled it. The answer reveals whether they designed for the operation or for a metric. Mature practitioners talk about the threshold as a capacity decision, about tiering so high-confidence cases are actioned automatically while marginal ones queue, and about the feedback loop from investigators being the most valuable data the system generates.
The follow-up: what did they do when the reviewers stopped trusting the alerts? It happens, it is close to terminal, and recovering from it is mostly about precision rather than recall.
The adversary makes this different from other modelling
In fraud and intrusion, somebody is actively trying to defeat the system, and this changes the discipline in ways that surprise people arriving from other modelling work.
Ask how their model degraded. The answer should involve the adversary adapting: a pattern that worked for six months stopped working because the behaviour moved, and the model that was excellent in March was mediocre by September without anything in the code changing. Candidates who have lived with this build in retraining cadence from the start and monitor the input distributions rather than only the outcomes.
There is also a defensive subtlety worth hearing: explaining too much about why something was flagged tells an adversary how to avoid it. That tension between explainability and security is real, and somebody who has worked in the field will have an opinion about where they drew the line.
Supervised, unsupervised, or rules — and why the answer is usually all three
Ask what proportion of their detections came from rules. If they say none, be sceptical.
Real systems are layered, and each layer earns its place. Rules catch the known patterns cheaply, are instantly explainable to a regulator, and can be changed the same afternoon a new scheme appears. Supervised models generalise from confirmed cases and are the workhorse. Unsupervised methods exist to catch the thing nobody has seen before, and are the hardest to tune because their output is “this is unusual” rather than “this is wrong” — and most unusual things are perfectly innocent.
An engineer who wants to replace the rules entirely with a model is telling you they have not yet had to explain a decision to a compliance officer. On the modelling side specifically, this is territory where gradient-boosted trees usually outperform anything deeper, which the XGBoost guide covers.
The cost asymmetry, and getting it stated
A false negative and a false positive cost wildly different amounts, and the ratio is a business fact rather than a technical one. In payments, blocking a legitimate customer may cost more in lifetime value than the fraud you prevented; in industrial monitoring, a missed failure may cost more than a thousand unnecessary inspections.
Strong candidates ask you for that ratio rather than waiting to be told it, and then set the operating threshold from it. Weak ones optimise a symmetric metric and present a confusion matrix without an opinion. If the role sits close to the commercial side of that conversation, the data scientist guide describes the hire more accurately.
What it pays, and where to look
Indicatively £70,000 to £110,000 permanent, with day rates from around £550 and the upper end in payments, banking and insurance where the saving is directly attributable.
Across the UK careers pages we index, about 410 employers mention anomaly detection and 370 mention fraud detection — among the deeper markets on this site, because the requirement is old and regulated rather than fashionable. That also means the best candidates frequently come from financial crime, risk or industrial monitoring backgrounds and describe themselves in that language rather than in current machine learning vocabulary. Somebody who has sat with investigators for a year is usually more useful than somebody with better models and no operational exposure.