Les dessous de la détection de la fraude chez la Banque Postale et la Société Générale

La naissance de FraudIA

En 2017, le POC d’un système de détection à la fraude à la carte bancaire est mis sur pied. Le projet est renommé FraudIA et mis en production l’année suivante.

FraudIA doit alors être installé auprès de la Banque Postale et de la Société Générale à travers leur joint-venture Transactis.

« La preuve de concept a démontré que les modèles d’intelligence artificielle que nous avions entraînés étaient suffisamment performants pour être déployés en production », explique Mohamad Othman Abdallah, chef de produit et architecte logiciel techlead chez Probayes. « Ce POC reposait en partie sur une base de données PostgreSQL et du code écrit en Python. Mais ces deux technologies ne correspondaient pas aux contraintes du temps réel ».

Cette notion de temps réel est essentielle dans la supervision d’un système transactionnel bancaire. Selon l’observatoire de la sécurité des moyens de paiement de la Banque de France, au premier semestre 2023, la carte bancaire restait « le moyen de paiement le plus fraudé en valeur avec un montant de 256,5 millions d’euros ». En 2022, ce montant s’élevait à 464 millions d’euros, selon les déclarations des établissements auprès de la Banque de France.

« Les indicateurs sont des données agrégées obtenues après calcul. Cela peut être un champ comme un montant, la durée entre la transaction que l’on cherche à évaluer et la transaction actuelle, ou bien la distance entre deux lieux. »

Détecter les fraudes en temps réel demande de calculer des indicateurs. Ces indicateurs sont calculés par des arbres de décision et de boosting de gradient tel XGBoost, un type de modèles de machine learning très populaire. « En données d’entrée, nous avons la demande d’autorisation, des informations sur le porteur (sa date de naissance, son type de carte, son secteur d’activités si c’est une entreprise, etc.) et l’historique des transactions », liste Mohamad Othman Abdallah. « Les indicateurs sont des données agrégées obtenues après calcul. Cela peut être un champ comme un montant, la durée entre la transaction que l’on cherche à évaluer et la transaction actuelle, ou bien la distance entre deux lieux ».

Ces agrégations peuvent concerner la devise, le code de transaction, le type de sécurisation ou encore le nombre de transactions sur les X derniers jours.

« Nous avons des centaines d’indicateurs. Le défi était d’effectuer ces calculs fenêtrés en 50 millisecondes », explique l’architecte logiciel. « Le travail de mes collègues data scientists est de trouver quels sont les meilleurs indicateurs qui permettent d’obtenir de bons résultats ».

L’in-memory, une technologie requise

Ces 50 millisecondes représentent finalement une portion du temps qu’un consommateur doit attendre lorsqu’il effectue un achat, notamment quand il attend la validation de son paiement.

Pour industrialiser la solution, il fallait donc adopter un SGBD in-memory, adapté au calcul rapide des indicateurs, selon Mohamad Othman Abdallah.

RocksDB est un temps considéré. Développé à l’origine par Facebook (Meta), RocksDB est un magasin clé-valeur persistant (NoSQL donc) utilisé par un grand nombre d’éditeurs et d’entreprises. « Or, nous avons compris rapidement qu’il nous fallait une base de données distribuée, qu’il fallait plusieurs nœuds ».

Mohamad Othman Abdallah fait la rencontre d’un représentant de Couchbase lors de Big Data Paris 2017. Intéressé par la base de données in-memory et NoSQL, Probayes effectue alors des tests de charge. « À l’époque, nous avions pour contrainte de traiter 200 transactions par seconde, avec un temps maximum de 50 millisecondes par transaction », se rappelle l’architecte. « Ces tests ont donné des résultats satisfaisants ».

Passer de PostgreSQL à Couchbase réclamait une refonte complète des fondations techniques mise en place lors du POC.

« Nous sommes passés d’un couple PostgreSQL et Python à un autre associant Couchbase et Scala pour la mise en production de la solution, tandis que l’entraînement des modèles est réalisé à l’aide de Scala et Apache Spark », relate Mohamad Othman Abdallah.

Des algorithmes complémentaires des moteurs de règles

L’infrastructure Apache Spark sert à la fois à entraîner et à évaluer les modèles écrits en Scala avant leur mise en production.

« Nous évaluons tous types de transactions à la carte bancaire, les ventes à distance, les retraits aux distributeurs, le paiement chez le commerçant », évoque l’architecte logiciel. « Il y a trois modèles de machine learning. Chacun de ces modèles a ses propres indicateurs », précise-t-il.

« Ces algorithmes ne sont pas figés dans le marbre. […] Les fraudeurs ont souvent une longueur d’avance, il faut s’adapter, réfléchir à de nouveaux indicateurs, les évaluer et livrer les modèles. »

« Ces algorithmes ne sont pas figés dans le marbre. Nous discutons régulièrement avec les responsables de la fraude chez nos clients. Les fraudeurs ont souvent une longueur d’avance, il faut s’adapter, réfléchir à de nouveaux indicateurs, les évaluer et livrer les modèles ».

Les modèles eux-mêmes sont réentraînés à partir de données anonymisées, afin d’être redéployés plusieurs fois par an. Il n’est toutefois pas envisageable d’automatiser la mise à jour des algorithmes à la mode MLOps. « Nos clients métiers doivent être prévenus avant toute modification. FraudIA ne retourne pas un booléen [un 0 ou un 1, N.D.L.R.], mais un score de probabilité sur 100. C’est à la banque de définir un seuil et de l’adapter ». Cela exige de trouver un équilibre entre l’expérience du consommateur et le niveau de sécurité qu’on souhaite lui offrir.

D’autant que la détection de fraudes demande de travailler avec des classes déséquilibrées : en proportion du volume total de transactions bancaires, celles affectées par une fraude représentent une part minime. « Il faut gérer ce déséquilibre à l’entraînement pour produire des modèles pertinents », signale le chef de produit chez Probayes.

FraudIA est donc un complément au moteur de règles déjà en place chez les deux clients principaux. « Au vu du volume de fraudes, plus nous sommes nombreux, mieux c’est », s’exclame Mohamad Othman Abdallah. « La banque peut utiliser le score de FraudIA dans plusieurs règles du moteur et c’est celui-ci qui, en agrégeant les résultats de toutes les règles, donnera la décision finale avant que l’achat se concrétise ».

Une montée en régime inévitable

Jusqu’alors, Probayes et Transactis exploitaient la version communautaire de Couchbase.

En production, des nœuds Couchbase distribués sont déployés via Ansible sur des machines virtuelles, et orchestrés par Docker Swarm. « Nous avons mis en place des services utilitaires, mais il y a deux services essentiels dans notre application : le service qui score (qui reçoit les demandes de traitement) et les nœuds de Couchbase », relate l’architecte logiciel.

Or, depuis 2017, les critères de traitement ont été revus à la hausse. « Nous sommes passés de 200 à plus de 300 transactions par seconde et nous risquons de devoir passer à 450 transactions par seconde », note Mohamad Othman Abdallah. Le système développé par Probayes et déployé par Transactis gère environ 10 millions de transactions par jour.

Les traitements représentent actuellement une dizaine de millisecondes par transaction : Probayes a fait évoluer ses structures de données et profite de certaines fonctionnalités de Couchbase.

« Les achats sur les Internet ne cessent de croître, surtout depuis la pandémie. La solution doit supporter la charge. C’est d’ailleurs pour cela que nous optons pour Couchbase Enterprise ».

Ici, Probayes n’entend pas seulement bénéficier d’un niveau de support supplémentaire de la part de l’éditeur pour ses clients. « La future architecture demandera de déployer un cluster Kubernetes. Et Couchbase sur Kubernetes n’est disponible qu’au travers de sa version entreprise », indique-t-il. « Un opérateur Couchbase va faciliter la tâche des administrateurs de la solution ».

Actuellement, les travaux de maintenance, de mise à jour d’installation des patchs sont principalement réalisés par les DBA et les administrateurs IT de Transactis. « La majorité de ces tâches seront automatisées ».

En dehors de FraudIA, Probayes poursuit ses recherches et travaille notamment sur la lutte contre le blanchiment d’argent.