Transaction monitoring

Définition

Le transaction monitoring (surveillance transactionnelle) suit en continu — temps réel ou batch — les flux d'un client pour détecter les opérations atypiques relevant du blanchiment, du financement du terrorisme ou de la fraude.

C'est le maillon opérationnel entre l'onboarding KYC (« je sais qui c'est ») et la déclaration de soupçon TRACFIN (« je signale ce qui est anormal »). Il combine moteurs de règles, modèles ML et équipes d'analystes.

Le pipeline typique

1. Ingestion : transactions, KYC, contexte device, historique.
2. Enrichissement : géolocalisation, MCC, classification du bénéficiaire, scoring du device.
3. Scénarios : règles déterministes et modèles ML (anomalies statistiques).
4. Alertes sur les transactions ou clients à risque.
5. Triage : auto-clear ou auto-block sur certaines, remontée des autres.
6. Revue humaine par un analyste, qui confirme ou rejette.
7. Action : blocage, demande d'info, déclaration TRACFIN, reporting.

LCB-FT vs anti-fraude

Souvent dans le même outil, deux objectifs distincts :

• LCB-FT : détecter blanchiment, terrorisme, fraude fiscale — horizon moyen/long terme, action = déclaration TRACFIN.
• Fraude : détecter compte compromis, APP fraud, fraude carte — horizon temps réel, action = blocage avant exécution.

Les fournisseurs modernes (Hawk, Sardine, Featurespace, Feedzai) proposent les deux dans une même plateforme.

Scénarios classiques

• LCB-FT : structuring/smurfing (petits montants sous le seuil), compte de transit, pays à risque, activité incohérente avec le profil, network analysis (comptes liés), cash intensif.
• Fraude : login depuis un nouveau device suivi d'un virement, premier virement vers un IBAN étranger inconnu, test de cartes volées, géolocalisation incohérente, velocity, pattern de mule.

Règles vs ML

• Règles déterministes : auditables, mais beaucoup de faux positifs (jusqu'à 95 % chez les acteurs historiques).
• ML supervisé : plus précis, moins de faux positifs, mais exige des labels (alertes confirmées).
• ML non supervisé : détecte les anomalies sans label, utile pour les nouveaux types d'attaque.
• Hybride : règles + ML + human-in-the-loop, les meilleurs scores du marché.

Le vrai débat : ML opaque vs explicabilité. L'ACPR exige de comprendre pourquoi une transaction est bloquée — d'où les modèles explicables (SHAP, surrogate trees).

Le défi du volume d'alertes

Une banque moyenne génère plusieurs milliers d'alertes par jour. Cibles d'un bon moteur : moins de 10 % d'alertes confirmées, plus de 50 % traitées en automatique, 5 à 30 minutes de traitement humain par alerte restante. L'optimisation continue (révision des règles, ré-entraînement ML, chasse aux faux positifs) est un travail à plein temps.

Ce que le transaction monitoring n'est pas

• Pas un substitut au KYC : sans profil de référence, il est aveugle.
• Pas une garantie zéro fraude : aucune solution n'attrape 100 % des cas.
• Pas un blocage automatique massif : trop bloquer génère des plaintes, des sanctions ACPR et des coûts.
• Pas figé : règles et modèles doivent être revus en continu (drift).

Dans l'écosystème PSD2

C'est une obligation LCB-FT (AMLD), donc requise pour tous les PSP DSP2, et un enjeu DSP2/PSR sur l'APP fraud (repérer les transactions suspectes avant exécution). DORA ajoute une exigence de résilience opérationnelle sur le système de monitoring lui-même.

Exemples concrets

• Spécialistes : Hawk (DE, ML-first), ComplyAdvantage (UK), Sardine (US, crypto + fintech), Featurespace (UK), Feedzai (PT), Quantexa (network analysis), NICE Actimize et SAS AML (grands comptes).
• Néobanque : un client reçoit 5 000 € d'un IBAN inconnu et re-vire 4 800 € vers un wallet crypto en 5 minutes → alerte → revue en 10 min → demande de justification → blocage et DS TRACFIN si insuffisant.
• APP fraud : un virement de 8 000 € vers un nouveau bénéficiaire à 22h déclenche une friction (pop-up, délai de 24h, vérification téléphone), avec des baisses de fraude rapportées par les grandes banques.
• Solaris (DE) : sanctionnée par la BaFin en 2023 pour défaillance du monitoring (cap de croissance, refonte du moteur).
• Scale : passé de 1 à 10 M de clients, Revolut a dû repenser son moteur (règles seules → ML + équipes 24/7).
• Coût : 0,1 à 1 €/client/an d'outil plus ~1 ETP pour 50 à 100 K clients actifs — soit 2 à 4 M€/an pour 1 M de clients.
• Évolution : graph analytics pour les réseaux de mules, et partage de signaux inter-banques (projet UK Finance), à équilibrer avec le RGPD.