Scénarios LCB-FT des institutions financières : actions immédiates et préparatifs pour demain

1. L’efficacité des dispositifs et des outils qui sont déployés reste insuffisante 

Un système de détection de lutte contre le blanchiment des capitaux et le financement du terrorisme (LCB-FT) est actif en amont et en aval des opérations. Nous traitons ici uniquement de la détection des opérations atypiques a posteriori (un autre article est à venir sur la détection a priori).

La détection a posteriori est désormais largement automatisée compte tenu de la volumétrie des opérations à surveiller. Pour autant, l’efficacité des outils de détection et des dispositifs déployés reste encore insuffisante. Et cela pour plusieurs raisons : le fréquent manque de visibilité des Compliance Officers sur le fonctionnement technique de ces outils ; des scénarios datés, mal conçus ou mal calibrés, entraînant un nombre d’alertes à traiter trop élevé et trop peu pertinent au regard des examens renforcés et des déclarations de soupçons (DS) qui en découleront effectivement ; et enfin, un traitement des alertes pas assez agile et réactif.

2. Cinq actions immédiates pour améliorer la détection automatisée et passer d’un fonctionnement déterministe à un processus piloté

• Se réapproprier les outils de surveillance
• Challenger les scénarios de détection
• Optimiser le taux de transformation « alerte – DS »
• Assurer la traçabilité et la productivité du traitement des alertes
• S’appuyer sur des tableaux de bord pour un meilleur suivi
   

Se réapproprier les outils de surveillance   

Le fonctionnement et le paramétrage des outils de surveillance apparaissent fréquemment comme une « boîte noire » pour les équipes Conformité. Leur configuration technique est peu connue et insuffisamment compréhensible par les utilisateurs (Compliance Officers, analystes LCB-FT, contrôle interne…). Par exemple, en l’absence de documentation fonctionnelle précise concernant les spécifications des scénarios, les équipes Conformité peuvent rester à l’écart du dispositif si elles n’ont pas participé initialement à sa conception et/ou ne sont pas impliquées dans sa revue régulière.

Ainsi, une bonne pratique consiste, pour les équipes Conformité à réaliser des tests fonctionnels complets en étroite coordination avec les équipes techniques, afin d’homologuer les outils. Des dysfonctionnements peuvent être identifiés dans les différentes étapes de la chaine de détection (voir le schéma ci-dessous). Les actions correctrices peuvent ainsi être engagées par les équipes Conformité/les opérationnels ou par les équipes techniques (SI, éditeur…) et la documentation fonctionnelle mise à jour.

Exemple de dysfonctionnements constatés dans la chaine de détection

Challenger les scénarios de détection

Les institutions financières s’équipent d’outils spécialisés en surveillance des opérations LCB-FT depuis plus d’une décennie. A défaut de réaliser les montées de version pour profiter des nouvelles fonctionnalités ou des nouveaux scénarios, les organismes choisissent trop souvent de conserver les anciennes versions des outils, à la suite d’arbitrages sur les priorités, ou des problématiques liées aux infrastructures techniques sous-jacentes aux outils.
Les scénarios de détection mis en place à partir des typologies de blanchiment connues au moment du déploiement d’un outil peuvent devenir rapidement obsolètes, alors que le périmètre de contrôle LCB-FT évolue en permanence (changements réglementaires, modification de l’exposition aux risques, nouveaux circuits illicites).

La revue régulière des scenarios est ainsi un impératif.

Un premier travail consiste à intégrer les nouvelles typologies de blanchiment, via une analyse interne des opérations atypiques observées, ou à travers une veille externe (lignes directrices, rapports issus des autorités de contrôles, rapports de sanction, bonnes pratiques de Place…).

Un second travail consiste à sérier régulièrement, et a minima chaque année, les déclarations de soupçon (DS) réalisées. Cette analyse permet d’identifier les opportunités d’automatisation de la détection de certaines typologies qui ont fait l’objet à plusieurs reprises de DS. Les nouvelles typologies peuvent être évaluées régulièrement, a minima annuellement, afin d’étudier la pertinence d’intégration dans les outils de surveillance (évolution des scénarios existants ou création de nouveaux scénarios), et d’effectuer des « Proof of Concept » sur la surveillance de ces nouvelles typologies afin d’anticiper et préparer un passage en production.

Exemple de démarche pour la revue de scénarios

Optimiser le taux de transformation « alerte – DS »

Ce n’est pas nouveau mais ce n’est toujours pas résolu. Les taux de transformation « alerte – DS » sont très bas, autour de 1% à 5%, et plus souvent proches de 2%. En analysant l’ensemble des DS et leurs canaux de remontée d’information, il s’avère en général que les cas identifiés par les scénarios ne représentent qu’une fraction de toutes les DS transmises par les organismes. La réduction du nombre de « faux positifs » via une plus grande pertinence des alertes devient une priorité pour les Compliance Officers.

Ces difficultés découlent souvent de règles de détection qui ne visent pas spécifiquement les comportements atypiques mais peuvent, par simplification, générer des alertes à partir du simple montant d’opérations (par exemple en assurance vie, un seuil unique de montant cumulé des versements libres pour toute la clientèle ne permet pas d’identifier des comportements atypiques au regard du profil du client ; de même montant seul pour identifier une renonciation suspecte n’est pas suffisant). 

L’amélioration du dispositif passe, dans un premier temps, par la combinaison de plusieurs règles de détection (opérations entrantes et sortantes, fréquence etc.) afin de cibler les véritables comportements atypiques : par exemple, en intégrant la fréquence des rotations des capitaux, ou un changement de RIB suivi d’un ou de plusieurs rachats sur un contrat d’assurance vie, ou encore dans la banque un remboursement anticipé d’un crédit de manière rapprochée après octroi... Ensuite, et il s’agit de l’élément le plus important, il convient d’intégrer les spécificités du client (son profil) dans la règle de détection. C’est possible en enrichissant et en utilisant mieux les données de connaissance de la clientèle (Know your Customer, KYC). Par exemple les revenus ou le patrimoine pour les risques de blanchiment ou de fraude fiscale, les informations géographiques pour les risques de financement du terrorisme ou de fraude fiscale (cf. Rapports d’activité et rapports d’analyse de Tracfin 2019 et 2020), ou encore d’autre types d’opérations non financières comme le changement d’adresse/coordonnées bancaires, le changement de bénéficiaire pour l’abus de faiblesse ou la fraude externe. 

La méthode et les outils Data Analytics permettent aux équipes Conformité de visualiser le comportement global de l’ensemble de ses clients et d’identifier la position des comportements issus des DS (avec les profils des clients) parmi l’ensemble des opérations réalisées. 

Prenons l’exemple assurantiel illustré ci-dessous : tous les versements exceptionnels réalisés sur un an sont présentés dans le graphique avec un point. En appliquant les autres règles de détection (ratio de la rotation des capitaux) et les seuils actuellement définis, seuls les points en rouges représentent des alertes générées par le scénario. De l’autre côté, nous visualisons tous les cas de DS identifiés pendant la période (en noir). L’interprétation graphique des opérations donne une meilleure visibilité aux Compliance Officers sur les comportements des clients de son établissement, et la possibilité de confirmer la pertinence des scénarios ou d’ajuster les paramétrages pour optimiser la détection.

Illustration d’une simulation du scénario avec Data Analytics et de l’objectif d’optimisation du taux de transformation 

Assurer la traçabilité et la productivité du traitement des alertes

La traçabilité de toutes les étapes du traitement des alertes est primordiale pour la Conformité. Cela peut être demandé par une autorité de supervision mais c’est surtout nécessaire pour mesurer l’efficacité des scénarios. Face à une volumétrie importante d’alertes à traiter, les analystes LCB-FT, bien souvent, ne disposent pas du temps nécessaire pour correctement retracer les analyses et les motifs de clôture dans les outils. En amont, le workflow (schéma de traitement) doit être correctement paramétré : par exemple, il peut parfois manquer la possibilité d’attribuer des statuts intermédiaires pour distinguer les dossiers complexes en attente d’informations supplémentaires, des dossiers non traités ; la gestion des dossiers ne permet pas toujours un traitement homogène des alertes sur le même client ou le groupement de plusieurs personnes liées à un même client. L’amélioration ou la correction de ces schémas de traitement peut passer par la catégorisation des motifs de clôture et la prédéfinition dans l’outil de ceux le plus souvent utilisés. 

Les équipes Conformité peuvent également s’appuyer sur les nouvelles technologies relativement aisées à mettre en œuvre pour le traitement des alertes. Par exemple, le Machine Learning, si elle n’autorise pas de clôturer les alertes à la place des analystes, permet de prioriser les alertes selon différents niveaux de complexité et gagner ainsi en productivité et sécurité des analyses. Les alertes similaires à celles ayant généré historiquement des examens renforcés ou des DS sont priorisées et proposées pour traitement par des analystes expérimentés, tandis que les alertes similaires à celles clôturées sans suite, peuvent être traitées par les profils plus juniors. 

Exemple de la priorisation des traitements des alertes par Machine Learning 
 

Des tableaux de bord de pilotage pour un meilleur suivi

Montrer aux autorités de contrôle que la fonction Conformité s’assure régulièrement de l’efficacité des scénarios est plus difficile en l’absence de tableaux de bord dédiés. Une série d’indicateurs semblent incontournables (avec une production régulière, par exemple 2 fois par mois). Par exemple :

• Taux de transformation des alertes - examens renforcés - DS par scénario (nombre des alertes / Examen Renforcé (ER) /Déclaration de Soupçons (DS) par scénario)
• Délai de traitement des alertes par étape (opération suspecte – détection – ER – DS)
• Suivi du traitement (analyse des changements de statuts et des stocks par statuts…) et l’évolution du stock
• Remontée des alertes/typologies très risquées nécessitant une priorisation
• Remontée des incidents techniques des outils
• Date de mise à jour des critères de détection utilisés dans les scénarios (par scénario)
• …

L’ensemble de ces actions sur les dispositifs en place, immédiatement réalisables, permettent aux institutions financières d’engranger des gains rapides en termes d’efficacité dans la détection des opérations atypiques, et de démontrer que le dispositif est piloté, dans une logique d’amélioration continue.
 

3. Et comment préparer demain ? 

Faire aboutir l’architecture data centric

Faire évoluer les dispositifs de détection vers une architecture data centric (architecture décloisonnant l'ensemble des systèmes d’information) n’est pas une idée nouvelle, mais commence à être déployée par un nombre croissant d’institutions. Cette évolution passe par le recensement et la mise en commun de toutes les données disponibles, internes et externes, depuis l’entrée en relation, jusqu’à la surveillance des opérations en cours de vie, au-delà des données actuellement utilisées pour les outils de marché. Les données consolidées dans une base centrale sont plus complètes et robustes pour une vision 360 du comportement du client et permettent de mieux identifier la chaine complète des opérations suspectes.

En s’affranchissant ainsi des solutions historiques de marché, une architecture centrée sur la donnée offre des opportunités d’ajouter rapidement des scénarios LCB-FT dans le dispositif de détection. Elle permet à l’organisme de s’appuyer sur les nouvelles technologies telles que l’IA ou RPA. Sans contrainte de compatibilité technologique imposée par les éditeurs, les équipes Conformité peuvent définir et mettre en place les algorithmes de détection de manière agile et personnaliser les fonctionnalités selon les besoins. Une architecture centrée sur la donnée permet également aux acteurs d’intégrer des informations externes dans leurs dispositifs afin d’enrichir les scénarios. Lorsque les équipes Conformité participent activement aux projets sur les données, elles renforcent leur compréhension de ces données et la maitrise du dispositif de surveillance dans son ensemble.

Cette architecture permet aussi d’enrichir la détection, en complément des scénarios, en analysant directement les données « à la recherche d’atypisme » ou en détectant des signaux faibles. Les résultats de ces analyses pourront, à leur tour, alimenter de futurs scénarios de détection.

Fiabiliser les données clients et opérations

Comme évoqué plus haut, l’intégration de nouvelles données est indispensable pour améliorer l’efficacité de la détection. Cependant, il faut s’assurer de la qualité de celles-ci. L’exemple des données revenus/patrimoine est très parlant. Pour un même client, le revenu peut ne pas apparaitre dans la fiche client ou plusieurs revenus peuvent apparaitre correspondant à des informations collectées lors de la souscription de différents produits via différents réseaux… Si cette information est intégrée comme facteur dans un scénario, sa fiabilité doit être assurée. La récupération des données via les sources externes et fiables peut également être une option pour les institutions afin de compléter la connaissance de leurs clients.

Mettre en place une détection pluriactivité et multi-objectifs

Par exemple dans un groupe de bancassurance ou d’assurbanque (qui cumulent des opérations bancaires et des opérations d’assurance) ou chez des acteurs multi-activités (banque de détail et entreprise, leasing, crédit conso ; un assureur ou une mutuelle multibranche vie et non-vie), la détection ne devrait plus être organisée en silos par activités. Par exemple, en assurance-vie il est nécessaire de pouvoir détecter un rachat suivi de retraits d’espèces (risque de financement du terrorisme) ou des virements vers un tiers sans lien avec l’assuré (risque d’abus de faiblesse) et ces opérations, lorsqu’elles sont de faibles montants, ne peuvent être détectées que si les opérations bancaires et assurantielles sont analysées ensemble. Il en est de même concernant la détection d’un ou plusieurs versements de faible montant sur un contrat d’assurance-vie associés à des indemnisations multiples sur des contrats d’assurance non-vie qui peuvent témoigner d’une volonté de fraude et de blanchiment. Cette détection pluriactivité repose également sur la qualité et la vitesse des échanges d’information entre activités ou équipes différentes.

Concernant la détection multi-objectifs, il existe une tendance à rapprocher la détection de BC-FT avec la fraude fiscale, la fraude externe (notamment pour IARD) et voire la cybersécurité (l’analyse du dark web permet de mieux connaître certaines fraudes et d’anticiper / découvrir des typologies de blanchiment par exemple). Cette tendance impacte les équipes, les outils et les compétences à mobiliser… Dans le secteur de l’assurance où, d’après TRACFIN, le nombre de DS « non-vie » est désormais équivalent au nombre de DS « Vie », le dispositif doit prendre en compte le fait que des clients peut entrer en relation par un simple contrat IARD et basculer ensuite sur des investissements massifs en Epargne.

Être agile et proactif

Il faut détecter (et traiter) plus vite et adapter les systèmes de détection plus rapidement à l’évolution des typologies de blanchiment et autres atypismes. L’analyse régulière de la qualité de la détection, combinée aux travaux du contrôle interne doivent permettre d’identifier les faiblesses et d’élaborer des actions de remédiation. Les nouvelles typologies de risques générées par l’environnement (par exemple la fraude dans le contexte de la crise sanitaire ou les risques émergents en matière de terrorisme) demandent une réaction quasi-immédiate de la part des acteurs. Les outils doivent permettre une mise à jour rapide (la création d’un scénario doit pouvoir être une affaire de jours et le nombre d’alertes doit pouvoir être testé et simulé à partir de données de production).
 

Les limites actuellement observées en matière de surveillance et de détection des opérations suspectes pourront être dépassées en passant d’un modèle déterministe à une approche agile et proactive s’appuyant sur l’ensemble des données disponibles, internes et externes. Les dispositifs doivent être orientés « résultats » sur cette mission confiée par la société civile aux établissements financiers : participer à la lutte contre la criminalité ! L’évolution récente des outils et technologies centrés sur les données offrent des opportunités à portée de main de l’ensemble des banques et des organismes d’assurance.