L’évaluation du risque de fraude est un processus continu consistant à identifier les vecteurs, les modèles et les scénarios d’attaque, puis à les atténuer. En travaillant étroitement avec les utilisateurs, notre équipe de services professionnels a constaté que les entreprises les plus efficaces dans ce domaine sont souvent celles où analystes en fraude et analystes de données collaborent, en combinant Stripe Radar for Fraud Teams et des produits de données Stripe, tels que Stripe Sigma ou Stripe Data Pipeline, pour identifier à la fois les modèles de fraude courants et ceux spécifiques à leur entreprise.

Radar for Fraud Teams permet de détecter et prévenir la fraude et offre la possibilité de créer une configuration de fraude sur mesure, propre à votre entreprise, avec des règles personnalisées, des rapports et des vérifications manuelles. Stripe Sigma est une solution de rapports qui rend toutes vos données transactionnelles, de conversion et clients accessibles dans un environnement interactif via le Stripe Dashboard. Data Pipeline fournit les mêmes données, mais les envoie automatiquement à votre entrepôt de données Snowflake ou Redshift, afin qu’elles soient consultables aux côtés de vos autres données d’entreprise.

Ces outils fonctionnent parfaitement ensemble pour couvrir les quatre piliers d’un processus efficace de gestion de la fraude : Détection, Enquête, Confirmation et Affinement et atténuation, que nous aborderons plus en détail par la suite.

L’intérêt d’utiliser Radar for Fraud Teams 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, conjointement avec vos propres données incluant la préautorisation, le parcours utilisateur, la conversion et les informations de session afin de distinguer les transactions légitimes des comportements frauduleux des clients. De cette façon, vous pouvez optimiser :

1. Délai de détection pour identifier et prévenir la fraude de manière proactive
   
2. Temps de réaction pour élaborer des règles préventives et de détection
   
3. Coût de fraude, qui comprend les remboursements, les frais de litiges, l’attrition client et les paiements refusés par l’émetteur
   

Notre rapport sur l’état des fraudes en ligne met en évidence les frais d'exploitation des processus de vérification manuelle et indique que « plus les [entreprises] sont grandes, plus la proportion de transactions qu'elles vérifient est faible ». En automatisant ces processus, vous pouvez donner à vos analystes de la fraude plus de temps pour identifier de nouveaux vecteurs d'attaque et développer des règles de prévention et de détection. Cela signifie que vous pouvez trouver un meilleur équilibre entre le blocage du trafic frauduleux et la réduction de la friction pour les clients légitimes (attrition).

Un processus de gestion de la fraude sur les transactions de base

Supposons que vous disposiez d’un processus élémentaire de gestion de la fraude transactionnelle de détection, d’enquête, de confirmation, d’affinement et d’atténuation qui se déroule dans un cadre de risque plus large.

• La détection, également connue sous le nom d’identification, de prédiction ou de réponse aux incidents, est la découverte d’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 (par le biais de règles de détection ou d’une surveillance par rapport à votre référence), automatisée (par apprentissage automatique ou détection d’anomalies) ou déclenchée à l’extérieur (par exemple, les commentaires des clients ou les litiges). En matière de détection, l’apprentissage automatique de Radar peut automatiquement trouver des modèles de fraude courants, tandis que Stripe Sigma peut vous aider à trouver des modèles spécifiques à votre entreprise.
  
• L’enquête, ou analyse exploratoire, est l’évaluation des Paiements ou du comportement suspects afin de mieux comprendre l’impact de l’entreprise; cela implique souvent une vérification par rapport à des données plus larges pour éliminer le bruit. En règle générale, les analystes fraude utiliseront la file de vérification Radar ou le Dashboard de paiement de Stripe pour enquêter.
  
• La confirmation, également appelée modélisation ou test rétroactif, est la généralisation du vecteur d’attaque de fraude vérifiée en dimensions et en candidats modèles. Cela couvre également la validation et l’évaluation d’impact à partir de données antérieures, et par rapport à d’autres règles. Les fonctionnalités de test rétroactif et de simulation de Radar peuvent aider les analystes fraude à le faire, mais les ingénieurs de données peuvent utiliser Stripe Sigma pour un plus large éventail de scénarios.
  
• Leraffinement et l'atténuation, parfois appelés action ou confinement, sont la mise en œuvre du modèle de mappage des dimensions et des caractéristiques significatives sur les prédicats de règles Radar pour prévenir, surveiller ou réacheminer la fraude. Traditionnellement, il s'agissait de règles préventives statiques, mais maintenant que l'apprentissage automatique est une contrepartie importante pour les humains et que l'objectif est d'augmenter la précision, le raffinement est le terme le plus approprié. Il s'agirait généralement de règles de blocage ou de listes dans Radar.
  

Une mise en œuvre basique de ce traité pourrait impliquer des cycles itératifs tels que des contrôles quotidiens, des sprints ou des libérations d'une configuration de détection de fraude établie sur des règles. Cependant, étant donné que les temps de cycle peuvent être différents et que des boucles de rétroaction peuvent se produire simultanément, nous préférons voir cela comme un traité continu.

Ensuite, nous examinerons en détail chacun de ces quatre piliers dans le contexte d’un scénario hypothétique et vous montrerons comment Radar for Fraud Teams et Stripe Sigma ou Data Pipeline peuvent vous aider.

Notre scénario

Dans notre scénario hypothétique, nous analyserons le comportement qui se produit sur une période donnée, par opposition à un pic soudain.

Supposons maintenant que vous êtes une entreprise de commerce en ligne. Votre suite d’observabilité a mis en place un suivi par lien de rappel https qui trace en temps réel divers graphiques sur les tendances de paiement. Vous remarquez une augmentation constante des refus de paiement pour une marque de carte appelée « Mallory » au cours des derniers jours, pour un produit qui n’est habituellement pas vendu dans la région où cette marque est couramment utilisée. (Remarque : Mallory est une marque fictive utilisée ici pour illustrer le scénario ; par exemple, elle pourrait ne pas figurer dans le Enhanced Issuer Network.) Il n’y a ni promotion ni incident pouvant expliquer ce changement, et votre équipe doit donc enquêter pour déterminer la marche à suivre.

Détection

Les règles par défaut de Stripe utilisent l'apprentissage automatique pour prédire, détecter et bloquer un nombre substantiel de Paiements frauduleux. Le Dashboard Radar analytics peut vous donner un aperçu rapide des tendances en matière de fraude. Et pour les entreprises qui ont besoin de plus de contrôle sur les Paiements à vérifier, autoriser ou bloquer, les règles sont un outil puissant pour personnaliser votre protection contre la fraude.

Avant de pouvoir détecter de nouveaux schémas de fraude, vous devez d’abord disposer d’une base de référence de signaux prédictifs, tels que la performance de vos règles existantes. Autrement dit, vous devez savoir ce qui est « normal » pour votre entreprise, ou à quoi ressemble une « bonne » transaction. C’est à ce moment que vos analystes fraude et vos ingénieurs de données collaborent (ils peuvent aussi travailler avec les équipes DevOps et leur suite d’observabilité). Dans notre scénario hypothétique, une augmentation des transactions refusées provenant de types de cartes « Mallory » est détectée grâce à une surveillance continue.

Tableaux Stripe Sigma avec données pertinentes sur la fraude

Pour détecter de nouveaux schémas émergents, vous devez d’abord établir une performance de référence à l’aide de paramètres comme le taux de refus/autorisation des émetteurs et le taux de blocage Radar. Ensuite, vous devez interroger leslitiges frauduleux, les alertes précoces de fraude (enregistrements de fraude émetteur) ainsi que les transactions de paiement présentant une forte vélocité, un taux élevé de refus d'émetteur ou des hauts scores de risque Radar. Idéalement, vous devez programmer cette requête pour qu'elle s'exécute quotidiennement en établissant les données disponibles et vous aurez tous vos tableaux de bord visualisés avec les données passées, y compris des découpes hebdomadaires et mensuelles, sans même avoir à interroger manuellement Stripe Sigma ou votre entrepôt de données. Cela vous permettra d’accélérer votre temps de réponse en cas d’incident.

Voici les tableaux les plus pertinents :

Vos analystes fraude ou d’affaires devraient déjà avoir une idée des dimensions de ventilation supplémentaires qu’il pourrait être pertinent d’évaluer, en fonction du domaine de votre entreprise. Le tableau Radar Rule Attributes dans Radar for Fraud Teams fournit des informations détaillées sur les transactions existantes évaluées par Radar, mais elle ne couvre pas l’historique avant avril 2023 et n’inclut pas les métadonnées ni les résultats finaux. Auparavant, vous auriez interrogé les champs suivants :

Le nouveau tableau Radar Rule Attributes suit les mêmes dimensions et bien d'autres encore pour chaque transaction évaluée par Radar avec le nom exact des attributs Radar. Par exemple, vous pouvez suivre la catégorie name_count_for_card_weekly

Il existe différentes façons de visualiser les tendances, mais un graphique linéaire pivoté par catégorie est un moyen simple de comparer facilement avec d’autres facteurs. Lors de l’approfondissement de l’analyse dans la phase d’enquête, vous pourriez vouloir combiner plusieurs catégories. Voici un exemple de tableau montrant la répartition par segment de produit pour l’augmentation des transactions refusées provenant des types de cartes « Mallory » :

Et vous pouvez le visualiser ainsi dans l’outil de tableur de votre choix :

Examinons de plus près un exemple de requête Stripe Sigma ou Data Pipeline pour obtenir des données de référence. Dans la requête ci-dessous, vous verrez les taux quotidiens de contestation, de refus et de blocage, ainsi que d’autres indicateurs, présentés dans des colonnes distinctes. Pendant les phases de Détection et d’Enquête, des données larges et dispersées dans des colonnes séparées sont souvent plus faciles à visualiser. Cela facilite également le mappage des colonnes sur les prédicats Radar ultérieurement. Toutefois, vos data scientists pourraient préférer un format “haut et dense” pour une analyse exploratoire pendant l’enquête, ou pour l’apprentissage automatique lors des phases de Confirmation, Affinement et Atténuation.

Dans cet exemple, nous incluons des métadonnées de paiement pour ventiler les résultats par segment de produit. Dans une approche large, nous aurions besoin de requêtes similaires pour la marque de carte (« Mallory ») et le type de financement, selon notre scénario. Nous dédupliquons ici les tentatives de relance pour nous concentrer sur les intentions de paiement réelles et mieux évaluer l’ampleur. Nous avons choisi de dédupliquer sur les intentions de paiement des intégrations plus poussées peuvent transmettre un champ (par exemple, un ID de commande dans les métadonnées) afin d’assurer la déduplication tout au long du parcours utilisateur. Cet exemple montre comment augmenter la précision de vos mesures anti-fraude en ajoutant un facteur supplémentaire. Dans notre scénario, il s’agit du segment de produit « cartes-cadeaux ». Nous reviendrons sur les moyens d’accroître cette précision dans la section Raffinement et Atténuation.

Cette requête n'inclut pas le délai réel en ce qui concerne les litiges, ce qui est un indicateur de retard, mais nous avons inclus quelques exemples d'indicateurs, tels que les relances comme indicateur de test (frauduleux) de cartes. Dans cette requête, nous obtenons quelques indicateurs quotidiens de manière simple :

• Le volume de paiements, aussi bien en valeur brute comme qu’en valeur hors doublons : par exemple, 1 150 paiements par jour, dont 100 refusés et 50 bloqués par Radar, sur 1 000 Intentions de paiement.
  
• Le taux d'autorisation : dans cet exemple, 90 % pour les paiements bloqués, car les paiements bloqués ne sont pas envoyés à l'émetteur, et 100 % pour les Intentions de paiement, car ils ont tous finalement été relancés avec succès.
  
• Le risque élevé et le taux de blocage : Dans ce cas, les deux seraient de 1,6 % (les 50 risques élevés ont également été bloqués).
  
• Le taux de contestation rétrospectif des paiements pour une même période : par exemple, 5 paiements sur 1 000 ont été contestés. Le nombre par jour de paiement augmentera à mesure que d’autres litiges surviendront; nous incluons donc l’heure d’exécution de la requête pour suivre l’évolution.
  

Comme indiqué précédemment, nous avons simplifié ces requêtes pour en faciliter la lecture. En réalité, cette requête comporterait encore plus de dimensions, comme les tendances, les écarts ou les différences de pertes.

Nous avons aussi inclus un exemple de moyenne glissante sur 30 jours à l’aide d’une fonction de fenêtre. Des approches plus complexes, comme l’analyse des percentiles au lieu des moyennes pour repérer des attaques marginales, sont possibles, mais rarement nécessaires au départ pour la détection de fraude, puisque les tendances sont plus importantes que des chiffres parfaitement précis.

Une fois que vous avez établi une base de référence, vous pouvez commencer à suivre les anomalies et les tendances afin d’enquêter, par exemple, sur une hausse de la fraude ou du taux de blocage provenant d’un certain pays ou mode de paiement (dans notre scénario hypothétique, il s’agirait de la marque de carte « Mallory »). Les anomalies sont habituellement analysées au moyen de rapports ou d’analyses manuelles dans le Dashboard, ou encore grâce à des requêtes ad hoc dans Stripe Sigma.

Enquête

Une fois que vos analystes ont détecté une anomalie à examiner, l’étape suivante consiste à effectuer une requête dans Stripe Sigma (ou dans votre entrepôt de données via Data Pipeline) pour explorer les données et élaborer une hypothèse. Il est recommandé d’inclure certaines dimensions de ventilation selon vos hypothèses, par exemple : les modes de paiement (utilisation de cartes), le canal ou la plateforme (métadonnées), le client (réputation) ou les produits (catégorie de risque) susceptibles de présenter des risques de fraude. Plus tard, lors de l’étape de confirmation, ces dimensions pourront être appelées « fonctionnalités » et seront mappées aux prédicats Radar.

Reprenons notre hypothèse : un grand volume de transactions sur des cartes prépayées « Mallory » présente des taux de fraude plus élevés. Vous pouvez représenter cela comme une dimension de regroupement sur laquelle pivoter dans votre outil d’analyse. Généralement, à cette étape, la requête est itérée et ajustée, il est donc conseillé d’inclure différents candidats de prédicats sous forme de versions réduites ou étendues de l’hypothèse, en supprimant les fonctionnalités mineures, afin d’évaluer leur impact.

Cette approche vous donnerait une idée de l’ampleur afin de prioriser l’impact. Le tableau indique, avec une confiance raisonnable, que le candidat règle 3 semble capturer l’excès de transactions malveillantes. Une évaluation plus sophistiquée pourrait se baser sur l’exactitude, la précision ou le rappel. Vous pouvez générer un résultat similaire avec la requête ci-dessous.

Dans cette requête, nous avons supprimé les doublons pour des raisons de lisibilité, mais avons inclus le taux de litiges et le taux d'alerte de suspicion de fraude, qui sont importants pour les programmes de surveillance des marques de cartes. Cependant, il s'agit d'indicateurs à la traîne et dans cette requête simplifiée, nous ne les catégorisons qu'à rebours. Nous avons également inclus des échantillons de paiement arbitraires pour le recoupement et l'étude plus approfondie des tendances trouvées dans la requête. Nous en reparlerons plus tard.

Vous pouvez décomposer des indicateurs supplémentaires en un histogramme pour identifier les clusters, ce qui peut être utile pour définir des règles de vélocité que vous pouvez utiliser pour limiter le débit (par exemple, total_charges_per customer_hourly).

L’identification des tendances via l’analyse d’histogrammes est un excellent moyen de comprendre le comportement souhaité de vos clients tout au long de leur cycle de vie et de leur entonnoir de conversion. L’ajouter à la requête ci-dessus serait trop complexe, mais voici un exemple simple de décomposition, sans logique complexe de fenêtres glissantes, en supposant que vous disposez d’un type de client dans les métadonnées (par exemple, des utilisateurs invités) :

Dans notre scénario, vous ne voudrez peut-être pas bloquer toutes les cartes prépayées de « Mallory », mais vous souhaiterez tout de même identifier avec confiance d’autres facteurs de risque corrélés. Cette requête de vélocité pourrait augmenter la confiance pour, par exemple, éviter de bloquer les clients invités à faible fréquence.

Une façon simple d’analyser la situation consiste à examiner des échantillons directement dans le Dashboard via la vue « Related Payments » afin de comprendre le comportement, c’est-à-dire le vecteur d’attaque ou le schéma frauduleux, ainsi que les informations sur les risques Radar associées. C’est pourquoi nous avons inclus des échantillons de paiements arbitraires dans la requête ci-dessus. Vous pouvez également repérer des paiements plus récents qui ne sont pas encore disponibles dans Stripe Sigma. Une approche plus défensive et personnalisée consiste à modéliser votre hypothèse sous forme de règle de vérification, qui autorise toujours les paiements tout en les dirigeant vers vos analystes pour une révision manuelle. Certains clients utilisent cette méthode pour envisager de rembourser les paiements inférieurs aux frais de contestation, tout en bloquant ceux qui les dépassent.

Confirmation

À l’avenir, supposons que le modèle que vous avez identifié n’est pas simple, qu’il ne peut être atténué en remboursant et en bloquant le client frauduleux et qu’il ne relève pas seulement 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. Ce n'est pas un problème d'optimisation anodin, car le montant optimal de fraude est non nul. Parmi tous les différents modèles candidats, choisissez le modèle 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 écrites d'abord, puis validées par rapport à vos données. (Vous pouvez également le faire en annulant, c'est-à-dire découvrir d'abord les modèles, puis écrire des règles.) Par exemple, au lieu d'écrire une règle par pays, rédigez une règle comme celle-ci qui facilite la confirmation :

Bloquer si :card_funding : = 'prépayé et :card_country : dans @preaid_card_countries_to_block

La requête partagée ci-dessus dans la section Enquête peut également être utilisée comme modèle, sauf que différentes valeurs seront soulignées. Nous en reparlerons plus tard lorsque nous aborderons les techniques de raffinement et d’atténuation.

Mappage du schéma Stripe Sigma à la règle Radar

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

Les deux derniers items, risk_level et risk_score, ne sont pas similaires aux autres, car le modèle d’apprentissage automatique lui-même est dérivé des autres facteurs. Au lieu d’écrire des règles trop complexes, nous vous recommandons de vous appuyer sur l’apprentissage automatique de Radar. Nous en reparlerons plus en détail dans la section Raffinement par apprentissage automatique.

Le nouveau tableau des attributs de règle Radar suit les mêmes dimensions et beaucoup plus pour chaque transaction qui a été réellement évaluée par Radar avec le nom exact des attributs Radar.

Le tableau ci-dessus montre l'ensemble Standard d'attributs et omet délibérément les signaux que vous personnaliseriez pour votre parcours client, tels que dessessions Radar ou métadonnées.

Sur la base de l’enquête ci-dessus, supposons que vous arriviez à une règle qui ressemble à ceci :

Bloquer si :card_funding : = 'prepaid' et :card_funding: = 'mallory' et :amount_in_usd: > 20 et ::Type Client:: = 'guest' et :total_charges_per_customer_hourly: > 2

L’étape suivante consiste à confirmer l’impact de cette règle sur vos transactions de paiement réelles. En général, cela se fait à l’aide de règles de blocage. Consultez notre guide Radar for Fraud Teams : Rules 101 pour obtenir des conseils sur la rédaction de la syntaxe correcte des règles. Un moyen simple de tester une règle de blocage consiste à la créer en mode test et à effectuer des paiements manuels de tests pour valider qu'elle fonctionne comme prévu.

Les règles de blocage et les règles de vérification peuvent être testées rétroactivement dans Radar grâce à la fonctionnalité Simulation Radar for Fraud Teams.

Un des avantages des simulations Radar for Fraud Teams est qu’elles tiennent compte de l’effet d’autres règles existantes. Ce guide ne se concentre pas sur la maintenance des règles, mais la suppression et la mise à jour des règles devraient également faire partie de votre processus d’amélioration continue. En général, le nombre de règles doit rester suffisamment réduit pour que chaque règle soit atomique, puisse être surveillée à l’aide des requêtes de référence développées lors des phases de Détection et d’Enquête, et testée clairement sans risque d’effets secondaires (par exemple, la règle 2 ne fonctionne que parce que la règle 1 filtre autre chose).

Vous pouvez également utiliser des règles de vérification au lieu des règles de blocage, que nous aborderons dans la section suivante.

Raffinement et atténuation

Enfin, après avoir testé vos règles de blocage, vous appliquez le modèle pour prévenir, surveiller ou rediriger la fraude. Nous parlons de raffinement, car il s’agit d’accroître la précision de vos mesures anti-fraude globales, notamment en combinaison avec l’apprentissage automatique. Pour améliorer cette précision, diverses techniques peuvent être mises en œuvre. Parfois, cette étape — également appelée confinement ou atténuation — est effectuée simultanément avec la confirmation, où, 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 immédiatement les paiements suspects afin de réduire le risque immédiat.

Même si des mesures ont déjà été prises, certaines techniques permettent de raffiner le modèle développé aux étapes 1 à 3 afin d’en améliorer les résultats au fil du temps :

Raffinement à l’aide des règles vérifier

Si vous ne voulez pas risquer un taux de faux positifs plus élevé, ce qui pourrait avoir une incidence sur vos revenus, vous pouvez opter pour la mise en œuvre de règles de vérification. Bien qu’il s’agisse d’un traitement davantage manuel et qui peut complexifier l’expérience client, les règles de vérification peuvent permettre à un plus grand nombre de transactions légitimes de se poursuivre. (Vous pouvez également ajouter un étranglement, sous forme de règles de vélocité, aux règles de blocage existantes pour les transactions à rythme plus lent.) Une option plus Avancée pour l’utilisation des règles de vérification est le test A/B, qui est particulièrement utile pour gérer le nombre total de cas dans la file de vérification. Vous pouvez tirer parti des métadonnées de vos Paiements pour commencer à autoriser une petite quantité de trafic pendant le test A/B, par exemple, à partir de clients connus ou simplement en utilisant un nombre aléatoire. Nous vous recommandons d’ajouter cela aux règles de blocage au lieu de créer des règles d’autorisation, car les règles d’autorisation remplaceront les blocs et rendront donc plus difficile le catégorie de la performance de la règle de blocage au fil du temps.

Optimisation des règles en surveillant leur performance

Pour surveiller les performances de la règle, vous pouvez vérifier l'objet Issue du Paiement dans l'API Payment Intents, en particulier l'objet Rule. De même, dans Stripe Sigma vous pouvez utiliser les champs charges.outcome_rule_id, charges.outcome_type et paiement_intents.review_id pour l'analyse. Voici un exemple de catégorie de performance d'une règle dans Stripe Sigma utilisant le tableau de décisions de Radar :

Raffinement par apprentissage automatique

Souvent, l’étape qui intervient après le blocage d’une attaque immédiate consiste à affiner de manière itérative la règle parallèlement à l’apprentissage automatique pour réduire les faux positifs, ce qui permet d’obtenir plus de trafic légitime, et partant de revenus.

Prenons l'exemple du blocage du NIB ou de l'IIN (numéro d'identification de l'émetteur). Lors d'une attaque de test (frauduleuse) de cartes, vous avez peut-être temporairement ajouté un NIB à une liste de blocage, ce qui laisse le temps aux émetteurs de corriger leurs lacunes. Bloquer directement un émetteur pourrait toutefois réduire vos revenus ; une approche plus raffinée consiste à exercer une surveillance accrue au fil du temps et à affiner le modèle. C’est le moment idéal pour revoir comment rédiger des règles efficaces et évaluer les risques, en particulier l’indice de risque de Radar. Nous recommandons généralement de combiner l’apprentissage automatique de Radar avec votre intuition. Plutôt que d’avoir une seule règle pour bloquer toutes les transactions à haut risque, combiner l’indice avec des règles manuelles représentant un modèle ou un scénario de risque permet souvent de mieux équilibrer le blocage du trafic malveillant et la préservation des revenus. Par exemple :

Bloquer si :card_funding : = 'prepaid' et :card_funding : = 'mallory' et :card_country : dans @high_risk_card_countries_to_block et :risk_score : > 65 et :amount_in_usd : > 10

Raffinement avec 3DS

Comme mentionné précédemment, bien que ce guide ne couvre pas l'étendue de l'authentification 3D Secure (3DS), vous devriez l'envisager dans le cadre de votre stratégie en matière d'atténuation des risques. Par exemple, bien que le transfert de responsabilité puisse réduire vos frais concernant les litiges pour les transactions frauduleuses, ces transactions sont toujours prises en compte dans le cadre des programmes de surveillance des cartes, et avec cela votre expérience utilisateur. Au lieu d'un montant fixe, vous pourriez affiner cette règle de « bloquer tous les paiements pertinents » à effectuer une « requête 3DS » :

Requête 3DS si :card_country : dans @high_risk_card_countries_to_block ou :ip_country : dans @high_risk_card_countries_to_block ou :is_anonymous_ip : = ‘true’ ou :is_disposable_email : = ‘true’

Ensuite, utilisez une règle pour bloquer les cartes qui n’ont pas été identifiées avec succès ou qui, pour d'autres raisons, n'offrent pas de transfert de responsabilité :

Bloquer si (:card_country : dans @high_risk_card_countries_to_block ou :ip_country: dans @high_risk_card_countries_to_block ou :is_anonymous_ip : = ‘true’ ou :is_disposable_email : = ‘true’) et :risk_score: > 65 et :has_liability_shift : != ‘true’

Affinement à l’aide des listes

Utiliser les listes par défaut ou maintenir des listes personnalisées peut être un moyen très efficace de bloquer une attaque lors d’un incident, sans risquer de modifier les règles ; par exemple, en bloquant un client frauduleux, un domaine courriel ou un pays de carte. Une partie de l’affinement consiste à déterminer quels motifs doivent devenir une règle, lesquels doivent modifier un prédicat de règle, et lesquels peuvent simplement enrichir une liste existante. Les règles temporaires (breakglass) sont un bon exemple de solution de contournement pendant un incident, qui peut ensuite être transformée en une liste ou en une modification d’une règle existante.

Traité de rétroaction

Le raffinement signifie également revenir à l'étape 1, c’est-à-dire surveiller la performance de vos règles et vos schémas de fraude. Une bonne surveillance repose sur des niveaux de référence établis et sur des changements atomiques uniques pour assurer une traçabilité, une précision et un rappel optimaux lors des tests rétroactifs. Pour cette raison, nous recommandons de ne modifier les règles et les prédicats que dans le cadre de déploiements clairs et distincts, et de se fier autrement aux listes, aux vérifications et aux blocages ou remboursements proactifs.

Comment Stripe peut vous aider

Radar pour les plateformes

Êtes-vous une plateforme qui utilise Stripe Connect? Si oui, toutes les règles que vous créez ne s'appliquent qu'aux Paiements créés sur le compte de la plateforme (en conditions associées, il s'agit de destination ou pour le compte de
paiements). Les Paiements créés directement sur le compte connecté sont soumis aux règles de ce compte.

Radar pour Terminal

Les paiements Stripe Terminal ne sont pas contrôlés par Radar. Cela signifie que si vous utilisez Terminal, vous pouvez rédiger des règles établies sur la fréquence IP sans vous soucier de bloquer vos Paiements en personne.

Services aux professionnels Stripe

L’équipe des services aux entreprises de Stripe peut vous aider à mettre en œuvre un traité de gestion de la fraude en constante amélioration. Du renforcement de votre intégration actuelle au lancement de nouveaux modèles d’entreprise, nos experts vous fournissent des conseils pour vous aider à développer votre solution Stripe existante.

En conclusion

Dans ce guide, nous avons vu comment Stripe Sigma ou Data Pipeline peuvent être utilisés pour construire à la fois une base de référence ainsi que divers modèles de fraude qui représentent des scénarios d'attaque et des modèles que vous et votre entreprise seuls pouvez juger. Nous avons également montré comment vous pouvez étendre et affiner Radar pour réagir à un plus large éventail de transactions frauduleuses établies sur vos règles personnalisées.

Comme la fraude aux paiements évolue en permanence, ce processus doit lui aussi évoluer continuellement afin de suivre le rythme, comme nous l’avons expliqué dans notre modèle Détection, Enquête, Confirmation et Affinement et atténuation. Exécuter ces cycles de manière continue avec une boucle de rétroaction rapide devrait vous permettre de passer moins de temps à réagir aux incidents et plus de temps à développer une stratégie proactive de lutte contre la fraude.

Pour en savoir plus sur Radar for Fraud Teams, cliquez ici. Si vous êtes déjà un utilisateur Rada  for Fraud Teams, payez la page Règles de votre Dashboard pour démarrer la rédaction de règles.

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