Vue d'ensemble
La détection de fraude de CentralPay est basée sur 4 services complémentaires :
- La gestion de blacklists et de whitelists
- Un service d'alerte post-transaction basé sur l'analyse du comportement et les transactions qui y sont liées
- Un service d'acceptation des transactions basé sur des règles contextuelles
- Un service de détection de fraude en temps réel basé sur la technologie du machine learning
Les 4 services complémentaires forment une nouvelle approche globale de la gestion de la fraude dont l’objectif est d’offrir :
- D’une part, aux marchands, un meilleur taux d’acceptation pour un minimum d’impayés
- D’autre part, d’apporter à CentralPay les moyens d’encadrer ses politiques LCB/FT*.
La gestion de blacklists et de whitelists
Plusieurs niveaux de blacklists et de whitelists sont disponibles :
- Pays
- Régions géographiques-numéros de carte
- Numéros de téléphone
- Adresses IP
- IBAN
LES LISTES NOIRES :
Les listes noires permettent le refus inconditionnel d'une transaction sur la base des critères mentionnés ci-dessus.
LE BLOCAGE :
Sur la base de ces mêmes critères, les blocages permettent de contourner les listes noires potentielles et d'autres règles d'acceptation.
Par exemple : si une carte whitelistée, une adresse IP, un e-mail ou un numéro de téléphone est présenté(e) au moteur des règles, seules les règles inconditionnelles seront exécutées.
Service de détection 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
Principe de fonctionnement
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
- accepter en 3DS
- accepter avec CVV
- demande d’OTP
- 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...
Le système de traitement des transactions se compose de plusieurs étapes consécutives dont les règles s'enchaînent toujours dans un ordre prédéfini (voir schéma ci-dessous).
Le système de traitement d'une transaction se découpe en trois étapes :
1Whitelist :
Le but de la "whitelist" est de rendre sélective l’application d’une règle.
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".
Le service 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 des populations d’utilisateurs.
2Blacklist :
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 (Carte, IP, Tel, email).
3Acceptance :
Cette étape permet de construire les règles spécifiques définissant les conditions d’acceptation d’un paiement.
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, la phase de "blacklist" ne sera pas exécutée et la transaction passera directement à la phase "Acceptance".
- Dans le cas où une opération rentre dans la phase de "blacklist", si les données d'entrée remplissent une des conditions des "blacklist" définies, le paiement sera refusé et la phase "Acceptance" ne sera pas exécutée.
- Chaque phase est exécutée de façon descendante vis à vis de la hiérarchie des acteurs du système de paiement.
L'organigramme ci-contre représente le fonctionnement hiérarchique du système de paiement.
Le système de traitement des transactions s'inscrit dans cette logique de hiérarchisation des acteurs.
En effet, chaque "Acteur" peut définir des règles pour des entités inférieures sur lesquels il possède les droits. En aucun cas une entité inférieure (marchand ou agent) ne peut définir, modifier ou consulter des règles portant sur une entité supérieure ou équivalente.
Les règles suivent donc la même hiérarchie que les acteurs dont les règles exécutées dans l’ordre ascendant.
NB : les droits sur les règles ne s’appliquent que sur des niveaux de N à N-1.
Règles d'acceptance
Définition
Une règle d'acceptance 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'L'exemple précédent refuse les paiements si le pays de la carte n'est pas la France.
La syntaxe de la grammaire choisie par la plateforme pour son moteur d'acceptance est très semblable à la syntaxe SQL (utilisée pour dialoguer avec les bases de données).
Actions
Toutes les règles d'acceptance doivent être liées à une action.
Les actions disponibles sont les suivantes :
ALLOW
Autorise le paiement.
REFUSE
Refuse le paiement.
OTP
OTP (One Time Password) demande au porteur de carte de fournir un code de confirmation, le cryptogramme de sécurité de la carte ou un code unique qui sera envoyé par sms ou email.
THREE_D_SECURE
Impose une transaction 3D Secure.
OTP_AND_THREE_D_SECURE
Combine les actions OTP et THREE_D_SECURE.
ALERT
Adresse une notification "webhook" de la transaction associée.
Si la transaction répond aux conditions exprimées dans la règle, l'action sera exécutée et les règles suivantes ne seront pas traitées.
Dans les cas où l'action est THREE_D_SECURE ou OTP, les règles suivantes seront traitées si l'action est déjà réalisée (la transaction est déjà 3-D-SECURE ou l'OTP est déjà présent dans la transaction).
Les attributs
Les attributs (Cf. Liste des attributs) sont des critères de comparaisons liés aux données d'entrée de la transaction.
Par exemple, il peut s’agir du montant ou du pays de la carte.
Un attribut commence toujours par le caractère spécial "#". Cette convention permet au moteur de règle de détecter les attributs dans la règle saisie.
De plus, dès la saisie de ce caractère dans le formulaire, vous disposez de la liste exhaustive des attributs auto complétés.
Les attributs sont typés, c'est-à-dire qu'ils représentent des types de valeurs différentes, par exemple :
- montant = type entier (une valeur numérique sans décimale)
- pays de la carte = chaîne de caractères d'une taille de 3 caractères (Cf. liste des attributs)
Dans une règle, un attribut est toujours suivi d'un Opérateur de comparaison.
Les opérateurs de comparaison
Les opérateurs de comparaison sont des opérateurs mathématiques qui permettent au moteur de règle de comparer la valeur de l'attribut à la valeur de comparaison saisie.
Les opérateurs de comparaison sont à utiliser en fonction du type de l'attribut choisi.
| Type | Opérateurs |
|---|---|
| Entiers (valeur numérique sans décimale) | = | != | IN | NOT IN | < | > | <= | >= |
| Doubles (valeur numérique avec décimales) | = | != | IN | NOT IN | < | > | <= | >= |
| Chaîne de caractères | = | != | IN | NOT IN |
| Booléen (true, false) | = | != |
Les opérateurs = , != , > , < , >= et <= sont suivis d'une unique valeur de comparaison.
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')Explication : l'exemple précédent refuse 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.
Exemple :
REFUSE if #card_country IN ('ITA', 'AFG')est équivalent à :
REFUSE if #card_country = 'ITA' and #card_country = 'AFG'
Les valeurs
Les valeurs correspondent aux éléments de comparaison que vous définissez par rapport aux attributs. La valeur est typée en fonction de l'attribut et donc du type de l'opérateur correspondant.
En fonction du type de l'opérateur, la syntaxe permettant de définir la valeur ne sera pas la même :
| Type de valeurs | Syntaxe |
|---|---|
| Entiers | Exemple : [...] = 100 |
| Doubles | La valeur est définie avec un point comme séparateur de décimale. Exemple : [...] = 12.32 |
| Chaîne de caractères | La valeur est définie entre quotes simples '. Exemple : [...] = 'FRA' |
| Booléens | La valeur est true ou false. Exemple : [...] = false |
Pour les valeurs de type chaîne de caractères, en fonction de l'attribut choisi, la syntaxe de la valeur doit répondre à des normes spécifiques.
Pour les attributs de type pays (_country), les valeurs sont de type chaînes de caractères et doivent répondre à la norme ISO 3166-1 alpha-3.
Pour les attributs de type monétaire (_currency), les valeurs sont de type chaînes de caractères et doivent répondre à la norme ISO 4217.
Les valeurs pour les attributs comme la marque de la carte (commercial brand) ou la région de l'IP (ip_region), les valeurs sont de type chaînes de caractères et correspondent aux valeurs d'une liste finie, définie dans la liste des attributs.
L'attribut #always
Cet attribut ne sera jamais suivi d'aucun opérateur ni d'aucune valeur. Il est là pour définir le comportement du moteur de règle lorsque la transaction n'a rempli aucune des conditions définies dans les règles précédentes.
Exemple :
THREE_D_SECURE if #alwaysL'exemple précédent impose une transaction 3_D_SECURE si les données d'entrée du paiement n'ont répondu à aucune des conditions définies dans les règles précédentes.
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 < 10000Explication : 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.
Liste des attributs
| Attribut | Description | Type de valeurs | Exemple |
|---|---|---|---|
| #always | Aucune | ||
| #transactions[_état][_entité] [_temporalité] | Quota du nombre de transactions [état] [entité] [temporalité] | Entiers | Cf. attributs quotas |
| #transactions_amount[_état] [_entité][_temporalité] | Quota du montant des transactions [état] [entité] [temporalité] | Entiers | Cf. attributs quotas |
| #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 |
|
#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 |
|
#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écéssaire que l'exact même champs soit reporté dans la requête de l'objet visé.
Attributs de type quota
Les attributs de types quotas sont partagés en deux grande familles :
- "#transactions_xxx_xxx_xxx" : les attributs qui vont porter sur le nombre de transactions
- "#transactions_amount_xxx_xxx_xxx" : les attributs qui vont porter sur le montant des transactions
Ces attributs peuvent être plus ou moins précis, c'est-à-dire que l'on peut les compléter par états, par entités et par temporalité (aucun de ces éléments n’étant obligatoire).
État
Permet de distinguer les transactions réalisées avec succès et les transactions échouées.
La syntaxe de cet élément est la suivante : succeeded ou not_succeeded.
Exemples :
- #transaction_amount_not_succeeded représente la somme des montants des transactions échouées.
- #transaction_succeeded représente le nombre de transactions réussies.
Entité
Permet de découper l'attribut par entité. Une entité est une carte, un client (Customer) ou une adresse IP.
La syntaxe est la suivante : per_card, per_customer, per_ip.
Exemples :
- #transactions_per_card représente le nombre de transactions par carte
- #transactions_succeeded_per_customer représente le nombre de transactions réussies par client
- #transactions_amount_not_succeeded_per_ip représente la somme des montants des transactions échouées par adresse IP
Temporalité
Permet d'ajouter un indicateur de temporalité aux attributs.
La syntaxe est la suivante : hourly, daily, weekly, monthly, rolling_hour, rolling_day, rolling_week ou rolling_month.
Exemple :
- #transaction_hourly représente le nombre de transactions par heure
- #transaction_amount_rolling_day représente la somme des montants des transactions par jours glissants
- #transaction_succeeded_rolling_month représente le nombre de transactions réussies par mois glissants
- #transaction_amount_succeeded_per_customer_rolling_hour représente la somme des montants des transactions réussies par client par heures glissantes