Última actualización: septiembre de 2026
Las mejores plataformas de monitoreo de transacciones de AML no se pueden elegir de una lista clasificada, porque una clasificación no dice nada sobre cómo funcionará una plataforma con sus alertas. Para un banco, cooperativa de crédito o fintech, la mejor plataforma de monitoreo de transacciones de AML es aquella que demuestra, con los datos históricos y en tiempo real de la propia institución, que genera alertas que los investigadores pueden cerrar de manera más rápida y justificable, manteniendo intacta la cobertura de tipologías. Esa prueba proviene de un ejercicio que evalúa conjuntamente la calidad de las alertas y el flujo de trabajo de los investigadores, califica cada caso cerrado y compara los resultados con los propios analistas de la institución. Esta guía explica cómo realizar ese ejercicio y qué conservar de él, ya que la elección de la plataforma se convierte en algo por lo que un examinador podría preguntar.
Resumen ejecutivo (TL;DR)
La plataforma adecuada es aquella que demuestra con sus propios datos que los investigadores pueden cerrar sus alertas más rápido y de manera más justificable, manteniendo intacta la cobertura de tipologías.
Pruebe la calidad de las alertas y el flujo de trabajo de los investigadores en un solo ejercicio y califique el caso cerrado, porque cada mitad puede mejorar a expensas de la otra.
Realice la prueba con flujos de datos reales: una prueba retrospectiva en un período histórico con reportes de actividad sospechosa (SAR) conocidos, una muestra a ciegas analizada por sus investigadores y un período de prueba en paralelo con datos en tiempo real, todo comparado con las decisiones pasadas de sus analistas.
Revise cada discrepancia con una resolución anterior, ya que puede señalar un error de la plataforma, un vacío en los datos o una práctica que nadie documentó.
Conserve el registro de la evaluación. El modelo de un proveedor sigue siendo responsabilidad de la institución para su validación, y el manual del FFIEC espera que los sistemas de monitoreo se validen de forma independiente.
¿Qué hace que una plataforma de monitoreo de transacciones de AML sea la mejor para su institución?
La mejor plataforma de monitoreo de transacciones de AML para su institución es la que demuestra con sus propios datos que sus alertas alcanzan una resolución justificable más rápido de lo que lo hacen hoy, manteniendo intacta la cobertura de tipologías. Una plataforma se gana esa posición al superar una prueba con sus propios datos, por lo que la misma plataforma puede ser la adecuada para una institución y la incorrecta para otra. Una resolución justificable es aquella que un examinador podría reconstruir meses después: qué regla o versión del modelo se activó, qué datos vio el investigador, qué pruebas y tipologías se consideraron, qué se decidió, y por quién y por qué.
Dos medidas definen el resultado y deben evaluarse juntas. La calidad de la alerta se refiere a si la plataforma genera las alertas que realmente importan para sus riesgos, y el flujo de trabajo del investigador es la rapidez y justificación con la que un investigador pasa de una alerta a una decisión documentada. El caso cerrado captura ambos aspectos: una alerta trabajada hasta llegar a una resolución que se pueda defender.
El manual de examen del Consejo Federal de Examen de Instituciones Financieras (FFIEC) cubre el mismo espectro. Enumera cinco componentes interdependientes de un sistema eficaz de monitoreo y reporte de actividades sospechosas: identificación o alerta de actividad inusual, gestión de alertas, toma de decisiones sobre SAR, finalización y presentación de SAR, y monitoreo y presentación de SAR sobre actividad continua. Una plataforma de monitoreo influye al menos en los tres primeros, por lo que una prueba que se detiene en la alerta solo mide uno de los cinco.
Sus propios analistas son el punto de referencia, y sus decisiones pasadas sobre las mismas alertas son el estándar que un candidato tiene que cumplir o explicar. Un vicepresidente sénior de operaciones e innovación de un banco de ahorro comunitario describió la única prueba que convencería a su institución: "No puedes hacer un cambio hasta que demuestres que otra opción va a ser igual de buena. Y la única manera que se me ocurre para hacerlo... es configurar algo en paralelo, ejecutarlos a la vez y evaluar uno contra el otro".
Conserve el registro a medida que avanza, porque lo que probó, en qué población, con qué resultados y por qué lo eligió es la evidencia que un examinador puede solicitar más adelante. Esta guía parte de una lista preseleccionada. Cómo construir una, entre el software de monitoreo diseñado para fraude y para AML, se cubre en una guía independiente para elegir software de monitoreo de transacciones.
Por qué una comparación de características no puede elegir la plataforma por usted
Una comparación de características no puede elegir una plataforma de monitoreo de transacciones de AML porque el software de monitoreo de BSA/AML en una lista preseleccionada suele cumplir con los mismos requisitos, y una marca de verificación no dice nada sobre cómo se comporta una plataforma en sus datos con sus investigadores. Los criterios de evaluación de proveedores construidos como una cuadrícula de características muestran, al igual que una demostración, lo que se puede configurar en una plataforma. Ninguno de los dos muestra el día a día de un investigador en ella.
Al describir una demostración, un director de cumplimiento de BSA/AML en un banco comunitario dijo: "Eso es lo que me mostraron: cómo configurar [la plataforma]. Yo quiero saber cómo es la vida cotidiana... las alertas, cómo abro casos a partir de ellas". La evaluación tiene que responder a la pregunta que la demostración dejó abierta.
La coincidencia de características tampoco es motivo para cambiar. Como dijo un gerente sénior de cumplimiento de AML en un operador de juegos en línea, "si todo lo demás es idéntico, no vamos a cambiar, ¿verdad?". Un cambio implica trabajo de datos, una ejecución en paralelo y la atención del examinador, por lo que la evaluación tiene que mostrar una diferencia que justifique el costo.
El mismo razonamiento explica por qué esta guía no menciona plataformas: la clasificación de un proveedor se basa en los datos y el perfil de riesgo de otra persona, y no puede decirle cómo funcionará en los suyos. La pregunta sobre qué capacidades diferencian a los sistemas de monitoreo de transacciones tiene su propia guía, y esta continúa donde aquella se detiene, con la prueba de esas capacidades en sus propias alertas.
Los examinadores han avanzado en la misma dirección. Según un director global de operaciones de cumplimiento de una empresa de criptomonedas, antes los examinadores evaluaban un programa por su número de alertas y la cantidad de personas que las revisaban, y ahora preguntan si el programa es estratégico, incluyendo si utiliza IA y aprendizaje automático. La evidencia de sus propios datos responde a esa pregunta, y una lista de características no puede hacerlo.
Qué significa la calidad de la alerta en el monitoreo de AML
La calidad de la alerta en el monitoreo de AML es la confiabilidad con la que las alertas de monitoreo de transacciones de una plataforma conducen a un trabajo relevante, como una derivación, un caso o un SAR, para las tipologías que su evaluación de riesgos indica que enfrenta. Las buenas alertas son productivas, cubren los riesgos que deben cubrir y se basan en datos completos, y el volumen de alertas por sí solo dice poco sobre cualquiera de estos aspectos.
La conversión de alerta a SAR es una métrica útil de analizar pero un mal objetivo a perseguir. En un banco digital, un subdirector de AML comentó que el equipo la sigue como una medida estándar, en conjunto y agregando las derivaciones por fraude: "así medimos si estamos obteniendo buenas alertas, buenas revisiones". Un candidato puede elevar esta proporción alertando menos, así que analícela junto con una lista de aquello sobre lo que el candidato dejó de alertar.
Los resultados de los SAR no siempre coinciden con la regla que se activó. Un analista de cumplimiento de una plataforma de criptomonedas planteó el problema directamente: "A veces, la alerta que se revisa da como resultado la presentación de un SAR, pero no es exactamente por la regla que se activó, ¿verdad?". Atribuir cada SAR a cualquier escenario que haya alertado juzga erróneamente qué escenarios merecen su lugar, por lo que es mejor rastrear cada resultado hasta una tipología.
El origen de sus SAR es la prueba más honesta de la calidad de las alertas. En un banco comunitario, un oficial de BSA describió "demasiados falsos positivos" y dijo: "La mayoría de nuestros SAR provienen de derivaciones internas de las sucursales porque no recibimos alertas realmente buenas del sistema". Cuando la mayoría de los SAR comienzan como derivaciones, el sistema de monitoreo está fallando en su trabajo sin importar su número de alertas, así que registre la fuente de cada SAR en el período de evaluación y verifique cuáles habría detectado el candidato.
Una tasa de falsos positivos tiene doble filo. "Si la tasa de falsos positivos es demasiado alta, significa que estamos perdiendo mucho tiempo en ello. Pero si la tasa de falsos positivos es demasiado baja, significa que podríamos estar perdiendo casos realmente sospechosos", explicó un analista de BSA de un banco comunitario. Para un director de cumplimiento de AML en un banco regional, la prioridad está clara: el equipo prefiere descartar falsos positivos adicionales "antes que correr el riesgo de no alertar sobre algo que tendríamos la obligación de reportar". Menos alertas solo ahorran dinero si se mantiene la cobertura.
La cobertura debe seguir su propia evaluación de riesgos en lugar de una biblioteca de escenarios genéricos. El manual de la FFIEC indica que la sofisticación de los sistemas de monitoreo "debe estar dictada por el perfil de riesgo del banco". Asocie cada escenario de monitoreo de transacciones que ejecute un candidato con una tipología en su evaluación de riesgos, y trate cualquier tipología de alto riesgo no asociada como un vacío, por muy limpios que parezcan los demás resultados.
Los datos completos son parte de la calidad de las alertas, porque una plataforma no puede alertar sobre una transacción que nunca recibió. Un oficial de AML en una fintech de pagos prepagos comentó que parte del motivo para iniciar un nuevo proceso de selección fue que el proveedor actual no devolvía los datos de las transacciones recibidas, por lo que tras una falla en el flujo de datos, el equipo no podía confirmar que se hubieran procesado todas las transacciones. El equipo quería pruebas de que el proveedor había recibido cada fila, "no solo que el proceso se ejecutó", y cualquier candidato debería ser capaz de conciliar lo que procesó con lo que se envió, flujo por flujo.
Los examinadores también evalúan el volumen de alertas en su contexto. El director de cumplimiento de la subsidiaria de un banco señaló que el regulador les había indicado que el banco generaba más alertas que otros bancos similares de su tamaño y volumen. Adaptar el volumen manteniendo intacta la cobertura de tipologías es una disciplina de ajuste, detallada en una guía para reducir los falsos positivos de AML sin perder cobertura. Si las reglas o los modelos de aprendizaje automático son los que deben generar las alertas en primer lugar es una cuestión de diseño independiente, abordada en una guía complementaria sobre reglas de monitoreo de transacciones frente a aprendizaje automático.
Qué significa el flujo de trabajo del investigador y a dónde va realmente el tiempo
El flujo de trabajo del investigador es el camino desde una alerta hasta una decisión documentada: recopilar pruebas, analizarlas, redactar la justificación para el cierre o la derivación y, para las alertas que se convierten en casos, la investigación más profunda detrás de la decisión de un SAR. El manual del FFIEC trata la gestión de alertas como un componente por derecho propio, centrado en los "procesos utilizados para investigar y evaluar la actividad inusual identificada", y señala que "los investigadores deben documentar las conclusiones, incluida cualquier recomendación sobre si presentar o no un SAR".
La recopilación consume gran parte del tiempo de un investigador antes de que comience cualquier análisis de fondo. Un gerente de entregas de TI en una gestora de activos observó trabajar a los analistas con una alerta y vio que su primer paso era salir de la herramienta de casos e iniciar sesión en varios sistemas externos para buscar datos que esta no contenía. En un gran banco regional, un vicepresidente sénior y director de AML y sanciones llamó a esto "transporte crítico sin valor agregado", con investigadores "copiando y pegando de [sus notas] y de su hoja de cálculo favorita". Desde el punto de vista del investigador, un investigador sénior de BSA en un banco comunitario dijo que el sistema "básicamente solo nos repite y lanza alertas. Y luego yo paso todo a [una hoja de cálculo] y lo hago yo mismo".
El análisis y la redacción son los otros grandes costos. Al preguntar a dónde se van las horas, un subdirector de AML en un banco digital comentó: "Creo que se pasa mucho tiempo en el análisis, así como en la redacción de las narrativas para el cierre o la derivación. Y cuando llegas al nivel de caso, ahí es donde creo que se pasa más tiempo saltando entre sistemas y haciendo investigación externa".
Mida a dónde va el tiempo antes de diseñar la prueba, porque el paso más lento varía entre instituciones. En una fintech de pagos prepagos, un director de monitoreo de transacciones de AML dijo que la demora en la gestión de casos se debe a la espera de que los clientes respondan a las consultas, y agregó: "Para ser sincero, estamos bastante bien optimizados en la parte de alertas". Por el contrario, un vicepresidente y oficial de riesgo de BSA en un banco comunitario comentó que su proveedor actual ya "completa gran parte de esa información" y "lo único que a veces nos lleva tiempo es hacer el análisis". Una plataforma que acelere un paso que su equipo ya tiene resuelto no cambiará sus resultados.
Califique la gestión de alertas y la investigación de casos por separado dentro de la misma prueba, ya que una plataforma puede ser rápida en una y lenta en la otra. Un mejor flujo de trabajo también produce mejores investigaciones, como describió el vicepresidente sénior y director de AML y sanciones del gran banco regional: "Si pasaras menos tiempo en el transporte y la unificación de datos, tal vez no solo encontrarías un gran SAR, sino que descubrirías una red completa de operaciones sospechosas". Por eso el flujo de trabajo forma parte de la evaluación de la detección.
Por qué la calidad de las alertas y el flujo de trabajo deben probarse juntos
La calidad de las alertas y el flujo de trabajo de los investigadores deben probarse de forma conjunta porque cada uno puede mejorar a expensas del otro, y las pruebas por separado pierden de vista esta relación. Una plataforma más silenciosa que genere menos alertas pero les quite el contexto puede retrasar cada investigación restante, mientras que una más ruidosa cuyas alertas lleguen con evidencia completa puede cerrar más casos, más rápido y con mejores registros.
El contexto es lo que hace que una alerta sea procesable. Una alerta que solo informa que algo pareció inusual no le da al investigador herramientas para actuar; lo que el cliente hace normalmente, lo que está vinculado a la cuenta y por qué se activó la alerta es lo que la hace útil.
Probado por separado | Lo que puede mostrar | Lo que puede ocultar |
|---|---|---|
Calidad de la alerta | Menos alertas, mejor conversión de alerta a SAR, manteniendo la cobertura de tipologías | Alertas que llegan sin la evidencia que un investigador necesita, por lo que cada caso toma más tiempo |
Flujo de trabajo del investigador | Menos tiempo por alerta, menos copias entre sistemas | Una lista de pendientes que ya no contiene actividad que sus analistas habrían detectado |
Ambos, calificados en el caso cerrado | Resoluciones justificables, el tiempo necesario para alcanzarlas y lo que se pasó por alto | Muy poco, siempre que se analice cada discrepancia |
Solo el caso cerrado muestra ambas mitades de la balanza a la vez.
Para calificar los casos cerrados, registre para cada alerta si llegó a una resolución que pudiera defender, cuánto tiempo tomó y si se pasó por alto algo que sus analistas sí detectaron. El manual del FFIEC orienta a los examinadores en la misma dirección: "Los examinadores deben centrarse en si el banco cuenta con un proceso eficaz de toma de decisiones sobre SAR, no en las decisiones individuales sobre SAR", y "Los bancos deben documentar las decisiones sobre SAR, incluida la razón específica para presentar o no un SAR".
Una discrepancia con una resolución anterior mide tanto el registro como la plataforma. Algunos analistas habrán descartado o derivado alertas basándose en conocimientos que nunca llegaron al expediente del caso, como lo que realmente hace una empresa cliente o actividad investigada fuera del sistema. Un candidato que solo lea el expediente discrepando de esas decisiones estará en lo cierto respecto al expediente. Vale la pena analizar cada discrepancia, más que la tasa de coincidencia general, porque algunas serán errores de la plataforma, otras serán vacíos en los datos y algunas serán prácticas que nadie documentó.
Deje espacio para el criterio del analista sobre la actividad que nunca generó alerta. El director de cumplimiento de AML de un banco regional quería conservar una característica de la revisión humana: revisores que notan actividad que nunca generó alerta pero parece incorrecta, y la derivan para su investigación. Una prueba que solo cuenta las alertas no puede ver esas derivaciones, por lo que debe registrarlas durante el período de evaluación.
Decida qué significa el éxito antes de que lleguen los resultados y defínalo en torno a la calidad. En una cooperativa de crédito, un gerente de BSA fijó el objetivo como: "Incluso si nuestros números no disminuyen... simplemente hagamos que sean de mayor calidad", porque "tenemos oportunidades para identificar actividad sospechosa adicional que podría estar pasándose por alto actualmente". Una métrica redactada con antelación no se puede moldear para adaptarla a la plataforma que el equipo ya prefiera.
Cómo ejecutar la evaluación con sus propios datos
Una evaluación con sus propios datos se ejecuta en siete pasos, ya sea que se llame prueba de concepto (POC), piloto o comparativa directa, y cada paso produce evidencia que vale la pena conservar.
Defina por escrito qué significa el éxito antes de ver cualquier resultado. Defina las métricas, la población y el estándar que un candidato debe superar, y haga que las personas que firmarán la decisión estén de acuerdo con ellos. Una métrica elegida a posteriori suele describir a la plataforma que obtuvo el mejor resultado.
Elija una población que se parezca a su trabajo real. Tome un período histórico con SAR conocidos, alertas resueltas y derivaciones, y ejecútelo en sus flujos de datos reales, con defectos incluidos. Un vicepresidente y gerente del grupo de objetivos de riesgo de un gran banco fue franco sobre esos defectos: "Te sorprendería o no lo terribles que son nuestros datos, lo fragmentados que están y cuántas conexiones rotas tenemos en nuestros flujos de datos todos los días". Una plataforma probada con datos limpios le dirá muy poco sobre flujos de datos como estos.
Realice una prueba retrospectiva del período frente a su sistema actual, en ambas direcciones. Vuelva a procesar la población a través de la plataforma candidata y compare sus alertas con las que generó su sistema. Un responsable de TI de una institución describió la versión del comprador de la prueba: "Creo que sería fantástico ver que algo que alertó en nuestro otro sistema también alerte en el suyo y cómo se trabaja en ello". La comprobación inversa, como la describió un gerente de cumplimiento normativo de una empresa de auditoría de BSA y validación de modelos, es confirmar "que el sistema antiguo estaba activando las alertas correctas" y "asegurarse de que el nuevo sistema no se estuviera perdiendo de nada".
Trabaje una muestra a ciegas como alertas nuevas. Entregue a los investigadores una muestra de las alertas de la plataforma candidata sin su recomendación, y haga que trabajen en cada una de la forma en que lo describió un director de operaciones de AML en una empresa de pagos: "simplemente la trataríamos como una alerta nueva y la analizaríamos, observando nuestros datos". Compare los resultados con lo que decidieron sus analistas en ese momento, o como lo expresó el oficial principal de BSA en un banco patrocinador, "veamos los datos históricos y qué hicieron nuestros analistas".
Trabaje en paralelo con el flujo en tiempo real junto a su proceso actual. Ejecute la plataforma candidata con datos en tiempo real mientras su equipo y sistema actuales continúan con normalidad, de modo que la comparación cubra actividad que el período histórico no contenía. En su declaración conjunta de 2018 sobre innovación, aún vigente a septiembre de 2026, la FinCEN y los reguladores federales de bancos y cooperativas de crédito calificaron a los programas piloto como "un medio importante para probar y validar la eficacia de enfoques innovadores" y señalaron que los pilotos "no deberían someter a los bancos a críticas de supervisión, incluso si los programas piloto finalmente no tienen éxito".
Analice cada discrepancia y pregunte qué se pasó por alto. Cuando la plataforma haya omitido algo que su equipo detectó, averigüe por qué antes de calificar cualquier otra cosa. Cuando haya detectado algo que su sistema actual pasó por alto, analícelo de cerca antes de llamarlo ruido: si su sistema actual tiene vacíos, imitarlo no es el estándar de éxito, y la diferencia podría ser el hallazgo clave. La pregunta que toda prueba retrospectiva debe enfrentar proviene de un director de AML de una gestora de activos: "¿Cómo lo sabemos?".
Pruebe al proveedor además del producto. Un director de cumplimiento de AML en un operador de juegos en línea consideró el soporte y la estabilidad del proveedor como "un aspecto adicional que debe demostrarse a través de la POC, no solo los agentes de IA". Un responsable de tecnología de una empresa de tecnología de nóminas con división bancaria advirtió que tras la decisión "pasamos a su equipo de implementación, que a veces en el pasado nos ha fallado bastante". Conozca al equipo que implementará y dará soporte a la plataforma, pida referencias sobre la implementación y realice un seguimiento de la rapidez con la que el proveedor responde durante la prueba.
Cómo acordar el alcance, el cronograma y la aprobación final para el ejercicio se cubre en una guía sobre criterios de aceptación para una prueba de concepto.
Qué medir y cómo se ve un resultado débil
Las métricas que definen la evaluación de una plataforma de AML muestran la calidad de las alertas y el flujo de trabajo de los investigadores en sus propios casos. La siguiente tarjeta de puntuación enumera diez, con cómo interpretar cada una y cómo se ve un resultado débil.
Métrica | Cómo interpretarla | Un resultado débil |
|---|---|---|
Cobertura frente a su mapa de tipologías | Cada tipología en su evaluación de riesgos se asocia al menos con un escenario o modelo que ejecuta la plataforma candidata, y cada asociación está documentada | Una tipología de alto riesgo sin un escenario asociado, o una asociación que solo el proveedor puede explicar |
Coincidencia con su sistema actual | Lo que alertó antes vuelve a alertar, y cada alerta que difiere tiene una justificación | Una coincidencia exacta con el sistema actual, vacíos incluidos, o diferencias que nadie puede explicar |
Omisiones detectadas por su equipo | Cada SAR y derivación conocidos en el período se rastrean para ver si la plataforma candidata los habría detectado | SAR o derivaciones conocidos que la plataforma candidata nunca detectó, descubiertos solo después de la decisión |
Resultados de la muestra a ciegas | Las resoluciones de los investigadores sobre la muestra a ciegas coinciden con las decisiones pasadas de sus analistas, o bien se explica cada diferencia | Una tasa de coincidencia general alta pero sin un análisis de las discrepancias |
Tiempo para una resolución justificable | Tiempo transcurrido desde la alerta hasta una decisión documentada, medido en casos cerrados | Primeras revisiones más rápidas que requieren más trabajo de corrección, derivación o investigación para cerrarse |
Evidencia en la alerta | Los investigadores encuentran lo que necesitan para decidir en un solo lugar | Los investigadores aún tienen que salir de la herramienta o reconstruir la situación en una hoja de cálculo |
Conciliación de datos | La plataforma candidata demuestra que recibió cada registro enviado, flujo por flujo | Un registro que muestra que la carga se ejecutó, pero sin un conteo de lo que llegó |
Probar un cambio antes de producción | Un cambio de umbral o escenario se puede ejecutar contra el historial antes de implementarse | Los cambios solo se pueden probar activándolos directamente |
Por qué se activó una alerta | Puede mostrar a un examinador la lógica y los datos detrás de cualquier alerta | El proveedor solo ofrece una vista de alto nivel de sus reglas |
Soporte durante la prueba | Las preguntas son respondidas por las personas que le darán soporte después de la implementación | Respuestas rápidas del equipo de ventas, pero lentas por parte de todos los demás |
Un resultado débil en cualquiera de estas filas es un problema que se debe resolver antes de tomar la decisión.
La explicabilidad tiene un peso particular porque un examinador la evaluará directamente. En una cooperativa de crédito, un gerente de cumplimiento de BSA/AML/OFAC comentó que cuando los reguladores preguntan cómo se generan las alertas, el equipo no puede mostrar las reglas específicas porque su proveedor de monitoreo actual solo ofrece una vista de alto nivel. El manual de la FFIEC espera lo contrario: "La administración debe documentar y ser capaz de explicar los criterios de filtrado, los umbrales utilizados y cómo ambos son adecuados para los riesgos del banco".
Verifique también el entorno de prueba. Un ejecutivo de BSA/AML en un banco con una división de banca digital describió el vacío en su sistema actual: "Si quieres hacer algunos cambios en los umbrales de las reglas existentes, eso no es algo que puedas probar antes de activarlo dentro del sistema". El manual espera que los criterios de filtrado y los umbrales se revisen y prueben periódicamente "para garantizar que sigan siendo eficaces", lo cual es difícil en una plataforma que solo permite probar un cambio directamente en producción.
Independientemente de las puntuaciones, obténgalas por escrito. Un director de cumplimiento de BSA/AML en un banco comunitario explicó por qué, partiendo de la pregunta del examinador: "¿cómo lo determinaron? ¿Cómo determinó esto el sistema? Y si no lo tengo por escrito, no podré defenderlo".
Cómo puede ser engañosa una evaluación
Una evaluación resulta engañosa cuando mide la unidad incorrecta o se ejecuta con los datos equivocados. Estas son las formas habituales, cada una cubierta anteriormente:
probar con datos limpios o de muestra en lugar de sus flujos de datos reales
calificar las alertas e ignorar los casos cerrados, de modo que una lista de pendientes más tranquila que ralentiza las investigaciones parezca una victoria
tratar una coincidencia con su sistema actual como un éxito cuando ese sistema tiene vacíos
reportar una tasa de coincidencia general y dejar las discrepancias sin analizar
elegir la métrica de éxito después de tener los resultados
guiarse por la demostración y nunca por el día a día de un investigador
conocer al equipo de ventas y nunca al equipo de implementación
Qué conservar de la evaluación para su examinador
Conserve un registro de la evaluación que alguien externo al proyecto pueda entender: la población y por qué se eligió, el método, los resultados, cómo se interpretó cada discrepancia y por qué se tomó la decisión final. Ese registro responde a un examinador que pregunta cómo eligió la institución su plataforma de monitoreo, y alimenta la justificación interna de la decisión. Un director de cumplimiento de BSA/AML en un banco comunitario describió ese paso interno como "lo que llamamos un formulario de justificación de proyecto... que te guía a través de, por ejemplo, pros y contras... el análisis de costo-beneficio".
El modelo de un proveedor sigue siendo responsabilidad de la institución para su validación. La guía revisada de gestión de riesgos de modelos, emitida el 17 de abril de 2026 por la Reserva Federal (SR 26-2), la OCC (Boletín 2026-13) y la FDIC (FIL-15-2026), reemplazó a SR 11-7 y SR 21-8, la declaración conjunta de 2021 sobre la gestión de riesgos de modelos para sistemas de BSA/AML. Esta reconoce que los bancos "pueden no recibir del proveedor el código subyacente, los datos o la metodología", y señala que "Un elemento importante de la gestión de riesgos de modelos es la validación de los productos del proveedor, ya sea por partes internas o externas". Solicite a cada candidato la documentación que necesitarán sus validadores y registre qué candidatos pudieron proporcionarla.
Se espera que esta misma guía "sea de mayor relevancia para las organizaciones bancarias con más de $30 mil millones en activos totales", y deja fuera de su alcance la IA generativa y agéntica. Una guía independiente cubre lo que implica la validación de modelos de AML en la actualidad, incluyendo qué tan profunda debe ser la validación del modelo de monitoreo.
Las instituciones más pequeñas aún enfrentan la expectativa del manual de examen para los sistemas de monitoreo. El manual del FFIEC señala que "la metodología de programación y la eficacia del sistema de monitoreo deben validarse de forma independiente", y esa expectativa no depende del tamaño de los activos.
Un candidato que encuentre actividad que su sistema actual pasó por alto no pone en duda, por ese solo hallazgo, su programa actual. La declaración conjunta de 2018 señala que cuando los bancos prueban el monitoreo de transacciones basado en IA y encuentran actividad sospechosa que sus procesos existentes no habrían identificado, "las Agencias no asumirán automáticamente que los procesos existentes de los bancos son deficientes". Registre esos hallazgos y cómo se manejaron como parte de la evaluación.
La propuesta de programa de la FinCEN de 2026 aborda la misma inquietud. El preámbulo de su propuesta de regla de programa de AML/CFT (91 FR 18704, abril de 2026) señala que las instituciones que experimenten de manera responsable con tecnologías innovadoras "no incurrirán en ningún riesgo adicional de ser sujetas a una acción de supervisión significativa de AML/CFT o a una acción de ejecución de AML/CFT únicamente sobre la base del uso de tecnologías innovadoras". A septiembre de 2026, la regla de programa de la FinCEN sigue siendo una propuesta: los comentarios cerraron el 9 de junio de 2026 y no se ha emitido una regla final.
¿Implementar una nueva plataforma sobre el sistema actual o reemplazarlo?
Una nueva plataforma puede valer la pena de evaluar sin necesidad de reemplazar su sistema actual, y una plataforma superpuesta (overlay) debe enfrentar la misma prueba que un reemplazo completo. Una capa que tome alertas de su monitoreo existente y las prepare para los investigadores aún tiene que demostrar con sus datos que las resoluciones se vuelven más rápidas y justificables, sin que se pase por alto nada que su equipo habría detectado. La comparación cambia de forma: la plataforma superpuesta se mide contra su proceso actual con las mismas alertas, mientras que un reemplazo se mide como un motor de detección frente a otro.
La responsabilidad sigue siendo de la institución en cualquiera de los dos caminos. Escalonar un cambio a lo largo del tiempo, manteniendo las fuentes de datos ascendentes y el sistema actual mientras se agrega una nueva capa, es una decisión de modernización por derecho propio. Lo que sucede después de la elección, incluidos los datos que se trasladan, la ejecución en paralelo de un cambio, la validación y el mantener informados a los examinadores, se cubre en una guía de compra de software de AML independiente.
Cómo aborda Oscilar una evaluación
Oscilar estructura una evaluación previa a la producción como una alianza de diseño en cuatro etapas: configuración de datos, una prueba retrospectiva contra las alertas históricas de la institución, modo en paralelo junto con el proceso existente y una lectura con intervención humana (human-in-the-loop). Esas etapas siguen la prueba descrita en esta guía, con los propios datos de la institución. La plataforma admite pruebas retrospectivas, pruebas A/B y pruebas unitarias para validar modelos de riesgo existentes y nuevos, de modo que un cambio de umbral o escenario se puede probar contra el historial antes de implementarse.
Después de la implementación, Oscilar monitorea el desvío de datos, características y conceptos junto con los KPI de resultados por segmento. La plataforma mantiene un registro de auditoría completo por decisión con razonamiento almacenado, y está diseñada con intervención humana: los agentes nunca cierran ni derivan una alerta por sí mismos, y un analista humano revisa y confirma cada recomendación antes de tomar cualquier medida. La institución conserva sus estándares de validación, autoridad de aprobación y responsabilidad regulatoria.
La métrica que defiende esta guía es la que Oscilar reporta de una implementación. Un banco en fase de implementación muestra un 92% de coincidencia de los agentes con su equipo de analistas en la resolución de alertas, y un 75% menos de tiempo por revisión. La coincidencia con los propios analistas del banco es la mitad de calidad de la prueba, y el tiempo por revisión es la mitad de flujo de trabajo. Esos son los resultados de un banco con sus propias alertas, y las cifras en las que debe confiar para su institución son las que genere su propia evaluación.
Chartis Research nombró a Oscilar en la FCC50 de 2026, con premios en categorías para Innovación en IA Agéntica y Personalización Low-Code/No-Code. Ese reconocimiento aplica los criterios de un tercero, y la prueba que define su elección sigue siendo la que ejecute con sus propios datos.
Preguntas frecuentes
¿Cómo debe una institución financiera comparar las plataformas de monitoreo de transacciones de AML?
Una institución financiera debe comparar las plataformas de monitoreo de transacciones de AML probando cada una con sus propios datos históricos y en tiempo real, en lugar de basarse en listas de características o demostraciones. La prueba califica los casos cerrados: si cada alerta alcanzó una resolución justificable, cuánto tiempo tomó y qué se perdió la plataforma que los analistas de la institución sí detectaron. Las decisiones pasadas de los analistas son el punto de referencia, y el registro de la comparación vale la pena conservarlo para los examinadores.
¿Por qué probar la calidad de las alertas y el flujo de trabajo de los investigadores juntos?
Probar la calidad de las alertas y el flujo de trabajo de los investigadores de forma conjunta es importante porque cada uno puede mejorar a expensas del otro. Una plataforma que reduzca el volumen de alertas pero elimine el contexto de cada una puede retrasar cada investigación restante, mientras que una lista de pendientes más rápida puede pasar por alto actividades que los analistas habrían detectado. Calificar el caso cerrado, lo que significa una resolución justificable y el tiempo necesario para alcanzarla, captura ambos aspectos en una sola métrica.
¿Cómo puede una nueva plataforma reducir la revisión manual manteniendo la aprobación humana?
Una nueva plataforma reduce la revisión manual recopilando la evidencia para cada alerta y preparando una recomendación, mientras que un investigador sigue revisando y confirmando cada resolución antes de tomar cualquier medida. El tiempo ahorrado proviene de la búsqueda y copia entre sistemas, y la persona que aprueba sigue siendo la misma. Una evaluación debe confirmar que el ahorro se mantiene en los casos cerrados y que cada resolución aún contiene la justificación del investigador.
¿Qué evidencia, pruebas y registro de auditoría deben esperar los reguladores y compradores de una evaluación?
Los reguladores y compradores deben esperar que una evaluación deje un registro escrito de la población analizada, el método, los resultados, cómo se interpretó cada discrepancia con una resolución anterior y por qué se eligió la plataforma. Las pruebas deben incluir una prueba retrospectiva de datos históricos con SAR conocidos, una muestra a ciegas analizada por investigadores y un período de prueba en paralelo con datos en tiempo real. El registro de auditoría de cada alerta debe mostrar qué la activó, qué datos vio el investigador, qué se decidió, y por quién y por qué. El modelo de un proveedor aún necesita validación, ya sea por parte de la institución o de un tercero externo.
¿Podemos evaluar una nueva plataforma mientras la antigua sigue funcionando?
Sí. Una plataforma candidata puede ejecutarse en paralelo con datos en tiempo real junto al sistema existente, que sigue generando las alertas sobre las que actúa la institución. La declaración conjunta de 2018 de las agencias sobre innovación, aún vigente a septiembre de 2026, califica a los programas piloto como "un medio importante para probar y validar la eficacia de enfoques innovadores", y señala que las agencias no asumirán automáticamente que los procesos existentes son deficientes cuando un sistema basado en IA encuentre actividad que esos procesos pasaron por alto.
La mejor plataforma de monitoreo de transacciones de AML para su institución es la que ha demostrado, con sus alertas y frente a las decisiones de sus analistas, que cierra casos más rápido y de manera más justificable con la cobertura de tipologías intacta. Comience con una definición escrita del éxito, evalúe la calidad y el flujo de trabajo en un solo ejercicio y conserve el registro de por qué eligió. Para ver cómo Oscilar puede integrarse sobre el monitoreo existente o reemplazarlo con el tiempo, lea sobre la modernización del monitoreo de AML en fases.

Equipo de Oscilar
El equipo de Oscilar está formado por expertos en diversas áreas de gestión de riesgos. Estos artículos reflejan las opiniones y conocimientos de una gran variedad de colaboradores de toda nuestra organización.
DESCARGO DE RESPONSABILIDAD
El contenido de este sitio web se proporciona solo con fines informativos y no constituye asesoramiento legal, fiscal, financiero, de inversión u otro tipo de asesoramiento profesional. Las opiniones expresadas por las personas citadas, los colaboradores o terceros son exclusivamente suyas y no reflejan necesariamente los puntos de vista de nuestra organización.
Nada aquí debe interpretarse como un respaldo, recomendación o aprobación de ninguna estrategia, producto, servicio o punto de vista en particular. Los lectores deben consultar a sus propios asesores calificados antes de tomar cualquier decisión financiera o de inversión.
Oscilar no hace declaraciones ni garantías sobre la precisión, integridad o actualidad de la información proporcionada y renuncia a cualquier responsabilidad por cualquier pérdida o daño que surja de la confianza en este contenido. Este sitio web puede contener enlaces a sitios web de terceros, que Oscilar no controla ni respalda.


