Anti-fraud and fraud analytics
1) Why do you need it
The purpose of the fraud circuit is to reduce financial losses (chargebacks, bonus abuse, cashing out), protect players from ATO and maintain regulatory/partner compliance without destroying UX. The basis is a risk-based approach (RBA), in which resources are directed to where risk and damage are maximum.
2) Threat taxonomy (iGaming context)
1. Multi-accounting (farms, proxy routing, document clones).
2. Bonus abuse (orbits of accounts, "carousel" depozit→vyvod, promotional arbitration).
3. Account Takeover (ATO) (phishing, password faces, SIM-swap).
4. Collusion (betting/play coordination; P2P/tournaments, PvP slots/missions).
5. Chargeback fraud (friendly fraud, card testing, intermediaries).
6. Payment schemes (third parties, "mules," cashing through quick cashouts).
7. Dock fraud/KUS bypass (synthetic personalities, deepfakes, bots).
8. Bot activity (registration/entry/bet scripts, emulators).
9. Affiliate fraud (cookie staffing, motivated traffic, hidden redirects).
10. Exploit mechanic (errors in limits, RTP drift, tournament/quest bugs).
3) Data and features (what to collect and how to cook)
Identification: email/phone, device fingerprint, browser signals, geolocation/IP-ASN.
KYC/KYB/KYA: document quality, selfie liveness, payer name match.
Payment: BIN/issuer, IP↔BIN↔dokument country match, frequency/amounts, returns/chargebacks.
Gaming: betting speed, variance, correlations with other accounts, "minimal risk."
Behavioral: session duration, transitions, form filling speed, erroneous inputs.
Graph: connectivity by device/card/address/ip/affiliate.
Service: flags of anti-boot systems, quality of affiliate traffic, client versions.
Feature store: a single versioned repository of features with online/offline consistency (millisecond scoring access).
4) Deterministic rules (rapid controls)
Examples (configurable thresholds):- R-01: IP country ≠ BIN country and ≠ country of the document → + 25 to risk, manual check at WD.
- R-02: ≥3 different payment instruments in 24 hours → + 15.
- R-03: output depozit→zapros
- R-04: correlation by device/address with a previously blocked account → block before review.
- R-05: fail shower/anti-bot → hard KYC, bonus ban.
- R-06: payment medium owner does not match profile → SOF/confirmation request.
Tips: version the rules, use canary inclusions and feedback from the case team.
5) ML scoring (flexibility and FP reduction)
Models: gradient boosting/trees, logreg, for graphs - GNN/Node2Vec, for text - simple embeddings of applications.
Goals: probability of ATO/chargeback/bonus abuse in the horizon of N days.
Features: devices, payments, connection graph, time series of rates, affiliate quality tags.
Explainability: SHAP/Reason Codes for support and appeals.
Drift: monitoring of PSI/metric fluctuations, autocalibration of thresholds.
6) Graph analytics
Tops: accounts, devices, maps, addresses, IP, affiliates.
Edges: "uses/connected to/belongs to/credited/output."
Patterns: clusters of "farms," triangles of translations, "stars" with a common device.
Use: prioritization of cases (cluster center above), prohibition of group payments before review.
7) Antibot and liveness
Device fingerprint + behavioral biometrics (mouse movement/timings).
Liveness (passive/active), anti-spoof (masks, replays).
Emulators/autoclickers: ADB/emulator signals, UI event patterns.
Rate limits/captcha adaptively, without killing conversion.
8) Controls by scenario
8. 1 Bonus abuse
Step bonuses (deferred bonus/sales releases), limits on FTD bonuses, "cooldown" by affiliate/device.
Graph limits (per "family" of accounts/devices).
Transparent conditions, anti-orientation of bets on minimal risk.
8. 2 ATO
MFA/push confirmation, risk-based login (new device/IP → additional check).
Secret markers in mail/SMS, password resets throttling.
Signals "not me" and a quick trash through the application.
8. 3 Chargers
3-D Secure/trusted methods, velocity rules.
Card/account holder match, "same method" for WD.
Dossier of evidence for disputes (logins, IP, sessions).
8. 4 Collusion/Tournaments
Abnormal correlations of results/bets, repeated sequences, frequent match-ups of the same players.
Secret "control" tables/tournaments to detect collusion.
9) Case management and investigation process
Pipeline: Alert → Qualification (L1) → Inquiry/Explanation → Decision (L2/MLRO) → Action (Limits/Block/SAR if necessary) → Post-Sea.
SLA (example):- High-risk WD/sanctions/payment - ≤4 -8 hours.
- ATO/safety - nemedlenno/≤2 h.
- Bonus abuse - ≤24 hours.
Tools: queue priority, letter templates, four eyes, WORM solution storage, reason codes.
10) Solution architecture
Event bus (real-time): logins, deposits, bets, WD, profile changes.
Fraud service: rules + online ML scoring (milliseconds).
Feature store: online/offline features with consistency.
Graph store: quick search for links and clusters.
Case system: queue, SLA, integration with support/CCM/payments.
Observability: metrics/logs/trails, version of rules/models, canary rolls.
11) Metrics and goals
Chargeback Rate/Net Fraud Loss (in% GGR/volume).
Precision/Recall alerts; False Positive Rate (especially on login/WD).
Time-to-Decision, Time-to-Payout (before and after measures).
Auto-clear / Manual-review rate.
ATO Containment Time and share of restored accounts.
Bonus Abuse Uplift (savings) and ROI measures.
Affiliate Traffic Quality: CR→FTD→депозитор, WD-ratio, chargeback-by-affiliate.
12) Privacy, Ethics and UX
Minimization of data, legal basis for processing; storage of ≥5 years for evidence.
Anti-bias: exclude sensitive signs; features - behavior/facts.
Explainability: reason codes in communications, understandable appeals.
UX balance: soft checks by default, signal escalation; not to block "clean" in vain.
13) Experiments and calibration
A/B tests of ML rules and thresholds; canary inclusions of 5-10% of traffic.
Cost matrices: FP vs FN price, profit threshold optimization.
Periodic recalibration (QM) , seasonality control/campaigns.
14) Interaction with Payments, KYC and AML
Payments: pre-auth/3DS, owner verification, "same-method" for WD, tracing.
KYC: liveness, NFC reading, re-verification at risk.
AML: SAR/STR on reasonable suspicion, sanction rescreening on WD, SOF/SOW on high-risk.
15) Checklists (operating)
Onboarding:- Anti-bots + device fingerprint.
- Geo/IP/BIN basic rules.
- KYC L1 (dock + liveness), sanctions/PEP.
- Start limits enabled by RG.
- Sanctions Rescreen/REP.
- Payment means owner match.
- Checking graph connections and behavioral anomalies.
- SOF when the threshold is exceeded.
- Urgent adjustment of rules/thresholds.
- Freeze disputed payments.
- Notification of payment partners/affiliates (as required).
- Post-sea and playbook update.
16) Typical mistakes and how to avoid them
Overregulation (killing conversion) → stepwise measures, canary tests.
Island solutions (no bus/profile) → centralize features and events.
No feedback → train models on case/chargeback outcomes.
Ignoring the graph → skipping clusters of "farms."
Lack of explainability → heavy appeals, conflict with support/regulator.
17) Example of Risk Action Matrix
18) Implementation (roadmap)
1. Identify targets (chargeback/abuse reduction, TTP ATO), KPIs and risk appetite.
2. Build an event bus, feature store, basic rules and case system.
3. Connect graph storage and online scoring ML.
4. Run canary tests, configure alerts and drift monitoring.
5. Train teams (support/compliance/payments), fix RACI.
6. Calibrate rules/models quarterly, audit and retro.
Result
An effective fight against fraud is a system: a single bus of events, a feature store, a hybrid of rules and ML, graph analytics, disciplined case management and thoughtful integrations with KYC/AML/payments. Add to that UX-thrifty, transparent metrics and regular experimentation - and you have a steady contour that reduces losses and preserves player conversion and trust.