Je m’appelle Quentin Coïc et au moment où j’écris ces lignes, je suis Machine Learning Engineer & Data Scientist depuis plus de 5 ans chez Bleckwen, éditeur de logiciel dans le domaine de la prévention de la fraude. Nos produits se démarquent de la concurrence grâce à un usage appuyé de modèles de Machine Learning et de traitement en temps-réel. Ils sont utilisés par les banques pour détecter et prévenir les fraudes, en particulier dans le domaine du financement : crédit, leasing et factoring.
Précédemment, nous avons vu une première technique de mutualisation de connaissance de la fraude le partage de features. Dans ce second article, nous vous proposons d’aborder une autre d’entre elles, les modèles sur étagère. Nous mentionnerons également les pré-requis d’harmonisation nécessaire au bon fonctionnement de toute technique de mutualisation.
Un modèle sur étagère est un modèle prêt à l’emploi entraîné sur des patterns de fraude ou non-fraude extraits de la connaissance mutualisée de l’ensemble des clients d’un même secteur.
Comme pour le partage de features, il est important de s’assurer de la cohérence de la mutualisation. Les clients doivent tout d’abord partager un cas d’usage similaire sans quoi les patterns frauduleux ou non pourraient différer du tout au tout, amenant ainsi à des scores non pertinents. Il faut ensuite veiller à ce que les features du modèle soient cohérentes entre les clients. Là encore, l’utilisation d’un risque sur une zone géographique nécessite de d’assurer de sa transférabilité entre les clients via un référentiel cohérent sur un périmètre comparable, par exemple sur un territoire Français ou Européen, ayant des exigences réglementaires communes.
Comme pour le partage de features, à aucun moment les données de différents clients ne sont mélangées. Seul le modèle, qui ne contient pas de données, mais seulement la connaissance de patterns, est partagé pour scorer les demandes de différents clients. Celui-ci a été entraîné sur des patterns de fraude ou non-fraude acquis de la connaissance mutualisée de l’ensemble des acteurs d’un même secteur, via des features partagées entre autres, qui, comme vu précédemment, ne mélangent pas de données. Là encore, la confidentialité des données de chaque client est donc préservée.
A l’instar du partage de features, un modèle sur étagère peut permettre une meilleure détection de fraude pour chacun des clients du secteur dont il est issu. En effet, la mutualisation de connaissance de la fraude va augmenter le volume et la diversité des patterns auxquels le modèle sera confronté lors de son entraînement. Ceci pourra lui donner un avantage certain sur un modèle ayant été exclusivement confronté aux patterns d’un seul client.
Un modèle sur étagère peut également permettre d’accélérer la mise en place d’un modèle pour un nouveau client du secteur. Ce dernier pourra commencer à éprouver rapidement les performances de détection d’un modèle Bleckwen avant d’évoluer dans le temps vers un modèle sur mesure qui demandera plus d’investissement.
Il faut tout de même être conscient que même si les clients du secteur sont très similaires, il y aura toujours des spécificités que seul un modèle sur mesure pourra capter. Certains patterns spécifiques au nouveau client pourront échapper au modèle sur étagère et au contraire d’autres pourront avoir été appris, mais ne pas être pertinents pour ce même client, perturbant ainsi la détection de fraude chez ce dernier. Un modèle sur étagère bien construit et utilisé à bon escient pourra donc atteindre une part significative des performances d’un modèle sur mesure, mais sera toujours limité pour un nouveau client.
S’assurer de la cohérence des cas d’usage et des features utilisées dans un modèle mutualisé serait vain si le contenu des informations de demande de crédit fournies par les clients ne concordaient pas. Sans cela, les features et par conséquent les scores produits auraient des valeurs biaisées.
Les informations catégorielles doivent se baser sur un référentiel commun. Prenons l’exemple d’un partage du risque du secteur d’activité de l’emprunteur entre deux clients. Le secteur A correspond au code 12 pour le premier client et 23 pour le second. Sans harmonisation, le calcul du risque pour une demande d’un emprunteur du secteur A chez le premier client ne prendrait pas en compte les demandes des emprunteurs de ce même secteur chez le second client et vice versa. Les valeurs de la feature partagée seraient ainsi biaisées.
Les informations textuelles doivent être uniformes. Prenons l’exemple d’un partage du risque du modèle de véhicule demandé entre deux clients. Le problème décrit précédemment se répéterait si les libellés pour un même modèle n’étaient pas semblables. Pour désigner le modèle “DeLorean DMC-12”, un premier client pourrait la libeller “DELOREAN DMC-12” , un second “La DeLorean DMC-12” et un dernier “DMC-12”. Un pré-traitement serait donc nécessaire pour uniformiser ces libellés.
Les informations numériques doivent être au même format. Prenons l’exemple de l’utilisation du chiffre d’affaires de l’entreprise en tant que feature d’un modèle sur étagère. Lors de l’entraînement, ce montant est exprimé en €. Le modèle est ensuite utilisé par un client l’exprimant en k€. Un pattern appris lors de l’entraînement du modèle pourrait contenir une segmentation des demandes selon la valeur du chiffre d’affaires de l’entreprise par rapport à un seuil de 10 000. Une demande chez le client utilisateur avec un montant de 12 serait alors mal segmentée puisqu’exprimé en k€.
Pour nous prémunir de ces problèmes, nous proposons à nos clients des catalogues d’information à fournir selon les cas d’usage. Les définitions des informations du catalogue sont celles attendues pour une éventuelle mutualisation. Le client nous fournit ainsi ses informations les plus proches de celles demandées. Puis, des transformations sont appliquées pour ramener l’information initiale du client au format attendu.
Pour l’exemple du partage du risque du secteur d’activité de l’emprunteur, les référentiels propres à chaque client seraient transposés vers un référentiel commun défini dans le catalogue.
Pour l’exemple du partage du risque du modèle de véhicule demandé, le champ serait pré-traité pour chaque client afin d’être le plus uniforme possible. Entre autres, les libellés pourraient tous être mis en majuscule et sans accent. Les mots courants comme “le”, “la”, “un”, “une” etc… pourraient être retirés. Un référentiel de libellés de modèles de véhicule (amené à évoluer dans le temps) pourrait être construit. Une mesure de distance serait alors calculée entre le libellé d’une demande de crédit du client et chaque libellé du référentiel afin de substituer le libellé de la demande en son alternative la plus proche au sein du référentiel.
Pour l’exemple du chiffre d’affaires de l’entreprise, le catalogue spécifierait l’unité k€ pour cette information et une transformation serait alors appliquée aux clients exprimant ce montant en € afin de le convertir en k€.
Dans ce second article, nous avons pu voir en quoi consiste la technique des modèles sur étagère. Comment celle-ci peut d’abord bénéficier aux performances de détection d’un modèle client grâce à l’augmentation du volume et de la diversité des patterns auxquels le modèle est confronté lors de son entraînement. Puis, comment elle peut accélérer la mise en place d’un modèle Bleckwen chez un client avec déjà un bon niveau de performance avant d’évoluer dans le temps vers un modèle sur mesure. Nous avons également appuyé sur l’importance de l’harmonisation afin de ne pas biaiser un modèle mutualisé.
Dans les prochains articles, nous nous intéresserons à la définition et l’application du protocole mis en place pour mesurer l’apport des techniques de mutualisation de connaissance de la fraude pour nos clients.
Un des enjeux les plus importants pour créer des modèles de détection performants et viables pour nos clients (des organismes de financement tels que le crédit, le leasing et le factoring) est d’obtenir une donnée, qualifiée comme frauduleuse ou non, suffisamment importante en volume et diverse en patterns de fraude ou non-fraude.
En France, les pertes liées à la fraude financière en 2022 sont estimées à +175 millions d’euros. Et les fraudeurs améliorent constamment l'efficacité et la rentabilité de leurs transactions grâce aux technologies (deepfake, Chat GPT, nouveaux modes de paiement, etc). Des solutions concrètes existent pour lutter efficacement contre la fraude.
Résultats prouvés et économies garanties contre la fraude
Sur-mesure pour votre entreprise
Intégration facile et mise en œuvre rapide