L'explosion récente du commerce en ligne s'est accompagnée d'une hausse tout aussi importante des paiements en ligne frauduleux. Pour les entreprises du monde entier, la fraude représente annuellement une perte estimée à plus de 20 milliards de dollars. Par ailleurs, chaque dollar de perte imputable à la fraude représente en réalité pour les entreprises un coût total bien plus élevé en raison de l'augmentation des coûts d'exploitation, des frais de réseau et du taux de perte de clientèle que cela induit.
Non seulement la fraude coûte cher, mais les fraudeurs trouvent toujours de nouvelles façons d'exploiter les vulnérabilités, ce qui la rend plus difficile à combattre. C'est la raison pour laquelle nous avons conçu Stripe Radar, une solution de prévention de la fraude pleinement intégrée à la plateforme Stripe. La technologie d'apprentissage automatique sur laquelle repose Radar tire parti des données de centaines de milliards de dollars de paiements traités tous les ans sur le réseau Stripe pour détecter la fraude et s'adapter rapidement aux dernières menaces. Grâce à Radar, les entreprises peuvent se développer sans risquer de voir leur taux de fraude augmenter.
Ce guide vous présente la solution Stripe Radar et vous explique comment tirer profit du réseau Stripe pour lutter contre la fraude. Il passe en revue les techniques d'apprentissage automatique que nous employons ainsi que les performances des systèmes de détection de la fraude. Enfin, il explique comment les autres outils de la suite Radar peuvent aider les entreprises à optimiser leur système antifraude.
Introduction à la fraude à la carte de crédit en ligne
Un paiement est considéré comme frauduleux dès lors que le titulaire de la carte ne l'a pas autorisé. Par exemple, si un fraudeur effectue un achat à l'aide d'une carte qui n'a pas encore été déclarée volée, il est possible que le paiement soit traité. Lorsque le titulaire de la carte s'aperçoit que sa carte a été utilisée de manière frauduleuse, il peut contester le paiement auprès de son institution financière en soumettant un litige (une contestation de paiement).
Pour contester un litige, les entreprises peuvent soumettre des preuves démontrant la légitimité du paiement. Cependant, pour les transactions effectuées sans présentation de la carte, si le paiement est jugé frauduleux par les réseaux, le titulaire de la carte remporte le litige et l'entreprise est redevable des pertes de marchandises et autres frais.
Traditionnellement, les entreprises adoptent une approche de « force brute » pour identifier les paiements suspects et les bloquer. Néanmoins, les règles codées en dur (par exemple, le blocage de toutes les cartes de crédit utilisées depuis l'étranger) peuvent bloquer de nombreuses transactions valides. A contrario, l'apprentissage automatique peut mettre en lumière des mécanismes plus nuancés pour vous aider à accroître vos revenus. Dans le langage de l'apprentissage automatique, un faux négatif survient lorsque le système valide un paiement frauduleux. Inversement, un faux positif se produit lorsque le système bloque par erreur un paiement légitime. Avant d'étudier plus en détail le fonctionnement de l'apprentissage automatique, il est essentiel de comprendre les compromis qui sont en jeu.
Les faux négatifs ont un impact considérable sur les entreprises qui doivent souvent rembourser le montant de la transaction d'origine ainsi que les frais de litige (le coût de l'annulation par l'institution financière du paiement par carte). De plus, la gestion des litiges générés par les faux négatifs entraîne une augmentation des frais de réseau et des coûts opérationnels. Enfin, si votre entreprise fait l'objet d'un trop grand nombre de litiges, elle peut se voir intégrer l'un des programmes de surveillance des litiges des réseaux de cartes, ce qui peut entraîner des coûts plus élevés ou, dans certains cas, l'incapacité d'accepter des paiements par carte.
Les faux positifs correspondent aux transactions légitimes refusées. Ils sont source pour les entreprises de pertes de revenus et d'atteinte à la réputation. En effet, une enquête récente révèle que 33 % des consommateurs cesseraient d'effectuer des achats auprès d'une entreprise après le refus d'un paiement légitime.
Il est nécessaire de faire un compromis entre le nombre de litiges évités (les faux négatifs) et le nombre de clients légitimes bloqués (les faux positifs) : moins vous avez de faux négatifs, plus vous devez tolérer les faux positifs (et inversement). Lorsque vous bloquez davantage de paiements frauduleux, vous augmentez le nombre de clients légitimes bloqués. D'autre part, réduire le nombre de faux positifs accroît souvent la probabilité qu'un nombre croissant de transactions frauduleuses passent à travers les mailles du filet. Les entreprises doivent déterminer quel est le meilleur compromis en fonction notamment de leurs marges et de leur profil de croissance.
Pour les entreprises pratiquant des marges faibles (par exemple dans le cas de la vente de nourriture en ligne), le coût d'une transaction frauduleuse devra probablement être compensé par des centaines de transactions légitimes, ce qui rend chaque faux négatif très coûteux. Les entreprises répondant à ce profil sont susceptibles de « ratisser large » pour éviter toute fraude potentielle. La réciproque est vraie pour les entreprises pratiquant des marges plus importantes (par exemple, une entreprise de type logiciel-service). Les pertes de revenus induites par le blocage d'un client légitime peuvent être supérieures au coût de l'augmentation de la fraude.
Stripe Radar et le réseau Stripe
Radar est une solution Stripe de prévention de la fraude qui vise à protéger les entreprises contre la fraude à la carte bancaire en ligne. Elle repose sur une technologie d'apprentissage automatique adaptatif, fruit de plusieurs années de travail en data science et en infrastructure des équipes de Stripe dédiées à l'apprentissage automatique. Les algorithmes de Radar évaluent le risque de fraude de chaque transaction et agissent en conséquence. Les paiements au score de risque élevé sont bloqués et Radar for Fraud Teams fournit des outils permettant aux utilisateurs d'indiquer à quel moment 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.
La prédiction est l'une des principales applications de l'apprentissage automatique : nous souhaitons prédire la valeur d'une variable de sortie à partir de certaines valeurs d'entrée. Dans notre cas, la valeur de sortie est « true » si le paiement est frauduleux ou « false » dans le cas contraire (ces valeurs binaires sont des booléens). La valeur d'entrée pourrait être le pays d'émission de la carte ou le nombre de pays dans lesquels la carte a été utilisée sur le réseau Stripe au cours des dernières 24 h. Nous déterminons le mode de prédiction sur la base 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 la banque é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.
Une distribution bimodale seule ne saurait indiquer la qualité d'un modèle. En effet, un modèle qui affecte de manière aléatoire des probabilités de 0,0 et 1,0 uniquement aurait également une distribution de score bimodale. Cependant, s'il est prouvé que les transactions présentant un indice bas ne sont pas frauduleuses, alors que celles présentant un indice élevé le sont, une distribution bimodale est le signe d'une efficacité accrue.
Différents modèles présentent souvent différentes distributions d'indice. Lorsque nous publions de nouveaux modèles, nous comparons la nouvelle distribution à l'ancienne, en vue d'éviter tout changement perturbateur causé par une variation soudaine des indices. Nous prenons notamment en compte les stratégies de blocage actuelles des marchands selon leur seuil de blocage des transactions. Notre objectif est de conserver la même proportion de transactions qui dépassent le seuil.
Calcul de la précision et du rappel
Nous pouvons mesurer les indicateurs ci-dessus dans deux contextes distincts : lors de l'entraînement du modèle, au moyen de données d'historique qui orientent le processus de développement du modèle, de même qu'après le déploiement du modèle, au moyen de données réelles (c'est-à-dire des données du monde réel lorsque le modèle est utilisé pour prendre des mesures, par exemple en bloquant les transactions si P(fraude)>0,7).
Dans le premier cas, les spécialistes des données se servent généralement des données d'entraînement à leur disposition (voir le tableau ci-dessus), et affectent aléatoirement une partie des enregistrements à un ensemble d'entraînement, et l'autre partie à un ensemble de validation. Par exemple, les premiers 80 % des lignes pour l'ensemble d'entraînement et les derniers 20 % pour l'ensemble de validation.
L'ensemble d'entraînement correspond aux données alimentant une méthode d'apprentissage automatique dans le but de générer un modèle, tel que décrit ci-dessus. Lorsque nous disposons d'un modèle candidat, nous pouvons nous en servir pour affecter des indices à chacun des échantillons de l'ensemble de validation. Les indices de l'ensemble de validation, associés à leurs valeurs de sortie, permettent de calculer les courbes ROC et de précision-rappel, les distributions d'indice, etc. Nous faisons appel à un ensemble de validation distinct de celui d'entraînement, car le modèle « connaît déjà la réponse » pour les exemples d'entraînement et s'est formé à partir de ces réponses. Un ensemble de validation nous aide ainsi à produire des indicateurs qui représentent une mesure exacte du pouvoir prédictif du modèle sur de nouvelles données.
Opérations d'apprentissage automatique : déploiement de modèles à un rythme régulier et de manière sécurisée
Lorsque les performances d'un modèle sur un ensemble distinct dépassent celles du modèle actuellement en production, l'étape suivante consiste à le mettre en production. Ce processus présente deux défis majeurs :
Calculs en temps réel : nous devons être capables de calculer en temps réel la valeur de chaque caractéristique pour chaque nouveau paiement, car nous devons être en mesure de bloquer toutes les transactions que notre classifieur juge potentiellement frauduleuses. Ce calcul est totalement distinct de celui servant à générer les données d'entraînement. En effet, nous devons maintenir un état actualisé sur les deux adresses IP les plus utilisées pour chaque carte vue par Stripe, et la récupération et la mise à jour de ces nombres doivent s'effectuer rapidement, car ces opérations se déroulent dans le cadre du flux de l'API Stripe. Les équipes de Stripe chargées de l'infrastructure de l'apprentissage automatique ont simplifié cela en concevant des systèmes permettant de spécifier des caractéristiques de manière déclarative et en mettant les valeurs actuelles des caractéristiques à disposition automatiquement en production, le tout avec une latence faible.
Application utilisateur dans le monde réel : déployer un modèle d'apprentissage automatique ne revient pas à déployer du code. Les changements de code sont souvent validés au moyen de scénarios de test précis, tandis que les changements de modèle sont généralement testés sur un vaste jeu de données agrégées au moyen d'indicateurs, tels que ceux définis ci-dessus. Toutefois, un modèle qui permet une meilleure détection de la fraude au niveau agrégé n'est pas forcément préférable pour tous les utilisateurs de Stripe. Il est possible que l'amélioration des performances ne soit pas distribuée de manière égale, avec quelques marchands importants constatant des gains conséquents, alors que nombre de petits marchands déplorent de légères régressions. Un modèle peut présenter un rappel plus élevé, mais entraîner un pic du taux de blocage qui peut être préjudiciable aux entreprises (de même qu'à leurs clients). Avant de publier un modèle, nous vérifions ses performances dans la pratique.
Pour ce faire, nous mesurons le changement suscité par chaque modèle sur divers indicateurs, comme les taux de faux positifs, de blocage et d'autorisation au niveau agrégé et par marchand pour un sous-ensemble d'utilisateurs de Stripe. Si nous constatons qu'un nouveau modèle entraînerait une variation défavorable de l'un des indicateurs de référence, nous l'ajustons pour différents sous-ensembles d'utilisateurs avant de le publier, de façon à réduire les perturbations et à assurer une performance optimale.
Nous avons découvert qu'en automatisant la plus grande part possible de l'entraînement et de l'évaluation, nous obtenions des avantages cumulatifs au niveau de la vitesse d'itération des modèles. L'année dernière, nous avons investi dans des outils destinés à entraîner, optimiser et évaluer les modèles de façon régulière et automatique au moyen de nos caractéristiques et de l'architecture de modèle les plus récentes. Par exemple, nous mettons continuellement à jour les tableaux de bord de performance après l'entraînement d'un modèle, avant sa mise en production. Ainsi, un ingénieur peut facilement détecter si un modèle candidat est devenu obsolète sur un sous-ensemble du trafic avant même sa mise en production, et l'entraîner une nouvelle fois de manière proactive.
Une fois un modèle publié, nous surveillons ses performances et commençons à travailler sur la version suivante. Les tendances en matière de fraude évoluant rapidement, les modèles d'apprentissage automatique perdent rapidement de leur efficacité : les données sur lesquelles ils ont été entraînés ne sont plus représentatives de la fraude actuelle.
Ces outils nous ont permis de mettre en production des modèles trois fois plus vite, ce qui s'est traduit directement par des gains de performance importants en production. En réalité, même le réentraînement d'un modèle du mois dernier sur des données plus récentes (à l'aide de la même architecture et des mêmes définitions de caractéristiques) et sa mise en production nous permettent d'accroître notre rappel de 0,5 % par mois. En étant à même de mettre en production des modèles de manière régulière et sécurisée, nous pouvons capitaliser et cumuler les gains de l'ingénierie des caractéristiques et du travail de modélisation et nous adapter à l'évolution des stratagèmes de fraude au profit des utilisateurs de Radar.
Lorsque nous mettons un modèle en production, nous surveillons en permanence les performances de notre paire de modèle-stratégie. Pour les paiements qui présentent des indices inférieurs au seuil de blocage, nous pouvons observer le résultat ultime : la transaction contestée par le titulaire de la carte était-elle effectivement frauduleuse? Les paiements dont les indices dépassent le seuil sont cependant bloqués. Pour cette raison, nous ne sommes pas en mesure de savoir quel aurait été le résultat. Le calcul de la courbe complète de précision-rappel ou ROC en production est donc plus complexe que le calcul des courbes de validation, car il implique une analyse contrefactuelle : il nous faut obtenir des estimations statistiquement valables 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 à cette fin. Pour en savoir plus, veuillez visionner cette présentation.
Nous venons de décrire quelques-unes des mesures d'efficacité d'un modèle que les spécialistes des données et les ingénieurs chargés de l'apprentissage automatique prennent en compte lors du développement de modèles d'apprentissage automatique. À présent, nous allons nous intéresser à la façon dont les entreprises doivent appréhender la prévention de la fraude.
Comment Stripe peut vous aider
En focalisant votre attention sur un seul et unique chiffre pour déterminer vos performances face à la fraude, vous êtes suceptible de faire des choix qui ne sont pas judicieux pour votre entreprise. Nous avons constaté que les entreprises ont souvent tendance à accorder trop d'importance aux faux négatifs (étant très préoccupées par la fraude non détectée) et à sous-estimer les faux positifs. Cette attitude mène souvent à des mesures brutales, inefficaces et coûteuses, comme le blocage de l'ensemble des cartes internationales. En règle générale, vous devriez réfléchir à la relation entre les diverses mesures de performance et chercher à déterminer les bons compromis en fonction de votre situation. Voici un exemple de la façon dont ces indicateurs peuvent être associés pour vous aider à déterminer l'efficacité de votre système de prévention de la fraude :
MODÈLE APPROXIMATIF DE LA PRÉCISION DE RENTABILITÉ
Si votre vente moyenne est de 26 $ avec une marge de 8 %, votre profit par vente est de 26,00 $ × 8,00 % = 2,08 $. En moyenne, si votre produit coûte 26,00 $ – 2,08 $ = 23,92 $ à fabriquer et que vous avez prélevé des frais de litige de 15 $, votre perte totale en cas de vente frauduleuse est de 23,92 $ + 15,00 € = 38,92 $. Par conséquent, une vente frauduleuse vous coûte la somme correspondant au profit 38,92 $ / 2,08 $ = 18,7 $ d'une vente légitime et votre précision 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 la stabilisation des taux de blocage au sein de notre base d'utilisateurs. Vous pouvez accéder à un tableau de bord afin de voir les performances d'apprentissage automatique de Radar pour votre entreprise, ainsi que celles de vos règles personnalisées si vous optez pour Radar for Fraud Teams. Avec ces outils, vous pouvez facilement comparer vos taux de litiges frauduleux, de faux positifs et de blocage à ceux d'autres entreprises similaires sur la base de cohortes d'entreprises agrégées et personnalisées de la même taille que votre entreprise ou qui opèrent dans le même secteur.
Amélioration des performances au moyen de règles et de vérifications manuelles
Grâce à Radar for Fraud Teams, vous pouvez ajuster avec précision votre protection en établissant directement votre seuil de risque de manière à bloquer ou autoriser davantage de paiements. Outre la solution plus automatique des algorithmes de machine learning, Radar for Fraud Teams permet aux entreprises de créer des règles personnalisées (par exemple « bloquer toutes les transactions de plus de 1 000 $ si le pays de l'adresse IP ne correspond pas à celui de la carte »), de solliciter des interventions ainsi que 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 Stripe applique le machine learning à la prévention de la fraude et comment évaluer l'efficacité de vos systèmes antifraude. Vous pouvez en apprendre davantage sur les fonctionnalités de Radar ou consulter notre documentation.
Pour toute question ou si vous souhaitez en savoir plus sur Stripe Radar, veuillez nous contacter.