AI system iGaming: why rules don't catch multi-accounts
Classic anti-fraud relies on rules and thresholds: more than three registrations from one device, bonus claimed in the first minutes after deposit, shared payment details across two accounts.
As long as schemes are of the same type, this is enough — the trigger is unambiguous, and review takes minutes.
But a rule describes only an already known scheme.
Multi-accounts drift faster than thresholds can be rewritten: device changes, rotation of payment methods, distribution of activations across different subnets — and one participant turns into dozens of "independent" players with their own history.
The cost shows up in two places. Bonus abuse stays below the threshold: networks split into groups of three or four accounts, below the cutoff line.
The manual review queue grows — an analyst spends a shift on similar triggers instead of complex cases, the share of confirmed violations in the queue drops to single-digit percentages, and payouts on fake profiles stall and irritate real players.
Raise thresholds — open the bonus gap wider; lower them — drown the review in the flow. The contradiction is not resolved by tuning, because the decision is made on a single attribute, without the context of connections between accounts, devices, and payments.
The AI system iGaming evaluates not a single condition but the totality of these connections and behavior — below we break down how this closes the bottleneck.
Effect of the risk model: false positives, review, response time
We fix the decision quality metrics before launch: false positive rate, detection recall, time from event to decision, and the share of cases that an analyst closes manually.
Without these numbers, the debate about "whose model is better" remains a matter of taste — so charts for each metric live on a Grafana dashboard and update on the same event stream as scoring.
False positives and trust in decisions
A false positive is a blocked withdrawal for a real player, a support ticket, and a manual review.
We select the threshold not by abstract accuracy but by the cost of error in the scenario: it is higher for withdrawals and lower for bonus abuse, and it is configured separately by segment.
Trust in decisions grows from explainability: in the review card, an analyst sees the features, the history of similar confirmed cases, and the version of the model that issued the verdict.
The load on analysts drops due to queue prioritization — routine cases are closed with one action, not by rechecking from scratch.
Incident response time
While rules live in code and are rolled out by release, a new scheme has time to operate before the first complaint.
When the configuration can be changed on the fly, response time is measured in hours: rules, weights, and features are edited without rebuilding the core, and the update is run against historical data before being enabled in the stream.
A separate effect is the disappearance of a class of similar schemes. Multi-accounting from shared devices and repeated bonus chains are closed automatically by graph connections, and these reviews immediately enter the training sample.
Scheme misses decrease for the same reason: the model is updated on fresh confirmed cases, not on data from past periods.
Operating modes: event stream, batch recalculation, manual rules
The operating mode is chosen not by preference but by the time budget for a decision and the amount of history that needs to be taken into account.
The same set of models can work in a stream, recalculate accumulated data, and run up against manual rules — these are three different load profiles, three different error classes, and three different rollback scenarios.
| Option | When it fits | Limitations |
|---|---|---|
| Event stream | Risk assessment at the moment of action: entering the game, bet, withdrawal, payment method change | Sees only a sliding window, resources are held constantly, the decision cannot be replayed retroactively |
| Batch recalculation | Linking accounts, updating risk profiles, testing rules on history, reporting | Delay from minutes to hours, does not protect at the moment of the operation |
| Hybrid rules | Regulatory thresholds, limits, mandatory checks, rare anomalies | Limited coverage, requires regular review, handles multidimensional dependencies poorly |
Event stream
The model responds before the operation is confirmed. Features are taken from a sliding window: action frequency, device change, discrepancies in the payment profile, session behavior.
The decision latency here is limited by the interface response, so only what actually changes the outcome remains in the stream, while heavy checks go to the background.
Batch recalculation and hybrid mode
Batch recalculation runs history again: it collects linked accounts, recalculates risk profiles, and tests hypotheses on accumulated data. Completeness here is higher, but the delay makes it useless at the moment of the operation itself.
The hybrid closes the gap: the stream issues a preliminary decision, the batch refines labels and corrects erroneous triggers, and manual rules hold regulatory thresholds and limits — what cannot be entrusted to statistics.
Implementation step by step: data audit, design, validation, handover
Implementation begins not with an algorithm but with an inventory of what already exists in the system.
We look at which events are recorded for bets and payments, with what delay confirmations arrive from payment systems, and where the connection between account, device, and payment method is lost.
Everything else depends on the completeness of this data: without stable connections between entities, features turn out noisy and thresholds uncalibrated.
Data audit and problem statement
- We break down the sources: event retention depth, share of missing values in fields, delays between an action and its recording in the log. The output is a data map with an honest list of gaps that will have to be closed before launch.
- We design features: aggregates of activity over windows of different lengths, deviation of a player's behavior from their own usual norm, rate of bet growth, intersections of devices and payment instruments. We calculate them from primary events, not from ready-made summary reports.
- We configure thresholds on labeled confirmed cases: separately for deposits, withdrawals, and gaming sessions. A threshold is always a trade-off between missed incidents and false blocks, and we fix this boundary together with your support service.
Validation on historical data
- We run the loop on closed periods: the system processes past events and issues decisions that we compare with actual outcomes. We calculate what share of real incidents would have been caught and how many false positives would have had to be reviewed manually.
- We check robustness: we look at behavior on slices with different player composition and on data that was not present during configuration. If quality drops, the cause is usually features tied to outdated schemes — we remove those.
- We transfer the loop into operation: a decision queue for analysts with justification for each trigger, a log and quality metrics, a threshold review procedure, and retraining rules. After acceptance, your team runs the system independently, and our engineers remain in contact under an agreed procedure.
Deliverables: data flow diagrams, rules, review procedures
The document set is not an appendix to the report but a working tool that your team uses to further develop the system. We hand over everything needed for independent operation: from the data flow diagram to the procedure for reviewing disputed triggers.
Diagrams and configurations
- Data flow diagram: from bets and sessions through normalization to the feature store — with latency monitoring and points where events may be lost.
- Feature list: for each one — source, calculation window, update frequency, and the reason it was included in the model.
- Access policies: who sees raw events, who sees only aggregates, who changes trigger thresholds; roles are described for your processes.
- Solution documentation: architecture, data composition, quality metrics, and actions to take during degradation.
- Anti-fraud and personalization rule configurations: thresholds, weights, exceptions — with comments explaining why each value exists.
Procedures and team training
- Appeals review procedure: how a player disputes a block, who checks the features and within what time frame, and where the decision is recorded.
- Support instructions: typical scenarios, what is closed on the first line, what is escalated to an analyst.
- Team training: review of real cases, transfer of rights to configure rules and thresholds, acceptance criteria for changes.
A month after launch, you run the system yourselves: you add features, tighten rules, and review disputed blocks. We remain for model development and complex cases.
Case study: false block rate and appeal review time
An operator with several thousand active accounts per day reviewed every anti-fraud trigger manually: an analyst opened the profile, checked deposit history, devices, and payment details, and wrote a summary using a template.
The queue grew faster than the team could handle, and some legitimate players left before the check was finished.
What it was like before implementation
Rules triggered on amount threshold and geolocation, without behavioral features, so entire cohorts of ordinary players were blocked.
The false block rate stayed around one third of triggers, the median appeal review took more than half an hour, and only a quarter of checks were closed automatically.
The error cost in both directions: real fraud passed between the rules, while a legitimate player left for a competitor.
What changed after and how it was measured
We added a risk assessment layer on top of the rules: instead of a single threshold, the model calculates probability based on behavior — input speed, device change, payment profile mismatch, anomalies in the gaming session.
Thresholds were split by level: low risk — auto-approval, medium — automatic additional check, high — rejection with a fast appeal path.
Measurements were taken via Grafana as separate slices by payment method and device type: the false block rate decreased from 31% to 9%, median review time — from 38 to 5 minutes, and the share of automatic decisions grew from 27% to 76%.
We retrain the model on labels from already reviewed appeals, and once a week we compare the share of appeals and refunds — this way, feature drift does not quietly shift the thresholds.
How AI assessment differs from hard rules and when both layers are needed
A hard rule is a predicate over event fields: total bets over a window, payment instrument change, mismatch of geo and device, repeated login from one address.
It triggers instantly and is explained in one line, but it breaks down where a scheme is assembled from legitimate actions, each of which individually does not exceed the threshold.
Model-based assessment looks at hundreds of features at once and catches composite schemes, but its decision cannot be presented to either a player or a regulator without an explanation layer. Hence the choice is not "either/or" but "what goes on which layer."
| Layer | Transparency | Configuration speed | Resistance to evasion |
|---|---|---|---|
| Hard rules | Full: the condition can be read in the log | Hours: new logic without retraining | Low: a known threshold is bypassed by splitting amounts |
| Model-based assessment | Requires an explanation layer | Days: labeling, training, validation on history | High: reacts to combinations of features |
| Hybrid loop | Rule as cause, model as risk assessment | Fast start on rules, model on top | Maximum: rule evasion is caught by the model |
In a hybrid loop, rules work as policy: mandatory blocks, responsible gambling requirements, age and self-exclusion restrictions remain deterministic and do not depend on model weights.
The model ranks the residual flow and suggests which features are ready to be turned into a rule and which are too noisy.
Decision explainability is not reporting but a working function: the SHAP add-on shows the contribution of features to the score, and a triggered rule identifies itself by name.
Every decision is reproducible: the version of the rule set, the model version, and the feature snapshot are stored, so a player's appeal is reviewed based on facts, not memory.
Common technical concerns: data, explainability, false declines
Before starting, clients ask the same questions: will the accumulated data be enough, who is responsible for labeling quality, what happens during model drift, and how not to lose real players to false declines. Below are short answers to the point, without presentation-style wording.
Is the data enough if the history is short?
We cover the cold start by transfer from similar segments and rules on confirmed incidents: deterministic scoring works immediately, and the model connects as a second loop once enough labeled cases have accumulated.
Labeling is based on decisions already made by the security service — confirmed fraud, erroneous block, normal — plus active selection of disputed episodes that most refine the boundary.
How is each trigger explained?
We return every decision with a breakdown of contributions: which features raised the risk and by how much, and what data it is based on. The analyst sees the reason, not a black box, and can challenge the verdict — the feedback returns to retraining.
What to do about model drift?
We monitor the divergence of the input feature distribution and the share of confirmed triggers. Beyond the threshold — retraining on a fresh window and a shadow run of the new version alongside the current one: we switch only after it does not underperform on the live stream.
False declines and responsible gambling — how to combine them?
We limit the share of automatic blocks and route disputed cases to a manual review queue prioritized by amount and frequency. Responsible gambling signals are a separate layer: change in pace of play, sharp increase in limits, night sessions.
The response here is not a block but a limit, a pause, or a support contact — with an action log for regulatory reporting.
Let's discuss the task: what data exists and what risk loop is needed
So that the scope estimate is based on facts rather than guesses, we structure the first conversation as an audit of data and task boundaries. We break down where signals come from, what is already being done with them, and where time or value is currently being lost. After the meeting, we return with a data map, a scope estimate, and a phased implementation plan.
In the first meeting, we need answers to the following questions:
- What event sources are available — bets, deposits and withdrawals, sessions, support requests, correspondence — and in what form they are stored: exports, logs, stream.
- How deep the history is and whether there are confirmed cases of violations, who recorded them and by what attribute.
- How decisions are made now: manual rules, manual review, who issues the final verdict and how much time it takes.
- What restrictions exist on data and access: where it is stored, what is permissible to use for model training, and what regulatory requirements exist for retention and timelines.
- Which risk loop is the priority: payments and bonus abuse, multiple accounts, signs of risky play.
- By which metrics we will consider the pilot successful: false positive rate, incident response time, share of operations that passed automatic checks.
- Who on the client side grants access and confirms labeling — without this, timelines shift.
We run the first pilot on historical data: the model and rules are tested on already accumulated events, without load on the production loop and without changes to current processes.
You can see real quality on your data, not on a demo set, and it is clear what needs refinement before production launch.
Describe the task and what you already have on these points — we will return with a scope estimate and an implementation plan.
