Fraud & Compliance / Learning brief
How a fraud detection product works
Your notes
In simple terms / 01
What this means in plain language
An end-to-end view of how fraud detection products work — real-time scoring, rules engines combined with machine-learning models, behavioural, device, and consortium signals, case management, and feedback loops that retrain the models.
A fraud detection product decides, in the moment a payment is attempted, whether it looks like the genuine customer or someone else. It works by combining two kinds of logic. A rules engine applies clear, explainable checks an expert wrote — for example, flagging a first-ever payment to a new country above a set amount. Alongside it, machine-learning models weigh dozens of subtle signals at once and produce a risk score. Those signals come from several sources: behavioural patterns such as how the customer usually types or navigates, device signals such as the phone or browser in use, and consortium signals shared across many institutions so a fraud pattern seen elsewhere can inform a local decision. When the combined score is high, the product can hold, challenge, or decline the payment. Confirmed outcomes then feed a feedback loop that retrains the models, so the system keeps learning as fraud tactics change. Fraud detection differs from sanctions screening: it asks whether a transaction is genuine, not whether a party is forbidden.
Complete lesson / 02
Understand the full idea, step by step
When your card is used somewhere unusual and a message asks Was this you?, something decided in a fraction of a second that the payment was worth a second look. That something is a fraud-detection product. Let us open it up and see how it reaches that decision.
Rules engine — explicit, human-written conditions that fire on stated risks
A rules engine holds checks written by fraud experts — conditions such as a payment to a newly added beneficiary above a set amount, or several rapid attempts after a failed login. Rules are prized because they are transparent: an analyst can read exactly why one fired, which matters for explaining a decision to a customer or a regulator. Their weakness is that fraud adapts faster than anyone can hand-write conditions.
Machine-learning model and risk score — a model trained on labelled history that outputs how much a payment resembles known fraud
A model is trained on large histories of payments labelled genuine or fraudulent, and it learns patterns across many variables at once — amount, timing, location, sequence — that no single rule captures. It outputs a risk score, often between 0 and 1, expressing how much a payment resembles known fraud. Where rules state known risks plainly, the model catches subtler and shifting patterns; a good product runs both and combines their outputs into one decision rather than choosing between them.
| Rules engine | Machine-learning model | |
|---|---|---|
| How it is built | Experts write explicit conditions | Trained on labelled transaction history |
| Strength | Transparent — you can read why it fired | Catches subtle, multi-variable, shifting patterns |
| Weakness | Brittle — fraud adapts faster than rules are written | Harder to explain a single score |
| Best use | Known, clearly stated risks and explainability | Emerging patterns no one has hand-coded |
The signal families a product weighs
- Behavioural
- How the genuine customer normally acts — login times, navigation, typing and swipe rhythms; a sharp deviation raises suspicion
- Device
- The phone, computer, or browser in use, and whether it is one the customer has used before
- Consortium
- Anonymised fraud outcomes pooled across firms, so a pattern seen at one institution can inform a decision at another
- Transaction
- Amount, payee, currency, velocity — the payment's own features, weighed alongside the rest
Score, decide, review, label, retrain
- VALIDATION
The product assembles the signals for Riya's payment into a feature set and scores it in real time — fast enough not to disturb a genuine customer.
- NOTIFICATION
On the score and policy it acts: let the payment proceed, hold it for review, send a step-up challenge to confirm identity, or decline it.
- VALIDATION
Held and challenged items flow into case management, where an analyst like Maya reviews the evidence — signals, score, and the customer's history — and reaches a disposition.
- LEDGER
Every resolved case produces a confirmed label: genuine, or fraud. A false alarm confirmed as genuine is just as valuable as a confirmed fraud.
- VALIDATION
The feedback loop returns those labels to the data-science team, which periodically retrains the models so they reflect current tactics and stop repeating avoidable false positives.
If it stops a genuine payment like Riya's, has the product failed?
Not exactly — a false positive is a cost, not a defect, and it is measured deliberately. Teams track detection rate against false-positive rate, because tightening one usually worsens the other. Friction is a budget: every challenge or hold spends a little customer convenience, so a mature product spends it where the signals concentrate rather than uniformly. When Riya confirms it was really her, that outcome becomes a label that helps the model stop flagging the same harmless pattern next time. Real-time scoring catches a payment before it moves; post-event review of settled payments catches what slipped through and feeds the same loop.
COMMON CONFUSION
“A fraud-detection product and sanctions screening are basically the same kind of check.”
They ask different questions. Sanctions screening asks whether a party is on a forbidden list — a legal, list-based check with its own queue and release authority. Fraud detection asks whether the payment is genuinely the customer's. A fraud clearance never releases a sanctions hold, and the two keep separate owners because they answer to different rules.
STRICTLY SPEAKING
Strictly speaking, a real product's exact features, model architectures, score thresholds, and challenge policies are institution-specific and held closely — publishing them would help attackers. What is shared is the shape: rules plus models, several signal families, real-time scoring, case management, and a feedback loop. Treat the numbers and steps here as an illustrative teaching model, not any one vendor's design.
FOR NOW, REMEMBER
- A fraud-detection product pairs a transparent rules engine with machine-learning models and combines both into one real-time decision.
- It weighs several signal families — behavioural, device, consortium, and transaction — to tell the genuine customer apart from an impostor.
- High-risk items route to case management; every resolved case becomes a label that retrains the models through a feedback loop.
- False positives are a measured cost, and fraud detection is a separate discipline from sanctions screening.
TRY IT YOURSELF
The product holds Riya's genuine payment because it looked risky, and she confirms it really was her. How should a well-run fraud product treat this outcome?
You have now walked the whole defensive arc — the security posture, the fraud typologies, the BEC controls, and the detection product. The topic behind them ties the layers together into how a payments shop is secured end to end.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Fraud detection scores transactions in real time, combining written rules with machine-learning models.
- 02
Behavioural, device, and consortium signals give the models context a single transaction cannot.
- 03
Confirmed fraud and confirmed-genuine outcomes feed a loop that retrains models over time.
Practical use cases / 04
Where you would use this
A card-issuing team scores each authorisation in real time to challenge or decline suspicious ones.
A fraud analyst works a case queue, confirming genuine transactions and labelling true fraud.
A data-science team uses confirmed outcomes to retrain models and measure false-positive rates.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional card issuer, Cedar Point Card Services, sees a GBP 640.00 online purchase on a customer's card. The rules engine notes the merchant is in a new country; the model observes an unfamiliar device and a typing rhythm unlike the customer's usual pattern, producing a risk score of 0.92 within 200 milliseconds. The product sends a step-up challenge to the customer's app. The customer confirms the purchase is genuine in 40 seconds, the payment proceeds, and that confirmed-genuine label is stored to help retrain the model.
Evidence & review / 07
Evidence & review
General architecture of payment fraud-detection products; specific features, model designs, thresholds, and challenge policies are vendor- and institution-specific and not published. Step-up authentication framing reflects EU/EEA PSD2.
What this brief simplifies: Presents an illustrative rules-plus-models pipeline and feedback loop rather than any one product; score ranges and timing are teaching illustrations, not fixed parameters.
Sources for this brief3
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Riya scoring scenario and illustrative rules/model/feedback-loop design
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · Step-up / strong customer authentication as a challenge response
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Market practice
Wolfsberg Group Payment Transparency Standards ↗ — The Wolfsberg Group · Real-time and post-event monitoring, case management, and separation from sanctions screening
The 2023 standards replace the 2017 version and are supplemented by separate Wolfsberg guidance on roles and responsibilities in payment chains.