‍

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.

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.

Plusieurs facteurs peuvent complexifier cette tâche :

• Le crédit est un type de transaction bancaire relativement restreint en terme de volume.
• La donnée qualifiée disponible peut être d’autant plus limitée par un processus de qualification en développement chez certains organismes en quête de nouveaux marchés.
• La diversité des données de chaque organisme est par essence limitée. La donnée d’une institution ne peut refléter que les patterns qu’elle contient et un modèle construit à partir de cette donnée sera avant tout efficace pour détecter ces dits patterns. Cela est d’autant plus problématique dans un contexte où les patterns de fraude sont de plus en plus nombreux, évoluent de plus en plus vite et sont de plus en plus sophistiqués.
• Certains organismes souhaitent d’abord éprouver la performance de nos modèles rapidement, dans leur contexte, avant d’investir plus de temps et d’effort pour fournir un volume suffisamment important de données qualifiées.

Avec maintenant plusieurs clients partageant des cas d’usage similaires, les techniques de mutualisation de connaissance de la fraude entre clients, telles que le partage de features ou les modèles sur étagère, semblent prometteuses pour adresser cette problématique.

Afin de nous assurer de l’apport de ces techniques pour nos clients, nous avons menés plusieurs expérimentations. Nous aborderons donc dans cette série d’articles, les techniques de partage de features et de modèles sur étagère, ainsi que le protocole que nous avons mis en place pour tester si celles-ci apportent bel et bien un bénéfice significatif à nos clients.

Dans les deux premiers articles, nous décrirons et illustrerons les techniques de partage de features et de modèles sur étagère, ainsi que ce qu’elles requièrent pour être appliquées.

L’article suivant présentera le protocole que nous avons mis en place pour mesurer l’efficacité ou non des techniques testées.

Enfin, dans un dernier article, nous aborderons l’application de ce protocole aux techniques de mutualisation de données essayées, ainsi que les conclusions que nous en avons tirées.

‍

Fonctionnement d’un modèle de Machine Learning en temps réel

Avant de pouvoir aborder le partage de features, il nous faut d’abord expliciter le fonctionnement d’un modèle de Machine Learning pour la prévention de la fraude en temps réel.

Le but d’un tel modèle est de scorer chaque nouvelle demande de crédit en temps réel (i.e. au moment où celle-ci est soumise) entre 0 et 100. Plus le score est proche de 100, plus le modèle considère élevée la probabilité que la demande soit frauduleuse et inversement.

Un seuil est défini (e.g. 90) afin de lever des alertes pour les demandes de crédit que le modèle considère comme les plus à risque de fraude. Celles-ci pourront ainsi être revues par des analystes spécialisés dans la prévention de la fraude.

Features

Pour que le modèle puisse scorer une demande de crédit, un ensemble de features doit d’abord être calculé. Une feature est le résultat d’un calcul effectué à partir des informations mis à disposition sur les demandes de crédit. Ce résultat doit être numérique comme un montant, un compte, un pourcentage ou un booléen (i.e. vrai ou faux).

Les features peuvent être divisées en deux types selon le procédé du calcul, les features sans état et celles avec état.

Features sans état

Une features sans état n’a besoin que des informations de la demande de crédit à scorer. Cela peut être directement la valeur d’un champ comme le montant de la demande de crédit ou dérivé d’un ou plusieurs champs comme un booléen pour savoir si l’emprunteur travaille dans le secteur d’activité A ou encore un ratio entre l’apport et le montant de la demande.

Features avec état

Une feature avec état a besoin d’informations provenant de demandes de crédit passées pour être calculée. Un état est un agrégat (e.g. un compte ou une moyenne) d’informations provenant de demandes de crédit passées. Par exemple, le compte du nombre de demandes de crédit ou de fraudes dans les concessions du département X sur les 6 derniers mois. Une feature avec état est le résultat d’un calcul effectué à partir d’un ou plusieurs états.

‍

‍

Voici 3 grandes catégories de features avec état.

Features temporelles

Une feature temporelle donne pour résultat une durée calculée entre la demande de crédit à scorer et une demande de crédit passée.

Exemple : Le nombre de jour depuis la première demande de cette entreprise.

Features de risque

Une feature de risque évalue le risque de fraude pour une catégorie à laquelle appartient la demande de crédit à scorer sur une fenêtre de temps dans le passé.

Exemple :

‍

Features comportementales

Une feature comportementale évalue la déviation d’une information numérique de la demande de crédit à scorer par rapport à une valeur de référence pour une catégorie à laquelle appartient cette même demande sur une fenêtre de temps dans le passé.

Exemple :

‍

Entraînement et scoring

Une fois les features de la nouvelle demande de crédit calculées, celle-ci peut être scorée par le modèle. Pour cela, ce dernier a été entraîné à reconnaître des patterns frauduleux ou non en identifiant des liens plus ou moins complexes entre les valeurs des features calculées sur des demandes de crédit passées et leur qualification (fraude ou non-fraude). C’est cet entraînement qui permet au modèle de donner un score de fraude pour une nouvelle demande de crédit en fonction des valeurs des features que cette dernière obtient par rapport aux patterns que le modèle a appris.

‍

Le partage de features

Le partage de features est une technique qui permet une meilleure connaissance des indicateurs de fraude. Cette technique permet de calculer des features communes à un ou plusieurs clients ayant des caractéristiques similaires, le tout dans un cadre sécurisé. 

La cohérence avant tout

Il est primordial de s’assurer de la cohérence du partage.

Tout d'abord, les clients doivent partager un cas d’usage similaire. Partager le risque du secteur d’activité de l’emprunteur entre une institution proposant des crédits auto et une autre proposant des crédits renouvelables n’aurait pas forcément de sens. Les cas d’usage étant différents, les profils de fraudeurs et patterns qui en découlent ne seraient pas forcément cohérents. Le secteur d’activité A pourrait très bien ressortir comme à risque dans le cadre des crédits renouvelables, mais pas du tout dans celui des crédits auto. Le modèle pourrait donc être induit en erreur par un tel partage.

Il faut ensuite veiller à ce que les features partagées soient cohérentes entre les clients. Partager un risque sur une zone géographique, doit se faire dans 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.

Partage d’états, pas de données

Le partage de features ne s’applique qu’aux features nécessitant des informations de demandes de crédit passées pour leur calcul, donc aux features avec état. A noter que pour le calcul d’une feature partagée, seuls les états requis dans le calcul ont pour nécessité d’être partagés entre les clients. A aucun moment les données de différents clients ne sont mélangées. Par exemple, pour partager le risque des concessions du département X sur les 6 derniers mois, seuls les comptes, de demandes de crédit et de fraudes concernant des concessions du département X sur les 6 derniers mois notamment, sont utilisés. Cela ne requiert pas de mélanger les données, permettant ainsi de préserver la confidentialité des données de chaque client.

Partager pour mieux cibler

Dès lors que le partage est cohérent, cette technique permet de rendre le calcul d’une feature à état plus représentatif, facilitant ainsi l’identification de patterns frauduleux ou non par le modèle, ainsi que leur variété et donc la détection de potentielles fraudes.

Par exemple, dans le cas du nombre de jour depuis la première demande de cette entreprise, celle-ci pourrait très bien avoir effectué sa première demande il y a deux mois chez une institution, mais il y a deux ans chez une autre, ce qui donnerait une autre perspective de la récence de cette entreprise une fois placée dans le système globalisé constitué par les clients mutualisés.

Dans le cas du risque de la zone géographique du concessionnaire, une attaque (i.e. une série de tentatives de fraude) pourrait avoir été effectuée dans le département X le mois dernier parmi les demandes de crédit d’une institution, mais pas pour une autre. Cette attaque pourrait très bien arriver chez cette seconde institution le mois prochain. La valeur de la feature partagée à la hausse grâce aux données du premier client pourrait alors permettre une meilleure détection de cette éventuelle attaque à venir.

‍

Pour le cas de la déviation du salaire déclaré par l’emprunteur par rapport à la valeur de référence pour les employés du secteur A, cette valeur de référence pourra être calculée de manière plus représentative dans le cadre d’un partage où plus de données sont à disposition. Cela est donc particulièrement intéressant pour les clients disposant de peu de données. Ceci est également valable pour le calcul d’une feature de risque (i.e. plus de données permettent un calcul plus représentatif de la proportion de fraude d’une catégorie). La valeur de référence étant plus représentative, la déviation calculée sera alors également plus représentative.

‍

‍

Conclusion

Dans ce premier article, nous avons pu voir en quoi consiste la technique de partage de features et comment celles-ci peuvent bénéficier aux performances de détection d’un modèle client grâce à un calcul plus représentatif des features avec état via l’augmentation du volume et de la diversité des données utilisées.

Dans le prochain article de cette série, nous nous intéresserons aux modèles sur étagère ainsi qu’aux pré-requis des techniques de mutualisation de connaissance de la fraude avant d’aborder le protocole mis en place pour mesurer l’apport de ces techniques pour nos clients.

‍