Services anti-fraude

1/ Organisation des services anti-fraude

Les services anti-fraude sont segmentés en 4 outils :

• 1/ Liste blanche (whitelist)
  Le but de la « whitelist » est de rendre sélective l’application d’une règle d’acceptation.
  La règle définie devient inopérante pour des clients identifiés, VIP ou reconnus de confiance qui sont intégrés à une « whitelist ».
  Les « whitelists » portent sur les données spécifiques d’un client, comme le numéro de sa Carte Bancaire ou son adresse IP.
  Cette fonctionnalité permet d’être moins restrictif sur des populations d’utilisateurs.
• 2/ Liste noire (blacklist) :
  Le service de « blacklist » permet de refuser les paiements.
  Tout comme pour les « whitelists », les « blacklists » portent sur les données propres au porteur de carte (Carte, IP, Tel, email).
• 3/ Règles d’acceptation des transactions :
  Cet outil permet de construire les règles spécifiques définissant les conditions d’acceptation d’un paiement.
• 4/ Scoring anti-fraude
  Le service de scoring permet de détecter les transactions potentiellement frauduleuses en se basant sur l’analyse croisée de plusieurs données liées aux paiements.

Les phases de traitement des transactions sont toujours exécutées dans cet ordre.

Dans le cas où les données d’entrée remplissent toutes les conditions des « whitelist » définies, le service de « blacklist » ne sera pas exécutée et la transaction sera opérée normalement.
Dans le cas où les données d’entrée remplissent une des conditions des « blacklist » définies et ne figurent pas dans le service de « whitelist », la transaction sera refusée et le service « règle d’acceptation » ne sera pas exécutée.
Chaque service est exécuté de façon descendante vis-à-vis de la hiérarchie des acteurs CentralPay, ce qui signifie qu’une plateforme peut appliquer les paramètres de ses services anti-fraude à ses marchands, mais que l’inverse n’est pas possible.

2/ Outil de scoring de fraude

CentralPay s’appuie sur un service de détection de fraude reposant sur des algorithmes de machine learning.

Ce moteur prédictif est constitué depuis un large échantillon de données fourni par CentralPay au format JSON et issues des données TRANSACTION / REFUND / DISPUTE.
Ce service s’appuie sur une classification comportementale liée au secteur d’activité du marchand.

Le moteur retourne une action et un score.

L’action invite le service de paiement à accepter ou refuser la transaction.

Le score classifie le niveau de risque en fournissant un pourcentage de probabilité de fraude. Ce score est ensuite interprété dans le moteur de règle.

Le score permet au marchand et à l’algorithme d’interagir ensemble pour s’améliorer.

Les scores sont classifiés ainsi :

• De 0 à 19 = risque faible
  Transaction acceptée
  Pas d’action
• De 20 à 59 = risque moyen
  Transaction acceptée
  Action : envoi événement avec détail du score pour revue manuelle et apprentissage
• +60 = risque élevé
  Transaction refusée
  Action : envoi événement avec détail du score pour revue manuelle et apprentissage

Ce service d’analyse d’exposition à la fraude analyse le contexte d’exposition au risque de fraude de chaque transaction. Ce service retourne un score qui permet de traiter automatiquement la réponse attendue dans le moteur de règle.

Le score repose sur l’analyse croisée des données suivantes :

• Indice de risque IP
• Détection de Proxy
• Détection réseau TOR
• Vérification de l’adresse IP
• Confidence factors
• Email checks
• Address & phone checks
• Adresse d’expédition à haut risque
• Géolocalisation des adresses IP
• Identification des équipements utilisés
• Adresse e-mail
• Type de navigateur
• Discordances de pays
• Distance de l’adresse d’expédition
• Distance de l’adresse de facturation
• Domaine e-mail
• Heure
• Montant de la commande
• Pays
• Numéro de téléphone
• Titulaire IP
• Titulaire de l’e-mail
• Vérification adresse CB

3/ Listes blanches et listes noires

3.1/ Liste blanche (Whitelist)

Le but de la « whitelist » est de rendre sélective l’application d’une règle d’acceptation. Cette règle devient inopérante pour des clients identifiés, VIP ou reconnus de confiance qui sont intégrés à une « whitelist ».

Le service anti-fraude passe ainsi à l’étape suivante.

Les « whitelists » portent sur les données spécifiques d’un client, comme le numéro de sa Carte Bancaire ou son adresse IP. Cette fonctionnalité permet d’être moins restrictif sur une population d’utilisateurs.

3.2/ Liste noire (Blacklist)

L’étape de la « blacklist » permet de refuser les paiements.

Tout comme pour les « whitelists », les « blacklists » portent sur les données propres au porteur de carte :

• Pays
• Régions géographiques
• Numéros de carte
• Numéros de téléphone
• E-mail
• Adresses IP
• IBAN

4/ Règles d’acceptation des transactions

Le moteur de règles d’acceptation est une brique applicative puissante et modulaire qui permet d’adapter le comportement lié au traitement à réaliser sur chaque transaction comme :

• accepter
• refuser
• alerter
• …

Ce service permet ainsi de définir des actions à réaliser sur chaque transaction depuis une large liste d’attributs disponibles : score de fraude, localisation du porteur, montant des ventes cumulées sur 7 ou 30 jours, client VIP whitelist, paramètre spécifique adressé par le marchand…

Une règle d’acceptation est une condition logique. Elle permet : d’autoriser, de restreindre, et/ou d’interdire des transactions.
Une règle se compose de 4 éléments : l’action, les attributs, les opérateurs, les valeurs.

La syntaxe d’une règle est la suivante :
« Action » « if » « Attribut » « Opérateur de comparaison » « Valeur de comparaison »

Exemple :

REFUSE if card_country != 'FRA'

La règle présentée dans cet exemple permet de refuser automatiquement les paiements lorsque le pays de la carte n’est pas la France.
La syntaxe de la grammaire choisie par la plateforme pour son moteur d’acceptation est très semblable à la syntaxe SQL (utilisée pour dialoguer avec les bases de données).

4.1/ Les actions disponibles

• ALLOW
  Autorise le paiement.
• REFUSE
  Refuse le paiement.
• ALERT
  Adresse une notification « webhook » de la transaction associée.

4.2/ Les attributs disponibles

En tapant « # », les attributs disponibles sont affichés.

Dans une règle, un attribut est toujours suivi d’un Opérateur de comparaison.

4.3/ Les opérateurs de comparaison disponibles

• = (égal)
• != (différent de)
• < (plus petit que)
• <= (plus petit ou égal à)
• in (dans ce qui va suivre)
• not in (pas dans ce qui va suivre)

Les opérateurs de comparaison = , != , > , < , >= et <= doivent être suivis d’une valeur.

Les opérateurs IN et NOT IN sont suivis d’une liste de valeurs de comparaison.
Une liste de valeurs est entourée par des parenthèses et les valeurs à l’intérieur de la liste sont séparées par des virgules.

Exemple :

REFUSE if #currency NOT IN ('EUR', 'USD', 'GBP', 'CHF')

L’exemple présenté ci-dessus permet de refuser tous les paiements dont la devise n’est pas l’Euro, le Dollar US, la Livre Sterling ou le Franc Suisse.

Cette syntaxe évite d’écrire plusieurs règles ou plusieurs conditions dans la même règle.

4.4/ Les valeurs disponibles :

En fonction du type de valeur, la syntaxe permettant de définir la valeur ne sera pas la même :

• Entiers (valeur numérique sans décimale) : syntaxe classique (ex : 100)
• Doubles (valeur numérique avec décimales) : la valeur est définie avec un point comme séparateur de décimale (ex : 12.32)
• Chaîne de caractères : la valeur est définie entre ‘quotes’ simples (ex : ‘FRA’)
• Booléens : la valeur est true ou false (ex : false)

ATTENTION : les valeurs de « montants » doivent être renseignées en centimes (ex : pour 10 € on renseignera une valeur de 1000).

4.5/ Les opérateurs logiques :

Les opérateurs disponibles sont AND et OR. Ils permettent de définir comment le moteur de règle va interpréter la succession de ces règles. Le « AND » permet une inclusion tandis que le « OR » une exclusion.

Exemple :

REFUSE if #amount < 1000 and #card_country != 'FRA'

L’exemple présenté ci-dessus permet de refuser les paiements dont le montant est inférieur à 10 € ET dont la carte n’est pas française. Si l’une ou l’autre des conditions définies n’est pas remplie, l’action ne sera pas exécutée.