Faut-il changer d'outil LBC/FT quand il produit trop d'alertes ?

Pourquoi un outil LBC/FT produit-il trop d'alertes ?

Dans la plupart des cas que nous avons examinés, l'outil n'est pas en cause. Il fonctionne comme on l'a paramétré, avec les données qu'on lui fournit. Les symptômes se ressemblent d'une banque à l'autre : des milliers d'alertes de filtrage à traiter, une surveillance des opérations qui génère surtout du bruit, des analystes débordés. Et des déclarations de soupçon qui naissent plus souvent de la vigilance d'un chargé de clientèle que d'une alerte du système.

La phrase « notre outil ne fonctionne pas » revient alors dans les directions de la conformité, suivie d'une conclusion qui semble évidente : il faut en changer. C'est rarement la bonne première décision.

De quoi dépend la performance d'un outil de filtrage ou de surveillance ?

Elle dépend de quatre éléments extérieurs au logiciel lui-même :

• le paramétrage : seuils, règles de correspondance, listes de sanctions chargées, tolérance de rapprochement des noms ;
• les scénarios activés, les populations de clients auxquelles ils s'appliquent et leurs seuils ;
• les données : complétude et qualité des informations clients et des opérations qui alimentent l'outil ;
• l'organisation du traitement des alertes : qui les traite, selon quelle procédure, avec quel niveau de délégation et dans quel délai.

Des scénarios standards activés sans adaptation au profil de la banque, des seuils jamais revus depuis la mise en production, des fiches clients incomplètes qui empêchent toute segmentation : avec ces paramètres, une nouvelle solution produirait les mêmes résultats que l'ancienne.

Comment relier les scénarios à la classification des risques ?

La surveillance découle de l'analyse des risques LBC/FT de la banque, et non l'inverse. Notre démarche commence donc par la classification des risques : clients, produits, canaux de distribution, zones géographiques.

Chaque scénario est ensuite confronté à cette classification à travers trois questions. Couvre-t-il un risque réellement identifié ? Ses seuils sont-ils calibrés sur les comportements observés dans la clientèle concernée ? Produit-il des alertes utiles, c'est-à-dire qui débouchent sur des analyses approfondies, et parfois sur des déclarations ?

Les scénarios qui ne répondent à aucun risque identifié sont désactivés ou réorientés. Les risques identifiés qu'aucun scénario ne couvre deviennent des priorités de paramétrage.

Quel est le rôle de la connaissance client ?

Elle conditionne tout le reste. Un client dont l'activité déclarée, les revenus ou la nature de la relation ne sont pas renseignés ne peut pas être comparé à un comportement attendu, et l'outil ne peut alors générer que des alertes génériques.

La remédiation du stock de dossiers clients est un chantier à part entière. Nous la conduisons par priorité de risque : clients à risque élevé, personnes politiquement exposées, relations de correspondance, puis le reste du portefeuille. Les processus d'entrée en relation sont revus en même temps, faute de quoi le stock se dégrade à nouveau en quelques mois.

Quelles spécificités pour une banque de la zone UMOA ?

Plusieurs risques sont mal couverts par les scénarios standards, souvent conçus pour d'autres marchés :

• l'usage important des espèces, qui impose des scénarios adaptés aux dépôts et retraits fractionnés et aux versements par des tiers ;
• le mobile money et les agents de transfert d'argent, avec des flux nombreux et de faible montant, et la question de la connaissance du client du client ;
• les relations de correspondance, dont la surveillance conditionne l'accès de la banque aux circuits internationaux ;
• l'exposition à des zones géographiques à risque élevé, qui appelle un filtrage et une vigilance renforcée adaptés.

Ces sujets sont au centre des attentes de la BCEAO et des cellules nationales de traitement du renseignement financier. Ils doivent apparaître dans la classification des risques, puis dans le paramétrage.

Comment organiser le traitement des alertes ?

Un outil bien paramétré reste inefficace si ses alertes sont mal traitées. L'analyse porte donc aussi sur le circuit : répartition des rôles entre agences, analystes de premier niveau et fonction conformité, délais de traitement par type d'alerte, existence d'un stock en souffrance.

Deux points font souvent défaut. Le premier est la documentation des décisions : une alerte classée sans suite doit être motivée pour pouvoir être justifiée lors d'un contrôle. Le second est le chemin qui mène d'une alerte à une analyse approfondie, puis à une déclaration de soupçon. Il doit être formalisé et connu de tous les intervenants.

Nous associons à ce travail les équipes qui utilisent l'outil au quotidien. Elles savent quels scénarios ne produisent que du bruit, quels champs clients restent toujours vides et quels contournements ont été mis en place pour tenir les délais. Leur expérience nourrit directement le diagnostic.

Nous examinons enfin les indicateurs dont dispose la direction de la conformité : taux de faux positifs, délai moyen de traitement, origine des déclarations. Sans eux, l'effet d'une recalibration ne peut pas être démontré.

Quand le remplacement de l'outil se justifie-t-il ?

Lorsque l'analyse démontre que des fonctionnalités nécessaires manquent réellement. Parfois, une revue du paramétrage, des scénarios et de l'organisation suffit à rendre l'outil existant efficace. Parfois, elle met en évidence des limites que seule une autre solution peut lever.

Nous ne représentons aucun éditeur de solution de conformité, ce qui nous permet de poser ce diagnostic sans parti pris. Dans le second cas, la décision de changer d'outil s'appuie sur un cahier des charges construit à partir de l'analyse. La banque sait alors ce qu'elle attend de la nouvelle solution et pourquoi l'ancienne ne pouvait pas le fournir.