La mayor parte de las mesas de cumplimiento con las que hablamos coloca a PEP y listas restrictivas como “ya resuelto”. Pregunta un poco más a fondo y descubres lo opuesto: el stack es frágil, la base está desactualizada, el matching tiene falso positivo grosero y la reverificación no existe. Es la etapa donde el regulador mira primero, y donde salen más multas.
Qué está en juego
PEP (Persona Expuesta Políticamente) es alguien que ocupa, ocupó o es cercano a quien ocupa un cargo público relevante. No están prohibidos de tener cuenta, son clientes que exigen monitoreo reforzado porque el riesgo de involucramiento en lavado o corrupción es estadísticamente mayor.
Listas restrictivas (sanciones, terror, narcotráfico, lavado) son clientes o contrapartes a los que tu institución no puede atender, bajo pena de violación directa de la ley y exposición a multas multimillonarias. ONU, OFAC, Unión Europea y órganos locales publican esas listas, y cambian todos los días.
La combinación PEP + sanciones es la verificación mínima de cualquier onboarding en RegTech serio. Y es donde la mayor parte de las instituciones tropieza.
Los cinco problemas reales
1. Base desactualizada
Las listas oficiales son actualizadas por los propios órganos diariamente. Si tu institución corre actualización semanal o mensual, tienes cliente sancionado en la base, y eso, jurídicamente, es tu problema.
Los programas maduros tienen ingestión automática diaria de las fuentes oficiales, con logs de cuándo cada lista fue actualizada y qué versión estaba activa cuando el cliente fue verificado.
2. Matching frágil
El nombre es el peor identificador del mundo: “Juan Pérez” hay millones. Los sistemas que hacen sólo match exacto dejan pasar el 80% de las ocurrencias reales (porque “Juan Perez” sin acento ya escapa). Los sistemas que hacen sólo fuzzy match generan un lago de falsos positivos donde el analista se ahoga.
Un buen matching combina:
- Match exacto con prioridad alta.
- Match fonético (Soundex, Metaphone) para variaciones de grafía.
- Match fuzzy (Levenshtein) con threshold calibrado.
- Match estructurado: nombre + fecha de nacimiento + país de nacionalidad.
- Match transliterado: nombres árabes, rusos, chinos transliterados de forma diferente entre listas.
Y retorna un nivel de confianza, no un sí/no.
3. Falta de reverificación
Un cliente bueno en el onboarding puede volverse PEP en dos meses (fue nombrado para un cargo público). Un cliente puede ser sancionado después de volverse cliente (cambió de régimen, entró en lista nueva). Si sólo verificas en el onboarding, tienes clientes fantasma en la base.
Buenas prácticas:
- Reverificación nocturna de TODA la base contra las listas actualizadas del día.
- Alerta automatizada cuando hay un nuevo match.
- Caso disparado para la mesa de decisión, sin depender de operación manual.
4. Falsos positivos sin gobernanza
La mesa marca el caso como “no es el mismo Juan Pérez”. Excelente. Pero ¿el sistema recuerda esa decisión? Cuando el nombre aparezca de nuevo mañana, ¿va a generar la misma alerta? En programas frágiles, sí, y el analista rehace el trabajo. En programas maduros, las decisiones se vuelven conocimiento institucional: la alerta no dispara para un match ya analizado y descartado.
5. Beneficiarios finales (UBO) ignorados
Verificar sólo al cliente directo es la mitad del trabajo. El cliente es una persona jurídica, pero el socio oculto a través de holding es PEP, y nadie lo vio. Un buen KYB descubre al UBO en cadena hasta el punto de control real, y cada UBO descubierto pasa por la misma verificación de PEP y sanciones.
Cómo tratar a escala
La escala cambia la ecuación. Quien tiene 500 clientes puede resolver a mano. Quien tiene 50.000 o 5 millones necesita arquitectura.
Los bloques esenciales:
- Fuente unificada: las listas llegan por API o feed automatizado, son normalizadas en un schema interno, y el motor de matching consume ese schema. No importa si la fuente cambió de formato, tu mesa no lo siente.
- Matching como servicio: el mismo servicio atiende onboarding, monitoreo continuo, reverificación y consultas ad-hoc. No hay lógica duplicada.
- Workflow de revisión: la alerta cae en fila con prioridad calibrada (PEP de alto cargo, sanción crítica, valor alto), pasa por un analista y la decisión es registrada con motivo.
- Audit trail completo: cada alerta, decisión, lista consultada y versión del motor es registrada con timestamp para auditoría y regulador.
El costo de no hacerlo
Un único cliente sancionado escapando cuesta, en promedio, múltiples veces el presupuesto anual del programa de cumplimiento entre multa, proceso administrativo y daño reputacional. Y el riesgo es binario: no eres castigado por la cantidad de errores, eres castigado por UN error.
No es lugar para economizar.
Conclusión
PEP y sanciones son problema de ingeniería de datos disfrazado de problema de cumplimiento. Quien lo trata de esa forma, con pipeline de ingestión, motor de matching configurable, gobernanza de falso positivo y audit trail, no tiene sorpresas. Quien lo trata como ítem de checklist, sí.
Guardline trata las listas restrictivas como infraestructura crítica. Actualización diaria, matching calibrado, gobernanza de decisión y audit trail por defecto. ¿Quieres ver el motor corriendo contra tu base? Agenda una demo.