Anti-fraud for a bookmaker: where margin leaks
A bookmaker's margin leaks not in one place, but through several channels at once, and each looks like ordinary player activity. A network of betting bots is dozens of coordinated accounts that distribute amounts so as not to exceed the limits of a single profile.
Individually, each account is harmless; in aggregate, they take down the line faster than the risk service can react.
The second channel is detecting arbitrageurs on line discrepancies. While the odds in one system lag behind the market, arbitrage manages to take both sides and lock in a risk-free result.
Margin losses on line discrepancies accumulate unnoticed: each bet is correct, the anomaly is visible only in statistics over time and across markets.
The third source is match-fixing schemes in narrow markets and lower divisions, where betting volumes are small and a few large entries skew the settlement.
Here, a bookmaker's anti-fraud works not with an individual bet, but with anomalies in dynamics: a skew toward one outcome, synchronous entries from different platforms, amounts atypical for the market.
And the fourth is gaps in one's own settlement rules. If the regulations do not describe event cancellation, an odds error, or a refund, the settlement is done manually and often in the player's favor. Such places are bypassed systematically, and analytics do not cover them.
We start by digitizing all four channels and showing the share of deviations for each. Then we sort out what is covered by rules, what by models, and what by manual review.
What changes after implementation: effect in metrics
The first effect is the speed of reaction to an anomaly. Previously, a signal surfaced when the settlement had already passed, and the review went through complaints and statements: hours, sometimes days.
Online scoring of the event stream reduces the detection window to minutes, and for some cases the verdict is made before the bet is accepted.
Detection is built on a composition: rules for thresholds, speed and spread of bets, plus the Isolation Forest model, which finds deviations in session features without a pre-described scenario.
The practical point is that an arbitrageur changes tactics more often than we manage to rewrite a rule — a model based on behavioral features weathers such shifts calmly.
The share of arbitrage bets in turnover falls several times over: the scheme is cut off before settlement, not after. False blocks are the flip side, and here a combination of features is important: device, network, behavior, settlement history for the client.
With it, the share of erroneous verdicts drops to single-digit percentages, and manual review — by about two-thirds.
Refunds on disputed settlements are the same effect from the other side: the fewer decisions made 'by eye', the fewer disputes with the player.
Anti-fraud metrics are viewed together — detection window, share of cut-off schemes, false positives, and volume of manual review, otherwise improving one breaks another.
Detection modes: comparison of approaches to cutting off anomalies
Approaches differ not in accuracy 'in a vacuum', but in what data they need and on which class of attacks they break. Rules and thresholds give an explainable decision in milliseconds, but describe only the schemes the analyst has already seen.
Behavioral models guess the new, but require a labeled event stream and a carefully selected trigger threshold.
| Approach | When applicable | What is needed at the input | Where it stops working |
|---|---|---|---|
| Rules and thresholds | Explicit signs: multiple accounts from one device, a bet after a sharp odds movement, synchronous actions | Bet and login log, device directory, line history | Bypass via device change, proxy, and splitting the amount across accounts |
| Behavioral models | Mass scenarios where a fraudster disguises himself as an ordinary client | Labeled sample, features by time, bet frequency, and market depth | Rare schemes do not get into training — no signal, the share of false positives grows |
| Manual bet review | Disputed cases, large amounts, client appeals, and regulator requests | Account snapshot, match context, analyst's conclusion | Does not scale: review speed drops as the flow grows |
| Hybrid detection scheme | A working loop where both speed and explainability of the decision are needed | All the above data plus feedback from bet review | Requires maintenance: features and thresholds are revised regularly |
In practice, the loops are built as a funnel: rules cut off the obvious, the model evaluates the remainder, manual review handles the disputed and returns the verdict into training.
A hybrid detection scheme works only when the decision of each loop is saved together with the features at the time of the bet — otherwise the analyst's corrections do not turn into a training example.
The threshold is a controllable parameter, not a constant: it is kept where false blocks do not interfere with legitimate clients, and is revised after every spike.
The same principle is applied by external line monitoring at Sportradar — a discrepancy with the market estimate serves as a signal, not a verdict.
Without revising thresholds, both rules and behavioral models begin to cut honest bets, and the cost of error outweighs the gain from cut-off violators.
Anti-fraud implementation: stages of engineering work
The order of work here is set not by the model, but by the quality of labeling and the cost of error. A false positive on a live player costs more than a missed bot: support drowns in appeals, and a loyal client goes to a competitor.
That is why we build anti-fraud for a bookmaker starting from an audit and historical data — and only then touch the thresholds.
-
Audit of rules and incidents. We examine current limits, blocklists, and support requests: which schemes are already cut off, which pass through, where rules duplicate each other and hit normal players.
-
Assembly of historical data. We restore the label 'honest player / violator' from event logs, verify it against actual blocks and refunds, and discard periods where the labeling is unreliable.
-
Feature description. We form a set of signals by account and session: matches of devices and payment details, speed and rhythm of bets, group intersections, behavior before and after odds changes.
-
Threshold calibration. We select trigger boundaries for the profile of a specific line and sport — so that the share of false blocks remains within a given corridor.
-
Validation on historical data. We run the settings on a held-out period that did not participate in tuning: we look at which violators we miss and whom we hit unnecessarily, and correct the rules based on the result.
-
Shadow operation. We launch detection in observation mode in parallel with the manual work of the security service and compare verdicts line by line, without blocks.
-
Handover of regulations. We provide the feature description, threshold matrix, procedure for reviewing disputed cases, and instructions for revising rules when player behavior changes.
Each stage ends with an artifact that can be checked, not a presentation: a labeling log, a false positive report, a threshold table. This is what allows you to further change settings without us.
Artifacts and regulations: what we hand over to the client's loop
An anti-fraud loop does not live on its own: rules become outdated, arbitrageurs change tactics, and the shift composition in the security service is updated.
Therefore, we hand over not a 'working system', but a set of artifacts by which your analyst can change the detector's behavior without us. Below is what remains in your hands after launch.
- Rule configurations — thresholds, feature weights, aggregation windows, and whitelists are moved to separate files in your repository. An edit goes through review, and rollback to the previous version is one operation instead of manual blind editing.
- Access policies — a role matrix: who sees signals, who changes rules, who removes an account block. Critical actions are under double confirmation, and every edit goes into an immutable log.
- Data flow diagrams — the path from a client event to the verdict: sources, enrichment points, personal data retention periods. The diagram shows which features may be shared with adjacent systems.
- Instructions for the security service — what to do during a spike of similar triggers, how to distinguish false from real, where to escalate. Designed for a shift, not for a single expert.
- Rule testing scenarios — a labeled set of cases on which we run a change before rollout. The growth of false positives is visible before it reaches players.
- Degradation plan — which mode turns on when the event source is unavailable, which checks remain in operation, and how this affects decisions.
The set lives together with the system: rule changes and incident reviews are recorded in one log, so a revision in six months does not turn into log archaeology.
Case study: how a network of arbitrage bets and bots was cut off
The client is a betting operator with a market-average volume. Suspicious accounts were reviewed manually: up to 400 signals per day, a significant part remained unchecked, and arbitrage across different bookmakers and multi-accounting went to payouts before they were noticed. The reaction took hours and rested on one analyst.
What linked the accounts into one network
The signs turned out to be infrastructural, not gameplay-related. Matching device fingerprints and environment parameters, shared subnets and autonomous systems, intersecting payment chains, and synchronous bets on the same markets in a short window.
IP risk and geolocation data were taken from MaxMind, then a relationship graph was built: 1,800 accounts converged into clusters around 40 devices and 12 payment details.
Calibration took several iterations — early versions of the graph triggered on family accounts and clients behind a shared corporate connection.
The threshold for the number of shared features was raised, shared networks were moved to signal-only, and a block turns on only when two independent groups of features match.
After calibration, the precision of confirmed links reached 0.94, false blocks of legitimate clients dropped from 11% to 2%, and the time from signal to block decreased from 6 hours to 15 minutes.
Manual review decreased threefold: analysts took on new schemes instead of a stream of similar triggers, and arbitrage bets stopped reaching settlement.
How does bot detection differ from finding arbitrageurs?
Action automation and search for line discrepancies are different classes of violations, and they differ in the signal source.
For a bot, the execution itself is anomalous: intervals between steps are even, there are no pauses for reading the line, one device fingerprint holds several sessions. For an arbitrageur, the actions are human — the logic of bet selection is anomalous.
Bot detection relies on automation features: distribution of intervals between actions, reaction speed to odds changes, repeatability of scenarios across different accounts, synchronicity of entries.
The response here is technical — rate limiting, additional verification, session isolation, and breaking links between accounts.
Finding arbitrageurs is arranged differently: the signal lies in the structure of bets. These are paired bets on opposite outcomes in a narrow window, a narrow pool of markets, interest in odds before their movement, a spike in activity at the edges of the line.
The response is not a block, but risk management: personal limits, manual confirmation, line correction for a specific market.
Both tasks converge on one thing — player behavior over time. A single bet proves almost nothing; a sustained deviation in a sliding window relative to the player's own history and their cohort is significant.
The profile is calculated over a distance: the share of anomalous actions, the stability of the deviation, and the rate of its growth.
Confusing the classes is costly in both directions: a block based on automation does not stop an arbitrageur, and line limits silently lose a loyal player with an atypical style.
That is why the rules are separated, and thresholds and response measures are calibrated for each class separately.
Technical doubts: questions from analysts and engineers
Anti-fraud in a bookmaker is not a separate system, but an evaluation layer on top of an already working bet acceptance process. Analysts and engineers ask about the same thing: will current processes suffer, how many false positives will there be, how to review disputed cases.
How many false positives will there be on live traffic?
We do not block based on a single feature. The assessment accumulates across a set of signals and is returned as a risk rating with thresholds configured for the traffic profile: sports, bet type, acquisition channel.
A player above the threshold goes into a review queue, not immediately under account closure — the share of erroneous restrictions is several times lower than with the 'one match — block' rule.
Will we have to change the current platform and the bet acceptance core?
No. We connect to the account event stream — registrations, bets, withdrawals, device changes — through the standard exchange mechanisms that already exist in the platform. The model works in a separate loop and returns a risk assessment; the bet acceptance core is not rewritten. Rollback is disabling the evaluation stream.
How does the model catch up with new bypass schemes?
Reviewed cases go into labeling, and the model is further trained on it: features are reassembled, quality is checked on a held-out sample together with drift metrics. This is a regular cycle, not a one-time setup at the start — a new scheme is usually closed within a few weeks.
What to do if a block is disputed?
For each trigger, a log is saved: which signals fired and with what weight.
The decision is reproducible, so the case is reviewed by the log, not by the principle 'the model decided so': support sees the basis, the player is shown the reason, and an erroneous trigger can be removed and sent for further training.
Let's discuss the task: where the pilot begins
An anti-fraud pilot begins not with a model, but with your data: without confirmed violators there is nothing to train on, and without ordinary players there is nothing with which to measure false positives.
Therefore, the first step is a short review of what is already in the system, and only after that the work plan.
What is needed from the client:
- an export of bet, deposit, and withdrawal logs for a period that includes both ordinary players and known violators;
- technical identifiers: device, session fingerprint, address, time zone — links between accounts are built from them;
- a list of confirmed cases — bots, multi-accounts, arbitrageurs — with the date and a note on how the review ended;
- an anonymized copy or a test loop to compute on real volumes without loading the production database;
- current rules and trigger thresholds, if the service has already configured them manually;
- a responsible person on your side who confirms labeling and decides disputed cases.
In response, we return a plan, not general wording: which features we use, what the verification loop looks like, on what data it trains, and what accuracy it must achieve.
Separately, we record acceptance metrics and the rollback procedure if the quality turns out to be lower than expected.
The first measurable results are visible already on a retrospective check against your history: the share of caught violators at a given level of false positives and the review time for one case. Then shadow mode, comparison with your service's decisions, and only then blocks. Describe the task — we will return with an estimate and a plan.
