Anti-fraud engines: signals, scoring, rules

1) Anti-fraud task and key KPIs

The goal is to minimize losses from fraud with the maximum uproar of conscientious players and a low delay in the decision. Upper-level metrics:

Fraud rate (by deposits/winnings/chargeback), Chargeback rate, Bonus abuse rate.
Approval rate/FPR (false positive rate), Precision/Recall, AUC/PR-AUC for models.
Latency solutions (p95/p99, target budget real-time: 50-150 ms), Cost savings vs baseline.
Manual review rate and SLA for case analysis.

2) Real-time architecture

Typical conveyor:

1. Collection of events: deposit, withdrawal, registration, login, rate, change of details, creation of a ticket, use of promotional codes.

2. Enrichment: KYC/AML statuses, behavioral features, geo/device, graph connections, payment provider profile risk.

3. Real time: event bus (Kafka/PubSub), feature store with windows 5 min/1 hour/24 hours, scoring service (online model + rules).

4. Actions: allow/deny/challenge (3DS/SCA, additional KYC), limiting, promo block, manual check.

5. Fidbeck loop: chargers, confirmed cases, appeals → markings → retraining.

6. Monitoring: dashboards and alerts by metrics, data drift, "quiet" windows and bursts.

3) First Order Features

Identification and environment:

Device fingerprint (WebGL/Canvas, User-Agent stability, fonts), IP reputation (VPN/hosting), ASN, proxy.
Geo-behavior: unsynchronized ip-geo vs payment BIN/address, country/time zone change.
Behavioral biometrics: click/scroll rhythm, mouse speed and shake, print rhythm, mobile-gyro.
Bot patterns: headless browsers, abnormally stable timings, script repetitions.

Finance and Payments:

BIN features, issuer, risk country, 3DS status, card returns.
Velocity features: n deposits per 10 min/1 hour, amount per window, attempts to pay with different cards/wallets.
Crypto-red flags: deposits from mixers/high-risk exchanges, UTXO "broken" graph connection.

Account and social graph:

Provider mail/domain age, namesakes/same addresses, phone/card/device matches.
Multi-account/Cluster detection: common devices/IP, repeating patterns of registration and inputs.
Promo bonus: a surge in registrations to one address/subnet, quick cash-out bonuses, deposit-minimum rate-withdrawal cycles.

Gaming behavior:

Session velocity (time to first bet, average interval between bets), bets without variability, playing only with bonuses, stopping activity immediately after wagering.

4) Scoring models: from logistic regression to graph-ML

The approaches are combined:

Gradient boosting/logistic regression for interpreted, rapid models in prod.
Sequence models (GBDT on time window units, LightGBM/CatBoost; less often - LSTM/Transformer on events).
Graph models (Node2Vec/GraphSAGE) for identifying multi-account clusters.
Ensembles and risk rate: we rate the rate 0.. 100. Threshold A - auto-allow, B - challenge/KYC, C - deny.

An example of simple scoring (pseudocode):


risk = 0 if ip_is_hosting: risk += 25 if device_reused_over_5_accounts_24h: risk += 30 if deposit_velocity_1h > 3: risk += 20 if email_domain_new or temp: risk += 10 if chargeback_history: risk += 40 score = min(100, risk)
decision = "ALLOW" if score < 30 else "CHALLENGE" if score < 60 else "DENY"

5) Rules: Why are they if there is ML

Rules are needed for:

Quick reactions to new schemes (zero-day pattern).
Legally transparent cases (audit/justification).
Fine policies (regional exceptions, VIP levels, provider-specifics).

Model rules:

Velocity: `count(deposits, 10m) ≥ 3` и `distinct_cards_24h ≥ 2` → CHALLENGE.
Geo-mismatch: BIN_country ≠ IP_country и нет 3DS → DENY.
Device reuse: 'device _ hash' met on ≥ N accounts in 72 hours → BAN/REVIEW.
Promo: new account + bonus + bet at minimum + attempt to instantly withdraw → HOLD + verification.
Crypto: incoming UTXO from high-risk clusters → HOLD to CCM/source of funds.

Rule management - Decision Table, priorities, conflicts, shadow mode before enabling. Logs: which branch worked, which features are decisive.

6) Balance between risk and conversion

Risk-based authentication: SCA/3DS/доп. KYC - only on boundary pressure bands.

Whitelist/graylist/blacklist at BIN level, providers, partners, VIP.

A/B tests of policies: comparison of thresholds, cost of error vs revenue, retention.

Explainability: SHAP/feature importance on the prod for appeals and support training.

7) Graph analysis and multi-account

Nodes: accounts, devices, maps, phones, IP. Ribs: "used," "connected."

Metrics: triads/clicks, connectivity components, centrality.

Rules on the column: if in the component> k new accounts in 24 hours with the same device fingerprint → a promo block, output limits, manual verification of key nodes.

8) About promo fraud/bonus abuse

Signals:

Serial registrations with the same type of addresses, one-time mail.
Fast execution of minimum wagering and attempt to zero.
Coordination through the same devices/IP/referrals.
Mitigate: limits on bonuses for the device and payment details, KYC at the first withdrawal, personalized wagering conditions, velocity-cap on promo.

9) Processes and Case Management

Queueing & Prioritization: prioritization of cases by the amount of risk/loss.

Playbooks for analysts: checklists, what evidence to collect (screenshots of transactions, statements, explanations).

SLA: auto-solution ≤ 150 ms, manual cases p95 ≤ 24 h; high-value escalation ≤ 2 hours

Appeals: decision tracing, revision hierarchy, retrospective of erroneous flags.

10) Data and quality

Feature store: online windows (5 min, 1 h, 24 h) + offline aggregates.

Data quality: completeness, freshness, drift. Alerts when the null/fallback share grows.

Versioning: event schemas, model versions and rule set, "replay" on history.

11) Model monitoring and drift

Data drift/concept drift: PSI/KS tests, seasonality control (evenings/weekends/promo releases).

Online monitoring: scoring calibration (Brier score), threshold stability.

Shadow/Champion-Challenger: bringing new models into the shadows, comparison by offline labels/late chargebacks.

12) Compliance and regulatory requirements

KYC/AML: sanctions lists, PEP, sources of funds; manual check thresholds.

GDPR/data: minimization, purpose limitation, explainability of solutions.

PCI DSS (cards), SCA/PSD2 (EU), MGA/UKGC/Curacao requirements, etc.

Audit: unchangeable decision logs, who/when changed the rule or model.

13) Risk profiles and actions

Example of an action policy:

Score <30 → ALLOW, frictionless.
30-59 → CHALLENGE: SCA/3DS, selective KYC (selfie + dock), amount/speed limit.
60-79 → HOLD: freeze withdrawal, request source of funds, manual review.
≥ 80 → DENY/BAN: promo/output unit, account closure upon confirmation.

14) Performance and reliability

Latency budget: light features online, heavy ones in cached/presented windows.

Fail-safe: degradation to the basic rules in case of model/feature failure; timeouts and circuit breaker.

HA: several instances of scoring service, stateless, blue-green deploy, canary releases.

Rate-limits for critical actions (registration, change of details, conclusions).

15) Example of an event and engine response

Entrance (abbreviated):

json
{
"event": "withdraw_request",  "user_id": "u_92871",  "amount": 1200. 00,  "currency": "EUR",  "ip": "185. 12. 34. 56",  "device_hash": "d:1a2b3c",  "bin_country": "GB",  "ip_country": "DE",  "kyc_status": "BASIC",  "velocity_withdraw_24h": 3,  "bonus_active": true,  "wagering_progress": 22
}

Anti-fraud answer:

json
{
"decision": "HOLD",  "score": 68,  "reasons": ["Geo_mismatch", "Withdraw_velocity_high", "Active_bonus_low_wagering"],  "actions": ["Request_KYC_Level2", "Freeze_withdrawal_48h", "Notify_analyst_queue_high"]
}

16) Implementation: phased plan

1. Discovery: inventory of events, sources, SLAs.

2. MVP: basic rules + simple model, latency ≤ 150 ms.

3. Graph layer: multi-account clustering, promo sanctions.

4. Behavioral biometrics: reducing bots/scripts.

5. Conversion optimization: risk-based authentication, thresholds.

6. Operating system: case management, alerts, reports for the regulator.

7. Continuous improvement: shadow runs, retrain every N weeks, post mortems.

17) Checklist of practical measures

Single feature store with windows and SLA updates.
Decision explainability protocol (reason log, SHAP cards).
Decision table with priorities, conflict tests.
Rate-limits and hold-policies for output/promo.
Graph checks of multi-account before accrual of bonuses.
A/B frame for thresholds and policies.
Fail-safe mode without model and without external integrations.
Regular retrospectives of false-positive/false-negative cases.

Resume Summary

A strong anti-fraud engine is not a "couple of rules," but a living circuit of signals, scoring and managed policies that works quickly, explainably and adaptively. Combine ML scoring with clear rules, graph analysis and risk-based authentication - and you will reduce fraud losses without excessive friction for honest players.