Blacklists y hojas de flujo en lógica de pago

TL; DR

Blacklist/Block List es una capa controlada de prohibiciones «rígidas» y «blandas» en una paipline de pago. Su valor es el corte rápido de identificadores notoriamente arriesgados (tarjetas, IBAN, direcciones criptográficas, dispositivos, IP, etc.) a costosas comprobaciones e intentos de cancelación. La clave de la eficiencia es un modelo claro de datos (fecha de vencimiento, fuente, causa, jurisdicción, nivel de confianza), un servicio aislado con caché y auditoría fuertes, políticas de amnistía/TTL coherentes, y métricas de «hit-rate ↔ overblock».

1) Términos y diferencias

Blacklist/Deny-list/Block List (Lista de bloques): conjunto de identificadores con los que la operación se rechaza con dureza cuando coincide (HARD BLOCK).
Stop-list (contextual) - bloqueo en un contexto específico (por ejemplo, sólo en conclusiones, sólo en el país X, sólo para la cantidad> € Y).
Watchlist/Greylist - «observación»: la operación no se rechaza inmediatamente, sino que se traduce en STEP-UP (3DS/OTP/dop. KYC) o Revisión Manual.
Allow-list/White-list es una resolución explícita que supera las señales grises (por ejemplo, VIP, cuenta bancaria confirmada).
Negative List (interno) es una lista basada en incidentes internos (charjbacks, bonus abuse, coincidencias sancionadoras, multiaccounting).

💡 Recomendación: en términos de plataforma, usar Deny (hard), Stop (scoped hard), Observe (soft), Allow (override).

2) Qué es exactamente «listamos»: identificadores

Detalles de pago

Mapa: token PAN/hash FPAN, BIN, emisor/país (para políticas geográficas), fecha límite, nombre del medio (opcional, hash/fazzie).
Bancario: IBAN/BIC, cuenta/enrutamiento (ACH/SEPA), nombre del propietario (hash normalizado).
E-wallet/fintech: monedero (PayPal/Skrill/Neteller, etc.), ID UPI/PIX, pagador PISP de banca abierta.
Crypto: direcciones de L1/L2, etiquetas (mixer/sanciones/alto riesgo), cadena (ETH/BTC/TON, etc.).

Comunicación y comportamiento

Email/teléfono (con normalización, contabilidad de dominios «desechables» y números redistribuibles).
Dispositivo/navegador de huellas electrónicas, clave de cliente, ID móvil.
Red: IP (ASN/proxy/VPN/data center) ,/24-subredes, geo-locking.

Cuentas y contrapartes

UserID/CustomerID, socio/afiliado, fuente promocional.
PSP/MID/Acquirer (para bloqueos operativos en rutas).
Dirección/FIO (normalización hash, fuzzy-matching por tokens).

3) Fuentes de reposición de listas

Eventos internos: charjbacks, fred alerts, bonus abuse (multiaccount, scoring «se llevó el bono - sacado sin giro»), casualidades sancionadoras, self-exclusion/banderas MLRO.
Fuentes externas: hojas negativas de PSP/Ecuador, bases de consorcio (intel de fraud compartido), proveedores de etiquetas criptográficas, bases BIN, modelos de riesgo.
Reglas y entrada manual: soluciones de cumplimiento/oficina de riesgo, «freeze» por incidente.

4) Modelo de datos (mínimo suficiente)

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

Campos obligatorios: 'key', 'policy', 'reason _ code', 'source', 'created _ at', 'expiry _ at/ttl'.
Buena práctica: almacenar scope (acción/jurisdicción/producto) y confidence (para políticas blandas).

5) Arquitectura del servicio de listas

Servicio dedicado ListService (estado de «verdad» para todos los microservicios).

API:

`GET /v1/list/check? key =... & ctx =... '- verificación sincrónica (p99 <5-10 ms de Redis).
'POST/v1/list/upsert' es un registro masivo/unitario con validación y auditoría.
'POST/v1/list/bulk' - descargas CSV/NDJSON desde dry-run.
'POST/v1/list/review/: id' - Marcado/amnistía/prórroga.
Almacenamiento: Redis (caché caliente, TTL) + Postgres (historial/auditoría) + DLQ/bus de registro (Kafka) para event-sourcing y replicación.
Accesos: escritura - solo riesgo/cumplimiento/MLRO a través de RBAC + control de 4 ojos para claves sensibles (banca/cripto).
Fiabilidad: upsert idempotent, versioning de registros, exactly-once en la canalización de eventos, cifrado KMS/HSM.

6) Dónde incrustar los controles

1. Registro/enlace de medios de pago - Deny temprano para los datos «quemados».
2. Depósito (iniciación) - rápido Deny/Stop antes de 3DS/OTP para no pagar por la autorización de las claves notoriamente malas.
3. Salida/pago: listas separadas para los datos de pago (IBAN/dirección de cifrado); a menudo más estricta que la entrada.
4. El cambio de los datos es step-up + check; protección contra el «cambio de cuenta antes de la retirada».
5. Las operaciones de bonificación son observe/stop a través de esquemas de abius (multiaccount, cadenas de dispositivos).

7) Políticas (HARD/SOFT) y TTL

Aplicar HARD (deny/stop) a: sanciones, frod confirmado, charjbacks repetidos, tarjetas robadas, mulas.
SOFT (observe/step-up) cuando: señales débiles (nuevo IP/dispositivo, dominio de correo electrónico «frío», alta velocidad), «dudoso» BIN/ASN.

TTL/expiry:

Charjback: 180-540 días (dependiendo de los esquemas y el riesgo).
Bonificación abusiva: 90-365 días (con revisión).
Sanciones: indefinidas con sincronización periódica de listas.
Amnistía: Después de un éxito de CUS/historial de juego «puro» ≥ N días y sin incidentes - descenso automático a observe o retirada.

8) Soluciones y escalamiento (Decision Matrix)

Señal	Política	Acción	Ejemplo
Partido exacto de las sanciones (name + dob + address)	DENY	Rechazar, notificar a MLRO	Salida en IBAN desde el trineo. países
CB repetido por token PAN	STOP(deposit,withdrawal)	Entrada/salida de la unidad, caso en riesgo	2 × CB en 45 días
IP ASN + nuevo dispositivo sospechoso	OBSERVE	3DS Step-Up / KYC-Tier raise	Depósito de 1000 € desde el centro de datos
VIP con IBAN confirmado	ALLOW	Supera a observe	Alto límite, historia pura

9) Seudocodo de verificación en línea

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) Integración con el motor de riesgo y el bus de pago

El motor de riesgo primero lee ListService, luego lee las reglas de puntuación/ML/.
Orden en pipeline: 'Pre-auth → ListService (hard/soft) → 3DS/OTP → Auth → Clearing'.
Enrutamiento: en el nivel de enrutamiento PSP, se pueden «anular» los canales/acuarios si 'MID '/' BIN' han caído en las hojas de flujo de los proveedores.
Eventos: Cada solución ('DENY/STOP/OBSERVE/ALLOW') se va a Kafka para auditar y aprender ML.

11) Operaciones y procesos

Descargas masivas: CSV/NDJSON con validación y simulación (cuántas operaciones afectarán).
Rugido: muestreo diario para prolongación/retirada; SLA para el manejo de casos.
Conflictos: si 'ALLOW' y 'DENY' al mismo tiempo, aplique la regla most-restrictive, excepto VIP-override explícito.
Versionar: cualquier edición es una nueva versión de la grabación; el estado antiguo se almacena para las investigaciones.
Incidentes: plantillas de reason_code, comunicación con tickets (Jira/Case-ID).

12) Métricas de calidad y objetivos

Hit Rate (HR) = proporción de operaciones incluidas en cualquier lista.
Tasa de Hard-Hit (HHR) = proporción de bloqueados severamente.
Overblock Rate (OBR) = proporción de bloqueos «falsos» (pagador válido posterior).
CB- Uplift↓/Fraud- Loss↓ después de la implementación.
Approval Rate (AR) para depósitos/retiros.
Time-to-Wallet (TTW) impacto de las medidas soft (step-up) en la velocidad de pago.
Time-to-Decision (p95/p99) para cheques en línea.

💡 Objetivos: El HHR crece sin deterioro perceptible del AR; OBR ≤ un umbral válido (por ejemplo, <0. 3%); p99 check ≤ 10 ms.

13) Derecho y privacidad

Base del tratamiento: interés legítimo/obligación legal (AML/sanciones/prevención de fraude).
Minimización: almacenamos hashes/tokens en lugar de datos primarios (PAN/IBAN), solim, controlamos el acceso.
Plazos de retención: TTL + políticas generales de retención (AML/contabilidad/regulación).
Derechos de las entidades: proceso de DSAR/eliminación (sujeto a excepciones de cumplimiento).
Transfronterez: límites claros de replicación entre regiones/tenantes.

14) Errores frecuentes y cómo evitarlos

Overblock por IP/ASN: centros de datos/CGNAT → utilice una combinación de señales (IP + dispositivo + comportamiento).
Fusión de datos personales: normalice el correo electrónico/teléfono, tenga en cuenta el reciclaje de números.
Reciclaje de tarjetas (reemisión PAN): vincule mediante token PAN/cifrado-tokenización en lugar de por datos «crudos».
Total IBAN del hogar: aplique scope (sólo payouts) y observe en lugar de global deny.
Direcciones cifradas: no bloquee todo de forma consecutiva; tener en cuenta las etiquetas/contexto (intercambios, carteras castodiales).

15) Relación con bonus abusivo y límites

Patrones de bonificación: una monedero/dirección → muchas cuentas, salida rápida sin rotación - en stop/deny en payouts.
Límites y TtW: «observe» puede requerir una mayor rotación/TtW alargado a rugido.

16) Ejemplos de claves (formas canónicas)


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) Listas de comprobación (lista de comprobación de la implementación)

1. Definir el conjunto de políticas: deny/stop/observe/allow + reason_codes.
2. Esquema de datos: claves, scope, ttl/expiry, confidence, audit.
3. Arquitectura: Redis + PG + Kafka, idempotency, control de 4 ojos.
4. Insertar en el flujo: pre-auth check, step-up, payout-hardening.
5. Métricas/dashboard: HR/HHR/OBR/AR/TTW, cortes por jurisdicciones/canales.
6. Procesos: rugido/amnistía, descargas masivas, DSAR, incidentes.
7. Formación de equipos: sapport/riesgo/finanzas, playbucks de solución de conflictos.

18) Mini playbucks

Ráfaga de CB por BIN X → stop temporal (depósito) por 'bin: X' + reroute a otro ecuador, rugiendo a las 48 h.
Sustitución de los datos antes de la salida → stop (withdrawal) + KYC-step-up + verificación del benificador.
Un éxito de consorcio en la cartera → observe en los depósitos, stop en payouts hasta el rugido MLRO.
Noticias sancionadoras sobre el país Y → actualizar el país-scope, incluir deny en payouts, contar las listas.

19) Ejemplo de interfaz de panel de administración (lógica)

Búsqueda por clave/máscara, filtros: policy, scope, reason, source, expiry <30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
Acciones masivas con dry-run: muestra cuántas operaciones caerán bajo las nuevas reglas.

20) Resumen

Las hojas de flujo no son solo una «tabla de prohibiciones», sino un servicio de nivel de plataforma: con un modelo de datos claro, caché fuerte, auditoría, TTL competente y procesos de rugido claros. Cuando se integren correctamente con el motor de riesgo, estrecharán el embudo de frod sin destruir la conversión y acelerarán los pagos donde sea seguro.

Blacklists y hojas de flujo en lógica de pago

TL; DR

Comunicación y comportamiento

Cuentas y contrapartes

Póngase en contacto

Contacto rápido

El vídeo se actualizará pronto

Estamos actualmente muy ocupados con proyectos