Le réglage fin des paramètres de stockage des données pour les mises à jour de modèles dans la détection des fraudes

 

 

 

 

Bonjour à tous,


Je vais vous présenter mon stage chez XYZ SAS à Strasbourg. Le sujet de mon stage est le réglage fin des paramètres de stockage des données pour les mises à jour de modèles dans la détection des fraudes. D’abord, je vais présenter l’introduction comme le contexte du projet et le profil d’entreprise. Ensuite, la mission que j’ai effectué comme la transaction stocké, étiquetage dynamique, comment gérer de haut risques et de modèle a jour, je vais les expliquer dans la section travail proposé. La section suivante est les performances et les résultats. Ici, on vas voir les performances de modèles. Et a la fin, la conclusion.

 

INTRODUCTION

On vas commencer par l’introduction. Comme vous le savez que, Le commerce en ligne en France est en augmentation. Environ de 14 % des paiements sont faites en ligne par carte bancaire, et ces payements sont responsable pour 70 % des fraudes. Cette situation justifie l’utilisation de dispositifs de paiement d’authentification renforcée, tel que le 3D-Secure (3DS). Mais, ce système conduit à environ 16 % de taux d’abandon des transactions, ce qui n’est pas la méthode idéale pour les commerçants. Et Cela nous amène à une deuxième stratégie, c’est d’utiliser une « machine learning » pour détecter les transactions frauduleuses.

 

L’entreprise XYZ est créée en février 2019 dans le contexte d’une expérience de presque 10 ans dans le domaine de développement informatique, sécurisation bancaire et solutions sécurisés de paiement en ligne. Cette démarche a commencé en 2010 avec la création de Movidone, qui est une entreprise spécialisée dans le domaine de l’ingénierie d’outils web et mobiles pour la diffusion vidéo, infrastructure serveur et sécurisation bancaire.

 

L’XYZ développe un système capable d’utiliser des algorithmes d’intelligence artificielle pour retrouver de façon automatique dans les données les motifs de fraude. Des modèles ainsi construits peuvent être utilisés pour identifier des transactions à haut risque de fraude. On peut donc déclencher le 3DS seulement pour les transactions à haut risque et réduire significativement les pertes dues à la fraude et en même temps augmenter la conversion du panier. Par ailleurs, en déclenchant régulièrement des mises à jour des modèles d’IA, on peut ainsi adapter les modèles pour identifier des nouvelles stratégies de fraude, et assurer de cette façon des bonnes performances de détection dans le temps.

 

MISSION #1: Transaction Storage and Tagging Dynamics

Le but de stage est d’étudier et d’optimiser les paramètres de stockage et d’extraction des données pour l’entraînement du modèles, afin de trouver les meilleures performances et stabilité du modèle dans le temps.

 

Les problèmes qu’ils rencontrent actuellement sont :

  • D’abord, les données doivent être étiquetées.
  • Ensuite, les données d’entraînement doivent inclure une variable → pour la Fraude ou Légitimité.
  • Et, quand de nouvelles transactions arrivent, XYZ les évalue et les stocke → ça donnera la probabilité de fraude (Pfraud)
  • On peut donc déclencher le 3DS pour les transactions à haute risque → Une transaction peut Passer ou Arrêter.
  • Mais pour les Non 3DS → ils pourraient être légitimes ou frauduleux
  • Et pour les légitimes → dont la plupart sont jamais étiqueté, car aucun client ne le signalera comme une fraude
  • Et en plus, la procédure de traitement de la fraude prend un certain temps
  • Délai d’étiqueter.
    • Nous pouvons définir une fenêtre temporelle « tag-time window » pour déclarer toutes les transactions non marquées comme légitimes. Par exemple, dans notre cas actuel, déclarer toutes les transactions non marquées plus anciennes que Delta t_ tag 94 jours, entraîne une erreur de marquage de 10%, c’est-à-dire qu’après cette période, 10% des transactions frauduleuses attendent d’être marquées , qui dans ce cas serait considéré comme légitime aux fins de l’entraînement du modèle.
    • le délai d’étiqueter (en jours) de la distribution des transactions frauduleuses. Presque toutes les transactions frauduleuses (environ 99%) sont marquées après environ 4 mois depuis leur exécution.

 

Afin de former un modèle «aujourd’hui» (td), nous ne pouvons pas simplement utiliser toutes les données précédentes!

 

Pourquoi ?

Je veux dire que nous ne pouvons tout simplement pas adapter le modèle à nos données d’entraînement et espérons qu’il fonctionnera avec précision pour les données réelles qu’il n’a jamais vues auparavant. Nous avons besoin d’une sorte d’assurance que notre modèle a la plupart des modèles des données corrects.
En plus, cette procédure pourrait produire une erreur de marquage.
 

Et donc ?
Nous avons besoin d’extraire des données.
Nous devons d’abord remonter dans le temps un montant Delta t_ lag puis extraire les données à la fenêtre temporelle Delta t_ train avant cela, c’est-à-dire que les données pour la formation seront comprises entre les instants t1 = td – Delta t_ lag – Delta t_ train et t2 = td – Delta t_ lag.

 

Cependant, cela peut poser des problèmes alors que Delta t_lag ou Delta t_train est trop petit ou trop grand.

  • Par exemple, si le Delta t_lag est trop petit, alors nous aurons trop de transactions frauduleuses non marquées. Par contre, si le Delta t_lag est trop grand, et alors l’entraînement données ne sont pas à jour, et le modèle n’est pas bon actuellement.
  • D’ailleurs, si le Delta t_train est trop petit, alors nous n’avons pas assez de données pour l’entraînement . Et si le Delta t_train est trop grand, et donc, la plupart des données pour l’entraînement ne sont pas mises à jour car la transaction frauduleuse peut varier de temps en temps.
  • Et Donc, il existe un besoin d’optimisation dans ce cas.

 

MISSION #2: High-Risk Transactions & Model Update

Il y a un autre problème de stockage de données qui est très important pour la mise à jour du modèle. Toutes les transactions avec une probabilité de fraude au-delà d’un certain seuil « threshold » (appelé transaction à haut risque) seront soit soumises à une 3DS. Les transactions légitimes doivent généralement passer la 3DS. Inversement, les éléments frauduleux à haut risque seront bloqués, ils ne seront donc plus disponibles pour la formation de modèles à l’avenir.

  • Une des solutions que nous pouvons proposer que de sélectionner au hasard une fraction (par exemple 10 %) des transactions à haute risque et de leur attribuer artificiellement une faible probabilité de fraude. Ces derniers suivront alors le processus naturel de traitement et de marquage des fraudes, et feront alors partie des ensembles de données utilisés pour la mise à jour du modèle.
  • Pendant l’entraînement , nous aurions besoin de leur attribuer un poids de 1 sur f pour prendre en compte la sélection aléatoire et leur donner l’importance relative appropriée qu’ils auraient si aucune 3DS n’était déclenchée.

Et donc, la fraction optimale pour les transactions à haute risque doit être estimée à partir des données pour maximiser les performances de prédiction.

 

TRAVAUX PROPOSÉS

Et maintenant, nous allons parler du travail proposé.
Nous appelons cela « Réglage fin des paramètres d’extraction et de stockage des données ».
Comme vous pouvez le voir ici, nous avons quelques paramètres à régler, comme :
◦ le dataset
◦ fenêtre temporelle des données d’entraînement (Delta_t_train)
◦ jusqu’où nous allons dans le passé à partir d’aujourd’hui (td)
◦ quelle est la fraction des transactions à haut risque que nous laisserons passer (frac_hr_pass)
 

Comment ?
◦ nous effectuons des simulations

  • Le but est de trouvez les meilleures performances stables dans le temps.

 

Et pour les paramètres de contrôle, ici par exemple nous avons utilisé :

  • Les données du 01/01/2016 au 01/01/2018, avec plus de 10 million transactions et 26 variables. Et voici le tableau de variables de données et le tableau de paramètre de réglage.
  • Le Delta t_train sont 90, 120, 180, et 270 jours.
  • Le Delta t_lag sont 110, 93, 71, et 55 jours.
  • Le Frac_hr_pass sont None, 5, 10, 20, et 30 %

 

La simulation effectue certaines opérations avec des données historiques sur une période de temps. Il y a un processus de boucle à l’intérieur de la simulation où la boucle est sur plusieurs itérations dépend des paramètres de contrôle donnés. Chaque itération correspond à l’exécution du processus ci-dessus mais avec un décalage de fenêtre temporelle sur l’ensemble de données, qui dans notre cas actuel est de 30 jours d’intervalle, ce qui signifie qu’il effectue périodiquement le cycle tous les 30 jours. La simulation exécute certaines routines comme suite:

  • ◦ Formatage de l’ensemble de données et prétraitement. Ces étapes permet de gérer les données manquantes et de nettoyage dans l’ensemble de données, de reformater l’ensemble de données en supprimant les fonctionnalités inutilisées, de réinitialiser l’index, d’initialiser le poids (w), la probabilité de fraude (P_fraud) et le seuil (Thr).
  • Extraction de données. Cette routine consiste à extraire les données d’entraînement d’un ensemble de données en fonction d’un Delta t_ train, Delta t_ lag et aujourd’hui (td).
  • L’entraînement du Modèles. Cette routine exécute le processus d’entraînement. L’ensemble de données d’apprentissage est utilisé pour raccord et ajuster les modèles en utilisant la régression logistique.
  • Évaluez les modèles. Maintenant, les modèles de déploiement sont évalués. Cette routine comprend la prévision de la probabilité de fraude (P_ fraud) et traite le poids (w) des transactions à faible et à haut risque à laisser passer selon la fraction frac_hr _pass.
  • Mettre à jour le nouveau stockage de données. Cette routine s’applique au stockage de données en mettant à jour un nouvel ensemble de données. Une fois cette routine se termine, le cycle recommence.

 

En termes d’indicateurs de performance, nous avons utilisé ces 3 indicateurs, qui sont fpr, tpr et ROC AUC, car ce sont des critères majeurs pour le système de détection des fraudes.

  • Le taux de faux positifs est la fraction des transactions légitimes considérées comme frauduleuses.
  • Le véritable taux positif est la fraction des transactions frauduleuses correctement identifiée.
  • ROC AUC est un outil de scikit-learn pour évaluer des performances du modèle de classification.
  • Et nous calculons le fpr et le tpr en utilisant ces formules, où nl est le nombre de transactions légitimes et nf est le nombre de transactions frauduleuses.

 

Nous effectuons 2 types de simulations , « Single Fit » et « Retraining ». Le « Single Fit » signifie qu’un modèle unique est formé au début de la période, puis déployé pour le reste de la période. Cela signifie que le modèle est statique, car aucun « retraining » (mises à jour du modèle) n’est effectué. D’autre part, le « Retraining » fait référence à la réexécution du processus qui a généré le modèle précédemment sélectionné sur un nouvel ensemble de données d’apprentissage.

 

RESULTAT

Et puis pour les performances et les résultats…:)
Voyons un exemple pour la configuration Δt_train = 180 jours, Δt_lag = 93 jours, frac_hr_pass = 10%.
à partir du fichier journal, nous pouvons voir que :

  • En termes de taux de faux positifs. Nous pouvons voir la comparaison de le « Single Fit » et du « Retraining » avec la configuration Delta t_train de 180 jours, Delta t_lag de 93 jours et frac_hr_pass de (10%, 30%). Le « Single Fit » semble plus stable dans le temps par rapport aux modèles de « Retraining » (lignes rouges et vertes). Cela montre que les modèles de recyclage n’ont pas amélioré de manière significative le modèle en général. Cela pourrait être dû aux variations sur les éléments frauduleux peu nombreux dans l’ensemble de données que nous avons utilisé.
  • En termes de taux réellement positif ou d’efficacité effective de la fraude, en général, le « Single Fit » modèle (ligne bleue) donne des performances préférables d’efficacité de la fraude dans le temps (environ 60%). Cela signifie que le « Single Fit » modèle peut détecter les transactions qui étaient en fait frauduleuses.
  • En termes de ROC AUC, Notre courte observation que Delta t_ train dépendra du flux de transaction. Dans nos études, nous avons constaté que la configuration avec Delta t_ train de 180 jours a obtenu de bons résultats, mais à ce moment le flux de transaction était beaucoup plus élevé que le flux actuel.

 

CONCLUSIONS

Certains paramètres de réglage ont été optimisés et simulés dans ces simulations de paramètres de stockage de données pour les mises à jour du modèle d’XYZ.
D’après les résultats de nos simulations, nous pouvons dire heuristiquement que le modèle préférable que nous pouvons obtenir est une configuration donnée pour un « Single Fit » modèle avec Delta t_ train de 180 jours, Delta t_ lag de 90 jours et frac_hr_pass de 10 %. Cela est dû à cette configuration qui a une efficacité de détection raisonnable (environ 50%) et une valeur fpr plus petite. Cependant, il était attendu le pire.
Certains travaux a venir qui pourraient être entrepris, tels que la façon de définir le seuil de manière optimale, de comprendre comment détecter les nouveaux modèles de fraude évolutifs et de modéliser les variations de performances au fil du temps, ainsi que de trouver un moyen de définir les valeurs des paramètres de Delta t_train , Delta t_ lag et frac_hr_pass de manière optimale.