Los mejores software de control de sanciones: 8 criterios

Última actualización: octubre de 2026

El mejor software de detección de sanciones para una institución financiera es aquel cuya coincidencia la institución puede ver, ajustar y defender. Analiza cada parte y cada campo de pago que la institución debe revisar, tan pronto como cambia una lista, encuentra entidades bloqueadas por propiedad y deja un registro de por qué se autorizó cada coincidencia. La OFAC no elegirá la herramienta, no establecerá el umbral ni confirmará una coincidencia, por lo que la única forma confiable de comparar productos es probarlos con sus propios clientes y pagos. Lea primero las coincidencias verdaderas omitidas y cuente los falsos positivos evitados solo después de eso.

Esta guía establece ocho criterios para elegir un software de detección de sanciones. Cada criterio cubre qué es, qué preguntar a un proveedor, cómo suena una respuesta débil y cómo probarlo con sus propios datos, y una tabla de puntuación al final recopila los ocho.

TL;DR (Resumen)

• Ningún software de detección de sanciones es el mejor para todas las instituciones. La OFAC señala que el tamaño y las necesidades de cada institución determinan qué buscar, y no recomienda un umbral de coincidencia.

• Evalúe las herramientas de detección según ocho criterios: cobertura de listas y velocidad de actualización, coincidencia de nombres que pueda ver y ajustar, propiedad bajo la Regla del 50 por ciento, clientes y pagos, cómo se descartan los falsos positivos, umbrales de su propiedad, calidad de coincidencia con sus propios datos y un registro que un examinador pueda seguir.

• Los datos de las listas y el motor de coincidencia son compras independientes. Evalúe cada uno por separado.

• Pruebe cada candidato con su propio historial etiquetado antes de firmar. El límite para las coincidencias verdaderas omitidas es cero; los falsos positivos eliminados es el segundo número, no el primero.

• La norma de mantenimiento de registros de la OFAC ahora exige que los registros estén disponibles durante al menos 10 años, un cambio que entró en vigor en marzo de 2025.

• Oscilar escribió esta guía. Los criterios no mencionan ningún producto, y una sección posterior aplica los mismos criterios a Oscilar, incluidos aquellos que Oscilar no responde por sí mismo.

La respuesta corta: cómo elegir un software de detección de sanciones

Elija el software de detección de sanciones que se adapte al perfil de riesgo de su institución, le muestre cómo asocia los nombres, analice a los clientes y pagos con cada lista que necesite tan pronto como esas listas cambien, gestione la propiedad y registre por qué se autorizó cada coincidencia. Luego, pruébelo con sus propios datos. No existe una única herramienta óptima entre las soluciones de detección de sanciones, porque la OFAC deja la elección a la institución: su FAQ 31 dice "El tamaño y las necesidades de cada institución ayudan a determinar qué buscar en un paquete".

La OFAC también deja claro que las decisiones dentro de la herramienta pertenecen a la institución. Sobre las puntuaciones de umbral, la FAQ 250 de la OFAC dice que los usuarios "deben tomar sus propias determinaciones de umbral de coincidencia en función de sus propias evaluaciones de riesgo internas y prácticas de cumplimiento establecidas". Sobre las coincidencias individuales, la FAQ 5 dice "La OFAC no confirma posibles coincidencias o falsos positivos en nuestras listas de sanciones y, en su lugar, alienta a las organizaciones a tomar determinaciones basadas en el riesgo de acuerdo con la guía anterior".

Un gerente de sanciones de una fintech de pagos resumió el trabajo del comprador en una línea: "la detección de sanciones consiste en encontrar lo que busco. Entonces, ¿cómo defino mejor lo que busco?". El software encuentra; la institución define lo que busca, establece qué tan exacta debe ser la coincidencia de un nombre y decide cada alerta.

Por eso la prueba importa más que la lista de funciones. El director de detección de un gran banco describió cómo leerían los resultados de un proveedor con sus propios datos: "¿hay alguna pérdida en las coincidencias verdaderas? No, genial. Entonces, ¿de cuántos falsos positivos pudiste... deshacerte?". Las coincidencias verdaderas omitidas van primero, porque una coincidencia verdadera omitida es una posible violación de sanciones y un falso positivo es tiempo del analista.

Haga a cada proveedor las mismas preguntas por escrito y realice cada prueba con sus propios clientes y pagos en lugar de con datos de demostración. Oscilar escribió esta guía; los criterios no mencionan productos y la sección siguiente evalúa a Oscilar con esos mismos criterios.

Qué hace el software de detección de sanciones

El software de detección de sanciones compara los nombres en los registros de clientes y pagos con las listas de sanciones, genera una alerta cuando un nombre se parece lo suficiente a uno de la lista y pone esa alerta frente a una persona que decide si es una coincidencia verdadera. Las herramientas de detección de sanciones, el software de detección de listas de vigilancia, el software de detección de nombres y el software de detección de la OFAC son nombres para el mismo trabajo, aplicado a clientes (detección de nombres en la incorporación y redetección) y a pagos (detección de pagos, a veces llamada detección de transacciones). En el Marco para los Compromisos de Cumplimiento de la OFAC de 2019, la herramienta es un control interno dentro de un programa con cinco componentes: "(1) compromiso de la dirección; (2) evaluación de riesgos; (3) controles internos; (4) pruebas y auditorías; y (5) capacitación".

La propia herramienta gratuita de búsqueda de listas de sanciones de la OFAC ya aplica lógica difusa a los nombres, combinando coincidencia de cadenas y fonética, por lo que lo que compra una institución es la cobertura de toda su cartera y de cada pago, una coincidencia que puede ajustar y defender, y un registro de cada decisión. El monitoreo de transacciones es un trabajo diferente con sus propios criterios de compra; consulte nuestra guía para elegir software de monitoreo de transacciones. Elegir un software de AML en su conjunto, del cual la detección de sanciones es una parte, es una evaluación más amplia con sus propios criterios.

1. Cobertura de listas y velocidad de actualización

Qué es: La cobertura de listas se refiere a qué listas de sanciones analiza el software, incluida la Lista SDN, otras listas de la OFAC, cualquier otra lista que requiera su evaluación de riesgos y sus propias listas de vigilancia internas. La velocidad de actualización es qué tan rápido llega una nueva designación a la detección que se ejecuta en producción. El Marco de la OFAC menciona esto como una causa fundamental de fallas de cumplimiento, bajo "Fallas en el filtro o software de detección de sanciones": las organizaciones "no actualizaron su software de detección de sanciones para incorporar las actualizaciones de la Lista SDN o la Lista SSI".

Los datos de las listas y el motor de coincidencia son compras independientes, y muchas instituciones ahora los compran por separado. Un arquitecto principal de sistemas de delitos financieros de un gran banco describió el plan: "nuestros feeds de listas... probablemente serán de uno de los proveedores más grandes... pero nuestra [herramienta] que realmente hace la detección es lo que estamos pensando en reemplazar. Y no queremos que estén estrechamente vinculados". Una herramienta que solo funciona con sus propios datos de listas toma ambas decisiones por usted.

Las listas internas necesitan el mismo alcance que las oficiales. Un líder de sanciones de la OFAC en un banco regional describió una herramienta que podía analizar la propia lista de vigilancia interna del banco con los clientes, pero no con las transferencias en vivo, por lo que la lista interna se detenía en la incorporación.

Qué preguntar a un proveedor:

• ¿Con qué listas realizan la detección y podemos agregar nuestras propias listas internas y analizarlas tanto con clientes como con pagos?

• ¿Podemos usar los datos de listas para los que ya tenemos licencia y cambiar de proveedor de listas más adelante sin reemplazar la herramienta de detección?

• Cuando la OFAC agrega una designación, ¿cuánto tiempo pasa hasta que está activa en la detección en producción y quién activa la actualización?

• ¿Cómo demostramos a un examinador qué versión de la lista estaba activa en cualquier momento?

Un vicepresidente senior de operaciones de FIU en un banco comunitario hizo esa última pregunta directamente: "¿Cómo mostramos a los examinadores o auditores cuándo se actualizó la lista con marcas de tiempo, fechas, cosas así? ¿Tenemos esa funcionalidad?".

Cómo suena una respuesta débil: Una garantía de que las listas se actualizarán todas las noches, sin una marca de tiempo de cuándo se activó cada versión de la lista. Una función de lista interna que solo cubre a los clientes es otra señal de advertencia.

Cómo probarlo con sus propios datos: Tome una designación reciente, vuelva a pasar su archivo de clientes y un día de pagos con la versión de la lista de antes y después de esa designación, y verifique cuándo habría generado el software una alerta por primera vez. Luego pida el registro que demuestre qué versión de la lista estaba activa en cada momento.

2. Coincidencia de nombres que pueda ver y ajustar

Qué es: La coincidencia de nombres es cómo el software decide que un nombre en un registro o un pago es lo suficientemente cercano a un nombre de la lista para generar una alerta. Los métodos incluyen coincidencia difusa y fonética, comparación de partes de nombres, transliteración, ortografías alternativas y alias. El mismo líder de sanciones de la OFAC en un banco regional lo expresó claramente: "Sé que lo difuso se está quedando obsoleto, pero todavía se necesita lo difuso".

Cómo se comparan los nombres importa tanto como si se comparan. Tratar un nombre completo como una sola cadena de texto pasa por alto casos que la comparación de nombres y apellidos por separado detectaría, en ambas direcciones. El Marco de la OFAC incluye el no "considerar las ortografías alternativas de países o partes prohibidas" entre las fallas de detección, con ejemplos como Habana para Havana y Soudan para Sudan.

Algunas opciones son explícitamente decisión de la institución. La FAQ 5 de la OFAC dice: "La OFAC puede clasificar algunos alias de la lista como 'alias débiles', y su herramienta de detección puede excluir estos alias como parte de una decisión basada en el riesgo". El Manual de Examen BSA/AML de la FFIEC dice: "el banco debe definir claramente sus criterios para comparar los nombres provistos en la lista de la OFAC con los nombres en los archivos del banco o en las transacciones". Una configuración que importa tanto tiene que ser visible y estar documentada, no oculta en los valores predeterminados del proveedor.

La coincidencia también necesita contexto más allá de la similitud de cadenas. El mismo director de detección de un gran banco preguntó sobre una alerta: "¿por qué habría una embarcación en un campo de nombre?". Un director de cumplimiento y riesgos de una empresa de pagos transfronterizos trazó la misma línea entre la lista y la coincidencia: "no son solo datos. Es la lógica que construyeron para evaluar estos datos".

Qué preguntar a un proveedor:

• ¿Qué métodos de coincidencia utilizan, en qué campos y podemos ver qué método produjo cada alerta?

• ¿Cómo manejan el orden de los nombres, las partes de los nombres, la transliteración y los alias, y podemos elegir si se analizan los alias débiles?

• ¿Puede nuestro equipo cambiar la configuración de coincidencia y se registra cada cambio con quién lo hizo y por qué?

• ¿Qué contexto más allá del nombre, como el campo en el que apareció el nombre o una fecha de nacimiento, utilizan para separar las alertas?

Cómo suena una respuesta débil: Una puntuación de coincidencia patentada que nadie en el proveedor puede explicar a un examinador, o configuraciones de coincidencia que solo el proveedor puede cambiar.

Cómo probarlo con sus propios datos: Cree un conjunto de variantes de designaciones recientes que incluyan nombres reordenados, transliteraciones, partes de nombres omitidas y alias, e introdúzcalos en una copia de su archivo de clientes y datos de pago. Verifique qué variantes detecta cada candidato y si puede mostrar por qué.

3. Propiedad y la Regla del 50 por ciento

Qué es: Según la guía de la OFAC de 2014 sobre entidades propiedad de personas bloqueadas, "cualquier entidad de la que una o más personas bloqueadas posean, en conjunto, directa o indirectamente, el 50 por ciento o más de participación se considera en sí misma una persona bloqueada". Los bienes de dicha entidad están bloqueados "independientemente de si la entidad misma figura en la lista". Un análisis de nombres por sí solo no puede encontrarla, porque el nombre de la entidad no está en ninguna lista.

La propiedad se calcula de forma agregada. La FAQ 399 de la OFAC ofrece el siguiente ejemplo: "si la Persona Bloqueada X posee el 25 por ciento de la Entidad A y la Persona Bloqueada Y posee otro 25 por ciento de la Entidad A, se considera que la Entidad A está bloqueada". Añade que "se acumulan las participaciones de propiedad de personas bloqueadas bajo diferentes programas de sanciones de la OFAC". Por debajo del umbral, la guía de 2014 sigue aconsejando a las personas de EE. UU. "actuar con cautela al considerar una transacción con una entidad no bloqueada en la que una o más personas bloqueadas tengan una participación de propiedad significativa inferior al 50 por ciento".

Los datos de beneficiario final que una institución recopila para la debida diligencia del cliente responden a una pregunta diferente. La norma de CDD de FinCEN (31 CFR 1010.230) identifica a cada individuo que "posee el 25 por ciento o más de las participaciones de capital" de un cliente que sea persona jurídica, más un individuo con control significativo. La prueba de la OFAC suma las participaciones de las personas bloqueadas, por pequeñas que sean, de modo que los datos de CDD por sí mismos no responden a la pregunta de la Regla del 50 por ciento.

La propiedad también tiene capas. Un subdirector que gestiona KYC y sanciones en un banco comunitario preguntó si se podía analizar la propiedad en cada capa durante la incorporación (por ejemplo, una empresa propiedad de otra empresa que a su vez es propiedad de personas físicas) y si las capas intermedias se volverían a analizar más adelante.

Qué preguntar a un proveedor:

• ¿Analizan a los propietarios de una entidad en cada capa de propiedad y agregan las participaciones de personas bloqueadas en todos los programas de sanciones?

• ¿De dónde provienen los datos de propiedad y se trata de una compra independiente?

• Cuando se designa a un propietario después de la incorporación, ¿la entidad genera una alerta en la siguiente revisión?

Cómo suena una respuesta débil: Una oferta para analizar los beneficiarios finales que usted proporcione. Eso analiza a los propietarios de CDD por nombre y deja la cuestión de la agregación sin responder.

Cómo probarlo con sus propios datos: Tome una muestra de sus clientes corporativos con propiedad en capas, agregue una designación hipotética de un propietario en cada capa y verifique si el software marca a la entidad y cómo muestra la ruta de propiedad que produjo la alerta.

4. Clientes y pagos, no uno u otro

Qué es: El análisis de sanciones cubre dos flujos diferentes. El análisis de clientes verifica los nombres durante la incorporación y nuevamente cada vez que cambia una lista; el análisis de pagos verifica a cada parte y campo en un pago antes de que se mueva. El mismo gerente de sanciones de una fintech de pagos describió por qué es importante volver a analizar: "hemos incorporado a alguien, ya es un cliente existente, salen nuevas sanciones. Ahora están designados y ahora debemos tomar las medidas adecuadas".

El análisis de pagos debe cubrir todo el mensaje, no solo los campos que el proveedor elija. El mismo líder de sanciones de la OFAC en un banco regional dijo: "No me importa dónde esté Irán en un pago. Se analiza todo ese... pago en busca de Irán". El Marco de la OFAC incluye el no "incluir identificadores pertinentes como los Códigos de Identificación Comercial de SWIFT (BIC)" entre las fallas de detección.

El análisis de pagos también funciona a contrarreloj. El mismo director de detección de un gran banco describió la cadena: un cliente llama para preguntar por qué un pago sigue retenido, el negocio presiona a operaciones y operaciones culpa a sanciones. La guía de la OFAC de 2022 sobre sistemas de pago instantáneo dice que "la velocidad que requiere esta función comercial no debe desalentar a las instituciones financieras de implementar controles de cumplimiento de sanciones basados en el riesgo", y que la OFAC "alienta el uso de tales herramientas y otras tecnologías y soluciones emergentes para gestionar los riesgos de sanciones que podrían surgir en el contexto de los pagos instantáneos" cuando sea apropiado según el riesgo.

Qué preguntar a un proveedor:

• ¿Analizan a los clientes durante la incorporación, vuelven a analizar toda la cartera cuando cambia una lista y revisan los pagos en tiempo real y por lotes?

• ¿Qué campos de cada formato de mensaje de pago analizan, incluido el texto libre y los identificadores como los BIC de SWIFT?

• ¿Nuestras listas internas se aplican tanto a los pagos como a los clientes?

• ¿Cuánto tiempo espera un pago mientras se revisa una coincidencia y qué ve el revisor?

Cómo suena una respuesta débil: Listas internas que se aplican solo a clientes, análisis de pagos limitado a campos designados o revisiones que se ejecutan en un calendario fijo en lugar de cuando cambia una lista.

Cómo probarlo con sus propios datos: Pase una muestra de sus propios mensajes de pago por cada candidato con un nombre de la lista introducido en un campo de texto libre, y ejecute un cambio de lista en su archivo de clientes para ver qué clientes existentes se volverían a analizar y cuándo.

5. Cómo se descartan los falsos positivos

Qué es: La mayoría de las alertas no son coincidencias verdaderas. La FAQ 5 de la OFAC dice: "Muchas de las posibles coincidencias identificadas mediante la detección son falsos positivos". La FAQ, actualizada el 9 de septiembre de 2026, establece seis pasos para revisar una posible coincidencia: determinar si la alerta coincide con una lista de la OFAC; determinar con qué coincide potencialmente; evaluar la calidad de la coincidencia; determinar los siguientes pasos para una coincidencia válida; determinar si se debe bloquear o rechazar; y reportar las coincidencias válidas a la OFAC y mantener registros.

El paso de la calidad es donde el software marca la mayor diferencia para un revisor. La FAQ 5 dice: "Para verificar o descartar una posible coincidencia, compare todos los detalles de la lista de la OFAC con la información de la que dispone sobre los datos de su transacción o actividad que dieron lugar a la 'alerta' o 'coincidencia'". Esos detalles incluyen "nombres completos, nombres anteriores, alias conocidos, nacionalidades, pasaporte, identificación fiscal, números de identificación nacional, lugar de nacimiento, fecha de nacimiento, números de registro comercial o direcciones conocidas". Un buen software coloca esos identificadores uno al lado del otro frente al revisor, mostrando cuáles coincidieron, cuáles no y cuáles faltaban.

El volumen de alertas falsas es en sí mismo una señal para los exámenes. La sección de la OFAC del manual de la FFIEC dice: "Un alto volumen de alertas falsas puede indicar la necesidad de revisar el programa de interdicción del banco".

Cómo se gestiona una alerta descartada hacia el futuro importa tanto como cómo se resolvió. El mismo líder de sanciones de la OFAC en un banco regional describió la función de supresión de una herramienta: "Básicamente escribe una regla de reducción de falsos positivos. Sin embargo, no me gustan los parámetros de esa regla. Se hace una vez y ya está". Una supresión sin fecha de vencimiento y sin un nuevo análisis cuando cambia la entrada de la lista puede ocultar una coincidencia que debería volver a aparecer.

Si alguna coincidencia se descarta automáticamente, alguien debe poder verificarla. Un especialista senior en AML de una fintech de pagos transfronterizos preguntó: "¿Tenemos la capacidad de revisar aquellas que la IA ha decidido cerrar?". La forma en que los agentes de IA pueden preparar esa revisión para un analista se detalla en nuestra guía sobre cómo los agentes de IA revisan las alertas de sanciones.

Qué preguntar a un proveedor:

• Para una coincidencia, muéstrenos los identificadores comparados, cuáles coincidieron, cuáles no y cuáles faltaban, así como la entrada de la lista y el alias que la produjeron.

• ¿Cómo se gestiona hacia el futuro una coincidencia descartada? ¿Expira y se vuelve a analizar cuando cambia la entrada de la lista?

• ¿Qué se puede descartar sin la intervención de una persona, quién lo configura y cómo tomamos muestras y lo revisamos?

Cómo suena una respuesta débil: Una lista de nombres descartados o una regla de supresión que se configura una vez y nunca se vuelve a revisar, o un descarte automático sin registro de lo que se comparó.

Cómo probarlo con sus propios datos: Tome una muestra de alertas que su equipo ya haya descartado, páselas por cada candidato y compare la evidencia que presenta el software con la que sus analistas necesitaron para decidir. Luego, cambie una entrada de la lista detrás de una alerta suprimida y verifique que la alerta regrese.

6. Umbrales de su propiedad y quién puede cambiarlos

Qué es: El umbral de coincidencia es qué tan cercano debe estar un nombre a uno de la lista antes de que el software genere una alerta. Ningún regulador establece uno. Al preguntarle si recomienda una puntuación de umbral de coincidencia específica para su propia herramienta de búsqueda de listas de sanciones, la OFAC respondió en la FAQ 250: "La OFAC no puede hacer tal recomendación porque cada búsqueda tiene su propio conjunto único de hechos que la rodean". El manual de la FFIEC dice: "Las decisiones de utilizar software de interdicción y el grado de sensibilidad de ese software deben basarse en la evaluación que haga el banco de su riesgo y del volumen de sus transacciones".

Eso deja el umbral, y su explicación, en manos de la institución. El mismo director de detección de un gran banco describió lo que esperan los examinadores: "Mis reguladores... esperan que esté en mi propia casa y que yo sea el dueño. Que yo lo ajuste, que escriba las reglas en él, que sea capaz de explicar cada una de las formas en que funciona".

Subir un umbral no es una forma gratuita de reducir los falsos positivos. Un umbral más alto reduce las alertas y la cobertura al mismo tiempo, mientras que un mejor contexto, como fechas de nacimiento, direcciones y el campo en el que apareció el nombre, reduce las alertas manteniendo la cobertura. Cuando cambie un umbral, tome una muestra de la actividad justo por encima de la nueva línea para verificar que valga la pena revisar las alertas restantes, y justo por debajo para verificar que no haya desaparecido nada que debería haber alertado. La muestra por debajo de la línea es lo que demuestra a un examinador que la cobertura se mantuvo.

Qué preguntar a un proveedor:

• ¿Quién puede cambiar los umbrales y la configuración de coincidencia, y se registra cada cambio en una versión con el motivo documentado?

• ¿Podemos probar un cambio de umbral en nuestros propios datos históricos antes de que se active en producción?

• ¿Podemos establecer diferentes umbrales por lista, por segmento de clientes o por tipo de pago?

Cómo suena una respuesta débil: Una afirmación de que el umbral predeterminado del proveedor se adapta a la mayoría de los bancos. Un umbral que solo el proveedor puede cambiar, o que no se puede probar antes de activarse, es otra señal de advertencia.

Cómo probarlo con sus propios datos: Ejecute su propio historial con el umbral actual y con el propuesto, y analice las alertas que desaparecen antes de celebrar la reducción del volumen.

7. Calidad de coincidencia probada con sus propios datos

Qué es: La calidad de coincidencia es qué tan bien encuentra el software las coincidencias verdaderas y evita las falsas con sus clientes y pagos reales, no con un conjunto de demostración. El Marco de la OFAC espera que las instituciones hayan "seleccionado y calibrado las soluciones de una manera que sea apropiada para abordar el perfil de riesgo y las necesidades de cumplimiento de la organización, y que la organización pruebe rutinariamente las soluciones para garantizar su eficacia".

El diseño de prueba más sólido es el que ya utilizan los compradores. El mismo director de detección de un gran banco diseñó una competencia de proveedores como un período de datos de alerta etiquetados de los que el proveedor pudiera aprender, seguido de un período de datos no etiquetados, para luego verificar los resultados del proveedor contra las propias etiquetas del banco. El mismo director de cumplimiento y riesgos de una empresa de pagos transfronterizos planeaba probar a un proveedor en una gran muestra de sus propios registros antes de firmar, porque sin confianza en el sistema, en cualquier sistema, no tiene sentido firmar.

Lea los resultados como dos números, y léalos en orden. El primero son las omisiones críticas: coincidencias verdaderas que el software habría omitido o descartado, y el límite para estas es cero. El segundo son los falsos positivos que eliminó, lo que muestra cuánto tiempo de revisión puede ahorrar. Luego lea las discrepancias una por una, porque algunas son errores de software, otras son datos que su analista tenía pero que no aparecían en la alerta, y otras son prácticas que nadie dejó por escrito.

Los nombres de control sirven como un primer filtro sencillo. Un arquitecto principal de sistemas de delitos financieros de un gran banco describió la prueba de si el sistema de un proveedor detecta nombres de control exactos de una lista importante bajo un umbral estricto, llamándolo "como un filtro de pasa o no pasa para seleccionar a un proveedor". Los examinadores utilizan el mismo método: los procedimientos de examen del manual de la FFIEC dicen "Si hay alguna duda sobre la eficacia del filtro de la OFAC, realice pruebas del sistema introduciendo nombres de cuentas de prueba que sean iguales o similares a los añadidos recientemente a la lista de la OFAC".

Qué preguntar a un proveedor:

• ¿Podemos ejecutar su software en nuestro propio historial etiquetado antes de firmar, y luego en datos no vistos verificados contra nuestras etiquetas?

• ¿Reportarán las omisiones críticas por separado de los falsos positivos eliminados?

• ¿Podemos mantener un entorno de prueba después de la puesta en marcha, de modo que cada cambio de umbral o de lista se pueda probar antes de llegar a producción?

Cómo suena una respuesta débil: Una garantía de que no necesitará un entorno de prueba. El mismo líder de sanciones de la OFAC en un banco regional describió a un proveedor que decía que el banco no necesitaría una plataforma de prueba, y el banco descubrió que sí la necesitaba, porque un entorno paralelo en el que no se pueden realizar pruebas reales no es un entorno de prueba.

Cómo probarlo con sus propios datos: Realice una prueba retrospectiva (backtesting) con el historial etiquetado, luego ejecútelo en modo espejo (shadow) con el tráfico en vivo junto con su herramienta actual y compare ambas con los mismos clientes y pagos. Incluya nombres de control y variantes de designaciones recientes en ambas ejecuciones.

8. Un registro que un examinador pueda seguir

Qué es: El registro es lo que el software conserva sobre cada alerta y cada decisión, y es lo que solicita la OFAC. La FAQ 5 de la OFAC dice: "Las organizaciones deben mantener registros completos y precisos que detallen las medidas adoptadas para investigar la posible coincidencia y la información en la que se basaron para determinar en última instancia si la posible coincidencia era válida". Según la norma 31 CFR 501.601, los registros deben estar "disponibles para su examen durante al menos 10 años después de la fecha de dicha transacción"; el cambio de cinco a 10 años se publicó el 13 de septiembre de 2024 y entró en vigor el 12 de marzo de 2025. Los bienes bloqueados y las transacciones rechazadas también deben reportarse a la OFAC en un plazo de 10 días hábiles (31 CFR 501.603 y 501.604), y el registro debe respaldar esos reportes.

Los hallazgos de auditoría suelen tener que ver con la justificación, no solo con la detección. Un oficial que supervisa las sanciones, la incorporación y el control de calidad en un banco comunitario dijo: "los hallazgos que solemos ver en el frente de las sanciones son que los usuarios suelen olvidar completar la detección de sanciones... o, si la realizaron, la descartan con una justificación incorrecta". El Marco atribuye la solución a la institución: "es responsabilidad de la organización mejorar su programa, incluyendo todo el software, los sistemas y otras tecnologías relacionados con el programa, para remediar cualquier brecha de cumplimiento identificada".

El registro de una alerta descartada debe contener:

• la lista, la entrada y el alias que produjeron la alerta, y la versión o fecha de la lista

• cada identificador comparado (partes de nombres, fecha de nacimiento, nacionalidad, dirección, números de identificación) y su resultado: coincidencia, discrepancia o faltante

• cualquier información adicional solicitada y recibida

• la recomendación y su razonamiento, en caso de que el software la ofrezca

• la decisión del analista y su justificación

• quién confirmó la decisión y cuándo

• para una posible coincidencia verdadera: el escalamiento y la decisión de bloqueo o rechazo tomada por una persona

Qué preguntar a un proveedor:

• Muéstrenos el registro completo de una alerta descartada y de una escalada, exactamente como lo recibiría un examinador.

• ¿Cuánto tiempo se conservan los registros, podemos exportarlos y sobreviven si dejamos de usar el servicio?

• ¿Se registran todos los cambios en las listas, los umbrales y la configuración de coincidencia junto con las alertas a las que afectaron?

Cómo suena una respuesta débil: Registros disponibles únicamente a petición del proveedor, o una resolución que almacena el resultado pero no el razonamiento.

Cómo probarlo con sus propios datos: Elija un puñado de alertas descartadas durante la prueba piloto y pida a un colega que no haya participado que reconstruya cada decisión basándose únicamente en el registro.

Dónde encaja Oscilar, evaluado con los mismos criterios

Oscilar escribió esta guía, por lo que aquí presentamos a Oscilar evaluado según los mismos ocho criterios, incluidos los que no responde por sí mismo.

Criterios 1 y 2, cobertura de listas y coincidencia de nombres: Oscilar no responde a estos por sí mismo. Los datos de las listas y el motor de coincidencia provienen de la herramienta de detección y del proveedor de listas con los que la institución tiene licencia, y esta guía no pretende afirmar que Oscilar reemplace a ninguno de los dos. Evalúe esos componentes bajo sus propios términos utilizando las preguntas anteriores. Debido a que los agentes de Oscilar "pueden ejecutarse dentro de la plataforma completa de Oscilar o como una capa independiente sobre su infraestructura existente", elegir Oscilar no vincula a la institución a un proveedor de listas o herramienta de detección en particular.

Criterios 3, 4 y 6, propiedad, clientes y pagos, y umbrales: Estas son propiedades de la herramienta de detección que genera las alertas, incluido el lugar donde se establece el umbral de coincidencia, por lo que deben evaluarse allí.

Criterio 5, cómo se descartan los falsos positivos: Aquí es donde se ubica Oscilar. En la visión de diseño de Oscilar, la herramienta de detección genera alertas contra las listas con licencia, y el agente revisa cada alerta contra la entrada de la lista y los datos del cliente o del pago, recomendando descartar o escalar y mostrando su trabajo. El Centro de Agentes de Oscilar describe a su agente de Detección de Sanciones como "Guía de resolución explicable y precompletada para cada alerta de sanciones". Una persona sigue tomando la decisión: "Los agentes nunca cierran ni escalan alertas de forma autónoma", que es justo lo que solicitaba un subdirector de KYC y sanciones en un banco comunitario: "la aprobación debe provenir de un analista y no de la IA".

Criterio 7, calidad de coincidencia con sus propios datos: Pruebe Oscilar de la manera en que esta guía recomienda probar cualquier solución: realice pruebas retrospectivas con alertas que su equipo ya haya decidido, luego ejecútelo en modo espejo junto a su proceso actual y analice las omisiones críticas antes del tiempo de revisión ahorrado. Para los modelos que ejecuta, Oscilar monitorea el desvío de datos, características y conceptos junto con los KPI de resultados por segmento.

Criterio 8, el registro: Oscilar proporciona una pista de auditoría completa por decisión con razonamiento almacenado y participación humana en el proceso por diseño.

Dos puntos adicionales, descritos tal como son. La plataforma Oscilar está diseñada para tomar decisiones en menos de 100 ms; esa es una especificación de la plataforma, no una medida de cuánto tiempo se tarda en analizar o revisar una coincidencia de sanciones. Chartis incluyó a Oscilar en la lista FCC50 de 2026 con premios de categoría por Innovación en IA Agéntica y Personalización de Bajo Código/Sin Código; ese es el reconocimiento de un analista, no una clasificación en esta guía.

Los ocho criterios de un vistazo

Utilice la segunda columna como guión para cada conversación con los proveedores y la última columna como plan de prueba.

Preguntas frecuentes

¿Qué debería hacer un software de detección de sanciones que no haga la herramienta de búsqueda gratuita de la OFAC?

La búsqueda gratuita de listas de sanciones de la OFAC aplica lógica difusa únicamente al campo de nombre, combinando la coincidencia de cadenas y la fonética. El software de detección de sanciones tiene que hacer el trabajo que rodea a eso: analizar toda la cartera de clientes y cada pago contra cada lista que la institución necesite, volver a analizar cuando cambien las listas, permitir que la institución vea y ajuste sus coincidencias y mantener un registro de cada decisión. La FAQ 27 de la OFAC señala que los paquetes de software de interdicción comercial "varían considerablemente en costo y capacidades".

¿Recomienda la OFAC un umbral de coincidencia o un producto de detección específico?

No. La FAQ 250 de la OFAC dice que "no puede hacer tal recomendación" sobre las puntuaciones de umbral, y los usuarios "deben tomar sus propias determinaciones de umbral de coincidencia en función de sus propias evaluaciones de riesgo internas y prácticas de cumplimiento establecidas". Sobre si una institución tiene que comprar un software costoso, la FAQ 27 de la OFAC dice que "es principalmente una cuestión para su regulador", y la FAQ 31 dice que el tamaño y las necesidades de cada institución determinan qué buscar.

¿Con qué frecuencia debe una institución financiera volver a analizar a sus clientes?

Una institución financiera debe volver a analizar a sus clientes cada vez que cambie una lista de sanciones contra la que realiza la detección, además de realizar el análisis durante la incorporación y cuando cambien los datos de los clientes. La guía de la OFAC citada en este artículo no establece un calendario fijo, y su Marco menciona el no actualizar el software de detección ante cambios en las listas como una causa fundamental de fallas de cumplimiento. Una revisión que espera a una evaluación periódica puede dejar activo a un cliente recién designado mientras tanto.

¿Es la detección de PEP lo mismo que la detección de sanciones?

No. La detección de sanciones verifica a clientes y pagos contra listas de sanciones, y una coincidencia válida puede significar que la institución debe bloquear o rechazar. La detección de PEP identifica a personas políticamente expuestas, lo que eleva el riesgo del cliente y exige una mayor debida diligencia en lugar de una prohibición. Nuestra guía sobre lo que exigen las normas de EE. UU. para la detección de PEP lo cubre en su totalidad.

¿Durante cuánto tiempo deben conservarse los registros de detección de sanciones?

Según la norma de mantenimiento de registros de la OFAC, 31 CFR 501.601, los registros deben estar disponibles para su examen durante al menos 10 años después de la fecha de la transacción. El período se amplió de cinco a 10 años mediante una norma publicada el 13 de septiembre de 2024, y el cambio entró en vigor el 12 de marzo de 2025. La FAQ 5 de la OFAC espera que los registros de una posible coincidencia incluyan las medidas adoptadas y la información en la que se basó.

¿Es Oscilar un proveedor de detección de sanciones?

El Centro de Agentes de Oscilar incluye un agente de Detección de Sanciones, descrito como "Guía de resolución explicable y precompletada para cada alerta de sanciones". Funciona sobre las alertas, junto con los datos de las listas y la herramienta de detección que la institución tenga contratados, y un analista confirma cada recomendación. Dado que Oscilar escribió esta guía, pruébela con sus propias alertas tal como lo haría con cualquier otro candidato.

El mejor software de detección de sanciones es el que funciona con sus propios clientes y pagos. Cubre las listas que necesita y las actualiza rápidamente, asocia nombres de una manera que usted puede ver y ajustar, detecta la propiedad, analiza a los clientes y los pagos por igual, descarta los falsos positivos mostrando la evidencia, le deja el control del umbral, supera una prueba con sus propios datos y deja un registro que un examinador puede seguir. Para ver cómo funciona la guía de resolución sobre alertas de sanciones junto con una herramienta de detección existente, consulte el agente de Detección de Sanciones en el Centro de Agentes de Oscilar y sométalo a la misma prueba que cualquier otro candidato.