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.

Liste des attributs

Attribut	Description	Type de valeurs	Exemple
#always		Aucune
#transactions[_état][_entité] [_temporalité]	Quota du nombre de transactions [état] [entité] [temporalité]	Entiers
#transactions_amount[_état] [_entité][_temporalité]	Quota du montant des transactions [état] [entité] [temporalité]	Entiers
#amount	Montant de la transaction en centimes	Entier	#amount > 100
#card_country	Pays d’émission de la carte	Chaîne de caractères  ISO 3166-1 alpha-3	#card_country IN (‘FRA’, ‘USA’, ‘BEL’, ‘DEU’)
#card_establishment	Etablissement de la carte
#card_product	Type de carte	‘gold’, ‘platinium’
#card_product_type	Type de carte (perso ou corp.)	CONSUMER CORPORATE	#card_product_type = ‘CONSUMER’
#card_region	Région d’émission de la carte	‘ASIA_PACIFIC »EUROPE »LATIN_AMERICA »MIDDLE_EAST_AND_AFRICA »USA_AND_CANADA »ANTARCTIQUE »UNKNOWN’	#card_region NOT IN (‘ASIA_PACIFIC’, ‘LATIN_AMERICA’)
#commercial_brand	Marque de la carte	VISA MASTERCARD AMEX OTHER	#commercial_brand != ‘VISA’
#currency	Devise de la transaction	Chaîne de caractères  ISO 4217	#currency = ‘EUR’
#ip_country	Pays de l’adresse IP	Chaîne de caractères  ISO 3166-1 alpha-3	#ip_country IN (‘FRA’, ‘USA’, ‘BEL’, ‘DEU’)
#ip_region	Région de l’adresse IP	‘ASIA_PACIFIC »EUROPE »LATIN_AMERICA »MIDDLE_EAST_AND_AFRICA »USA_AND_CANADA »ANTARCTIQUE »UNKNOWN’	#card_region NOT IN (‘ASIA_PACIFIC’, ‘LATIN_AMERICA’)
#is_anonymous_ip	Est une IP anonyme	TRUE | FALSE	#is_anonymous_ip = TRUE
#is_three_d_secure	Est une transaction 3D-Secure	TRUE | FALSE	#is_three_d_secure = TRUE
#payout_amount	Montant de reversement	Entier	#payout_amount > 100
#payout_currency	Devise de reversement	Chaîne de caractères  ISO 4217	#payout_currency = ‘EUR’
#risk_score	Score d’antifraude	Double	#risk_score > 2,34
#custom_acceptance_data[‘key’] = ‘value’	champs customisé	key : Regex [a-zA-Z0-9_-]value: Regex [a-zA-Z0-9_-]	#custom_acceptance_data[‘product_category’] = ‘high’

Dans le cas du custom_acceptance_data[‘key’] = ‘value’, afin qu’il soit pris en compte il est nécessaire que l’exact même champs soit reporté dans la requête de l’objet visé.

Les opérateurs logiques et parenthésage

Opérateurs logiques and et or

La syntaxe utilisée pour définir les règles permet de créer plusieurs conditions au sein de la même règle. Les conditions resteront définies de la même manière, à la seule différence qu’un mot clé sera placé entre les conditions.

Les mots clés 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 » correspond à l’inclusion et le « or » à l’exclusion.

Exemple :

ALLOW if #amount < 1000 and #card_country = 'FRA'

L’exemple précédent autorise les paiements dont le montant est inférieur à 10 ET dont la carte est française. Si l’une ou l’autre des conditions définies n’est pas remplie, l’action ne sera pas exécutée.

Exemple :

ALLOW if #amount < 1000 or #card_country = 'FRA'

L’exemple précédent autorise les paiements dont le montant est inférieur à 10 OU dont la carte est française. Si l’une ou l’autre des conditions définies est remplie, l’action sera exécutée.

Les parenthèses

L’utilisation des parenthèses dans la définition d’une règle multi-conditions permet de définir des blocs de conditions et les priorités entre ces blocs. Le principe est le même que celui des priorités pour les opérateurs mathématiques.

Exemple :

ALLOW if #amount < 1000 and (#card_country = 'FRA' or #currency = 'EUR')

Dans l’exemple précédent, le moteur de règle va d’abord interpréter le bloc (#card_country = ‘FRA’ or #currency = ‘EUR’). C’est à dire que le paiement sera autorisé si (la carte est française ou que la devise est l’euro), ET que le montant est inférieur à 10.

Ordre d’exécution des règles

Les règles sont exécutées dans un ordre à définir. Cet ordre est important car dès qu’une transaction répond aux critères d’une règle, les règles suivantes ne seront pas traitées.

Les règles sont exécutées dans l’ordre d’affichage de la liste de l’interface.
Un indicateur de position est affiché dans chaque liste. Pour changer la position d’une règle, il suffit de la faire glisser à la position souhaitée.

Exemples de règles :

ALLOW if #amount < 1000 and #transactions_amount_daily < 10000

Explication : cet exemple autorise les transactions dont le montant est inférieur à 10 si la somme des montants des transactions de la journée est inférieur à 100.

REFUSE if #risk_score > 3 or (#ip_regions = 'ASIA_PACIFIC' and #card_region = 'ASIA_ PACIFIC')

Explication : cette règle bloque les paiements si le score de risque dépasse 3 ou que l’IP utilisée ainsi que la région d’émission de la carte correspondent à la zone ‘ASIA_PACIFIC’.

THREE_D_SECURE if #card_country NOT IN ('FRA', 'USA', 'GBR') 

Explication : cette règle demande une transaction 3D Secure si le pays de la carte n’est pas la France, les Etats-Unis, ou la Grande Bretagne.

ALLOW (#amount < 10000 and #transactions_amount_daily < 100000) or (#currency IN ('EUR', 'USD') and #transactions_amount_monthly < 1000000)

Explication : cet exemple précédent AUTORISE les paiements SI le montant est INFÉRIEUR à 100 ET que la somme des montants des transactions du jour est INFÉRIEUR à 1000 OU que la devise est € ou $ ET que la somme des montants des transactions du mois est INFÉRIEURE à 10 000.

Les opérateurs logiques « and » et « or » ne sont syntaxiquement correct qu’en minuscule.

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.