Definición
El transaction monitoring (vigilancia transaccional) sigue de forma continua — en tiempo real o por lotes — los flujos de un cliente para detectar operaciones atípicas vinculadas al blanqueo de capitales, a la financiación del terrorismo o al fraude.
Es el eslabón operativo entre el onboarding KYC («sé quién es») y la comunicación de sospecha a TRACFIN («señalo lo que es anómalo»). Combina motores de reglas, modelos de ML y equipos de analistas.
El pipeline típico
- Ingesta: transacciones, KYC, contexto del dispositivo, historial.
- Enriquecimiento: geolocalización, MCC, clasificación del beneficiario, scoring del dispositivo.
- Escenarios: reglas deterministas y modelos de ML (anomalías estadísticas).
- Alertas sobre transacciones o clientes de riesgo.
- Triaje: auto-clear o auto-block en algunas, escalado del resto.
- Revisión humana por un analista, que confirma o rechaza.
- Acción: bloqueo, solicitud de información, comunicación a TRACFIN, reporting.
PBC/FT vs antifraude
A menudo en la misma herramienta, dos objetivos distintos:
- PBC/FT: detectar blanqueo, terrorismo, fraude fiscal — horizonte de medio/largo plazo, acción = comunicación a TRACFIN.
- Fraude: detectar cuenta comprometida, fraude APP, fraude con tarjeta — horizonte en tiempo real, acción = bloqueo antes de la ejecución.
Los proveedores modernos (Hawk, Sardine, Featurespace, Feedzai) ofrecen ambos en una misma plataforma.
Escenarios clásicos
- PBC/FT: structuring/smurfing (importes pequeños por debajo del umbral), cuenta de tránsito, países de riesgo, actividad incoherente con el perfil, network analysis (cuentas vinculadas), uso intensivo de efectivo.
- Fraude: inicio de sesión desde un nuevo dispositivo seguido de una transferencia, primera transferencia a un IBAN extranjero desconocido, prueba de tarjetas robadas, geolocalización incoherente, velocity, patrón de mula.
Reglas vs ML
- Reglas deterministas: auditables, pero con muchos falsos positivos (hasta el 95% en los actores históricos).
- ML supervisado: más preciso, menos falsos positivos, pero exige etiquetas (alertas confirmadas).
- ML no supervisado: detecta anomalías sin etiqueta, útil para los nuevos tipos de ataque.
- Híbrido: reglas + ML + human-in-the-loop, los mejores resultados del mercado.
El verdadero debate: ML opaco vs explicabilidad. La ACPR exige entender por qué se bloquea una transacción — de ahí los modelos explicables (SHAP, surrogate trees).
El reto del volumen de alertas
Un banco mediano genera varios miles de alertas al día. Objetivos de un buen motor: menos del 10% de alertas confirmadas, más del 50% tratadas de forma automática y de 5 a 30 minutos de tratamiento humano por alerta restante. La optimización continua (revisión de reglas, reentrenamiento del ML, caza de falsos positivos) es un trabajo a tiempo completo.
Lo que el transaction monitoring no es
- No es un sustituto del KYC: sin un perfil de referencia, está ciego.
- No es una garantía de cero fraude: ninguna solución atrapa el 100% de los casos.
- No es un bloqueo automático masivo: bloquear de más genera quejas, sanciones de la ACPR y costes.
- No es estático: las reglas y los modelos deben revisarse de forma continua (drift).
En el ecosistema PSD2
Es una obligación de PBC/FT (AMLD), por lo que se exige a todos los PSP de la PSD2, y un asunto de la PSD2/PSR sobre el fraude APP (detectar transacciones sospechosas antes de la ejecución). DORA añade una exigencia de resiliencia operativa sobre el propio sistema de monitorización.
Ejemplos concretos
- Especialistas: Hawk (DE, ML-first), ComplyAdvantage (UK), Sardine (EE. UU., cripto + fintech), Featurespace (UK), Feedzai (PT), Quantexa (network analysis), NICE Actimize y SAS AML (grandes cuentas).
- Neobanco: un cliente recibe 5.000 € de un IBAN desconocido y retransfiere 4.800 € a una wallet cripto en 5 minutos → alerta → revisión en 10 min → solicitud de justificación → bloqueo y comunicación a TRACFIN si es insuficiente.
- Fraude APP: una transferencia de 8.000 € a un nuevo beneficiario a las 22 h desencadena una fricción (pop-up, plazo de 24h, verificación telefónica), con descensos del fraude reportados por los grandes bancos.
- Solaris (DE): sancionada por la BaFin en 2023 por fallos de monitorización (tope de crecimiento, rediseño del motor).
- Escala: tras pasar de 1 a 10 M de clientes, Revolut tuvo que replantear su motor (solo reglas → ML + equipos 24/7).
- Coste: 0,1 a 1 €/cliente/año de herramienta más ~1 FTE por cada 50 a 100 K clientes activos — es decir, 2 a 4 M€/año para 1 M de clientes.
- Evolución: graph analytics para las redes de mulas y el intercambio de señales entre bancos (proyecto UK Finance), a equilibrar con el RGPD.