Screening contra Sanciones Internacionales

Verificación manual, riesgo máximo

El proceso de screening de sanciones era enteramente manual. Un analista de compliance debía ingresar el nombre de cada persona o entidad en múltiples portales web —el buscador de OFAC, el consolidado de la ONU, el registro de la UE, la lista de sanciones del Reino Unido— y comparar visualmente los resultados. Para una sola persona, este proceso tomaba entre 30 y 45 minutos, considerando las variaciones de nombre, alias y transliteraciones.

El riesgo regulatorio era crítico. Una verificación incompleta o un falso negativo podía resultar en multas de millones de dólares por parte de la OFAC, bloqueo de operaciones internacionales, o incluso responsabilidad penal para los oficiales de compliance. Las listas de sanciones cambian constantemente —la OFAC actualiza su SDN List varias veces por semana— y el equipo no tenía forma de garantizar que trabajaba con la versión más reciente.

Los nombres internacionales agravaban el problema. Un nombre en árabe transliterado al inglés puede escribirse de 5 o más formas distintas. «Mohammed» aparece como «Muhammad», «Mohamed», «Mohamad». Los nombres rusos transliterados varían entre «Ivanov» e «Ivanoff». Una búsqueda exacta por texto simplemente no funciona en este contexto, y cada variante no detectada es un riesgo regulatorio real.

• 30-45 minutos por verificación individual, con consultas a múltiples portales web
• Sin trazabilidad auditable: imposible demostrar a un regulador qué se verificó y cuándo
• Listas desactualizadas: sin sincronización automática con las fuentes oficiales
• Falsos negativos por coincidencia exacta: variantes de nombre, alias y transliteraciones pasaban inadvertidas
• Imposible escalar: verificar un batch de 500 clientes tomaba semanas de trabajo manual

Motor de matching inteligente

Diseñamos y construimos una plataforma de screening automatizado que consolida 7 listas de sanciones internacionales en una sola base de datos normalizada, actualizada diariamente desde las fuentes oficiales. El corazón del sistema es un motor de matching multi-algoritmo que combina múltiples técnicas de comparación difusa para maximizar la detección sin generar un volumen inmanejable de falsos positivos.

El motor ejecuta cada consulta a través de tres algoritmos en paralelo: distancia de Levenshtein para detectar errores tipográficos y variaciones menores, Jaro-Winkler para capturar similitudes en prefijos comunes de nombres, y token set ratio para manejar reordenamientos de palabras y nombres compuestos. Los scores de cada algoritmo se ponderan y combinan con bonificadores contextuales —fecha de nacimiento, número de pasaporte, nacionalidad, tipo de documento— para producir un score final de coincidencia entre 0 y 100.

Un score por encima de 85 se marca como hit automático; entre 60 y 85, como revisión manual; y por debajo de 60, como descartado. Estos umbrales son configurables por cliente según su apetito de riesgo regulatorio.

• 7 listas internacionales: OFAC (SDN, Consolidated), ONU, UE, UK (OFSI), Argentina (UIF), México (SAT)
• Motor multi-algoritmo: Levenshtein + Jaro-Winkler + token set ratio con ponderación configurable
• Bonificadores contextuales: DOB, pasaporte, nacionalidad, tipo de entidad (persona, organización, embarcación)
• Procesamiento batch vía SQS FIFO para verificaciones masivas de hasta 10.000 entidades
• Circuit breakers por fuente de datos: si OFAC no responde, las demás listas continúan sin interrupción
• Auditoría completa: cada consulta registra timestamp, usuario, score, algoritmo utilizado y resultado
• Multi-tenant con aislamiento lógico de datos por cliente mediante row-level security en PostgreSQL

Por qué la coincidencia exacta no funciona

El matching exacto de texto falla sistemáticamente con nombres internacionales. Las listas de sanciones contienen entidades de más de 80 países, con nombres en alfabetos árabe, cirílico, chino y otros que deben transliterarse al latín. Cada transliteración introduce variantes legítimas que un sistema basado en igualdad de strings no detecta.

La distancia de Levenshtein mide cuántas operaciones de edición (inserción, eliminación, sustitución) se necesitan para transformar un string en otro. Es eficaz para errores tipográficos y variaciones menores, pero penaliza excesivamente las diferencias de longitud. «Al-Rahman» vs «Alrahman» produce una distancia baja, pero «Mohammed bin Salman Al Saud» vs «M. Salman» genera una distancia alta que no refleja la relación real.

Jaro-Winkler compensa esta limitación al dar mayor peso a las coincidencias en los primeros caracteres del string, lo que es particularmente útil para nombres propios donde el apellido o nombre de pila suele coincidir al inicio. El token set ratio, por su parte, tokeniza ambos strings, los ordena alfabéticamente, y compara los conjuntos de tokens independientemente de su orden original. Esto resuelve casos como «Kim Jong-un» vs «Jong-un Kim» o «Banco Nacional de Cuba» vs «Cuba Banco Nacional».

La combinación de los tres algoritmos, ponderada por tipo de entidad, produce una tasa de detección superior al 97% en nuestras pruebas contra datasets de referencia, con una tasa de falsos positivos inferior al 3% —un orden de magnitud mejor que los sistemas de matching exacto, que típicamente muestran tasas de falsos negativos del 15-25% con nombres internacionales.

SQS FIFO y circuit breakers

Las operaciones de compliance a menudo requieren verificaciones masivas: onboarding de carteras completas, auditorías periódicas, o screenings regulatorios trimestrales. Un cliente puede necesitar verificar 5.000 a 10.000 entidades en un solo batch. Enviar todas estas consultas de forma síncrona saturaría el sistema y generaría timeouts.

Implementamos una arquitectura de colas basada en Amazon SQS FIFO que garantiza el orden de procesamiento y la entrega exactamente una vez (exactly-once delivery). Cada batch se divide en chunks de 50 entidades, se encola con un deduplication ID único, y se procesa por workers Lambda concurrentes. Un orchestrator monitorea el progreso y notifica al usuario cuando el batch completo está listo, con un reporte descargable en CSV o PDF.

Cada fuente de datos externa (OFAC API, ONU XML feed, UE consolidated list) está protegida por un circuit breaker independiente con tres estados: closed (operación normal), open (fuente caída, se usa caché local) y half-open (pruebas periódicas de recuperación). Si la API de OFAC sufre una interrupción, el sistema continúa verificando contra las otras 6 listas sin degradar la experiencia del usuario, y marca los resultados de OFAC como «pendiente de verificación» hasta que la fuente se recupere.

• SQS FIFO con exactly-once delivery y deduplication automática
• Chunks de 50 entidades procesados por Lambda workers concurrentes
• Circuit breakers por fuente con estados closed/open/half-open
• Caché local de listas para operación degradada cuando una fuente cae
• Reportes de batch en CSV y PDF con trazabilidad por entidad
• Dead letter queue para reintentos automáticos de verificaciones fallidas

Aislamiento de datos por cliente

La plataforma opera como servicio multi-tenant, donde cada organización cliente accede a su propio espacio aislado con configuraciones independientes. El aislamiento se implementa a nivel de base de datos mediante row-level security (RLS) en Aurora PostgreSQL, lo que garantiza que las consultas de un cliente jamás puedan acceder a datos de otro, incluso en caso de un bug en la capa de aplicación.

Cada tenant puede configurar sus propios umbrales de matching (conservador, estándar, agresivo), seleccionar qué listas de sanciones son relevantes para su jurisdicción, y definir flujos de aprobación personalizados para resultados en zona gris. La autenticación se gestiona vía AWS Cognito con soporte para SSO corporativo (SAML 2.0), y cada acción queda registrada en un log de auditoría inmutable para cumplir con requisitos regulatorios de trazabilidad.

La plataforma también soporta múltiples tipos de entidad más allá de personas naturales: personas jurídicas, embarcaciones, aeronaves, y direcciones. Cada tipo tiene su propio conjunto de bonificadores y reglas de matching optimizadas para las características específicas de esa categoría.

De horas a segundos

El impacto fue inmediato y medible. Las verificaciones individuales que antes tomaban 30-45 minutos ahora se completan en menos de 2 segundos. Un batch de 5.000 entidades que antes requería semanas de trabajo manual ahora se procesa en menos de 15 minutos. La tasa de detección subió al 97.4%, mientras que los falsos positivos bajaron al 2.8%, eliminando la mayoría de las revisiones manuales innecesarias.

Cada verificación queda registrada con trazabilidad completa: qué analista la inició, qué listas se consultaron, qué algoritmos se usaron, cuál fue el score, y qué decisión se tomó. Los auditores externos pueden generar reportes de cumplimiento en un clic, en lugar de reconstruir manualmente la evidencia de cada verificación.

Tecnologías utilizadas