What a detection system is choosing between
Every fraud detection decision is a choice under uncertainty with two ways to be wrong, and the two errors have different costs that are rarely measured on the same scale.
A false negative lets fraud through. The cost is visible, quantified and attributed: a chargeback, a written-off balance, a promotional loss.
A false positive stops a legitimate customer. The cost is the acquisition spend already committed, the lifetime value forgone, the complaint, and the customers who leave without saying anything. None of it appears in the fraud report.
A system tuned by people who only see the first error will tighten indefinitely, because every tightening improves the only number on the dashboard. That is the central design problem of the whole discipline, and everything below is a response to it.
Rules: honest about what they are for
Rules encode a known pattern as a condition. They remain the backbone of most implementations and there are good reasons for that.
They are explainable, which matters when a customer complains or a regulator asks. They are testable against historical data before deployment. They are auditable, with a change history. And they can be written the day after a new attack appears, which no model can.
Their weaknesses are equally real. They are static, they are blunt, and anyone who works out where the threshold sits can operate beneath it. A rule set alone will always be reactive.
The rules worth building map to the signals from the earlier lessons: velocity rules on deposits, registrations and instrument additions; sequence rules on the takeover pattern of contact change, payout change and withdrawal; mismatch rules on name, address and instrument; linkage rules on shared device, network and instrument across accounts; and behaviour rules on deposit-withdrawal with minimal turnover.
Two disciplines make a rule set defensible rather than accumulated. Every rule has a stated purpose and an owner, so nobody inherits a condition nobody can explain. And every rule has a measured precision, so it is known how often it fires on legitimate customers.
Models: the question to ask about any of them
Machine-learned models are better at ranking than a rule stack, and worse at explaining themselves. Both facts matter.
The question to ask of any fraud model is what it was trained on, because the label determines what the model actually learns.
Trained on confirmed fraud is the ideal and is rare. Confirmation requires an outcome the operator observed, and most cases end in restriction rather than confirmation.
Trained on chargebacks learns to predict disputes. That includes friendly fraud, which is a different phenomenon with different drivers, so the model will flag regretful losers alongside actual fraud.
Trained on manual decisions learns to reproduce the existing team, including its biases and its blind spots, and then presents them as objective output.
Trained on rule hits reproduces the rule stack.
None of these are disqualifying, and all of them need stating in the model documentation before someone else finds them. A model whose limitations are written down is a tool; one presented as simply accurate is a liability.
Anomaly detection avoids the label problem by flagging deviation from a peer group or from an account's own history. Well suited to a domain where confirmed labels are scarce, and its weakness is that unusual is not the same as fraudulent.
Device, network and behavioural signals
The signal layer beneath both rules and models, and the highest-value investment for most operators.
Device fingerprinting identifies a device across sessions from its characteristics. The strongest single linking signal available, and it degrades as platforms restrict the attributes available, so it needs maintenance.
Network and connection characteristics identify shared origins, hosting ranges, proxy and VPN use. Useful and noisy: VPN use is now ordinary consumer behaviour and is not a fraud signal on its own.
Behavioural biometrics analyse how a person interacts: typing cadence, mouse movement, form completion patterns. Particularly effective against account takeover, because the attacker interacts with the account differently from the owner, and against automation.
Velocity across dimensions rather than within one: a single account's deposit velocity is weak; the same instrument across ten accounts in an hour is strong.
The general principle is that linkage signals outperform threshold signals. A threshold asks whether one account did something unusual. A linkage signal asks whether several accounts are the same person, and that question is both harder to evade and more often the thing you actually want to know.
Tiering the response
The mechanism that resolves the two-error problem, and the one most often missing.
A binary approve-or-block decision forces every case to the strictest response the weakest evidence can justify. A tiered response matches the friction to the confidence.
Weak signal: monitor, no customer-visible action. The case is scored and watched, and repetition escalates it.
Moderate signal: a low-friction verification step. Confirm a code, re-authenticate, verify an instrument. Most legitimate customers pass in seconds, most fraudsters abandon.
Strong signal: hold the specific transaction, not the account. A withdrawal held for review while play continues is a much smaller imposition than a frozen account, and it protects the money that is actually at risk.
Very strong or corroborated: restrict the account pending review, with a clear message and a defined review timeframe.
Designing the moderate tier properly is the highest-return piece of work available to most fraud functions, because it converts a large population of uncertain cases from a binary decision into a cheap test.
Tuning, and proving the system works
A detection system nobody has tested is a system nobody can defend.
Measure precision per rule, which is the proportion of alerts that were genuine. A rule at very low precision is a tax on legitimate customers and should be retired or rewritten rather than tolerated.
Sample below the line. Review cases that did not alert. This is the only way to find what the system misses, it is the half everyone skips, and it is where the genuinely useful findings are.
Review overturned decisions. Every reversed block is a false positive with a known cost. The pattern across them identifies the rule responsible.
Back-test before deploying. Run a proposed rule against historical data and see what it would have caught and what it would have stopped. A rule that would have blocked a hundred legitimate customers to catch three fraud cases is a rule you now know not to deploy.
Change control. Every rule change recorded with its reason, its expected effect and its observed effect. Without it, nobody can explain why a threshold is where it is, which is the answer supervisors and auditors hear most often.
Alert volume and the review that does not happen
The same arithmetic as every low-base-rate detection problem. Fraud is a small proportion of activity, so even an accurate system produces mostly false positives among its alerts, and a system tuned to catch everything produces a volume no team can review.
The consequence is specific and bad: alerts closed superficially, which means the operator has documented that it detected something and did nothing. In fraud that is a commercial loss; where the alert touched financial crime or responsible gambling, it is a regulatory finding.
The discipline is the same as elsewhere. Size the human queue to the strong-signal volume, automate the weak and moderate tiers, and measure closure quality by independent re-review of a sample rather than closure rate.
Cross-functional routing
A detection system in a gambling operator sits on top of signals that belong to three other functions, and the routing decision matters as much as the detection.
The same observable behaviour can mean different things. Deposit, minimal play, withdrawal is laundering, stolen instrument extraction, or a customer who changed their mind. Rapid escalating deposits are fraud, or a customer in difficulty. Multiple failed deposits are a stolen card being tested, or a customer who has run out of money.
An operator whose fraud system silently resolves these to fraud will systematically under-refer to the financial crime function and to the responsible gambling function, and both of those have obligations the fraud function does not.
The design answer is that ambiguous signals route to a triage step with visibility of all three domains, not to whichever queue the rule happened to be written in. Build that on day one, because retrofitting it means re-examining every historical case.