L'accélération récente et massive du e-commerce a engendré une augmentation correspondante de la fraude liée aux paiements en ligne. À l'échelle mondiale, on estime que 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é bien 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 est coûteuse, mais les fraudeurs aguerris trouvent sans cesse de nouvelles manières d'exploiter les vulnérabilités, ce qui la rend difficile à combattre. C'est pourquoi nous avons créé Stripe Radar, une solution de prévention de la fraude basée sur l'IA, entièrement intégrée à la plateforme Stripe. Le machine learning de Radar s'appuie sur les données de centaines de milliards de dollars de paiements traités sur le réseau Stripe chaque année afin de détecter la fraude avec précision et de s'adapter rapidement aux nouvelles tendances. Vous pouvez ainsi vous développer sans accroître la fraude.

Ce guide présente Stripe Radar et aborde la façon dont nous utilisons le réseau Stripe pour détecter la fraude. Outre un aperçu de nos techniques de machine learning, il explique également notre approche de l'efficacité et des performances qui caractérisent les systèmes de détection de la fraude. Enfin, il décrit la manière dont d'autres outils de la suite Radar peuvent aider les entreprises à optimiser leurs performances face à la fraude.

Introduction à la fraude à la carte bancaire en ligne

Un paiement est considéré comme frauduleux dès lors que le titulaire de la carte en question ne l'autorise pas. À titre d'exemple, si un fraudeur effectue un achat à l'aide d'une carte dont le vol n'a pas encore été signalé, le paiement est susceptible d'être validé. Après avoir constaté l'utilisation frauduleuse de sa carte, la personne qui en est réellement titulaire contestera le paiement auprès de sa banque en ouvrant un litige (également appelé « contestation de paiement »).

De même, les entreprises peuvent s'opposer à une contestation de paiement en apportant la preuve que le paiement était bien valide. Toutefois, pour les transactions sans présentation de carte, si le paiement est effectivement considéré comme frauduleux par les réseaux, le titulaire de la carte aura gain de cause et l'entreprise sera tenue responsable de la perte des biens et d'autres frais.

Les entreprises ont traditionnellement recours aux règles de force brute pour prédire et intercepter les paiements suspects. Néanmoins, les règles codées en dur (telles que le blocage de toutes les cartes bancaires utilisées à l'étranger) peuvent entraîner le rejet de nombreuses transactions valides. A contrario, le machine learning peut détecter des mécanismes plus nuancés pour vous aider à accroître vos revenus. Dans le contexte du machine learning, un faux négatif survient lorsque le système passe à côté d'un élément qu'il est censé détecter, soit dans le cas présent, une transaction frauduleuse. De la même manière, un faux positif se produit lorsque le système signale un événement par erreur (par exemple en bloquant un client légitime). Avant d'entrer dans les détails du machine learning, il est essentiel de bien comprendre les compromis en jeu.

Avec les faux négatifs, les entreprises sont souvent redevables du montant de la transaction d'origine et des frais de contestation de paiement (coût d'annulation du paiement en carte par la banque), de frais de réseau plus élevés en raison du litige, ainsi que de coûts opérationnels supérieurs liés à l'examen des paiements ou à la lutte contre les litiges. En outre, si vous recevez un trop grand nombre de litiges, vous risquez de vous retrouver dans un programme de surveillance des contestations de paiement d'un réseau, ce qui peut entraîner des coûts plus élevés, voire, dans certains cas, vous empêcher d'accepter les paiements par carte.

Les faux positifs, ou faux refus de paiement, se produisent lorsqu'un client légitime essaie d'effectuer un achat, mais en est empêché. Les faux refus de paiement peuvent affecter le bénéfice brut et entacher la réputation de l'entreprise. D'ailleurs, selon une récente enquête, 33 % des consommateurs ont affirmé qu'ils n'achèteraient plus jamais auprès d'une entreprise à la suite d'un faux refus de paiement.

Il existe un compromis entre la prévention des litiges (faux négatifs) et la réduction du nombre de clients légitimes bloqués (faux positifs) : moins les litiges sont nombreux, plus vous devez tolérer les blocages (et vice versa). Plus vous vous efforcez de prévenir la fraude, plus vous augmentez le nombre de clients légitimes qui se trouvent bloqués. D'un autre côté, en réduisant le nombre de faux positifs, il se peut que davantage de véritables tentatives de fraude passent entre les mailles du filet. Les entreprises doivent donc parvenir à un juste équilibre entre les deux, en fonction de leurs marges, de leur profil de croissance et d'autres facteurs.

Si les marges de votre entreprise sont faibles (par exemple, si vous vendez des denrées alimentaires en ligne), il vous faudra potentiellement compenser le coût d'une transaction frauduleuse par des centaines de transactions légitimes. Dans ce cas, chaque faux négatif se révèle extrêmement coûteux. Les entreprises concernées sont susceptibles de privilégier la prévention de la fraude au détriment du blocage de clients légitimes. En revanche, si les marges d'une entreprise sont élevées (comme dans le cas d'une entreprise SaaS), l'inverse se vérifie. La perte de revenus découlant du blocage d'un client légitime peut être supérieure au coût engendré par un volume de fraude accru.

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 à la carte bancaire en ligne. Elle est alimentée par un machine learning adaptatif, fruit de plusieurs années de travail en science des données et en infrastructure par les équipes de Stripe dédiées au machine learning. Les algorithmes de Radar évaluent le risque de fraude de chaque transaction et prennent les mesures appropriées. Les paiements dont le score est élevé sont bloqués, et Radar Plus fournit des outils pour que les utilisateurs puissent spécifier à 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 de machine learning 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 le machine learning et son utilisation chez Stripe.

Les principes fondamentaux du machine learning

Le machine learning 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 du machine learning est la prédiction : nous voulons prédire la valeur d'une variable de sortie en fonction de certaines valeurs d'entrée. Dans notre cas, la valeur de sortie est vraie si le paiement est frauduleux et fausse dans le cas contraire (ces valeurs binaires sont appelées booléens), et un exemple de valeur d'entrée pourrait être le pays d'émission de la carte bancaire ou le nombre de pays distincts dans lesquels la carte bancaire a été utilisée sur le réseau Stripe au cours de la veille. Nous déterminons la manière d'effectuer une prédiction en nous basant sur des 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é) :

Cet exemple ne comporte que trois valeurs d'entrée. Dans la pratique, les modèles de machine learning en possèdent souvent des centaines, voire des milliers. La sortie de l'algorithme de machine learning 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 ? Le machine learning 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 de machine learning 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 ? ». Le machine learning permet de modéliser des millions de paramètres linguistiques en moins de trois secondes.
  
• Amazon fait appel au machine learning 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, le machine learning constitue le fondement de Stripe Radar, avec l'objectif de prédire les paiements frauduleux.

Comment fonctionne le machine learning ?

Les cours universitaires de machine learning 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 de machine learning. 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 de machine learning 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 de machine learning peuvent servir à entraîner des modèles. Dans la majorité des applications de machine learning 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 le deep learning, 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 de machine learning 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 du machine learning industriel. 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 workflows é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.

Le recours aux plongements est de plus en plus répandu dans les applications industrielles de machine learning à grande échelle. Les plongements de mots comme ceux-ci, par exemple, facilitent la capture des relations sémantiques complexes entre les mots. Ils ont, par ailleurs, été utilisés dans des étapes majeures du domaine du traitement automatique du langage, tels que Word2Vec, BERT et GPT-3. Stripe produit des plongements afin de capturer les relations de similitude entre différentes entités sur son réseau, de la même façon que les méthodes ci-dessus capturent les similitudes entre les mots. Les plongements constituent un moyen puissant d'apprentissage de concepts de niveau plus élevé sans entraînement explicite. Par exemple, les mécanismes de fraude présentent souvent une distribution géographique hétérogène. Grâce aux plongements, si notre système identifie un nouveau mécanisme de fraude au Brésil, il peut automatiquement identifier le même mécanisme s'il apparaît aux États-Unis, sans entraînement supplémentaire. Ainsi, les avancées algorithmiques permettent de garder une longueur d'avance face à l'évolution des mécanismes de fraude, et donc de protéger nos clients.

Évaluation des modèles de machine learning

Après avoir développé un classifieur de machine learning contre la fraude qui s'appuie sur des centaines de caractéristiques et affecte à chaque transaction entrante une probabilité (ou un score) de fraude, nous devons déterminer si le modèle est efficace pour détecter la fraude.

Termes essentiels

Pour mieux appréhender notre méthode d'évaluation des systèmes de machine learning, il peut être utile de définir certains termes essentiels.

Supposons tout d'abord que nous ayons é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 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 : part de tous les paiements légitimes qui sont bloqués à tort par notre stratégie. 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 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 probabilité 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 (en s'appuyant sur de plus en plus de données issues du réseau Stripe, en ajoutant des caractéristiques qui constituent de bons indicateurs de fraude et en optimisant d'autres paramètres du 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 sur cette courbe lorsque nos spécialistes de données et nos ingénieurs de machine learning modifient les modèles.

Lorsque vous examinez un graphique 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. 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 à résoudre :

• Celui de la data science, qui est de créer un bon modèle de machine learning en ajoutant les bonnes caractéristiques. Le modèle contrôle la forme de la courbe de précision-rappel.

• Celui de l'entreprise, qui est de choisir une stratégie et de décider du volume de fraude potentielle à bloquer. La stratégie détermine le point de fonctionnement sur la courbe.

Lors de l'évaluation d'un modèle de machine learning, la courbe ROC est également examinée (ROC est l'abréviation de l'anglais « Receiver Operating Characteristic », fonction d'efficacité du récepteur, qui est une relique des applications de traitement de signal à l'origine de cette courbe.). La courbe ROC est une représentation du taux de faux positifs (sur l'axe des x) et du taux de vrais positifs (qui correspond au rappel) sur l'axe des y pour différentes valeurs du seuil de stratégie.

La courbe ROC idéale se situe dans le coin supérieur gauche du graphique (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 inutile. Ce caractère aléatoire est capturé par la distribution de scores du modèle : c'est-à-dire 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é (via l'ajout de caractéristiques de prédiction, l'entraînement 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 permet pas d'affirmer qu'un modèle est performant. (Un modèle vide qui attribue de manière aléatoire des probabilités de 0,0 et 1,0 aurait également une distribution de score bimodale.) Toutefois, s'il est prouvé que les transactions dont le score est faible ne sont pas frauduleuses et que les transactions dont le score est élevé le sont, une distribution de plus en plus bimodale est le signe d'une efficacité accrue d'un modèle.

Différents modèles ont souvent des distributions de score différentes. Lorsque nous publions de nouveaux modèles, nous comparons les anciennes distributions aux nouvelles afin de minimiser les perturbations causées par un changement soudain des scores. En particulier, nous tenons compte des politiques de blocage actuelles des marchands, telles que mesurées par le seuil auquel ils bloquent les transactions, et nous visons à maintenir stable la proportion de transactions qui se situe au-dessus du seuil.

Calcul de la précision et du taux de rappel

Nous pouvons calculer les indicateurs ci-dessus dans deux contextes différents : pendant l'entraînement du modèle, en utilisant les données historiques qui pilotent 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 réelles lorsque le modèle est déjà utilisé pour prendre des mesures en bloquant par exemple les transactions si P(fraude)>0,7).

Pour le premier cas, les scientifiques des données prennent généralement les données d'entraînement dont ils disposent (voir le tableau ci-dessus) et attribuent de manière aléatoire une partie des enregistrements à un ensemble d'entraînement et le reste à un ensemble de validation. On pourrait imaginer que les 80 % de premières lignes aillent dans le premier et les 20 % restants dans le second, par exemple.

L'ensemble d'entraînement correspond aux données transmises à une méthode de machine learning pour produire un modèle tel que décrit ci-dessus. Une fois que nous disposons d'un modèle candidat, nous pouvons l'utiliser pour attribuer des scores à chaque échantillon de l'ensemble de validation. Les scores de l'ensemble de validation ainsi que leurs valeurs de sortie sont utilisés pour calculer les courbes ROC et de précision-taux de rappel, les distributions de scores, etc. La raison pour laquelle nous utilisons un ensemble de validation distinct de l'ensemble d'entraînement est que le modèle a déjà « vu la réponse » pour ses exemples d'entraînement et appris de ces réponses. Un ensemble de validation nous aide à générer des indicateurs qui mesurent avec précision le pouvoir prédictif du modèle sur de nouvelles données.

Opérations de machine learning : déployer des modèles en toute sécurité et fréquemment

Une fois qu'il a été démontré que les performances d'un modèle sont supérieures à celles du modèle de production actuel sur un ensemble mis de côté, l'étape suivante consiste à le déployer en production. Ce processus présente deux défis principaux :

• Calculs en temps réel : nous devons être capables de calculer la valeur de chaque fonctionnalité pour chaque nouveau paiement en temps réel, car nous voulons pouvoir bloquer toutes les transactions que notre classificateur juge susceptibles d'être frauduleuses. Ce calcul est totalement indépendant de celui utilisé pour produire les données d'entraînement (nous devons maintenir un état à jour sur les deux adresses IP les plus fréquemment utilisées pour chaque carte bancaire jamais vue sur Stripe, et la récupération ainsi que la mise à jour de ces comptes doivent être rapides car ces opérations s'inscrivent dans le flux de l'API Stripe). Les équipes d'infrastructure de machine learning chez Stripe ont facilité cette tâche en créant des systèmes permettant de spécifier des fonctionnalités de manière déclarative et de rendre les valeurs actuelles de ces fonctionnalités disponibles automatiquement en production avec une faible latence.

• Application pour les utilisateurs dans le monde réel : le déploiement d'un modèle de machine learning 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 agrégées à l'aide d'indicateurs tels que ceux définis ci-dessus. Cependant, un modèle plus performant pour détecter la fraude dans son ensemble peut ne pas l'être pour chaque utilisateur Stripe. Il se peut que l'amélioration des performances soit inégalement répartie, quelques grands marchands enregistrant des gains importants alors que de nombreux petits marchands subissent de légères régressions. Un modèle peut avoir un taux de rappel plus élevé mais provoquer un pic du taux de blocage, ce qui perturberait les entreprises (et leurs clients). Avant de publier un modèle, nous vérifions qu'il fonctionne bien dans la pratique. Pour ce faire, nous mesurons l'impact que chaque modèle aurait sur divers indicateurs, tels que le taux de faux positifs, le taux de blocage et le taux d'autorisation de manière agrégée et par marchand pour un sous-ensemble d'utilisateurs 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 des performances optimales.

Nous avons constaté que l'automatisation au maximum du processus d'entraînement et d'évaluation offre des avantages cumulatifs à la vitesse d'itération du modèle. Au cours de l'année écoulée, nous avons investi dans des outils permettant d'entraîner, d'ajuster et d'évaluer automatiquement et régulièrement des modèles en utilisant nos dernières fonctionnalités et notre architecture de modèle. Par exemple, nous mettons continuellement à jour les tableaux de bord de performances après l'entraînement d'un modèle (avant sa publication). De cette manière, 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 réentraîner de manière proactive.

Après avoir publié un modèle, nous surveillons ses performances et commençons à travailler sur la prochaine version. Étant donné que les tendances en matière de fraude évoluent rapidement, les modèles de machine learning commencent vite à subir une dérive : les données sur lesquelles ils ont été entraînés ne sont plus représentatives de la fraude actuelle.

Grâce à ces outils, nous avons triplé la vitesse à laquelle nous publions des modèles, ce qui se traduit directement par des gains de performances importants en production. En fait, le simple fait de réentraîner un modèle du mois dernier sur des données plus récentes (en utilisant les mêmes définitions de fonctionnalités et la même architecture) et de le publier nous permet d'augmenter notre taux de rappel d'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 capitaliser sur les gains du travail d'ingénierie des fonctionnalités et de modélisation, de les faire fructifier et de nous adapter à l'évolution des modèles de fraude pour les utilisateurs de Radar.

Une fois qu'un modèle est mis en production, nous surveillons continuellement les performances de notre paire modèle-politique. Pour les paiements dont les scores sont inférieurs au seuil de blocage, nous pouvons observer le résultat final (la transaction a-t-elle été contestée par le titulaire de la carte pour fraude ?). Cependant, les paiements dont les scores sont supérieurs au seuil sont bloqués, et nous ne pouvons donc pas savoir quel aurait été leur résultat. Le calcul de l'intégralité de la courbe de précision-taux de rappel ou ROC de production est donc plus complexe que le calcul des courbes de validation, car il implique une analyse contrefactuelle (nous devons obtenir des estimations statistiquement fiables de ce qui se serait passé même pour les paiements que nous avons bloqués). Au fil des ans, Stripe a développé des méthodes pour y parvenir, dont vous pourrez en apprendre davantage dans cette présentation.

Nous venons de décrire quelques-unes des mesures d'efficacité des modèles que les scientifiques des données et les ingénieurs en machine learning examinent lors du développement de modèles de machine learning. Ensuite, nous aborderons la façon dont les entreprises devraient envisager la prévention de la fraude.

Comment Stripe peut vous aider

Se focaliser sur un seul chiffre pour évaluer vos performances en matière de fraude peut entraîner des choix non optimaux pour votre entreprise. Nous avons constaté que les entreprises accordent souvent une importance excessive aux faux négatifs (elles s'inquiètent beaucoup des fraudes non détectées) et sous-estiment les faux positifs. Cette mentalité se traduit souvent par des mesures de force brute inefficaces et coûteuses, comme le blocage de toutes les cartes bancaires internationales. En général, il convient de réfléchir à la manière dont toutes les différentes mesures de performances sont liées et aux compromis appropriés compte tenu de votre situation particulière. 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 prélevé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 de machine learning de Radar font le compromis entre l'optimisation des marges des marchands et le maintien de taux de blocage stables sur l'ensemble de notre base d'utilisateurs. Vous pouvez accéder à un tableau de bord pour voir les performances du machine learning de Radar pour votre entreprise, ainsi que les performances de vos règles personnalisées si vous utilisez Radar Plus. Ces outils vous permettent de comparer facilement vos taux de litiges pour fraude, de faux positifs et de blocage avec d'autres entreprises similaires, sur la base de cohortes personnalisées et agrégées d'entreprises de taille ou de secteurs similaires au vôtre.

Amélioration des performances à l'aide de règles et de vérifications manuelles

Parallèlement aux algorithmes de machine learning plus automatiques, Radar Plus permet également aux entreprises individuelles de composer 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 bancaire »), de demander des 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 pour faciliter ces calculs avant même l'application 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 complexifiant le processus (à l'aide d'une vérification manuelle).

Si vous constatez que les algorithmes de machine learning peinent souvent à détecter un certain type de fraude spécifique à votre entreprise (alors que vous pouvez facilement l'identifier), vous pouvez établir une règle visant à bloquer ce type de fraude. 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 améliorez 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 qui permettent d'authentifier les clients à haut risque, et ainsi d'améliorer les statistiques relatives à la fraude.

Prochaines étapes

Nous espérons que ce guide vous aidera à comprendre comment le machine learning est appliqué à la prévention de la fraude chez Stripe et comment évaluer l'efficacité de vos systèmes anti-fraude. Vous pouvez en savoir plus sur les fonctionnalités de Radar ou explorer notre documentation.

Si vous avez des questions ou souhaitez en savoir plus sur Stripe Radar, n'hésitez pas à nous contacter.