Construire des pipelines de détection de fraude et de KYC/AML

# Construire des pipelines de détection de fraude et de KYC/AML

Un compte s'ouvre un mardi matin. Il passe les contrôles d'identité en moins de 90 secondes. Trois semaines plus tard, ce même compte reçoit 14 petits dépôts de la part d'inconnus et transfère immédiatement l'argent vers une plateforme d'échange crypto. Vous venez d'assister au blanchiment de fonds par une mule financière, et chaque étape a laissé des données derrière elle.

Cette leçon suit ce compte de l'onboarding au payout, et vous montre comment construire les systèmes qui l'attrapent : device fingerprinting, transaction monitoring, et la mécanique qui déclenche un Suspicious Activity Report (SAR), une déclaration obligatoire que les banques adressent aux régulateurs lorsqu'elles repèrent une activité criminelle possible.

Le cycle de vie d'un compte frauduleux

La fraude n'est pas un événement. C'est un pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète →, et votre détection doit lui répondre étape par étape.

Étape 1 : Onboarding. Une identité synthétique (une fausse personne construite à partir d'un vrai numéro de sécurité sociale et de détails fabriqués) ou une identité volée fait une demande. C'est là que commencent le KYC (Know Your Customer, l'obligation légale de vérifier qui sont vos clients) et l'AML (Anti-Money Laundering, l'ensemble plus large de règles pour bloquer les fonds illicites).

Étape 2 : Dormance. Les bonnes mules restent discrètes. Le compte se comporte normalement pendant des jours ou des semaines pour construire un « historique de confiance » et passer sous le radar des règles simples.

Étape 3 : Activation. L'argent arrive, souvent en montants structurés (délibérément maintenus sous les seuils de déclaration comme la limite américaine de 10 000 $ du Currency Transaction Report).

Étape 4 : Payout. Les fonds sortent vite, généralement vers un canal difficile à inverser : crypto, cartes cadeaux, ou un autre compte mule.

Chaque étape produit un signal de données différent. Ratez-en une et toute la chaîne aboutit.

Onboarding : device fingerprinting et signaux d'identité

À l'inscription, vous disposez de très peu d'historique transactionnel, donc vous vous appuyez sur qui et quoi fait la demande.

Le device fingerprinting consiste à construire un identifiant semi-unique à partir des attributs d'un appareil : système d'exploitation, version du navigateur, résolution d'écran, polices installées, fuseau horaire et adresse IP. Aucun attribut n'est unique isolément, mais la combinaison l'est généralement. Le signal de fraude clé n'est pas l'empreinte elle-même. C'est la répétition : un même device fingerprint qui ouvre 50 comptes est un signal d'alarme criant, même si chaque identité paraît propre.

Autres signaux d'onboarding à forte valeur :

• Vélocité : combien de demandes depuis cette IP, cet appareil ou cette adresse dans la dernière heure.
• Ancienneté de l'e-mail et du téléphone : un numéro activé hier est plus risqué qu'un numéro détenu depuis cinq ans.
• Liveness documentaire : le selfie correspond-il à la pièce d'identité, et s'agit-il d'une personne vivante plutôt que d'une photo de photo.
• Incohérence des données : le numéro de sécurité sociale indique 55 ans, le selfie en montre 22.

Pour la base réglementaire, le FinCEN du Trésor américain publie la règle de Customer Due Diligence qui encadre ce que vous devez collecter et vérifier.

La tension de conception est réelle. Trop de contrôles et les clients légitimes abandonnent le parcours. C'est la friction d'onboarding, et en fintech elle tue directement la conversion. Donc vous procédez par paliers : contrôles légers pour les profils à faible risque, vérification renforcée (document supplémentaire, appel vidéo) uniquement quand les signaux franchissent un seuil.

Transaction monitoring : observer le comportement dans la durée

Une fois le compte actif, vous passez de « qui êtes-vous » à « que faites-vous ». Le transaction monitoring est un système de scoring continu.

Deux grandes approches, utilisées conjointement :

Monitoring à base de règles. Une logique explicite, écrite par des humains. Exemples :

• Signaler tout virement entrant suivi d'un virement sortant de taille similaire sous 24 heures (comportement de pass-through typique des mules).
• Signaler trois dépôts ou plus juste sous 10 000 $ en une semaine (possible structuring, le délit consistant à fractionner les montants pour échapper à la déclaration).

Les règles sont transparentes et faciles à expliquer à un régulateur, ce qui compte. Mais les criminels les apprennent et restent juste sous la ligne.

Modèles de machine learning. Ils scorent les transactions sur des centaines de features à la fois et détectent des patterns que les humains n'ont pas codés à la main. Le revers : ils sont plus difficiles à expliquer, et les régulateurs attendent de la model explainability (pouvoir justifier pourquoi un client a été signalé).

La plupart des fintechs matures font tourner les deux : les règles comme filet de sécurité transparent, le ML pour les cas subtils.

Voici un exemple simplifié d'une feature de vélocité et d'une règle, le type de logique qui se trouve dans un moteur de monitoring :

# Détecte un pass-through rapide : argent entrant, argent sortant, solde résiduel minime
def is_passthrough(account):
    inflow = sum(t.amount for t in account.txns_24h if t.direction == "in")
    outflow = sum(t.amount for t in account.txns_24h if t.direction == "out")
    retained = inflow - outflow
    # Les comptes mules reversent presque tout, vite
    if inflow > 1000 and outflow >= 0.9 * inflow:
        return True, "pass_through_pattern"
    return False, None

C'est volontairement basique. Les vrais systèmes combinent des dizaines de signaux de ce type en un score de risque unique.

Le problème des faux positifs

C'est le cœur de la discipline. Un système anti-fraude qui signale tout attrape tous les criminels et détruit le business.

Chaque alerte coûte de l'argent de deux façons :

1. Coût d'investigation. Un analyste humain doit examiner les comptes signalés. Les analystes coûtent cher et sont lents.

2. Préjudice client. Un compte gelé à tort, c'est un client en colère, un ticket de support, et souvent une relation perdue.

Les commentaires du secteur relèvent systématiquement que la grande majorité des alertes AML se révèlent être des faux positifs (des chiffres supérieurs à 90 % sont largement cités, même si les taux exacts varient selon les institutions et sont difficiles à vérifier). Autrement dit, vos analystes passent l'essentiel de leur temps à disculper des innocents.

L'arbitrage tient en deux termes :

• Précision : parmi les comptes signalés, combien étaient réellement mauvais.
• Rappel : parmi tous les mauvais comptes, combien vous en avez attrapés.

Poussez le rappel vers le haut (attraper plus de fraude) et la précision baisse généralement (plus de fausses alertes). Vous ne pouvez pas maximiser les deux. Les équipes business, compliance et risque doivent décider ensemble du point acceptable, car la « bonne » réponse dépend de l'appétit pour le risque et de l'exposition réglementaire, pas des maths seules.

Une tactique pratique : le risk tiering de la réponse. Toutes les alertes n'exigent pas le gel du compte. Les options montent en sévérité :

• Score faible : journaliser et surveiller.
• Moyen : vérification renforcée légère (demander une confirmation).
• Élevé : bloquer la transaction concernée, pas le compte entier.
• Critique : geler et router vers l'investigation.

Cela préserve l'expérience clientexpérience clientLa perception globale qu'un client se construit de votre marque à travers chaque interaction, du premier contact au support après-vente.Voir la définition complète → tout en contenant le risque.

De l'alerte au SAR : boucler la boucle

Quand l'investigation confirme le soupçon, le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → atteint son point d'aboutissement réglementaire : le Suspicious Activity Report.

Un SAR est un rapport confidentiel déposé auprès de la cellule de renseignement financier (FinCEN aux États-Unis, la National Crime Agency au Royaume-Uni, et leurs équivalents ailleurs). Deux règles comptent :

• Les délais sont légaux. Aux États-Unis, un SAR est généralement dû dans les 30 jours suivant la détection de l'activité suspecte. Rater les délais crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée une responsabilité réglementaire.
• Le tipping off est illégal. Vous ne pouvez pas dire au client que vous avez déposé un SAR. Cela façonne votre produit : vous pouvez restreindre discrètement un compte sans expliquer exactement pourquoi.

Les bons pipelines de SAR sont conçus pour la preuve, pas seulement la détection. Chaque alerte doit porter ses données justificatives : les liens de device fingerprint, la chaîne de transactions, les pics de vélocité. Les enquêteurs ont besoin d'un récit clair, et les régulateurs pourront l'auditer plus tard.

C'est pourquoi le data lineagedata lineageLe data lineage cartographie les déplacements et transformations de la donnée à travers les systèmes, de l'origine à la consommation : d'où elle vient, ce qui l'a modifiée, et où elle va.Voir la définition complète → (la capacité à retracer chaque score jusqu'à ses données sources) n'est pas optionnel. Si votre modèle ML signale un compte, vous devez pouvoir reconstituer pourquoi des mois après.

Assembler le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète →

Retraçons notre compte mule une dernière fois, cette fois à travers le système complet :

1. Onboarding : le device fingerprint correspond à quatre comptes antérieurs. Score relevé mais pas bloqué (les documents d'identité étaient valides). Compte approuvé avec un flag de surveillance.

2. Dormance : période calme. Les règles ne voient rien. Le flag persiste.

3. Activation : 14 petits dépôts entrants d'expéditeurs sans lien entre eux déclenchent une anomalie de réseau (un financement plusieurs-vers-un est inhabituel pour un compte personnel).

4. Payout : la règle de pass-through se déclenche quand les fonds partent vers une plateforme crypto en quelques heures.

Le score combiné franchit le seuil critique. La transaction sortante est bloquée (pas le compte entier, pour limiter le préjudice en cas d'erreur). Un analyste examine les preuves rassemblées, confirme le pattern, et un SAR est déposé dans les délais. Le client n'est jamais informé du motif.

Aucun signal isolé n'a attrapé ce compte. C'est la superposition de signaux faibles tout au long du cycle de vie qui a fonctionné.

Points clés

• La fraude est un pipeline, donc la détection doit l'être aussi. Onboarding, dormance, activation et payout laissent chacun des signaux de données distincts ; ne couvrir qu'une seule étape laisse la chaîne aboutir.
• La force du device fingerprinting, c'est la répétition, pas l'identité. Un appareil qui ouvre de nombreux comptes est un signal plus fort que n'importe quel faux profil isolé.
• Les faux positifs sont le vrai centre de coûts. La plupart des alertes AML sont des fausses alertes ; échelonnez votre réponse (surveiller, vérification renforcée, blocage, gel) plutôt que de tout geler.
• Concevez pour la preuve et l'explicabilité dès le premier jour. Les SAR ont des délais légaux, le tipping off est interdit, et chaque score doit être traçable jusqu'à ses données sources.
• Précision contre rappel est une décision business. Aucun modèle ne la tranche ; risque, compliance et produit doivent choisir ensemble où se placer sur la courbe.