Détecter la fraude et le blanchiment en temps réel

# Détecter la fraude et le blanchiment en temps réel

Un virement de 48 000 $ quitte le compte d'une petite entreprise à 2h14 du matin, à destination d'une banque bénéficiaire dans un pays avec lequel le client n'a jamais réalisé de transaction. Habituellement, ce client déplace 3 000 à 5 000 $ pendant les heures de bureau. En 200 millisecondes, avant que le paiement ne soit exécuté, le dispositif de monitoring de la banque doit décider : laisser passer, mettre en attente, ou bloquer et appeler le client.

Cette décision est un problème de données. Cette leçon suit ce virement à travers les couches de détection que font tourner les banques modernes, et montre pourquoi le défi le plus difficile n'est pas d'attraper les acteurs malveillants, mais de ne pas se noyer dans les fausses alertes.

Deux problèmes qui se ressemblent mais n'en sont pas un seul

Commençons par définir les termes, car les banques les traitent différemment.

La fraude est un vol : quelqu'un déplace de l'argent sans autorisation. La victime est en général le client ou la banque. La vitesse est le facteur clé, car l'argent peut disparaître en quelques minutes.

Le blanchiment consiste à masquer l'origine de fonds déjà illicites (produits du trafic de drogue, corruption, contournement de sanctions). La banque n'est pas la victime directe ; elle est le tuyau. Les régulateurs exigent des banques qu'elles le détectent et le déclarent au titre des règles AML (Anti-Money Laundering). La fenêtre d'investigation pertinente se compte en jours ou en semaines, pas en millisecondes.

Les deux reposent sur la même matière première : données de transaction, données client et schémas comportementaux. Mais la détection de fraude est optimisée pour l'interception en temps réel, tandis que l'AML est optimisée pour construire un dossier défendable qu'un régulateur acceptera.

Couche 1 : les règles

La couche la plus ancienne, et toujours la plus répandue, est le moteur de règles : une logique si-alors codée en dur par des analystes.

Notre virement de 48 000 $ déclenche plusieurs règles à la fois :

• Montant très supérieur à la plage habituelle du compte
• Transaction en dehors des horaires habituels
• Nouveau pays bénéficiaire
• Pic de vélocité (plusieurs virements importants sur une courte fenêtre)

Les règles sont transparentes et faciles à expliquer à un examinateur, ce que les régulateurs apprécient. Une règle AML classique est la détection du structuring : signaler les dépôts juste sous le seuil de déclaration de 10 000 $ qui déclenche un Currency Transaction Report aux États-Unis. Si quelqu'un dépose 9 500 $ trois jours de suite, une règle l'attrape.

La faiblesse : les règles sont rigides et génèrent un bruit énorme. Un seuil de « 10 000 $ par jour » signale de la même façon un traiteur de mariage et un blanchisseur. C'est le problème des faux positifs, et c'est le principal poste de coût de tout le système.

La taxe des faux positifs

Voici le calcul qui dérange. Les praticiens du secteur estiment couramment que plus de 90 % des alertes AML sont des faux positifs (le chiffre exact varie selon les banques et est difficile à vérifier publiquement : traitez-le comme une estimation largement citée, pas comme une statistique précise).

Chaque alerte devient du travail. Un investigateur humain sort l'historique du client, vérifie le bénéficiaire et rédige une conclusion. Cela coûte de l'argent et du temps. Les grandes banques font tourner des équipes d'investigation de plusieurs milliers de personnes.

L'objectif n'est donc pas de « tout attraper ». C'est attraper davantage de vrais positifs tout en réduisant les faux positifs, parce que la capacité des analystes est finie. Un modèle qui signale 10 000 transactions pour attraper 5 cas réels peut être moins bon qu'un modèle plus fin qui en signale 200 pour en attraper 4.

Gardez ce compromis en tête. Chaque couche ajoutée existe pour l'affiner.

Couche 2 : l'analyse de réseau

Les règles regardent une transaction ou un compte. L'analyse de réseau (ou analyse de graphe) regarde les relations entre de nombreux comptes.

Le blanchiment passe rarement par un seul compte. Il circule par des chaînes : un compte mule reçoit des fonds, les fractionne, les fait suivre et les empile entre plusieurs banques pour brouiller la piste. Chaque saut pris isolément paraît normal. Le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → n'apparaît que si l'on relie les points.

Les techniques de graphe modélisent les comptes comme des nœuds et les transactions comme des arêtes, puis cherchent des structures suspectes :

• Fan-out / fan-in : un compte qui envoie vers beaucoup, ou beaucoup qui envoient vers un seul, dans un timing serré
• Flux circulaires : de l'argent qui revient à son point de départ après une boucle
• Ponts soudains entre des grappes qui n'avaient jamais interagi

Notre virement de 48 000 $ est réexaminé dans son contexte. Si le compte bénéficiaire a reçu la même nuit des virements de taille comparable de six émetteurs sans lien entre eux et les a immédiatement fait suivre, c'est un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → de mule classique, invisible pour une règle mono-transaction mais évident sur le graphe.

Pour une introduction en langage clair à la façon dont les criminels structurent ces flux, le Groupe d'action financière (l'organisme mondial qui fixe les standards AML) publie des ressources accessibles sur fatf-gafi.org.

🎬 [VIDEO: "How Money Laundering Works" - youtube.com - une explication animée claire du modèle placement, empilement, intégration qui sous-tend la détection AML]

Couche 3 : le machine learning

Les règles encodent ce que l'on sait déjà. Le machine learning (ML) trouve les schémas que l'on n'a pas écrits.

Deux variantes comptent ici.

L'apprentissage supervisé s'entraîne sur un historique labellisé : des transactions passées marquées frauduleuses ou non frauduleuses. Le modèle apprend les combinaisons de variables (montant, heure, appareil, localisation, risque du bénéficiaire, ancienneté du compte) corrélées à une fraude confirmée. Il note ensuite les nouvelles transactions de 0 à 1.

Le piège : les modèles supervisés ont besoin de labels propres. La fraude que vous avez attrapée est labellisée ; celle que vous avez manquée est silencieusement labellisée « saine ». Le modèle hérite de vos angles morts.

L'apprentissage non supervisé n'a pas besoin de labels. Il signale des anomalies : des comportements qui s'écartent de la baseline propre au client ou de celle de ses pairs. Notre virement de 2h14 est anormal au regard de l'historique du client, donc un modèle non supervisé le fait remonter même si ce schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → exact n'a jamais été observé.

Les stacks modernes combinent les trois couches. Un design courant fait passer une transaction d'abord par les règles (rapide, peu coûteux), puis note les survivantes avec du ML, puis enrichit les scores élevés avec des variables de graphe avant qu'un humain ne les voie.

Voici une étape de scoring simplifiée :

# Combine les signaux en un score de risque unique
def score_transaction(txn, customer, graph):
    rule_hits = count_rule_triggers(txn, customer)      # ex. 3
    ml_score  = fraud_model.predict_proba(txn)          # 0.0 - 1.0
    graph_risk = graph.mule_pattern_score(txn.payee)    # 0.0 - 1.0

    risk = (0.3 * min(rule_hits / 5, 1)
            + 0.4 * ml_score
            + 0.3 * graph_risk)

    if risk > 0.85:
        return "BLOCK_AND_REVIEW"
    elif risk > 0.5:
        return "HOLD_FOR_ANALYST"
    return "ALLOW"

Les pondérations ne sont pas arbitraires. Les banques les calibrent en fonction de la taxe des faux positifs, en décidant combien d'heures d'analyste chaque seuil va coûter.

L'exigence d'explicabilité

Un modèle de ML peut être précis et rester inutilisable, parce que les banques doivent expliquer leurs décisions aux régulateurs et, quand elles bloquent un paiement légitime, aux clients.

Si un modèle gèle le virement d'un client, la banque ne peut pas dire « le réseau de neurones n'était pas à l'aise ». Il lui faut des codes de motif : « signalé pour montant inhabituel, nouveau pays bénéficiaire, horaire atypique ». C'est pourquoi les techniques interprétables et des outils comme SHAP (une méthode qui attribue un score à chaque variable d'entrée) accompagnent les modèles. Les régulateurs attendent de plus en plus une gouvernance des modèles, de la documentation et des tests de biais, pas seulement de la précision.

C'est la tension de tout le domaine : les modèles les plus puissants sont souvent les moins explicables, et la banque ne peut pas troquer totalement l'explicabilité contre la performance.

Ce qui se passe après le déclenchement d'une alerte

La détection n'est que la moitié du système. Dès que notre virement est signalé, un workflow s'enclenche.

En fraude, la banque peut mettre le paiement en attente et déclencher une step-up authentication : un appel ou une notification dans l'application pour confirmer que le client en est bien à l'origine. Si c'est confirmé, le virement est libéré. Sinon, il est bloqué et le compte mule peut être déclaré.

En AML, si un investigateur confirme le soupçon, la banque dépose un Suspicious Activity Report (SAR), une déclaration confidentielle aux régulateurs financiers (FinCEN aux États-Unis). Point essentiel : la banque ne peut généralement pas informer le client qu'un SAR a été déposé (le « tipping off » est interdit). Le client ne voit rien ; la déclaration part vers les autorités, qui peuvent la relier aux déclarations d'autres banques.

C'est pourquoi la qualité des données compte autant. Un SAR construit sur des données sales est ignoré. Un SAR bien étayé, enrichi de preuves issues du réseau, devient du renseignement actionnable.

Pourquoi les banques mutualisent leurs données

Une banque ne voit que sa part du réseau de blanchiment. La chaîne de mules traverse souvent plusieurs établissements. Cet angle mort structurel pousse à des dispositifs de partage d'information et à des modèles de consortium où les banques contribuent des signaux pour détecter des schémas inter-bancaires, dans le respect de règles de confidentialité strictes.

Des techniques émergentes comme les analyses préservant la confidentialité (analyser des signaux de risque partagés sans exposer les données client brutes) visent à permettre aux banques de collaborer sans enfreindre le droit de la protection des données. C'est une frontière active en 2026, pas un problème résolu.

À retenir

• La fraude et l'AML utilisent les mêmes données mais optimisent différemment : la fraude pour une interception en millisecondes, l'AML pour un dossier défendable et déclarable.
• Les faux positifs sont le vrai coût. La mesure d'un bon système, c'est d'attraper plus de fraude réelle en envoyant moins d'alertes inutiles à des équipes d'analystes en nombre fini.
• Les couches s'empilent, elles ne se concurrencent pas. Les règles apportent vitesse et transparence, l'analyse de réseau révèle les schémas inter-comptes, le ML trouve l'inconnu. Les stacks modernes font tourner les trois.
• L'explicabilité est une contrainte dure, pas un bonus. Un modèle que vous ne pouvez pas expliquer à un régulateur ou à un client lésé est un risque, quelle que soit sa précision.
• Le prochain avantage est dans la collaboration. Le blanchiment traverse les institutions, donc le partage de données préservant la confidentialité est la direction que prend la détection.