Exposición a sanciones y filtrado · Lección 3 de 5
Verificación de nombres y entidades
9 min de lectura
La verificación de nombres es el control de sanciones más antiguo y sigue siendo el primero que suelen evaluar los supervisores. Determina si una persona designada puede abrir una cuenta, recibir un retiro o aparecer como beneficiaria de un mensaje de Travel Rule. Si se realiza mal, inunda a los analistas con alertas sin sentido o deja pasar discretamente el nombre que sí importa; esta lección explica cómo diseñarla, ajustarla y documentarla.
Fuentes y gestión de listas
La gestión de listas es el proceso integral de selección, obtención, carga y mantenimiento de las listas con las que una empresa realiza verificaciones. Parte de la decisión sobre los regímenes descrita en la lección Cómo funcionan las sanciones:
- la Lista Consolidada del Consejo de Seguridad de la ONU, publicada en formato legible por máquina, con un número de referencia permanente para cada entrada;
- las listas de todos los regímenes autónomos que aplica la empresa;
- listas internas: antiguos clientes desvinculados por motivos relacionados con sanciones, sociedades pantalla conocidas y personas o entidades a las que la empresa ha decidido no prestar servicios.
Cada carga de una lista es un evento controlado. La empresa debe registrar la fuente de la lista, la versión o la marca de tiempo de publicación, el momento en que se cargó en el sistema de verificación y la cantidad de entradas añadidas, modificadas y eliminadas. Comparar esas cantidades con el anuncio del propio editor es una comprobación sencilla de integridad. Como el GAFI espera que la congelación se realice sin demora, el tiempo transcurrido entre la publicación de una lista y la nueva verificación de toda la base de clientes debe medirse en horas y comunicarse a la dirección.
Los datos de las listas requieren cuidado. Las entradas pueden incluir varios nombres en distintos sistemas de escritura, fechas de nacimiento parciales y alias de calidad desigual. La lista de la ONU marca algunos alias como de baja calidad, y la Guía de Wolfsberg sobre la verificación de sanciones (2019) describe los alias débiles como nombres amplios o genéricos, por ejemplo, apodos y acrónimos comunes, para los que la verificación «no se espera ni suele resultar productiva». Una decisión documentada de excluir o reducir el peso de los alias débiles es una opción legítima de ajuste; una decisión no documentada constituye una deficiencia.
Qué datos se verifican
| Conjunto de datos | Nombres que suelen verificarse | Cuándo |
|---|---|---|
| Datos de referencia de clientes | Clientes individuales, personas jurídicas, beneficiarios finales, directores, firmantes autorizados | Durante la incorporación, cuando cambia una lista o un dato, y periódicamente |
| Mensajes de Travel Rule | Nombres de ordenantes y beneficiarios recibidos o enviados | Antes de completar o acreditar la transferencia |
| Datos de pagos fiduciarios | Nombres en transferencias bancarias entrantes y salientes, titulares de tarjetas | En tiempo real, antes de autorizar el pago |
| Contrapartes | VASP contraparte, mesas OTC, socios de pago y sus propietarios | Durante la incorporación y cuando haya cambios |
Los beneficiarios finales son tan importantes como los titulares de las cuentas, ya que las reglas de propiedad y control pueden hacer que una entidad esté prohibida aunque su propio nombre no presente alertas. Es fácil olvidar los datos de Travel Rule: el nombre del beneficiario en un mensaje entrante corresponde a una parte con la que opera la empresa y debe verificarse antes de acreditar los fondos (véase la lección Datos y mensajería de Travel Rule).
Preparación de los datos propios de la empresa
La calidad de la verificación depende tanto de los datos de los clientes como de los datos de las listas. Muchos casos no detectados se deben a la forma en que la empresa almacenó el nombre desde el principio. Entre las buenas prácticas para los datos de referencia se incluyen:
- campos separados para los nombres de pila, el apellido y el nombre completo tal como está escrito, en lugar de un único campo de texto libre;
- el nombre en su sistema de escritura original, además de la transliteración latina que aparece en el documento de identidad;
- la fecha de nacimiento completa, la nacionalidad y los números de documentos registrados en campos estructurados, para que puedan compararse automáticamente con los identificadores de las listas;
- para las personas jurídicas, el nombre registrado, los nombres comerciales, los nombres anteriores y el número de registro;
- una regla que exija verificar cada registro antes de activar una cuenta, para que la falta de un campo no permita a un cliente eludir el sistema.
La normalización antes de la comparación elimina ruido que, de otro modo, reduciría las puntuaciones: convertir todo a un mismo uso de mayúsculas y minúsculas, eliminar de manera uniforme la puntuación y los signos diacríticos, estandarizar sufijos jurídicos como «Ltd» y «Limited» y quitar los tratamientos honoríficos. Debe aplicarse la misma normalización a los datos de las listas y a los de los clientes; de lo contrario, la comparación será desigual. Los cambios en las reglas de normalización modifican el control y deben probarse y aprobarse como cualquier cambio de umbral.
Coincidencia aproximada
La coincidencia exacta falla porque los nombres no son cadenas estables. Una misma persona puede registrarse con distintas grafías, órdenes de palabras y sistemas de escritura. La coincidencia aproximada calcula qué tan similares son dos nombres, en lugar de exigir que sean idénticos. Entre las dificultades habituales se incluyen:
- transliteración: los nombres de origen árabe, cirílico, chino, coreano u otros sistemas de escritura pueden representarse con letras latinas de muchas maneras, por lo que el sistema necesita variantes de transliteración o comparación fonética;
- orden y estructura de los nombres: apellido al principio o al final, patronímicos, apellidos compuestos, partículas y tratamientos honoríficos;
- truncamiento e iniciales: nombres acortados por el límite de un campo o registrados mediante iniciales;
- alias: se considera válida una coincidencia con cualquiera de los alias incluidos, pero los alias débiles generan ruido;
- nombres de entidades: sufijos jurídicos, nombres traducidos y abreviaturas.
Los algoritmos combinan medidas de distancia de edición, códigos fonéticos y comparación de tokens para obtener una puntuación. La puntuación por sí sola no debe determinar ninguna decisión. Los identificadores secundarios, como la fecha de nacimiento, la nacionalidad, el lugar de nacimiento, los números de documentos de identidad y los números de registro, permiten distinguir una coincidencia real de una persona con el mismo nombre. En las listas son frecuentes las fechas de nacimiento parciales: una entrada puede mostrar solo un año, un año «aproximado» o varias fechas posibles. Un cliente nacido ese año es compatible con la entrada; uno nacido varias décadas después, no.
Verificación durante la incorporación y reverificación
La verificación durante la incorporación impide que una persona designada empiece a operar. La reverificación mantiene depurada la base de clientes a medida que cambian las listas y los datos. Se necesitan tres factores desencadenantes:
- Cambio en una lista: cada adición o modificación se compara con toda la base de clientes, por lo general mediante un archivo delta, el mismo día.
- Cambio en los datos de un cliente: un nuevo nombre, nacionalidad, domicilio o beneficiario final activa la verificación del registro modificado.
- Reverificación periódica completa: una ejecución completa detecta cualquier elemento que las actualizaciones delta no hayan recogido, como un cambio en las reglas de comparación o una carga fallida.
Una empresa que solo verifica durante la incorporación no detectará a los clientes designados después de su ingreso, uno de los incumplimientos citados con mayor frecuencia en las medidas de ejecución públicas.
Ajuste de umbrales: falsos positivos y falsos negativos
Cada puntuación de coincidencia se compara con un umbral. Un umbral más bajo detecta más variantes y genera más alertas; uno más alto reduce el ruido y aumenta el riesgo de no detectar una coincidencia.
| Resultado | Significado | Costo |
|---|---|---|
| Verdadero positivo | Alerta sobre una parte realmente designada | El control funciona según lo previsto |
| Falso positivo | Alerta sobre una persona con el mismo nombre o no relacionada | Tiempo de los analistas, molestias para el cliente, fatiga por alertas |
| Falso negativo | No se genera una alerta sobre una parte realmente designada | Posible infracción, sanción, daño reputacional |
| Verdadero negativo | No se genera una alerta y no hacía falta | Ninguno |
Como un falso negativo puede constituir una infracción, los umbrales deben establecerse mediante pruebas, no según el volumen de quejas. Una buena práctica consiste en ejecutar un archivo de prueba con nombres sembrados, incluidas variantes de transliteración, nombres reordenados, errores tipográficos y alias de entradas reales de las listas, en la configuración de producción, y medir cuántos detecta el sistema con distintos umbrales. El muestreo por debajo del umbral, en el que los analistas revisan un conjunto aleatorio de pares que casi alcanzaron el umbral, permite saber qué se está dejando pasar. La guía de Wolfsberg espera que el ajuste se realice antes de la implementación y de manera continua, con pruebas independientes respaldadas por métricas.
Resolución de alertas y documentación
Al resolver una alerta, el analista compara los datos del cliente con la entrada de la lista, identificador por identificador, y registra una decisión: falso positivo, posible coincidencia que requiere escalamiento o coincidencia verdadera. Las coincidencias verdaderas y posibles se remiten al responsable de sanciones, y las coincidencias confirmadas activan los pasos de congelación, bloqueo e informe. Un registro podría tener este aspecto:
{
"alert_id": "SAN-2026-004417",
"list_source": "UN Consolidated List",
"list_version": "2026-10-27T18:05Z",
"list_ref": "QDi.xxx",
"customer_id": "C-88213",
"match_score": 0.91,
"matched_field": "alias",
"comparison": {"name": "partial", "dob": "customer 1994 vs listed circa 1961",
"nationality": "different", "document": "no listed number"},
"decision": "false_positive",
"rationale": "Shared surname only; DOB 33 years apart; nationality differs",
"analyst": "A-117", "reviewed_by": "A-042",
"closed_at": "2026-10-28T09:14Z"
}El registro indica la versión de la lista para que un auditor pueda reproducir lo que vio el sistema; compara cada identificador en lugar de limitarse a decir «no es la misma persona»; y muestra que hubo un segundo revisor, requisito de muchas empresas para las coincidencias verdaderas y para una muestra de falsos positivos. La referencia de la lista aparece truncada porque se trata de un ejemplo ficticio.
Los falsos positivos recurrentes para un mismo cliente pueden suprimirse mediante una entrada en una lista de clientes exentos, pero solo para ese par cliente-entrada, con un motivo, una persona aprobadora y una fecha de vencimiento o revisión. Si cambia la entrada de la lista, la supresión debe caducar automáticamente.
Enfoque del examen: gestión de listas y documentación de cada carga (fuente, versión, marcas de tiempo y cantidades); reverificación de toda la base dentro de las horas siguientes a un cambio en una lista; qué datos verificar, incluidos los beneficiarios finales y los nombres de ordenantes y beneficiarios de Travel Rule; problemas de coincidencia aproximada (transliteración, orden de los nombres, alias y alias débiles) y función de los identificadores secundarios, incluidas las fechas de nacimiento parciales; los tres factores que activan la reverificación; falsos positivos frente a falsos negativos y ajuste mediante archivos de prueba con nombres sembrados y muestreo por debajo del umbral; contenido de un registro de alerta completo; control de las listas de clientes exentos.