L'évaluation du risque de fraude est un processus continu qui consiste à identifier les vecteurs d'attaque, les mécanismes et les scénarios, puis à les atténuer. En travaillant en étroite collaboration avec les utilisateurs, notre équipe de services professionnels a observé que les entreprises qui y parviennent le plus efficacement sont souvent celles où les analystes de fraude et les analystes de données travaillent ensemble, en combinant Stripe Radar for Fraud Teams et les produits Stripe Data tels que Stripe Sigma ou Stripe Data Pipeline pour identifier à la fois les mécanismes de fraude courants et ceux spécifiques à leur activité.

Radar for Fraud Teams aide à détecter et à prévenir la fraude et vous permet de créer une configuration anti-fraude sur mesure, unique à votre entreprise, avec des règles personnalisées, des rapports et des vérifications manuelles. Stripe Sigma est une solution de reporting qui met à votre disposition toutes vos données transactionnelles, de conversion et clients dans un environnement interactif au sein du Dashboard Stripe. Data Pipeline fournit les mêmes données, mais les envoie automatiquement à votre entrepôt de données Snowflake ou Redshift afin que vous puissiez y accéder en même temps que vos autres données commerciales.

Ces outils fonctionnent en synergie parfaite pour couvrir les quatre piliers d'un processus de gestion de la fraude efficace : Détection, Investigation, Confirmation, et Perfectionnement et mesures d'atténuation (nous les aborderons plus en détail).

Valeur ajoutée de Radar for Fraud Teams en combinaison avec Stripe Sigma ou Data Pipeline

L'objectif principal de l'utilisation de Radar for Fraud Teams avec Stripe Sigma ou Data Pipeline est d'analyser les données de Radar, telles que les métadonnées, parallèlement à vos propres données (notamment les informations relatives aux préautorisations, au parcours utilisateur, à la conversion et aux sessions) afin de distinguer les transactions légitimes des comportements frauduleux des clients. Vous pouvez ainsi optimiser :

1. Le temps d'analyse pour la détection et la prévention proactive de la fraude
   
2. Le temps de réaction pour le développement de règles de détection et de prévention
   
3. Le coût de la fraude, y compris les remboursements, les frais de litige, l'attrition et les refus de paiement par l'émetteur
   

Notre rapport État des lieux de la fraude en ligne met en évidence les coûts opérationnels liés aux processus de vérification manuelle et souligne que « plus les [entreprises] sont grandes, plus la proportion de transactions qu'elles vérifient est faible ». En automatisant ces processus, vous pouvez libérer vos analystes en matière de fraude afin qu'ils consacrent davantage de temps à l'identification de nouveaux vecteurs d'attaque et à l'élaboration de règles préventives et de détection. Cela signifie que vous pouvez trouver un meilleur équilibre entre le blocage du trafic frauduleux et la réduction des frictions pour les clients légitimes (taux d’attrition).

Processus classique de gestion de la fraude aux transactions

Partons du principe que vous disposez d'un processus classique de gestion de la fraude aux transactions basé sur la détection, l'investigation, la confirmation, et le perfectionnement et les mesures d'atténuation, et ce, au sein d'un cadre plus étendu de gestion du risque.

• La détection, également appelée identification, prédiction ou réponse aux incidents, consiste à découvrir un point de données qui justifie une enquête plus approfondie. La détection peut être manuelle (par exemple, lors d'un incident), semi-automatisée (via des règles de détection ou une surveillance par rapport à votre base de référence), automatisée (via le machine learning ou la détection d'anomalies) ou déclenchée en externe (par exemple, commentaires ou litiges des clients). En matière de détection, le machine learning de Radar permet de repérer automatiquement les mécanismes de fraude courants, tandis que Stripe Sigma vous aide à identifier les mécanisme spécifiques à votre entreprise.
  
• L'enquête, ou analyse exploratoire, consiste à évaluer les paiements ou comportements suspects afin de mieux comprendre leur impact sur l'activité. Elle implique souvent une vérification à l'aide de données plus larges afin d'éliminer les interférences. En général, les analystes spécialisés dans la fraude utilisent la file d'attente Radar ou le Dashboard des paiements Stripe pour mener leurs enquêtes.
  
• La confirmation, également appelée modélisation ou test rétroactif, consiste à généraliser le vecteur d'attaque frauduleux vérifié en dimensions et en modèles candidats. Elle couvre également la validation et l'évaluation d'impact à l'aide de données historiques et par rapport à d'autres règles. Les fonctionnalités de tests rétroactifs et de simulation de Radar peuvent aider les analystes en fraude à réaliser cette tâche, mais les ingénieurs de données peuvent utiliser Stripe Sigma pour un éventail plus large de scénarios.
  
• Le raffinement et l'atténuation, parfois appelés « action » ou « confinement », correspondent à la mise en œuvre du modèle, qui consiste à mapper les dimensions et les caractéristiques significatives sur les prédicats des règles Radar afin de prévenir, surveiller ou rediriger la fraude. Traditionnellement, il s'agissait de règles préventives statiques, mais maintenant que le machine learning est un complément important pour les humains et que l'objectif est d'accroître la précision, le terme « raffinement » est plus approprié. Cela comprend généralement des règles de blocage ou des listes dans Radar.
  

Une mise en œuvre basique de ce processus pourrait impliquer des cycles itératifs tels que des vérifications quotidiennes, des sprints ou la mise en place d'une configuration de détection de la fraude basée sur des règles. Toutefois, dans la mesure où les durées de cycle peuvent différer et que les boucles de rétroaction peuvent se produire simultanément, nous préférons adopter le prisme d'un processus continu.

La suite de cet article aborde chacun de ces quatre piliers en détail sous l'angle d'un scénario hypothétique, puis vous présente la manière dont Radar for Fraud Teams et Stripe Sigma, ou encore Data Pipeline, peuvent vous aider.

Notre scénario

Dans le cadre de notre scénario hypothétique, nous analyserons un comportement qui se produit sur une période donnée, plutôt qu'un comportement soudain de courte durée.

Partons du principe que vous êtes une entreprise d'e-commerce. La fonctionnalité de surveillance via webhooks est configurée dans votre solution d'observabilité. Elle réalise divers graphiques de tendances en matière de paiement, et ce, en temps réel. Vous avez constaté, ces derniers jours, une augmentation régulière du volume de refus de paiement d'une marque de carte bancaire appelée « Mallory », pour un produit qui n'est pas habituellement vendu dans la région dans laquelle cette marque de carte bancaire est fréquemment utilisée. (Remarque : Mallory est une marque de carte bancaire fictive que nous utiliserons pour décrire ce scénario. Par exemple, il pourrait s'agir d'une marque qui n'appartient pas au réseau renforcé d'émetteurs. Aucune promotion ni aucun incident ne saurait expliquer ce changement. Votre équipe doit donc se pencher sur la question et décider de la marche à suivre.

Détection

Les règles par défaut de Stripe utilisent le machine learning pour prédire, détecter et bloquer un nombre conséquent de paiements frauduleux. Le Dashboard d'analyse Radar permet d'obtenir un aperçu des tendances en matière de fraude. Pour les entreprises qui souhaitent avoir davantage de contrôle sur la nature des paiements à examiner, à autoriser ou à bloquer, les règles sont un outil puissant de personnalisation de la protection contre la fraude.

Avant de commencer à détecter de nouveaux mécanismes de fraude, vous devez tout d'abord disposer d'un socle de signaux prédictifs, tels que la performance de vos règles existantes. En d'autres termes, vous devez pouvoir identifier la « normalité » pour votre entreprise et savoir ce à quoi ressemble une transaction légitime. C'est là que vos analystes en matière de fraude et ingénieurs de données collaboreront (en impliquant éventuellement les équipes DevOps et leur solution d'observabilité). Dans notre scénario hypothétique, une augmentation des refus de paiement par carte bancaire « Mallory » est détectée via une surveillance continue.

Tableaux Stripe Sigma de données utiles sur la fraude

Pour détecter les tendances émergentes, vous devrez d'abord établir une base de référence en matière de performances à l'aide de fonctionnalités telles que le taux de refus/d'autorisation des émetteurs et le taux de blocage Radar. Ensuite, vous devrez rechercher les litiges frauduleux, les alertes précoces de fraude (dossiers de fraude des émetteurs) et les transactions de paiement à vitesse élevée, à taux de refus élevé de la part des émetteurs ou à score de risque Radar élevé. Idéalement, vous programmerez cette recherche pour qu'elle s'exécute quotidiennement en fonction des données disponibles et vous afficherez tous les tableaux de bord avec les données passées, y compris les coupes hebdomadaires et mensuelles, sans même avoir à interroger manuellement Stripe Sigma ou votre entrepôt de données. Cela accélérera votre temps de réponse aux incidents.

Voici les tableaux les plus utiles ici :

Vos analystes commerciaux ou spécialisés dans la fraude ont forcément en tête des catégories supplémentaires de dimensions dont l'évaluation basée sur votre domaine peut être importante. Le tableau des attributs de règles Radar de Radar for Fraud Teams contient des informations détaillées sur les transactions existantes évaluées par Radar, mais ne remonte pas au-delà d'avril 2023, et ne présente ni métadonnées ni résultats finaux. Auparavant, les champs suivants auraient fait l'objet d'une requête :

Le nouveau tableau des attributs de règles Radar permet d'effectuer un suivi des mêmes dimensions et de bien d'autres, pour chaque transaction évaluée par Radar portant le nom exact des attributs Radar. Par exemple, vous pouvez faire le suivi des tendances de vélocité avec name_count_for_card_weekly.

Il existe différentes façons de visualiser les tendances. Cependant, un simple graphique linéaire croisé dynamique par catégorie de dimension constitue un bon outil de comparaison avec d'autres facteurs. Lorsque vous approfondirez la phase d'investigation, il vous sera peut-être nécessaire de combiner plusieurs catégories. Voici, à titre d'exemple, un tableau indiquant des catégories de segment de produit en lien avec l'augmentation du refus des transactions par carte « Mallory » :

Vous pouvez en obtenir une visualisation dans l'outil de feuille de calcul de votre choix :

Regardons de plus près l'exemple d'une requête Sigma ou Data Pipeline pour le renvoi du socle de données susmentionné. Dans la requête ci-dessous, vous observerez les taux quotidiens de litiges, de refus de paiement, de blocages, entre autres, répartis dans des colonnes distinctes. Durant la phase de détection et d'investigation, les données en volume et disparates sont plus faciles à visualiser lorsqu'elles sont réparties dans des colonnes distinctes. Il sera également plus facile de mapper les colonnes vers les prédicats de Radar ultérieurement. Vos experts en données pourront toutefois préférer un format vertical long et dense pour conduire une analyse exploratoire durant l'investigation, ou le machine learning durant les phases de confirmation et de perfectionnement et de mesures d'atténuation.

Dans cet exemple, nous incluons les métadonnées sur le paiement afin d'afficher une catégorisation par segment de produit. Pour une approche à plus grande échelle, nous aurions besoin de requêtes similaires pour la marque de carte (« Mallory ») et le type de financement, conformément à notre scénario. Nous dédupliquons les tentatives d'essai afin de nous concentrer sur les intentions en tant que telles et de mieux appréhender l'ampleur de la situation. Nous optons pour une déduplication des intentions de paiement : des intégrations plus poussées sont susceptibles d'envoyer un champ (un ID de commande, dans les métadonnées, etc.) afin d'assurer la déduplication tout au long du parcours utilisateur. Cet exemple montre comment vous pouvez augmenter la précision de vos mesures antifraude grâce à l'ajout d'un autre facteur. Dans notre scénario, il s'agirait du segment de produit « cartes cadeaux ». Nous reviendrons sur les moyens de gagner en précision ultérieurement, dans la section portant sur le perfectionnement et les mesures d'atténuation.

Cette requête n'indique pas les données temporelles relatives au litige en soi, ce qui est un indicateur retardé, mais nous avons inclus quelques indicateurs à titre d'exemple, tel que l'indicateur de tests de carte bancaire. Dans cette requête, nous obtenons quelques mesures quotidiennes de façon simple :

• Le volume de paiements, valeur brute sans doublon : Par exemple, 1 150 paiements par jour, dont 100 sont refusés et 50 bloqués par Radar, avec 1 000 intentions de paiement ;
  
• Le taux d'autorisation : Dans cet exemple, 90 % pour les paiements, parce que les paiements bloqués n'atteignent pas l'émetteur, et 100 % pour les intentions de paiement, dans la mesure où les nouvelles tentatives ont, au bout du compte, fonctionné ;
  
• Le taux de blocage et de risque élevé : Dans ce cas, on parlerait de 1,6 % (les 50 paiements à haut risque ont également tous été bloqués) ;
  
• Le taux de litiges initial pour des paiements sur la même période : Par exemple, 5 paiements sur 1 000 ont fait l'objet de litiges. Le nombre de litiges journaliers sur des paiements augmentera avec l'ajout de litiges « en haut de la pile » d'un jour sur l'autre. Par conséquent, nous incluons le temps d'exécution de la requête afin de suivre le changement.
  

Comme mentionné supra, nous avons simplifié ces requêtes pour des raisons de lisibilité. En réalité, cette requête disposerait d'encore davantage de dimensions, par exemple, des tendances, des déviations, ou des différences de perte.

Nous avons également inclus un exemple de moyenne dynamique sur 30 jours calendaires déterminés à l'aide d'une fonction de fenêtre. Des approches plus complexes, telles que l'analyse de centiles plutôt que de moyennes, afin d'identifier des attaques de grande envergure, sont envisageables, mais rarement nécessaires pour la détection de la fraude, dans la mesure où les tendances ont plus d'utilité qu'une précision mathématique idéale.

Une fois votre socle maîtrisé, vous pouvez commencer à repérer des anomalies et des tendances à examiner, par exemple, une augmentation du taux de fraude ou de blocage depuis un certain pays ou en lien avec un moyen de paiement donné (dans notre scénario hypothétique, il s'agit de la marque de carte bancaire « Mallory »). Les anomalies sont généralement examinées via des rapports ou des analyses manuelles depuis le Dashboard, ou encore des requêtes ponctuelles dans Stripe Sigma.

Investigation

Une fois que les analystes ont trouvé une anomalie à examiner, l'étape suivante consiste à effectuer une requête dans Stripe Sigma (ou votre entrepôt de données via Data Pipeline), afin d'explorer les données en question et d'élaborer une hypothèse. Il vous faudra inclure des sous-catégories de dimensions basées sur vos hypothèses ; par exemple, les moyens de paiement (utilisation de carte bancaire), les canaux ou la surface (métadonnées), le client (réputation) ou les produits (catégorie de risque) qui ont une tendance plus marquée en matière de fraude. Ensuite, à l'étape de confirmation, ces dimensions pourront être appelées « caractéristiques ». Elles seront mappées avec des prédicats Radar.

Retournons à notre hypothèse selon laquelle un large volume de transactions sur des cartes prépayées « Mallory » entraîne des taux de fraude plus élevés, que vous pouvez représenter comme une dimension en agrégation, qui pourra ensuite être croisée via votre outil d'analyse. Normalement, à cette étape, la requête est réitérée et optimisée. Il est donc judicieux d'y inclure divers candidats pour les prédicats, pour former des versions réduites ou détaillées des hypothèses, en retirant des caractéristiques mineures, afin d'évaluer leur impact. Par exemple :

Cette approche vous donnera une idée de l'ampleur, en vue de la priorisation de l'impact. Le tableau vous indique que, selon toute vraisemblance, le candidat 3 de la règle capte des transactions malveillantes en surplus. Une évaluation plus sophistiquée sera basée sur la précision ou le rappel. Vous pouvez obtenir un tel résultat, grâce à la requête ci-dessous.

Dans cette requête, nous avons retiré les mentions de doublons pour des raisons de lisibilité, mais nous avons inclus le taux de litige et le taux d'alertes de suspicion de fraude, qui sont importants pour les programmes de surveillance des cartes. Il s'agit, néanmoins, d'indicateurs retardés. Par ailleurs, cette requête simplifiée ne permettra qu'une identification rétroactive. Nous avons également introduit des échantillons de paiement aléatoires pour réaliser une vérification comparative et une analyse plus approfondie des mécanismes identifiés à partir de la requête. Nous y reviendrons.

Il vous sera peut-être utile de distinguer d'autres mesures au sein d'un histogramme, ce qui peut permettre de définir des règles de rapidité à utiliser pour délimiter les taux (p. ex total_charges_per customer_hourly).

Identifier les tendances via une analyse sous forme d'histogramme constitue un excellent moyen de comprendre le comportement du client légitime tout au long de son parcours et de son tunnel de conversion. L'ajouter à la requête supra complexifierait trop notre explication. Voici tout de même un exemple de répartition en catégories sans logique complexe de fenêtre dynamique, avec un type de client au sein des métadonnées (utilisateurs invités, par exemple) :

Dans notre scénario, vous ne bloquerez peut-être pas l'ensemble des cartes prépayées « Mallory », mais souhaiterez quand même identifier de façon certaine tout autre facteur de risque corrélé. Cette requête de vélocité éclairera votre réflexion et vous permettra, par exemple, d'éviter de bloquer des clients invités à faible fréquence.

Une méthode simple consiste à examiner directement les échantillons dans le Dashboard via la vue « Paiements associés » afin de comprendre le comportement, c'est-à-dire le vecteur d'attaque ou les mécanismes de fraude, ainsi que les informations associées sur les risques fournies par Radar. C'est pourquoi nous avons inclus des échantillons de paiements arbitraires dans la requête ci-dessus. De cette façon, vous pouvez également trouver des paiements plus récents qui ne sont pas encore disponibles dans Stripe Sigma. Une méthode plus défensive et plus personnalisée consisterait à modéliser votre hypothèse sous forme de règle de vérification qui autorise toujours les paiements, mais les transmet à vos analystes pour qu'ils les vérifient manuellement. Certains clients procèdent ainsi pour envisager le remboursement des paiements inférieurs aux frais de litige tout en bloquant ceux qui sont supérieurs.

Confirmation

À l'avenir, supposons que le modèle que vous avez identifié n'est pas simple, qu'il ne peut être atténué par un remboursement et le blocage du client frauduleux, et qu'il ne relève pas simplement d'une liste de blocage par défaut.

Après avoir identifié et hiérarchisé un nouveau modèle à traiter, vous devez analyser son impact potentiel sur vos revenus légitimes. Il ne s'agit pas d'un problème d'optimisation trivial, car le montant optimal de la fraude n'est pas nul. Parmi tous les différents modèles candidats, choisissez celui qui représente le meilleur compromis pour votre appétit pour le risque, soit par simple ampleur, soit par précision et rappel. Ce processus est parfois appelé « test rétroactif », en particulier lorsque les règles sont d'abord rédigées, puis validées par rapport à vos données. (Vous pouvez également procéder à l'inverse, c'est-à-dire découvrir d'abord les modèles, puis rédiger les règles.) Par exemple, au lieu de rédiger une règle par pays, rédigez une règle comme celle-ci qui facilite la confirmation :

Block if :card_funding: = 'prepaid and :card_country: in @preaid_card_countries_to_block

La requête indiquée plus haut, dans la section sur l'investigation, peut également être utilisée comme modèle. Toutefois, différentes valeurs seront mises en exergue. Nous y reviendrons lorsque nous aborderons les techniques de perfectionnement et d'atténuation.

Schéma Stripe Sigma pour le mappage de règles Radar

Il est temps de traduire vos requêtes exploratoires de Stripe Sigma ou Data Pipeline afin de vous aider à mapper les règles Radar à Stripe Sigma pour les tests rétroactifs. Voici quelques mappages courants, en supposant que vous envoyez les bons signaux à Radar :

Les deux derniers éléments, risk_level et risk_score, sont différents des autres, dans la mesure où le modèle de machine learning en soi est issu des autres facteurs. Plutôt que d'écrire des règles très complexes, pensez à recourir au machine learning de Radar. Nous en reparlerons à la section Perfectionnement avec le machine learning.

Le nouveau tableau des attributs de règles Radar permet d'effectuer un suivi des mêmes dimensions et de bien d'autres, pour chaque transaction réellement évaluée par Radar et portant le nom exact des attributs Radar.

Le tableau ci-dessus indique l'ensemble d'attributs standard et omet volontairement les signaux que vous personnaliserez en fonction de votre parcours client, tels que les sessions Radar ou les métadonnées.

Si l'on s'appuie sur l'investigation susmentionnée, admettons que vous finissiez par obtenir une règle de ce type :

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :amount_in_usd: > 20 and ::CustomerType:: = 'guest' and :total_charges_per_customer_hourly: > 2

L'étape suivante consistera à confirmer l'impact de cette règle sur vos transactions de paiement. On procédera généralement par le biais de règles de blocage. Consultez notre guide Radar for Fraud Teams : Notions de base sur les règles pour obtenir des conseils sur la rédaction de règles avec une syntaxe adéquate. Une façon simple de tester une règle de blocage est de la créer en mode test et de créer des paiements test manuels afin de vérifier son bon fonctionnement.

Les règles de blocage et les règles de vérification peuvent être testées de façon rétroactive sur Radar, grâce à la fonctionnalité de simulation Radar for Fraud Teams.

L'un des avantages à utiliser les simulations de Radar for Fraud Teams est la prise en compte de l'impact d'autres règles existantes. La maintenance des règles ne constitue pas l'élément central de ce guide, mais le retrait et la mise à jour de règles doivent faire partie de vos processus d'amélioration continue. De façon générale, le nombre de règles dont vous disposez doit être réduit de manière à ce que chaque règle soit, elle aussi, réduite au minimum, et puisse être surveillée via les requêtes de base abordées dans les sections sur la détection et l'investigation, et faire l'objet de tests rétroactifs précis, sans risque d'effets secondaires (par exemple, la règle 2 ne fonctionne que parce que la règle 1 filtre d'autres données).

Vous pouvez également procéder en utilisant des règles de vérification plutôt que des règles de blocage, que nous aborderons à la section suivante.

Perfectionnement et mesures d'atténuation

Pour finir, une fois vos règles de blocage testées, vous mettez en œuvre le modèle visant à prévenir, à surveiller ou à rediriger la fraude. Nous qualifions cette étape de « perfectionnement », car il s'agit d'augmenter la précision de vos mesures globales antifraude et, dans le même temps, de booster le machine learning. Diverses techniques peuvent être utilisées pour augmenter la précision. Parfois, cette étape, autrement dit l'étape de quarantaine ou d'atténuation, est concomitante à celle de la confirmation. Au lieu d'utiliser des règles de vérification, des tests A/B (métadonnées) ou des simulations pour évaluer votre modèle, vous bloquez alors immédiatement les paiements suspects afin de neutraliser le risque immédiat.

Même si vous avez déjà agi face à ces événements, certaines techniques peuvent vous permettre d'affiner le modèle développé aux étapes 1 à 3 en vue d'améliorer les résultats dans le temps :

Perfectionnement avec des règles de vérification

Si vous ne souhaitez pas risquer une augmentation de votre taux de faux positifs, ce qui pourrait avoir un impact sur votre revenu, vous pouvez opter pour la mise en œuvre de règles de vérification. Il s'agit, certes, d'un processus plus manuel qui peut influer sur la fluidité de l'expérience client. Toutefois, les règles de vérification peuvent au bout du compte permettre la validation de davantage de transactions légitimes. (Vous pouvez également ajouter des accélérateurs, sous la forme de règles de vélocité, à des règles de blocage existantes pour des transactions plus ralenties.) Pour une option plus avancée pour l'utilisation de règles de vérification, optez pour le test A/B, qui est tout particulièrement utile lorsqu'il s'agit de gérer le nombre total de cas inclus dans la file de vérification. Vous pouvez exploiter les métadonnées de vos paiements afin de commencer à autoriser une petite partie du trafic tout en effectuant vos tests A/B, par exemple en priorisant les clients connus ou en utilisant un nombre aléatoire. Nous vous recommandons d'ajouter cela à vos règles de blocage plutôt que de créer des règles d'autorisation, car les règles d'autorisation écraseront les règles de blocage et complexifieront le suivi de la performance de la règle de blocage dans le temps.

Optimisation des règles via la surveillance de leurs performances

Pour surveiller les performances d'une règle, vous pouvez vérifier l'objet résultat du paiement dans l'API Payment Intents, en particulier l'objet « règle ». De même, dans Stripe Sigma, vous pouvez utiliser les champscharges.outcome_rule_id, charges.outcome_type et payment_intents.review_id à des fins d'analyse. Voici un exemple illustrant comment suivre les performances d'une règle dans Stripe Sigma à l'aide du tableau spécial décisions d’une règle Radar :

Perfectionnement avec le machine learning

Souvent, l'étape suivant le blocage d'une attaque immédiate est d'affiner la règle à répétition en parallèle du machine learning, afin de réduire le taux de faux positifs, ce qui permet d'autoriser davantage de trafic légitime et de récupérer les revenus prévus.

Prenons pour exemple le blocage basé sur le BIN ou l'IIN. Durant une attaque par test des cartes bancaires, vous avez sûrement ajouté un BIN à une liste de blocage de façon temporaire, afin de laisser aux émetteurs le temps de résoudre les soucis qui se présentent. Bloquer un utilisateur purement et simplement pourrait cependant réduire vos revenus. Une approche plus fine consiste à se montrer plus rigoureux sur la durée et à perfectionner le modèle. Le moment est opportun pour un rappel sur l'écriture de règles efficaces et l'évaluation des risques, en particulier le score de risque de Radar. Nous recommandons généralement d'accompagner le machine learning de Radar de votre intuition. Plutôt que de disposer d'une unique règle qui bloquera l'ensemble des transactions à haut risque, combiner le score à des règles manuelles qui représentent un modèle ou un scénario à risque permet souvent de trouver un meilleur équilibre entre le blocage de trafic malveillant et le passage des revenus légitimes. Par exemple :

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :card_country: in @high_risk_card_countries_to_block and :risk_score: > 65 and :amount_in_usd: > 10

Perfectionnement avec l'authentification 3DS

Comme susmentionné, si ce guide n'aborde pas l'intégralité des éléments relatifs à l'authentification 3D Secure (3DS), il est crucial de l'intégrer à votre stratégie d'atténuation des risques. Par exemple, les transferts de responsabilité peuvent réduire les frais de litige en cas de transactions frauduleuses. Toutefois, ces transactions seront toujours imputées aux programmes de surveillance des cartes et altéreront l'expérience utilisateur. Plutôt que d'opter pour un montant fixe, vous pouvez également affiner cette règle et, au lieu de bloquer l'ensemble des paiements y afférents, exiger une authentification 3DS :

Request 3DS if :card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’

Ensuite, utilisez une règle pour bloquer les cartes qui n'ont pas pu être authentifiées ou qui, pour d'autres motifs, n'entraînent pas de transfert de responsabilité :

Block if (:card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’) and :risk_score: > 65 and :has_liability_shift: != ‘true’

Perfectionnement avec les listes

L'utilisation de listes par défaut ou la mise à jour de listes personnalisées peut constituer un moyen très efficace de bloquer une attaque durant un incident, sans courir le risque de modifier les règles, par exemple en bloquant un client frauduleux. Dans le cadre du perfectionnement, on devra aussi décider quels mécanismes deviendront des règles, changeront un prédicat de règle ou seront simplement porteurs de valeur ajoutée pour une liste existante. Les règles ponctuelles constituent une bonne solution temporaire lors d'un incident, qui pourra ensuite être perfectionnée en prenant la forme d'une liste ou d'une modification apportée à une règle existante.

Processus de retour d'information

Le perfectionnement nécessite également de repartir de l'étape 1, soit de surveiller la performance des règles et les mécanismes de fraude. Une bonne surveillance est le fruit de socles établis et de modifications minimes et uniques, et ce, pour une traçabilité, une précision et un rappel de tests rétroactifs parfaitement optimisés. C'est pour cette raison que nous recommandons de ne modifier les règles et les prédicats que sous la forme de déploiements clairs et distincts. Autrement, il faut s'appuyer sur des listes, des vérifications, et une approche proactive du blocage et du remboursement.

Comment Stripe peut vous aider

Radar pour les plateformes

Vous gérez une plateforme qui utilise Stripe Connect ? Toute règle que vous créerez ne s'appliquera qu'aux paiements créés sur le compte de la plateforme (selon la terminologie de Connect, il s'agit de paiements de destination ou
pour autrui). Les paiements créés directement sur le compte connecté sont régis par les règles dudit compte.

Radar pour Terminal

Les paiements Stripe Terminal ne sont pas vérifiés par Radar. En d'autres termes, si vous utilisez Terminal, vous pouvez rédiger des règles à partir de la fréquence liée à l'IP sans bloquer les paiements par TPE.

Services aux entreprises de Stripe

Chez Stripe, l'équipe de services aux entreprises peut vous aider à mettre en œuvre un processus d'amélioration de la gestion de la fraude sur la durée. Vous souhaitez renforcer votre intégration actuelle ou créer de nouveaux modèles économiques ? Laissez-vous guider par nos experts pour développer votre solution Stripe existante.

Conclusion

Dans ce guide, nous avons découvert comment Stripe Sigma et Data Pipeline peuvent s'employer pour créer un socle ainsi que divers modèles de fraude représentant des scénarios et des mécanismes d'attaques dont seuls votre entreprise et vous-mêmes pouvez juger de l'adéquation. Nous avons également abordé les possibilités d'utilisation plus étendue et plus pointue de Radar afin de faire face à un plus grand nombre de transactions frauduleuses à partir de vos règles personnalisées.

Dans la mesure où la fraude aux paiements évolue sans cesse, ce processus doit évoluer de concert afin de garder le rythme, comme nous l'avons souligné en lien avec notre modèle de détection, d'investigation, de confirmation et de perfectionnement et d'atténuation. La mise en œuvre de ces cycles sur la durée, avec une boucle de rétroaction rapide, devrait vous permettre de passer moins de temps à gérer les incidents et davantage à mettre au point une stratégie antifraude proactive.

Pour en savoir plus sur Radar for Fraud Teams, cliquez ici. Si vous utilisez déjà Radar for Fraud Teams, consultez la page des règles de votre Dashboard pour commencer à définir vos règles.

Pour en savoir plus sur Stripe Sigma, cliquez ici, et pour en savoir plus sur Stripe Data Pipeline, cliquez ici.