FRAML: Unifique el fraude y el lavado de dinero sin difuminar las responsabilidades

Última actualización: septiembre de 2026

Los equipos de prevención de fraude y blanqueo de capitales (AML) observan a los mismos clientes, las mismas cuentas y las mismas transacciones, y durante la mayor parte de la última década lo hicieron desde salas distintas y con herramientas diferentes. Acortar esa distancia es una de las ventajas más claras para cualquier área de delitos financieros. Sin embargo, el término "unificado" abarca muchas cosas en las conversaciones actuales, y el escenario que suele salir mal es aquel que nadie se ha parado a definir.

La respuesta rápida: unifique la capa de señales, no la responsabilidad.

Resumen rápido

• FRAML implica tratar el fraude y el blanqueo de capitales como un único ámbito problemático, pero el término engloba tres aspectos diferentes que no deben tomarse como una sola decisión.

• El fraude y el AML comparten el cliente, el comportamiento y las señales subyacentes, por lo que la necesidad de contar con una capa de datos compartida es evidente.

• Sin embargo, no comparten la obligación legal, las expectativas del supervisor, los plazos ni el estándar de prueba.

• Unifique los datos. Unifique en gran medida la detección, pero manteniendo etiquetas y validaciones separadas. No fusione las decisiones ni la responsabilidad.

• El principal riesgo de error es tener una cola de trabajo unificada: las tareas de cumplimiento acaban gestionándose con las métricas de rendimiento del fraude, simplemente porque eso es lo que muestra el cuadro de mando.

• Planifique el proceso por etapas: primero los datos, segundo la detección y, en último lugar, el modelo operativo, y esto último solo si existe un motivo que vaya más allá de la eficiencia.

¿Qué es FRAML?

FRAML es la práctica de tratar el fraude y el blanqueo de capitales como un único ámbito de actuación en lugar de dos, partiendo de la base de que ambos rastrean actividades ilícitas que se mueven a través de los mismos clientes y transacciones. En la práctica, el término abarca tres aspectos diferentes: datos compartidos, detección compartida o un equipo fusionado.

Estas tres opciones no representan la misma decisión, y el resto de este artículo depende de que sepamos mantenerlas diferenciadas.

Por qué el fraude y el AML están convergiendo ahora

La convergencia no es una moda creada por los proveedores. Es un impulso de todo el sector que responde a dos factores muy concretos.

El primero es que, en la práctica, las tipologías se han fusionado. Una cuenta mula es a la vez un problema de fraude y de blanqueo en la misma transacción: los fondos se obtienen engañando a alguien y luego se mueven para ocultar su origen. Tratar esto como dos investigaciones de dos problemas distintos implica que dos equipos tengan que reconstruir la misma historia contando cada uno con la mitad de las pruebas.

El segundo factor es el tiempo. Los pagos en tiempo real han reducido los plazos. Un análisis que antes se hacía cómodamente después de la liquidación ahora tiene que realizarse en el momento de la transacción o, de lo contrario, no servirá de nada. En una conversación sobre este tema, un banco global describió este cambio como la combinación del cribado de fraude y AML en el mismo instante (el momento de la transacción) en lugar de realizar dos revisiones secuenciales. Esa simultaneidad es el motor del cambio. En cuanto ambas preguntas deben responderse a la vez, tener dos visiones distintas del cliente deja de ser una ineficiencia y pasa a ser una limitación.

Además, esto ya no es una aspiración, sino una categoría de proyectos activos. Las entidades se refieren a sus iniciativas FRAML como programas internos específicos con presupuestos y planes definidos, y reorganizan sus departamentos de delitos financieros en torno a ellos.

Lo que el fraude y el AML realmente comparten

Es importante dejar claro lo sólida que es la base para la convergencia, ya que las advertencias que incluimos más adelante no pretenden ser un argumento en su contra.

Comparten el sujeto. El mismo cliente, la misma cuenta y el mismo comportamiento, observados por dos departamentos que históricamente no podían ver la perspectiva del otro.

Comparten la materia prima. El dispositivo, la identidad, la red, la velocidad, la contraparte... Las señales que aportan valor a un modelo de fraude son, en gran medida, las mismas que resultan útiles para un sistema de monitorización, y ninguno de los dos departamentos las genera por separado. La misma base de pruebas sirve tanto para analizar un pago en tiempo real como para decidir si ese pago encaja en un patrón que deba notificarse.

Y comparten el reto analítico: distinguir lo inusual de lo ilícito. Por eso, las técnicas de detección se pueden trasladar perfectamente de un ámbito al otro, y un equipo que ha desarrollado una buena infraestructura de atributos en un lado rara vez empieza desde cero en el otro.

Por lo tanto, apostar por una capa de datos compartida no es una solución de compromiso. Es el argumento más sólido de todo este debate y donde reside la mayor parte del valor de un programa FRAML.

Lo que no comparten

Esta es la parte que el entusiasmo inicial suele pasar por alto.

La obligación es de naturaleza distinta. Una pérdida por fraude afecta al dinero de la propia entidad, y esta decide qué nivel de riesgo asumir. En cambio, la detección del blanqueo de capitales es una obligación de notificación: un deber hacia el exterior sobre la conducta de un tercero, que se cumple informando a una autoridad sobre lo que se ha observado. Uno es una decisión comercial que afecta al balance propio; el otro es una rendición de cuentas ante un tercero.

La evaluación es diferente. Cada ámbito está sujeto a expectativas de supervisión distintas, por lo que el registro que solicitará un auditor también será diferente.

Los plazos son diferentes. Una decisión sobre fraude se toma en milisegundos, a la velocidad de las máquinas, y normalmente es reversible: se puede desbloquear una transacción retenida o anular una restricción. La decisión de presentar una notificación sigue un ritmo más lento y no es reversible de la misma manera.

El estándar de prueba es diferente. Las decisiones sobre fraude se basan en probabilidades y aceptan cierto margen de error en ambos sentidos de forma deliberada, ya que el coste de cada error se conoce y se puede ajustar. La decisión de presentar una notificación es un juicio ponderado que debe contar con una justificación documentada que un profesional pueda defender formalmente más adelante.

Tenga en cuenta que las consecuencias de confundir ambas cosas van en una sola dirección. Aplicar un estándar propio de AML a la toma de decisiones sobre fraude resulta lento y costoso. Por otro lado, que un proceso de fraude absorba silenciosamente una decisión de notificación de AML constituye un fallo de control, no una mejora de la eficiencia.

Las tres capas que abarca el término "unificado"

Quienes buscan estas soluciones suelen llegar siendo ya un poco conscientes de esta ambigüedad. En una evaluación reciente, una empresa de servicios financieros para particulares planteó su proceso como una pregunta a tres bandas (¿buscaban una solución de AML, una de fraude o una de FRAML?) y, acto seguido, formuló otra más precisa: ¿hasta qué punto querían realmente combinar las revisiones que se procesaban en cada lado?

Esta segunda pregunta es la clave y se divide en tres capas.

Capa uno: datos. Unificar. No hay ningún argumento sólido para mantener dos visiones distintas del mismo cliente. Aquí reside la mayor parte del valor, el riesgo de gobernanza es prácticamente nulo y es un paso reversible.

Capa dos: modelos y detección. Unificar en gran medida. Los atributos y las señales compartidas se pueden transferir perfectamente, con una única advertencia que debe gestionarse activamente en lugar de darla por sentada: las poblaciones de etiquetas son diferentes. Un modelo entrenado con casos confirmados de fraude no se convierte automáticamente en un modelo de monitorización de AML, ya que "fraude confirmado" y "notificado como sospechoso" no son el mismo evento; el segundo es mucho más inusual y requiere una mayor intervención humana. Infraestructura compartida, sí. Etiquetas compartidas, no.

Capa tres: decisiones y responsabilidad. No fusionar. Aquí es donde las obligaciones se separan, y fusionar esta capa es lo que genera problemas de gobernanza.

La mayor parte de la frustración con los programas FRAML surge de tratar estas tres capas como una única decisión, aceptarla en teoría y descubrir solo al llegar a la tercera capa a qué se había comprometido realmente la organización.

Dónde falla la consolidación ingenua

El momento del error es fácil de identificar. En un taller de trabajo sobre un flujo unificado, una empresa de pagos estadounidense llegó a este punto en directo: dado que el modelo hace que los investigadores de fraude también analicen los casos desde la perspectiva de AML, el destino final del trabajo pasa a ser un informe de actividad sospechosa (SAR)... y entonces nadie en la sala supo decir cómo debía ser el flujo de trabajo.

Esa pregunta resume todo el problema en una sola frase. Que un investigador de fraude tome una decisión sobre una notificación de AML es una cuestión de gobernanza, no de asignación de tareas, y ningún diseño de flujo de trabajo puede resolver eso.

En concreto, fallan tres aspectos:

• Quién es el propietario de la notificación. Una cola de trabajo fusionada implica un responsable único, y la decisión de presentar una notificación es precisamente la que debe tener un responsable con nombre y apellidos.

• Qué ocurre con un caso que entra en ambas categorías. Un caso que es candidato a devolución de cargo y, a la vez, a notificación de AML tiene dos salidas distintas, y un único registro de caso con un solo campo de resolución obliga a elegir una de las dos.

• Con qué métricas se gestiona el equipo unificado. Este es el factor crítico silencioso. Si se fusiona la cola de trabajo, las tareas de cumplimiento normativo acabarán gestionándose según las métricas de rendimiento del fraude, porque el rendimiento es lo que muestra el cuadro de mando. Nadie decide esto de forma consciente; simplemente ocurre, y ocurre sin hacer ruido, que es precisamente lo que lo hace peligroso.

Cómo es un modelo unificado cuando la responsabilidad se mantiene separada

La solución no es "volver a crear dos equipos". Es tener una visión de cliente única con dos responsables de la toma de decisiones.

La capa compartida es lo que ven ambos departamentos. Los derechos de decisión siguen perteneciendo a la función que tiene la obligación legal. Un caso que realmente pertenezca a ambos ámbitos se gestiona dos veces de forma deliberada, y cada departamento llega a su propia conclusión a partir de las pruebas compartidas, en lugar de heredar la del otro. Esto es lo contrario a duplicar el trabajo, ya que la parte costosa de una investigación es recopilar las pruebas, no analizarlas.

Lo que hace que esto sea práctico y no burocrático es el registro. Un historial de auditoría completo por decisión con la justificación guardada, diseñado con supervisión humana y adaptado a normas como la SR 11-7, permite que cada departamento vea cómo el otro llegó a su conclusión sin estar condicionado por ella. Los argumentos del equipo de fraude se convierten en pruebas para el analista de cumplimiento, en lugar de ser un veredicto impuesto.

Las herramientas subyacentes pueden ser totalmente compartidas. Una plataforma unificada (con un entorno de datos en tiempo real, inteligencia de dispositivos y comportamiento, reglas y gestión de casos en una sola tecnología, con agentes nativos integrados) es una capa de señales y herramientas compartidas. No es una decisión fusionada, y no debe presentarse como tal al consejo de administración de la empresa.

La diferencia práctica entre un programa integrado y uno confuso se reduce a esto: en el primero, los traspasos de información entre fraude y cumplimiento normativo están definidos, identificados y registrados. En el segundo, simplemente se dan por supuestos.

Cómo organizar la transición por etapas

El orden de los factores importa más que la rapidez en este proceso, ya que las capas varían en cuanto a la facilidad con la que se pueden revertir los cambios.

1. Primero, los datos. Es el paso de mayor valor, menor riesgo de gobernanza y es reversible. Aunque un programa no haga nada más, esto ya lo justifica. El momento del registro o alta del cliente suele ser el punto de partida más claro, ya que las señales que se recopilan al abrir la cuenta son las mismas que ambos departamentos querrán analizar en cada transacción posterior.

2. Después, la detección compartida, abordando explícitamente la particularidad de las etiquetas en lugar de ignorarla. Atributos y herramientas compartidas; objetivos y validaciones independientes.

3. Por último, y solo si hay un motivo que vaya más allá de la eficiencia, el modelo operativo. Defina por escrito quién es el propietario de cada decisión antes de cambiar la ubicación o la estructura de los equipos.

Hay una prueba sencilla que se debe aplicar en cada paso: si un inspector preguntara quién tomó esta decisión y con qué base, ¿la respuesta seguiría siendo un nombre individual y una justificación registrada? Mientras sea así, estará unificando la capa de señales. Cuando deje de serlo, habrá empezado a fusionar responsabilidades, y debería ser capaz de explicar el motivo.

Si el paso de compartir datos es el que está planificando ahora, conviene analizar a fondo qué debe hacer realmente una tecnología de detección consolidada antes de definir su alcance.

Un tema relacionado (hasta qué punto el contexto compartido reduce realmente los falsos positivos y qué se necesita para lograrlo sin aumentar las pérdidas por fraude) merece su propio análisis detallado. Lo mismo ocurre con la elección entre reglas y modelos dentro de la capa dos, que plantea el mismo debate pero a un nivel más técnico.

Preguntas frecuentes

¿Qué significan las siglas FRAML?

FRAML es una contracción en inglés de fraude y AML (prevención de blanqueo de capitales). Se refiere a tratar ambos campos como un único espacio de trabajo, utilizando datos compartidos y, a menudo, las mismas herramientas, en lugar de gestionarlos como dos funciones independientes con visiones separadas del mismo cliente.

¿Cuál es la diferencia entre fraude y AML?

El fraude tiene que ver con las pérdidas de la propia entidad financiera: alguien se lleva un dinero que no es suyo y la entidad decide qué parte de ese riesgo asume. El AML es una obligación de notificación hacia el exterior sobre el comportamiento de un tercero. Esta diferencia en la naturaleza de la obligación condiciona todo lo demás: genera distintas expectativas de supervisión, diferentes plazos y un estándar de prueba propio para cada decisión.

¿Quién presenta el informe de actividad sospechosa en un modelo unificado de fraude y AML?

A nivel estructural, la presentación de la notificación sigue correspondiendo al departamento que tiene la obligación legal de informar, independientemente de las herramientas compartidas que se utilicen de fondo. Unificar los datos y la detección no traslada esta obligación legal, y un caso detectado por un modelo de fraude sigue llegando a la decisión de notificación a través del criterio y el registro del departamento de cumplimiento normativo. Confirme los requisitos específicos aplicables a su entidad con su asesor de cumplimiento.

¿La combinación de fraude y AML reduce los falsos positivos?

En la capa de datos, por lo general sí: disponer de más contexto para cada decisión significa que se generan menos alertas sobre comportamientos que otro sistema ya podría explicar. Fusionar las colas de trabajo de los equipos no produce este efecto e incluso puede camuflarlo, ya que un recuento de alertas combinado oculta de qué lado procede realmente el ruido. El beneficio se obtiene de compartir las señales, no de unificar el personal.

¿Qué debería unificar primero un banco?

Los datos. Una visión única del cliente, la cuenta y la transacción que esté disponible para ambos departamentos. Es el paso que aporta la mayor parte del valor, apenas conlleva riesgos de gobernanza y se puede revertir si no funciona. Cualquier otro aspecto de un programa FRAML resulta mucho más fácil de evaluar una vez que ambas partes observan la misma información.