🛡️ Fraud & Risk Anomaly Detector — Live
Transactions scatter across a 2D feature space — an anomaly-detection boundary flags outliers as fraud risk, and a threshold slider trades false positives against false negatives.
About the Fraud & Risk Anomaly Detector
Real fraud-detection systems rarely have enough confirmed fraud labels to train a plain classifier, and fraud patterns shift faster than labelled data can be collected. A common practical answer is unsupervised anomaly detection: model what "normal" transactions look like statistically, then flag anything that lies too far from that model. This simulation estimates a live mean and covariance matrix from a synthetic set of transactions plotted by z-scored transaction amount and z-scored time-since-last-transaction, computes each point's Mahalanobis distance from that estimate, and renders the resulting anomaly-score field as a continuous heatmap.
A threshold slider sets the distance cutoff above which a transaction is flagged as fraud risk. Because the simulation also knows the internal ground-truth label of every synthetic point, it can score the detector's precision, recall, F1, and full confusion matrix live as you move the slider — making the false-positive/false-negative tradeoff at the heart of every real fraud system directly visible and adjustable.
Frequently Asked Questions
What is anomaly detection and how does it differ from supervised fraud classification?
Anomaly detection is unsupervised (or semi-supervised): it models what "normal" transactions look like — their mean and spread — and flags anything that deviates strongly, without ever being told which historical transactions were fraudulent. Supervised classification (e.g. logistic regression, gradient-boosted trees) instead learns directly from labelled fraud/not-fraud examples to draw a decision boundary between the two classes. Anomaly detection is essential in fraud because confirmed fraud labels are rare, delayed (chargebacks can take weeks), and fraud patterns constantly shift — an anomaly detector can flag genuinely novel attack patterns that no classifier has ever seen labelled examples of.
What does Mahalanobis distance measure, and why is it better than raw Euclidean distance here?
Mahalanobis distance measures how many standard deviations a point lies from the mean of a distribution, but — unlike Euclidean distance — it accounts for the correlation and differing spread between features. It is computed as d(x) = √((x−μ)ᵀ Σ⁻¹ (x−μ)), where μ is the mean vector and Σ the covariance matrix estimated from the current data. Because transaction amount and time-since-last-transaction are correlated in normal behaviour (large purchases tend to follow longer gaps), Euclidean distance would over-flag points that are merely unusual along the already-spread-out axis while under-flagging points unusual along the tight, correlated direction. Mahalanobis distance normalises for that correlation, producing elliptical (not circular) contours of equal "normality" that match the true shape of the data cloud.
How does the threshold slider control the precision/recall tradeoff?
The slider sets the Mahalanobis-distance cutoff above which a transaction is flagged as fraud risk. Lowering the threshold flags more points — recall rises (fewer real fraud cases slip through as false negatives) but precision falls (more legitimate transactions get wrongly flagged as false positives). Raising the threshold does the opposite: fewer alerts, higher precision, but more missed fraud. There is no single "correct" threshold — it depends on the relative cost of a missed fraud versus the cost and customer friction of a false alarm, which is why production systems tune it against business metrics, not just statistical ones.
Why can't real-world fraud detection just use one fixed threshold forever?
Spending patterns, fraud tactics, seasonality (e.g. holiday shopping), and even currency/inflation effects shift the underlying distribution of "normal" transactions over time — a phenomenon called concept drift. A threshold tuned to last year's data can become miscalibrated: either the false-positive rate creeps up as legitimate behaviour drifts outward, or fraudsters learn to stay just inside the boundary. Production systems recompute μ and Σ (or retrain more complex models) on rolling windows of recent data, monitor precision and recall in real time, and often use adaptive or per-segment thresholds — e.g. different cutoffs for different countries or merchant categories — rather than one static global cutoff.
What do precision, recall and F1 mean here, and why not just use accuracy?
Precision = TP/(TP+FP) — of all transactions flagged, what fraction were actually fraud. Recall = TP/(TP+FN) — of all actual fraud, what fraction did the system catch. F1 is their harmonic mean, balancing both. Accuracy is misleading here because fraud is rare — a heavily imbalanced problem: a detector that flags nothing at all could still be "99% accurate" while catching zero fraud. Precision and recall separate the two failure modes that actually matter operationally: annoying customers with false alarms versus letting fraud through undetected.
How is the anomaly-score heatmap computed and rendered?
The mean vector and 2×2 covariance matrix are recomputed live from every point currently in the dataset. The covariance matrix is analytically inverted, and the Mahalanobis distance is evaluated at every cell of a grid spanning the visible plane, producing a continuous scalar field. That field is mapped through a colour ramp — green through yellow to red as distance increases — and written into a canvas/DataTexture that Three.js renders as a textured plane behind the scatter points, the same technique used for decision-boundary heatmaps elsewhere on this site, just with a Mahalanobis-distance field instead of a network's forward pass.
Why is the cost of false positives and false negatives asymmetric in fraud detection?
A false negative (missed fraud) directly costs the money lost to the fraudulent transaction, plus potential regulatory and reputational damage. A false positive (blocking or flagging a legitimate transaction) costs customer trust and support overhead, and can push genuine customers to abandon a purchase or a bank altogether — but it doesn't lose principal. Because these costs are measured in different currencies — direct financial loss versus customer-experience friction — and vary by transaction size and customer segment, real systems often weight the threshold decision by expected monetary loss rather than treating every error as equally bad.
Why does the normal cluster look like an ellipse rather than a circle in the heatmap?
The shape of the equal-anomaly-score contours is determined entirely by the estimated covariance matrix Σ. If the two features were uncorrelated and had equal variance, the contours would be circles. Because amount and time-since-last-transaction are positively correlated in this simulation's normal cluster, Σ has non-zero off-diagonal terms, which tilts and stretches the contours into ellipses aligned with the direction of correlation — exactly the shape you would get by eye-balling a scatter plot of the normal points, which is the point: Mahalanobis distance is a principled, automatic version of "does this point fall outside the natural scatter of the cloud".
Transactions scatter across a 2D feature space — an anomaly-detection boundary flags outliers, trading false positives against false negatives.
3D · Three.js / WebGL renderer · 60 FPS target · runs fully client-side, no install