RER/Sanktionslisten: Screening

1) Warum RPP/Sanktionsscreening in iGaming

Screening - die grundlegende Compliance-Schleife: verhindert die Arbeit mit verbotenen Personen/Organisationen und reduziert das Risiko von regulatorischen Sanktionen, Einfrieren von Zahlungskanälen und Sperren bei Banken/PSPs. In iGaming (MCC 7995) ergänzt es die KYC/KYB- und AML-Überwachung und beeinflusst direkt die Verfügbarkeit der Zahlungsinfrastruktur und die Geschwindigkeit der Ableitungen.

2) Quellen und Arten von Listen

Sanktionslisten: international (UN), supranational/regional (EU, UK), national (US OFAC sowie lokale Register).
PEP (Politically Exposed Persons): amtierende/ehemalige Amtsträger + Verwandte und nahestehende Personen.
Adverse Media (negative Medien): kriminelle Ermittlungen, Betrug, Korruption usw. - eine Hilfsschicht.
De facto Verbote und Handelsembargos: Länder, Sektoren, Vermögenswerte.
Krypto-Adressen mit Sanktionsetiketten: Börsen/Wallets/Mixer, hohes Risiko durch KYT.

3) Wann und wen zu screenen (CUS/CUV/Chirurgie)

KYC (natürliche Personen): bei der Registrierung (Tier 1), vor der ersten Ausgabe, beim Upgrade auf Tier 2/3, bei Änderung des vollständigen Namens/der Adresse/des Dokuments, tägliches Rescrining.
KYB (juristische Personen): Unternehmen, Direktoren/Offiziere, UBO; beim Onboarding, Strukturupdates, alle 6-12 Monate geplantes Rescrining.
Operative Ereignisse: große Ein-/Auszahlungen (Schwellenwert-Auslöser), Geo-/Gerätewechsel, Risikoanstieg im AML.

4) Datenqualität und Normalisierung (vor Matches)

Normalisierung des vollständigen Namens: Register, Leerzeichen, Diakritik, Transliteration (GOST/ISO/nationale Vorschriften), alternative Formen (Aleksandr/Alexander).
Geburtsdaten: Formate' DD/MM/YYYY 'vs' YYYY-MM-DD', Fehler ± 1 Tag (Dokumentenfehler).
Adressen: Länder/Regionen in ISO-Kodifizierungen, Stadtverzeichnisse.
Organisationen: Rechtsform (LLC/Ltd/AO), Alias-/ehemalige Namen, Registrierungsnummern.
Krypto: Normalisierung von Adressen und Anbietern (Börsen, Depots), Netzwerke/Kette.

5) Matching: Präzise, unscharf und falsch positiv reduzieren

• Exakt nach ID: Reisepass/Reg. Nummer, Geburtsdatum/-ort, Handelsregisternummer.
• Fuzzy Match (Entfernungsalgorithmen: Levenshtein, Jaro-Winkler) mit Schwellen in der Ähnlichkeit.
• Aliasy/AKAs: Vergleich nach alternativen Namen, Mädchennamen, lateinisch/kyrillisch.

• Erfordert eine Übereinstimmung von mindestens zwei unabhängigen Merkmalen (Name + Geburtsdatum/Name + Land/Dokumentennummer).
• Alert-Deduplizierung (Konsolidierung von Spielen pro Person/Unternehmen).
• Geofilter und Kontext (Geburtsland vs aktueller Wohnsitz).
• Whitelists (allow-list) für bestätigte „falsche Übereinstimmungen“ mit einem Kontrollzeitraum (expiry).

6) Alert-Klassifizierung und Priorisierung

Wählen Sie die Schwelle des Fuzzy-Matches nach Markt/Sprache (für kyrillisch - etwas höher, unter Berücksichtigung der Transliteration).

7) Revue-Prozess (Workflow)

1. Bereicherung: Straffung der Kunden-/Gegenpartei-Daten (KYC/KYB, Geo, Zahlungen).
2. Quellenverifizierung: Überprüfen Sie den Eintrag im Register/Aggregator (Relevanz, Aktualisierungsdatum).
3. Entscheidungsfindung: Approve (falsche Übereinstimmung), EDD/Limits, Reject/Freeze.
4. Dokumentation: Grund, verwendete Zuordnungsfelder, Quellenreferenzen, Ablaufdatum der Lösung (für allow-list).
5. Kommunikation: Anforderung von Dokumenten/Erklärungen, Einhaltung des Tipping-off-Verbots bei SAR.

• Hoch: ≤ 4 h (kritische Sperren)
• Medium: ≤ 24 ч
• Low: ≤ 72 Stunden

8) Rescrining und Events (eventgetrieben)

Täglich: automatischer Lauf aller aktiven Profile/Kontrahenten.
On-Demand: bei Änderung des vollständigen Namens/der Adresse/des Dokuments/des UBO/der Direktoren, bei großen Schlussfolgerungen, bei AML-Warnmeldungen.
Listen-Versionierung: Erfassen Sie das Datum/die Version der Quelle in den Protokollen, um die Lösung nach einem Jahr zu reproduzieren.

9) Integration mit KYB/KYC/AML/Zahlungen

KYC/KYB: Screening zum Zeitpunkt des Onboardings und bei jedem Level-Upgrade.
AML-Monitoring: Positives Screening erhöht die Priorität von Alerts (siehe Rapid In-Out, Structuring).
Zahlungen Orchestrator: automatische Holds/Limits bei High-Alert; Routing zu „sicheren“ Methoden.
KYT/Travel Rule: Sanktionsrisiken durch Krypto-Adressen, Austausch von Attributen zwischen VASPs (falls zutreffend).

10) Daten, Datenschutz und Audit

Minimierung: Speichern Sie nur die Felder, die für die Lösung verwendet wurden; Dokumentnummern maskieren.
Verschlüsselung und Zugriff: KMS/HSM, RBAC, Fallprotokoll; Verbot von Entladungen außerhalb geschützter Kanäle.
Retention: Speicherung von Entscheidungen/Protokollen gemäß Verordnung (oft 5 + Jahre).
Fußabdruck-Audit: wer/wann/was abgeglichen hat, welche Version der Liste, welches Ergebnis.

11) Prozessmetriken und -qualitäten

Präzision und Geschwindigkeit

Präzision/Rückruf durch manuelle Markierung (Sample), Anteil falsch positiv (FP).
SLA-Trefferquote (High/Med/Low), mittlere Zeit bis zur Entscheidung (p50/p95).

Betrieb

Anteil der Rescrinings mit Statusänderung, Aktualisierungsrate der Listen.
Anzahl der Alert pro 1k Onboarding/pro 1k aktive Kunden.
Stückkosten pro Fall.

Risiko/Geschäft

Anzahl der Stop-Cases (Sanktionen) und verhinderte Auszahlungen.
Korrelation von „positivem Screening“ mit AML-Vorfällen, Charjbacks.

12) Anbieterauswahl und Architektur

• Abdeckung: internationale + lokale Listen (offizielle Quellen), Aktualisierungsrate.
• Qualität der Spiele: anpassbare Schwellenwerte, Unterstützung für Transliterationen, Alias, Fuzzy.
• Leistung: API-Latenz, SLA-Uptime, Batch-Modus für Rescrining.
• Datenschutz/Compliance: DPIA, Datenstandort, Logbücher, Zertifikate.
• Funktionen: Case Management, Allow/Deny-Listen, Versionierung von Quellen, Web Hooks.

• Screening-Service (Microservice) + Cache von „heißen“ Ergebnissen.
• Warteschlangen für Batch-Rescrining (nächtliche Aufgaben).
• Case-System für manuelle Reviews, mit Integration in KYC/KYB/AML.

13) Entscheidungsmatrix (Beispiel)

14) Anti-Muster

„Deaf“ -Exact-Match nur mit Namen - FP-Lawine.
Keine Transliteration/Alias - Auslassung von echten Matches.
Keine Allow-Liste mit Ablauf - der Befehl sinkt in wiederholten FPs.
Seltenes Rescrining - Neue Einträge in Listen werden nicht gefangen.
Keine Protokollierung von Listenversionen - Lösungen können bei der Prüfung nicht geschützt werden.
Die Meldung eines SAR (Tipping-Off) an den Kunden ist ein schwerwiegender Verstoß.

15) Checkliste Umsetzung

• Quellen: internationale, regionale und lokale Listen + Aggregator.
• Normalisierung von Daten (Name/Datum/Adresse/Organisation/Krypto), Transliterationen und Alias.
• Matchstrategie: exact + fuzzy mit anpassbaren Schwellenwerten und Geocontext.
• Revue-Prozess: Rollen, SLA (4h/24h/72h), Lösungsvorlagen und Kommunikation.
• Allow/deny-Listen mit Ablauf und Prüfung.
• Tägliches Rescrining + On-Demand-Event; Versionierung der Quellen.
• Integrationen: KYC/KYB/AML, KYT/Travel Rule, Payments Orchestrator (Holds/Limits).
• Daten/Datenschutz: Verschlüsselung, RBAC, Protokolle, Retention.
• Qualitätsmetriken und regelmäßiges QS-Sampling; Reduzierung des FP durch gezielte Experimente.
• Continuity Plan (Fallback Provider, API Degradation).

16) Zusammenfassung

Ein effektives Peer-to-Peer/Sanktionen-Screening besteht nicht nur darin, „Listen zu durchbrechen“. Dies sind normalisierte Daten, flexibles Exact + Fuzzy Matching, ein kontrollierter Revue-Prozess mit Prioritäten und SLA, tägliches Rescrining und Integration mit AML/KYC/KYB/KYT. Eine solche Kontur minimiert falsch positive, fängt reale Risiken auf, schützt Zahlungsschienen und beschleunigt legitime Schlüsse - und unterstützt damit eine nachhaltige Monetarisierung.