Anti-Fraud-Engines: Signale, Scoring, Regeln

1) Anti-Fraud-Aufgabe und wichtige KPIs

Das Ziel ist es, die Verluste durch Betrug zu minimieren, mit einem maximalen Anfall von gewissenhaften Spielern und einer geringen Entscheidungsverzögerung. Top-Level-Metriken:

Betrugsrate (bei Einzahlungen/Gewinnen/Chargebacks), Chargeback-Rate, Bonus-Missbrauchsrate.
Approval rate/FPR (false positive rate), Precision/Recall, AUC/PR-AUC für Modelle.
Latenzlösungen (p95/p99, Echtzeit-Zielbudget: 50-150 ms), Kosteneinsparungen vs. baseline.
Manuelle Überprüfung der Rate und SLA durch Fallanalyse.

2) Echtzeit-Architektur

Typisches Förderband:

1. Sammlung von Veranstaltungen: Einzahlung, Auszahlung, Registrierung, Login, Wette, Änderung der Details, Erstellung eines Tickets, Verwendung von Aktionscodes.

2. Bereicherung: KYC/AML-Status, Verhaltensdaten, Geo/Device, Graph-Links, Risiko-Profil des Zahlungsanbieters.

3. Echtzeit: Event-Bus (Kafka/PubSub), Feature-Store mit Fenstern 5 min/1 Stunde/24 Stunden, Scoring-Service (Online-Modell + Regeln).

4. Aktionen: allow/deny/challenge (3DS/SCA, extra KYC), limit, block promo, manuelle überprüfung.

5. Fidbek-Loop: Charjbacks, bestätigte Fälle, Appelle → Markierungen → Umschulungen.

6. Überwachung: Dashboards und Alerts für Metriken, Datendrift, „stille“ Fenster und Bursts.

3) Signale (Features) erster Ordnung

Identifikation und Umgebung:

Gerätefingerprint (WebGL/Canvas, User-Agent-Stabilität, Schriftarten), IP-Reputation (VPN/Hosting), ASN, Proxy.
Geo-Verhalten: ip-geo vs payment BIN/Adresse, Land/Zeitzone ändern.
Verhaltensbiometrie: Klick-/Scrollrhythmus, Geschwindigkeit und Maus- „Jitter“, Druckrhythmus, Mobile-Gyro.
Bot-Muster: Headless-Browser, ungewöhnlich stabile Timings, Skript-Wiederholungen.

Finanzen und Zahlungen:

BIN-Zahlen, Emittent, Risikoland, 3DS-Status, Kartenrückgaben.
Velocity-Daten: n Einzahlungen für 10 Minuten/1 Stunde, Betrag pro Fenster, Zahlungsversuche mit verschiedenen Karten/Geldbörsen.
Crypto-Red-Flags: Einlagen von Mixern/risikoreichen Börsen, UTXO-Graph-Link „gebrochen“.

Account und Soc-Graf:

Mail-Provider/Domain-Alter, Namensgeber/identische Adressen, Telefon/Karte/Geräteübereinstimmung.
Multi-Account/Cluster-Erkennung: geteilte Geräte/IPs, wiederkehrende Registrierungs- und Eingabemuster.
Promo-Missbrauch: Anstieg der Registrierungen pro Adresse/Subnetz, schnelle Cash-out-Boni, Einzahlung-Mindestauszahlungsrate-Zyklen.

Spielverhalten:

Session Velocity (Zeit bis zum ersten Einsatz, durchschnittliches Intervall zwischen den Einsätzen), Wetten ohne Variabilität, Spielen nur mit Boni, Stoppen der Aktivität unmittelbar nach dem Wagering.

4) Scoring-Modelle: Von der logistischen Regression zum Graph-ML

Die Ansätze werden kombiniert:

Gradientenverstärkung/logistische Regression für interpretierbare, schnelle Modelle in der Produktion.
Sequenzmodelle (GBDT auf Aggregaten mit Zeitfenstern, LightGBM/CatBoost; seltener - LSTM/Transformer bei Ereignissen).
Graphenmodelle (Node2Vec/GraphSAGE) zur Identifizierung von Multiaccount-Clustern.
Ensembles und Risiko-Score: Wir normalisieren Score 0.. 100. Schwelle A - auto-allow, B - challenge/KYC, C - deny.

Beispiel für ein einfaches 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) Regeln: warum sie sind, wenn es ML gibt

Die Regeln werden benötigt für:

Schnelle Reaktionen auf neue Schemata (Zero-Day-Muster).
Rechtlich transparente Fälle (Audit/Begründung).
Feine Politik (regionale Ausnahmen, VIP-Ebenen, anbieterspezifisch).

Typische Regeln:

Velocity: `count(deposits, 10m) ≥ 3` и `distinct_cards_24h ≥ 2` → CHALLENGE.
Geo-mismatch: BIN_country ≠ IP_country и нет 3DS → DENY.
Device reuse: „device _ hash“ traf sich auf ≥ N Konten in 72 Stunden → BAN/REVIEW.
Promo: neues Konto + Bonus + Einsatz auf Minimum + Versuch einer sofortigen Auszahlung → HOLD + Verifizierung.
Crypto: eingehende UTXOs von High-Risk-Clustern → HOLDs bis CUS/Geldquelle.

Regelverwaltung: Entscheidungsbaum/Entscheidungstabelle, Prioritäten, Konflikte, „Schattenmodus“ vor dem Einschalten. Logs: Welcher Ast funktionierte, welche Fici entscheidend sind.

6) Balance zwischen Risiko und Conversion

Risk-based authentication: SCA/3DS/доп. KYC - nur an den Grenzen der Schnellkochtöpfe.

Whitelist/Graylist/Blacklist auf BIN-Ebene, Anbieter, Partner, VIP.

A/B-Tests der Politik: Schwellenwertvergleich, Fehlerkosten vs Umsatz, Retention.

Erklärbarkeit: SHAP/Feature-Bedeutung auf dem Produkt für Appelle und Sapport-Training.

7) Graphenanalyse und Multiaccount

Knoten: Konten, Geräte, Karten, Telefone, IP. Röbra: „verwendet“, „gebunden“.

Metriken: Triaden/Klicks, Konnektivitätskomponenten, Zentralität.

Regeln auf der Spalte: wenn in der Komponente> k neue Konten für 24 Stunden mit dem gleichen Gerät fingerprint → Block Promo, Grenzen für die Ausgabe, manuelle überprüfung der wichtigsten Knoten.

8) Über Promo-Betrug/Bonus-Missbrauch

Signale:

Serielle Registrierungen mit der gleichen Art von Adressen, einmalige Post.
Schnelles Ausführen des minimalen Wagerings und Versuch der Ausgabe „auf Null“.
Koordination über die gleichen Geräte/IP/Empfehlungen.
Mitigieren: Limits für Boni auf dem Gerät und Zahlungsdetails, KYC bei der ersten Auszahlung, personalisierte Bedingungen wagering, velocity-cap auf promo.

9) Prozesse und Fallmanagement

Queueing & Prioritization: Priorisierung von Fällen nach der Höhe des Risikos/Verlustes.

Playbooks für Analysten: Checklisten, welche Nachweise zu sammeln sind (Screenshots von Transaktionen, Kontoauszüge, Erklärungen).

SLA: Auto-Lösung ≤ 150 ms, manuelle Fälle p95 ≤ 24 h; Hochwerteskalation ≤ 2 Stunden

Appelle: Urteilsspur, Revisionshierarchie, Rückblick auf fehlgeleitete Flaggen.

10) Daten und Qualität

Feature Store: Online-Fenster (5min, 1h, 24h) + Offline-Einheiten.

Data quality: completeness, freshness, drift. Warnungen, wenn der Null-/Fallback-Anteil steigt.

Versionierung: Ereignismuster, Modellversionen und Regelsätze, „replay“ auf Historie.

11) Modellüberwachung und Drift

Daten-Drift/Konzept-Drift: PSI/KS-Tests, Saisonalitätskontrolle (Abende/Wochenende/Promo-Releases).

Online-Überwachung: Kalibrierung des Scoring (Brier Score), Stabilität der Schwellen.

Shadow/Champion-Challenger: Neue Modelle in den Schatten stellen, Vergleich durch Offline-Shortcuts/späte Charjbacks.

12) Compliance und regulatorische Anforderungen

KYC/AML: Sanktionslisten, PEP, Mittelquellen; manuelle Prüfschwellen.

DSGVO/Daten: Minimierung, Purpose Limitation, Erklärbarkeit von Lösungen.

PCI DSS (Karten), SCA/PSD2 (EU), MGA/UKGC/Curacao-Anforderungen usw.

Audit: Unveränderliche Protokolle von Entscheidungen, wer/wann eine Regel oder ein Modell geändert hat.

13) Risikoprofile und Maßnahmen

Beispiel für eine Aktionsrichtlinie:

Score <30 → ALLOW, ohne Reibung.
30-59 → CHALLENGE: SCA/3DS, selektives KYC (Selfie + Dock), Summen-/Geschwindigkeitslimit.
60-79 → HOLD: Auszahlungsstopp, Quellenabfrage, manuelle Überprüfung.
≥ 80 → DENY/BAN: Block von Promo/Schlussfolgerungen, Schließung des Kontos bei Bestätigung.

14) Leistung und Zuverlässigkeit

Latenzbudget: Leichte Zahlen online, schwere in Caches/gelesenen Fenstern.

Fail-safe: Degradierung zu Grundregeln bei Modell-/Fich-Stora-Ausfall; Timeouts und Circuit Breaker.

HA: mehrere Scoring-Service-Instances, Stateless, Blue-Green-Deploy, kanarische Releases.

Rate-Limits für kritische Aktionen (Registrierung, Änderung der Details, Schlussfolgerungen).

15) Beispiel für ein Ereignis und eine Motorantwort

Eintritt (abgekürzt):

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
}

Die Antwort des Anti-Fraud:

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) Umsetzung: Stufenplan

1. Entdeckung: Inventar von Ereignissen, Quellen, SLA.

2. MVP: Grundregeln + einfaches Modell, Latenz ≤ 150 ms.

3. Graph-Layer: Clustering des Multi-Accounts, Sanktionen für Promo.

4. Verhaltensbiometrie: Reduzierung von Bots/Skripten.

5. Conversion-Optimierung: risikobasierte Authentifizierung, Schwellenwerte.

6. Operational: Case Management, Alerts, Berichte für die Regulierungsbehörde.

7. Kontinuierliche Verbesserung: Shadow-Runs, Retrain alle N Wochen, Post-Mortems.

17) Checkliste praktischer Maßnahmen

Einheitlicher Feature Store mit Fenstern und SLA-Updates.
Protokoll der Erklärbarkeit von Entscheidungen (Ursachenprotokoll, SHAP-Karten).
Entscheidungstabelle mit Prioritäten, Konflikttests.
Rate-Limits und Hold-Richtlinien für die Ausgabe/Promo.
Graph-Checks des Multi-Accounts vor der Bonusvergabe.
A/B-Rahmen für Schwellenwerte und Richtlinien.
Fail-Safe-Modus ohne Modell und ohne externe Integrationen.
Regelmäßige Rückblicke auf falsch positive/falsch negative Fälle.

Zusammenfassung

Eine starke Anti-Fraud-Engine ist kein „Regelpaar“, sondern eine Live-Schaltung aus Signalen, Scoring und Managed Policies, die schnell, selbsterklärend und adaptiv arbeitet. Kombinieren Sie ML-Scoring mit klaren Regeln, Graphenanalyse und risikobasierter Authentifizierung - und Sie reduzieren Betrugsverluste ohne übermäßige Reibung für ehrliche Spieler.