Berichterstattung über AML und KYC

1) Zweck und Reichweite

Das Ziel: ein reproduzierbares, überprüfbares und zeitnahes AML/KYC-Reporting für alle Jurisdiktionen und Partner (Banken, PSPs, KYC/KYB-Anbieter) zu gewährleisten, das Risiko von Bußgeldern/Sperren zu reduzieren und die Kontrollfunktionen zu stärken.
Reichweite: Onboarding von Spielern und Partnern (KYC/KYB), Sanktionen/PEER, Transaktionsüberwachung, EDD, SAR/STR, Geldquellen (SoF/SoW), RG-Signale, Speicherung und Zugriff auf PII, Vorfälle und Benachrichtigungen.

2) Klassifizierung von Berichten und Häufigkeit

1. Regulatorisch: Zusammenfassungen zu Onboarding, Sanktionsalerts/RER, SAR/STR, Beschwerden, ergriffenen Maßnahmen.

Frequenzen: monatlich/vierteljährlich; Ereignismeldungen - innerhalb festgelegter Fristen (z. B. ≤72 h).

2. Banken/PSP: Transaktionsvolumen, Chargebacks, verdächtige Muster, EDD-Fälle.

Frequenzen: wöchentlich/monatlich, auf Anfrage ad hoc.

3. Intern: KRIs/KPIs, KYC-Trichter, FPR/FNR, Anbieter-SLAs, AML-Fallstatus.

Frequenzen: Tagesdashboards, Wochenausschüsse, monatliche Rückblicke.

4. Anbieter/Outsider: Qualität und SLA der CUS/Sanktionsanbieter, Fehlertoleranz, falsch positiv.

Häufigkeit: monatlich, vierteljährlich.

3) Einheitliche Datenstruktur (minimale Felder)

Cubject (der Spieler/Partner): subject_id, den Typ (player/partner), das Land, den Altersstatus (18 +), risk_score, kyc_level, pep_flag, sanctions_flag, soe/sow_status.
Документы KYC: doc_type, doc_number_hash, issuer_country, expiry_date, liveness_passed, verification_provider, verification_result, confidence_score.
Транзакции: tx_id, ts, amount, currency, method, psp, device_id, ip_geo, velocity_flags, rule_hits[].
Алерты AML: alert_id, rule_id, severity, reason_codes[], owner, status, opened_at, closed_at, action_taken (EDD/SAR/STR/block/none).
Санкции/PEP: list_version, hit_type (sanctions/pep/adverse media), match_score, disposition (true/false positive), reviewer_id.
PII-Zugriffsprotokoll: actor, action (view/export/delete), dataset, ts, purpose, ticket_id.

4) KRIs/KPIs für das Reporting

• KYC pass rate, KYC fail%, Liveness dropout%, Avg TAT (min/h), FPR/FNR Modelle.

• Hit-Rate auf 1k Onboarding, FPR%, Dispo TAT, Anteil der Sekundärprüfungen.

• Alerts per 10k tx,% der Eskalationen in EDD, SAR/STR per 10k active, Conversion alert→action.

• Anbieter-Uptime, durchschnittliche API-Latenz,% Retrays, Anteil der Nichtverfügbarkeit> X min.

• % der Auslassungen von Pflichtfeldern, Takes, Divergenzen otchet↔bukhuchet, Erfolgsrate der täglichen ETL.

5) Qualitätskontrolle und Abstimmung

DQ-Regeln: not null/Format/Bereiche/Referenzen; SLA auf Korrektur.

• Onboarding-Register gegen KYC-Anbieter,
• Transaktionen DWH vs Berichte PSP/Bank,
• SAR/STR-Register vs gesendete Nachrichten,
• Sanktionslisten Version N vs N-1 (Deltas).
• Nachweisbar: Hashsummen von Uploads, Verrechnungsprotokolle, unveränderliche Protokolle (WORM/Object Storage).

6) Standard-Berichtsformulare (Vorlagen)

6. 1 AML/KYC Regulatory Summary (monatlich)

Verstöße/Vorfälle: 0 kritisch, 1 durchschnittlich (KYC-Provider-Latenz 18 Min.).
Getroffene Maßnahmen: Fallback aktiviert, Velocity-Regeln aktualisiert.

6. 2 Bericht für Bank/PSP (monatlich)

Einzahlungs-/Auszahlungsvolumen über Zahlungskanäle, Chargeback-Rate, verdächtige Muster, Liste der gesperrten Konten/Geräte (Hashes), EDD/Hold-Maßnahmen.

6. 3 Interner Sanktionsbericht/RER (wöchentlich)

7) Workflows (SOP) und RACI

7. 1 SOP: Monatlicher regulatorischer Bericht

1. Start ETL T + 1 02:00 → 2) DQ-Validierung → 3) Abstimmungen mit PSP/DWH → 4) Vorbereitung PDF/CSV/JSON → 5) Legal Revue → 6) Unterschrift/Einreichung → 7) Archiv/Hash/Log.
RACI: Responsible — Compliance Analyst; Accountable — Head of Compliance; Consulted — Legal, DPO, Payments, Security; Informed — C-level.

7. 2 SOP: SAR/STR

Trigger (Rule/Machine-Learning/Manuell), EDD-Check, Lösung (File/Not), Feiling, Empfangsbestätigung, Registeraktualisierung, Nachverfolgung (Hold/Block/Nachricht an Bank/Regulator).

7. 3 SOP: CUS Vorfall/Sanktionen

FPR> Schwelle oder SLA-Degradation → Incident Bridge → Einbeziehung eines zweiten Providers → Regelkalibrierung → Incident Report (TTR/Ursache/Maßnahmen).

8) Automatisierung: architektonische Kontur

Sammlung: CDC/Stream mit Prod-DB, CUS/Sanktionen Webhooks, PSP-SFTP, Log-Sammler.
Хранилище: Data Lake (RAW → CURATED), DWH (reporting marts: aml_alerts, kyc_events, sanctions_hits, psp_recon).
Bearbeitung: Orchestrator (Airflow/Argo) mit SLA/Retrays, Policy-as-Code für Aggregate.
SOAR: Playbooks für SAR/EDD, Auto-Eskalationen bei Schwellenwerten, Tickets und Benachrichtigungen.
Data Directory/lineage: automatische Generierung von Schemata und Abhängigkeiten, Versionen von Berichten.

9) Aggregationen und Beispiele für Implementierungen

9. 1 SQL-Beispiel (Pseudo)

sql
-- Sanctions/PEP weekly hit-rate with FPR
SELECT date_trunc('week', screening_ts) AS week,
COUNT() FILTER (WHERE hit = true) 100.0 / COUNT() AS hit_rate_pct,
COUNT() FILTER (WHERE hit = true AND disposition = 'false_positive') 100.0
/ NULLIF(COUNT() FILTER (WHERE hit = true),0) AS fpr_pct
FROM sanctions_screenings
WHERE screening_ts >= current_date - interval '90 day'
GROUP BY 1
ORDER BY 1 DESC;

9. 2 JSON-Entladeschema SAR/STR (vereinfacht)

json
{
"report_id": "SAR-2025-000128",
"filed_at": "2025-11-01T10:42:12Z",
"subject": {"id":"player_9f4a", "country":"EE", "risk_score":82},
"transactions": [{"tx_id":"T123", "amount":950.00, "currency":"EUR", "ts":"2025-10-28T21:10:00Z"}],
"reasons": ["velocity_withdrawals", "device_cluster"],
"actions": ["hold","EDD","bank_notification"],
"attachments": ["/evidence/aml/SAR-2025-000128.pdf"],
"confidentiality":"restricted"
}

10) Schwellenwerte und Eskalationen (Benchmarks)

Sanktionen/PEP-Trefferquote:> 3% - Eskalation; FPR%:> 12% - Kalibriervorfall.
KYC Fail%:> 15% Tag - Fallback/manueller VIP-Stream aktivieren.
Dispo TAT:> 48 h - Fallumverteilung und High-Value-Priorisierung.
SAR/STR pro 10k aktiv: Sprung> × 2 zum Median - dringende Überarbeitung der Regeln/Kampagnen.
ETL-Erfolg: <99% - Ursachenanalyse, SRE/Compliance-Bericht.

11) Speicherung, Zugriff und Prüfung

Retention: Berichte und Register - mindestens X Jahre (von der Politik festgelegt); SAR/STR - nach Gerichtsbarkeit (in der Regel länger).
PII-Kontrolle: Minimierung von Feldern, Pseudonymisierung von subject_id, Zugriff nach dem Prinzip der geringsten Privilegien, obligatorische Audit-Protokolle von Aufrufen/Exporten.
Export: weiße Listen der Empfänger; Alle Uploads werden signiert und gehasht. WORM-Speicher für die finalen Versionen.

12) Änderungsmanagement (Change/CAB)

Die Änderungen an den gemeldeten Metriken/Regeln durchlaufen die CAB: Geschäftsbeschreibung, Auswirkungen auf KRIs, Testproben, A/B auf Sandbox, Einschlussdatum, Rollback-Plan.
Versionsberichte: report_version, changelog, vergleichende Tabs (v-1 vs v).

13) Anbieter und vertragliche Verpflichtungen

Vor dem Onboarding: Due Diligence (Sanktionen/RER gegen Begünstigte, ISO/SOC2 DPIA/DTIA, DPA/SCCs).
Im Einsatz: vierteljährliche SLA-Prüfungen, Test-Alerts, Logabgleich, Fixierung von Subprozessoren.
Offboarding: Widerruf von Schlüsseln/Zugriffen, Löschung/Rückgabe von Daten, Schließungsakt und Bericht über die Vollständigkeit der Löschung.

14) Rollen und Interaktionen

Head of Compliance (A): Genehmigung von Berichten, Risikoappetit.
Compliance Analyst (R): sbor/walidazija/swerki/formirowanije der Berichte.
DPO/Legal (C): Rechtmäßigkeit der Verarbeitung, Benachrichtigungen.
Zahlungen/FRM (C): Transaktionen, Gebühren, Betrugsbekämpfung.
Sicherheit/SRE (C): Vorfälle, Zugriffe, Protokollierung, ETL-Stabilität.
Daten/BI (R): Modelle, Schaufenster, Dashboards.
Support/VIP (I): RG/EDD Fallkommunikation.

15) Dashboards und Visualisierung (Minimum von Widgets)

KYC Funnel: Registrierung → KYC init → pass/fail → SoF/SoW abgeschlossen.
Sanktionen/PEP: Trefferquote/FPR/TAT, Version der Listen, Anteil der Sekundärprüfungen.
AML-Warnungen: nach Regeln/Segmenten/Regionen; conversion alert→action; EDD-Anteil.
SAR/STR: Dynamik der Filings, Ursachen, teilen nach Zahlungsmethoden.
SLA-Anbieter: Aptime, Latency, Retrays, Vorfälle.
DQ&ETL: Fehler, Lücken, Pipelineerfolge, „Ampel“ -Qualität.

16) Checkliste zur Berichtsreife

• Datensatz mit Lineage und Schemaversionen gebildet
• DQ-Validierungen und Abstimmungen bestanden
• Bestätigte KRIs/KPIs und Schwellenwerte
• Legal/DPO Revue abgeschlossen
• Signiert/vergriffen/archiviert
• An Adressaten verschickt, Zustellprotokolle gespeichert

17) Anwendungen (Vorlagen)

17. 1 SAR/STR-Karte (Register)

ID, Datum, Subjekt, Länder/Methoden, Betrag, Gründe (rule_ids), EDD-Maßnahmen, Entscheidung, Datum der Failing, Bestätigung, Verantwortlicher, Hinweise auf Beweise.

17. 2 KYC Monatsberichtsvorlage (CSV)

month;country;onboardings;kyc_pass;kyc_fail;avg_tat_min;liveness_dropout_pct;provider_sla_uptime;notes
2025-10;EE;14320;12688;1632;9.6;3.1;99.92;fallback activated 10/21

17. 3 Vorlage Sanktions-/RER-Bericht (CSV)

week;onboardings;screened;hits;fpr_pct;dispo_tat_min;list_ofac;list_eu;list_uk
2025-W43;11982;11982;252;9.1;42;2025-10-21;2025-10-18;2025-10-19

TL; DR

Stabiles AML/KYC-Reporting = standardisiertes Datenschema + strenge DQs/Abstimmungen + verständliche KRIs/KPIs und Schwellenwerte + ETL/SOAR-Automatisierung + transparentes RACI und Storage/Audit. Dies reduziert regulatorische Risiken, beschleunigt die Reaktion auf Bedrohungen und unterstützt die Widerstandsfähigkeit des iGaming-Geschäfts.