Les activités criminelles continuent d’exister malgré l’effort mondial considérable de la part de tous les gouvernements pour mettre fin aux activités illégales, telle que le trafic de drogue, le terrorisme ou la corruption. Tant que ces activités criminelles continuent d’exister, le blanchiment d’argent perdurera également, les deux étant étroitement liés. Le but du blanchiment pour les criminels est de rendre légitime l’argent gagné illégalement afin de les intégrer dans le système financier et de pouvoir en profiter.
Selon l’Office on Drugs and Crime des Nations-Unies, entre 2% à 5% du PIB mondial est blanchi chaque année, soit un montant entre 800 milliards et 2 trillions.
La criminalité financière est en évolution constante et utilise les technologies les plus récentes. C’est la raison pour laquelle la conformité réglementaire et la mise en œuvre de dispositifs LAB/FT évolutifs et adaptés reste un défi majeur pour les institutions financières.
Cet objectif doit être atteint tout en conservant un fort niveau de pertinence, car des fausses alertes (des faux-positifs) trop nombreuses génère à la fois un coût financier démesuré
Les outils pour répondre à ces défis sont nombreux. Le progiciel Actimize se positionne comme un leader dans le domaine. Il offre des solutions avancées pour détecter le blanchiment afin de gérer les risques de conformité.
Cet article va présenter les principes fondateurs de ces outils de LAB/FT, mais également traiter de la manière dont les établissements assujettis peuvent les faire évoluer, et la possibilité d’évaluer les impacts de ces évolutions sans devoir modifier ces outils eux-mêmes dans un premier temps.
Parmi ces méthodes d’évaluation et de simulation, nous aborderons notamment l’utilisation de langages comme Java, Python et le PL/SQL.
1. Les solutions LAB
Les institutions financières s’appuient généralement sur des outils proposés par des éditeurs ou d’autres fournisseurs qui interviennent dans le domaine de la LAB/FT. Ceux-ci proposent différents types de solutions.
1.1. Les différents types de solutions
- Les solutions Cloud
Des éditeurs ou RegTech proposent des solutions cloud, qui offrent plusieurs avantages et inconvénients. L’avantage principal est la scalabilité, qui est définit comme la capacité d’un système informatique à s’adapter aux besoins de l’entreprise pour faire face aux évolutions de charge et des besoins.
Les Solutions Cloud offrent également des possibilités de paiement ou en fonction de l’usage. Cela aide à faire des économies en cas de variations des besoins.
L’inconvénient majeur de ces solutions vient des préoccupations liées à la confidentialité des données. La difficulté à migrer plus tard vers d’autres solutions est également un aspect qui peut être problématique.
Bien évidemment, le fournisseur choisi doit être suffisamment résilient pour éviter toute interruption de service. - Les solutions on-premise
Pour éviter les inconvénients des solutions cloud, les banques peuvent utiliser des solutions sur site. Mais ces solutions ne sont pas aussi scalables que les solutions cloud. Il faut bien étudier les besoins avant de prendre une décision concernant la meilleure solution adaptée. Si les besoins en termes de ressources informatiques sont stables, c’est mieux d’opter pour une solution sur-site. Cependant, si les besoins sont fluctuants, dans ce cas une solution cloud va être plus rentable financièrement. - Les solutions Internes
Le coût de la licence des solutions on-premise ou Cloud peut dépasser des centaines de millier d’euros. C’est la raison pour laquelle certaine banque développe leur propre logiciel en interne pour trouver le juste milieu entre les solutions payantes on-premise et les solutions open source.
1.2. Un exemple : AML-SAM Solution
La solution AML-SAM (Anti-Money Laundering – Suspicious Activity Monitoring), est un outil édité par NICE Actimize. Le fonctionnement est le même que pour d’autres éditeurs intervenant sur le domaine de la LAB/FT : l’outil génère une alerte si certaines conditions prédéfinies sont satisfaites. Un score est également calculé et associé à l’alerte, afin de fournir un indicateur sur la gravité estimée de l’alerte aux équipes de la conformité en charge de traiter celle-ci. Le dépassement de seuils, l’écart par rapport aux normes et le niveau de suspicion déjà établi à l’encontre des entités concernées par les alertes sont des facteurs qui sont pris en compte par l’outil pour calculer ce score.
Sur cette base ainsi que les informations rattachées à l’alerte, les analystes AML-SAM (utilisant ACTIMIZE Risk Case Manager) peuvent alors décider si le compte ou/ou le titulaire concerné doit faire l’objet d’une enquête plus approfondie.
Le schéma ci-dessous montre toutes les étapes qui constituent le flux complet de la solution AML-SAM.
La solution AML-SAM est conçue pour traiter et analyser une large gamme de données sources et générer des alertes significatives et ciblées. Les étapes qui composent la solution AML-SAM peuvent être résumées comme suit :
- La solution reçoit des données à partir des sources de données de l’organisation.
- Les règles de filtrage éliminent les données non pertinentes afin de déterminer le scope.
- Les modèles de détection traitent ensuite les données pour générer les alertes.
- Les alertes sont ensuite consolidées pour faciliter le travail des agents de conformité.
Modèles de détection
Une solution de monitoring AML contient plusieurs modèles de détection, chacun d’eux étant basé sur une ou plusieurs règles. Chaque règle monitore un scénario de blanchiment et repose sur un ou plusieurs paramètres, tel que des seuils.
A titre d’illustration, un cas concret pourrait être celui où l’on configure un scénario visant à détecter un client qui fait un virement d’un montant trop élevé par rapport à son profil et son activité commerciale. Dans cette configuration, une alerte sera déclenchée dès lors qu’un mouvement représente plus d’un certain pourcentage de l’activité annuelle ou mensuelle jugée « normale » pour ce client.
Un modèle de détection repose donc typiquement sur 3 éléments :
- Des règles de détection, éventuellement modulée ou définie par niveau de risque,
- Des critères ou seuils de déclenchement
- Un score associé à chaque alerte,
Les règles de détection ou les seuils peuvent être définis différemment pour différents groupes de population, correspondant à différents profils de clientèle.
En effet, les modèles de détection visent à identifier les opérations ou ensemble d’opérations inhabituelles. Afin de déterminer ce qui est habituel, l’agent de conformité sépare les clients en plusieurs groupes, appelés population groups. Chaque groupe contient des clients qui partagent les mêmes caractéristiques, par exemple un chiffre d’affaires annuel comparable. On peut avoir une dizaine et même jusqu’à une centaine de groupes. Chaque groupe aura ainsi ses propres seuils de déclenchement afin de générer des alertes pertinentes par rapport au profil habituel du client.
Fine-Tuning Process
La possibilité de définir des seuils de déclenchement adaptés aux profils des clients répond à un besoin primordial des équipes de conformité : minimiser le nombre de faux positifs, c’est-à-dire des alertes déclenchées alors que leur analyse ne permettra pas de trouver d’éléments confirmant une tentative de blanchiment ou de financement du terrorisme.
En effet, les faux positifs peuvent entraîner une perte de temps pour les agents de conformité, voire à dégrader leur capacité à analyser les alertes les plus crédibles. C’est la raison pour laquelle la conformité est amenée à revoir les seuils afin de minimiser le nombre de faux positifs et améliorer la précision de la détection.
Ce processus est appelé fine-tuning ou ajustement fin ou calibration.
Le fine tuning peut se faire en utilisant différentes approches, voire en les combinant :
- En examinant les transcriptions historiques, on pourrait éventuellement identifier des patterns qui se répètent. On comprend également mieux l’activité de chaque client. Tout cela aide à mettre en place des seuils ou des règles de détection pertinentes.
- En réalisant une analyse statistique. Cela joue un rôle essentiel dans le processus de fine tuning en donnant les statistiques qui permettent de mieux comprendre le profil de chaque client. Les mesures statistiques les plus utilisées pour analyser la tendance et la dispersion des montants et des volumes des transactions historiques sont la moyenne et l’écart type.
Cependant, bien souvent ce fine tuning doit être fait directement dans l’outil de détection, même si c’est dans un environnement dédié comme une plateforme de développement ou de pré-production.
Cette manière de faire présente l’inconvénient de reposer uniquement sur l’outil choisi, et mobilise des personnes disposant des compétences nécessaires et de l’expertise dans l’outil lui-même.
Pour cette raison, certains clients préfèrent avoir un outil développé en interne pour faire ces simulations de fine tuning et estimer leur impact sur le nombre d’alerte et la charge de travail des équipes de la Conformité.
En effet, il peut être plus avantageux de travailler sur les données utilisées par l’outil de détection, mais de mettre en place un « simulateur » dans un autre environnement voire un autre langage qui permettra de mesurer les effets d’un changement de seuil ou la mise en place d’une nouvelle règle.
2. Mise en œuvre d’un simulateur pour optimiser la détection LAB
2.1. Principes généraux
Le simulateur est un système qui reproduit le comportement d’un outil de détection en termes de génération d’alertes, mais qui est mis en œuvre de manière totalement différente.
Il permet de simuler le volume d’alertes dans des conditions prédéfinies sans affecter les environnements d’Actimize (par exemple, des tests pour d’autres évolutions peuvent se poursuivre pendant qu’une simulation est en cours).
Il fournit une estimation précise du nombre d’alertes par modèle en fonction des paramètres définis par l’utilisateur, et peut ainsi mesurer le nombre d’alertes « évitées » ou « supplémentaires » par ces nouveaux paramètres et/ou de nouvelles règles de détection.
En fonction du langage et des technologies utilisées pour construire ce simulateur, il peut être plus simple et plus rapide de tester plusieurs hypothèses de travail, de réaliser un backtesting (en particulier pour s’assurer qu’aucune alerte jugée pertinente ne serait plus générée), et ceci sans mobiliser des experts de l’outil habituel.
Egalement, en fonction des environnements disponibles pour l’outil de détection et de ceux mis en œuvre pour le simulateur, on constate généralement des temps de réponse plus courts en utilisant un simulateur, même sur des environnements moins puissants et moins couteux.
Il est par exemple possible de réaliser un simulateur en utilisant une base MySQL ou posGreSQL, et en faisant les développements en Java ou en Python : il est bien plus aisé de trouver des développeurs maitrisant ces langages de développement que des experts d’une solution telle qu’Actimize.
2.2. Architecture d’un simulateur
Le simulateur est généralement composé de deux modules, front-end et back-end. Le front-end est la partie visuelle de l’application et est dédié à la gestion des écrans et des utilisateurs. Le back-end est la partie non-visuelle de l’application qui est responsable de la gestion des process, des connexions aux bases de données et des appels API.
L’architecture de chaque partie peut être définie séparément :
Pour le front-end, on pourrait choisir l’une des trois frameworks les plus utilisés : Angular, React ou Vue.js. Ces trois frameworks offrent plusieurs fonctionnalités, sont assez flexibles et peuvent répondre aux besoins de différents clients. Comme nous le verrons dans l’étude de cas qui conclut cet article, Angular et sa librairie PrimeNG présentent de nombreux avantages.
Pour le backend, les technologies suivantes nous semble les plus appropriées :
2.3. PL/SQL
L’avantage principale de cette technologie est la rapidité. La nouvelle version d’Oracle 19c offre la possibilité de charger des tables/vues en mémoire du serveur afin d’éliminer des appels entrées/sorties vers le disque dans le but d’optimiser les traitements.
Oracle offre également d’autres possibilités pour optimiser le processus (par exemple un mécanisme de partitionnement et de sous-partitionnement des tables, ou l’indexation, qui permet de localiser facilement des enregistrements dans la table).
De plus, adopter des bonnes pratiques de développement PL/SQL, telles qu’éviter les boucles FOR sur des grosses tables, permet d’avoir un code optimisé. Toutes ces fonctionnalités font d’Oracle la meilleure technologie si l’enjeu premier est la performance et la rapidité.
Tous les avantages cités précédemment viennent cependant avec deux inconvénients : la difficulté à debugger les programmes PL/SQL et la rareté des développeurs PL/SQL compétents.
2.4. Python
Python est un langage facile à apprendre et le déploiement d’un programme écrit en python est facile. Python offre une grande flexibilité et est également apprécié pour sa richesse en bibliothèques et frameworks open source. En effet, le nombre de librairies open source écrit en python dépasse la centaine de milliers !
Le nombre de développeurs python est également assez important. Python est un langage populaire grâce à la facilité de sa syntaxe, ce qui le rend attractif pour les jeunes diplômés. En résumé, il est beaucoup plus facile de trouver des développeurs Python compétents que pour le PL/SQL.
En revanche, ce langage a un inconvénient majeur : c’est un langage interprété et comme tous les langages de ce type, sa performance est moindre que celle de langages compilés ou dont l’interprétation est optimisée, comme le Java par exemple.
2.5. Spark ou Hive
Spark et Hive font partie de l’écosystème Big Data, mais servent des fins différentes et ont une architecture sous-jacente également différente. Voici quelques différences entre les deux frameworks :
1. Usage
- Spark est un Framework du calcul distribué qui fournit une interface pour programmer des clusters entiers avec des données en parallèle et tolérance aux pannes. Spark est connu pour sa rapidité à traiter des données à grande échelle.
- Hive est un framework qui fournit l’infrastructure « Data Warehousing » et qui est construit sur Hadoop. Hive fournit un langage de requêtage, appelé HiveSQL , qui est similaire à SQL et qui permet de requêter les données enregistrés en HDDS ( Système de fichiers distribué Hadoop).
2. Architecture
- Spark enregistre les données en mémoire entre les différents calculs afin d’effectuer des requêtes interactives rapidement.
- Hive est construit sur Hadoop MapReduce et traduit les requêtes HiveSQL en jobs MapReduce qui sont exécutés dans le cluster Hadoop. Ce type d’architecture est moins rapide que Spark pour exécuter les requêtes interactives.
3. Langage de requêtage
- Spark fournit des APIs en plusieurs langages de programmation tel que Python, Scala et Java. Les développeurs peuvent utiliser ces API pour traiter les données. Spark fournit également un module SparkSQL pour exécuter des requêtes SQL sur des données enregistrés en Spark.
- Hive fournit un langage de requêtage HiveSQL qui permet d’exécuter des requêtes SQL sur des données en HDFS.
4. Facilité d’utilisation
- Spark est généralement plus facile que Hive en raison de ses APIs en plusieurs langages de programmation.
- Hive est fait pour les développeurs qui ont des compétences en SQL. Il permet également d’éliminer les complexités de la programmation MapReduce de Hadoop.
5. Performance
- Spark est plus rapide que Hive en raison de ses capacités de lancement de traitements en mémoire. Le moteur d’exécution de Spark permet de lancer des algorithmes itératifs et des requêtes interactives.
- Hive est construit sur Hadoop MapReduce et souffre de la surcharge liée à l’écriture et à la lecture à partir du disque, ce qui le rend plus lent.
2.6. Java
Java est indépendant de la plateforme, ce qui signifie qu’une fois compilé, le programme Java peut être exécuté sur n’importe quel plateforme disposant de la JVM (Java Virtual Machine).
L’écosystème Java est assez riche en librairies et plateformes pour développement web et la connectivité aux bases de données.
Java aide à avoir un code fiable en raison de son typage qui permet de détecter les erreurs au moment de la compilation, en particulier dans les systèmes complexes, où la précision et la fiabilité sont cruciales.
Pour mettre en œuvre la logique de détection du modèle AML, il est recommandé d’appliquer des filtres et des conditions, suivis d’opérations d’agrégation et de tri : Il est fortement déconseillé de recoder ces fonctionnalités en Java à partir de de zéro. Plutôt que de chercher à réinventer la roue, il est préférable d’utiliser une bibliothèque Open Source comme « Apache Commons Collections » qui fournit des fonctionnalités supplémentaires par rapport aux collections standard de Java. Ses classes et ses méthodes sont conçues pour simplifier le processus de manipulation de collections de données en Java.
3. Retours d’expérience
3.1. Python & PL/SQL
Pour l’un de nos clients, qui souhaitait optimiser son dispositif et ses scénarios LAB/FT, nous lui avons proposé de mettre en place un tel simulateur, et l’un des enjeux pour ce clients était de comparer les performances de 2 des langages qu’il utilisait déjà par ailleurs : Python et PL/SQL.
La volumétrie des données était d’à peu près 1 million de lignes.
Ce comparatif a confirmé que PL/SQL est plus rapide que Python. ceci s’explique par le fait qu’Oracle est écrit en C, est un langage compilé, et que c’est le fruit de 50 ans de travail acharné par les meilleurs développeurs et architectes.
Cependant, quand la volumétrie des données dépasse une dizaine de millions de ligne, il faudrait opter pour une solution basée sur du calcul distribué en Python et non pas PL/SQL.
Il y a plusieurs solutions du calcul distribué écrit en Python qu’on peut utiliser comme Dask ou Ray. Ces solutions permettent de traiter des grandes quantités de données de manière efficace et rapide.
En revanche, recourir à une architecture distribuée en Python pour des volumes comme ceux utilisés dans l’étude présente peu d’intérêt par rapport à l’usage de PL/SQL.
3.2. Angular et PrimeNG
Pour un autres de nos clients, nous lui avons proposé d’utiliser Angular/PrimeNG pour la partie Frontend. La partie frontend comprend les éléments visuels (boutons, formulaires, menus, interface utilisateurs etc.).
Angular est un Framework open-source développé et maintenu par Google. PrimeNG est une bibliothèque open-source pour Angular. Elle propose des composants prêts à l’emploi.
PrimeNG permet aux développeurs de créer des interfaces attrayantes sans devoir décrire un code complexe. Le principal avantage de PrimeNG est son équipe d’assistance technique qui donne une réponse dans un délai d’un jour ouvré. L’équipe fait également des releases régulières pour corriger les bugs et ajouter de nouvelles fonctionnalités.
Cette approche de développement « maison » en s’appuyant sur des composants éprouvés a ainsi démontré son intérêt dans la mise en œuvre rapide d’un simulateur permettant également de consulter les alertes.
3.3. Etude Comparative (Spark Vs Oracle)
Les chercheurs de l’université Telkom ont publié une étude comparative de performances entre Spark et Oracle dans le journal International de Visualisation Informatique. Les résultats de cette étude ont montré qu’il y avait des différences dans les temps de traitement des requêtes sur les deux outils. Apache Spark est considéré comme meilleur car il offre un temps de traitement des requêtes relativement plus rapide que la base de données Oracle.
Ils ont également conclu qu’Oracle est plus fiable pour stocker des modèles de données complexes que pour analyser de grands volumes de données.
Le Tableau 1 présente les configurations utilisées pour faire fonctionner Spark et Oracle. En se basant sur le tableau, on peut conclure qu’Oracle nécessite des ressources plus élevées en ce qui concerne son processeur, son stockage, et sa RAM.
Pour tester la scalabilité et détecter les éventuels problèmes de performance, les chercheurs ont réalisé des tests en exécutant différentes requêtes, puis en exécutant une même requête sur des volumes différents. Les résultats en termes de temps d’exécution sont présentés dans les deux tableaux suivants. On observe que Spark est plus rapide et scalable qu’Oracle.
Ce tableau montre le temps de traitement des requêtes sur les deux outils. À ce stade, Apache Spark est supérieur à Oracle.
Ce dernier tableau montre le temps d’exécution de ces requêtes sur trois volumes de données (1K , 10K et 100K enregistrements) : Spark est toujours plus rapide qu’Oracle.
En conclusion…
Nos récentes interventions chez des clients ainsi que l’étude de documents plus théoriques montre que l’usage de solutions du marché pour mettre en œuvre un dispositif LCB/FT reste une solution privilégiée, mais que mettre en place des outils développés en internes pour optimiser ce dispositif et simuler le fonctionnement de la solution du marché présente des avantages certains, en termes de rapidité mais aussi de coûts.
Par ailleurs, comme de tels simulateurs permettent de mesurer les impacts quantitatifs mais aussi qualitatifs des changements envisagés pour un modèle de détection dans le contexte de la LCB/FT, cette approche peut aussi être utilisée avantageusement pour d’autres domaines reposant sur la détection d’alertes, comme la lutte contre la fraude ou les abus de marché.
un article rédigé par…
Alain KHALIL
Consultant Manager au sein de la Practice Risque, Conformité et Réglementaire
