Operations und Compliance → AML-Richtlinien und Transaktionskontrolle

AML-Richtlinie und Transaktionssteuerung

1) Ziel und Umfang

Ziel der AML-Politik ist es, die Nutzung der Plattform für Geldwäsche und Terrorismusfinanzierung zu verhindern, indem Fehlalarme und die operative Belastung minimiert werden. Die Richtlinie gilt für den gesamten Lebenszyklus des Spielers: Registrierung → Einzahlungen → Spiel/Transfers → Auszahlung; sowie auf Affiliates, Anbieter und Zahlungspartner.

2) Prinzipien (risikobasiert & evidence-by-design)

1. Risikobasierter Ansatz (RBA): Überprüfungen und Schwellenwerte hängen vom Risikoprofil (Land, Zahlungsmethode, Verhalten, Beträge) ab.
2. Layered Controls: Eine Kombination aus CUS/Sanktion/RER, Verhaltensanalyse und manuellen Untersuchungen.
3. Evidence-by-Design: Jede Lösung hat Artefakte: Datenquellen, Screenshots, Protokolle, exportierte Berichte.
4. Privacy-first: PD-Minimierung, Maskierung, rollenbasierter Zugriff, kontrollierte Retention-Policy.
5. Erklärbarkeit: Regeln und Modelle sind interpretierbar; für ML - Zeichen/Bedeutung/Fallbeispiel.
6. Continuous Improvement: Schwellenwerte einstellen, Feedback von MLRO und Retro zu den Fällen.

3) Rollen und Verantwortung

MLRO (Money Laundering Reporting Officer): Eigentümer des AML-Prozesses, endgültige Entscheidungen über SAR/STR, Kommunikation mit Aufsichtsbehörden/Banken.
AML Ops: Untersuchungen, Kommunikation mit Spielern/Banken, Kontrolle von SLA-Fällen.
Data/BI & Risk Analytics: Regel-/Modellunterstützung, Überwachung der Detektionsqualität.
Zahlungen/Ops: Einhaltung von Grenzen und Hold/Reverse-Verfahren, Transaktionsverfolgung.
Sicherheit/DSB: Datenschutz, Zugriffe, Datenschutzvorfälle.

4) Spieler- und Segmentrisikomodell

• Geo/IP/Wohnsitz, Dokument und KYC-Methode.
• Einzahlungs-/Auszahlungsmethoden, Vielzahl von Zahlungsinstrumenten.
• Aktivität: Beträge, Häufigkeit, Winrate/Lossrate, Nachtsitzungen, Korrelation mit anderen Konten.
• Geräte/Fingerprint, Schnittpunkte IP/Geräte/Zahlungsdetails.

Segmente: Low/Medium/High/Prohibited.
Routing-Engine: Niedrig - vereinfachte Prüfungen; Hoch - EDD/hold/constraints.

5) KYC, Sanktionen und PEP

Tiered KYC: „KYC1 (Identität) → KYC2 (Adresse) → EDD (zusätzliche Dokumente/SoF)“.
Sanktionen/RER: Überprüfung bei der Registrierung, bei signifikanten Ein-/Auszahlungsschwellen und bei Änderungen der Angaben.
SoF/SoW: durch Auslöser (hohe Umdrehungen, Profildisparität, VIP).
Retention: Aufbewahrung von Dokumenten gemäß den Anforderungen der Gerichtsbarkeit; Zugang über vault/Ausgabekontrolle.

6) Transaktionskontrolle (Regeln und Signale)

• Velocity: schnelle Ein-/Auszahlungsspitzen; eine Reihe von kleinen Einlagen → eine große Schlussfolgerung.
• Multi-Instrument: viele verschiedene Karten/Geldbörsen in kurzer Zeit.
• Quelle/Ziel mismatch: Einzahlung von einem Instrument, Ausgabe zum anderen.
• Circularity: Auffüllen → Mindesteinsätze/Waschen von Boni → Zurückziehen.
• Split/Structuring: Zerkleinerung von Beträgen unter Schwellenwerten.
• Affiliate Missbrauch: abnorme Zufluss aus dem Kanal + typische Muster des Missbrauchs.
• Geräte-/IP-Risiko: Gerätewechsel/Proxy/Hochrisiko-ASNs.

• Unrealistische Winrate bei geringer Varianz, Wetten beim „Content-Partner“ mit Beschwerden, Spiele mit minimalem Risiko um des Umsatzes willen.

7) Controls-as-Code (Fragmente)

yaml control_id: AML-VELOCITY-DEP-01 scope: deposits risk_weight: 0. 8 trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3
OR count_unique(payment_method, 1h) >= 3
OR count(amount < threshold_structuring, 24h) >= 5 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- request: "KYC2_or_EDD"
evidence:
store: s3://evidence/aml/velocity/{player_id}/{ts}
fields: [amounts_1h, methods_1h, ip, device, kyc_level]
owner: mlro review_sla_days: 180

yaml control_id: AML-SRC-DST-02 scope: withdrawals trigger:
expr: payout_method!= last_successful_deposit_method actions:
- limit: withdrawals "require_same_source"
- notify: payments_team
- flag: aml_review exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true evidence:
fields: [payout_method, last_deposit_method, policy_ref]

yaml control_id: AML-GAMING-PATTERN-03 scope: gameplay trigger:
expr: turnover_24h / deposits_24h > 10
AND avg_bet_risk_index < 0. 2
AND session_count_24h > 8 actions:
- flag: aml_review
- limit: bonuses "freeze"
- request: "source_of_funds"

yaml control_id: AML-RISK-SCORE inputs: [AML-VELOCITY-DEP-01, AML-SRC-DST-02, AML-GAMING-PATTERN-03, sanctions, pep]
score:
expr: w1velocity + w2srcdst + w3gaming + w4sanctions + w5pep thresholds:
- high: score>=0. 8 -> EDD + hold
- medium: score>=0. 5 -> review
- low: score<0. 5 -> auto_clear

8) Modelle und Regeln: teilen

Rules-first am Start (schnell, selbsterklärend) + ML zur Priorisierung (Gradientenboosting/Logreg/abrufbare Fichi).
Champion/Challenger: Vergleich der aktuellen Schwellen mit neuen Modellen im Schatten.
Drift-Monitoring: Kontrolle von Schaltfehlern, Flag/Hold-Bruchteilen, FPR/TPR.
Erklärbarkeit: SHAP/feature importance, Referenzfälle.

9) SOP (Fragmente)

SOP: Triage der AML-Ansteuerung

1. Überprüfen Sie die Karte des Spielers (Geo, KYC, Risiko, Geschichte).
2. Datenquellen verifizieren (Zahlungs-/Spielprotokolle, Kommunikation nach Gerät).
3. Entscheidung: „clear/ request_info/hold/EDD/SAR“.
4. Aktivitäten im Fallsystem erfassen und Status aktualisieren.
5. Kommunikation mit dem Spieler (Vorlage, Reaktionszeit).
6. Überarbeitung der Schwelle/Regel (wenn es viele FPs gibt).

SOP: EDD/SoF Anfrage

1. Anforderung von Dokumenten (Auszüge/Gehalt/Steuern).
2. Abgleich der Summen/Frequenzen/Quellen mit dem Verhalten auf der Plattform.
3. Risikoprofil aktualisieren, Einschränkungen aufheben/bestätigen.
4. Speichern Sie evidence und die Lösung (MLRO-Signatur).

SOP: SAR/STR feed

1. Sammeln Sie eine Tatsache (Zeitlinie, Beträge, Verbindungen, Skins).
2. Überprüfen Sie die Fristen und Formate der Gerichtsbarkeit/Bank.
3. SAR/STR einreichen, ID/Zeit/Kanal erfassen.
4. Aktualisieren Sie die internen Status und Einschränkungen Ihres Kontos.
5. Follow-up vor dem Schließen/Anweisungen der Regulierungsbehörde/Bank.

10) Kommunikation mit Spielern und Partnern

Ton: neutral und sachlich, ohne Offenlegung interner Regeln/Modelle.
Fristen: klare ETAs auf Antwort, Mahnungen, Fixierung im Ticket.
Zahlungspartner: Synchronisation von Hold/Reverse, Case-ID-Austausch, AML Single Channel.

11) Integrationen und Daten

Payments Gateway: Transaktionsstatus, Methode und Details, Retouren, Chargeback.
Spielplattform: Turnaround/Vinrate/Sessions/Varianz, Anomalien.
Device Graph: Fingerabdruck/Kommunikation Geräte/Sitzungen/IP.
KYC/PEP/Sanctions: Anbieter-Screening nach Ereignissen und Zeitplänen.
Fallmanagement: Status, SLA, Entscheidungsprotokoll, SAR/STR-Verpackung.

12) Qualitätskennzahlen (KPI/OKR)

• TPR/Recall für bestätigte Fälle, FPR (falsche Flaggen) ↓ QoQ.
• Precision по High-risk > X%; Auto-clear Rate для Low-risk > Y%.
• Fallpriorisierung Genauigkeit (die oberen N% ergeben M% der Funde).

• Time-to-Triage (P95), EDD Turnaround, Hold Duration (Median).
• SAR/STR SLA (Einreichung ≤ Fristen), Retouren/Chargeback nach AML-Maßnahmen ↓.
• Modell/Regel Drift - innerhalb der zulässigen Korridore.

• Verluste durch Betrug/ ↓, Betriebsstunden/Fall ↓.
• Spielererfahrung: Beschwerden über AML-Prozesse, NPS über ehrliche Spieler.

13) Governance und Sicherheit

Zugriffsrichtlinien: Nur AML/MLRO sehen sensible Felder; Audits von Lesungen.
Retention: Aufbewahrungsfristen für Fälle/Dokumente; automatische Reinigung.
Protokollierung: Alle Aktionen für Fälle und Regel-/Modelländerungen.
Dual Control: Kritische Regeländerungen/Schwellenwerte erfordern 2 Bestätigungen.
Tests in CI: Regelsyntax, Schwellenkonflikt, Regressionsszenarien.

14) Checklisten

• Transaktions-/Spiel-/Gerätedaten wurden verifiziert.
• Die Einzahlungs-/Auszahlungsmethoden wurden verglichen.
• Sanktionen/RER/Geo überprüft.
• Richtiger Lösungstyp ausgewählt ('clear/hold/EDD/SAR').
• ETA und Kommunikation an den Spieler aufgezeichnet.

• Vollständige Zeitlinie und Beträge, Verbindungen zu anderen Konten.
• Bestätigende Artefakte (Bildschirme/Protokolle/Auszüge).
• Format und Kanal entsprechen der Anforderung.
• Interne Status und Einschränkungen aktualisiert.
• Überwachung der nachfolgenden Anweisungen.

• Schwelle/Zeitfenster gerechtfertigt.
• Es gibt eine Schätzung von FP/TP, dem Geschäftseffekt.
• Drift- und Autotest-Überwachung konfiguriert.
• Das Playbook der Triage wurde aktualisiert.
• MLRO/Compliance Revue gehalten.

15) Anti-Muster

Universelle Schwellenwerte „für alle Länder“ ohne RBA.
Halten Sie ohne ETA/Kommunikation, „hängende“ Fälle.
ML-Modelle ohne Erklärbarkeit und Versionsprotokoll.
Manuelle Uploads/SAR ohne Evidence-Templates und Terminkontrolle.
Mangelnde depozit↔vyvod, schwache Integration mit Zahlungen.
Es gibt kein regelmäßiges Retro durch Fehlalarme.

16) 30/60/90 - Umsetzungsplan

• AML-Richtlinie, Rollen (MLRO/AML Ops) und RBA-Matrix genehmigen.
• Führen Sie grundlegende Controls-as-Code (velocity, src/dst mismatch, gaming pattern) aus.
• Aktivieren Sie KYC tiers + Sanktionen/RER, erstellen Sie SOP-Vorlagen (Triage/EDD/SAR).
• Geben Sie evidence-storage und retention policy ein.

• Verbinden Sie den Risiko-Score-Aggregator, das Auto-Routing von Fällen und das SLA-Reporting.
• Führen Sie Champion/Challenger für Schwellenwerte und ML-Priorisierungsassistent aus.
• Integrieren Sie payments/game/device graph in ein einzelnes Spielerprofil.
• Trainieren Sie Teams, debuggen Sie Kommunikationsmuster, aktivieren Sie Regelautotests.

• Reduzieren Sie FPR ≥ 20%, ohne Recall zu verlieren; Time-to-Triage um ≥ 30% reduzieren.
• SLA SAR/STR = 100% pünktlich erreichen; Schließen Sie alle „alten“ Fälle.
• Durchführung einer internen Prüfung des Designs und der Wirksamkeit der Kontrollen; OKR für das nächste Quartal zu fixieren.

17) FAQ

Q: Wie man Sicherheit und UX ausgleicht?
A: RBA-Routing: für Low-Risk - Auto-Reinigung, für Medium - einfache Anfragen, für High - EDD/Hold. Transparente ETAs und Kommunikation.

Q: Was tun mit VIP und High Limits?
A: Obligatorische EDD, periodische Überprüfung des SoF/Verhaltens, starre Ausgabe (Quelle-zu-Quelle), zusätzliche Grenzen.

F: Wann eskalieren zu Bank/Regulator?
A: Bei bestätigten roten Fahnen/Verdächtigungen gemäß Zuständigkeitsbedingungen; nach Rücksprache mit der MLRO und Fixierung von evidence.