L'évaluation du risque de fraude est un processus continu d'identification et d'atténuation des vecteurs, des mécanismes et des scénarios d'attaque. Dans le cadre d'une collaboration étroite avec les utilisateurs, notre équipe des services professionnels a observé que les entreprises qui procèdent de la manière la plus efficace ont souvent recours à des analystes spécialisés dans la fraude et dans les données qui, ensemble, utilisent une combinaison de produits Stripe Data et Stripe Radar for Fraud Teams tels que Stripe Sigma ou Stripe Data Pipeline, afin d'identifier les mécanismes de fraude fréquents et ceux plus spécifiques de leur activité.

Radar for Fraud Teams aide à la détection et à la prévention de la fraude et vous permet de créer une configuration antifraude sur mesure pour votre entreprise grâce à des règles personnalisées, des fonctionnalités de reporting et des examens manuels. Sigma est une solution de reporting qui rassemble toutes les données relatives à vos clients, à vos conversions et à vos transactions au sein d'un environnement interactif sur votre Dashboard Stripe. Data Pipeline fournit des données identiques, mais les envoie automatiquement à votre entrepôt de données Snowflake ou Redshift, de façon à ce qu'elles soient accessibles en parallèle des autres données relatives à votre entreprise.

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 Sigma ou Data Pipeline

L'objectif majeur de l'utilisation de Radar for Fraud Teams avec Sigma ou Data Pipeline est de comparer les données Radar (telles que les métadonnées) avec vos données, y compris en ce qui concerne la préautorisation, le parcours utilisateur, les conversions et les informations de session, afin de distinguer les transactions légitimes des comportements client frauduleux. Vous pourrez ainsi optimiser les facteurs suivants :

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

Notre état des lieux de la fraude en ligne met en lumière les frais d'exploitation liés aux processus d'examen manuels et le fait que « plus les [entreprises] sont grandes, plus la part des transactions qu'elles vérifient est faible ». En automatisant ces processus, vous donnerez davantage de temps à vos analystes en matière de fraude pour l'identification de nouveaux vecteurs d'attaque et le développement de règles de prévention et de détection. En d'autres termes, vous parviendrez à un meilleur équilibre entre le blocage du trafic frauduleux et le maintien d'une expérience fluide pour les clients légitimes, pour réduire l'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 (on parle aussi d'identification, de prédiction ou de traitement de l'incident) constitue la découverte d'un point de données qui justifie la réalisation d'un examen plus poussé. La détection peut être manuelle (lors d'un incident, par exemple), semi-automatisée (via des règles de détection ou un dispositif de surveillance comparative au regard de vos données habituelles), automatisée (via le machine learning ou la détection d'anomalies), ou encore déclenchée par des éléments externes (commentaires client ou litiges, etc.). Dans le cadre de cette détection, le machine learning de Radar est capable d'identifier automatiquement les mécanismes de fraude fréquents tandis que Sigma peut vous aider à déterminer les mécanismes propres à votre activité.
  
• L'investigation, ou analyse exploratoire, consiste à évaluer les paiements ou les comportements suspects en vue de mieux en comprendre l'impact sur l'entreprise. Cela implique généralement une comparaison avec un ensemble de données plus conséquent, afin d'éliminer tout bruit éventuel. En général, les analystes en matière de fraude utiliseront la file de vérification Radar ou le Dashboard Payments de Stripe pour effectuer leurs recherches.
  
• La confirmation, ou encore « modélisation » ou « tests rétroactifs », est la généralisation du vecteur d'attaque frauduleuse vérifié à plusieurs dimensions et candidats-modèles. Cela comprend également la validation et l'évaluation de l'impact à partir de données antérieures et en comparaison avec d'autres règles. La fonctionnalité de simulation et de tests rétroactifs de Radar peut aider les analystes dans cette démarche, mais les ingénieurs de données pourront utiliser Sigma pour bénéficier d'un éventail plus important de scénarios.
  
• Le perfectionnement et les mesures d'atténuation (on parle également d'action ou de quarantaine) consistent en la mise en œuvre d'un modèle avec mappage des dimensions et des caractéristiques majeures aux prédicats des règles Radar afin de prévenir, de surveiller ou de rediriger les cas de fraude. Ces règles auraient auparavant été des règles préventives statiques, mais maintenant que le machine learning occupe une place importante et que le but est de gagner en précision, le terme « perfectionnement » est plus approprié. Cela passe généralement par des règles de blocage ou des listes sur 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 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 Sigma de données utiles sur la fraude

Pour identifier des mécanismes naissants, il vous faudra tout d'abord établir ce fameux socle de performances avec des fonctionnalités telles que le taux de refus/d'autorisation de paiement par l'émetteur et le taux de blocage Radar. Ensuite, il faudra effectuer une requête quant aux litiges pour fraude, aux alertes de suspicion de fraude (enregistrements de fraude d'émetteur) et aux transactions de paiement à vélocité élevée, à un taux élevé de refus de l'émetteur ou à des scores de risque Radar élevés. Dans l'idéal, vous planifierez l'exécution quotidienne de cette requête à partir des données disponibles et disposerez de tableaux de bord incluant des données antérieures, par semaine et par mois, sans avoir à effectuer de requête manuelle auprès de Sigma ou de votre centrale de données. Cela réduira votre temps de réaction en cas d'incident.

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 data scientists 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 Sigma.

Investigation

Une fois que les analystes ont trouvé une anomalie à examiner, l'étape suivante consiste à effectuer une requête dans 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.

Afin de simplifier vos recherches, vous pouvez directement jeter un œil aux exemples sur le Dashboard via la section relative aux paiements associés, afin de mieux comprendre le comportement, autrement dit le vecteur d'attaque ou le mécanisme de fraude, ainsi que les données sur les risques de Radar. C'est la raison pour laquelle nous avons introduit des échantillons de paiement dans la requête ci-dessus. De cette façon, vous trouverez également davantage de paiements récents qui ne sont pas encore disponibles sur Sigma. Pour vous protéger davantage et de façon plus personnalisée, vous pouvez modéliser votre hypothèse sous forme de règle de vérification qui autorise les paiements tout en les redirigeant vers vos analystes pour une vérification manuelle. Certains clients procèdent ainsi en vue de remboursements éventuels dont le montant n'excède pas les frais pour litige, et bloquent les paiements qui dépassent ce montant.

Confirmation

Désormais, partons du principe que le mécanisme identifié n'est pas simple, ne peut être atténué via un remboursement et un blocage du client à l'origine de la fraude et ne se trouve pas parmi les cas qui ne nécessitent qu'une liste de blocage par défaut.

Après avoir identifié et priorisé un nouveau mécanisme à traiter, vous devrez analyser son impact potentiel sur vos revenus légitimes. Il ne s'agit pas d'un simple problème d'optimisation le taux optimal de fraude se situe toujours au-dessus de zéro. Parmi l'ensemble des candidats pour le modèle, choisissez celui qui représente le meilleur compromis pour vous en matière d'appétit pour le risque, qu'il s'agisse d'une question d'ampleur, de précision ou de rappel. Ce processus est parfois appelé test rétroactif, en particulier lorsque les règles sont tout d'abord écrites, puis validées avec vos données. (Vous pouvez également opérer le cheminement inverse, soit identifier les mécanismes, puis écrire les règles.) Par exemple, plutôt que d'écrire une règle par pays, optez pour une règle telle que celle ci-dessous, qui facilitera l'étape de 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 Sigma pour le mappage de règles Radar

Le moment est venu de traduire vos requêtes exploratoires depuis Sigma ou Data Pipeline pour le mappage de règles Radar vers Sigma aux fins de tests rétroactifs. Voici quelques mappages fréquents (nous partons du principe que vous envoyez les signaux adéquats à 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

La ligne d'arrivée approche : 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 suivre la performance des règles, vous pouvez jeter un œil à l'issue de l'objet du paiement (charge object outcome) dans l'API Payment Intents, en particulier à l'objet de la règle. De la même manière, sur Sigma, vous pouvez utiliser les champs charges.outcome_rule_id, charges.outcome_type, et payment_intents.review_id à des fins d'analyse. Voici comment suivre la performance d'une règle sur Sigma à l'aide du tableau de décisions relatif aux règles 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 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.

Apprenez-en davantage sur Radar for Fraud Teams sur ce lien. Si vous utilisez déjà Radar for Fraud Teams, rendez-vous sur la page des règles de votre Dashboard, afin de commencer à en écrire.

Obtenez plus d'informations sur Sigma sur ce lien et sur Stripe Data Pipeline en cliquant ici.