Blacklist e blocchi nella logica dei pagamenti

TL; DR

Blacklist/Block List è un livello controllato di restrizioni rigide e morbide nella pipline di pagamento. Il suo valore è il taglio rapido di identificatori a rischio (mappe, IBAN, indirizzi cripto, dispositivi, IP, ecc.) a controlli costosi e tentativi di riscossione. La chiave per l'efficienza è un modello di dati chiaro (data di scadenza, origine, causa, giurisdizione, livello di sicurezza), un servizio isolato con una cache forte e un controllo, regole di amnistia TTL coerenti e metriche «hit-rate overblock».

1) Termini e differenze

Blacklist/Deny-list/Foglio di blocco è un insieme di identificatori con cui l'operazione viene rigettata (HARD BLOCK).
Stop-list - Blocca in un contesto specifico (ad esempio solo per le conclusioni, solo nel paese X, solo per la somma> Y €).
Watchlist/Greylist - «Osservazione»: l'operazione non viene rifiutata immediatamente, ma viene tradotta in STEP-UP (3DS/OTP/supplemento. KYC) o Manual Review.
Allow-list/White-list è una risoluzione esplicita che supera i segnali grigi (ad esempio VIP, banca-account confermata).
La Lista di Negative (interna) è una lista basata su incidenti interni (charjback, bonus-abuse, corrispondenze sanzionatorie, multiacunting).

💡 Raccomandazione: in termini di piattaforma utilizzare Deny (hard), Stop (scoped hard), Osserva (soft), Allow (override).

2) Esattamente «fogliamoci»: identificatori

Informazioni di pagamento

Scheda PAN-token/FPAN-hash, BIN, emittente/paese (per geo-regole), scadenza, nome del supporto (opzionale, hash/phaszi).
Bancari: BAN/BIC, conto/routing (ACH/SEPA), nome proprietario (hash normalizzato).
E-wallet/fintech: portafoglio (PayPal/Skrill/Neteller, ecc.), UPI/PIX ID, Open-banking PISP pagatore.
Crypto: indirizzi L1/L2, etichette (mixer/sanzioni/alto rischio), catena (ETH/BTC/TON, ecc.).

Comunicazione e comportamento

Email/telefono (con normalizzazione, registro dei domini usa e getta e dei numeri ridistribuiti).
Dispositivo/browser fingerprint, chiave client, mobile-ID.
Rete: IP (ASN/proxy/VPN/Data Center) ,/24 subnet, geo-locale.

Account e contest

UserID/CustomerID, socio/affiliato, fonte promozionale.
PSP/MID/Activer (per blocchi operativi su rotte).
Indirizzo/FIO (hash normalization, fuzzy-matching per token).

3) Sorgenti di ricambio degli elenchi

Eventi interni: Charjback, Frod-Alert, Bonus-Abuse (Multiplacount, Screening «Preso Bonus - Fuori Giro»), corrispondenze sanzionatorie, self-exclusion/Flag MLRO.
Fonti esterne: fogli PSP/Equayers negativi, basi di consorzio (shared fraud intel), provider di crittografia, basi BIN, modelli di rischio.
Regole e input manuali: soluzioni di compilazione/ufficio di rischio, «freeze» per l'incidente.

4) Modello di dati (minimo sufficiente)

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

I campi obbligatori sono: «key», «policy», «reason _ code», «source», «created _ at», «expiry _ at/ttl».
Buona pratica: conservare scope (azione/giurisdizione/prodotto) e confidence (per regole morbide).

5) Architettura del servizio elenchi

Servizio di ListService dedicato (stato di verità per tutti i microservizi).

API:

`GET /v1/list/check? key =... & ctx =... 'è un controllo sincrono (p99 <5-10 ms da Redis).
«POST/v1/list/upsert» è un record di massa/singolo con convalida e revisione.
«POST/v1/list/bulk» - download CSV/NDJSON con dry-run.
«POST/v1/list/review/: id» - contrassegno/amnistia/estensione.
Archivio: Redis (hot cache, TTL) + Postgres (cronologia/controllo) + DLQ/Logg Bus (Kafka) per l'event-surcing e la replica.
Disponibili: write - solo rischio/compilation/MLRO tramite RBAC + controllo a 4 occhi su chiavi sensibili (banche/crypto).
Affidabilità: upsert idempotent, versioning dei record, exactly-once nella catena di montaggio eventi, crittografia KMS/HSM.

6) Dove incorporare i controlli

1. Registrazione/collegamento dei mezzi di pagamento - Deny precoce per gli oggetti «bruciati».
2. Deposito (iniziazione) - Veloce Deny/Stop fino a 3DS/OTP per non pagare l'autorizzazione con chiavi chiaramente pessime.
3. Output/pagamento - elenchi separati per informazioni payout (BAN/crypto-indirizzo); Spesso più severa dell'entrata.
4. Modifica delle informazioni - step-up + check; protezione da «cambio di conto prima del ritiro».
5. Le operazioni di bonus sono observe/stop su diagrammi di abyuse (multiacount, catene di dispositivi).

7) Regole (HARD/SOFT) e TTL

HARD (deny/stop): sanzioni, frode confermato, charjback ripetuti, carte rubate, muli.
SOFT (osserva/step-up) a: segnali deboli (nuovo dispositivo IP, dominio e-mail freddo, high-velocity), «discutibili» BIN/ASN.

TTL/expiry:

Charjback: 180-540 giorni (a seconda degli schemi e dei rischi).
Bonus abuse: 90-365 giorni (con revisione).
Sanzioni a tempo indeterminato con sincronizzazione periodica degli elenchi.
Amnesty: Dopo il successo del CUS/storia del gioco «pulito» di N giorni e senza incidenti, il declassamento automatico o la rimozione.

8) Soluzioni e scalate (Decision Matrix)

Segnale	Criteri	Azione	Esempio
Partita di sanzioni esatta (name + dob + address)	DENY	Rifiuta, notifica MLRO	Output a IBAN dalla slitta. Paesi
Nuovo CB per token PAN	STOP(deposit,withdrawal)	Blocco ingresso/uscita, valigetta a rischio	2 x CB in 45 giorni
IP ASN sospetto + nuovo dispositivo	OBSERVE	3DS Step-Up / KYC-Tier raise	Deposito €1000 con data center
VIP con IBAN confermato	ALLOW	Supera observe	Limite elevato, cronologia netta

9) Pseudo-codice di controllo online

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) Integrazione con il motore di rischio e il bus di pagamento

Il motore di rischio prima legge il ListService, poi lo screening/ML/regole.
Ordine in pipline: "Pre-auth " (hard/soft) 3DS/OTP "Auth" Clearing ".
Routing: a livello di routing PSP, è possibile «azzerare» i canali/acquiatori se «MID »/« BIN» è finito nei blocchi dei provider.
Eventi: ogni soluzione ('DENY/STOP/OSSERVA/ALLOW') viene inviata a Kafka per l'ispezione e l'apprendimento di ML.

11) Operazioni e processi

Download di massa: CSV/NDJSON con convalida e simulazione (quante operazioni interessano).
Ringhiera: campionamento giornaliero per estensione/rimozione; SLA per l'elaborazione delle valigette.
Conflitti: se ALLOW è DENY contemporaneamente, applica la regola della protezione dei VIP override.
Versioning: qualsiasi modifica è una nuova versione del record; Il vecchio stato è conservato per le indagini.
Incidenti: modelli di reason _ code, associazione a ticket (Jira/Case-ID).

12) Metriche di qualità e obiettivi

Hit Rate (HR) = Percentuale di operazioni inserite in qualsiasi elenco.
Hard-Hit Rate (HHR) = percentuale di bloccati rigidamente.
Overblock Rate (OBR) = quota di blocchi «falsi» (successivi pagatori validi).
CB- /Fraud's dopo l'implementazione.
Approval Rate (AR) per depositi/conclusioni.
Time-to-Wallet (TTW) influenza le misure soft (step-up) sulla velocità di pagamento.
Time-to-Decection (p95/p99) per gli assegni online.

💡 Obiettivi: HHR cresce senza peggiorare notevolmente AR; OBR ≤ la soglia consentita (ad esempio <0). 3%); p99 check. 10 mc.

13) Giurisprudenza e privacy

Basi di elaborazione: legittimo interesse/obbligo legale (AML/sanzioni/Frod Prevention).
Minimizzazione: memorizzando hash/token anziché dati primari (PAN/BAN), sale, controllo dell'accesso.
Data di conservazione: TTL + regole generali di ritenzione (AML/Bubbit/Regolazione).
Diritti dei soggetti: processo di eliminazione DSAR (con esclusioni complete).
Transfrontaliera: limiti di replica chiari tra regioni/tenenti.

14) Errori frequenti e come evitarli

Overflow IP/ASN: data center/CGNAT → usa una combinazione di segnali (IP + dispositivo + comportamento).
Scarica dati personali: normalizza e-mail/telefono, tiene conto della ricollocazione dei numeri.
Riciclaggio mappe (reemersione PAN) - Aggancia il token PAN/cripto-tokenizzazione anziché i dati crudi.
Comune BAN delle famiglie: applica scope (solo payouts) e osserva invece di global deny.
Indirizzi cripto: non bloccare tutto; Tenere conto delle etichette/contesti (borse, portafogli castodiali).

15) Collegamento con bonus-abyus e limiti

Bonus-Pattern: un portafoglio/indirizzo, molti account, output rapido - stop/deny su payouts.
Limiti e : «observe» può richiedere un aumento del giro/allungamento fino alla gelosia.

16) Esempi di chiavi (forme canoniche)


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) Elenchi di controllo (assegno-foglio di implementazione)

1. Definisci policy set: deny/stop/osserva/allow + reason _ codes.
2. Schema dati: chiavi, scope, ttl/expiry, confidence, audit.
3. Architettura: Redis + PG + Kafka, idempotency, controllo a 4 occhi.
4. Inserimento nel flusso: pre-auth check, step-up, payout-hardening.
5. Metriche/dashboard: HR/HHR/OBR/AR/TTW, tagli per giurisdizioni/canali.
6. Processi: ravvedimento/amnistia, download di massa, DSAR, incidenti.
7. Formazione dei comandi: zapport/rischio/finanza, playbook per la risoluzione dei conflitti.

18) Mini playbook

→ CB su BIN X-stop temporaneo (deposit) su 'bin: X' + reroute su un altro equayer, geloso dopo 48 ore.
Sostituzione degli oggetti prima dell'output → stop (withdrawal) + KYC-step-up + verifica del benifero.
Un successo di consorzio per il portafoglio di → observe per i depositi, stop per i payouts fino alla gelosia MLRO.
Le notizie relative alle sanzioni per il paese Y devono aggiornare il country-scope, includere deny sui payouts, ricalcolare le liste.

19) Esempio di interfaccia dashboard (logica)

Ricerca chiave/maschera, filtri policy, scope, reason, source, expiry <30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
Azioni di massa con dry-run - Mostra quante operazioni verranno sottoposte alle nuove regole.

20) Riepilogo

I blocchi non sono solo una «tabella dei divieti», ma un servizio a livello di piattaforma, con un modello di dati chiaro, una cache forte, un controllo, una TTL corretta e processi di gelosia ben definiti. Se integrati correttamente con il motore di rischio, restringeranno il vortice di frodo senza distruggere la conversione e accelereranno i pagamenti laddove questo sia sicuro.

Blacklist e blocchi nella logica dei pagamenti

TL; DR

Comunicazione e comportamento

Account e contest

Mettiti in contatto

Contatto rapido

Il video sarà aggiornato presto

Siamo attualmente molto impegnati con i progetti