Fraud and anomaly detection that explains every flag
Score transactions, logins and claims as they happen, show analysts why each one was flagged, and tune the threshold to your risk appetite rather than to a vendor's default.
Rules catch yesterday's fraud and bury analysts in noise
Rule engines are precise about patterns someone already wrote down. They are blind to new ones, and every added rule raises the false-positive rate. Analysts end up reviewing hundreds of harmless alerts a day, while the genuinely unusual event waits in the same queue.
A scoring model turns the problem around. It learns what normal looks like for each customer, device and merchant, ranks events by how unusual and how costly they are, and hands analysts a short, explained list instead of a long, silent one.
How it works
From event stream to analyst decision
Every event gets a score and an explanation. The band it falls in decides whether it passes, waits for an analyst or is held. Analyst decisions become tomorrow's training labels.
1. Features, not raw events
Each event is enriched with what matters: spend velocity, device history, distance from usual behaviour, links to other accounts. Features are computed once and served to both rules and models.
2. Two models, one score
A supervised model learns from confirmed outcomes; an anomaly model flags what it has never seen. Rules still fire for policy. The combined score is calibrated so that 90 means roughly the same thing every month.
3. Bands decide the action
You set three bands against your false-positive tolerance. The top band holds automatically with an appeal route, the middle goes to analysts ranked by expected loss, the rest passes and is logged.
What you get
A scoring service your analysts will trust
Real-time scoring API
Low-latency scoring for authorisation flows and batch scoring for reviews, built on a feature store maintained by our AI data engineering team.
Explanations per flag
The three to five factors that drove each score, in plain language, so an analyst can confirm or dismiss in seconds and a customer can be told why.
Threshold tuning console
See the trade-off between catch rate and false positives before you move a band. Thresholds are versioned and changes are logged with who and why.
Drift and performance monitoring
Weekly reports on score distribution, precision at the operating point and feature drift, with alerts when the model starts missing. Retraining runs on a schedule, not in a panic.
Model documentation pack
Training data lineage, evaluation results, fairness checks and the decision policy, written for auditors and regulators as much as for engineers.
Guardrails we build in
Accuracy thresholds: the model only replaces a rule when backtesting shows a better catch rate at an equal or lower false-positive rate. Human-in-the-loop: automatic holds are limited to the extreme band and always have an appeal route with a response-time commitment. Audit trail: every score, explanation, threshold version and analyst decision is stored together for the retention period your regulator expects. PII handling: features are derived from personal data under a documented lawful basis, with pseudonymisation in training sets and bias testing across customer groups. Automated decisions with legal effect follow our AI governance framework and the wider AI security and governance practice.
Typical rollout
Shadow mode before any customer is affected
Baseline (2 weeks)
Measure the current rules: alert volume, analyst hours, catch rate and losses. Inventory the event streams and historical outcomes available for training.
Model and backtest (4–5 weeks)
Feature pipeline, first models and a backtest against the last six to twelve months. We agree the bands with your risk owner using the actual trade-off curve.
Shadow run (3–4 weeks)
The model scores live traffic without acting. Analysts see its ranking beside the rules and tell us where it is wrong. Thresholds are adjusted.
Go live and monitor (2 weeks)
Bands switched on, noisy rules retired, monitoring and retraining schedule in place. Handover with documentation and a quarterly review.
Illustrative example
What a first release usually looks like
Illustrative scenario, not a client case
A payments business runs a few dozen rules that generate a steady stream of alerts, most of them harmless. During the shadow run, the model's ranking places the confirmed fraud cases near the top of the queue while demoting the repetitive false alarms from two over-broad rules. After go-live, those rules are retired, analysts review a shorter list that starts with the highest expected loss, and the extreme band holds a small number of transactions each day with a same-day appeal process. The team's weekly report now tracks catch rate and false positives against the baseline measured in week one.
The same mechanism, applied to forecasting instead of flagging, is described under predictive analytics.
Supervised models need them, and most organisations have more than they think: chargebacks, confirmed disputes, closed investigations. Where labels are thin we start with anomaly detection, which learns what normal looks like, and add a supervised model as analyst decisions accumulate.
Will this replace our rules engine?
No. Rules encode policy and regulation and stay. The model runs beside them and handles what rules cannot express: subtle combinations, new patterns and ranking by risk. Over time, noisy rules can be retired because the model covers them with fewer false positives.
How do you stop the model drifting as fraud changes?
Fraud adapts, so the model is monitored weekly for score distribution, precision at the operating threshold and feature drift. Retraining is scheduled, not heroic, and every version is evaluated against the previous one before it serves traffic. This is standard in our monitoring practice.
Can a customer be blocked automatically?
Only in the extreme band you define, with an appeal route and a human review within an agreed time. Everything else creates a case for an analyst. Automated decisions with legal effect carry obligations under GDPR and, for some sectors, the EU AI Act; see AI governance.
How fast does scoring need to be?
For payment authorisation, tens of milliseconds, so features are precomputed and the model is served in-memory. For account reviews and claims, minutes or hours are fine and batch scoring is cheaper. We design for the slowest latency the business can tolerate.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.