El mejor software de prevención de lavado de dinero: 9 criterios para su preselección

Última actualización: octubre de 2026

El mejor software de AML (prevención de lavado de dinero) para un banco, cooperativa de crédito o fintech es aquel que cubre el riesgo de lavado de dinero específico de esa institución, ofrece a cada área del programa la misma visión del cliente y deja un registro que un auditor pueda seguir fácilmente desde la alerta hasta la decisión de reportar un SAR (Informe de Actividad Sospechosa). Ninguna lista de clasificación puede saber esto de antemano; por eso, esta guía ofrece nueve criterios claros, cada uno con una pregunta clave y una forma de probar la respuesta con sus propios datos. Oscilar escribió esta guía y comercializa software de AML. Por esa razón, no menciona ni clasifica productos, y se somete a sí misma a los mismos nueve criterios al final del documento.

Resumen rápido

• El software de AML abarca cuatro funciones principales, no un solo producto: debida diligencia del cliente y calificación de riesgo, monitoreo de transacciones, filtrado de sanciones y PEP (personas expuestas políticamente), y gestión de casos y presentación de SAR.

• Decida primero si prefiere gestionar estas tareas en una sola plataforma o distribuidas en varias herramientas, y evalúe con honestidad los costos operativos de transferir datos entre distintas herramientas.

• Evalúe a cada proveedor con los mismos nueve criterios, desde la cobertura de su propio riesgo hasta la validación independiente y la validación humana en cualquier recomendación de IA.

• Descarte respuestas imprecisas y pruebe con sus propios datos a los proveedores finalistas antes de firmar cualquier contrato.

La respuesta corta: cómo elegir un software de AML

Para elegir un software de AML, comience con su propia evaluación de riesgos en lugar de una lista de funciones, defina para cuál de las cuatro tareas de AML está comprando la solución y luego plantee las mismas preguntas a todos los proveedores basándose en criterios claros. El Manual de Examen de la FFIEC BSA/AML establece el principio básico para el monitoreo: "La sofisticación de los sistemas de monitoreo debe estar determinada por el perfil de riesgo del banco". Los proveedores cuyas respuestas resulten sólidas formarán la lista de finalistas para realizar pruebas con sus datos históricos y en tiempo real antes de la firma.

Contar con criterios claros es fundamental porque las primeras conversaciones suelen parecerse mucho. Un oficial de cumplimiento de un banco mediano describió el inicio de su evaluación de esta manera: "Al principio, todos parecen ofrecer lo mismo, pero lo importante es ver qué hace realmente la herramienta y cuáles son los resultados prácticos". Los nueve criterios detallados a continuación están diseñados para responder a esas dos preguntas clave con cualquier proveedor.

Esta guía se centra en cómo armar su lista de finalistas. Una vez que esté cerca de tomar una decisión, los pasos relacionados con comprar y cambiar de software de AML, desde la migración del historial hasta las pruebas en paralelo y la transición definitiva, se detallan en una guía independiente.

Qué cubre el software de AML

El software de AML es el conjunto de sistemas que utiliza una institución financiera para conocer a sus clientes, supervisar su actividad, verificar que no figuren en listas de sanciones o PEP (personas expuestas políticamente), y analizar y reportar lo que resulte sospechoso. La mayoría de las soluciones de prevención de lavado de dinero resuelven muy bien una o dos de estas funciones, y algunas plataformas intentan cubrir las cuatro. Cada tarea genera un registro que un auditor revisará; por eso, el registro de la auditoría es tan importante como la detección en sí.

Cada componente se alinea con un conjunto de normas o directrices de cumplimiento. Para la debida diligencia del cliente, la norma de CDD de FinCEN (31 CFR 1010.230) exige que la institución identifique a cualquier persona física que "posea el 25 por ciento o más de las participaciones de capital" de una persona jurídica cliente, y que verifique a los beneficiarios finales "conforme a procedimientos basados en riesgos en la medida en que sea razonable y viable". La calificación de riesgo del cliente se apoya en este proceso, y un analista de cumplimiento de un banco comunitario destacó su relevancia con claridad: "La gestión del riesgo del cliente es un pilar fundamental en el programa de AML".

En cuanto al monitoreo, el manual de la FFIEC describe cinco componentes interdependientes para supervisar y reportar actividades sospechosas: detección o alerta de actividad inusual, gestión de alertas, toma de decisiones sobre SAR, redacción y presentación de SAR, y monitoreo y reportes continuos sobre actividades sospechosas recurrentes. Un software de monitoreo que solo genera alertas cubre únicamente el primero de estos cinco puntos. Los nueve criterios para software de monitoreo de transacciones analizan en profundidad esta función específica.

El filtrado es un control dentro de un programa de cumplimiento mucho más amplio. El Marco para Compromisos de Cumplimiento de OFAC de 2019 define cinco componentes esenciales de un programa de cumplimiento de sanciones: "(1) compromiso de la dirección; (2) evaluación de riesgos; (3) controles internos; (4) pruebas y auditorías; y (5) capacitación". Una herramienta de filtrado forma parte de los controles internos, y el Marco espera que la institución haya "seleccionado y calibrado las soluciones de manera adecuada para responder al perfil de riesgo de la organización y sus necesidades de cumplimiento". En una guía independiente se detalla cómo evaluar una herramienta de filtrado en sí misma.

La gestión de casos y la presentación de SAR completan el ciclo de cumplimiento. El manual de la FFIEC es muy claro sobre lo que buscan los auditores: "Los examinadores deben enfocarse en si el banco cuenta con un proceso de toma de decisiones sólido para los SAR, no en las decisiones individuales de cada reporte". También indica que "Los bancos deben documentar todas las decisiones de SAR, detallando las razones específicas para presentar o no un reporte".

¿Una sola plataforma o varias herramientas?

El software de AML se puede adquirir como una plataforma unificada que cubre los cuatro componentes, o bien mediante herramientas individuales para cada función; ambas opciones pueden ser correctas. El factor decisivo es evaluar en qué puntos de la transferencia de datos entre componentes su equipo pierde tiempo, contexto o capacidad de justificación ante auditorías. Un buen análisis evalúa las ventajas de ambos enfoques antes de decidir.

El principal argumento a favor de una sola plataforma es la facilidad para escalar casos. El director de cumplimiento de un banco comunitario explicó por qué prefieren integrar los procesos de prevención de fraude y cumplimiento: "Prefiero tener todo bajo un mismo techo porque, actualmente, el equipo analiza y descarta una alerta de fraude. Pero si no la descartan, tienen que escalarla... Si tenemos dos sistemas separados, esa integración directa no existe". Un directivo de operaciones de un banco comunitario describió este objetivo como unificar procesos dispersos "desde el inicio de la cuenta hasta el final de la relación comercial con el cliente".

Por otro lado, la idea de que una sola plataforma lo hace todo a la perfección no siempre se cumple. El director de cumplimiento de una empresa de pagos comentó: "No he visto a un solo proveedor que haga todo de forma excelente. Por lo general, uno destaca mucho en la verificación de transacciones (KYT) y otros se especializan en la debida diligencia de clientes y empresas (KYC/KYB)". Una herramienta especializada puede ser la mejor opción para un componente específico, siempre que sus datos se integren sin perder contexto en el resto del programa de cumplimiento.

El filtrado suele ser la tarea que define si se consolida el sistema o no. Un especialista en cumplimiento que dirigió una evaluación para un banco comunitario señaló que "el banco prefería una solución integrada que cubriera tanto el monitoreo de AML como el cumplimiento de sanciones internacionales". Este mismo especialista enumeró las complicaciones de usar una herramienta independiente: "implica gestionar otro proveedor, mayor dependencia de terceros, más complejidad en la implementación y más trabajo de integración tecnológica".

Sin embargo, otros compradores prefieren conservar su herramienta de filtrado actual. El responsable de prevención de fraude y cumplimiento de una cooperativa de crédito preguntó durante una evaluación si la nueva plataforma podía recibir los resultados de su filtro actual, incluidos los casos descartados, para continuar con sus tareas de AML en lugar de reemplazarlo por completo.

Antes de comparar opciones, pregunte qué datos requiere ingresar cada plataforma y qué resultados entrega exactamente. El director de cumplimiento de una empresa de transferencias en etapa inicial resumió la duda de forma directa: "¿La plataforma analiza todo el flujo de transacciones y devuelve alertas procesadas? ¿O solo recibe nuestras alertas y las organiza en un panel de control? Son dos tipos de producto totalmente distintos". Si mezcla ambos conceptos en su lista de finalistas, estará comparando opciones incomparables.

¿Una sola plataforma o varias herramientas?

Sea cual sea el modelo que elija, unifique las señales de alerta pero mantenga separadas las responsabilidades operativas. El área de prevención de fraude y el equipo de AML deben tener acceso a la misma información del cliente y a su historial de transacciones; sin embargo, responden a normativas, reguladores y niveles de prueba distintos, por lo que una cola de decisiones unificada puede generar problemas de control y gobernanza. Para las fintech, el banco patrocinador también influye en la decisión: el responsable de riesgos de una fintech que opera a través de bancos patrocinadores señaló que el banco es el encargado final de reportar los SAR, lo que limita lo que la fintech puede integrar por su cuenta. La transición a una plataforma unificada también puede hacerse de forma progresiva, manteniendo los sistemas actuales mientras se implementa una nueva capa de software.

1. Cobertura de su propio riesgo

En qué consiste. La cobertura de riesgo mide qué tan bien se adaptan las reglas de detección, el filtrado y las calificaciones de la herramienta a las prioridades de su propia matriz de riesgo de cumplimiento: sus productos, clientes, canales y geografías. El manual de la FFIEC especifica que el monitoreo debe alinearse con el perfil de riesgo del banco, "con especial atención a la composición de productos, servicios, clientes, entidades y geografías de mayor riesgo". La cobertura también implica segmentación, ya que un banco patrocinador, una entidad con varias líneas de negocio o una fintech con diversos programas de cumplimiento rara vez manejan un único perfil de riesgo.

El director de cumplimiento de un banco comunitario planteó esta duda durante una demostración: "Si tuviéramos un número de sucursal diferente para una fintech que patrocinamos, ¿es posible configurar reglas distintas para esa sucursal o para ese conjunto de transacciones?"

Qué preguntar al proveedor. ¿Cómo se adaptan sus reglas de detección a nuestras tipologías de riesgo prioritarias y de qué forma podemos aplicar reglas diferentes para una línea de negocio o un programa patrocinado específico?

Cómo suena una respuesta débil. Que le ofrezcan una gran cantidad de reglas genéricas preestablecidas, sin adaptarlas a su matriz de riesgo y sin opciones para tratar distintos segmentos de forma independiente.

Cómo probarlo con sus propios datos. Seleccione las tipologías más comunes de su matriz de riesgo y solicite al proveedor que demuestre, con una muestra de su historial de transacciones, qué regla o modelo las detectaría y en qué casos no habría cobertura.

2. Calificación de riesgo de clientes siempre actualizada

En qué consiste. La calificación de riesgo de clientes es el nivel o puntaje que define la intensidad con la que se debe supervisar a cada usuario, y este indicador debe ajustarse de forma dinámica cuando cambian sus hábitos o su situación. Esta calificación define los límites de monitoreo, la frecuencia del filtrado de listas y las medidas de debida diligencia reforzada (EDD); por lo tanto, un sistema de riesgo desactualizado afecta la efectividad de todo el programa de cumplimiento. Además, debe ser fácil de justificar, ya que cualquier auditor preguntará los motivos detrás de la clasificación de un cliente.

El equipo de cumplimiento de un banco comunitario describió las dificultades de trabajar con un cálculo de riesgo por lotes mensual: el sistema actualizaba las calificaciones cada mes, la lista de clientes de alto riesgo cambiaba continuamente y el personal tenía que registrar de forma manual las fechas de revisión de debida diligencia reforzada para poder entregar informes ordenados a los reguladores.

Qué preguntar al proveedor. ¿Qué eventos modifican automáticamente la calificación de un cliente entre sus revisiones periódicas, cuánto tarda ese cambio en reflejarse en los sistemas de monitoreo y filtrado, y qué justificación se registra en cada actualización?

Cómo suena una respuesta débil. Un cálculo periódico de riesgo por lotes cuya lógica interna nadie comprende, lo que obliga a gestionar la debida diligencia reforzada y las listas de alto riesgo de forma manual fuera del sistema.

Cómo probarlo con sus propios datos. Tome una muestra de sus clientes actuales, simule un evento que deba elevar su perfil de riesgo (como el uso de un producto de alto riesgo o un patrón de transacciones inusual) y compruebe que el sistema actualice el nivel de riesgo, registre el motivo y comunique el cambio al resto de los componentes.

3. Acceso ágil y directo a sus datos

En qué consiste. El acceso a los datos define qué información puede extraer el software de su sistema bancario central (core) y de sus otras herramientas, quién se encarga de integrar esos datos y si es posible exportar toda su información sin trabas. El éxito de cada componente depende de esto: una calificación de riesgo, una alerta o una coincidencia en listas es tan útil como la calidad de los datos del cliente que la respaldan. El responsable de prevención de fraude de un banco mediano señaló que conocer si el proveedor ya ha trabajado con su core bancario específico es clave para garantizar una visión unificada del cliente cuando la información proviene de múltiples plataformas.

Poder exportar su información es tan valioso como poder ingresarla al sistema. El director de cumplimiento de una fintech de tarjetas prepagas de consumo comentó: "Solo necesito que todos mis datos sean exportables de alguna forma directa. Necesito una ventana de acceso libre a la información".

Qué preguntar al proveedor. ¿Con qué sistemas centrales y auxiliares de nuestra entidad puede conectarse el software desde el primer día, quién realiza la integración de los datos y podemos exportar todos los registros, incluidos el historial de alertas, decisiones y notas de casos?

Cómo suena una respuesta débil. Que le ofrezcan reportes predefinidos estáticos en lugar de una opción de exportación completa de los datos, o que el proyecto de integración se cotice por separado una vez firmado el contrato.

Cómo probarlo con sus propios datos. Solicite un archivo de exportación completo correspondiente a un mes de prueba que contenga alertas, resoluciones de casos y notas de análisis, y compárelo con la información guardada en sus sistemas actuales para ese mismo mes.

4. Un proceso integrado desde la alerta hasta la decisión de SAR

En qué consiste. El flujo de trabajo desde la alerta hasta el reporte de SAR es el camino que sigue una transacción inusual desde que se detecta, se analiza en un expediente de investigación, hasta que se documenta formalmente la decisión de reportarla o archivarla. El manual de la FFIEC evalúa la gestión de alertas como una tarea clave: "La gestión de alertas se centra en los procesos que se siguen para analizar y evaluar actividades sospechosas identificadas". Añade que "los analistas deben documentar sus conclusiones, recomendando claramente si corresponde presentar un SAR".

Este flujo comienza con alertas que aporten contexto. Una alerta que solo indica que algo es "inusual" no es útil; necesita incluir información complementaria, como el comportamiento habitual del cliente y sus cuentas vinculadas. A partir de ahí, la gestión de casos ayuda en la investigación profunda: vinculando alertas con clientes, recopilando evidencia, documentando las conclusiones y coordinando las aprobaciones necesarias.

La presentación de reportes debe formar parte de este mismo flujo. Un responsable de cumplimiento de un banco comunitario enumeró los puntos clave para una demostración: "¿Podemos enviar reportes SAR y CTR (Reportes de Transacciones en Efectivo) directamente desde aquí? ¿Podemos completar el proceso en la misma plataforma o tenemos que usar otro sistema externo? Eso es lo que define el trabajo diario de nuestro equipo".

Qué preguntar al proveedor. Muéstrenos cómo una alerta se convierte en un caso de investigación, cómo se agrupan dos alertas relacionadas de un mismo cliente y de qué forma se documenta la decisión final de un SAR (incluidas las razones para archivar un caso).

Cómo suena una respuesta débil. Gestionar casos de forma externa. El responsable de cumplimiento de una empresa de pagos describió un equipo que trabajaba sin un sistema centralizado, buscando información en distintas plataformas, redactando decisiones en notas sueltas y organizando los casos en planillas de cálculo.

Cómo probarlo con sus propios datos. Replique un caso de investigación real ya cerrado de su historial, desde la primera alerta de sospecha hasta la resolución de SAR, y verifique que cada paso y su explicación queden grabados en un solo lugar.

5. Reglas y límites modificables por su equipo, con registro de cambios

En qué consiste. El control de cambios se refiere a quién puede modificar las reglas de detección y límites de alerta, cómo se prueban estas modificaciones antes de llevarlas a producción y cómo se registra la justificación, el resultado de la prueba y la aprobación. La directora de cumplimiento de un banco comunitario explicó cómo llevan este registro hoy en día: "Documentamos por qué queremos hacer el ajuste, incluimos los resultados de las pruebas y lo enviamos a otra persona para su firma de aprobación". Un buen software automatiza y guarda este registro.

Los compradores prefieren que estas modificaciones las realicen los analistas directamente, sin depender de ingenieros. El responsable de riesgos de una fintech que opera a través de bancos patrocinadores comentó que necesita que "los analistas, no los ingenieros de sistemas, puedan ajustar y crear reglas y alertas en el momento". Cuando cada modificación requiere soporte técnico, un analista de cumplimiento de un banco digital comentó: "Es imposible realizar cambios rápidos de forma oportuna".

Las pruebas previas a la implementación en producción son la otra mitad del proceso. El director de cumplimiento de una fintech de tarjetas prepagas de consumo describió un proceso de ajuste lento: "Tenemos que esperar a que termine el ciclo mensual para ver el impacto del cambio... Si cometes un error sencillo, como poner 'mayor que' en lugar de 'mayor o igual que', los resultados fallan y tienes que esperar otro mes completo para detectarlo". El director de cumplimiento de un banco comunitario recordó un cambio de regla en su empleo anterior que provocó una gran cantidad de alertas falsas, y destacó la importancia de contar con un entorno de pruebas.

Qué preguntar al proveedor. ¿Pueden nuestros analistas modificar una regla sin necesidad de soporte técnico de su lado, probarla con nuestro historial de transacciones el mismo día y registrar quién la aprobó y por qué?

Cómo suena una respuesta débil. Que cada modificación de reglas requiera crear un ticket de soporte con el proveedor, o que los resultados de un ajuste de límites solo puedan verse tras el siguiente ciclo de monitoreo programado.

Cómo probarlo con sus propios datos. Realice una modificación real de límites durante el período de evaluación, ejecute una prueba retrospectiva (backtest) con su historial el mismo día y verifique que el registro de auditoría muestre el motivo, el resultado y la persona que aprobó el cambio. Un analista de cumplimiento de un banco comunitario resumió este estándar: "Para fines de auditoría, necesitamos la trazabilidad completa de todos los cambios realizados en el sistema".

6. Explicaciones claras que faciliten las auditorías

En qué consiste. La explicabilidad garantiza que cada alerta, calificación de riesgo y resolución de caso pueda comprenderse y justificarse por escrito meses después, incluso por alguien ajeno al proceso de análisis. El manual de la FFIEC indica: "La gerencia debe documentar y poder justificar las reglas de filtrado, los límites aplicados y la idoneidad de ambos frente a los riesgos detectados de la entidad". El director de cumplimiento de un banco comunitario resumió el desafío: "Un inspector me preguntará qué criterios usamos o cómo determinó el sistema este resultado. Si no tengo esa documentación por escrito, no podré respaldar nuestras decisiones".

La documentación debe cubrir tanto los cambios aplicados como la situación actual del sistema. El responsable de cumplimiento de una cooperativa de crédito señaló: "Debo poder explicar con claridad cómo genera alertas mi sistema y, si ha habido modificaciones en ese período de tiempo, asegurar que esos cambios están justificados". Un registro robusto para auditorías debe mostrar la alerta, la versión exacta de la regla que la activó, los datos analizados, las evidencias recopiladas, las conclusiones de los analistas y quién autorizó el cierre del caso.

Qué preguntar al proveedor. Seleccionemos un caso cerrado hace meses y muéstrenos el motivo de la decisión, qué versión de la regla o modelo se aplicó, qué información visualizó el analista y quién aprobó la resolución.

Cómo suena una respuesta débil. Un puntaje de riesgo de transacciones sin ninguna justificación asociada, o un proceso de reconstrucción de información que solo pueda realizar el personal técnico del proveedor.

Cómo probarlo con sus propios datos. Durante su período de prueba, elija alertas al azar y solicite a un integrante del equipo ajeno a ese análisis que redacte la justificación para un auditor utilizando únicamente la información grabada en el sistema.

7. Capacidad de validación independiente

En qué consiste. La validación independiente es la revisión técnica que realizan especialistas externos o internos ajenos a la creación del sistema para asegurar que la lógica de detección funciona según lo previsto por la institución. El manual de la FFIEC especifica: "La lógica de programación y la efectividad del sistema de monitoreo deben validarse de forma independiente para asegurar que los modelos identifican correctamente las transacciones inusuales". Para lograrlo, el proveedor debe ofrecer a los encargados de la validación acceso a la documentación, la lógica de reglas y los datos de prueba.

Las directrices de gestión de riesgos de modelos se actualizaron recientemente. El 17 de abril de 2026, la Reserva Federal, la OCC y la FDIC emitieron una guía de gestión de riesgos de modelos revisada (SR 26-2, Boletín OCC 2026-13 y FDIC FIL-15-2026), que reemplaza las normativas anteriores de 2021 sobre sistemas de cumplimiento y prevención de lavado de dinero. En relación con el software comercializado por terceros, la guía señala que las entidades "pueden no recibir del proveedor el código fuente, los datos de origen o la metodología detallada... Sin embargo, los principios generales de gestión de riesgos de modelos siguen siendo plenamente aplicables".

Tres puntos clave de la nueva guía definen los procesos de validación: excluye de la definición formal de "modelo" a los sistemas basados en reglas predefinidas sencillas que no utilicen metodologías estadísticas, económicas o financieras complejas. Por lo tanto, los sistemas de calificación mediante inteligencia artificial o aprendizaje automático entran en esta categoría, mientras que las reglas simples de umbrales fijos pueden quedar fuera. Además, la normativa se orienta principalmente a instituciones financieras con activos superiores a los 30 mil millones de dólares, y no incluye de momento directrices aplicables a tecnologías de inteligencia artificial generativa o agentes autónomos, cuya gobernanza queda en manos de la gestión de riesgos internos de cada institución.

Qué preguntar al proveedor. ¿Qué documentación técnica, conjuntos de datos y accesos de prueba recibirán nuestros validadores independientes para cada regla o modelo, y cómo se supervisa el rendimiento de los modelos en producción?

Cómo suena una respuesta débil. Que califiquen su tecnología o metodología de análisis como confidencial o propiedad intelectual sin ofrecer opciones alternativas para su evaluación.

Cómo probarlo con sus propios datos. Solicite a sus validadores o a la consultora externa que contrate que evalúen la documentación del software durante el período de prueba y realicen un análisis de control con sus propios datos. El proceso de validación al cambiar de sistemas se detalla en la guía para compradores mencionada anteriormente.

8. Control humano obligatorio en cualquier uso de Inteligencia Artificial

En qué consiste. El control humano garantiza que cuando el software utilice inteligencia artificial —por ejemplo, mediante agentes de IA para revisar alertas o redactar propuestas de resolución—, la decisión final siempre sea tomada por un especialista de cumplimiento, quedando registrado este paso de aprobación humana en el sistema. La IA puede analizar datos, recopilar evidencias y redactar justificaciones iniciales, pero el cierre, escalamiento o reporte de cualquier alerta es responsabilidad exclusiva del personal. El director de cumplimiento de un banco comunitario resumió el enfoque de supervisión: "Los reguladores aún no están listos para permitir decisiones de cumplimiento tomadas de forma 100% autónoma por sistemas informáticos".

Qué preguntar al proveedor. ¿En qué fase de cada proceso de trabajo el analista confirma y aprueba la sugerencia sugerida por la IA, y de qué forma se documenta la sugerencia original de la máquina frente a la decisión final del analista?

Cómo suena una respuesta débil. Soluciones de inteligencia artificial que cierren o descarten alertas de forma automática, o sistemas que no puedan diferenciar en su historial qué parte del análisis fue propuesto por la IA y qué parte fue decidida por el analista.

Cómo probarlo con sus propios datos. Ejecute las sugerencias generadas por la IA en paralelo con el trabajo diario de sus analistas en las mismas alertas, compare las diferencias y verifique que ninguna alerta en el entorno de pruebas haya sido cerrada o escalada sin un registro claro de decisión humana.

9. Pruebas reales con sus propios datos

En qué consiste. Una prueba de concepto real permite evaluar el software con su historial de transacciones y, posteriormente, en paralelo con su sistema actual antes de la firma de contratos. El director de cumplimiento de un banco comunitario señaló la relevancia de esto: "Una prueba de concepto es clave porque permite analizar el rendimiento real con nuestros propios datos". El Comunicado Conjunto de 2018 de los reguladores financieros fomenta estos pilotos como herramientas para evaluar y validar nuevas tecnologías, señalando que estos programas no deben generar observaciones negativas por parte de los supervisores, incluso si el piloto no resulta exitoso.

Es fundamental definir qué entiende cada proveedor por "pruebas en paralelo" o "modo espejo" antes de tomar una decisión. Un especialista de cumplimiento de una fintech preguntó: "¿Se trata de un modo espejo real donde podemos probar el impacto de las reglas con el flujo de datos real, o es simplemente un entorno de pruebas genérico donde tenemos que cargar la información de forma manual para ver qué sucede?"

Qué preguntar al proveedor. ¿Podemos realizar una prueba retrospectiva (backtest) de nuestras alertas históricas, ejecutar la plataforma en modo espejo con nuestras transacciones reales en producción y analizar tanto los casos falsos positivos como las posibles alertas omitidas? ¿Qué reguladores u auditores han supervisado ya su sistema en otras entidades? Como comentó un gerente de cumplimiento de una cooperativa de crédito: "Siempre es de gran ayuda conocer con qué reguladores han colaborado previamente".

Cómo suena una respuesta débil. Una demostración de uso del software realizada con datos de prueba genéricos del propio proveedor, o un entorno que requiera la carga manual de información por su parte.

Cómo probarlo con sus propios datos. Realice primero la prueba retrospectiva (backtest), luego la prueba en espejo en paralelo y compare las alertas resultantes caso por caso con las de sus analistas. La metodología detallada para evaluar plataformas de monitoreo de transacciones de AML con sus propios datos se analiza en una guía independiente.

Dónde se sitúa Oscilar frente a estos criterios

Oscilar ofrece una plataforma unificada para la gestión de decisiones de riesgo que integra los procesos de registro de clientes (onboarding), decisiones de crédito, prevención de fraude y cumplimiento de AML, y debe evaluarse frente a los mismos nueve criterios de cualquier otro proveedor. Esta sección utiliza únicamente datos respaldados por la información pública de Oscilar; utilícela como punto de partida para sus análisis.

Qué cubre Oscilar. Oscilar es una plataforma integrada: incluye procesamiento de datos en tiempo real, análisis de comportamiento del usuario y de dispositivos, reglas de negocio y gestión de casos en un único entorno con tecnologías de IA nativas. Sus agentes autónomos pueden funcionar dentro de la plataforma integrada o como una capa complementaria sobre sistemas de cumplimiento existentes, lo que ayuda a las entidades financieras a actualizar sus sistemas de forma progresiva sin necesidad de reemplazarlos por completo de una sola vez. En cuanto a la detección, las soluciones de Oscilar para bancos combinan reglas configurables con perfiles de comportamiento habitual, detección de anomalías de transacciones, riesgos del cliente, redes de contactos y priorización de alertas (criterios 1 y 2).

Filtrado de listas. Oscilar no comercializa un motor de filtrado propio de listas de sanciones. Las coincidencias de filtrado se reciben desde las herramientas de verificación que prefiera el cliente. Sin embargo, el centro de gestión de agentes de Oscilar incluye un asistente específico para el análisis de sanciones que ofrece propuestas explicadas y pre-completadas para la resolución de cada caso sospechoso detectado por el filtro. Si busca integrar el procesamiento de listas de sanciones de forma nativa en la misma plataforma de AML, es importante analizar este punto de acuerdo con su preferencia de arquitectura tecnológica.

Alertas, casos y presentación de reportes (criterio 4). La solución de gestión de casos de Oscilar vincula alertas de riesgo con clientes específicos, recopila la evidencia y registra la justificación y las aprobaciones del analista. Su portal de soluciones de AML para bancos automatiza la redacción y presentación electrónica de los informes SAR a la FinCEN a partir de plantillas pre-completadas con la información recopilada en el caso.

Modificaciones, explicabilidad y validación (criterios 5 a 7). Oscilar admite pruebas retrospectivas (backtests), pruebas A/B y controles de cambios para las reglas de riesgo, y mantiene un registro de auditoría completo para cada decisión tomada. Supervisa la evolución de los patrones de datos y los indicadores clave de rendimiento (KPIs) por segmentos, y su diseño se alinea con las directrices regulatorias de gestión de riesgos de modelos. Los materiales de la plataforma recuerdan de forma clara los límites de responsabilidad: "La entidad financiera conserva la responsabilidad sobre la validación de sus modelos, la autoridad de aprobación y el cumplimiento de las normativas vigentes".

Aprobación y control humano (criterio 8). Las directrices de los agentes inteligentes de Oscilar establecen: "Los asistentes inteligentes nunca descartan ni escalan alertas de forma autónoma; todas las sugerencias de resolución de casos son evaluadas y confirmadas por un analista antes de realizar cualquier acción".

Pruebas de concepto reales (criterio 9). Oscilar organiza sus procesos de prueba previos a la firma como un programa de diseño conjunto de cuatro semanas que incluye: estructuración e integración de datos de prueba, pruebas retrospectivas (backtest) con alertas históricas de la entidad, pruebas en espejo de transacciones en paralelo con sus sistemas actuales y un reporte detallado de resultados. Los datos de implementaciones reales muestran una coincidencia del 92% entre las sugerencias de la IA y el criterio de los equipos de análisis, con una reducción del 75% en el tiempo necesario para resolver cada alerta.

Core bancario y exportación de datos (criterio 3). La idoneidad de la integración tecnológica de datos debe analizarse de acuerdo con su arquitectura de sistemas. Plantee a Oscilar las mismas preguntas de mapeo y exportación de datos que realice a cualquier otro proveedor para validar su compatibilidad técnica.

Reconocimiento del sector. La consultora Chartis incluyó a Oscilar en su informe FCC50 de 2026, otorgándole galardones específicos en las categorías de Innovación en IA para Cumplimiento y Personalización mediante tecnologías sin código o de código bajo (Low-Code/No-Code).

Resumen de los nueve criterios

Utilice esta tabla de evaluación para comparar las respuestas de los proveedores de forma estructurada.

Muchos equipos de cumplimiento ya evalúan tecnologías con este formato. El departamento de AML de un banco digital utiliza una matriz de puntuación similar con valores fijos para calificar cada sistema analizado antes de presentar los resultados a la dirección; esta tabla ayuda a definir esas prioridades de análisis.

Preguntas frecuentes

¿Qué funciones cubre habitualmente un software de AML?

Un software de AML suele abarcar cuatro procesos principales: debida diligencia de clientes y calificación de riesgo, monitoreo de transacciones sospechosas, filtrado de sanciones internacionales y personas expuestas políticamente (PEP), y gestión de investigaciones de casos y reportes de actividad sospechosa (SAR). Algunas soluciones resuelven una tarea específica y otras plataformas unifican las cuatro. Dado que cada tarea genera un registro auditable, evalúe la calidad de esos informes de trazabilidad tanto como la precisión en la detección.

¿Qué regulaciones aplican al elegir una plataforma de prevención de lavado de dinero?

El manual de supervisión de la FFIEC define las expectativas regulatorias sobre monitoreo, gestión de alertas y decisiones de SAR, mientras que la OFAC establece los requisitos de cumplimiento de sanciones. Las nuevas pautas de gestión de riesgos de modelos se rigen por la directiva SR 26-2 (y sus equivalentes de la OCC y la FDIC de abril de 2026). La gestión de relaciones con proveedores se enmarca dentro de las directrices de relaciones con terceros de 2023, en espera de la actualización propuesta en septiembre de 2026.

¿Cómo se puede probar un software de AML con sus datos antes de comprarlo?

Realice una prueba retrospectiva (backtest) con su historial de alertas previas, ejecute la herramienta en paralelo (modo espejo) con el flujo de transacciones real de su sistema actual y compare las decisiones resultantes con el criterio de sus analistas. Asegúrese de que las pruebas en paralelo utilicen datos reales en producción en lugar de cargas de datos manuales. Analice tanto las alertas ignoradas como las detectadas.

¿La directiva SR 11-7 sigue aplicando a los sistemas de AML?

No. La directiva SR 11-7 fue reemplazada el 17 de abril de 2026 por la norma SR 26-2 (junto con el boletín OCC 2026-13 y FDIC FIL-15-2026), que también actualiza las pautas sobre riesgo de modelos de prevención de lavado de dinero. Los modelos provistos por terceros siguen siendo responsabilidad de validación de la entidad financiera, mientras que los sistemas basados en reglas lógicas fijas y las herramientas de IA generativa cuentan con tratamientos específicos según su alcance.

¿Cuál es el mejor software de AML para una entidad bancaria?

La mejor herramienta para un banco es la que mejor se adapta a su propia matriz de riesgo comercial, unifica la visión del cliente entre todos sus procesos de cumplimiento y genera un registro de auditoría claro para los supervisores. Ninguna clasificación externa puede anticipar esa compatibilidad. Evalúe a cada opción con criterios homogéneos y realice pruebas con sus propios datos antes de tomar la decisión.

¿Oscilar es un proveedor de software de AML?

Sí. Oscilar ofrece una plataforma unificada para decisiones de riesgo en las áreas de registro (onboarding), crédito, prevención de fraude y cumplimiento de AML. Incluye soluciones de monitoreo de transacciones, gestión de casos, presentación electrónica de reportes SAR y asistentes inteligentes de soporte para analistas. El filtrado de sanciones se integra conectando las herramientas de listas que utilice la entidad. Le invitamos a evaluar a Oscilar con los mismos nueve criterios definidos en esta guía.