Quick read. Payment-fraud detection is a rare-event classification problem under time pressure. A system observes a transaction, combines multiple signals into a risk estimate, compares that estimate with decision thresholds, and then approves, declines or sends the case for additional review. The mathematics is difficult because genuine transactions greatly outnumber fraudulent ones, fraud patterns change, and the costs of false alarms and missed fraud are different.
This article is defensive and educational. It describes public mathematical ideas used to understand fraud detection without giving operational thresholds, internal bank rules or instructions for bypassing controls.
The one-sentence answer
A fraud-detection algorithm estimates how compatible an observed transaction is with fraudulent versus legitimate behaviour, then makes a cost-sensitive decision while continuously checking for false positives, false negatives and changing patterns.
Why this is a mathematics problem before it is an AI problem
The core ideas are probability, conditional probability, statistics, classification, graphs, optimisation and sequential updating. Machine learning can make the models more flexible, but it does not remove the need to define the event, count errors, understand base rates or test whether the model remains valid.
The U.S. Federal Reserve’s 2025 CardSim research is a useful public example. It was created because real payment transaction data is difficult to share safely, and it uses a Bayesian simulation approach to support reproducible research into fraud-detection workflows. That illustrates an important principle: privacy and security constraints are part of the modelling problem, not an afterthought.
1. Define the event precisely
“Suspicious” is not a sufficient mathematical target. A model needs a labelled event such as a transaction later confirmed as unauthorised under a stated definition and time window. Other financial-crime tasks can have different targets, labels and legal meanings. Mixing them into one vague class damages both training and evaluation.
- What is the positive class?
- How long after a transaction can the label arrive?
- Can a label later be reversed?
- Which channels and transaction types are in scope?
- What decision is the model actually supporting?
2. Bayes’ theorem shows why the base rate matters
Let F mean fraud and x represent observed evidence. Bayes’ theorem gives:
P(F|x) = P(x|F)P(F) / P(x)
The prior probability P(F) matters. If fraud is rare, even a signal that occurs much more often in fraud than in legitimate activity can still produce many false alarms. This is the base-rate problem.
3. A rare-event example
Consider a purely hypothetical batch of 10,000 transactions in which 0.2% are fraudulent. That means 20 fraud cases and 9,980 legitimate transactions. Suppose an educational detector catches 90% of fraud but falsely flags 1% of legitimate transactions.
- True positives: about 18.
- False negatives: about 2.
- False positives: about 100.
- True negatives: about 9,880.
The detector catches most fraud, yet only about 18 of roughly 118 alerts are genuine fraud. Precision is therefore only around 15%. The exact figures are hypothetical, but the lesson is general: high recall can coexist with a large false-positive workload when the positive class is rare.
4. The confusion matrix is a control panel
- True positive: fraud correctly flagged.
- False positive: legitimate activity incorrectly flagged.
- True negative: legitimate activity correctly cleared.
- False negative: fraud missed.
From these counts we calculate recall, precision, false-positive rate and other metrics. Accuracy alone is dangerous. A model that labels every transaction “legitimate” could appear highly accurate when fraud is extremely rare while detecting no fraud at all.
5. Precision and recall describe different failure directions
Recall = TP / (TP + FN)
Precision = TP / (TP + FP)
Recall asks: of the fraud that happened, how much did we catch? Precision asks: of the transactions we flagged, how many were actually fraud? A threshold shift can improve one while worsening the other. There is no free threshold.
6. Fraud detection often combines several kinds of evidence
A public conceptual model might use broad categories such as transaction amount relative to a customer’s recent pattern, timing, channel, device consistency, merchant context, geographic consistency, account history and relationships between accounts or devices. The point is not any individual feature. The point is how evidence combines.
Robust systems should avoid treating one unusual feature as proof of fraud. A legitimate customer can travel, make a large purchase or change devices. Context converts an anomaly into evidence; it does not convert it into certainty.
7. Anomaly detection asks how unusual an observation is
One simple educational approach is to compare a numerical feature with a historical mean and standard deviation:
z = (x - mean) / standard_deviation
A large absolute z-score indicates unusualness under the assumed distribution. But unusual is not the same as fraudulent. Real transaction distributions can be skewed, heavy-tailed and highly individual. More advanced anomaly-detection methods can model complex patterns, but the conceptual warning remains unchanged.
8. Supervised classification and anomaly detection answer different questions
A supervised model learns from known labelled examples of fraud and legitimate activity. An anomaly detector instead asks whether an observation differs from expected behaviour, even if that exact fraud type has not been labelled before. Combining both can be useful because yesterday’s known fraud patterns and tomorrow’s new fraud patterns are different problems.
9. Graph mathematics can reveal relationships that single transactions hide
Represent accounts, cards, devices, merchants or other entities as nodes. Represent interactions as edges. A suspicious cluster may become visible only when many weak links are seen together. Degree, connected components, path structure and community patterns can all become signals.
Mastercard has publicly described using graph technology alongside AI to connect cards and merchants and identify potentially compromised relationships. Those vendor descriptions are examples of the general graph idea; they do not reveal internal production rules or thresholds.
10. Time creates another dimension
A transaction sequence can matter more than any one transaction. Sudden changes in frequency, repeated attempts, changes in counterparties or rapid transitions across states can be modelled as time-series or sequential features. The exact implementation differs, but the mathematical question is stable: does the recent path look plausible under expected behaviour?
11. Thresholds should reflect expected cost, not just classification score
If a model outputs probability p, a decision system still needs to decide what to do. A simplified expected-cost comparison might weigh the expected loss of letting fraud pass against the cost of interrupting legitimate activity and the cost of manual review.
The threshold can therefore differ by transaction context even when the underlying risk model is identical. This is decision theory layered on top of prediction.
12. Why false positives are not a minor inconvenience
False positives can block genuine purchases, create customer-support workload and reduce trust. Mastercard has publicly claimed that some of its newer fraud-detection technology reduced false positives in its own analysis. Such performance claims are vendor-specific and should not be generalised to all institutions or models, but they illustrate why fraud detection is a two-sided optimisation problem.
13. Label delay makes evaluation harder
Fraud may not be confirmed immediately. Chargebacks, investigations or customer reports can arrive later. If a model is evaluated too quickly, some apparently legitimate transactions may simply be fraud whose labels have not matured. Reliable evaluation therefore needs a defined observation window and label-maturity policy.
14. Concept drift is expected because adversaries adapt
Fraud detection is unusually dynamic because one side of the system actively changes behaviour in response to controls. A feature that was highly predictive can weaken when attackers adapt. Genuine customer behaviour also changes as new payment methods, devices and shopping habits appear.
Monitoring must therefore distinguish data drift, label-rate change and performance drift. Retraining merely because a metric moved can be as dangerous as ignoring drift altogether.
15. Human review is not a failure of automation
Some cases sit near the decision boundary or contain conflicting evidence. Routing those cases for additional verification can be rational. A mature system uses automation to reduce the search space and reserve expensive human attention for cases where it can change the outcome.
The key is to measure review quality too. Human decisions can be inconsistent, delayed or biased, and those decisions may later become training labels. The return path must therefore be auditable.
16. Diagnostics for a fraud model
- Track precision and recall separately.
- Measure performance by time period, channel and transaction type.
- Check whether probability calibration changes.
- Monitor alert volume as well as detected fraud.
- Test later time periods, not only random train-test splits.
- Investigate sudden changes in feature distributions.
- Audit whether human-review outcomes are feeding back correctly.
- Check latency: a good score that arrives after authorisation may be operationally useless.
17. Falsifiers: evidence that should weaken confidence
- A model has high accuracy but near-zero recall for fraud.
- Performance disappears on a later time period.
- Alert volume rises sharply while confirmed fraud does not.
- A single benign customer-behaviour change triggers widespread alarms.
- The model depends on labels that are too immature to trust.
- Explanation fields do not correspond to the actual decision path.
- The system is evaluated only on data sampled differently from production traffic.
18. Connection to school mathematics
- Probability: Bayes’ theorem and conditional reasoning.
- Statistics: distributions, z-scores and sampling.
- Ratios: precision, recall and false-positive rates.
- Graphs: nodes, edges and connected structures.
- Functions: risk scores and threshold mappings.
- Optimisation: balancing different error costs.
These ideas connect naturally to Bukit Timah Tutor’s public Probability and Statistics HELP Tasks and to the broader Mathematics Education Technology Atlas.
19. Update triggers
A fraud model should be reviewed after meaningful changes in payment channels, customer behaviour, fraud patterns, label definitions, device data, merchant mix, operational thresholds, model code or review policy. The world is part of the model.
Sources and further reading
- Federal Reserve: CardSim — A Bayesian Simulator for Payment Card Fraud Detection Research
- Mastercard: Card-fraud detection technology announcement
- Mastercard: Public explanation of graph technology in fraud detection
Final idea. Fraud detection is not “spot the unusual transaction.” It is a continuously tested probabilistic decision system operating under class imbalance, delayed labels, asymmetric costs and changing behaviour. The mathematics becomes useful when it tells us not only what to flag, but how we could know that our flagging system is failing.
