L’accélération récente et massive du commerce en ligne a entraîné une augmentation correspondante de la fraude liée aux paiements en ligne. Selon les estimations, à l’échelle mondiale, la fraude coûte aux entreprises plus de 20 milliards de dollars par an. De plus, pour chaque dollar perdu à cause de la fraude, le coût total pour les entreprises est en réalité nettement plus élevé en raison de l’augmentation des coûts opérationnels, des frais de réseau et de la perte de clients.
Non seulement la fraude coûte cher, mais les fraudeurs chevronnés trouvent constamment de nouvelles façons d'exploiter les failles, ce qui la rend difficile à combattre. C'est pourquoi nous avons conçu Stripe Radar, une solution de prévention de la fraude fondée sur l'IA, entièrement intégrée à la plateforme Stripe. L'apprentissage automatique de Radar exploite les données de centaines de milliards de dollars de paiements traités chaque année sur le réseau Stripe pour détecter la fraude avec précision et s'adapter rapidement aux dernières tendances, vous permettant ainsi de croître sans accroître la fraude.
Ce guide introduit Stripe Radar et la manière nous exploitons le réseau Stripe pour détecter la fraude, présente brièvement les techniques d’apprentissage automatique que nous utilisons, explique notre approche en matière d’efficacité et de performance des systèmes de détection de fraude et décrit comment les autres outils de la suite Radar peuvent aider les entreprises à optimiser leurs performances en matière de lutte contre la fraude.
Introduction à la fraude à la carte de crédit en ligne
Un paiement est considéré comme frauduleux lorsque le titulaire de la carte n’autorise pas le débit. Par exemple, si un fraudeur effectue un achat à l’aide d’un numéro de carte volé non signalé, il est possible que le paiement soit effectué avec succès. Ensuite, lorsque le titulaire découvre l’utilisation frauduleuse de sa carte, il peut contester le paiement auprès de sa banque en déposant un litige (également appelée « contestation de paiement »).
Les entreprises peuvent contester une contestation de paiement en fournissant des preuves attestant de la validité du paiement. Cependant, pour les transactions sans présentation de la carte, si le paiement est jugé véritablement frauduleux par les réseaux, le titulaire de la carte aura gain de cause et l’entreprise sera responsable de la perte des marchandises et des autres frais.
Historiquement, les entreprises ont utilisé des règles strictes pour prédire et bloquer les prélèvements suspectés d’être frauduleux. Cependant, les règles codées en dur, par exemple, le blocage de toutes les cartes de crédit utilisées à l’étranger peuvent entraîner le blocage de nombreuses transactions légitimes. L’apprentissage automatique, en revanche, permet de détecter, en l’occurrence une transaction frauduleuse. Dans le jargon de l’apprentissage automatique, on parle de « faux négatif » lorsque le système passe à côté d’un élément qu’il est censé détecter, en l’occurrence une transaction frauduleuse. On parle de « faux positif » lorsque le système signale un élément qu’il n’aurait pas dû signaler, par exemple en bloquant un client légitime. Avant d’entrer dans les détails de l’apprentissage automatique, il est important de comprendre les compromis qu’il implique.
En cas de faux négatifs, les entreprises sont souvent redevables du montant initial de la transaction, majoré des frais de contestation de paiement (frais liés à l’annulation du paiement par carte par la banque), des frais de réseau plus élevés liés au litige et des coûts opérationnels plus élevés liés à l’examen des frais ou au règlement des litiges. De plus, un nombre excessif de litiges peut entraîner la création d’un programme de surveillance des contestations de paiement réseau, et conduire à des coûts plus élevés, voire, dans certains cas, à l’impossibilité d’accepter les paiements par carte.
Les faux positifs ou refus injustifiés, surviennent lorsqu’un client légitime tente d’effectuer un achat, mais en est empêché. Ces faux refus peuvent impacter négativement le bénéfice brut et nuire à la réputation de l’entreprise. D’ailleurs, d’après une enquête récente, 33 % des consommateurs ont déclaré qu’ils ne reviendraient pas acheter dans une entreprise après un refus injustifié.
Il existe un compromis entre la prévention d’un plus grand nombre de litiges (faux négatifs) et la réduction du blocage de clients légitimes (faux positifs) : moins vous en avez dans le premier cas, plus vous devez tolérer dans le second (et vice versa). Lorsque vous prévenez davantage de fraudes, vous augmentez le nombre de bons clients bloqués. D’autre part, la réduction du nombre de faux positifs augmente souvent le risque que davantage de fraudes réelles passent entre les mailles du filet. Les entreprises doivent décider comment équilibrer ces deux aspects en fonction de leurs marges, de leur profil de croissance et d’autres facteurs.
Si les marges d’une entreprise sont faibles (par exemple, si vous vendez des produits alimentaires en ligne), le coût d’une transaction frauduleuse peut devoir être compensé par des centaines de transactions fiables, ce qui rend chaque faux négatif très coûteux. Les entreprises présentant ce profil peuvent avoir tendance à déployer de multiples solutions pour tenter de contrer une fraude potentielle. À l’inverse, si les marges d’une entreprise sont élevées, par exemple pour une entreprise de logiciels-services, c’est l’inverse qui se produit. Le manque à gagner lié au blocage d’un client légitime peut compenser le coût d’une hausse des fraudes.
Stripe Radar et le réseau Stripe
Radar est la solution de prévention de la fraude de Stripe qui protège les entreprises contre la fraude par carte de crédit en ligne. Elle est propulsée par l'apprentissage automatique adaptatif, fruit d'années de travail en science des données et en infrastructure mené par les équipes d'apprentissage automatique dédiées de Stripe. Les algorithmes de Radar évaluent chaque transaction pour déterminer le risque de fraude et prennent les mesures qui s'imposent. Les paiements à cote élevée sont bloqués, et Radar Plus fournit des outils permettant aux utilisateurs de spécifier le moment où d'autres mesures doivent être prises.
Stripe traite chaque année des centaines de milliards de paiements provenant de millions d'entreprises, et interagit avec des milliers de banques partenaires à travers le monde. Grâce à l'étendue de notre réseau, nous pouvons souvent détecter des signaux et des schémas de fraude bien plus tôt que les réseaux de taille plus modeste. Les données agrégées sur la fraude issues de toutes les transactions Stripe (qui sont collectées de façon automatique via le flux de paiement) nous permettent d'améliorer notre capacité à détecter la fraude. Les signaux, tels que le pays d'émission de la carte ou l'adresse IP d'origine du paiement, fournissent des informations utiles afin de prédire le caractère frauduleux d'un paiement.
Lorsqu'une carte a déjà été utilisée sur le réseau Stripe, nous bénéficions également de nombreuses données qui facilitent nos évaluations des risques. 90 % des cartes utilisées sur le réseau Stripe l'ont déjà été plusieurs fois, ce qui nous confère une infinité de données permettant d'évaluer le caractère légitime ou frauduleux de ces cartes.
Notre technologie d'apprentissage automatique présente un autre avantage majeur : Radar est directement intégré à Stripe et prêt à l'emploi. Les autres solutions de prévention de la fraude représentent généralement un investissement de départ conséquent et impliquent également d'autres investissements continus. Pour commencer, les entreprises doivent intégrer le produit de prévention de la fraude et déployer d'importants efforts de développement pour recevoir des données pertinentes sur les événements et les paiements. Elles doivent ensuite réaliser une intégration de façon à transmettre les étiquettes de paiement (c'est-à-dire une catégorisation du caractère frauduleux ou légitime d'une transaction) de leur prestataire de services de paiement à leur prestataire de services de prévention de la fraude ou étiqueter manuellement les paiements, une tâche qui peut se révéler très chronophage et engendrer des erreurs. A contrario, Radar reçoit des données de terrain directement issues du flux de paiement Stripe, et s'appuie sur des informations précises et suffisamment récentes provenant directement des réseaux et des émetteurs de cartes, sans aucun travail de développement ni de codage.
Examinons dans le détail l'apprentissage automatique adaptatif et son utilisation chez Stripe.
Les principes fondamentaux de l'apprentissage automatique
L'apprentissage automatique désigne un ensemble de techniques visant à utiliser de grandes quantités de données pour créer des modèles de prédiction de résultats, tels que la probabilité qu'un paiement entraîne un litige lié à la fraude.
L'une des principales applications de l'apprentissage automatique est la prédiction : nous voulons prédire la valeur d'une variable de sortie donnée en fonction de certaines valeurs d'entrée. Dans notre cas, la valeur de sortie est vraie si le paiement est frauduleux et fausse autrement (ces valeurs binaires sont appelées booléens), et un exemple de valeur d'entrée pourrait être le pays dans lequel la carte a été émise ou le nombre de pays distincts où la carte a été utilisée sur le réseau de Stripe au cours du dernier jour. Nous déterminons comment faire une prédiction en fonction d'exemples antérieurs de données d'entrée et de sortie.
Les données servant à entraîner (ou à générer) les modèles se composent d'enregistrements (souvent obtenus à partir de données de l'historique) comportant la valeur de sortie et les différentes valeurs d'entrée, comme dans l'exemple suivant (très simplifié) :
|
Montant en USD
|
Pays de la carte
|
Pays où la carte a été utilisée au cours des dernières (24 h)
|
Fraude?
|
|---|---|---|---|
| 10 $ | US | 1 | Non |
| 10 $ | CA | 2 | Non |
| 10 $ | CA | 1 | Non |
| 10 $ | US | 1 | Oui |
| 30 $ | US | 1 | Oui |
| 99 $ | CA | 1 | Oui |
Cet exemple ne comporte que trois valeurs d'entrée. Dans la pratique, les modèles d'apprentissage automatique en possèdent souvent des centaines, voire des milliers. La sortie de l'algorithme d'apprentissage automatique peut être un modèle similaire à l'arbre de décision suivant :
Lorsque nous examinons une nouvelle transaction, nous observons les valeurs d'entrée et parcourons l'arbre à la manière du jeu 20 questions jusqu'à atteindre l'une de ses « feuilles ». Chacune des feuilles est constituée de tous les échantillons du jeu de données (le tableau ci-dessus) qui satisfont les paires de question-réponse sur le chemin que nous avons suivi dans l'arbre. La probabilité que la nouvelle transaction soit frauduleuse correspond au nombre d'échantillons de la feuille divisé par le nombre total d'échantillons dans la feuille. Autrement dit, l'arbre répond à la question suivante : parmi les transactions de notre jeu de données dont les propriétés sont similaires à la transaction que nous examinons à présent, quelle part est effectivement frauduleuse? L'apprentissage automatique permet de construire l'arbre; quelles questions poser et dans quel ordre afin d'augmenter les chances de différencier précisément les deux classes? Les arbres de décision sont particulièrement faciles à visualiser et comprendre. Il existe toutefois un grand nombre d'algorithmes d'apprentissage, possédant chacun leur propre mode de représentation des relations que nous cherchons à modéliser.
Les modèles d'apprentissage automatique d'aujourd'hui sont répandus (ils sous-tendent nombre de produits avec lesquels nous interagissons couramment) et généralement bien plus sophistiqués que le modèle simplifié ci-dessus :
Lors des recherches, Google fournit des suggestions d'orthographe avec justesse et précision grâce à sa fonctionnalité « Vouliez-vous dire? ». L'apprentissage automatique permet de modéliser des millions de paramètres linguistiques en moins de trois secondes.
Amazon fait appel à l'apprentissage automatique afin de prédire les achats à l'aide de son système de recommandation reposant sur les besoins, les préférences et les comportements fluctuants des utilisateurs sur l'ensemble de sa plateforme, même pour les nouveaux utilisateurs sans historique.
De plus, si nous revenons au sujet de cette discussion, l'apprentissage automatique constitue le fondement de Stripe Radar, avec l'objectif de prédire les paiements frauduleux.
Comment fonctionne l'apprentissage automatique?
Les cours universitaires d'apprentissage automatique se concentrent généralement sur les processus de modélisation, c'est-à-dire les méthodes de traduction des données (par exemple le tableau ci-dessus) en modèles (par exemple l'arbre de décision), qui sont les algorithmes qui vous indiquent la relation entre les valeurs d'entrée (le pays d'émission de la carte, le nombre de pays dans lesquels elle a été utilisée, etc.) et les valeurs de sortie (la transaction était-elle frauduleuse?). Le processus qui produit le « meilleur » à partir du tableau de données en entrée ci-dessus est un exemple de méthode d'apprentissage automatique. La modélisation implique différentes étapes, selon la nature de vos données et les modèles que vous choisissez. Nous n'allons pas entrer dans le détail, mais vous trouverez ci-dessous un aperçu global.
Avant toute chose, il nous faut des données d'entraînement. Pour détecter automatiquement la fraude, nous avons besoin d'un jeu de données contenant des exemples de fraude. Pour chacun des exemples, nous devons avoir enregistré (ou être en mesure de calculer rétrospectivement) une gamme de propriétés d'entrée pouvant se révéler utiles pour établir des prédictions futures sur la valeur de sortie. Ces propriétés d'entrée sont appelées des caractéristiques. La collection de données d'entrée d'un échantillon donné est un vecteur de caractéristiques. Dans notre exemple ci-dessus, le vecteur de caractéristiques présentait une longueur de trois (le pays d'émission de la carte, le nombre de pays dans lesquels elle a été utilisée dans les dernières 24 h ainsi que le montant du paiement en USD).
Cependant, il n'est pas rare que les vecteurs comportent des centaines, voire des milliers de caractéristiques. En réalité, Radar utilise des centaines de caractéristiques et la plupart sont des agrégats calculés via l'ensemble du réseau Stripe. À mesure que notre réseau s'étend, chaque caractéristique devient plus instructive, car nos données d'entraînement deviennent plus représentatives de l'ensemble du jeu de données de la caractéristique, y compris toutes les données extérieures à Stripe. La valeur de sortie (dans notre exemple, le booléen indiquant si la transaction était frauduleuse) est souvent appelée cible ou étiquette. Les données d'entraînement se composent donc d'un grand nombre de vecteurs de caractéristiques et de leurs valeurs correspondantes en sortie.
Ensuite, nous devons entraîner un modèle. Sur la base des données d'entraînement, il nous faut une méthode pour produire notre modèle prédictif. En règle générale, les classifieurs d'apprentissage automatique ne se contentent pas de générer une étiquette de classe. Ils affectent habituellement des probabilités que l'échantillon donné appartienne à chaque classe possible. Par exemple, la sortie d'un classifieur de fraude peut indiquer que le paiement présente 65 % de risque d'être frauduleux et 35 % de chance d'être légitime.
Nombre de techniques d'apprentissage automatique peuvent servir à entraîner des modèles. Dans la majorité des applications d'apprentissage automatique industrielles, des approches traditionnelles, telles que la régression linéaire, les arbres de décision ou les forêts aléatoires suffisent tout à fait.
Cependant, des techniques sophistiquées inspirées de l'agencement des neurones du cerveau, à savoir les réseaux neuronaux et l'apprentissage profond, ont permis de nombreuses avancées dans le domaine, notamment les prévisions de 98 % des protéines humaines par AlphaFold. Pour tirer véritablement parti des réseaux neuronaux, ceux-ci doivent être entraînés sur des jeux de données de très grande taille. C'est pourquoi nombre d'entreprises ne sont pas en mesure d'en tirer pleinement profit dans la pratique. En raison de l'étendue de notre réseau, Stripe est à même d'exploiter cette approche de pointe afin de procurer de vrais résultats à nos utilisateurs. Nos nouveaux modèles ont amélioré les performances de Radar en matière d'apprentissage automatique de plus de 20 % d'une année sur l'autre. Nous pouvons ainsi détecter davantage de transactions frauduleuses tout en réduisant le nombre de faux positifs.
Ingénierie des caractéristiques
L'ingénierie des caractéristiques constitue l'un des aspects les plus complexes de l'apprentissage automatique. Elle se divise en deux parties :
La formulation des caractéristiques présentant une valeur prédictive sur la base des connaissances étendues du domaine du problème
L'ingénierie destinée à rendre les valeurs de ces caractéristiques disponibles à la fois pour l'entraînement du modèle et son évaluation en « production »
En formulant une caractéristique, un spécialiste des données Stripe peut avoir l'intuition qu'une caractéristique utile pourrait être de calculer si le paiement par carte est issu d'une adresse IP fréquente pour cette carte. Par exemple, un paiement par carte provenant d'adresses IP connues (correspondant, par exemple, au domicile ou au bureau du titulaire de la carte) est moins susceptible d'être frauduleux que si l'adresse IP provient d'un autre État. Dans ce cas, l'idée est le fruit de l'intuition, mais ces intuitions reposent sur l'examen de milliers de litiges. Par exemple, vous pourriez être surpris d'apprendre que le calcul de la différence entre l'heure de l'appareil de l'utilisateur et le temps universel coordonné (UTC), ou le nombre de pays dans lesquels la carte a été autorisée, sont des indicateurs de fraude.
Lorsque nous trouvons une idée de caractéristique, il nous faut calculer ses valeurs historiques en vue d'entraîner un nouveau modèle incluant cette caractéristique. Il s'agit d'ajouter une colonne à la « table » de données dont nous nous servons pour créer notre modèle. Pour ce faire, nous devons calculer pour chaque paiement de l'historique de Stripe les deux adresses IP dont provenaient le plus fréquemment les paiements antérieurs avec la carte. Nous pouvons réaliser cela de façon distribuée à l'aide d'une tâche Hadoop, mais cette tâche risque de prendre trop de temps (ou de mémoire). Pour y remédier, nous pouvons essayer d'optimiser le calcul au moyen d'une structure de données probabiliste qui économise l'espace. Même dans le cas de caractéristiques qui paraissent simples intuitivement, la production de données pour l'entraînement du modèle nécessite une infrastructure dédiée ainsi que des processus établis.
Les caractéristiques ne sont pas toutes établies de façon manuelle par les ingénieurs. Dans certains cas, vous pouvez laisser le modèle les calculer en ajoutant une étape de test avant le déploiement. Les valeurs catégorielles, telles que le pays d'origine d'une carte ou le marchand ayant traité une transaction (contrairement aux caractéristiques numériques), se prêtent facilement à cette approche. Ces caractéristiques présentent souvent un large éventail de valeurs et il peut être difficile d'en établir une représentation efficace.
Chez Stripe, nous entraînons nos modèles de façon à ce qu'ils apprennent un plongement pour chaque marchand sur la base des motifs de transaction. Un plongement peut être considéré comme les coordonnées d'un marchand donné par rapport aux autres. Des marchands semblables présenteront souvent des plongements similaires (tels que mesurés par la distance cosinus), ce qui permet au modèle de transférer les enseignements d'un marchand à l'autre. Le tableau ci-dessous illustre ces plongements, en supposant qu'Uber et Lyft ont davantage de similitudes entre elles qu'avec Slack. Chez Stripe, nous faisons appel aux plongements pour diverses caractéristiques catégorielles, telles que l'institution financière émettrice, le marchand et le pays de l'utilisateur, le jour de la semaine, etc.
|
Coordonnées d'intégration illustratives
|
|||
|---|---|---|---|
|
Uber
|
2.34 | 1.1 | -3.5 |
|
Lyft
|
2.1 | 1.2 | -2 |
|
Slack
|
7 | -2 | 1 |
Le recours aux The use of embeddings is increasingly common in large-scale industrial applications of machine learning. Word embeddings like these, for example, help capture the complex semantic relationships between words, and have been involved in natural language processing milestones like Word2Vec, BERT, and GPT-3. Stripe produces embeddings to capture similarity relationships between different entities on the Stripe network the same way that the methods above capture similarities between words. Embeddings are a powerful way to learn higher-level concepts without explicit training. For example, fraud patterns are often unevenly distributed geographically. With embeddings, if our system identifies a new fraud pattern in Brazil, it can automatically identify the same pattern if it appears in the US, without further training. In this way, algorithmic advances help stay ahead of shifting fraud patterns, protecting our customers.
Vous souhaitez travailler sur les produits de machine learning de Stripe ? Contactez-nous !
Évaluation des modèles de machine learning
Once we’ve developed a machine learning classifier for fraud that uses hundreds of features and assigns a probability (or score) that the payment is fraud to every incoming transaction, we need to determine how effective the model is at detecting fraud.
Key terms
To better understand how we evaluate our machine learning systems, it’s useful to define some key terms.
Supposons tout d'abord que nous avons établi une stratégie en vue de bloquer un paiement si le modèle de machine learning affecte à la transaction une probabilité de fraude d'au moins 0,7. (Nous l'exprimons sous la forme P(fraude)>0,7). Voici certaines valeurs utiles pour étudier les performances de notre modèle et stratégie :
Précision : la précision de notre stratégie correspond à la part des transactions que nous bloquons et qui sont effectivement frauduleuses. Plus la précision est élevée, moins il y a de faux positifs. Par exemple, sur dix transactions, P(fraude)>0,7 pour six d'entre elles, et sur ces six transactions, quatre sont frauduleuses. La précision est donc de 4/6=0,66.
Rappel : également appelé sensibilité ou le taux de faux positifs, le rappel désigne la part de l'ensemble de la fraude qui est détectée par notre stratégie, c'est-à-dire la part de la fraude pour laquelle P(fraude)>0,7. Plus le rappel est élevé, moins il y a de faux négatifs. Par exemple, sur dix transactions, cinq sont effectivement frauduleuses. Si notre modèle affecte une probabilité P(fraude)>0,7 à quatre de ces transactions, le rappel est de 4/5=0,8.
Taux de faux positifs : la part de tous les paiements légitimes qui sont bloqués par notre stratégie de manière erronée. Par exemple, sur dix transactions, cinq sont légitimes. Si notre modèle affecte une probabilité P(fraude)>0,7 à deux de ces transactions, le taux de faux positifs est de 2/5=0,4.
D'autres valeurs sont prises en compte lors de l'évaluation d'un classifieur, mais nous nous concentrerons ici sur les trois présentées ci-dessus.
Courbes de précision-rappel et ROC
Naturellement, la question suivante porte sur les bonnes valeurs à utiliser pour la précision, le rappel et le taux de faux positifs. Dans un monde théoriquement idéal, la précision serait de 1,0 (en d'autres termes, 100 % des transactions que vous classifiez comme frauduleuses le sont effectivement), ce qui donnerait un taux de faux positifs de 0 (vous n'avez classifié aucune transaction légitime comme frauduleuse). De même, le rappel serait de 1,0 (100 % de la fraude est identifiée comme telle).
En réalité, un compromis est effectué entre la précision et le rappel. Lorsque vous augmentez le seuil de probablité pour le blocage, la précision augmente (en raison du caractère plus strict du critère de blocage) et le rappel diminue (car moins de transactions correspondent au critère de haute probabilité). Pour un modèle donné, une courbe de précision-rappel capture le compromis entre la précision et le rappel, suivant la variation du seuil de stratégie de blocage :
À mesure que notre modèle s'améliore globalement (grâce à l'entraînement avec davantage de données tirées de l'ensemble du réseau Stripe, à l'ajout de caractéristiques qui sont de bons indicateurs de fraude et à l'optimisation d'autres paramètres de modèle), la courbe de précision-rappel évolue, comme illustré ci-dessus. Elle nous permet de contrôler le compromis des entreprises sur Stripe. C'est pourquoi nous surveillons attentivement l'impact au niveau de cette courbe lorsque nos spécialistes de données et nos ingénieurs de machine learning apportent des modifications aux modèles.
Lorsque vous examinez un graphe de précision-rappel, il est important de distinguer les deux notions de « performance ». En lui-même, plus un modèle est proche du coin supérieur droit du graphique (c'est-à-dire là où la précision et le rappel sont de 1,0), plus il est performant globalement. Néanmoins, pour rendre un modèle opérationnel, il est généralement nécessaire de sélectionner un point de fonctionnement sur la courbe de précision-rappel (ici, le seuil de stratégie pour bloquer une transaction), qui contrôle l'impact concret du modèle pour une entreprise.
En termes simples, il y a deux problèmes :
The data science problem of producing a good machine learning model by adding the right features. The model controls the shape of the precision-recall curve.
The business problem of picking a policy to decide how much potential fraud to block. The policy controls where on the curve we're operating.
Another curve that is examined when evaluating a machine learning model is the ROC curve. (ROC is short for “receiver operating characteristic," a relic of the curve’s origin in signal processing applications.) The ROC curve is a plot of the false positive rate (on the x-axis) and the true positive rate (which is the same as the recall) on the y-axis for various values of the policy threshold.
La courbe ROC idéale se situe dans le coin supérieur gauche du graphe (où le rappel est de 1,0 et le taux de faux positifs de 0,0). À mesure que le modèle s'améliore, la courbe ROC se déplace encore davantage dans cette direction. Pour calculer la qualité globale, l'une des méthodes consiste à calculer l'aire sous la courbe. Dans un scénario idéal, l'aire sous la courbe est de 1,0. Lors du développement de nos modèles, nous observons l'évolution de la courbe de précision-rappel, de la courbe ROC et de l'aire sous la courbe.
Distributions de scores
Imaginez que nous disposions d'un modèle qui affecte à une transaction une probabilité de fraude comprise entre 0,0 et 1,0, et ce de manière aléatoire. Dans la pratique, ce modèle ne permet pas de distinguer les transactions frauduleuses des transactions légitimes et nous est guère utile. Ce caractère aléatoire est capturé par la distribution de scores du modèle : la part des transactions recevant chaque score possible. Dans un scénario entièrement aléatoire, la distribution de scores serait presque uniforme :
Un modèle possède une distribution de scores uniforme, comme celui ci-dessus, si, par exemple, il ne présente aucune caractéristique qui peut, même de loin, prédire la fraude. À mesure qu'un modèle est amélioré (en ajoutant des caractéristiques prédictives, en l'entraînant sur davantage de données, etc.), sa capacité à distinguer les classes frauduleuses et légitimes augmente et la distribution de scores devient plus bimodale, avec des pics autour des scores de 0,0 et 1,0.
En soi, une distribution bimodale ne vous indique pas qu'un modèle est bon. (Un modèle vide qui attribue de manière aléatoire des probabilités de seulement 0,0 et 1,0 aurait également une distribution bimodale des cotes.) Cependant, en présence de preuves que les transactions dont la cote est faible ne sont pas frauduleuses et que celles dont la cote est élevée le sont, une distribution de plus en plus bimodale est le signe d'une efficacité améliorée pour un modèle.
Différents modèles auront souvent des distributions de cotes différentes. Lorsque nous publions de nouveaux modèles, nous comparons les anciennes et les nouvelles distributions, afin de minimiser tout changement perturbateur causé par un changement soudain des cotes. Plus particulièrement, nous prenons en compte les politiques de blocage actuelles des marchands telles que mesurées par le seuil auquel ils bloquent les transactions, et visons à maintenir stable la proportion de transactions qui se situent au-dessus du seuil.
Calculer la précision et le rappel
Nous pouvons calculer les indicateurs ci-dessus dans deux contextes différents : pendant la formation du modèle, en utilisant les données historiques qui stimulent le processus de développement du modèle, et après le déploiement du modèle, en utilisant les données de production; c'est-à-dire les données du monde lorsque le modèle est déjà utilisé pour prendre des mesures en bloquant, par exemple, les transactions si la P(fraude)>0,7.
Dans le premier cas, les scientifiques de données prendront généralement les données de formation dont ils disposent (en se référant au tableau ci-dessus) et attribueront de manière aléatoire une partie des enregistrements à un ensemble de formation et les autres enregistrements à un ensemble de validation. On pourrait imaginer que les premiers 80 % de lignes vont dans le premier et les derniers 20 % dans le second, par exemple.
L'ensemble de formation correspond aux données introduites dans une méthode d'apprentissage automatique pour produire un modèle tel que décrit ci-dessus. Une fois que nous avons un modèle candidat, nous pouvons ensuite l'utiliser pour attribuer des cotes à chaque échantillon de l'ensemble de validation. Les cotes de l'ensemble de validation ainsi que leurs valeurs de sortie sont utilisées pour calculer les courbes d'efficacité du récepteur et de précision et rappel, les distributions des cotes, et ainsi de suite. La raison pour laquelle nous utilisons un ensemble de validation distinct de l'ensemble de formation est que le modèle a déjà « vu la réponse » pour ses exemples de formation et appris de ces réponses. Un ensemble de validation nous aide à générer des indicateurs qui constituent une mesure précise de la puissance prédictive du modèle sur de nouvelles données.
Opérations d'apprentissage automatique : déployer des modèles de manière sûre et fréquente
Une fois qu'il a été démontré que la performance d'un modèle est supérieure à celle du modèle de production actuel sur un ensemble de validation, l'étape suivante consiste à le déployer en production. Ce processus comporte deux défis principaux :
Calculs en temps réel : nous devons être capables de calculer la valeur de chaque fonction pour chaque nouveau paiement en temps réel, car nous voulons pouvoir bloquer toutes les transactions que notre classificateur considère comme probablement frauduleuses. Ce calcul est entièrement distinct de celui utilisé pour produire les données de formation — nous devons maintenir un état à jour sur les deux adresses IP les plus fréquemment utilisées pour chaque carte jamais vue sur Stripe, et la récupération et la mise à jour de ces comptes doivent être rapides, car ces opérations font partie du flux de l'API Stripe. Les équipes d'infrastructure d'apprentissage automatique chez Stripe ont facilité ce processus en créant des systèmes permettant de spécifier des fonctions de manière déclarative et de rendre automatiquement les valeurs actuelles des fonctions disponibles en production avec une faible latence.
Application aux utilisateurs du monde réel : le déploiement d'un modèle d'apprentissage automatique est différent du déploiement de code. Alors que les modifications de code sont souvent validées par des cas de test précis, les modifications de modèle sont généralement testées sur un vaste ensemble de données globales à l'aide d'indicateurs tels que ceux que nous avons définis ci-dessus. Toutefois, un modèle qui parvient mieux à détecter la fraude dans son ensemble peut ne pas être meilleur pour chaque utilisateur de Stripe. Il se peut que l'amélioration de la performance soit inégalement répartie, quelques grands marchands connaissant d'importants gains tandis que de nombreux petits marchands subissent de légères régressions. Un modèle peut avoir un rappel plus élevé, mais provoquer une hausse du taux de blocage, ce qui perturberait les entreprises (et leur clientèle). Avant de publier un modèle, nous vérifions qu'il fonctionne bien en pratique. Pour ce faire, nous mesurons le changement que chaque modèle entraînerait sur divers indicateurs, tels que le taux de faux positifs, le taux de blocage et le taux d'autorisation de manière globale et par marchand pour un sous-ensemble d'utilisateurs de Stripe. Si nous constatons qu'un nouveau modèle entraînerait un changement indésirable dans l'un de ces indicateurs de référence, nous l'ajustons pour différents sous-ensembles d'utilisateurs avant de le publier afin de minimiser les perturbations et de garantir une performance optimale.
Nous avons constaté que l'automatisation d'une part aussi importante que possible du processus de formation et d'évaluation offre des avantages cumulatifs à la vitesse de l'itération des modèles. Au cours de la dernière année, nous avons investi dans des outils permettant de former, de régler et d'évaluer automatiquement et régulièrement les modèles à l'aide de nos plus récentes fonctions et architectures de modèle. Par exemple, nous mettons continuellement à jour les tableaux de bord de performance après la formation d'un modèle — avant sa publication. Ainsi, un ingénieur peut facilement détecter si un modèle candidat est devenu obsolète sur un sous-ensemble de trafic avant même de le publier, et le reformer de manière proactive.
Après la publication d'un modèle, nous surveillons sa performance et commençons à travailler sur la prochaine version. Étant donné que les tendances en matière de fraude évoluent rapidement, les modèles d'apprentissage automatique commencent rapidement à dériver : les données sur lesquelles ils ont été formés ne sont plus représentatives de la fraude actuelle.
En utilisant ces outils, nous avons triplé la vitesse à laquelle nous publions des modèles, ce qui se traduit directement par d'importants gains de performance en production. En fait, le simple fait de reformer un modèle du mois dernier avec des données plus récentes (en utilisant les mêmes définitions de fonction et la même architecture) et de le publier nous permet d'augmenter notre rappel jusqu'à un demi-point de pourcentage chaque mois. Le fait de pouvoir publier des modèles fréquemment et en toute sécurité nous permet de tirer parti des gains liés au travail de modélisation et d'ingénierie des fonctions, ainsi que de nous adapter aux modèles de fraude changeants pour les utilisateurs de Radar.
Une fois que nous avons mis un modèle en production, nous surveillons en permanence la performance de notre paire modèle-politique. Pour les paiements dont les cotes sont inférieures au seuil de blocage, nous pouvons observer le résultat final — la transaction a-t-elle fait l'objet d'une contestation pour fraude par le titulaire de la carte? Toutefois, les paiements dont les cotes sont supérieures au seuil sont bloqués, de sorte que nous ne pouvons pas savoir quels auraient été leurs résultats. Le calcul de la courbe de précision et rappel de production complète ou d'efficacité du récepteur est donc plus complexe que le calcul des courbes de validation, car il implique une analyse contrefactuelle — nous devons obtenir des estimations statistiquement solides de ce qui se serait passé, même pour les paiements que nous avons bloqués. Au fil des années, Stripe a mis au point des méthodes pour y parvenir. Vous pouvez en apprendre davantage à ce sujet dans cette présentation.
Nous venons de décrire quelques-unes des mesures de l'efficacité des modèles que les scientifiques de données et les ingénieurs en apprentissage automatique examinent lors du développement de modèles d'apprentissage automatique. Ensuite, nous expliquerons comment les entreprises devraient aborder la prévention de la fraude.
Comment Stripe peut vous aider
Le fait de se concentrer sur un seul chiffre pour saisir votre performance en matière de fraude peut entraîner des choix qui ne sont pas optimaux pour votre entreprise. Nous avons constaté que les entreprises accordent souvent une importance excessive aux faux négatifs — elles sont très préoccupées par la fraude non détectée — et sous-estiment les faux positifs. Cette mentalité entraîne souvent des mesures de force brute inefficaces et coûteuses, comme le blocage de toutes les cartes internationales. En général, vous devriez réfléchir à la façon dont les diverses mesures de performance se rapportent entre elles et aux compromis appropriés en fonction de vos circonstances particulières. Voici un exemple de la façon dont ces indicateurs s'articulent pour vous aider à déterminer l'efficacité de votre système de prévention de la fraude :
MODÈLE APPROXIMATIF POUR LA PRÉCISION DU SEUIL DE RENTABILITÉ
Si votre vente moyenne s'élève à 26 $ avec une marge de 8 %, votre bénéfice par vente est de 26,00 $ × 8,00 % = 2,08 $. En moyenne, si la production de votre produit coûte 26,00 $ – 2,08 $ = 23,92 $ et que des frais de rétrofacturation de 15 $ vous sont facturés, votre perte totale pour une vente frauduleuse est de 23,92 $ + 15,00 $ = 38,92 $. Par conséquent, une vente frauduleuse vous coûte le bénéfice de 38,92 $ / 2,08 $ = 18,71 ventes légitimes, et votre précision du seuil de rentabilité est de 1 / (1 + 18,71) = 5,07 %.
Les seuils d'apprentissage automatique de Radar établissent un compromis entre l'optimisation des marges des marchands et le maintien de la stabilité des taux de blocage au sein de notre clientèle. Vous pouvez accéder à un Dashboard pour voir comment l'apprentissage automatique de Radar fonctionne pour votre entreprise, ainsi que la performance de vos règles personnalisées si vous utilisez Radar Plus. Ces outils vous permettent de comparer facilement vos taux de contestation frauduleuse, vos taux de faux positifs et vos taux de blocage à ceux d'autres entreprises similaires en fonction de cohortes personnalisées et agrégées d'entreprises de secteurs ou de tailles similaires à la vôtre.
Amélioration des performances au moyen de règles et de vérifications manuelles
Outre les algorithmes d'apprentissage automatique plus automatiques, Radar Plus permet également aux entreprises individuelles de créer des règles personnalisées (par exemple, « bloquer toutes les transactions supérieures à 1 000 $ lorsque le pays de l'adresse IP ne correspond pas au pays de la carte »), de formuler une requête d'interventions et de vérifier manuellement les paiements signalés dans le Dashboard.
Les règles de ce type peuvent être considérées comme de simples « modèles » (après tout, elles peuvent être représentées par des arbres de décision !) et doivent être évaluées de la même façon que des modèles, en prenant pleinement compte du compromis entre la précision et le rappel. Lorsque vous créez une règle à l'aide de Radar, nous vous présentons l'historique des transactions correspondantes qui ont été contestées, remboursées ou acceptées en vue de faciliter ces calculs avant même la mise en œuvre de cette règle. Une fois la règle activée, vous pouvez observer son effet sur les taux de faux positifs et de litiges.
Les règles, les interventions et les vérifications manuelles sont tout aussi importantes. Elles permettent aux utilisateurs de faire pencher la courbe de précision-rappel en leur faveur en ajoutant une logique propriétaire et spécifique à l'entreprise (des règles) ou en requérant un effort supplémentaire (une vérification manuelle).
Si vous constatez que les algorithmes de machine learning ne parviennent souvent pas à détecter un certain type de fraude spécifique à votre entreprise (alors que la fraude est facile à identifier), vous pouvez établir une règle visant à la bloquer. Cette intervention spécifique augmente généralement le rappel sans affecter la précision outre mesure. Ce faisant, vous déplacez le point de fonctionnement le long d'une courbe de précision-rappel moins accentuée et plus favorable.
En transmettant certaines catégories de transactions pour vérification manuelle au lieu de les bloquer totalement, vous pouvez gagner en précision sans affecter le rappel. De la même façon, en transmettant certaines transactions pour vérification manuelle au lieu de les accepter directement, vous pouvez améliorer le rappel sans diminuer la précision.
À l'évidence, dans de tels scénarios, ces gains occasionnent un travail humain supplémentaire (et vous rendent dépendant de l'exactitude des évaluations de votre équipe). Toutefois, la vérification manuelle, les règles et les interventions sont autant d'outils supplémentaires en vue d'authentifier les clients à haut risque et ainsi d'améliorer les statistiques liées à la fraude.
Prochaines étapes
Nous espérons que ce guide vous aidera à comprendre comment l'apprentissage automatique est appliqué à la prévention de la fraude chez Stripe et comment évaluer l'efficacité de vos systèmes de lutte contre la fraude. Vous pouvez en apprendre davantage sur les fonctions de Radar ou explorer notre documentation.
Si vous avez des questions ou souhaitez en savoir plus sur Stripe Radar, n'hésitez pas à communiquer avec nous.