Sanktionierte Zahlungskonformität

1) Warum es notwendig ist (Risikorahmen)

Rechtsrisiko: Geldbußen/Entzug der Lizenz bei Verstößen gegen Sanktionsregelungen.
Finanzielles Risiko: Einfrieren von Geldern/Konten auf dem Korridor (Korrespondent/PSP/Schema).
Operationelles Risiko: Höhere Gewalt Retouren, schwebende Transaktionen, erhöhte manuelle Kontrollen.
Reputation: Die „sanktionierten“ Vorfälle treffen Partnerbanken und den Zugang zu Korridoren.

2) Regime und Prinzipien

Listen: OFAC (SDN/SSI), EU, UK (OFSI), CA, AU, UN, lokal.
Geo-Embargo: vollständige Verbote nach Ländern/Gebieten.
Sektorale: Beschränkungen der Sektoren/Fristen für die Finanzierung (SSI/Richtlinie).
„50% Regel“: Wenn eine oder mehrere SDNs zusammen ≥50% besitzen, gilt das Subjekt als gesperrt, auch wenn es nicht namentlich genannt wird.
Exportkontrolle/Dual-Use: Zahlung für verbotene Waren/Dienstleistungen (wichtig bei A2A/SWIFT Remiten).
Crypto/Travel Rule: Übertragung von KYC-Attributen zwischen VASPs bei grenzüberschreitenden Transfers.

3) Wo und wie zu screenen (Zahlungsverkehr)

3. 1. Depositen

Zahler: Name/Adresse/Geburtsdatum (falls vorhanden), Karte (BIN-Geo), Wallet, IP/ASN, Gerät.
Anbieter: PSP/MID und ihre Zuständigkeit; Überprüfung der „Sauberkeit“ der Route.
Ereignisse: Profilerstellung (L0), Ersteinzahlung (L1), Anomalien (Velocity/Geo-Konflikt).

3. 2. Schlussfolgerungen

Begünstigter: IBAN/BIC/Name/Adresse, Karte/Wallet, Krypto-Adresse (VASP).
Route: same-method/return-to-source, Empfängerbank, mögliche Korrespondenten.
Travel Rule (Crypto): Austausch von Originator-/Beneficiary-Daten, Überprüfung des VASP-Status.

3. 3. Routing/Korridore

A2A/SEPA/FPS/PIX/RTP: die Empfängerbank und ihr Land/Sank-Risiko.
Push-to-Card: kartenausgebende Bank (BIN-Land/Bank).
SWIFT: Korrespondenzbanken (alle Glieder der Kette).
E-Wallets: Zuständigkeit des Emittenten/Wallet-Betreibers.

4) Screening-Typen und Signale

Name/Aliasy/Transliteration (Fuzzy-Match, Reduktion der Diakritik).
Adresse/Stadt/Postleitzahl (Geo-Trigger, „sanktionierte“ Standorte).
Geburtsdatum/Reisepass/MRN (wenn verfügbar von KYC).
Organisationen/BEGÜNSTIGTE (UBO): erweiterte Due Diligence.
IBAN/BIC und Empfängerbank: Land, „Sanktionsbank“ oder sanktionierte UBO.
BIN/Kartenaussteller: Land/Bank, Cross-Check mit Sanklisten.
IP/ASN/VPN/Hosting: Sank-Geo, Proxy/Shadow ASN.
Device-graph/household: Kreuzungen mit zuvor gesperrten.
Krypto-Adressen: Etiketten „sanktioniert/Mischer/Risiko-Cluster“ bei Blockchain-Anbietern.
Geo-Konflikt: KYC-Land ≠ IP ≠ SIM ≠ BIN-Geo.

5) Orchestrierung des Screenings: „wo einbetten“

1. Onboarding: einfaches Screening nach Name/DR, Länderrisiko.
2. Zahlung init: Synchroner Hit-Check des Zahlers/Begünstigten, IBAN/BIN, IP/ASN.
3. Pre-Routing: Deny/Hold/Step-up (SoF/Dokumente) vor dem Versand in den Korridor.
4. In-flight: Statusüberwachung von PSPs/Banken (Returns/Holds).
5. Post-Event: Retrospektives Rescrining beim Aktualisieren von Listen (Backfill).

6) Entscheidungspolitik (risikobasiert)

AUTO-PASS: keine Treffer; geringes Risiko des Landes/der Bank; same-method; ND≥0.
MANUAL REVIEW: fuzzy-Hit unter der hohen Schwelle; einen neuen Begünstigten; Geo-Konflikt; hohes Land/Sektorrisiko.
DENY/BLOCK: exakter SDN-Hit, „50% Regel“, GEO-Embargo, Sanktionsbank/Korridor.
STEP-UP: SoF/SoW-Anfrage, Nachweis der Anschrift/des Namens des Begünstigten, „Namenscheck/IBAN“ (sofern vorhanden).

7) Reduzierung von Fehlalarmen (Präzision)

Normalisierung des vollständigen Namens (Permutation von Vor-/Nachnamen, Vatersnamen, Fällen, Partikeln).
Kontextuelle Attribute: Geburtsdatum/Stadt reduzieren FPR.
White-Listen: verifizierte Begünstigte/Banken/IBAN (mit TTL und Revalidierung).
ASN/VPN Blacklist: Weniger laute Treffer über IP.
Segmentschwellen: strenger für hohe Risiken GEO/Korridore, weicher für niedrige Risiken.
Auto-Auflösung nach manueller APPROVE mit gleichem Fingerprint (Device/IBAN).
Erklärbarkeitsprotokolle: warum abgelehnt/erlaubt (schnell, Regeln, Übereinstimmungsfelder).

8) UX und Kommunikation

Transparente Gründe: „Eine Validierung des Empfängers aufgrund der Bank/des Landes ist notwendig“.
Timing: Ehrliche ETAs für manuelle Überprüfung/SoF.
Retouren: Automatischer Refand in die Spielgeldbörse, Link „andere Methode/Empfänger auswählen“.
Lokalisierung: Gesetzestexte, Verweise auf Sanktionspolitik/Unterstützung.

9) Engineering: Datenmodell (Minimum)

sql sanctions.watchlists (
source TEXT,      -- OFAC, EU, UK, UN, etc.
entity_id TEXT,    -- уникальный ID записи entity_type TEXT,   -- person    org    vessel    bank name TEXT, aliases TEXT[], dob DATE, country TEXT,
programs TEXT[],    -- санкционные программы ownership_json JSONB, -- связи для "50% правила"
updated_at TIMESTAMP
);

sanctions.hits (
hit_id PK, user_id, payout_id, deposit_tx_id,
entity_id, source, match_score NUMERIC, match_fields JSONB,
status TEXT,      -- OPEN    APPROVED    DENIED    ESCALATED    FALSE_POSITIVE reviewer TEXT, decided_at TIMESTAMP, created_at TIMESTAMP
);

payments.endpoints (
beneficiary_id PK, user_id, type, -- IBAN    CARD    WALLET    CRYPTO iban TEXT, bic TEXT, bin TEXT, wallet_ref TEXT, crypto_addr TEXT,
bank_country TEXT, bank_name TEXT, verified BOOLEAN,
last_screened_at TIMESTAMP, risk_tags TEXT[]
);

risk.context (
user_id, ip INET, asn INT, device_hash TEXT,
geo_ip TEXT, geo_kyc TEXT, geo_sim TEXT, updated_at TIMESTAMP
);

10) Pseudo-DSL-Richtlinien

yaml policy: "sanctions_payments_v4"
lists:
sources: [OFAC, EU, UK, UN, CA]
refresh_interval_hours: 6 screening:
on_user_create: true on_deposit_init: true on_payout_init: true on_new_beneficiary: true rescreen_on_list_update: true thresholds:
name_fuzzy_pass: 0.72 name_fuzzy_manual: 0.62 org_fuzzy_pass: 0.80 crypto_risk_max: "MEDIUM"
routing_guards:
deny_if:
- geo in [EMBARGOED]
- bank_sanctioned == true
- ownership_sdn_agg >= 0.5  # "50% правило"
manual_review_triggers:
- fuzzy_hit == true
- new_beneficiary == true AND amount > 1000 EUR
- geo_conflict_score >= 2
- vasp_untrusted == true stepups:
- if: payout_amount > 2000 EUR then: ["name_check_iban"]
- if: crypto == true then: ["travel_rule", "beneficiary_vasp_check"]
audit:
store_feature_snapshot: true store_decision_tree: true exceptions:
whitelist_beneficiary_ttl_days: 180

11) SQL-Vorlagen

11. 1. Fuzzy-Suche nach Namen/Alias

sql
SELECT w.entity_id, w.source, w.name,
similarity(unaccent(lower(:full_name)), unaccent(lower(w.name))) AS score
FROM sanctions.watchlists w
WHERE w.entity_type='person'
AND (unaccent(lower(:full_name)) % unaccent(lower(w.name))
OR EXISTS (SELECT 1 FROM unnest(w.aliases) a
WHERE unaccent(lower(:full_name)) % unaccent(lower(a))))
ORDER BY score DESC LIMIT 20;

11. 2. Überprüfung der „50% -Regel“ nach Besitz

sql
SELECT entity_id
FROM sanctions.watchlists
WHERE entity_type='org'
AND (ownership_json->>'sdn_agg_share')::numeric >= 0.5;

11. 3. Rescrining-Trigger beim Aktualisieren der Liste

sql
INSERT INTO sanctions.hits (user_id, entity_id, source, match_score, status, created_at)
SELECT u.user_id, w.entity_id, w.source, 0.0, 'OPEN', now()
FROM users u
JOIN sanctions.watchlists w ON w.updated_at >:last_run
WHERE u.country IN (:risk_geos);

11. 4. IBAN/Empfängerbank: Risikogott

sql
SELECT e.beneficiary_id,
(e.bank_country = ANY(:embargo_geos)) AS embargo_hit,
(e.bic IN (SELECT bic FROM ref.sanctioned_banks)) AS bank_hit
FROM payments.endpoints e
WHERE e.beneficiary_id=:bid;

11. 5. Crypto Travel Rule (vereinfachte Kontrolle)

sql
SELECT v.vasp_id, v.trust_level, tx.crypto_addr
FROM crypto.transfers tx
JOIN ref.vasps v ON v.domain = tx.beneficiary_vasp
WHERE tx.payout_id =:pid;

12) KPIs und Dashboards

Trefferquote: Anteil der Transaktionen/Begünstigten mit sanktionierten Treffern.
False Positive % и Manual Approve %.
Manual TAT p50/p95 (Lösungszeit).
Denied% nach Modi/Geo/Korridore/Banken.
Rescreen backlog nach Aktualisierung der Listen.
Returns/Holds% auf Sank-Codes von PSPs/Banken.
Travel Rule Coverage% (Krypto).
Whitelisted TTL breach% (faule „Vertrauenswürdige“ ohne Revalidierung).

13) Alerts

Liste Update Spike: ein starker Anstieg der Treffer nach der Aktualisierung der Listen.
FPR Surge: False Positive%> Schwelle d/d.
Manual Backlog: offene Fälle> Limit oder p95 TAT> SLA.
Embargo Route Hit: Versuche, Zahlungen für verbotene Geo/Banken durchzuführen.
Travel Rule Missing: Krypto-Überweisungen ohne VASP-Datenaustausch.
Policy Drift: Transaktionen ohne Rules/Decision Snap.

14) Playbooks der Vorfälle

A. Massentreffer nach OFAC/EU-Update

1. Einfrieren Auto-Routing auf Risiko-Korridore → MANUAL.
2. Priorität nach Betrag/ETA, schnelle Schulung der Bediener neuer Alias/Rechtschreibungen.
3. Kommunikation PSP/Banken: Warnung vor vorübergehendem Anstieg der manuellen.

B. Rücksendungen der Korrespondenzbank

1. Ursache-Code normalisieren, Proben sammeln (BIC, Korridor).
2. Vorübergehend ausschließen Bank/Korridor aus der Kaskade, reroute.
3. Nachmordem: Verzeichnis der „Sankbanken“ aktualisieren, Precheck stärken.

C. Krypto ohne Reiseregel

1. Leads auf ungeprüften VASPs sperren, Daten anfordern.
2. Aktivieren Sie „only trusted VASP“, bis die Integration korrigiert ist.
3. Retest und Bericht an die Regulierungsbehörde, falls erforderlich.

15) Best Practices (kurz)

1. Policy-as-Code mit Versionen und Snap-Shots von Merkmalen/Lösungen.
2. Screening an mehreren Stellen (Profil, Init, Pre-Route, Post).
3. Berücksichtigen Sie die 50% -Regel und die UBO-Kommunikation, nicht nur die Namenseinträge.
4. Name Normalisierung und Kontext (DR/Stadt), um FPR zu reduzieren.
5. Weiße Listen der geprüften Begünstigten/Banken mit TTL und Revalidierung.
6. Segmentieren Sie die Schwellenwerte nach GEO/Methode/Korridor.
7. Protokolle der Erklärbarkeit und Audit-Trail: „wer/wann/warum“.
8. Vereinbaren Sie mit PSPs/Banken Rückgabecodes und manuelle SLAs.
9. Travel Rule und Register der vertrauenswürdigen VASPs für Krypto.
10. Regelmäßige Post-Vorfälle und Regeln-Tuning.

16) Checkliste Umsetzung

• Listenquellen und Aktualisierungsrate (OFAC/EU/UK/UN/lokal).
• „50%“ -Politik und UBO-Graph.
• Screening auf onboarding/deposit/payout/new beneficiary/rescreen.
• Integrationen: PSPs/Banken/Waspas, Retourencodes.
• Schwellenwertmatrix (pass/manual/deny), GEO/Methodensegmente.
• Whitelists/Blacklists (beneficiary/bank/ASN/IP) mit TTL.
• Protokolle der Erklärbarkeit, Merkmals-/Entscheidungsshots, Berichte für Lizenzen.
• KPI Dashboards und Alerts; SLA von Hand.
• Playbooks (Listen aktualisieren, Retouren, Reiseregel).
• Bedienerschulung (Alias/Transliterationen, Länderraritäten).

Zusammenfassung

Bei der sanktionierten Zahlungskonformität geht es darum, Regeln, Daten und Routen zu orchestrieren und nicht nur „durch die Liste zu schlagen“. Integrieren Sie Screening in Schlüsselpunkte der Zahlungsroute, berücksichtigen Sie UBO und die 50% -Regel, verwalten Sie Korridore/Banken, reduzieren Sie Fehlalarme durch Normalisierung und Kontext, speichern Sie erklärbare Entscheidungen und Richtlinienversionen als Code. Auf diese Weise behalten Sie den Zugang zu den Korridoren, senken die Transaktionskosten und halten den Lizenzanforderungen stand, ohne die Konvertierung zu töten.