Trois couches de pipeline pour que votre détection fraude et KYC tienne face à un examen ACPR

Les fintechs opérant sous licence EMI ou agrément établissement de paiement vivent une contradiction permanente : leurs marges dépendent de l'onboarding ultra-rapide (quelques minutes pour ouvrir un compte Lydia ou Sumeria), mais leur licence exige une vigilance KYC qui, mal architecturée, ralentit tout ou laisse passer l'inacceptable. En 2025, l'ACPR a prononcé plusieurs mises en demeure contre des acteurs du paiement pour défaillances dans les procédures de détection des opérations suspectes. La pression ne faiblit pas en 2026 : la transposition de la 6e directive AML européenne renforce les obligations de traçabilité des décisions et d'explication des alertes. Si votre 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 → fraude est un modèle boîte noire alimenté par un batch quotidien, vous n'êtes pas prêts.

Ce playbook décrit trois couches de pipeline à construire dans l'ordre, les pièges classiques à chaque étape, et ce que vous pouvez faire dès cette semaine.

Construire le pipeline en trois couches séquentielles

Couche 1 : ingestion et qualité des signaux bruts

Avant tout modèle, la question est : de quels signaux disposez-vous et à quelle latence ? Pour la fraude de paiement en temps réel (card-not-present, virements instantanés SEPA via le réseau RT1), un batch H+24 est inutilisable. Vous avez besoin d'un flux streaming sur Kafka ou Confluent Cloud avec une latence inférieure à 500 ms entre l'événement de transaction et l'entrée dans le moteur de scoring.

Pour le KYC et l'AML, la temporalité est différente : ce qui compte, c'est l'exhaustivité des signaux d'identité (pièce d'identité, selfie, données open bankingopen bankingCadre réglementaire (PSD2 en Europe) obligeant les banques à partager les données clients via des API standardisées, avec consentement, transformant les données bancaires en actif compétitif. via DSP2, historique de comportement sur 90 jours glissants) et leur qualité. Un pipeline KYC qui ingère des documents via un prestataire comme Onfido ou Veriff doit capturer non seulement le résultat de la vérification, mais aussi le score de confiance brut et les attributs d'échec, car ce sont ces métadonnées qui permettront d'auditer une décision de refus un an plus tard.

Posez un contrat de donnéescontrat de donnéesAccord formel entre l'équipe qui produit les données et celles qui les consomment, fixant structure, sens, qualité et responsabilité en cas de rupture.Voir la définition complète → explicite sur chaque source : 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 → versionné, propriétaire, SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète → de fraîcheur, règle de qualité automatisée. Sans cela, vos features d'entraînement divergent silencieusement de vos features de production, et votre modèle se dégrade sans que personne ne le voie.Comprendre ce que les données transactionnelles et comportementales révèlent réellement sur vos utilisateurs est un prérequis à cette étape.

Couche 2 : feature engineering et modélisation à deux vitesses

Séparez physiquement le pipeline fraude temps réel du pipeline AML/KYC batch. Ils ont des contraintes opposées.

Pour la fraude temps réel, les features les plus prédictives sont celles qui capturent l'anomalie contextuelle : vélocité sur 15 minutes (nombre de tentatives, somme des montants), distance géographique entre deux transactions consécutives, écart entre le device fingerprint actuel et le profil historique de l'utilisateur. Un gradient boosting (XGBoost, LightGBM) avec ces features calculées en ligne via un feature storefeature storeRéférentiel centralisé qui gère les features de ML et garantit la cohérence entre les environnements d'entraînement et de production.Voir la définition complète → Redis tient dans des latences de 20 à 50 ms. Stripe et Adyen publient des benchmarks internes montrant des taux de faux positifs autour de 0,1 % à ce niveau de latence, un repère utile pour calibrer vos propres objectifs.

Pour l'AML et le screening sanctions, la logique est différente. Vous travaillez sur des fenêtres longues (90 jours, 12 mois), des agrégats réseau (qui envoie à qui, quels schémas de structuration émergent), et vous devez croiser avec des listes externes : OFAC, listes de l'UE, bases de PEP (personnes politiquement exposées). Un graph database comme Neo4j ou TigerGraph permet de détecter les anneaux de mule en quelques secondes là où une requête SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète → classique prend des minutes. La modélisation de réseau n'est pas optionnelle dès lors que votre volume dépasse quelques centaines de milliers de comptes actifs.

Couche 3 : décisions auditables et gouvernance des alertes

Un régulateur ne vous demande pas seulement si votre modèle détecte bien : il vous demande pourquoi telle transaction a déclenché une alerte et pourquoi telle autre non. La 6e directive AML et les attentes de l'ACPR convergent sur ce point. Chaque décision de scoring doit être accompagnée d'une explication stockée (SHAP values ou équivalent), d'un lien vers les features utilisées au moment de la décision, et d'un horodatage immuable.

C'est ici quela gouvernance des données fintech, consentement, lignage et défendabilité réglementaire, devient opérationnelle. Le lignage de données n'est pas un artefact documentaire : c'est ce qui vous permet de répondre en 48 heures à une demande d'explication de l'ACPR sans mobiliser cinq équipes. Implémentez un catalogue de features avec versioning (Feast, Tecton, ou une solution maison sur dbt) et stockez les snapshots de features utilisés lors de chaque décision dans un entrepôt froid (S3 Glacier, Azure Archive). Le coût de stockage est négligeable comparé au coût d'une incapacité à répondre à un examen.

Pitfalls : comment ce chantier déraille

Le premier écueil est de traiter la fraude et l'AML comme un seul et même problème de modélisation. Ce sont deux disciplines avec des objectifs réglementaires, des temporalités et des seuils d'alerte distincts. Fusionner les pipelines au nom de la simplification produit des alertes mal calibrées dans les deux domaines.

Le deuxième écueil est le taux d'alerte incontrôlé. Un modèle trop sensible inonde votre équipe de compliance de faux positifs. Des fintechs B2C comme N26 ont connu des épisodes publics où la fermeture automatisée de comptes a généré des plaintes massives. Fixez un taux de révision manuelle acceptable (souvent 1 à 3 % du volume d'alertes) et rétro-calibrez vos seuils chaque semaine.

Le troisième écueil est l'absence de test en conditions adversariales. Les fraudeurs s'adaptent. Un modèle entraîné sur des données de 2024 ne voit pas les schémas de fraude apparus en 2026. Planifiez un red-teaming trimestriel avec votre équipe fraud ops : ils connaissent les nouvelles tactiques avant vos données d'

Le parcours complet sur ce secteur :Data dans Fintech.