Automatiser le contrôle KYC et la vigilance LCB-FT à l'entrée en relation avec n8n

Depuis l'entrée en fonction de l'AMLA (l'autorité européenne de lutte contre le blanchiment, opérationnelle à Francfort depuis 2025) et le paquet réglementaire LCB-FT de 2024, la vigilance à l'entrée en relation ne tolère plus l'approximation : identifier le client, son bénéficiaire effectif, vérifier s'il figure sur une liste de sanctions ou s'il est une personne politiquement exposée (PEP), documenter le tout et pouvoir le justifier à tout moment à l'ACPR ou à Tracfin. Pour une fintech, un cabinet de gestion de patrimoine ou tout organisme assujetti de taille modeste, cette charge tombe souvent sur une ou deux personnes qui jonglent entre un tableur et des recherches manuelles sur les listes officielles — un processus qui ne tient ni la charge, ni la preuve. Une étude de Bakry, Alsharkawy et Farag publiée en 2024 dans le Journal of Supercomputing (« Automatic suppression of false positive alerts in anti-money laundering systems using machine learning », voir sur Google Scholar) rappelle un chiffre qui structure tout le sujet : dans les dispositifs LCB-FT fondés sur des règles simples, l'écrasante majorité des alertes générées sont des faux positifs, qui saturent les équipes de conformité sans jamais correspondre à un risque réel. Un pipeline n8n bien construit ne prétend pas éliminer ce bruit — il le trie, avant qu'il n'atteigne un humain.

Ce que la vigilance LCB-FT impose à l'entrée en relation

Le code monétaire et financier et les lignes directrices de l'ACPR structurent la vigilance client autour de quelques obligations concrètes, quel que soit le secteur assujetti :

• Identifier le client et, le cas échéant, son bénéficiaire effectif : pièce d'identité, statuts pour une personne morale, chaîne de détention capitalistique au-delà d'un seuil de contrôle.
• Cribler contre les listes de sanctions et de gel des avoirs (listes UE, ONU, OFAC selon l'exposition internationale) et identifier un éventuel statut de personne politiquement exposée, qui impose une vigilance renforcée sans interdire la relation.
• Déterminer un profil de risque (faible, standard, renforcé) qui conditionne l'intensité de la vigilance et sa fréquence de révision.
• Documenter chaque étape et chaque décision, y compris les cas où la vigilance renforcée conclut à la poursuite de la relation malgré une correspondance — le silence sur une correspondance non écartée est ce qu'un contrôle sanctionne en priorité.

Pourquoi le criblage automatique change la donne

L'étude citée plus haut porte sur la surveillance des transactions, mais son enseignement se transpose directement au criblage à l'entrée en relation : un système fondé sur des règles rigides (correspondance de nom approximative, sans contexte) génère un volume d'alertes que personne ne peut traiter sérieusement à la main — et c'est précisément quand le volume dépasse la capacité humaine que les vrais positifs se noient dans le bruit. L'automatisation n'a de sens que si elle attaque ce goulot : interroger l'API de criblage systématiquement (au lieu d'une recherche manuelle oubliée un jour de rush), pré-qualifier la correspondance avec le contexte disponible, et ne router vers un humain que ce qui mérite réellement son attention — comme le détaille notre guide de la piste d'audit RGPD avec n8n et Supabase pour la traçabilité qui doit accompagner chaque décision.

Construire le contrôle KYC dans n8n, étape par étape

Le squelette s'appuie sur les mêmes briques que le Pack Conformité & Audit (149 €), adaptées au parcours d'entrée en relation :

1. Collecter l'identité du client et du bénéficiaire effectif avec le bot de questionnaire guidé : identité, statuts, chaîne capitalistique pour une personne morale. Un protocole conversationnel structuré évite les champs manquants qu'un formulaire statique laisse trop souvent filer.
2. Cribler via une API dédiée : un node HTTP Request interroge un service de criblage sanctions et PEP, par exemple l'endpoint /match/default d'OpenSanctions (ou /match/sanctions et /match/peps pour affiner), avec le nom, la date de naissance et le pays du client en entrée. Stockez la clé d'API selon les principes de notre guide pour sécuriser les credentials d'API dans n8n — jamais en clair dans un node Set.
3. Pré-qualifier la correspondance sans trancher seul : un Structured Output Parser en sortie d'un nœud IA structure le score de similarité, le motif de la correspondance (nom, date de naissance, alias) et un résumé lisible, puis un node IF route vers une validation humaine par node Wait dans Slack dès que le score dépasse un seuil bas — mieux vaut trop de revues humaines que pas assez sur ce sujet.
4. Enregistrer la décision dans la piste d'audit avec le workflow d'enregistrement d'audit Supabase : profil de risque retenu, correspondance écartée ou confirmée, nom de la personne qui a tranché, horodatage. C'est cette table, pas un email égaré, qui répond à un contrôleur qui demande pourquoi tel client a été accepté malgré une correspondance partielle.

Cribler en continu, pas seulement à l'entrée en relation

Les listes de sanctions et les statuts PEP évoluent en permanence : un client accepté en janvier peut apparaître sur une liste en juillet, sans qu'aucun événement ne le signale de lui-même. Un Schedule Trigger qui relance périodiquement le criblage sur l'ensemble de la base clients — mensuel pour un profil de risque standard, plus fréquent pour un profil renforcé — ferme cette faille. Le workflow de relances automatiques du même pack identifie les dossiers dont la revue périodique est en retard et notifie la personne responsable ; pour un volume important de clients à recribler, respectez les limites de débit du fournisseur d'API en suivant notre guide du rate limiting des API IA dans n8n, et branchez un Error Workflow pour ne jamais laisser un lot de criblage échouer silencieusement.

Pièges fréquents

• Cribler une seule fois, à l'entrée en relation. Sans rescreening périodique, la vigilance s'arrête le jour où elle devrait justement durer toute la relation d'affaires.
• Laisser un seuil de score trancher seul. Un score de similarité automatique pré-qualifie ; il ne remplace jamais la décision motivée d'une personne habilitée sur un cas ambigu.
• Ne pas documenter les correspondances écartées. Un contrôleur qui retrouve une correspondance non tracée dans le dossier d'un client accepté y voit un manquement, même si la décision de fond était justifiée.
• Sous-estimer la donnée du bénéficiaire effectif. Le criblage du seul représentant légal, sans remonter la chaîne de détention capitalistique, laisse passer exactement le type de montage que la LCB-FT cible.

Pour aller plus loin

Le criblage KYC/LCB-FT partage l'ossature de toute la conformité automatisée avec n8n : protocole conversationnel structuré, piste d'audit Supabase append-only et relances programmées, déjà détaillés pour le registre RGPD des traitements ou la conformité DORA. Le Pack Conformité & Audit (149 €) fournit ces briques prêtes à adapter au parcours d'entrée en relation. Pour les organismes qui traitent des données particulièrement sensibles, notre comparatif n8n self-hosted ou cloud aide à trancher où doit résider l'instance qui manipule ces vérifications ; et si votre équipe conformité reçoit aussi ses alertes réglementaires par email, le Bundle FlowKit Complet (269 €) associe ce pack au Pack Inbox IA (79 €) et au Pack Assistant RAG (119 €).