Blacklists et blocklists dans la logique de paiement

TL; DR

Le blacklist/blocklist est une couche gérable d'interdictions « dures » et « douces » dans une pipline de paiement. Sa valeur est de couper rapidement les identifiants à risque (cartes, IBAN, adresses cryptées, appareils, IP, etc.) à des vérifications coûteuses et des tentatives de débit. La clé vers l'efficacité - le modèle précis des données (les durées, la source, la raison, la juridiction, le niveau de l'assurance), le service isolé avec une forte cache et l'audit, les politiques coordonnés de la TTL/amnistie, ainsi que les actes de naissance "hit-rate ↔ overblock".

1) Termes et différences

Blacklist/Deny-list/Blocklist est un ensemble d'identifiants avec lesquels l'opération est violemment rejetée (HARD BLOCK).
Stop-list (contextuel) - verrouillage dans un contexte particulier (par exemple, uniquement sur les conclusions, seulement dans le pays X, seulement pour le montant> € Y).
Watchlist/Greylist - « observation » : l'opération n'est pas rejetée immédiatement, mais traduite en STEP-UP (3DS/OTP/dop. KYC) ou Manual Review.
Allow-list/White-list est une résolution explicite qui surpasse les signaux gris (par exemple, VIP, compte bancaire confirmé).
Negative List (interne) est une liste basée sur des incidents internes (chargbacks, bonus-abyse, coïncidences de sanctions, multi-accounting).

💡 Recommandation : en termes de plateforme, utiliser Deny (dur), Stop (dur scopé), Observer (soft), Allow (override).

2) Ce qui est exactement « listim » : identifiants

Détails de paiement

Carte : PAN-token/FPAN-hash, BIN, émetteur/pays (pour les géo-politiques), terme, nom du support (facultatif, hash/fazzi).
Banque : IBAN/BIC, compte/routing (ACH/SEPA), nom du propriétaire (hash normalisé).
E-wallet/fintech : portefeuille (PayPal/Skrill/Neteller, etc.), UPI/PIX ID, payeur PISP Open-Banking.
Crypto : adresses de L1/L2, étiquettes (mixer/sanctions/haute altitude), chaîne (ETH/BTC/TON, etc.).

Communication et comportement

Email/téléphone (avec normalisation, comptabilisation des domaines « jetables » et des numéros redistribuables).
Périphérique/navigateur-fingerrint, clé client, mobile-ID.
Réseau : IP (ASN/proxy/VPN/Data Center) ,/24 sous-réseaux, géolocalisation.

Comptes et contreparties

UserID/CustomerID, partenaire/affilié, source promotionnelle.
PSP/MID/Acquirer (pour les blocages opérationnels le long des itinéraires).
Adresse/nom (hachage-normalisation, fuzzy-matching par token).

3) Sources de reconstitution des listes

Événements internes : charjbacks, alertes frod, bonus-abyuz (multi-account, scoring « a pris le bonus - a sorti sans tourner »), coïncidences de sanctions, self-exclusion/drapeaux MLRO.
Sources externes : PSP/acquéreurs, bases de consortium (shared fraud intel), fournisseurs de crypto-étiquettes, bases BIN, modèles de risque.
Règles et entrées manuelles : Complis/Risk Office Solutions, « freeze » à l'incident.

4) Modèle de données (minimum suffisant)

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"
}
}

Champs obligatoires : 'key', 'policy', 'reason _ code', 'source', 'created _ at', 'expiry _ at/ttl'.
Bonne pratique : conserver la scope (action/juridiction/produit) et la confiance (pour les politiques douces).

5) L'architecture du service de liste

Service dédié ListService (statut « vérité » pour tous les microservices).

API:

`GET /v1/list/check? key =... & ctx =... 'est une vérification synchrone (p99 <5-10 ms de Redis).
'POST/v1/list/upsert 'est un enregistrement de masse/unité avec validation et audit.
'POST/v1/list/bulk '- téléchargements CSV/NDJSON avec dry-run.
'POST/v1/list/review/: id '- marquage/amnistie/extension.
Stockage : Redis (hot cache, TTL) + Postgres (historique/audit) + DLQ/log bus (Kafka) pour l'événement-sourcing et la réplication.
Accès : write - uniquement risque/conformité/MLRO via le contrôle RBAC + 4 yeux sur les clés sensibles (bancaire/crypto).
Fiabilité : idempotent upsert, versioning des enregistrements, exactly-once dans la chaîne d'événements, cryptage KMS/HSM.

6) Où intégrer les contrôles

1. Enregistrement/ancrage d'un moyen de paiement - Deny précoce pour les détails « brûlés ».
2. Dépôt (initiation) - rapide Deny/Stop jusqu'à 3DS/OTP, afin de ne pas payer pour l'autorisation sur les clés notoirement mauvaises.
3. Retrait/paiement - listes séparées pour les détails payout (IBAN/adresse cryptée) ; souvent plus stricte que sur l'entrée.
4. Modifier les détails - step-up + check ; protection contre le « changement de compte avant le retrait ».
5. Les opérations de bonus - observer/stop sur les schémas d'abyse (multi-account, chaînes d'appareils).

7) Politiques (HARD/SOFT) et TTL

Appliquer HARD (deny/stop) à : sanctions confirmées par frod, chargbacks répétés, cartes volées, mules.
SOFT (observateur/step-up) sous : signaux faibles (nouveau IP/appareil, domaine e-mail « froid », haute velocité), BIN/ASN « douteux ».

TTL/expiry:

Charjback : 180-540 jours (selon les schémas et les risques).
Bonus-abyse : 90-365 jours (avec révision).
Sanctions : indéfiniment avec synchronisation périodique des listes.
Amnistie : Après le succès du KUS/l'histoire du jeu « propre » ≥ N jours et sans incidents - rétrogradation automatique à observer ou retrait.

8) Solutions et escalade (Decision Matrix)

Signal	Politique	Action	Exemple
Match exact des sanctions (nom + dob + address)	DENY	Refuser, notifier MLRO	Sortie sur IBAN du traîneau. pays
CB répétée par le jeton PAN	STOP(deposit,withdrawal)	Bloc d'entrée/sortie, case à risque	2 × CB en 45 jours
ASN IP + nouveau périphérique suspect	OBSERVE	3DS Step-Up / KYC-Tier raise	Dépôt de 1000 € du centre de données
VIP avec IBAN confirmé	ALLOW	Surpasse l'observateur	Limite élevée, histoire pure

9) Pseudo-code de vérification en ligne

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) Intégration avec le moteur de risque et le bus de paiement

Le moteur de risque lit d'abord ListService, puis scoring/ML/règles.
Ordre dans le pipline : 'Pre-auth → ListService (hard/soft) → 3DS/OTP → Auth → Clearing'.
Routage : au niveau du routage PSP, il est possible de « réinitialiser » les canaux/aquayers si 'MID'/' BIN' entre dans les feuilles de flux des fournisseurs.
Evénements : chaque décision ('DENY/STOP/OBSERVER/ALLOW') va à Kafka pour l'audit et la formation complémentaire de ML.

11) Opérations et processus

Téléchargements en masse : CSV/NDJSON avec validation et simulation (combien d'opérations seront affectées).
Revue : prélèvement quotidien pour extension/retrait ; SLA pour le traitement des cas.
Conflits : si « ALLOW » et « DENY » sont à la fois, appliquez la règle most-restrictive, sauf pour les VIP-override explicites.
Versioning : toute modification est une nouvelle version de l'enregistrement ; l'ancien état est conservé pour les enquêtes.
Incidents : modèles de reason_code, communication avec les tickets (Jira/Case-ID).

12) Métriques de qualité et objectifs

Hit Rate (HR) = proportion d'opérations inscrites sur une liste.
Hard-Hit Rate (HHR) = proportion de personnes fortement bloquées.
Taux d'overblock (ROB) = proportion de verrous « faux » (payeur validé subséquent).
CB- Uplift↓/Fraud- Loss↓ après sa mise en œuvre.
Taux approval (RA) pour les dépôts/conclusions.
Time-to-Wallet (TTW) impact des mesures soft (step-up) sur la vitesse de paiement.
Time-to-Decision (p95/p99) pour les chèques en ligne.

💡 Objectifs : Les RHS augmentent sans détérioration notable des RA ; OBR ≤ seuil admissible (par exemple, <0. 3%); p99 check ≤ 10 ms.

13) Droit et vie privée

Base du traitement : intérêt légitime/obligation légale (AML/sanctions/fred-prevention).
Minimisation : nous stockons des hashs/tokens au lieu des données primaires (PAN/IBAN), des sels, des contrôles d'accès.
Durée de conservation : TTL + Politiques générales de rétention (AML/Buchet/Réglementation).
Droits des sujets : processus de DSAR/suppression (sous réserve d'exceptions de conformité).
Transfrontalité : des limites claires de réplication entre les régions/tenants.

14) Erreurs fréquentes et comment les éviter

Overblock par IP/ASN : data centers/CGNAT → utilisez une combinaison de signaux (IP + appareil + comportement).
Fusionner les données personnelles : normaliser l'e-mail/téléphone, prendre en compte le recyclage des numéros.
Recyclage des cartes (réémission PAN) : liez-le par token PAN/crypto-tokenization plutôt que par données « brutes ».
IBAN total du ménage : appliquer la scope (payouts uniquement) et observer au lieu du deny global.
Adresses cryptées : ne bloquez pas tout dans une rangée ; prendre en compte les étiquettes/contexte (bourses, porte-monnaie castodial).

15) Lien avec bonus-abyse et limites

Modèles de bonus : un portefeuille/adresse → de nombreux comptes, sortie rapide sans rotation - dans stop/deny sur payouts.
Limites et TtW : « observer » peut exiger une augmentation du chiffre d'affaires/TtW allongé à la rhubarbe.

16) Exemples de clés (formes canoniques)


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) Checklists (chèque de mise en œuvre)

1. Définir la politique set : deny/stop/observer/allow + reason_codes.
2. Schéma de données : clés, scope, ttl/expiry, confiance, audit.
3. Architecture : Redis + PG + Kafka, idempotency, contrôle à 4 yeux.
4. Mise en flux : pré-auth check, step-up, payout-hardening.
5. Métriques/dashboard : HR/HHR/OBR/AR/TTW, coupes par pays/canal.
6. Processus : revues/amnistie, téléchargements massifs, DSAR, incidents.
7. Formation des équipes : Sappport/Risque/Finance, Pleybooks de résolution de conflit.

18) Mini-playbooks

Sursaut de CB par BIN X → arrêt temporaire (deposit) par 'bin : X' + reroute sur l'autre écuyer, je rummage dans 48 h.
Échange de détails avant la sortie → stop (withdrawal) + KYC-step-up + vérification Benifar.
Consortium sur le portefeuille → observer sur les dépôts, stop sur les payouts à MLRO-revue.
Nouvelles de sanctions pour le pays Y → mettre à jour country-scope, inclure deny sur payouts, recalculer les listes.

19) Exemple d'interface admin-panel (logique)

Recherche par clé/masque, filtres : policy, scope, reason, source, expiry <30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
Action de masse avec dry-run : montrer combien d'opérations seront soumises à de nouvelles règles.

20) Résumé

Les blocs-feuilles ne sont pas seulement une « table d'interdictions », mais un service de niveau plateforme : avec un modèle de données clair, un cache fort, un audit, des TTL compétents et des processus de jalousie clairs. S'ils sont correctement intégrés au moteur à risque, ils réduiront l'entonnoir frod sans détruire la conversion et accéléreront les paiements là où c'est sûr.

Blacklists et blocklists dans la logique de paiement

TL; DR

Communication et comportement

Comptes et contreparties

Prendre contact

Contact rapide

La vidéo sera bientôt mise à jour

Nous sommes actuellement très occupés par des projets