Concevoir un programme de conformité · Leçon 3 sur 5
La pile technologique de conformité
10 min de lecture
Aucune entreprise du secteur des cryptoactifs ne peut gérer son programme manuellement : les transferts sont réglés en quelques minutes, les clients sont intégrés à distance, et les éléments de preuve se trouvent sur des registres publics et dans les systèmes des partenaires. La pile technologique constitue donc, en pratique, le cadre de contrôle, et ses faiblesses se traduisent par des défaillances de conformité. Cette leçon présente ses composants, explique comment les choisir et les intégrer sans favoriser un fournisseur, et montre comment maîtriser les données et les modèles qu’ils utilisent.
Les éléments constitutifs
Une pile classique comprend six composants. Certaines entreprises les achètent séparément, tandis que d’autres combinent des outils achetés et des solutions développées en interne.
| Composant | Fonction | Défaillance typique |
|---|---|---|
| Vérification d’identité | Vérifications de documents et de données, détection de présence réelle, signaux liés aux appareils, recherches dans les registres des entreprises | Peu efficace contre les hypertrucages ou les identités synthétiques ; couverture insuffisante de certains types de documents |
| Filtrage | Vérification des noms par rapport aux listes de sanctions, aux sources relatives aux PPE et aux médias défavorables ; vérification des adresses de portefeuille par rapport aux entrées de liste | Listes obsolètes, seuils de correspondance définis par habitude, absence de nouveau filtrage en cas de modification des listes |
| Analyse de la chaîne de blocs | Attribution des adresses, catégories de risque, exposition directe et indirecte | Chaînes ou jetons manquants, étiquettes obsolètes, scores inexpliqués |
| Solution Travel Rule | Recherche des EASP contreparties, messages IVMS101, connexions aux protocoles | Incapacité à joindre les contreparties sur d’autres réseaux ; données non conservées avec le transfert |
| Gestion des dossiers | Alertes, enquêtes, décisions, rédaction de rapports, piste d’audit | Décisions en texte libre, absence de lien entre l’alerte et les éléments de preuve |
| Plateforme de données | Regroupement des données clients, des registres, de la chaîne de blocs et des messages ; alimentation de la surveillance et des rapports | Lacunes entre les sources, absence de traçabilité, horodatages incohérents |
Les règles de surveillance des transactions sont généralement exécutées sur la plateforme de données ou dans l’outil d’analyse ou de gestion des dossiers ; quel que soit leur emplacement, elles dépendent des mêmes données. Le rapport du GAFI Opportunities and Challenges of New Technologies for AML/CFT (juillet 2021) et ses Guidance on Digital Identity (mars 2020) décrivent les avantages et les conditions requises : gouvernance, explicabilité et supervision humaine.
Développer, acheter ou combiner
Peu d’entreprises développent tout elles-mêmes ou achètent tout. Le choix dépend de quelques questions :
| Facteur | Favorise l’achat | Favorise le développement interne |
|---|---|---|
| Données de référence | Listes, étiquettes d’attribution et modèles de documents dont la mise à jour nécessite une grande équipe de recherche | Données détenues uniquement par l’entreprise, comme son propre registre et le comportement de ses clients |
| Rapidité | Lancement en quelques mois avec des outils éprouvés | Horizon à long terme, exigences stables |
| Différenciation | Contrôles standard dont chaque EASP a besoin | Scénarios propres aux produits de l’entreprise |
| Compétences | Petite équipe d’ingénierie | Équipe solide de données et d’ingénierie qui restera en place |
Une approche courante consiste à acheter la vérification d’identité, les données de listes, l’attribution analytique et la connectivité à la Travel Rule, tout en développant en interne la plateforme de données, les scénarios de surveillance qui s’appuient sur les données propres à l’entreprise et la logique de décision qui combine tous les signaux. Toute solution développée en interne doit être soumise aux mêmes exigences de documentation, de test et de contrôle des modifications qu’un outil fourni par un prestataire.
Sélection des outils
La sélection doit partir de l’évaluation des risques et du cadre de contrôle, et non d’une démonstration. Répertoriez les contrôles que l’outil doit effectuer, puis évaluez les candidats selon des critères tels que :
- couverture : chaînes, jetons et ponts que vous prenez en charge ou prévoyez de prendre en charge ; sources de listes ; pays et types de documents ;
- précision : taux de faux positifs et de faux négatifs mesurés sur vos propres données ;
- explicabilité : chaque score ou correspondance est-il accompagné de sa justification et de sa source ?
- latence et disponibilité : temps de réponse compatibles avec les vérifications préalables à la transaction, et niveaux de service ;
- configurabilité : seuils, règles et flux de travail que vous pouvez modifier dans le cadre de votre propre processus de contrôle des changements ;
- piste d’audit : historique complet des données d’entrée, des versions, des décisions et des actions des utilisateurs ;
- sécurité et protection des données : rapports d’assurance indépendants, certifications telles que l’ISO/IEC 27001, emplacement des données, chiffrement ;
- sortie : exportation de toutes les données et de l’historique dans un format exploitable en cas de départ.
Une preuve de concept réalisée avec vos propres données constitue la preuve la plus solide. Soumettez à un outil de filtrage des entrées de liste connues comportant des variantes orthographiques, puis observez ce qu’il détecte. Fournissez à deux sources d’analyse les mêmes 500 adresses, y compris vos propres dépôts de test, et mesurez leurs divergences ; celles-ci sont fréquentes et indiquent où une deuxième source ou un examen manuel est nécessaire (pour en savoir plus sur les variations d’attribution, consultez la leçon IDFE-BA Évaluer la qualité des clusters).
Diligence raisonnable à l’égard des fournisseurs et contrats
Un outil qui exécute un contrôle pour votre compte relève d’un accord avec un tiers, et les règles de la leçon Mettre en place la fonction de conformité s’appliquent : l’entreprise reste responsable. La diligence raisonnable porte sur la propriété et la santé financière du fournisseur, sa sécurité et sa résilience, son propre respect des règles relatives aux sanctions et à la protection des données, ses sous-traitants et la provenance de ses données. Pour les données d’analyse et de filtrage, demandez comment les étiquettes et les entrées de liste sont obtenues, à quelle fréquence elles sont mises à jour et comment les erreurs sont corrigées.
Le contrat doit prévoir des droits d’audit et d’accès à l’information, des niveaux de service assortis de mesures correctives, la notification des changements importants apportés aux modèles ou aux sources de données, la notification des violations, la propriété et la restitution des données, ainsi qu’un plan de sortie testé. La concentration est également importante : si une seule panne interrompt à la fois l’intégration des clients, le filtrage et la surveillance, prévoyez une solution de secours.
Intégration et cheminement de la décision
L’emplacement d’un contrôle dans le processus détermine s’il prévient un problème ou se contente de le détecter. Le filtrage des portefeuilles avant transaction et les vérifications Travel Rule doivent avoir lieu avant qu’un retrait soit signé et diffusé ; une fois le transfert inscrit sur la chaîne, il est impossible de l’annuler. Chaque contrôle préventif doit avoir un mode de défaillance défini : blocage en cas d’échec (suspendre la transaction lorsque l’outil est indisponible) pour les vérifications à haut risque, ou ouverture en cas d’échec avec examen ultérieur, uniquement lorsque l’évaluation des risques l’autorise. Autres règles d’intégration : un identifiant client unique partagé par tous les systèmes, des horloges synchronisées en UTC et des tentatives répétées qui ne créent jamais de doublons d’alertes ou de messages. Les changements apportés à la pile, qu’il s’agisse d’une nouvelle chaîne ou d’une mise à jour du modèle d’un fournisseur, doivent être testés dans un environnement hors production et approuvés par la conformité avant leur mise en service, car une intégration défectueuse peut désactiver un contrôle sans que personne ne s’en aperçoive.
Toute décision automatisée doit laisser une trace explicite :
{
"event": "withdrawal_decision",
"withdrawal_id": "WD-2026-0918-00417",
"customer_id": "C-88213",
"asset": "USDC", "amount": "12500.00", "destination": "0xA1b2…9F",
"screening": { "list_match": false, "list_version": "2026-09-18T06:00Z" },
"analytics": { "entity_type": "VASP", "risk_score": 22,
"source": "provider-1", "label_date": "2026-09-02" },
"travel_rule": { "required": true, "protocol": "TRP",
"status": "ACCEPTED", "payload_hash": "e91c…40ab" },
"decision": "RELEASE", "rule_set": "WD-POLICY v4.2",
"decided_at": "2026-09-18T10:42:07Z"
}
L’enregistrement conserve les données d’entrée et leurs versions, et pas uniquement le résultat : la version de la liste utilisée pour le filtrage, la source d’analyse qui a attribué une étiquette à la destination et la date, l’acceptation ou non du message Travel Rule, ainsi que l’ensemble de règles qui a déterminé la décision. Grâce à ces informations, un enquêteur ou un examinateur peut reconstituer des mois plus tard les raisons de la libération du transfert, même après la modification des listes, des étiquettes et des règles. Le hachage prouve quel message a été envoyé sans copier les données personnelles dans chaque journal.
Plateforme de données et traçabilité
La surveillance, les informations de gestion et les rapports destinés aux autorités ne sont fiables que dans la mesure où les données qui les sous-tendent le sont. La traçabilité des données documente la provenance de chaque chiffre et toutes les transformations effectuées. Les Principles for effective risk data aggregation and risk reporting du Comité de Bâle (BCBS 239, janvier 2013), rédigés à l’intention des grandes banques, énoncent des attentes adaptées à toute plateforme de données de conformité : exactitude, exhaustivité, actualité et adaptabilité, dans le cadre d’une gouvernance claire.
Les contrôles pratiques comprennent :
- les rapprochements d’exhaustivité, par exemple la comparaison quotidienne du nombre de retraits dans le registre avec le nombre de retraits soumis au filtrage et à la surveillance ;
- la surveillance des flux de données, avec des alertes lorsqu’une source cesse de fonctionner ou que son volume diminue fortement ;
- un dictionnaire de données et des responsables désignés pour chaque champ critique ;
- un accès fondé sur les rôles, l’enregistrement des personnes ayant consulté ou modifié des enregistrements, et une conservation d’au moins cinq ans ;
- un stockage inviolable pour les décisions et les éléments de preuve.
Un scénario de surveillance qui n’a pas détecté pendant trois mois une nouvelle chaîne est un constat typique ; le rapprochement est le contrôle qui aurait permis de le détecter.
Risque lié aux modèles
De nombreux composants de la pile sont des modèles : algorithmes de correspondance approximative, scores de risque client, scores de risque analytique et classement des alertes par apprentissage automatique. Chacun peut se tromper, devenir obsolète ou être utilisé à mauvais escient. Tenez un inventaire des modèles indiquant leur responsable, leur objectif, leurs données d’entrée, leur version et la date de leur dernière validation ; validez-les avant leur utilisation et périodiquement ; et contrôlez chaque modification. Lorsqu’un enquêteur conteste une étiquette ou un score fourni par un prestataire, le remplacement doit être enregistré avec sa justification et les éléments de preuve, signalé au fournisseur et comptabilisé : une hausse du taux de remplacements indique précocement qu’un modèle n’est peut-être plus adapté à votre activité. Les modèles des fournisseurs restent vos modèles : vous devez disposer d’une documentation et de résultats de test suffisants pour expliquer leurs résultats à un superviseur. Des cadres tels que le NIST AI Risk Management Framework (AI RMF 1.0, janvier 2023) et l’ISO/IEC 42001:2023 sur les systèmes de management de l’intelligence artificielle aident à structurer la gouvernance. Les méthodes de réglage et de validation sont présentées dans la leçon Réglage, métriques et gouvernance des modèles.
Points clés pour l’examen : les six composants de la pile et les défaillances typiques de chacun ; les critères de sélection (couverture, précision, explicabilité, latence, configurabilité, piste d’audit, sécurité, sortie) et leur mise à l’épreuve par une preuve de concept réalisée avec vos propres données ; la diligence raisonnable à l’égard des fournisseurs et les clauses contractuelles, l’entreprise restant responsable ; la raison pour laquelle les contrôles préalables à une transaction doivent être exécutés avant la diffusion, et la différence entre le blocage et l’ouverture en cas d’échec ; le contenu d’un enregistrement de décision qui s’explique de lui-même ; la traçabilité des données, les rapprochements d’exhaustivité et les principes de BCBS 239 ; l’inventaire et la validation des modèles, y compris ceux des fournisseurs.
Questions d’entraînement
Vérifiez votre compréhension. Ces questions ne comptent pas pour l’examen.
Connectez-vous pour enregistrer votre progression et reprendre là où vous vous êtes arrêté. C’est gratuit. Se connecter