Fraud and Anomaly Detection
Detection built around the constraint that actually binds: how many cases your review team can work in a day, and how confident they need to be before acting on one.
Fraud detection has an unusual property: your adversary reads your defences and changes behaviour. A model that performs beautifully in evaluation degrades in a way that ordinary business models do not, because someone is actively working out where the threshold sits.
Fraud and anomaly detection is the engineering of systems that identify transactions, accounts or events likely to be fraudulent or abnormal, ranked so that a review team works the highest-value cases first, with explanations attached, thresholds set from the cost of each error, and monitoring designed for an adversary who adapts.
The economics that decide the design
Three numbers determine almost every design decision, and we establish them in the first fortnight:
- Review capacity. How many cases can be worked per day. This sets the volume the model may flag, which sets the threshold, which sets everything else.
- Cost of a missed case. Average loss, plus the downstream cost of chargebacks, remediation and regulatory attention.
- Cost of a false positive. Review time, and more importantly the customer experience of a blocked legitimate transaction, which is frequently the larger number and almost never measured.
Teams routinely optimise for detection rate alone and discover that the third number dominates. A model that stops a modest amount of fraud while declining good customers can be net negative, and that is a calculation rather than an opinion.
Precision at the top of the queue is the metric
Overall accuracy is close to meaningless when the positive rate is a fraction of a percent. What matters is how many of the top hundred cases your team works today are genuinely fraudulent, because that is the number that determines whether analysts trust the queue at all.
How we build detection
Rules and models together
Existing rules stay. They are fast, explainable and encode expensive lessons. The model adds ranking and catches patterns rules miss, and we measure the contribution of each so that redundant rules can be retired deliberately rather than left accumulating.
Features from behaviour and network, not just the transaction
Velocity, deviation from the account's own history, device and identity reuse, and relationships between accounts, addresses and payment instruments. Fraud is usually visible in the relationships and the change in pattern rather than in any single transaction's attributes.
Handle severe class imbalance honestly
Fraud is rare, and the wrong sampling strategy produces a model that looks excellent and ranks badly. We evaluate on precision and recall at the operating threshold rather than on aggregate accuracy, and we validate by time so the model is tested on periods after the ones it learned from.
Explain every flag
Analysts need to know why a case surfaced, in terms they can verify: this device has been used by eleven accounts this week, this amount is nine times the account's usual, this address matches three prior confirmed cases. Unexplained scores get overridden and then ignored.
Design for the adversary
Monitoring watches for score-distribution shifts and for probing behaviour, retraining is scheduled rather than reactive, and a portion of cases below the threshold is reviewed anyway so you keep learning about what you are currently missing. Without that sampling, your labels only ever describe the fraud you already catch.
Feed decisions back as labels
Confirmed fraud, confirmed legitimate and inconclusive outcomes flow back into training with the reason attached. The label pipeline is a permanent part of the system, not a one-off extraction, and its quality determines how well the model ages.
Beyond payments fraud
| Domain | What is detected | The usual constraint |
|---|---|---|
| Payments | Card and account takeover, unusual transactions | Real-time latency and customer friction |
| Insurance claims | Inflated, staged or duplicated claims | Investigator capacity and regulatory fairness |
| Internal and expense | Policy breaches and unusual patterns | Employment sensitivity; handled carefully |
| Manufacturing and IoT | Sensor anomalies and process deviation | Few labels; unsupervised methods |
| Infrastructure | Behavioural anomalies in logs and access | Alert fatigue and false positive tolerance |
Where labelled fraud examples barely exist, the approach shifts to unsupervised anomaly detection with human triage, and expectations shift with it. We are explicit about which situation you are in before building.
How the engagement runs
Capacity and error costs are established first, because they set the threshold everything else is tuned to.
Economics and data audit
Review capacity, loss per missed case and cost of false positives established; case and label quality assessed.
Feature engineering
Behavioural, velocity and network features built, with time-based validation and leakage checks.
Model and threshold
Models trained and evaluated on precision and recall at the operating point, thresholds set to review capacity.
Analyst workflow
Explanations, case queue integration, feedback capture for labels, and shadow running against current rules.
Go-live and handover
Staged deployment alongside existing rules, adversarial monitoring configured, retraining schedule handed over.
What you receive
A ranked queue analysts trust, with the economics behind every threshold written down.
Detection model
Deployed scoring at the required latency, running alongside your existing rules.
Economics model
Review capacity, cost per missed case and per false positive, and the threshold derived from them.
Feature library
Behavioural, velocity and network features, documented and reusable.
Analyst explanations
Per-case reasons in verifiable terms, integrated into the case queue.
Label feedback pipeline
Analyst outcomes flowing back into training, including below-threshold sampling.
Adversarial monitoring
Score drift, probing detection and a scheduled retraining cadence with alerting.
Is this the right engagement?
Worth being direct. Fraud and Anomaly Detection is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Fraud or anomaly losses are material and a review team already exists.
- Historical cases are labelled with outcomes, even imperfectly.
- Rules are catching the obvious cases and missing the adaptive ones.
- Analysts can tell you why a case was fraudulent, so explanations can be validated.
- You can sample below the threshold to keep learning about misses.
Choose something else if
- There are no labelled cases and no capacity to investigate anomalies.
- Losses are small enough that review cost exceeds the recovery.
- The customer friction cost of a false positive has never been considered.
- Nobody will act on the queue once it exists.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How accurate is AI fraud detection?
The useful question is precision at your operating threshold, not overall accuracy, because with a positive rate under one per cent a model that flags nothing scores over ninety-nine per cent. We tune to your review capacity and report how many of the top-ranked cases are genuinely fraudulent, which is what determines whether analysts trust the queue.
Will it replace our existing fraud rules?
No, and it should not. Rules are fast, explainable and encode expensive lessons. The model adds ranking and catches adaptive patterns rules miss. We measure each rule's contribution so redundant ones can be retired deliberately rather than left to accumulate.
How do you handle fraud that adapts to detection?
With scheduled retraining rather than reactive fixes, monitoring for score-distribution shifts and probing behaviour, and deliberate sampling of cases below the threshold. Without that sampling your labels only describe the fraud you already catch, and the model slowly becomes an expert in yesterday's patterns.
What if we have very few labelled fraud cases?
Then the approach is unsupervised anomaly detection with human triage, and the expectations change accordingly: it surfaces the unusual rather than the known-fraudulent, and the investigation loop is what turns that into labels over time. We are explicit about which situation you are in before building.
How do you avoid blocking legitimate customers?
By costing false positives properly, including the customer experience of a declined transaction, and setting the threshold from that number rather than from detection rate alone. In several engagements the false positive cost has been the larger of the two, which changes the design substantially.
Often paired with this
Most clients combine two or three engagements from the Machine Learning & Predictive Analytics pillar. These are the ones that most often run immediately before or after.
Custom ML Model Development
A bespoke model for a problem no off-the-shelf product fits, benchmarked against a simple baseline and deployed properly.
Read more →Credit Risk and Underwriting Models
Underwriting models built to survive validation: documented, fairness tested, with reason codes and monitoring.
Read more →Predictive Analytics
Predictions embedded in the decisions they are meant to improve, measured on the business outcome rather than on AUC.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.