El mejor software de monitoreo de transacciones: 9 criterios a considerar

Última actualización: septiembre de 2026

El mejor software de monitoreo de transacciones para un banco o fintech es aquel que realiza las tareas de monitoreo que la institución necesita, con sus propios datos, y mediante decisiones que sus auditores puedan reconstruir. Una lista de clasificación no puede saber esto de antemano, por lo que esta guía ofrece en su lugar nueve criterios claros para crear una lista de preselección para prevención de fraude y AML (prevención de lavado de dinero). Oscilar escribió esta guía y vende software de monitoreo de transacciones. Por esa razón, no menciona ni clasifica ningún producto, y evalúa a Oscilar bajo estos mismos criterios casi al final.

Resumen rápido

• Una lista de los mejores softwares de monitoreo de transacciones es tan útil como sus criterios definidos y su autor. Esta lista fue creada por Oscilar, que vende soluciones en esta categoría, y no menciona ningún producto.

• Decida primero para qué tareas está comprando la solución: decisiones de fraude en tiempo real en el flujo de pagos, monitoreo de AML a lo largo del tiempo, o ambas en una sola plataforma pero manteniendo la responsabilidad por separado.

• Pondere los nueve criterios con sus equipos de fraude, cumplimiento y tecnología antes de ver cualquier demostración, y luego haga las mismas preguntas a todos los proveedores.

• Considere una respuesta vaga como una respuesta débil, y pruebe con sus propios datos a los proveedores finalistas antes de firmar.

La respuesta corta: cómo elegir un software de monitoreo de transacciones

Para elegir un software de monitoreo de transacciones, decida primero qué tareas de monitoreo necesita cubrir: decisiones de fraude en tiempo real en el flujo de pagos, monitoreo de AML del comportamiento de los clientes a lo largo del tiempo, o ambas en una sola plataforma donde cada equipo mantenga sus propias decisiones. Luego, defina criterios ponderados entre los equipos de fraude, cumplimiento y tecnología, haga las mismas preguntas a todos los proveedores y califique las respuestas, considerando una respuesta vaga como una débil. Los proveedores que pasen este filtro formarán su lista de finalistas para realizar pruebas con sus propios datos antes de firmar.

Oscilar redactó esta lista y vende software de monitoreo de transacciones para fraude y AML, por lo que aquí no se mencionan ni clasifican productos. Los nueve criterios se aplican a todos los proveedores, y en una sección posterior se evalúa a Oscilar bajo estos mismos puntos utilizando únicamente argumentos comprobables.

Cómo leer una lista del "mejor software de monitoreo de transacciones"

Una lista de los mejores softwares de monitoreo de transacciones solo vale la pena si responde a tres preguntas sobre sí misma: quién la escribió, qué criterios utilizó y si el autor vende alguno de los productos que clasifica. Una lista que no responde a ninguna de estas preguntas suele reflejar simplemente los nombres que el autor conoce, y muchas preselecciones reales se arman de la misma manera.

Un socio de una consultora regulatoria que asesora a bancos describió la atracción por un nombre familiar: "Sabemos que los bancos no suelen asumir riesgos... Por lo tanto, van a querer elegir algo que tenga un buen nombre, un nombre tradicional". Un administrador sénior de sistemas de fraude en una cooperativa de crédito comentó que su equipo arma su lista a partir de los proveedores con los que sus directivos han hablado, los que usan instituciones similares y los nombres que han escuchado, para luego ir descartando opciones. Un vicepresidente sénior y director de gestión de riesgos de fraude de un banco comercial señaló que sus primeras consultas van dirigidas a los proveedores que ya trabajan con ellos, y solo después investigan "qué más hay en la industria que pueda ser interesante para ayudarnos a gestionar el riesgo".

Una preselección disciplinada define primero los criterios y sus prioridades, y deja los nombres para el final. Lo que se busca obtener es un grupo pequeño de opciones viables. Un director de AML de una gestora de activos describió la tarea: "Al final, necesito presentarle a mi jefe un puñado de buenas opciones, sabiendo de antemano que un par de ellas no van a funcionar".

Las dos tareas de monitoreo y el tipo de software diseñado para cada una

El software de monitoreo de transacciones realiza dos tareas distintas, y la mayoría de los productos están diseñados para una de ellas. La toma de decisiones de fraude en tiempo real evalúa un pago o evento mientras está en curso y lo bloquea, lo retiene o lo autoriza antes de que el dinero se mueva. Por otro lado, el monitoreo de AML analiza el comportamiento del cliente a lo largo del tiempo, genera alertas para investigación y respalda los informes de actividad sospechosa (SAR) que la institución presenta después de que ocurre el hecho.

La inmediatez es lo que más claramente separa ambas tareas. Un responsable de cumplimiento de BSA/AML en un banco comunitario explicó que en BSA/AML "las alertas se activan mensualmente, y hay una razón para ello", mientras que "en el lado del fraude... quieres detectarlo ahora mismo, cuando aún tengo tiempo de revertirlo, de actuar y minimizar las pérdidas".

Los auditores utilizan un vocabulario específico para describir cómo funciona el monitoreo dentro de cada producto. Ese vocabulario proviene del manual de examen de BSA/AML del Consejo de Examen de Instituciones Financieras Federales (FFIEC). El manual clasifica el monitoreo automatizado en dos tipos de sistemas, y cualquiera de ellos puede estar integrado en los productos que se detallan a continuación.

En palabras del manual: "Los sistemas de monitoreo de transacciones incluyen sistemas basados en reglas y sistemas inteligentes", y "Los sistemas inteligentes son adaptables y pueden filtrar transacciones basándose en la actividad histórica de la cuenta o comparar la actividad del cliente con un grupo de pares preestablecido u otros datos relevantes".

Los compradores hoy en día suelen plantear la adquisición como una elección entre un sistema de monitoreo de transacciones de AML, una solución de monitoreo de fraude o una plataforma única que haga ambas cosas. Una empresa de servicios financieros de consumo planteó su evaluación exactamente de esa manera, y luego analizó hasta qué punto quería combinar las revisiones que procesa cada área. Los tipos de software en el mercado se alinean con estas opciones.

La tabla clasifica los productos según la tarea de monitoreo para la que fueron diseñados, que es lo primero que se debe definir al armar una lista de finalistas.

Es fácil confundir una capa de software (overlay) con un sistema de monitoreo completo. Un director de AML de una gestora de activos comentó: "Algunos proveedores... ofrecen solo capas adicionales, ¿no? No son motores de reglas. No son realmente un sistema de gestión de casos". Su primera opción era una solución integral con motor de reglas, gestión de casos y análisis que funcione de forma nativa con IA. Para la compra exclusiva de detección de fraude, incluyendo cómo se maneja ese mercado, consulte la guía de compra de software de detección de fraude.

¿Una plataforma única o dos independientes para fraude y AML?

El monitoreo de fraude y AML puede compartir una misma plataforma cuando ambos equipos se benefician de los mismos datos y de la misma vista del cliente, siempre y cuando cada área mantenga la propiedad de sus decisiones. Los compradores no siempre están de acuerdo en qué tanto integrar. Un director sénior de crédito de un banco digital comentó: "Yo veo el monitoreo de transacciones de fraude y AML como un solo paquete". Por el contrario, un oficial de AML en una fintech de tarjetas prepago advirtió sobre el riesgo de esto cuando el área de AML no tiene presupuesto propio: "nos quedamos atrapados usando lo que elegía el equipo de fraude, ¿y adivinen qué hacen? Eligen una plataforma excelente para fraude pero deficiente para AML, lo que genera todo tipo de problemas".

Una compra compartida requiere la decisión de ambos equipos. Un responsable de cumplimiento de BSA/AML en un banco comunitario señaló que necesitaría la aprobación del equipo de fraude antes de reemplazar un sistema del cual este equipo depende para sus alertas. La infraestructura tecnológica también se divide según lo que debe ocurrir en tiempo real: un administrador sénior de sistemas de fraude en una cooperativa de crédito mencionó que allí el monitoreo de fraude corre con proveedores independientes porque el sistema de AML no funciona en tiempo real.

En el sector bancario, es poco común ver una infraestructura totalmente integrada. Un vicepresidente sénior y director de AML y sanciones de un gran banco regional afirmó: "La integración total siempre es mejor, pero el mercado está muy fragmentado. En la banca, es muy raro lograr eso". Esto deja las opciones que planteó un gerente sénior de tecnología para sistemas de delitos financieros en una gestora de activos: "quedarnos como estamos y no hacer nada; quedarnos como estamos y colocar una capa de software encima; o adquirir algo nuevo que reemplace nuestro sistema de flujo de trabajo y de alertas".

Para AML, un socio de una consultora regulatoria que asesora a bancos sugirió empezar con una capa de software (overlay), porque los reguladores "no suelen sentirse cómodos con sistemas de monitoreo de transacciones totalmente nuevos", y el sistema nuevo puede ir asumiendo funciones de manera gradual. El argumento completo para compartir datos manteniendo las responsabilidades separadas se encuentra en nuestra guía para unificar el control de fraude y AML sin desdibujar las responsabilidades.

Implementación: dónde se instala el software y con qué debe conectarse

El software de monitoreo de transacciones se implementa en la ruta de pago, en paralelo a ella, o en ambas formas, y ya sea como una capa independiente sobre los sistemas existentes o como una plataforma completa. El software en la ruta de pago debe devolver una decisión antes de que se complete la transacción, mientras que el software que funciona en paralelo analiza la actividad a posteriori y puede procesarse en lotes (batches).

La integración debe estar en la lista de criterios desde el primer momento. Un vicepresidente sénior y director de gestión de riesgos de fraude de un banco comercial mencionó que, con excepción de los bancos muy pequeños, el área de fraude suele utilizar varios proveedores, por lo que la pregunta clave para cualquier candidato es si su arquitectura puede convivir con las demás. Un líder de tecnología para delitos financieros en un gran banco comentó: "Ni siquiera preseleccionamos a muchos de los grandes proveedores tradicionales porque vimos que intentaban meter la IA a la fuerza y modernizar a medias su plataforma heredada".

Para las transferencias ACH, el monitoreo de fraudes es ahora obligatorio. Las normas de monitoreo de fraude de Nacha, que entraron en vigor en dos fases en 2026, exigen a los participantes "establecer e implementar procesos y procedimientos basados en riesgo orientados razonablemente a identificar transferencias ACH iniciadas por fraude". La Fase 1 entró en vigor el 20 de marzo de 2026 para todas las instituciones de origen (ODFI) y los participantes más grandes. La Fase 2 entró en vigor el 19 de junio de 2026 y eliminó los límites por tamaño, por lo que ahora toda institución receptora (RDFI) debe realizar un monitoreo basado en riesgo de los créditos ACH que recibe.

Los nueve criterios y cómo utilizarlos

Los nueve criterios que se presentan a continuación sirven para preseleccionar herramientas de monitoreo de transacciones tanto de fraude como de AML. Cada uno incluye la pregunta que debe hacerle al proveedor y un ejemplo de lo que se considera una respuesta débil. Están planteados a un nivel superior al de una lista de funciones comunes; nuestro checklist de funciones para el monitoreo de transacciones en tiempo real detalla lo que un sistema en tiempo real debe hacer por sí mismo.

Utilice estos criterios en tres pasos:

1. Pondere los criterios antes de calificar a los proveedores, logrando un acuerdo en el peso de cada uno entre los equipos de fraude, cumplimiento y tecnología.

2. Haga las mismas preguntas por escrito a todos los proveedores y guarde sus respuestas.

3. Califique a cada proveedor según sus respuestas, considerando cualquier respuesta vaga como una calificación baja.

Un líder de estrategia de fraude en un neobanco describió este mismo proceso: "Preparé mi hoja de evaluación con diferentes ponderaciones y análisis internamente... Voy a alinearme con las diferentes áreas interesadas sobre el peso de cada criterio... Una vez que tengamos esto, definiremos la lista de preselección".

1. Tareas de monitoreo y canales de pago que cubre

Qué es. La cobertura de tareas y canales de pago se refiere a cuáles de sus necesidades de monitoreo resuelve el software hoy en día (decidir sobre pagos en curso o vigilar la actividad a posteriori) y qué canales de pago puede analizar y procesar. El manual del FFIEC vincula el nivel de sofisticación con la propia institución: "La sofisticación de los sistemas de monitoreo debe estar determinada por el perfil de riesgo del banco". Un banco receptor debe incluir créditos ACH entrantes, ya que las normas de Nacha ahora obligan a todas las RDFI a monitorearlos.

Ambas tareas pueden requerir controles distintos sobre el mismo canal de pago. Un director global de cumplimiento de delitos financieros en una empresa de pagos comentó: "Hoy nos enfocamos en reglas en tiempo real para el fraude, porque queremos poder activar o desactivar la capacidad de bloquear en lugar de solo monitorear. Para el lavado de dinero, no haríamos eso".

Qué preguntar al proveedor. Muéstrenos la actividad de un cliente en todos nuestros canales de pago en una sola pantalla, y díganos sobre qué canales deciden en tiempo real y cuáles revisan a posteriori.

Ejemplo de respuesta débil. "Soportamos todos los canales de pago", sin hacer una demostración real con su mezcla de transacciones, o bien ofrecer decisiones en tiempo real que cubren un solo canal y no los demás que usted solicitó.

2. Cobertura de tipologías que pueda asociar a su propia matriz de riesgo

Qué es. La cobertura de tipologías es qué tan bien se adaptan los escenarios y modelos del producto a los riesgos identificados en su propia matriz de riesgo, y cómo se mantiene actualizada esa cobertura. El mapeo y la calibración son pruebas distintas; un sistema puede pasar una y fallar la otra. Un vicepresidente sénior y director de inteligencia financiera de un banco regional comentó sobre su sistema actual: "Cuando hago mi evaluación de cobertura, se adapta muy bien a mi matriz de riesgo... Pero al mismo tiempo, no es para nada personalizable".

Los escenarios preestablecidos que vienen con el producto son solo el punto de partida. "Cada institución debería escribir reglas personalizadas adaptadas a su modelo de negocio", señaló un oficial de AML en una fintech de prepagos.

Qué preguntar al proveedor. Conecte su biblioteca de escenarios con nuestra matriz de riesgo y muéstrenos cuáles de nuestras tipologías cubre por defecto, cuáles tendríamos que configurar y cuáles tendríamos que escribir desde cero.

Ejemplo de respuesta débil. "Nuestra IA lo detecta todo", una matriz de cobertura sin opciones para ajustar parámetros según sus clientes, o escenarios por defecto presentados como cobertura total.

3. Los datos que puede utilizar y si es posible exportarlos

Qué es. El acceso a los datos define qué puede leer el software (incluyendo sus propios datos, datos de terceros y datos compartidos o de consorcios), cómo conecta los registros que pertenecen a un mismo cliente (resolución de entidades) y si usted puede extraer toda su información cuando lo necesite. La vinculación de datos es clave porque una alerta solo es útil si viene acompañada de su contexto: el dispositivo y la sesión, el comportamiento habitual de la cuenta y los elementos asociados a ella.

Cada uno de estos puntos puede definir la preselección. Un gerente de riesgo de fraude de un banco comercial destacó los datos de consorcio de su proveedor actual como una de sus mayores fortalezas, ya que las alertas basadas en ellos generaban muchos menos falsos positivos. Para un oficial de cumplimiento en una entidad de transferencia de divisas, "la resolución de entidades ha sido el factor decisivo". Por su parte, un oficial de AML de una fintech de prepagos quería tener acceso total a sus datos: "Solo denme un acceso abierto a los datos y nosotros nos encargaremos de extraerlos y hacer lo que necesitemos".

Qué preguntar al proveedor. ¿Cuáles de nuestras fuentes de datos pueden leer desde el primer día y quién desarrolla cada conexión nueva? ¿Cómo vinculan a un mismo cliente que tiene diferentes cuentas y productos? ¿Podemos exportar toda la información, incluyendo decisiones e historial de casos?

Ejemplo de respuesta débil. Cobrar servicios profesionales por cada campo de datos nuevo, explicar la resolución de entidades pero no mostrarla con sus propios registros, o una exportación que no incluya las decisiones ni el historial de los casos.

4. Quién puede modificar la lógica de detección y cómo se prueban los cambios

Qué es. El control de cambios se refiere a quién puede modificar las reglas y modelos de detección, si se puede probar un cambio con datos históricos antes de pasarlo a producción, y cómo se aprueba y registra dicha modificación. Las reglas se siguen modificando constantemente, incluso cuando los modelos realizan la mayor parte de la detección. Un director de riesgos de un banco digital comentó: "Siempre habrá analistas ajustando reglas porque no todo se puede resolver con un modelo".

Los cambios que no se prueban terminan afectando directamente la operación diaria. Un director de cumplimiento de un banco comunitario recordó un cambio de regla aplicado directamente en producción que generó una avalancha de alertas innecesarias.

La configuración también debe adaptarse a sus diferentes programas y segmentos de clientes. Un director de riesgos de un banco patrocinador que atiende a administradores de programas de prepago señaló: "Personalizamos nuestras reglas para cada programa". Un ejecutivo de BSA/AML de un banco con división digital mencionó que la falta de segmentación es un error muy común, ya que una cadena nacional de tiendas y un restaurante familiar no son el mismo tipo de cliente comercial.

Qué preguntar al proveedor. Muéstrenos cómo nuestro equipo de riesgos puede modificar una regla sin necesidad de sus ingenieros, probarla con nuestros datos históricos, y cómo se aprueba y registra el cambio. Luego, muéstrenos el entorno de pruebas real.

Ejemplo de respuesta débil. Cambios que requieren la intervención de los ingenieros del proveedor, segmentación limitada únicamente a cuentas comerciales y personales, o un entorno de pruebas donde no se pueden simular escenarios de forma real. Un experto en sanciones de OFAC de un banco comercial comentó que, luego de descubrir que el entorno de pruebas de un proveedor no permitía simular transacciones, "la expectativa frente a la realidad resultó ser muy diferente".

5. Por qué se generó cada alerta, explicado en términos claros para analistas y auditores

Qué es. La explicabilidad en el monitoreo de transacciones significa que el motivo de cada alerta o decisión debe ser visible para el analista que la trabaja y poder reconstruirse después ante un auditor, detallando la versión de la regla o modelo y los datos que se analizaron. El manual de FFIEC detalla claramente esta expectativa: "La dirección debe documentar y ser capaz de explicar los criterios de filtrado y los límites utilizados, y cómo ambos son adecuados para los riesgos del banco". En la práctica, el motivo de la alerta debe llegar a la bandeja del analista en forma de códigos de razón claros.

Las reglas pueden ser tan opacas como los modelos si dependen totalmente de un tercero. Un gerente de cumplimiento de BSA/AML/OFAC de una cooperativa de crédito comentó que cuando los reguladores preguntan cómo se generan las alertas, el equipo no puede mostrarles las reglas específicas porque su proveedor de monitoreo solo muestra una vista muy general. Un oficial de BSA en un banco comunitario con programas de banca asociada (partner-banking) señaló: "No entendemos cómo funciona cada regla... Creo que tenemos una idea de lo que se supone que deben hacer, pero no de cómo lo hacen".

Qué preguntar al proveedor. Busquen una alerta de hace meses y muéstrennos exactamente por qué se activó, qué versión de la regla o modelo la generó y qué datos vio el sistema en ese momento.

Ejemplo de respuesta débil. Una vista general de las reglas que no se pueden abrir para ver su detalle, una calificación (score) sin motivos asociados o una reconstrucción que solo el personal del proveedor puede realizar.

6. El trabajo posterior a la alerta entre los equipos de fraude y AML

Qué es. El trabajo después de la alerta es la gestión de casos y la transición entre fraude y AML: cómo una alerta se convierte en un caso, cómo un caso de fraude se escala a una investigación de AML y quién es el dueño de cada decisión. Los equipos de fraude y AML deben ver al mismo cliente y el mismo comportamiento, pero responden a obligaciones y estándares de prueba distintos. Compartir datos ayuda a ambos equipos, mientras que unificar la bandeja de decisiones en una sola puede generar problemas de control y gobernanza.

Este proceso se está acercando cada vez más al momento de la transacción misma. Un banco global describió cómo unificó los análisis de fraude y AML en el mismo instante del pago, en lugar de realizar dos revisiones consecutivas.

Qué preguntar al proveedor. Muéstrenos cómo un caso de fraude se convierte en una alerta de AML, qué ve el investigador de AML cuando le llega y quién tiene la última palabra para decidir si se presenta un reporte de actividad sospechosa (SAR).

Ejemplo de respuesta débil. Una sola bandeja compartida donde nadie sabe quién es el responsable final de la decisión, o herramientas separadas que no comparten la información del cliente, lo que obliga a cada equipo a armar el rompecabezas por su cuenta.

7. La información técnica que facilita a sus validadores de modelos

Qué es. La evidencia de validación es la documentación, el acceso a datos y las pruebas que necesitan los encargados de validar sus modelos, ya que incluso si el modelo es del proveedor, la responsabilidad de su validación sigue siendo de la institución financiera. La guía revisada de riesgo de modelos de la Reserva Federal (SR 26-2), en su sección sobre productos de proveedores, señala que aunque algunos componentes puedan ser confidenciales o patentados, las entidades bancarias "pueden no recibir del proveedor el código fuente, los datos o la metodología... Sin embargo, los principios de gestión de riesgo de modelos siguen siendo aplicables". La misma sección añade: "Un elemento importante de la gestión de riesgo de modelos es la validación de los productos de proveedores, ya sea por equipos internos o externos".

El manual de FFIEC también establece que "la metodología de programación del sistema de monitoreo y su efectividad deben ser validadas de forma independiente". Los sistemas complejos dificultan esto. Un vicepresidente sénior de gestión de riesgos de modelos en un banco regional lo describió como "una caja negra sobre otra caja negra, donde no hay visibilidad de las decisiones que se están tomando".

En la práctica, la línea entre una regla y un modelo suele ser borrosa, por lo que los validadores necesitan ver ambos. Un gerente de análisis de riesgo de un banco regional explicó cómo utilizaba el análisis de conglomerados (cluster analysis) para encontrar patrones y luego convertía esos resultados en reglas y tablas sencillas porque el sistema de monitoreo solo permitía ejecutar reglas tradicionales.

Qué preguntar al proveedor. ¿Qué documentación, datos y accesos para pruebas recibirán nuestros validadores, y cómo se monitorea cada modelo para evitar que pierda efectividad (drift) con el tiempo?

Ejemplo de respuesta débil. Decir que "la metodología es confidencial o patentada", sin ofrecer alternativas de validación. La forma de llevar a cabo este proceso se detalla en nuestra guía sobre validación de modelos de AML.

8. El costo total de operación, no solo el precio de compra

Qué es. El costo de operar un software de monitoreo de transacciones incluye todo lo que va más allá de la licencia: la integración con sus sistemas, la cantidad de proveedores de los que depende cada proceso, la gestión de los contratos y de quién es el presupuesto. La integración se paga por cada proveedor, y algunas integraciones no funcionan. Un líder de producto técnico para plataformas de fraude e identidad en un gran banco regional comentó: "Ha habido situaciones en las que nos dimos cuenta de que algo no se integraba bien y tuvimos que descartarlo para buscar otra opción".

Tener muchos proveedores y contratos aumenta los costos. Un líder de riesgos de un banco regional comentó: "No me gusta tener demasiados proveedores asociados a un solo proceso". Un director de operaciones de delitos financieros en un banco regional importante señaló que los contratos suelen tener "fechas y plazos diferentes" y que "al final del día, el área de tecnología es la dueña de nuestro presupuesto".

Qué preguntar al proveedor. ¿Cuál es el costo total de conectar esto a nuestros sistemas y mantenerlo funcionando, qué conceptos se cobran por separado y qué tendrá que desarrollar o mantener nuestro propio equipo?

Ejemplo de respuesta débil. Costos adicionales por cada conexión nueva descubiertos después de firmar el contrato, o trabajos de integración que se presentan únicamente como servicios profesionales de tarifa abierta.

9. Demostración práctica con sus propios datos antes de firmar

Qué es. La prueba con datos reales es la disposición del proveedor a ejecutar su software utilizando el historial de transacciones de su institución y, posteriormente, ponerlo a funcionar en paralelo (shadow) con su sistema actual antes de firmar. Esta prueba solo es útil si el proveedor le muestra de forma transparente tanto lo que el software detectó como lo que no logró identificar (falsos negativos). Pida ver el entorno donde se realizará la prueba, ya que la advertencia del criterio 4 también aplica en este caso.

Qué preguntar al proveedor. Ejecuten el sistema con nuestras alertas históricas y en paralelo con nuestro flujo en vivo, y muéstrennos tanto los aciertos como las alertas que el sistema pasó por alto.

Ejemplo de respuesta débil. Una demostración utilizando únicamente datos de prueba del proveedor, o resultados presentados de forma global sin permitirle analizar casos específicos. Cómo realizar esta prueba, evaluando la calidad de las alertas y el flujo de trabajo de los investigadores, se detalla en una guía independiente sobre evaluación de plataformas de monitoreo de AML con sus propios datos.

Dónde encaja Oscilar, evaluado bajo estos mismos criterios

Oscilar es una plataforma unificada: infraestructura de datos en tiempo real, análisis de dispositivos y comportamiento, motor de reglas y gestión de casos en una sola tecnología con agentes nativos. Los agentes pueden funcionar como una capa independiente sobre la infraestructura que usted ya tiene, o como parte de la plataforma unificada, lo que le da flexibilidad a la hora de elegir entre mantener, complementar o reemplazar su sistema actual.

En cuanto a la lógica de detección y explicabilidad, la propuesta de Oscilar para el monitoreo de AML en bancos combina reglas configurables con patrones de comportamiento, detección de anomalías, nivel de riesgo del cliente, contexto de red y priorización de alertas, manteniendo siempre controles claros y explicables para el análisis humano. Oscilar guarda un registro de auditoría completo de cada decisión con sus respectivos motivos, diseñado para mantener siempre al analista humano en el proceso.

La especificación técnica de la plataforma de Oscilar es procesar decisiones en menos de 100 milisegundos, tal como se publicó en el comunicado de prensa de Nacha del 11 de diciembre de 2025. Al ser una cifra provista por Oscilar y no una evaluación externa independiente, le sugerimos medirla con su propio volumen de transacciones durante el período de prueba en paralelo. El módulo de fraude de la plataforma se detalla en la sección de monitoreo de fraude en transacciones.

Chartis Research incluyó a Oscilar en la lista FCC50 de 2026, otorgándole reconocimientos en las categorías de Innovación en IA Agéntica y Personalización Low-Code/No-Code. Esta es la valoración de una firma de analistas externa y no una clasificación propia de esta guía.

Evalúe a Oscilar bajo el criterio 9 tal como lo haría con cualquier otro proveedor: solicite una prueba con sus datos históricos y un periodo en paralelo con su operación en vivo, y pida ver qué transacciones no se detectaron. Los puntos clave a definir antes de cambiar de sistema se detallan en una guía de compra de software de AML independiente.

Los nueve criterios de un vistazo

Preguntas frecuentes

¿Qué deben evaluar los compradores al comparar software de monitoreo de transacciones?

Los compradores deben evaluar el software de monitoreo de transacciones según las tareas y canales de pago que cubre, la adaptabilidad de las tipologías a su matriz de riesgo, el uso y exportación de datos, el control de cambios, la claridad en los motivos de las alertas, la transición de casos entre fraude y AML, la documentación para validadores, el costo operativo real y las pruebas con sus propios datos. Pondere estos criterios antes de ver cualquier demostración y haga las mismas preguntas a todos los proveedores.

¿Qué criterios de evaluación son los más importantes para las instituciones financieras reguladas?

Para una institución financiera regulada, los criterios que un auditor evaluará son los que más peso tienen: la justificación detallada de cada alerta, cómo se prueban y registran los cambios en la lógica de detección, el mapeo de tipologías según la matriz de riesgo y la información técnica provista para la validación de modelos. El manual de FFIEC espera que la dirección documente y explique sus criterios de filtrado y límites, y que el sistema sea validado de forma independiente. La ponderación exacta dependerá siempre del perfil de riesgo de cada institución, el cual define el nivel de sofisticación requerido.

¿Es lo mismo el monitoreo de fraude en tiempo real que el monitoreo de transacciones de AML?

No. El monitoreo de fraude en tiempo real evalúa y decide si bloquear, retener o permitir un pago mientras la transacción está en curso, antes de que el dinero se mueva. El monitoreo de transacciones de AML analiza el comportamiento del cliente a lo largo del tiempo, genera alertas para investigación y fundamenta los reportes de actividad sospechosa después de que han ocurrido los hechos. Ambos sistemas pueden compartir datos y una misma vista del cliente, pero responden a obligaciones distintas, por lo que una plataforma que combine ambos debe mantener las decisiones y responsabilidades de cada equipo de forma independiente.

¿Por qué esta lista no menciona nombres de proveedores?

Esta lista no menciona proveedores porque Oscilar, quien la redactó, vende software de monitoreo de transacciones, y una clasificación publicada por un vendedor no sería neutral. Al no mencionar productos específicos, la guía se enfoca en criterios objetivos que un comprador puede aplicar a cualquier opción, incluyendo a Oscilar. La lista final de candidatos la define el propio comprador según sus prioridades y las respuestas que reciba de cada proveedor.

¿Cómo se desempeña Oscilar bajo estos criterios?

Oscilar se evalúa bajo estos mismos nueve criterios en su sección correspondiente dentro de esta guía, utilizando únicamente argumentos comprobables, como la trazabilidad de auditoría completa para cada decisión con justificación guardada. Un comprador debe tratar estos puntos como propuestas a verificar. Le sugerimos solicitar a Oscilar la misma prueba con datos históricos y periodo en paralelo que el criterio 9 exige a todos los proveedores.