Blacklists und Blocklisten in der Zahlungslogik

TL; DR

Eine Blacklist/Blockliste ist eine überschaubare Schicht aus „harten“ und „weichen“ Verboten in einer Payment-Pipeline. Sein Wert besteht darin, notorisch riskante Identitäten (Karten, IBANs, Krypto-Adressen, Geräte, IPs usw.) schnell vor teuren Inspektionen und Abbuchungsversuchen abzuschneiden. Der Schlüssel zur Effizienz ist ein klares Datenmodell (Ablaufdatum, Quelle, Ursache, Zuständigkeit, Vertrauensniveau), ein isolierter Service mit starkem Cache und Audit, konsistente TTL/Amnestie-Richtlinien sowie „Hit-Rate ↔ Overblock“ -Metriken.

1) Begriffe und Unterschiede

Blacklist/Deny-list/Flowsheet - Eine Sammlung von IDs, bei deren Übereinstimmung eine Operation starr abgelehnt wird (HARD BLOCK).
Stop-List (kontextbezogen) - Sperre in einem bestimmten Kontext (z.B. nur auf Pins, nur in Land X, nur für Betrag> € Y).
Watchlist/Greylist - „Beobachtung“: Die Operation wird nicht sofort abgelehnt, sondern in STEP-UP (3DS/OTP/dop. KYC) oder eine manuelle Überprüfung.
Allow-list/White-list ist eine explizite Auflösung, die graue Signale überwiegt (z.B. VIP, bestätigtes Bank-Konto).
Negative List (intern) - Liste basierend auf internen Vorfällen (Chargebacks, Bonus-Missbrauch, sanktionierte Zufälle, Multi-Accounting).

💡 Empfehlung: Plattformspezifisch Deny (hart), Stop (hart gewickelt), Observe (weich), Allow (override) verwenden.

2) Was genau ist „Blatt“: IDs

Zahlungsdetails

Karte: PAN-Token/FPAN-Hash, BIN, Emittent/Land (für Geo-Richtlinien), Laufzeit, Medienname (optional, Hash/Fazzi).
Bank: IBAN/BIC, Konto/Routing (ACH/SEPA), Name des Eigentümers (normalisierter Hash).
E-Wallet/Fintech: Wallet (PayPal/Skrill/Neteller etc.), UPI/PIX ID, Open-Banking PISP-Zahler.
Crypto: L1/L2-Adressen, Tags (Mixer/Sanktionen/Hochorsk), Kette (ETH/BTC/TON usw.).

Kommunikation und Verhalten

E-Mail/Telefon (mit Normalisierung, Berücksichtigung von „einmaligen“ Domains und umverteilbaren Nummern).
Gerät/Browser-Fingerprint, Clientschlüssel, Mobile-ID.
Netzwerk: IP (ASN/Proxy/VPN/Rechenzentrum) ,/24-Subnetze, Geolokalisierung.

Konten und Gegenparteien

UserID/CustomerID, Partner/Affiliate, Promo-Quelle.
PSP/MID/Acquirer (für Betriebssperren auf Routen).
Adresse/Name (Hash-Normalisierung, Fuzzy-Matching durch Token).

3) Quellen der Listenauffüllung

Interne Ereignisse: Charjbacks, Betrugsalerts, Bonus-Missbrauch (Multiaccount, Scoring „nahm den Bonus - brachte ihn ohne Umsatz“), sanktionierte Zufälle, Selbstausschluss/MLRO-Flaggen.
Externe Quellen: Negativlisten von PSPs/Acquirern, Konsortialbasen (Shared Fraud Intel), Anbieter von Krypto-Tags, BIN-Basen, Risikomodelle.
Regeln und manuelle Eingabe: Compliance/Risk Office Entscheidungen, „freeze“ pro Vorfall.

4) Datenmodell (minimal ausreichend)

json
{
"key": "card:pan_token:9c4f...e1",
"scope": {
"action": ["deposit","withdrawal","payout"],
"jurisdiction": ["EEA","CA-ON"],
"product": ["casino","sports"]
},
"policy": "deny    stop    observe    allow",
"reason_code": "CHARGEBACK    BONUS_ABUSE    SANCTION_MATCH    MFA_BYPASS    KYC_FAIL    CONSORTIUM_HIT",
"source": "risk_engine    psp_x    mlro    consortium",
"confidence": 0. 92,
"created_at": "2025-10-01T12:30:00Z",
"expiry_at": "2026-01-01T00:00:00Z",
"ttl_days": 90,
"review_after": "2025-12-01T00:00:00Z",
"metadata": {
"case_id": "INC-2025-10344",
"notes": "2 CB in 45 days; bonus cycling through 3 wallets,"
"hash_algorithm": "sha256+salt",
"tenant": "brand_A"
}
}

Erforderliche Felder: 'key', 'policy', 'reason _ code', 'source', 'created _ at', 'expiry _ at/ttl'.
Gute Praxis: Speichern Sie Scope (Aktion/Gerichtsbarkeit/Produkt) und Confidence (für weiche Richtlinien).

5) Listendienstarchitektur

Dedizierter ListService (Status „Wahrheit“ für alle Microservices).

API:

`GET /v1/list/check? key =... & ctx =...'- synchrone Prüfung (p99 <5-10 ms von Redis).
„POST/v1/list/upsert“ - Massen-/Einzelaufzeichnung mit Validierung und Prüfung.
'POST/v1/list/bulk' - CSV/NDJSON-Downloads mit Dry-Run.
„POST/v1/list/review/: id“ - Markierung/Amnestie/Verlängerung.
Speicher: Redis (Hot Cache, TTL) + Postgres (History/Audit) + DLQ/Log-Bus (Kafka) für Event-Sourcing und Replikation.
Zugriffe: write - nur Risiko/Compliance/MLRO über RBAC + 4-Augen-Kontrolle auf sensible Schlüssel (Bank/Krypto).
Zuverlässigkeit: idempotent upsert, Datensatzversionierung, exactly-once in der Event-Pipeline, KMS/HSM-Verschlüsselung.

6) Wo man Inspektionen einbettet

1. Zahlungsmittelregistrierung/-bindung - Früher Deny für „verbrannte“ Details.
2. Einzahlung (Initiation) - schnelles Deny/Stop vor dem 3DS/OTP, um die Autorisierung nicht mit offensichtlich schlechten Schlüsseln zu bezahlen.
3. Auszahlung/Auszahlung - separate Listen für Payout-Details (IBAN/Krypto-Adresse); oft strenger als der Eingang.
4. Ändern der Identität - step-up + check; Schutz vor „Kontowechsel vor Auszahlung“.
5. Bonusoperationen - observe/stop nach Missbrauchsmustern (Multiaccount, Geräteketten).

7) Richtlinien (HARD/SOFT) und TTL

HARD (deny/stop) gilt für: Sanktionen, bestätigte Betrug, wiederholte Charjbacks, gestohlene Karten, Maultiere.
SOFT (observe/step-up) mit: schwachen Signalen (neue IP/Gerät, „kalte“ E-Mail-Domain, hohe Velocity), „fragwürdige“ BIN/ASN.

TTL/expiry:

Charjback: 180-540 Tage (je nach Schema und Risiko).
Bonus-Missbrauch: 90-365 Tage (mit Überarbeitung).
Sanktionen: unbefristet mit periodischer Synchronisation der Listen.
Amnestie: Nach erfolgreicher CUS/Geschichte des „sauberen“ Spiels ≥ N Tage und ohne Zwischenfälle - automatische Herabstufung auf observe oder Rückzug.

8) Entscheidungen und Eskalationen (Entscheidungsmatrix)

Signal	Die Politik	Die Handlung	Das Beispiel
Das genaue Spiel der Sanktionen (Name + Dob + Adresse)	DENY	Ablehnen, MLRO benachrichtigen	Ausgabe auf IBAN aus dem Sank. Länder
Wiederholte CB durch PAN-Token	STOP(deposit,withdrawal)	Ein-/Ausstiegseinheit, Risikofall	2 × CB in 45 Tagen
Verdächtiges IP ASN + neues Gerät	OBSERVE	3DS Step-Up / KYC-Tier raise	Kaution €1000 vom Rechenzentrum
VIP c bestätigte IBAN	ALLOW	Überwiegt die Observe	Hohes Limit, saubere Geschichte

9) Pseudocode der Online-Überprüfung

python def is_blocked(keys: list[str], ctx: dict) -> Decision:
keys: ["card:pan_token:..", "ip:..", "device:..", "iban:.."]
ctx: {"action":"withdrawal","jurisdiction":"EEA","product":"casino","amount":1000}
hits = list_service. batch_check(keys, ctx) # из Redis + fallback PG if any(h. policy in ["deny","stop"] for h in hits if h. in_scope(ctx)):
return Decision(block=True, reason=top_reason(hits))
if any(h. policy == "observe" for h in hits if h. in_scope(ctx)):
return Decision(block=False, step_up="3DS_or_KYC", reason="OBS_HIT")
return Decision(block=False)

10) Integration mit Risiko-Engine und Zahlungsbus

Die Risiko-Engine liest zuerst ListService, dann Scoring/ML/Regeln.
Die Reihenfolge in der Pipeline ist „Pre-auth → ListService (hard/soft) → 3DS/OTP → Auth → Clearing“.
Routing: Auf der PSP-Routing-Ebene können Kanäle/Aquarianer „zurückgesetzt“ werden, wenn 'MID'/' BIN' auf den Blocklisten der Anbieter stehen.
Ereignisse: Jede Entscheidung ('DENY/STOP/OBSERVE/ALLOW') geht an Kafka, um ML zu auditieren und zu trainieren.

11) Aktivitäten und Prozesse

Massen-Downloads: CSV/NDJSON mit Validierung und Simulation (wie viele Operationen betroffen sind).
Revue: Tägliche Probenahme für Verlängerung/Rückzug; SLA zur Fallbearbeitung.
Konflikte: Wenn 'ALLOW' und 'DENY' gleichzeitig sind, wenden Sie die restriktivste Regel mit Ausnahme der expliziten VIP-Override an.
Versionierung: Jede Bearbeitung ist eine neue Version des Eintrags; Der alte Zustand wird für Untersuchungen gespeichert.
Incidents: reason_code-Muster, Verknüpfung mit Tickets (Jira/Case-ID).

12) Qualitätsmetriken und Ziele

Trefferquote (HR) = Anteil der Transaktionen, die auf einer Liste stehen.
Hard-Hit Rate (HHR) = Anteil der Hartgesperrten.
Overblock Rate (OBR) = Anteil „falscher“ Sperren (nachfolgender gültiger Zahler).
CB- Uplift↓/Fraud- Loss↓ nach der Einführung.
Zustimmungsrate (AR) für Einzahlungen/Auszahlungen.
Time-to-Wallet (TTW) Auswirkungen von Soft-Maßnahmen (Step-up) auf die Auszahlungsgeschwindigkeit.
Time-to-Decision (p95/p99) für Online-Schecks.

💡 Ziele: HHR wächst ohne spürbare Verschlechterung der AR; OBR ≤ der zulässigen Schwelle (z. B. <0. 3%); p99-Check ≤ 10 ms.

13) Recht und Privatsphäre

Grundlage der Verarbeitung: berechtigtes Interesse/gesetzliche Verpflichtung (AML/Sanktionen/Betrugsprävention).
Minimierung: Speichern Sie Hashes/Token anstelle von Primärdaten (PAN/IBAN), salzen Sie, kontrollieren Sie den Zugriff.
Aufbewahrungsfristen: TTL + allgemeine Retention-Richtlinien (AML/Buchhaltung/Regulierung).
Betroffenenrechte: Prozess auf DSAR/Löschung (unter Berücksichtigung von Compliance-Ausnahmen).
Grenzübergreifend: klare Replikationsgrenzen zwischen Regionen/Tenanten.

14) Häufige Fehler und wie man sie vermeidet

Overblock über IP/ASN: Rechenzentren/CGNAT → Verwenden Sie eine Kombination von Signalen (IP + Gerät + Verhalten).
Zusammenkleben von persönlichen Daten: Normalisieren Sie E-Mail/Telefon, berücksichtigen Sie das Recycling von Zahlen.
Kartenrecycling (PAN-Remission): Binden Sie nach PAN-Token/Krypto-Tokenisierung und nicht nach „rohen“ Daten.
Allgemeine IBAN des Haushalts: Verwenden Sie Scope (nur Payouts) und Observe anstelle von Global Deny.
Krypto-Adressen: Blockieren Sie nicht alles in einer Reihe; Beachten Sie die Tags/den Kontext (Börsen, Depot-Wallets).

15) Zusammenhang mit Bonusmissbrauch und Limits

Bonusmuster: eine Brieftasche/Adresse → viele Konten, schnelle Auszahlung ohne Umsatz - in stop/deny auf payouts.
Limits und TtW: „observe“ kann erhöhten Umsatz/verlängerte TtW vor der Revue erfordern.

16) Beispiele für Schlüssel (kanonische Formen)


card:pan_token:<sha256>
iban:<sha256>
wallet:skrill:<normalized_id_hash>
upi:<vpa_hash>
pix:<pix_key_hash>
crypto:eth:<address_lower>
email:<local+domain_hash>
phone:+<E164_hash>
device:<fp_hash>
ip:<ipv4/6 or /24>
asn:<asn_id>
affiliate:<id>
psp:mid:<id>

17) Checklisten (Checkliste Umsetzung)

1. Definieren Sie policy set: deny/stop/observe/allow + reason_codes.
2. Datenschema: Schlüssel, Scope, ttl/expiry, confidence, audit.
3. Architektur: Redis + PG + Kafka, idempotency, 4-Augen-Steuerung.
4. Einbindung in den Stream: Pre-Auth-Check, Step-Up, Payout-Hardening.
5. Metriken/Dashboard: HR/HHR/OBR/AR/TTW, Zuschnitte nach Jurisdiktionen/Kanälen.
6. Prozesse: Revue/Amnestie, Massendownloads, DSAR, Vorfälle.
7. Teamtraining: Sapport/Risiko/Finanzen, Playbooks zur Konfliktlösung.

18) Mini-Playbooks

Ein CB-Anstieg nach BIN X → ein vorübergehender Stop (Deposit) nach 'bin: X' + reroute zu einem anderen Acquirer, Revue 48 Stunden später.
Ersatz der Requisiten vor der Ausgabe → stop (withdrawal) + KYC-step-up + Verifikation des Benificars.
Ein Konsortium Hit auf der Brieftasche → observe auf Einlagen, Stop auf Payouts zu MLRO Revue.
Sanktionierte Nachrichten über das Land Y → das Land-Scope aktualisieren, Deny auf Payouts aktivieren, Listen neu berechnen.

19) Beispiel einer Admin-Panel-Schnittstelle (Logik)

Suche nach Schlüssel/Maske, Filter: policy, scope, reason, source, expiry <30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
Massenaktionen mit Dry-Run: Zeigen Sie, wie viele Operationen unter die neuen Regeln fallen.

20) Zusammenfassung

Blocklisten sind nicht nur eine „Verbotstabelle“, sondern ein Service auf Plattformebene: mit klarem Datenmodell, starkem Cache, Auditing, kompetenten TTLs und klaren Revue-Prozessen. Mit der richtigen Integration mit der Risiko-Engine werden sie den Betrugstrichter eingrenzen, ohne die Konvertierung zu stören, und die Zahlungen beschleunigen, wo es sicher ist.

Blacklists und Blocklisten in der Zahlungslogik

TL; DR

Kommunikation und Verhalten

Konten und Gegenparteien

Kontakt aufnehmen

Schneller Kontakt

Das Video wird bald aktualisiert

Wir sind derzeit sehr stark ausgelastet