RR/listas de sanciones: cribado

1) ¿Por qué la detección de RR/sanciones en iGaming

El cribado es un circuito básico de cumplimiento: impide el trabajo con personas/entidades prohibidas y reduce el riesgo de sanciones regulatorias, congelación de canales de pago y bloqueos en bancos/PSP. En iGaming (MCC 7995), complementa el monitoreo KYC/KYB y AML y afecta directamente la disponibilidad de la infraestructura de pago y la velocidad de los retiros.

2) Fuentes y tipos de listas

Listas de sanciones: internacionales (ONU), supranacionales/regionales (UE, Reino Unido), nacionales (OFAC de Estados Unidos, así como registros locales).
PEP (Politically Exposed Persons): titulares/ex funcionarios públicos + familiares y allegados.
Adverse Media (medios negativos): investigaciones criminales, fraude, corrupción, etc. - capa auxiliar.
Prohibiciones de facto y embargos comerciales: países, sectores, activos.
Direcciones criptográficas con etiquetas sancionadoras: intercambios/carteras/mezcladores, alto riesgo según KYT.

3) Cuándo y a quién capturar (CUS/CUV/operaciones)

KYC (físico): en el registro (Tier 1), antes de la primera salida, en la actualización a Tier 2/3, en el cambio de FIO/dirección/documento, la revisión diaria.
KYB (Jurlitz): empresa, directores/oficiales, UBO; en el onboarding, las actualizaciones de la estructura, una vez cada 6-12 meses el rescribido planificado.
Eventos operativos: grandes depósitos/retiros (umbrales desencadenantes), cambio de geo/dispositivo, aumento del riesgo en AML.

4) Calidad de los datos y normalización (antes de los partidos)

Normalización de la FIO: registro, espacios, diacrítica, transliteración (GOST/ISO/regulaciones nacionales), formularios alternativos (Aleksandr/Alexander).
Fechas de nacimiento: formatos 'DD/MM/YYYY' vs 'YYYY-MM-DD', error ± 1 día (errores de documentos).
Direcciones: países/regiones en codificaciones ISO, guías de ciudades.
Organizaciones: formulario legal (LLC/Ltd/AO), alias/antiguos nombres, números de registro.
Crypto: normalización de direcciones y proveedores (intercambios, castodianos), red/cadena.

5) Match: preciso, difuso y reducción de falsos positivos

• Aprox match por ID: pasaporte/reg. número, fecha/lugar de nacimiento, número de registro de la empresa.
• Fuzzy match (algoritmos de distancia: Levenshtein, Jaro-Winkler) con umbrales de similitud.
• Alias/AKAs: yuxtaposición por nombres alternativos, apellidos de soltera, latín/cirílico.

• Requerir coincidencia en un mínimo de dos caracteres independientes (nombre + fecha de nacimiento/nombre + país/número de documento).
• Desduplicación de alertas (consolidación de partidos por persona/empresa).
• Geofiltros y contexto (país de nacimiento vs residencia actual).
• Listas blancas (allow-list) para «coincidencias falsas» confirmadas con el período de comprobación (expiry).

6) Clasificación de alertas y priorización

Seleccione el umbral de fuzzy-match por mercado/idioma (para el cirílico - justo por encima, dada la transliteración).

7) Proceso de rugido (flujo de trabajo)

1. Enriquecimiento: apriete los datos del cliente/contraparte (KYC/KYB, geo, pagos).
2. Verificación de origen: conciliar la entrada en el registro/agregador (relevancia, fecha de actualización).
3. Decisión: Approve (coincidencia falsa), EDD/límites, Reject/Freeze.
4. Documentación: causa, campos de asignación utilizados, referencias de origen, fecha de caducidad de la solución (para allow-list).
5. Comunicación: solicitud de documentos/explicaciones, cumplimiento de la prohibición de tipping-off en la RAE.

• Alto: ≤ 4 h (bloqueos críticos)
• Medium: ≤ 24 ч
• Bajo: ≤ 72 h

8) Reseñas y eventos (event-driven)

Diario: ejecución automática de todos los perfiles/contrapartes activos.
On-demand: cuando se cambia la dirección FIO/documento/UBO/directores, en las conclusiones importantes, en las alertas AML.
Versionar listas: captura la fecha/versión del origen en los logs para reproducir la solución después de un año.

9) Integración con KYB/KYC/AML/Payments

KYC/KYB: cribado en el momento de onboarding y en cualquier actualización de nivel.
Monitoreo AML: la detección positiva aumenta la prioridad de las alertas (ver Rapid In-Out, Structuring).
Payments Orchestrator: holds/limits automáticos con alertas altas; enrutamiento a métodos «seguros».
KYT/Travel Rule: riesgos sancionadores por direcciones criptográficas, intercambio de atributos entre VASP (cuando corresponda).

10) Datos, privacidad y auditoría

Minimización: almacene sólo los campos utilizados para la solución; enmascarar los números de documento.
Cifrado y acceso: KMS/HSM, RBAC, registro de llamadas; prohibición de descargas fuera de los canales protegidos.
Retention: almacenamiento de soluciones/registros de acuerdo con la regulación (a menudo 5 + años).
Auditoría de seguimiento: quién/cuándo/qué coincidió, qué versión de la lista, qué resultado.

11) Métricas y calidad del proceso

Precisión y velocidad

Precision/Recall por marcado manual (sample), proporción de falsos positivos (FP).
SLA hit rate (High/Med/Low), tiempo medio hasta la solución (p50/p95).

Porcentaje de reseñas con cambio de estado, frecuencia de actualización de listas.
Número de alertas por 1k onboarding/por 1k clientes activos.
El costo unitario de un caso.

Riesgo/negocio

Número de casos Stop (sanciones) y pagos impedidos.
Correlación de «cribado positivo» con incidentes de AML, charjbacks.

12) Selección de proveedor y arquitectura

• Cobertura: listas internacionales + locales (fuentes oficiales), frecuencia de actualización.
• Calidad de los partidos: umbrales personalizables, soporte para transliteraciones, alias, fuzzy.
• Rendimiento: API-latencia, SLA uptime, modo por lotes para la recuperación.
• Privacidad/cumplimiento: DPIA, ubicación de datos, registros, certificados.
• Funciones: gestión de casos, allow/deny-lists, versioning de fuentes, web hooks.

• Servicio de detección (microservicio) + caché de resultados «calientes».
• Colas para recuperación por lotes (tareas nocturnas).
• Sistema de caso para rugidos manuales, con integración en KYC/KYB/AML.

13) Matriz de soluciones (ejemplo)

14) Anti-patrones

«Sordo» exacto-match sólo por su nombre es una avalancha de FP.
Falta de transliteración/alias - perderse partidos reales.
No hay allow-list con expiración - el comando se hunde en FP repetidos.
Raras revisiones: no se capturan nuevas inclusiones en las listas.
No hay registro de versiones de listas: la solución no se puede proteger cuando se realiza una auditoría.
Informar al cliente sobre el SAR (tipping-off) es una infracción grave.

15) Lista de verificación de implementación

• Fuentes: listas internacionales, regionales y locales + agregador.
• la Normalización de los datos (FIO/daty/adresa/organizatsii/kripto), la transliteración y aliasy.
• Estrategia de partidos: exacto + fuzzy con umbrales personalizables y geocontexto.
• Proceso de rugido: roles, SLA (4h/24h/72h), plantillas de soluciones y comunicaciones.
• Allow/deny-lists con expiración y auditoría.
• Revisión diaria del evento + en demanda; versionar fuentes.
• Integraciones: KYC/KYB/AML, KYT/Travel Rule, Payments Orchestrator (holds/limits).
• Datos/privacidad: cifrado, RBAC, registros, Retench.
• Métricas de calidad y muestreo de QA regular; reducción de FP por experimentos dirigidos.
• Plan de continuidad (proveedor de fallback, degradación de API).

16) Resumen

Un cribado eficaz de las RR/sanciones no es solo «romper las listas». Se trata de datos normalizados, un match exacto + fuzzy flexible, un proceso de rugido guiado con prioridades y SLA, rescribido diario e integración con AML/KYC/KYB/KYT. Dicho circuito minimiza los falsos positivos, captura riesgos reales, protege los raíles de pago y acelera las conclusiones legítimas, lo que significa que mantiene una monetización sostenida.