La forte croissance qu'a connue le e-commerce récemment s'est accompagnée d'une hausse tout aussi importante de la fraude aux paiements en ligne. Pour les entreprises du monde entier, la fraude représente chaque année une perte estimée à plus de 20 milliards de dollars. Par ailleurs, chaque dollar de perte imputable à la fraude représente en réalité une charge totale bien plus élevée pour les entreprises en raison de l'augmentation des coûts d'exploitation, des frais de réseau et du taux d'attrition.

Non seulement la fraude coûte cher, mais elle est difficile à combattre, car des escrocs chevronnés trouvent constamment de nouveaux stratagèmes pour exploiter les faiblesses des entreprises. C'est pour cette raison que nous avons conçu Stripe Radar, une solution de prévention de la fraude reposant sur le machine learning, pleinement intégrée à la plateforme Stripe. La technologie de machine learning de Radar tire parti des 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 pourrez alors développer votre activité sans vous exposer davantage aux risques de 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 refus de paiement erronés, ont lieu lorsqu'un client légitime tente d'effectuer un achat, mais en est empêché. Les faux positifs ont un impact néfaste à la fois sur les revenus de l'entreprise et sa réputation. En effet, une récente enquête révèle que 33 % des clients indiquent ne plus vouloir effectuer d'achats auprès d'une entreprise suite à un refus de paiement erroné.

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 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 de machine learning adaptatif, fruit de plusieurs années de travail en data science et en infrastructure des équipes de Stripe dédiées au machine learning. 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 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.

La prédiction est l'une des principales applications du machine learning : 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é) :

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.

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 faible score ne sont pas frauduleuses, alors que celles présentant un score élevé le sont, une distribution bimodale est le signe d'une efficacité accrue.

Différents modèles présentent souvent différentes distributions de score. Lorsque nous publions de nouveaux modèles, nous comparons la nouvelle distribution à l'ancienne, en vue d'éviter tout changement perturbateur entraîné par une variation soudaine des scores. 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 de production (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 de machine learning 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 scores à chacun des échantillons de l'ensemble de validation. Les scores de l'ensemble de validation, associés à leurs valeurs de sortie, permettent de calculer les courbes ROC et de précision-rappel, les distributions de score, 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 de machine learning : 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 déployer 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 machine learning 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 de machine learning 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, tels que 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 suite à l'entraînement 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 du trafic avant même sa publication, 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 de machine learning 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 publier 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 publication nous permettent d'accroître notre rappel de 0,5 % par mois. En étant à même de publier 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 mécanismes 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 scores 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 scores 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 de machine learning prennent en compte lors du développement de modèles de machine learning. À 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 pouvez être amené à 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, telles que 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 vos circonstances spécifiques. 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 de machine learning 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 Dashboard afin de voir les performances de machine learning 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 pour fraude, 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 à l'aide de règles et de vérifications manuelles

Radar for Fraud Teams vous permet d'ajuster votre protection avec précision en définissant directement votre seuil de tolérance aux risques de manière à bloquer ou autoriser davantage de paiements. Outre les algorithmes automatiques de machine learning offerts par Radar for Fraud Teams, la solution permet également 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 bancaire »), de solliciter 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 Stripe tire parti du machine learning pour prévenir 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.

Si vous avez des questions ou souhaitez en savoir plus sur Stripe Radar, veuillez nous contacter.