Système de surveillance des transactions AML

Un système fiable a besoin de tout ce qui suit :

• Des données d'entrée propres. La plupart des échecs de surveillance commencent ici. Un scénario ne peut pas détecter ce qu'il n'a jamais reçu ; l'exhaustivité et le mapping des données comptent donc davantage que le niveau de sophistication de la détection.
• Une configuration qui reflète votre risque. Des scénarios, seuils et segments clients définis selon votre propre évaluation du risque plutôt que selon les réglages par défaut du fournisseur, avec gestion des changements et validation indépendante de chaque modification.
• Une détection qui va au-delà des transactions isolées. Des règles pour les typologies connues, de l'analytique comportementale pour les schémas que les règles ne peuvent pas exprimer et de l'analyse de réseau pour faire émerger les liens entre comptes. Les alertes peuvent aussi provenir de l'extérieur du système, par exemple lorsqu'un résultat de screening déclenche une revue rétrospective de l'activité. Quelle que soit la méthode, vous devez pouvoir expliquer pourquoi une alerte s'est déclenchée.
• La gestion des cas. Une alerte est générée, puis investiguée. Le soupçon est la conclusion d'une investigation, pas son déclencheur.
• Une chaîne d'escalade claire. Les équipes doivent savoir comment faire remonter une préoccupation, et votre MLRO ou responsable conformité doit être la personne qui décide si cela doit aller aux autorités.
• Un reporting adapté à vos marchés. Chaque FIU a son propre format, son propre portail et ses propres délais. Certains régimes exigent une autorisation avant de poursuivre une transaction que vous avez déclarée. Et partout, il est interdit d'informer le client qu'un rapport a été déposé, tout en étant protégé contre la responsabilité lorsque vous déclarez de bonne foi.
• Une piste d'audit et les moyens d'ajuster. Quel scénario s'est déclenché, sur quelles données, qui a examiné le cas, ce qui a été décidé et pourquoi, et qui a approuvé chaque modification. Sans oublier la capacité de tester au-dessus et en dessous de vos seuils pour démontrer que votre calibrage fonctionne.

Il n'existe pas une seule meilleure solution. Les règles sont conçues selon une logique fondée sur le risque ; le bon système dépend donc de ce que vous vendez, à qui vous vendez, où vous opérez et du volume que vous traitez. Ce qui convient à un émetteur de monnaie électronique sur un seul marché ne suffira pas à une activité de paiement multi-juridictionnelle, et ce qu'utilise une banque mondiale écraserait une plateforme de trading plus petite.

Les bons systèmes ont en commun :

• Une détection alignée sur vos typologies, plutôt qu'un modèle générique
• Des alertes explicables, pour que votre analyste puisse dire pourquoi elle s'est déclenchée et que votre enquêteur puisse rédiger quelque chose qui tienne la route
• Des ajustements démontrables, y compris des données de précision des alertes et une méthode documentée pour modifier les seuils
• Une piste d'audit que vous pouvez reconstituer des mois plus tard : la règle, les données, le relecteur, la justification, les validations
• Un timing adapté au contrôle. Le screening des sanctions intervient avant qu'un paiement ne parte. La surveillance comportementale s'exécute généralement par batch ou en quasi temps réel, parce que les schémas pertinents se construisent sur plusieurs jours et comptes. La décision en temps réel a sa place lorsque vous devez bloquer des fonds avant le règlement sur des rails instantanés, mais c'est une décision commerciale et de tolérance au risque. Ce que les régulateurs demandent, c'est un signalement rapide dès qu'un soupçon se forme.
• Un reporting adapté à chaque marché où vous déposez. Les délais varient fortement. Certains régimes imposent une déclaration dans la journée où le soupçon est formé et limitent la durée de la revue interne qui y mène. D'autres accordent un mois ou davantage à partir du moment de la détection. Certains superviseurs ajoutent une fenêtre attendue entre l'alerte et le dépôt, en plus de l'obligation légale de déclarer sans délai. Un paramétrage mondial unique enfreindra les exigences les plus strictes.

Évaluez les fournisseurs selon les critères suivants :

• Couverture et configurabilité. Quelles typologies couvre-t-il pour votre secteur et vos marchés ? Recherchez une bibliothèque de scénarios à partir de laquelle vous pouvez démarrer puis ajuster selon votre propre évaluation du risque.
• Explicabilité et supervision humaine. Un analyste peut-il voir pourquoi une alerte a été déclenchée ? Lorsque du machine learning est utilisé, le résultat peut-il être expliqué à un régulateur ? Le système priorise le travail. Ce sont les personnes qui décident.
• Qualité des alertes. Demandez des données de précision, pas des chiffres de débit. Votre vraie contrainte est le volume d'alertes par rapport à la capacité des analystes, pas le nombre de transactions traitées.
• Tests avant la mise en production. Pouvez-vous backtester de nouveaux scénarios sur des données historiques et simuler le volume d'alertes qu'un changement de seuil produirait ? C'est ce qui rend l'ajustement démontrable.
• Ce que le système sait de vos clients. La surveillance fonctionne bien mieux lorsqu'elle s'appuie sur vos données d'onboarding et de risque client, de sorte que l'activité est jugée à l'aune de ce que vous savez déjà plutôt qu'isolément.
• Opération multi-marché. Des workflows de reporting et des délais configurables par marché, la prise en charge des formats et portails locaux, la gestion des langues locales et différents ensembles de règles pour différentes entités sans exploiter des systèmes séparés.
• Résidence et conservation des données. Où les données sont-elles traitées et stockées, et cela répond-il aux exigences locales de protection et de localisation des données sur chaque marché ? La base FATF est de cinq ans pour les données de transaction et client, et plusieurs juridictions exigent davantage ; la conservation doit donc être configurable et non figée.
• Des contrôles pré-transaction correctement décrits. Les contrôles en temps réel peuvent retenir ou refuser un paiement. Ils ne peuvent pas empêcher le soupçon, qui est une appréciation humaine. Lorsqu'un paiement est bloqué pour soupçon de blanchiment, le droit local décide de la suite, et dans plusieurs juridictions vous avez besoin d'une autorisation avant de poursuivre. Les restrictions sur ce que vous pouvez dire au client s'appliquent tout au long du processus. Un outil doit soutenir ce workflow, pas prétendre l'éliminer.
• La mise en production. Les délais d'implémentation, la migration depuis votre système existant et la possibilité de faire tourner les deux en parallèle assez longtemps pour comparer les résultats avant de basculer.
• Le fournisseur lui-même. Sa viabilité, son modèle de support, ses niveaux de service et la direction prise par le produit. Vous achetez une relation qui doit survivre à vos prochains audits, pas seulement un logiciel.