Solution Business Score

Introduction

WL Sips est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métiers liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement en plusieurs fois , …).

L'objectif de ce document est de décrire les règles antifraudes en mode Business Score , d'expliquer la manière de les mettre en oeuvre et de les configurer.

La terminologie Business Score correspond au calcul du score global du risque de la transaction par agrégation de la pondération de chaque règle antifraude. Vous déterminez en toute autonomie le profil des transactions que vous considérez « à risque ».

À qui s'adresse ce document

Ce document s’adresse à tous les commerçants qui ont souscrit à l’offre « Gestion de la lutte contre la fraude – Business Score » et souhaitent bénéficier d’un outil de lutte contre la fraude administré par eux-mêmes sur le MEX .

Pour avoir une vue d’ensemble de la solution WL Sips , nous vous conseillons de consulter les documents suivants :

Présentation fonctionnelle ;
Guide de Configuration des fonctionnalités ;
Glossaire.

Vue d'ensemble

Accéder au MEX

Toutes les fonctionnalités de lutte contre la fraude décrites dans cette documentation sont gérées dans le MEX .

Vous devez donc avoir souscrit à l’offre Business Score pour pouvoir accéder à ces fonctionnalités.

L’accès au MEX se fait via l’URL suivante :

https://mex.fr.worldline.com/portal/home

L’accès est sécurisé et nécessite un identifiant et un mot de passe.

Après identification, cliquez sur l'onglet 'Fraude' pour gérer la lutte contre la fraude pour votre offre.

Voir la partie 'Configurer des profils anti-fraude avec le MEX ' pour plus d'informations.

Comprendre la lutte contre la fraude

Avant de commencer, il est absolument essentiel pour vous de bien comprendre la manière dont les fraudeurs mènent leurs attaques.

Les fraudeurs sont très bien organisés et exploitent la plupart des faiblesses que comportent la sécurité et les aspects légaux du commerce électronique. Notamment :

ils opèrent à l'échelle internationale ;
ils se servent de citoyens honnêtes pour exercer leurs activités frauduleuses ;
ils se dissimulent derrière des serveurs mandataires étrangers ;
3-D Secure n'est pas un obstacle pour eux ;
ils renouvellent leurs types d'attaques régulièrement.

Par conséquent, il est essentiel de comprendre au niveau commerçant les comportements frauduleux lors de la mise en œuvre des règles antifraudes. Il est également très important de surveiller les résultats régulièrement et de maintenir les bons paramétrages en fonction de cette surveillance. Cela nécessite généralement de mettre sur pied une cellule de gestion de la fraude de votre côté.

Le moteur de lutte contre la fraude s’appuie sur des profils antifraude afin d’évaluer les transactions. Ceux-ci sont composés de règles que vous configurez.

La gestion des règles antifraudes est un cercle vertueux qui débute par la création d’un profil antifraude efficace qui convient à votre activité. Elle se poursuit par des vérifications régulières des activités frauduleuses et l'affinage régulier du profil en question.

Note: l'onglet fraude du MEX et les outils de rapports existants sont conçus pour vous permettre de gérer la solution antifraude de manière indépendante.

Définition d'une règle antifraude

Qu'est-ce qu'une règle antifraude ?

Une règle antifraude est une vérification effectuée sur l’un des critères de la transaction. Le critère contrôlé peut être par exemple le pays de la carte, la plage de montants, le numéro de la carte, l’adresse IP, l’identifiant du client, etc. Les règles sont classées par catégorie : géolocalisation, vélocité, liste, panier et divers.

Les règles doivent être activées et paramétrées dans un profil antifraude afin d’être exécutées. Pour la définition d’un tel profil, veuillez-vous référer à la définition d'un profil antifraude .

Règle positive et règle négative

Règle positive

Une règle positive a pour objectif de détecter une condition favorable au niveau de l’acceptation de la transaction (exemple : identifiant client présent dans la liste blanche des clients).

Elle retourne un score d’une valeur supérieure ou égale à zéro en fonction du paramétrage de la règle si la condition est remplie, et elle ne retourne pas de score dans le cas contraire.

Actuellement les règles positives sont basées sur la présence d’un élément de la transaction dans des listes blanches appelées aussi listes positives.

Règle négative

Une règle négative a pour objectif de détecter une condition défavorable au niveau de l’acceptation de la transaction (exemple : identifiant client présent dans la liste noire des clients).

Elle retourne un score d’une valeur inférieure ou égale à zéro en fonction du paramétrage de la règle si la condition est remplie, et elle ne retourne pas de score dans le cas contraire.

Les règles du type négatif sont réparties en 5 catégories :

règles de géolocalisation ;
règles d'encours (vélocité) ;
règles de listes ;
règles de panier ;
règles diverses.

Configuration avancée

De base, certaines règles n’ont pas nécessairement un caractère positif ou négatif (par exemple les règles de géolocalisation ; vous pouvez vouloir favoriser certains pays ou en défavoriser d’autres) tandis que d’autres ont forcément un caractère positif (listes blanches) ou négatif (listes noires).

Par défaut les règles proposées sont configurables dans un mode de configuration simple, c’est-à-dire qu’une règle est définie comme étant positive ou négative .

Néanmoins, certaines règles bénéficient d’un mode de configuration avancée. En mode de configuration avancée, une même règle peut être à la fois positive et négative . Elle aura donc une influence positive, négative ou neutre sur le résultat du contrôle de la transaction en fonction du paramétrage de la règle et du contexte de transaction.

Le choix d’activer le mode de configuration avancée se fait lors du paramétrage de la règle dans le profil. Il est possible de n’activer ce mode que pour certaines règles et de laisser le mode de configuration simple pour les autres.

Le paramétrage avancé d’une règle permet de spécifier les critères qui auront une influence positive ou négative sur le résultat.

Exemple avec la règle plage de montant configurée en décisif :


	Configuration de la règle (profil)	Montant de la transaction	Résultat	Conséquence en mode pré-authentification
Mode de configuration simple	Min = 50 Max = 200	45	Négatif	Déclencher 3-D Secure
		150	Neutre	Passer aux règles suivantes
		250	Négatif	Déclencher 3-D Secure
Mode de configuration avancée	Plage positive : Min = 50 Max = 150 Plage négative : Min = 300 MAx = 400	45	Neutre	Passer aux règles suivantes
		100	Positif	Débrayer 3-D Secure
		200	Neutre	Passer aux règles suivantes
		350	Négatif	Déclencher 3-D Secure
		450	Neutre	Passer aux règles suivantes

Exemple avec la règle authentification 3-D Secure configurée en décisif :


	Configuration de la règle (profil)	Statut 3-D Secure de la transaction	Résultat	Conséquence en mode pré-autorisation
Mode de configuration simple	Statuts négatifs : ERROR	SUCCESS	Neutre	Passer aux règles suivantes
Mode de configuration simple	Statuts négatifs : ERROR	ERROR	Négatif	Refuser la transaction avant la demande d'autorisation
Mode de configuration avancée	Statuts négatifs : ERROR Statuts positifs : SUCCESS	SUCCESS	Positif	Passer à la demande d'autorisation directement sans passer par les autres règles
Mode de configuration avancée	Statuts négatifs : ERROR Statuts positifs : SUCCESS	ERROR	Négatif	Refuser la transaction avant la demande d'autorisation

Modes d'exécution et leurs impacts sur l'acceptation

WL Sips offre deux modes de contrôle de lutte contre la fraude :

mode pré-autorisation : permet d’arrêter les transactions frauduleuses avant la demande d’autorisation ;
mode pré-authentification : permet de débrayer 3-D Secure pour les transactions considérées comme non risquées.

Figure 1. déroulement des traitements lors d'une transaction de paiement

Mode pré-autorisation

En mode pré-autorisation (le mode par défaut de contrôle de lutte contre la fraude de WL Sips ), les règles sont exécutées avant la demande d’autorisation et après l’authentification 3-D Secure (si la boutique est enrôlée 3-D Secure). Si le résultat du contrôle est négatif, la transaction sera refusée avant la demande d’autorisation.

Pour les moyens de paiement avec redirection vers une page spécifique pour ce moyen de paiement (exemple : Paypal), le contrôle pré-autorisation est déclenché avant la redirection.

En fonction de votre besoin, vous définissez votre ou vos profils pré-autorisation en combinant :

les règles GO et/ou NOGO ;
les modes décisif et/ou informatif.

Un profil est informatif quand toutes les règles sont en mode informatif.

Un profil est décisif quand toutes les règles sont en mode décisif.

Un profil est mixte quand il comporte des règles en mode informatif et en mode décisif.


Type de profil	WL Sips / commerçant	Impacts sur l'acceptation
Profil informatif	WL Sips	Pas d’impact, WL Sips poursuit l’action de demande d’autorisation.
Profil informatif	Commerçant	Le commerçant doit analyser le résultat des règles et décider de la suite à donner à la transaction via les opérations de caisse annulation ou validation .
Profil décisif	WL Sips	Si le résultat est négatif , la transaction est refusée par WL Sips , il n’y a pas de demande d’autorisation. Si le résultat est positif ou neutre , WL Sips poursuit l’acceptation en faisant une demande d’autorisation.
Profil décisif	Commerçant	Pas d’impact sur l’acceptation de la transaction car le commerçant a délégué à WL Sips la prise de décision sur la fraude. Toutefois le commerçant peut analyser le motif.
Profil mixte	WL Sips	Idem au cas du profil décisif.
Profil mixte	Commerçant	Si la transaction est refusée , pas d’impact pour le commerçant. Si la transaction est acceptée , le commerçant doit analyser le résultat des règles en mode informatif et décider de la suite à donner.

Mode pré-authentification

En mode pré-authentification, les règles sont exécutées avant l’authentification 3-D Secure. Si le résultat du contrôle est positif, l’authentification 3-D Secure sera débrayée et WL Sips poursuit la demande d’autorisation.

Ce mode est applicable uniquement pour les transactions carte avec l’authentification 3-D Secure.

En fonction de votre besoin, vous définissez votre ou vos profils pré-authentification en combinant les règles GO et/ou NOGO.

Un profil est décisif quand toutes les règles sont en mode décisif.

Dans un profil Go-No-Go pour la phase de pré-authentification, il est uniquement possible de paramétrer des règles décisives. Des règles informatives dans un tel profil n’ont pas d’utilité à cette étape.


Type de profil	WL Sips / commerçant	Impacts sur l'acceptation
Profil décisif	WL Sips	Si le résultat est positif , WL Sips débraye l’authentification 3-D Secure et poursuit le contrôle pré-autorisation. Si le résultat est négatif ou neutre , WL Sips poursuit l’authentification 3-D Secure avant de faire le contrôle pré-autorisation.
Profil décisif	Commerçant	Le commerçant peut analyser le résultat des règles et décider de la suite à donner à la transaction via les opérations de caisse annulation ou validation .

IMPORTANT: précision sur les règles proposées en pré-authentification

Comme le débrayage de l’authentification 3-D Secure a lieu lorsque le résultat est positif, il est important de paramétrer au moins une règle du type GO en décisif afin de débrayer l’authentification 3-D Secure pour certains clients.

Définition d'un profil antifraude

Qu'est-ce qu'un profil antifraude ?

Un profil antifraude est un ensemble de règles que vous choisissez et paramétrez parmi les règles proposées par WL Sips . Les règles sont exécutées avant l’authentification 3-D Secure et avant la demande d’autorisation selon votre paramétrage (pour comprendre les modes pré-authentification et pré-autorisation, veuillez-vous référer aux modes d'exécution et leurs impacts sur l'acceptation).

Il existe 3 types de profils antifraude :

le profil « offre » du distributeur ;
les modèles de profil ;
les profils marchands.

Un profil « offre » distributeur est défini par le distributeur et administré par Worldline . Il définit le périmètre des règles disponibles et des configurations éventuellement imposées. Si une boutique n’a pas de profil adapté au moyen de paiement utilisé alors c’est le profil offre distributeur qui s’applique.

Les modèles de profil sont définis et administrés par WL Sips , ils sont utilisés comme modèle pour créer les profils marchands.

Les profils marchands sont définis par vous pour votre boutique et administrés par vous et/ou le distributeur (selon le choix du distributeur). Ils peuvent être créés à partir d’un profil modèle. Le terme « profil de boutique », parfois également utilisé dans ce document, est équivalent au profil marchand.

IMPORTANT: les modèles de profil et les profils marchands sont cloisonnés en pré-autorisation et pré-authentification. Par exemple, un modèle de profil en pré-autorisation ne peut pas servir à créer les profils marchands en pré-authentification. Un profil marchand en pré-authentification ne peut pas s’appliquer à l’étape de pré-autorisation lors d’un paiement.

Dans la suite de ce document, lorsque la notion de « profil » est évoquée, il s'agit de profils marchands.

Le paramétrage des profils antifraude se fait l'onglet fraude du MEX .

Profils moyen de paiement et profil par défaut

Dans la plupart des cas, vous définissez un profil antifraude unique qui est appliqué à l’ensemble de vos transactions, quel que soit le moyen de paiement utilisé. Cependant, vous pouvez également définir des profils antifraudes supplémentaires ayant un paramétrage adapté à un ou plusieurs moyens de paiement particuliers.

Lorsqu’une transaction doit être évaluée, le système de contrôle du risque commence par chercher, au sein du paramétrage de la boutique un profil antifraude spécifique au moyen de paiement utilisé.

Si un tel profil n’est pas trouvé, le système cherche le profil par défaut de la boutique. Ce profil est un profil permettant d’analyser les transactions qui n’ont pas été traitées par des profils spécifiques aux moyens de paiement.

Pour créer un profil par défaut, il suffit de créer un profil sans lui attribuer de moyen de paiement.

Attention: si aucun profil actif n'est disponible sur la boutique, c'est le profil offre du distributeur qui sera appliqué.

Il ne peut y avoir qu’un seul profil actif pour un moyen de paiement donné. De même, il ne peut y avoir qu’un seul profil par défaut actif.

Par exemple, il est possible d'avoir :

un profil dédié CB, VISA et MASTERCARD ;
un profil dédié AMEX ;
et un profil par défaut qui contrôlera les transactions payées avec un autre moyen de paiement.

Soit trois profils actifs simultanément.

Vous pouvez créer autant de profils inactifs que nécessaire. Ceci permet par exemple de garder des profils en réserve pour des périodes particulières de l’année (soldes, fêtes…).

Paramétrage pondéré ou décisif des règles

Illustration du poids du paramétrage :

Paramétrage pondéré

Lors de la définition d'un profil, vous devez choisir, activer et ordonner les règles parmi celles qui vous sont proposées dans votre offre.

À l'activation d'une règle, le poids associé à la règle est à choisir en fonction de son importance :

les règles positives ont un poids allant de 0 (neutre) à +3 (importance forte) ;
les règles négatives ont un poids allant de 0 (neutre) à -3 (importance forte).

Si la condition de la règle est remplie, le score obtenu est le poids que vous paramétrez lors de l'activation de la règle dans le profil. Dans le cas contraire, le score obtenu est de 0.

Exemple : une règle négative d'importance moyenne (-2) donnera un score de -2 si la condition est remplie.

Les règles particulièrement importantes à vos yeux peuvent être paramétrées en mode décisif (voir ci-dessous).

Paramétrage décisif

Si l’une des règles est déterminante pour vous, vous pouvez la paramétrer en décisif, ce qui vous permet de prendre une décision sur l’acceptation de la transaction sans tenir compte des autres règles :

pour les règles positives, le poids est de +4 ;
pour les règles négatives, le poids est de -4.

Si la condition de la règle décisionnelle est remplie, le résultat des contrôles antifraude est déterminé uniquement en fonction de cette règle, quel que soit le résultat des autres règles. Dans le cas contraire, le résultat des contrôles antifraude est déterminé en fonction du score global.

Note: important

Il est possible de paramétrer plusieurs règles en mode décisif. Dans ce cas, c'est le résultat favorable ou défavorable de la première règle paramétrée en mode décisif qui fait loi. Il est donc important d'ordonner les règles paramétrées en mode décisif dans l'ordre décroissant d'importance.

Définition des plages rouge, orange et verte

En mode Business Score , chaque règle active du profil utilisé évalue un aspect de la transaction et peut produire un score.

Les scores des règles sont ensuite additionnées pour former un score global (veuillez vous référer au calcul du score global pour connaître les détails du calcul). Ce dernier est alors comparé aux seuils orange et vert paramétrés dans le profil afin de prendre une décision quant à la poursuite de la transaction.

Le score global s'inscrit entre deux bornes :

la borne min. qui est la valeur obtenue si toutes les règles négatives et aucune règle négative se déclenchent ( c.-à-d. la somme des scores des règles négatives) ;
la borne max. qui est la valeur obtenue si toutes les règles positives et aucune règle négative se déclenchent (c.-à-d. la somme des scores des règles positives).

Lors de la définition du profil, vous devez donc définir les seuils orange et vert entre les deux bornes min. et max., qui délimiteront trois plages de résultats possibles pour le score. Ces plages sont chacune associées à une couleur : vert, orange et rouge (veuillez vous référer aux modes d'exécution et leurs impacts sur l'acceptation pour plus de détails sur les couleurs et leur effet sur les transactions) :

le seuil orange définit la limite entre la plage orange et la plage rouge. Sa valeur est incluse dans la plage orange ;
le seuil vert définit la limite entre la plage verte et la plage orange. Sa valeur est incluse dans la plage verte.

Dans l'exemple suivant, le seuil orange -8 est inclus dans la zone orange et le seuil vert -4 est inclus dans la zone verte.

Si les deux seuils orange et vert ont la même valeur, il n'y a alors pas de plage orange.

Dans l'exemple suivant, le seuil orange et le seuil vert sont tous sur le score -6. Le score -6 est inclus dans la plage verte.

Exemple : un profil antifraude est configuré avec trois règles :

règle 1, négatif, score associé -3 ;
règle 2, négatif, score associé -2 ;
règle 3, positif, score associé +3.

Par conséquent, vous devez positionner les seuils orange et vert entre les valeurs -5 (la borne min.) et +3 (la borne max.).

Dans le cas présent :

le seuil orange est -2 ;
le seuil vert est +1 ;
la plage rouge se situe entre le score -5 (inclus) et -3 (inclus) ;
la plage orange se situe entre le score -2 (inclus) et 0 (inclus) ;
la plage verte se situe entre le score +1 (inclus) et +3 (inclus).

Déroulement et résultat d'un profil antifraude

Lorsqu’une transaction doit être évaluée, le système de lutte contre la fraude commence par chercher, au sein du paramétrage de la boutique, le profil antifraude associé au moyen de paiement. Si un tel profil n’est pas trouvé, le système utilise le profil par défaut de la boutique.

Le profil antifraude est déroulé avant la demande d'autorisation.

Les règles du profil sont exécutées en parallèle à l’exception des règles paramétrées en décisif qui sont exécutées dans l’ordre que vous définissez. Vous avez toujours la possibilité de débrayer ou de changer le paramétrage d’une ou de plusieurs règles pour une transaction donnée.

Débrayage dynamique des règles

Vous avez la possibilité de débrayer dynamiquement, dans la requête de la transaction, certaines règles du profil. Pour avoir la liste des directives de débrayage reportez-vous à l’Annexe 1 : désactivation dynamique de certaines règles du profil.

Note: attention

Vous ne pouvez pas débrayer les règles imposées par le distributeur.

Note: le débrayage dynamique est applicable aux règles actives dans des profils pré-authentification et pré-autorisation (pour comprendre les modes pré-authentification et pré-autorisation, veuillez-vous référer aux modes d’exécution et leur impacts sur l’acceptation ).

Surcharge dynamique des règles

Vous avez la possibilité de surcharger dynamiquement, dans la requête de la transaction, certaines règles du profil.

Les modalités de surcharge dynamique sont décrites dans la description et mise en oeuvre des règles.

IMPORTANT: vous ne pouvez pas surcharger les règles imposées par le distributeur.

Note: la surcharge dynamique est applicable aux règles actives dans des profils pré-authentification et pré-autorisation (pour comprendre les modes pré-authentification et pré-autorisation, veuillez-vous référer aux modes d’exécution et leurs impacts sur l’acceptation).

Calcul du score global

Le score global, qui est le cumul des scores de toutes les règles, détermine le résultat des contrôles antifraude.

Pour un profil donné comportant n contrôles individuels :

soit Rk le résultat du contrôle individuel indexé par k dans le profil :
- 0 si non vérifié,
- 1 si vérifié,
soit Pk le coefficient de pondération associé au contrôle individuel indexé par k :
- 0 pour neutre,
- 1 pour faible,
- 2 pour moyen,
- 3 pour élevé,
- 4 pour décisif,
soit Tk le caractère du contrôle individuel indexé par k :
- +1 si positif,
- -1 si négatif.

Le score global (S) de la transaction contrôlée avec ce profil s'obtiendra grâce à la formule suivante :

Note: le score global est la somme mathématique de toutes les règles, y compris celles paramétrées en mode décisif.

Résultat global

Le résultat final des contrôles antifraude de l'offre Business Score est représenté par une couleur. Il existe 5 couleurs.

Trois couleurs représentent le résultat obtenu à partir du score global :

vert : le score global est supérieur ou égal au seuil vert du profil. Le résultat vert signifie que la transaction n'est pas risquée ;
orange : le score global est supérieur ou égal au seuil orange du profil et inférieur au seuil vert. Le résultat orange signifie que la transaction est moyennement risquée ;
rouge : le score global est inférieur au seuil orange du profil. Le résultat rouge signifie que la transaction est risquée.

Deux couleurs représentent un résultat obtenu par déclenchement d'une règle décisive :

blanc : la condition d'une règle positive paramétrée en mode décisif est remplie, la règle a donné un résultat favorable. Le résultat blanc signifie que la transaction n'est pas risquée ;
noir : la condition d'une règle négative paramétrée en mode décisif est remplie, la règle a donné un résultat défavorable. Le résultat noir signifie que la transaction est risquée.

Note: ordre de définition des règles décisives

Dans le cas où plusieurs règles décisives ont donné des résultats favorables et/ou défavorables, c'est la première règle exécutée de plus haute priorité qui fait foi. Ce qui signifie que l'ordre de définition des règles décisives dans le profil est important.

Note: la décision est prise par rapport à la couleur

Il est important de comprendre que c'est la couleur qui décide si la transaction doit être honorée ou non :

noir ou blanc : la décision est prise sans tenir compte du score global qui n'a qu'une valeur informative ;
rouge, orange ou vert : la décision est prise à partir du score global de la transaction qui est comparé aux seuils orange et vert paramétrés.

Ainsi, il n'y a pas forcément de cohérence entre la couleur et le score global. Il est donc possible d'obtenir un résultat blanc avec un score global inférieur au seuil orange ou un résultat noir avec un score supérieur au seuil vert.

Exemple : profil paramétré avec 5 règles :

règle 1 : liste blanche d'identifiants clients paramétrée en décisif (poids +4) ;
règle 2 : liste noire de numéros de carte paramétrée en décisif (poids -4) ;
règle 3 : encours par adresse IP (poids -3) ;
règle 4 : pays de la carte (poids -2) ;
règle 5 : pays de l'adresse IP (poids -2) ;

Seuil orange = 0, seuil vert = +2

Gestion du résultat orange

L’option CHALLENGE vous permet de mettre les transactions ORANGE en attente (état TO_CHALLENGE) pour vous permettre de vérifier le risque avant de poursuivre les autres étapes d’acceptation : validation, autorisation ou remise en banque.

Si vous ne possédez pas l'option CHALLENGE, la transaction est acceptée.

Vous disposez de X jours pour mesurer le risque de la fraude et valider ou refuser la transaction. X est la valeur maximale entre la validité de l’autorisation et le délai de capture ( captureDay ) que vous définissez lors du paiement (veuillez-vous reférer à l'exemple ci-dessous).

Pour mesurer le risque de la transaction, vous pouvez exploiter le champ scoreInfo qui contient le détail de l'exécution des règles : ce champ est retourné par WL Sips dans la réponse de paiement ( Sips Paypage , Sips Office ).

Deux opérations de caisse sont mises à votre disposition :

acceptChallenge , pour accepter la transaction ;
refuseChallenge , pour refuser la transaction (état REFUSED).

Ces deux opérations sont disponibles sur les interfaces suivantes :

Sips Office (veuillez vous reportez aux documentations Sips Office SOAP, Sips Office JSON et Sips Office Batch ) ;
Sips Office Extranet ;
MEX ;

Les principales règles de gestion des opérations challenge :

si la transaction est créée en mode VALIDATION, il est possible de combiner l'acceptation du challenge et la validation de la transaction en une seule étape ;
une transaction dont le challenge est accepté poursuit son cycle de vie (remise, remboursement, etc.) ;
une transaction dont le challenge est refusé arrive à la fin de son cycle de vie (état REFUSED) ;
une transaction en état TO_CHALLENGE peut être annulée. Si aucune opération n'est effectuée sur la transaction dans le délai, la transaction expire ;
la gestion du résultat orange est applicable uniquement pour les transactions CB, Visa, Mastercard et Amex.

Ci-dessous le cycle de vie d'une transaction avec la gestion du résultat orange :

En fonction du moment où le challenge est accepté, du captureDay, du captureMode et de la durée maximale de validité d’une autorisation, le jour de la remise en banque varie.

On distingue ici les cas d’utilisation en mode AUTHOR_CAPTURE et en mode VALIDATION.

Mode AUTHOR_CAPTURE

Cas d'utilisation 1 :
- Le captureDay est inférieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté avant la fin du délai captureDay
- La remise en banque se fait comme prévu à la fin du délai captureDay

Exemple : captureDay à 3, durée de l’autorisation à 6. Le challenge est accepté à J+2 :

Cas d'utilisation 2 :
- Le captureDay est inférieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté après la fin du délai captureDay
- La remise en banque se fait le soir de l’acceptation du challenge

Exemple : captureDay à 3, durée de l’autorisation à 6. Le challenge est accepté à J+4 :

Cas d'utilisation 3 :
- Le captureDay est supérieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté après la fin de validité de la demande d'autorisation
- Une nouvelle demande d’autorisation a lieu et la remise en banque se fait en respectant le captureDay

Exemple : durée de l’autorisation à 6. Le challenge est accepté à J+7, captureDay à 10:

Mode VALIDATION

Cas d'utilisation 1 :
- Le captureDay est inférieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté avant la fin du délai captureDay
- La validation est effectuée après acceptation du challenge et avant ou le même jour que le captureDay
- La remise en banque se fait le soir de la validation

Exemple : captureDay à 3, durée de l’autorisation à 6. Le challenge est accepté à J+2, la validation à J+3:

Cas d'utilisation 2 :
- Le captureDay est supérieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté avant la fin du délai captureDay
- L’autorisation est jouée pendant l’opération de validation
- La remise en banque se fait le soir de l’acceptation du challenge

Exemple : captureDay à 7, durée de l’autorisation à 6. Le challenge est accepté à J+2, la validation à J+3:

Note: en mode validation, une fois le challenge accepté, vous devez valider votre transaction avant la fin du délai captureDay, sinon elle ne pourra pas être validée et donc remise en banque.

Nous vous conseillons de faire la validation en même temps que l’acceptation du challenge en valorisant le champ validationIndicator dans la requête acceptChallenge à « Y ».

Restitution du résultat des règles

Mode pré-autorisation

Le résultat de l'exécution du profil de pré-autorisation est restitué dans les champs ci-dessous :

scoreColor , le résultat des règles représenté par une couleur ;
scoreValue , la valeur du score global ;
scoreProfile , le profil antifraude exécuté ;
preAuthorisationProfileValue , l'identifiant unique de la version du profil exécuté. Cette information est utile pour pouvoir retrouver le profil dans l'état où il se trouvait au moment de l'exécution des contrôles ;
scoreThreshold , les seuils paramétrés sur le profil ;
scoreInfo , les informations détaillées des règles exécutées ;
preAuthorisationRuleResultList , une liste du résultat détaillé de chaque règle exécutée avant la demande d'autorisation.

Chaque objet contenu dans le champ preAuthorisationRuleResultList correspond au résultat d'une règle et contient les valeurs suivantes :

ruleCode , le code de la règle. Pour connaître les codes de règles, veuillez-vous référer à la liste des règles ;
ruleType , le type de la règle. Pour connaître le type de chaque règle, veuillez vous référer à la liste des règles ;
ruleWeight , le poids de la règle défini dans le profil :
- 0 : neutre,
- 1 : importance faible,
- 2 : importance moyenne,
- 3 : importance forte,
- 4 : décisive,
ruleSetting , indique le type de configuration de la règle :
- D : dynamique dans la transaction,
- S : statique dans la configuration commerçant,
- I : statique imposée dans la configuration de l'offre distributeur,
- N : pas de configuration (lorsque la règle ne nécessite aucune configuration),
ruleResultIndicator , le résultat d'exécution de la règle :
- N : résultat négatif,
- P : résultat positif,
- O : résultat neutre,
- U : règle non exécutée car transaction incomplète (ex. donnée non renseignée),
- X : la règle n'est pas applicable à ce type de transaction,
- B : règle non exécutée car débrayée par le commerçant,
- E : règle non exécutée suite à erreur technique,
- D : règle non exécutée suite à erreur de la surcharge dynamique,
ruleDetailedInfo , informations complémentaires générées par cette règle.

Pour connaître les informations détaillées de chaque règle, veuillez vous référer à la description et mise en oeuvre des règles .

Ces champs vous sont restitués sur les interfaces suivantes :

les réponses automatique et manuelle de Sips Paypage ;
la réponse des connecteurs WL Sips (services Checkout, CashManagement (duplication) et Diagnostic) ;
le MEX ;
le journal des transactions à l'exception des champs scoreInfo et preAuthorisationRuleResultList .


Champ	Description
Résultat en vert / blanc
responseCode	Valorisé en fonction de la réponse d'autorisation
acquirerResponseCode	Valorisé en fonction de la réponse d'autorisation
scoreColor	WHITE/GREEN
scoreValue	Valeur du score global
scoreProfile	Nom du profil antifraude exécuté
preAuthorisationProfileValue	Identifiant unique du profil exécuté
scoreThreshold	Seuils paramétrés sur le profil
scoreInfo	Valorisé en fonction des règles déroulées
transactionStatus	Valorisé en fonction de la réponse d'autorisation et du mode de capture
preAuthorisationRuleResultList	Liste du résultat détaillé de chaque règle exécutée
Résultat en orange
responseCode	Valorisé en fonction de la réponse d'autorisation
acquirerResponseCode	Valorisé en fonction de la réponse d'autorisation
scoreColor	ORANGE
scoreValue	Valeur du score global
scoreProfile	Nom du profil antifraude exécuté
preAuthorisationProfileValue	Identifiant unique du profil exécuté
scoreThreshold	Seuils paramétrés sur le profil
scoreInfo	Valorisé en fonction des règles déroulées
transactionStatus	Valorisé en fonction de la réponse d'autorisation et de l'option challenge du commerçant
preAuthorisationRuleResultList	Liste du résultat détaillé de chaque règle exécutée
Résultat en rouge / noir
responseCode	Valorisé à 05
acquirerReponseCode	Non renseigné
scoreColor	BLACK/RED
scoreValue	Valeur du score global
scoreProfile	Nom du profil antifraude exécuté
preAuthorisationProfileValue	Identifiant unique du profil exécuté
scoreThreshold	Seuils paramétrés sur le profil
scoreInfo	Valorisé en fonction des règles déroulées
TransactionStatus	REFUSED
preAuthorisationRuleResultList	Liste du résultat détaillé de chaque règle exécutée

Mode pré-authentification

Le résultat de l'exécution du profil de pré-authentification est restitué dans les champs ci-dessous :

preAuthenticationColor , le résultat des règles représenté dans couleur ;
preAuthenticationValue , la valeur du score global ;
preAuthenticationThreshold , les seuils paramétrés sur le profil ;
preAuthenticationInfo , les informations détaillées des règles exécutées ;
preAuthenticationProfile , le nom du profil antifraude exécuté avant l'authentification ;
preAuthorisationProfileValue , l'identifiant unique de la version du profil exécuté. Cette information est utile pour pouvoir retrouver le profil dans l'état où il se trouvait au moment de l'exécution des contrôles.
preAuthenticationRuleResultList , une liste du résultat détaillé de chaque règle exécutée avant l'authentification.

Chaque objet contenu dans le champ preAuthenticationRuleResultList correspond au résultat d’une règle et contient les mêmes valeurs que le champ preAuthorisationRuleResultList en pré-autorisation. Pour en connaître le contenu, veuillez vous référer au mode pré-autorisation .

Ces champs vous sont restitués sur les interfaces suivantes :

les réponses automatique et manuelle de Sips Paypage ;
la réponse des connecteurs Sips Office (services Checkout, CashManagement (duplication) et Diagnostic) ;
le MEX ;
le journal des transactions à l'exception des champs preAuthenticationInfo et preAuthenticationRuleResultList .


Champ	Description
Résultat en vert / blanc
preAuthenticationColor	WHITE/GREEN
preAuthenticationValue	Valeur du score global
preAuthenticationThreshold	Seuils paramétrés sur le profil
preAuthenticationInfo	Les informations détaillées des règles exécutées
preAuthenticationProfile	Nom du profil antifraude exécuté
preAuthenticationProfileValue	Identifiant unique du profil exécuté
preAuthenticationRuleResultList	Liste du résultat détaillé de chaque règle exécutée
Résultat en orange / rouge / noir
preAuthenticationColor	BLACK/RED/ORANGE
preAuthenticationValue	Valeur du score global
preAuthenticationThreshold	Seuils paramétrés sur le profil
preAuthenticationInfo	Informations détaillées des règles exécutées
preAuthenticationProfile	Nom du profil antifraude exécuté
preAuthenticationProfileValue	Identifiant unique du profil exécuté
preAuthenticationRuleResultList	Liste du résultat détaillé de chaque règle exécutée

Limites d'utilisation

Moyens de paiement

L'offre globale WL Sips propose divers moyens de paiements internationaux, comme les cartes Visa/Mastercard, le portefeuille numérique Paypal, le virement iDeal, le prélèvement SDD, etc.

Les règles ne s'appliquent pas nécessairement à tous les moyens de paiement (exemple : les règles InfoScore ne sont applicables que pour les transactions ELV).

Pour les moyens de paiement single message**, la définition des profils informatifs est techniquement possible, mais le résultat du contrôle n’aura aucun impact sur l’acceptation de la transaction.

Pour savoir si une règle antifraude est applicable à un moyen de paiement, veuillez-vous référer aux correspondances entre moyens de paiement et règles antifraudes .

____________________

** Moyen de paiement en single message : autorisation et remise en une étape, comme les virements tel que Ideal, Sofort, Paybutton ou Paypal en mode immédiate. Moyen de paiement en dual message : autorisation et remise en deux étapes.

Opérations

Les profils antifraudes s’appliquent aux transactions, ainsi qu’aux opérations de caisse provoquant la création d’une nouvelle transaction (duplication et recyclage).

Ainsi les opérations de caisse standards qui manipulent les transactions existantes (validation, annulation, remboursement…) et credit holder ne font pas l’objet des contrôles antifraudes.

Paiement en n fois

Pour le paiement en N fois, seul le 1er paiement est soumis aux contrôles antifraudes.

Transfert de données dans la requête

Pour certaines règles, il est nécessaire de transmettre des données dans la requête. L’absence des données entraîne la non-exécution de la requête.

Par exemple, pour la règle de l’encours par identifiant client, il est nécessaire de transmettre l’identifiant du client dans la requête. Sinon la règle ne sera pas déclenchée.

Mode d'exécution et règles

Les règles ne s'appliquent pas nécessairement aux 2 modes (pré-authentification et pré-autorisation).

Par exemple la règle Authentification 3-D Secure n’est pas disponible en pré-authentification. En effet, cette règle se base sur le résultat de l’authentification 3-D Secure, or le profil antifraude de pré-authentification est appliqué en amont. Cette règle n’est pas applicable avant l’authentification.

Liste des règles

Table 1. Règles de géolocalisation
Nom de la règle	Code de la règle	Type	Config. avancée	Surch.	Débray.	Pré authen.	Pré autor.
Géolocalisation
Pays de la carte	CR	Négative	V	V	V	V	V
Pays de l’adresse IP	CY	Négative	V	V	V	V	V
Pays de la carte et de l’adresse IP	SI	Négative	V	V	V	V	V
Pays de livraison et de facturation	SB	Négative			V	V	V
Codes postaux de livraison et de facturation	ZC	Négative			V	V	V
Pays de livraison et de la carte	CS	Négative	V	V	V	V	V
Pays de facturation et de la carte	CB	Négative	V	V	V	V	V
Pays de l’IBAN	AC	Négative	V	V	V		V
Pays de livraison et l’IBAN	DI	Négative	V	V	V		V
Pays du téléphone et de l’IBAN	PI	Négative	V	V	V		V
Pays de l’adresse IP et de l’IBAN	IS	Négative	V	V	V		V

Table 2. Règles d'encours
Nom de la règle	Code de la règle	Type	Débray.	Pré authen.	Pré autor.
Encours carte	SC	Négative	V	V	V
Encours par adresse IP	VI	Négative	V	V	V
Encours par identifiant client	VC	Négative	V	V	V
Nombre de clients par carte	MD	Négative	V	V	V
Nombre de cartes par client	MR	Négative	V	V	V
Nombre de cartes par adresse IP	CI	Négative	V	V	V
Nombre d’IBAN par adresse IP	II	Négative	V		V
Nombre d’adresses IP par IBAN	IJ	Négative	V		V
Nombre de clients par IBAN	CJ	Négative	V		V
Nombre d’IBAN par client	IC	Négative	V		V
Nombre de mandats par adresse IP	MJ	Négative	V		V
Encours par mandat	EM	Négative	V		V
Encours par IBAN	EI	Négative	V		V

Table 3. Règles diverses
Nom de la règle	Code de la règle	Type	Config. avancée	Surch.	Débray.	Pré authen.	Pré autor.
Réputations d’adresse IP	IR	Négative			V	V	V
Carte en opposition	OP	Négative			V	V	V
Carte virtuelle	EC	Négative			V	V	V
Carte à autorisation systématique	SA	Négative			V	V	V
Carte commerciale (et pays de la carte)	CC	Négative		V	V	V	V
Plage de montants	CA	Négative	V		V	V	V
Carte réseau CB	NC	Négative			V	V	V
Adresse e-mail gratuite	FE	Négative			V	V	V
Authentification 3-D Secure	A3	Négative	V		V		V
Syntaxe d’adresse e-mail	ES	Négative			V	V	V
Vérification d’adresse (InfoScore)	AV	Négative			V		V
Vérification de compte (InfoScore)	BV	Négative			V		V
Date d’expiration de la carte	PE	Négative			V	V	V

Table 4. Règles de liste
Nom de la règle		Code de la règle	Type	Débray.	Pré authen.	Pré autor.
Adresses IP	Noire	BY	Négative	V	V	V
	Grise	GY	Négative	V	V	V
	Blanche	WY	Positive	V	V	V
Codes postaux par pays	Noire	BZ	Négative	V	V	V
	Grise	GZ	Négative	V	V	V
	Blanche	WZ	Positive	V	V	V
Adresses e-mail	Noire	BM	Négative	V	V	V
	Grise	GM	Négative	V	V	V
	Blanche	WM	Positive	V	V	V
ID clients	Noire	BI	Négative	V	V	V
	Grise	GI	Négative	V	V	V
	Blanche	WI	Positive	V	V	V
Noms de clients	Noire	BN	Négative	V	V	V
	Grise	GN	Négative	V	V	V
	Blanche	WN	Positive	V	V	V
Numéros de carte	Noire	BC	Négative	V	V	V
	Grise	GC	Négative	V	V	V
	Blanche	WC	Positive	V	V	V
Numéros de tél.	Noire	BP	Négative	V	V	V
	Grise	GP	Négative	V	V	V
	Blanche	WP	Positive	V	V	V
Plages de BIN	Noire	BB	Négative	V	V	V
	Grise	BR	Négative	V	V	V
	Blanche	WB	Positive	V	V	V
Liste de BIC	Noire	BE	Négative	V		V
	Grise	GE	Négative	V		V
	Blanche	WE	Positive	V		V
Liste d’IBAN	Noire	BA	Négative	V		V
	Grise	GA	Négative	V		V
	Blanche	WA	Positive	V		V
Liste de mandats	Noire	TB	Négative	V		V
	Grise	TG	Négative	V		V
	Blanche	TW	Positive	V		V

Table 5. Règles de panier
Nom de la règle	Code de la règle	Type	Débray.	Pré authen.	Pré autor.
Liste de produits à risque	RP	Négative	V	V	V
Quantité de produits à risque	PQ	Négative	V	V	V
Ratio de produits à risque	PR	Négative	V	V	V
Quantité de produits	QP	Négative	V	V	V

Description et mise en œuvre des règles

Les règles peuvent être paramétrées en combinant les modes décisif ou informatif d'une part et les modes pré-autorisation ou pré-authentification d'autre part.

Règles de géolocalisation : adresse et pays

Note: les listes évoquées dans les règles de géolocalisation ci-dessous sont limitées à 400 éléments, c'est-à-dire 400 pays ou 400 couples de pays (en fonction de la règle concernée).

Pays de la carte

Description de la règle

La règle du pays de la carte vous permet de décider de refuser ou non une transaction en fonction du pays d’émission de la carte du porteur.

La règle va interroger une base de données des plages porteuses afin de vérifier l’appartenance du pays d'origine de la carte à une liste de pays autorisés ou interdits.

En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre code pays comme le seul autorisé.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
et paramétrer la liste des pays de la carte autorisés ou interdits. Pour cela, vous devez :
- paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du MEX ,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative . Un même pays ne peut se trouver que dans l’une des deux listes.

IMPORTANT: information sur les cartes American Express

Notre module de fraude a pour référence la base CIS (Card Info Service), qui contient des informations sur les plages de BIN. Or ce référentiel ne contient pas la nationalité des cartes American Express. Il nous est donc impossible, via le module de fraude, de bloquer les cartes American Express via la règle « Pays de la carte ».

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	CR;N;NOT_APPLICABLE	NOT_APPLICABLE
Le pays de la carte n’est pas connu	0	CR;N; CARD_COUNTRY=XXX*	CARD_COUNTRY=XXX*
Le pays de la carte est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés ou n’est pas équivalent au pays du marchand	0 à -4 selon paramétrage
Le pays de la carte est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits ou est différent du pays du marchand	0

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	CR;N;NOT_APPLICABLE	NOT_APPLICABLE
Le pays de la carte n’est pas connu	0	CR;N; CARD_COUNTRY=XXX*	CARD_COUNTRY=XXX*
Le pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » ou est équivalent à votre pays	0 à -4 selon paramétrage
Le pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés »	0
Le pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés »	0 à +4 selon paramétrage

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous avez la possibilité de fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Il existe 2 méthodes pour surcharger dynamiquement les paramètres de la règle.

MÉTHODE 1 :

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedCardCountryList pour la liste des pays autorisés,
- DeniedCardCountryList pour la liste des pays interdits,
mode de configuration avancée :
- NDeniedCardCountryList pour la liste des pays désavantagés,
- NDeniedExceptCardCountryList pour la liste des pays non désavantagés,
- PAllowedCardCountryList pour la liste des pays avantagés,
- PAllowedExceptCardCountryList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedCardCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}

MÉTHODE 2 (dépréciée) :

La liste des pays carte est transmise dans le champ du connecteur :

fraudData.allowedCardCountryList pour la liste des pays autorisés ;
fraudData.deniedCardCountryList pour la liste des pays interdits.

Exemple en version POST :

      fraudData.allowedCardCountryList=FRA,BEL,GBR

Exemple en version SOAP :

      <urn:fraudData>
     <urn:allowedCardCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "allowedCardCountryList": ["FRA", "BEL", "GBR"]
}

Pour les 2 méthodes, la liste envoyée doit contenir :

soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) séparés par des virgules ;
soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive ForeignBinCard .

Exemple en version POST :

      fraudData.bypassCtrlList=ForeignBinCard

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>ForeignBinCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["ForeignBinCard"]
}

Pays de l'adresse IP

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en fonction du pays affecté à l’adresse IP de l’acheteur.

La règle va vérifier l’appartenance du pays de l’adresse IP à une liste de pays autorisés ou interdits. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage . Dans ce cas-là, une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
ou du transfert que vous effectuez dans la requête en Sips Office .

En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre code pays comme le seul autorisé.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l'onglet 'Fraude' du MEX .
paramétrer la liste des pays de l'adresse IP autorisés ou interdits. Pour cela, vous devez :
- paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du MEX ,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
et transmettre l'adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Le pays de l'adresse IP n’est pas connu.	0	CY;N;IP_COUNTRY=XXX	IP_COUNTRY=XXX
Le pays de l'adresse IP est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés.	0 à -4 selon paramétrage	CY;N;IP_COUNTRY=XXX*	IP_COUNTRY=XXX*
Le pays de l'adresse IP est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits.	0	CY;N;IP_COUNTRY=XXX*	IP_COUNTRY=XXX*

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	Scoreinfo	RuleDetailedInfo
Le pays de l'adresse IP n’est pas connu.	0	CY;N;IP_COUNTRY=XXX	IP_COUNTRY=XXX
Le pays de l'adresse IP est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ».	0 à -4 selon paramétrage	CY;N;IP_COUNTRY=XXX*	IP_COUNTRY=XXX*
Le pays de l'adresse IP est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ».	0
Le pays de l'adresse IP est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ».	0 à +4 selon paramétrage

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Il existe 2 méthodes pour surcharger dynamiquement les paramètres de la règle.

MÉTHODE 1 :

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedIpCountryList pour la liste des pays autorisés,
- DeniedIpCountryList pour la liste des pays interdits,
mode de configuration avancée :
- NDeniedIpCountryList pour la liste des pays désavantagés,
- NDeniedExceptIpCountryList pour la liste des pays non désavantagés,
- PAllowedIpCountryList pour la liste des pays avantagés,
- PAllowedExceptIpCountryList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIpCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}

MÉTHODE 2 (dépréciée) :

La liste des pays de l'adresse IP est transmise dans le champ du connecteur :

fraudData.allowedIpCountryList pour la liste des pays autorisés ;
fraudData.deniedIpCountryList pour la liste des pays interdits.

Exemple en version POST :

      fraudData.allowedIpCountryList=FRA,BEL,GBR

Exemple en version SOAP :

      <urn:fraudData>
     <urn:allowedIpCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "allowedIpCountryList": ["FRA", "BEL", "GBR"]
}

Pour les 2 méthodes, la liste envoyée doit contenir :

soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) séparés par des virgules ;
soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=IpCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>IpCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["IpCountry"]
}

Pays de la carte et de l'adresse IP

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays de la carte et du pays de l'adresse IP de l'acheteur.

Cette règle va interroger la base de données des plages porteuses et celle des plages d’adresses IP afin de vérifier l’appartenance de la combinaison de ces 2 pays à une liste de combinaisons de pays autorisées ou interdites.

Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage . Dans ce cas-là, une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
ou du transfert que vous effectuez dans la requête en Sips Office .

En l’absence de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de la carte et le pays de l'adresse IP.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste des combinaisons pays de la carte et pays de l'adresse IP autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du MEX ,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre l'adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte)	0	SI;N;NOT_APPLICABLE	NOT_APPLICABLE
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s).	0	SI;N; CARD_COUNTRY=XXX; IP_COUNTRY=YYY*	CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
La combinaison du pays de la carte et du pays de l'adresse IP est interdite.	0 à -4 selon paramétrage
La combinaison du pays de la carte et du pays de l'adresse IP est autorisée.	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte)	0	SI;N;NOT_APPLICABLE	NOT_APPLICABLE
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s).	0	SI;N; CARD_COUNTRY=XXX; IP_COUNTRY=YYY*	CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ».	0 à -4 selon paramétrage
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ».	0
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ».	0 à +4 selon paramétrage

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous avez la possibilité d'envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedIpCardCountryCombiList pour les combinaisons autorisées de pays de la carte et de l’adresse IP,
- DeniedIpCardCountryCombiList pour les combinaisons interdites de pays de la carte et de l’adresse IP,
mode de configuration avancée :
- NDeniedIpCardCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptIpCardCountryCombiList pour la liste des pays non désavantagés,
- PAllowedIpCardCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptIpCardCountryCombiList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCardCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam> AllowedIpCardCountryCombiList </urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilityIpCard

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilityIpCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilityIpCard"]
}

Pays de livraison et de facturation

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vérifiant que le pays de livraison et le pays de facturation sont identiques.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et transmettre le pays de livraison et de facturation dans la requête (champs billingAddress.country et deliveryAddress.country ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Le pays de livraison ne correspond pas au pays de facturation	0 à -4 selon paramétrage	SB;N; SHIP_COUNTRY=XXX; BILL_COUNTRY=YYY	SHIP_COUNTRY=XXX; BILL_COUNTRY=YYY
Le pays de livraison correspond au pays de facturation	0
Non connaissance des pays	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilarityDeliveryBillingCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingCountry"]
}

Codes postaux de livraison et de facturation

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vérifiant que le code postal de livraison et le code postal de facturation sont identiques.

Vous ne pouvez activer cette règle que si vous avez aussi activé la règle de comparaison des pays de livraison et de facturation. En effet, il n’est pas pertinent de comparer des codes postaux si les pays ne sont pas identiques.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

avoir déjà la règle « Pays de livraison et de facturation » activée ;
activer la règle dans le profil via l’onglet fraude du MEX
et transmettre le code postal de livraison et de facturation dans la requête (champs billingAddress.zipCode et deliveryAddress.zipCode ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Le code postal de livraison ne correspond pas au code postal de facturation	0 à -4 selon paramétrage	ZC;N; SHIP_COUNTRY=XXX; BILL_COUNTRY=YYY; SHIP_ZIP=A; BILL_ZIP=B*	SHIP_COUNTRY=XXX; BILL_COUNTRY=YYY; SHIP_ZIP=A; BILL_ZIP=B
Le code postal de livraison correspond au code postal de facturation	0
Non connaissance des codes postaux	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

A, B : code postal

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilarityDeliveryBillingPostalCode

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingPostalCode</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingPostalCode"]
}

Pays de livraison et de la carte

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays de la carte et du pays de livraison.

En premier lieu, cette règle va interroger la base de données des plages porteuses pour déterminer le pays de la carte. Ensuite, cette règle vérifiera la présence de la combinaison du pays de la carte fraichement déterminé et du pays de livraison dans la liste des combinaisons autorisées ou interdites.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de la carte et le pays de livraison.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer les combinaisons de pays de livraison et de la carte autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du MEX ,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre le pays de livraison dans la requête (champ deliveryAddress.country ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte)	0	CS;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays de livraison et du pays de la carte est interdite.	0 à -4 selon paramétrage	CS;N; SHIP_COUNTRY=XXX; CARD_COUNTRY=YYY	SHIP_COUNTRY=XXX; CARD_COUNTRY=YYY
La combinaison du pays de livraison et du pays de la carte est autorisée.	0
Non connaissance du pays de la carte ou du pays de livraison.	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte)	0	CS;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ».	0 à -4 selon paramétrage	CS;N; SHIP_COUNTRY=XXX; CARD_COUNTRY=YYY	SHIP_COUNTRY=XXX; CARD_COUNTRY=YYY
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ».	0
Non connaissance du pays de la carte ou du pays de livraison.	0
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ».	0 à +4 selon paramétrage

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedDeliveryCardCountryCombiList pour les combinaisons autorisées de pays de livraison et de la carte,
- DeniedDeliveryCardCountryCombiList pour les combinaisons interdites de pays de livraison et de la carte,
mode de configuration avancée :
- NDeniedDeliveryCardCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptDeliveryCardCountryCombiList pour la liste des pays non désavantagés,
- PAllowedDeliveryCardCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptDeliveryCardCountryCombiList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryCardCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedDeliveryCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,#ZEURO),(#ZEURO,FRA)”
          }
     ]
}

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilarityDeliveryCardCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryCardCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryCardCountry"]
}

Pays de facturation et de la carte

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en se basant sur la combinaison du pays de la carte et du pays de facturation.

En premier lieu, cette règle va interroger la base de données des plages porteuses pour déterminer le pays de la carte. Ensuite, cette règle vérifiera la présence de la combinaison du pays de la carte fraichement déterminé et du pays de facturation dans la liste des combinaisons autorisées ou interdites.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de la carte et le pays de facturation.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer les combinaisons de pays de facturation et de la carte autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du MEX ,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre les pays de facturation et de la carte dans la requête (champs billingAddress.country et cardNumber ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte)	0	CS;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays de facturation et du pays de la carte est interdite.	0 à -4 selon paramétrage	CS;N; BILL_COUNTRY=XXX; CARD_COUNTRY=YYY	BILL_COUNTRY=XXX; CARD_COUNTRY=YYY
La combinaison du pays de facturation et du pays de la carte est autorisée.	0
Non connaissance du pays de la carte ou du pays de facturation.	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte)	0	CS;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés »	0 à -4 selon paramétrage	CS;N; BILL_COUNTRY=XXX; CARD_COUNTRY=YYY	BILL_COUNTRY=XXX; CARD_COUNTRY=YYY
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés »	0
Non connaissance du pays de la carte ou du pays de facturation.	0
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés »	0 à +4 selon paramétrage

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de facturation et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedBillingCardCountryCombiList pour les combinaisons autorisées de pays de facturation et de la carte,
- DeniedBillingCardCountryCombiList pour les combinaisons interdites de pays de facturation et de la carte,
mode de configuration avancée :
- NDeniedBillingCardCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptBillingCardCountryCombiList pour la liste des pays non désavantagés,
- PAllowedBillingCardCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptBillingCardCountryCombiList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedBillingCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedBillingCardCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedBillingCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,#ZEURO),(#ZEURO,FRA)”
          }
     ]
}

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilarityBillingCardCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilarityBillingCardCountry"]
}

Pays de l'IBAN

Description de la règle

La règle du pays de l’IBAN vous permet de mesurer le risque sur un achat en fonction du pays d’émission de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

La règle va analyser le numéro de l’IBAN pour en extraire le pays et vérifier l’appartenance de celui-ci à une liste de pays autorisés ou interdits.

En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre pays comme le seul autorisé.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profilvia l’onglet fraude du MEX ,
et paramétrer la liste des pays d'IBAN autorisés ou interdits. Pour cela, vous devez :
- paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du MEX ,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	AC;N;NOT_APPLICABLE	NOT_APPLICABLE
Le pays de l’IBAN est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés ou est différent de votre pays	0 à -4 selon paramétrage	AC;N; IBAN_COUNTRY=XXX*	IBAN_COUNTRY=XXX*
Le pays de l’IBAN est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits ou est équivalent à votre pays	0	AC;N; IBAN_COUNTRY=XXX*	IBAN_COUNTRY=XXX*

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	AC;N;NOT_APPLICABLE	NOT_APPLICABLE
Le pays de l’IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés »	0 à -4 selon paramétrage	AC;N; IBAN_COUNTRY=XXX*	IBAN_COUNTRY=XXX*
Le pays de l’IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés »	0
Le pays de l’IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés »	0 à +4 selon paramétrage

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedIbanCountryList pour la liste des pays autorisés,
- DeniedIbanCountryList pour la liste des pays interdits,
mode de configuration avancée :
- NDeniedIbanCountryList pour la liste des pays désavantagés,
- NDeniedExceptIbanCountryList pour la liste des pays non désavantagés,
- PAllowedIbanCountryList pour la liste des pays avantagés,
- PAllowedExceptIbanCountryList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIbanCountryList,riskManagementDynamicValue=FRA,BEL,GBR}

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIbanCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIbanCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}

La liste envoyée doit contenir :

soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166), séparés par des virgules ;
soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=IbanCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>IbanCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["IbanCountry"]
}

Pays de livraison et de l'IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays de livraison et du pays de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

Elle va vérifier la présence de la combinaison du pays de livraison et du pays de l’IBAN dans la liste des combinaisons autorisées ou interdites.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de livraison et le pays de l’IBAN.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer les combinaisons de pays de livraison et de pays de l'IBAN autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du MEX ,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre le pays de livraison dans la requête (champ deliveryAddress.country ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	DI;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays de livraison et du pays de l'IBAN est interdite	0 à -4 selon paramétrage	DI;N; SHIP_COUNTRY=XXX; IBAN_COUNTRY=YYY	SHIP_COUNTRY=XXX; IBAN_COUNTRY=YYY
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s)	0
La combinaison du pays de livraison et du pays de l'IBAN est autorisée	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : Codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	DI;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés »	0 à -4 selon paramétrage	DI;N; SHIP_COUNTRY=XXX; IBAN_COUNTRY=YYY	SHIP_COUNTRY=XXX; IBAN_COUNTRY=YYY
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s)	0
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés »	0
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés »	0 à +4 selon paramétrage

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : Codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et pays de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedDeliveryIbanCountryCombiList pour les combinaisons autorisées de pays de livraison et de l’IBAN,
- DeniedDeliveryIbanCountryCombiList pour les combinaisons interdites de pays de livraison et de l’IBAN,
mode de configuration avancée :
- NDeniedDeliveryIbanCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptDeliveryIbanCountryCombiList pour la liste des pays non désavantagés,
- PAllowedDeliveryIbanCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptDeliveryIbanCountryCombiList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedDeliveryIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}

La liste envoyée doit contenir des couples séparés par des virgules et constitués :

soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilarityDeliveryIbanCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryIbanCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryIbanCountry"]
}

Pays du numéro de téléphone et de l'IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays du numéro de téléphone portable du client et du pays de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

La règle va vérifier la présence de la combinaison du pays du numéro de téléphone portable du client et du pays de l’IBAN dans la liste des combinaisons autorisées ou interdites.

Le pays du numéro de téléphone est obtenu en analysant l’indicatif de celui-ci. Si l’indicatif n’est pas spécifié, le pays ne pourra être récupéré.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays du numéro de téléphone portable du client et le pays de l’IBAN.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer les combinaisons de pays de numéro de téléphone et de pays de l'IBAN autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du MEX ,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre le numéro de téléphone portable du client dans la requête (avec indicatif ; champ mobile dans un ou plusieurs groupes d’informations de contact : billingContact, customerContact, deliveryContact, holderContact ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	PI;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est interdite	0 à -4 selon paramétrage	PI;N; PHONE_COUNTRY=XXX; IBAN_COUNTRY=YYY	PHONE_COUNTRY=XXX; IBAN_COUNTRY=YYY
Le pays du numéro de téléphone portable du client et/ou le pays de l'IBAN n’est/ne sont pas connu(s)	0
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est autorisée	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	PI;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés »	0 à -4 selon paramétrage	PI;N; PHONE_COUNTRY=XXX; IBAN_COUNTRY=YYY	PHONE_COUNTRY=XXX; IBAN_COUNTRY=YYY
Le pays du numéro de téléphone portable du client et/ou le pays de l'IBAN n’est/ne sont pas connu(s)	0
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés »	0
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés »	0 à +4 selon paramétrage

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons du pays du numéro de téléphone portable du client et pays de l’IBAN. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les 2 paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedPhoneIbanCountryCombiList pour les combinaisons autorisées de pays du numéro de téléphone portable du client et de l’IBAN,
- DeniedPhoneIbanCountryCombiList pour les combinaisons interdites de pays du numéro de téléphone portable du client et de l’IBAN,
mode de configuration avancée :
- NDeniedPhoneIbanCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptPhoneIbanCountryCombiList pour la liste des pays non désavantagés,
- PAllowedPhoneIbanCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptPhoneIbanCountryCombiList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedPhoneIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>llowedPhoneIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedPhoneIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilarityPhoneIbanCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityPhoneIbanCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilarityPhoneIbanCountry"]
}

Pays de l'adresse IP et de l'IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays de l’adresse IP du client et du pays de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

Elle va vérifier l’appartenance de la combinaison du pays de l’adresse IP et du pays de l’IBAN à une liste de combinaisons de pays autorisés ou interdits.

Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage . Dans ce cas-là, Une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
ou du transfert que vous effectuez dans la requête en Sips Office . En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de l’adresse IP du client et le pays de l’IBAN.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer les combinaisons de pays d'adresse IP et de pays de l'IBAN autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du MEX ,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre l'adresse IP de l'acheteur dans la requête, si vous êtes sur Sips Office .

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	IS;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays de l’adresse IP et du pays de l'IBAN est interdite	0 à -4 selon paramétrage	IS;N; IP_COUNTRY=XXX; IBAN_COUNTRY=YYY	IP_COUNTRY=XXX; IBAN_COUNTRY=YYY
Le pays de l’adresse IP et/ou le pays de l'IBAN n’est/ne sont pas connu(s)	0
La combinaison du pays de l’adresse IP et du pays de l'IBAN est autorisée	0

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD)	0	IS;N;NOT_APPLICABLE	NOT_APPLICABLE
La combinaison du pays du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés »	0 à -4 selon paramétrage	IS;N; IP_COUNTRY=XXX; IBAN_COUNTRY=YYY	IP_COUNTRY=XXX; IBAN_COUNTRY=YYY
Le pays de l'adresse IP et/ou le pays de l'IBAN n’est/ne sont pas connu(s)	0
La combinaison du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés »	0
La combinaison du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés »	0 à +4 selon paramétrage

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons du pays de l’adresse IP et pays de l’IBAN. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les 2 paramètres applicables à cette règle sont :

mode par défaut (configuration simple) :
- AllowedIpIbanCountryCombiList pour les combinaisons autorisées de pays d’adresse IP et de l’IBAN,
- DeniedIpIbanCountryCombiList pour les combinaisons interdites de pays d’adresse IP et de l’IBAN,
mode de configuration avancée :
- NDeniedIpIbanCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptIpIbanCountryCombiList pour la liste des pays non désavantagés,
- PAllowedIpIbanCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptIpIbanCountryCombiList pour la liste des pays non avantagés.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIpIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>>>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SimilarityIpIbanCountry

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SimilarityIpIbanCountry"]
}

Règles d'encours (vélocité)

Les règles d’encours calculent le cumul du montant ou de la quantité pour un aspect de la transaction sur une période (quelquefois deux) et le comparent à un seuil à ne pas dépasser. Ils vous permettent de superviser les activités d'un client, d’une adresse IP, d’une carte, etc.

Par exemple, des règles d’encours peuvent se déclencher si le montant cumulé dépensé sur une carte particulière dépasse 1 500€ sur les dernières 24 h ou si un client a passé plus de 10 transactions sur la semaine écoulée.

Il existe deux manières de calculer les encours :

par défaut, les encours sont calculés en prenant en compte les transactions d’une seule boutique ;
vous pouvez également calculer les encours en cumulant les activités de plusieurs boutiques. Un tel encours est dit « partagé ». Les encours partagés élargissent le périmètre de la surveillance.

Tip: lors du paramétrage d'un profil, vous avez la possibilité de prendre en compte les transactions refusées (en plus des transactions acceptées) dans les calculs.

Pour mettre en place un encours partagé, vous devez contacter votre gestionnaire de compte pour la configuration. Deux étapes sont à respecter :

tout d'abord créer un encours partagé en choisissant son type (encours par carte, encours par adresse IP, etc.) ;
puis associer l’encours partagé aux boutiques.

Lors de l'exécution d’un contrôle de lutte contre la fraude, si la règle d’encours partagé est active dans le profil de la boutique, les activités seront calculées et ajoutées avec les activités des autres boutiques du groupe.

5 encours partagés peuvent être mis en place par type de règle d’encours et par groupe commercial.

Encours carte

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant cumulé des transactions) de la carte.

La règle est exécutée sur toutes les transactions de paiement effectuées avec une carte. Le calcul de l’encours prend en compte les transactions qui ont été acceptées au préalable sur les périodes indiquées. Il est aussi possible d'ajouter les transactions refusées à ce calcul.

La règle contrôle l’activité d’une carte sur deux périodes distinctes. Vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions, ainsi que les périodes respectives, lors du paramétrage du profil.

Exemple

Le tableau suivant décrit l'évolution de l'historique de la carte de paiement dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour la même carte, pour un montant total de 500 € et par mois (30 j) :


Date de la transaction	Détails du paiement	Résultat de la règle	Encours par carte (nombre de transactions)	Encours par carte (montant cumulé)	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 Montant : 100 € Carte : CB1	OK	1	100 €	TR1 01/10/2018 CB1 100 €
07/10/2018	Transaction TR2 Montant : 400 € Carte : CB2	OK	1	400 €	TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2 400 €
10/10/2018	Transaction TR3 Montant : 400 € Carte : CB2	KO	2	800 € (> 500)	TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2 400 € OK TR3 10/10/2018 CB2 400 €
12/10/2018	Transaction TR4 Montant : 200 € Carte : CB1	OK	2	300 €	TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2 400 € OK TR3 10/10/2018 CB2 400 € KO TR4 12/10/2018 CB1 200 €
15/10/2018	Transaction TR5 Montant : 100 € Carte : CB1	KO	3 (> 2)	400 €	TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2 400 € TR3 10/10/2018 CB2 400 € KO TR4 12/10/2018 CB1 200 € OK TR5 15/10/2018 CB1 100 €
02/11/2018 (> 30j)	Transaction TR6 Montant : 300 € Carte : CB1	OK	1	300 €	TR6 02/11/2018 CB1 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
et paramétrer le nombre de transactions effectuées et/ou le montant cumulé, ainsi que les périodes respectives, via l’onglet fraude du MEX .


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Montant cumulé maximal	0.01 sur la période en devise du commerçant	9999999
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal de transactions	1 transaction sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte)	0	SC;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cette carte sur la période dépasse(nt) la/les limite(s) acceptée(s)	0 à -4 selon paramétrage	SC;N;TRANS=A:B; CUMUL=C:D*	TRANS=A:B; CUMUL=C:D*
Le nombre des transactions effectuées et la somme des montants cumulés avec cette carte sur la période sont inférieurs aux limites acceptées	0	SC;N;TRANS=A:B; CUMUL=C:D*	TRANS=A:B; CUMUL=C:D*

*A : le nombre de transactions effectuées avec cette carte sur la période.

B : le nombre maximum de transactions acceptées avec une carte sur la période.

C : la somme des montants cumulés sur la période avec cette carte.

D : la somme maximum des montants cumulés acceptés avec une carte sur la période.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=VelocityCard

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["VelocityCard"]
}

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, l’annulation et le remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Encours par adresse IP

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre des transactions et/ou le montant cumulé des transactions) d’un client à partir d’une adresse IP sur une période.

La règle est exécutée sur toutes les transactions de paiement. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir d’une adresse IP sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

Exemple

Le tableau suivant décrit l'évolution de l'historique d'adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour la même IP, pour un montant total de 500 € et par mois (30 j) :


Date de la transaction	Détails du paiement	Résultat de la règle	Encours par adresse IP (nombre de transactions)	Encours par adresse IP (montant cumulé)	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 Montant : 100 € IP : 105.24.68.102	OK	1	100 €	TR1 01/10/2018 105.24.68.102 100 €
07/10/2018	Transaction TR2 Montant : 400 € IP : 254.24.78.175	OK	1	400 €	TR1 01/10/2018 105.24.68.102 100 € OK TR2 07/10/2018 254.24.78.175 400 €
10/10/2018	Transaction TR3 Montant : 400 € IP : 254.24.78.175	KO	2	800 € (> 500)	TR1 01/10/2018 105.24.68.102 100 € OK TR2 07/10/2018 254.24.78.175 400 € OK TR3 10/10/2018 254.24.78.175 400 €
12/10/2018	Transaction TR4 Montant : 200 € IP : 105.24.68.102	OK	2	300 €	TR1 01/10/2018 105.24.68.102 100 € OK TR2 07/10/2018 254.24.78.175 400 € OK TR3 10/10/2018 254.24.78.175 400 € KO TR4 12/10/2018 105.24.68.102 200 €
15/10/2018	Transaction TR5 Montant : 100 € IP : 105.24.68.102	KO	3 (> 2)	400 €	TR1 01/10/2018 105.24.68.102 100 € OK TR2 07/10/2018 254.24.78.175 400 € OK TR3 10/10/2018 254.24.78.175 400 € KO TR4 12/10/2018 105.24.68.102 200 € OK TR5 15/10/2018 105.24.68.102 100 €
02/11/2018 (> 30j)	Transaction TR6 Montant : 300 € IP : 105.24.68.102	OK	1	300 €	TR6 02/11/2018 105.24.68.102 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du MEX
et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Montant cumulé maximal	0.01 sur la période en devise du commerçant	9999999
Nombre maximal de transactions	1 transaction sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cette adresse IP sur la période dépasse(nt) la/les limite(s) acceptée(s)	0 à -4 selon paramétrage	VI;N;TRANS=A:B; CUMUL=C:D*	NOT_APPLICABLE
Le nombre des transactions effectuées et la somme des montants cumulés avec cette adresse IP sur la période sont inférieurs aux limites acceptées	0		TRANS=A:B; CUMUL=C:D*
L'adresse IP n'est pas renseignée (en Sips Office )	0		TRANS=A:B; CUMUL=C:D*

*A : le nombre de transactions effectuées avec cette adresse IP sur la période.

B : le nombre maximum de transactions acceptées avec une adresse IP sur la période.

C : la somme des montants cumulés sur la période avec cette adresse IP.

D : la somme maximum des montants cumulés acceptés avec une adresse IP sur la période.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=VelocityIp

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityIp</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["VelocityIp"]
}

Limites d'utilisation

L'historique d'adresse IP n'est pas mis à jour lors des opérations de remboursement, d'annulation ou de validation, qu'elles soient partielles ou totales.

Encours par identifiant client

Description de la règle

La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’identifiant client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir d’un identifiant client sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période.

Exemple

Le tableau suivant décrit l'évolution de l'historique d'ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois maximum pour le même client, pour un montant maximum de 500 € et par mois (30 j) :


Date de la transaction	Détails du paiement	Résultat de la règle	Encours par client (nombre de transactions)	Encours par client (montant cumulé)	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 Montant : 100 € CustomerID : cust1	OK	1	100 €	TR1 01/10/2018 cust1 100 €
07/10/2018	Transaction TR2 Montant : 400 € CustomerID : cust2	OK	1	400 €	TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018 cust2 400 €
10/10/2018	Transaction TR3 Montant : 400 € CustomerID : cust2	KO	2	800 € (> 500)	TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018 cust2 400 € OK TR3 10/10/2018 cust2 400 €
12/10/2018	Transaction TR4 Montant : 200 € CustomerID : cust1	OK	2	300 €	TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018 cust2 400 € OK TR3 10/10/2018 cust2 400 € KO TR4 12/10/2018 cust1 200 €
15/10/2018	Transaction TR5 Montant : 100 € CustomerID : cust1	KO	3 (> 2)	400 €	TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018 cust2 400 € OK TR3 10/10/2018 cust2 400 € KO TR4 12/10/2018 cust1 200 € OK TR5 15/10/2018 cust1 100 €
02/11/2018 (> 30j)	Transaction TR6 Montant : 300 € CustomerID : cust1	OK	1	300 €	TR6 02/11/2018 cust1 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du MEX
et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId ).


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Montant cumulé maximal	0.01 sur la période en devise du commerçant	9999999
Nombre maximal de transactions	1 transaction sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
L’identifiant client n’est pas fourni	0	VC;N;TRANS=A:B; CUMUL=C:D*	NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cet identifiant client sur la période dépasse(nt) la/les limite(s) acceptée(s)	0 à -4 selon paramétrage		TRANS=A:B; CUMUL=C:D*
Le nombre des transactions effectuées et la somme des montants cumulés avec cet identifiant client sur la période sont inférieures aux limites acceptées	0		TRANS=A:B; CUMUL=C:D*

*A : le nombre de transactions effectuées avec cet identifiant client sur la période.

B : le nombre maximum de transactions acceptées avec un identifiant client sur la période.

C : la somme des montants cumulés sur la période avec cet identifiant client.

D : la somme maximum des montants cumulés acceptés avec un identifiant client sur la période.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=VelocityCustomerId

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityCustomerId</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["VelocityCustomerId"]
}

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, l’annulation et le remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Nombre de clients par carte

Description de la règle

Cette règle vous permet de vérifier qu’une carte donnée n’est pas utilisée par un nombre trop élevé de clients différents sur une période.

La règle contrôle l’activité à partir du numéro de carte et de l’identifiant du client sur une période donnée.

Exemple

Le tableau suivant décrit l'évolution de l'historique d'ID client/carte dans le cas où vous avez choisi de limiter les achats sur votre site à 3 clients par mois (30 j) avec la même carte :


Date de la transaction	Détails du paiement	Résultat de la règle	Clients/carte	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 CustomerID : cust1 Carte : CB1	OK	1	TR1 01/10/2018 cust1 CB1
07/10/2018	Transaction TR2 CustomerID : cust2 Carte : CB2	OK	2	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust2 CB1
12/10/2018	Transaction TR3 CustomerID : cust3 Carte : CB1	OK	3	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust2 CB1 OK TR3 12/10/2018 cust3 CB1
20/10/2018	Transaction TR4 CustomerID : cust4 Carte : CB1	KO	4 (> 3)	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust2 CB1 OK TR3 12/10/2018 cust3 CB1 OK TR4 20/10/2018 cust4 CB1
25/10/2018	Transaction TR5 CustomerID : cust4 Carte : CB2	OK	1	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust2 CB1 OK TR3 12/10/2018 cust3 CB1 OK TR4 20/10/2018 cust4 CB1 KO TR5 25/10/2018 cust4 CB2
27/10/2018	Transaction TR6 CustomerID : cust1 Carte : CB1	OK	3	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust2 CB1 OK TR3 12/10/2018 cust3 CB1 OK TR4 20/10/2018 cust4 CB1 KO TR5 25/10/2018 cust4 CB2 OK TR6 27/10/2018 cust1 CB1
02/03/2018 (> 30j)	Transaction TR7 CustomerID : cust5 Carte : CB1	OK	1	TR7 02/03/2018 cust5 CB1

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du MEX
et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId ).


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal de clients	1 client sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte)	0	MD;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre de clients différents utilisant la même carte sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	MD;N;MAX=A:B*	MAX=A:B*
Le nombre de clients différents utilisant la même carte sur la période est inférieur à la limite acceptée	0
L'identifiant client n'est pas renseigné	0

*A : le nombre de clients ayant utilisé la même carte sur la période.

B : le nombre maximum de clients acceptés pour la même carte.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=MaxCustomerIdPerCard

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxCustomerIdPerCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxCustomerIdPerCard"]
}

Limites d'utilisation

L'historique CustomerID/Carte d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de cartes par client

Description de la règle

Cette règle vous permet de vérifier qu’un client donné n’utilise pas un nombre trop élevé de cartes différentes sur une période.

La règle contrôle l’activité à partir du numéro de carte et de l’identifiant du client sur une période donnée.

Exemple

Le tableau suivant décrit l'évolution de l'historique Cartes/ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 3 cartes par mois (30 j) pour un même client :


Date de la transaction	Détails du paiement	Résultat de la règle	Cartes/client	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 ID client : cust1 Carte : CB1	OK	1	TR1 01/10/2018 cust1 CB1
07/10/2018	Transaction TR2 ID client : cust1 Carte : CB2	OK	2	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust1 CB2
12/10/2018	Transaction TR3 ID client : cust1 Carte : CB3	OK	3	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust1 CB2 OK TR3 12/10/2018 cust1 CB3
20/10/2018	Transaction TR4 ID client : cust1 Carte : CB4	KO	4 (> 3)	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust1 CB2 OK TR3 12/10/2018 cust1 CB3 OK TR4 20/10/2018 cust1 CB4
25/10/2018	Transaction TR5 ID client : cust2 Carte : CB4	OK	1	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust1 CB2 OK TR3 12/10/2018 cust1 CB3 OK TR4 20/10/2018 cust1 CB4 KO TR5 25/10/2018 cust2 CB4
27/10/2018	Transaction TR6 ID client : cust1 Carte : CB1	OK	3	TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust1 CB2 OK TR3 12/10/2018 cust1 CB3 OK TR4 20/10/2018 cust1 CB4 KO TR5 25/10/2018 cust2 CB4 OK TR6 27/10/2018 cust1 CB1
02/03/2018 (> 30 j)	Transaction TR7 ID client : cust1 Carte : CB5	OK	1	TR7 02/03/2018 cust1 CB5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du MEX ,
et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId ).


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal de cartes	1 carte sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte)	0	MR;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre de cartes différentes utilisées par le même client sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	MR;N;MAX=A:B*	MAX=A:B*
Le nombre de cartes différentes utilisées par le même client sur la période est inférieur à la limite acceptée	0
L'identifiant client n'est pas renseigné	0

*A : le nombre de cartes utilisées par le même client sur la période.

B : le nombre maximum de cartes acceptées pour le même client.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=MaxCardPerCustomerId

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerCustomerId</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxCardPerCustomerId"]
}

Limites d'utilisation

L'historique Cartes/CustomerID d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de cartes par adresse IP

Description de la règle

Cette règle vous permet de vérifier que des transactions en provenance d’une IP donnée n’utilisent pas un nombre trop élevé de cartes différentes sur une période.

La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’adresse IP de client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir du numéro de carte et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

Exemple

Le tableau suivant décrit l'évolution de l'historique Cartes/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 cartes par mois (30 j), pour un même client :


Date de la transaction	Détails du paiement	Résultat de la règle	Cartes/IP	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 IP : 105.24.68.102 Carte : CB1	OK	1	TR1 01/10/2018 105.24.68.102 CB1
07/10/2018	Transaction TR2 IP : 105.24.68.102 Carte : CB2	OK	2	TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018 105.24.68.102 CB2
12/10/2018	Transaction TR3 IP : 105.24.68.102 Carte : CB3	OK	3	TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018 105.24.68.102 CB3
20/10/2018	Transaction TR4 IP : 105.24.68.102 Carte : CB4	KO	4 (> 3)	TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018 105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102 CB4
25/10/2018	Transaction TR5 IP : 254.24.78.175 Carte : CB4	OK	1	TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018 105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102 CB4 KO TR5 25/10/2018 254.24.78.175 CB4
27/10/2018	Transaction TR6 IP : 105.24.68.102 Carte : CB1	OK	3	TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018 105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102 CB4 KO TR5 25/10/2018 254.24.78.175 CB4 OK TR6 27/10/2018 105.24.68.102 CB1
02/03/2018 (> 30 j)	Transaction TR7 IP : 105.24.68.102 Carte : CB5	OK	1	TR7 02/03/2018 105.24.68.102 CB5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du MEX
et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal de cartes	1 carte sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte)	0	CI;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre de cartes différentes provenant de la même adresse IP sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	CI;N;MAX=A:B*	MAX=A:B*
Le nombre de cartes différentes provenant de la même adresse IP sur la période est inférieur à la limite acceptée	0
L’adresse IP n’est pas renseignée (en Sips Office )	0

*A : le nombre de cartes utilisées par la même adresse IP sur la période.

B : le nombre maximum de cartes acceptées pour la même adresse IP.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=MaxCardPerIp

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerIp</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxCardPerIp"]
}

Limites d'utilisation

L'historique Cartes/adresse IP d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre d'IBAN par adresse IP

Description de la règle

Cette règle vous permet de vérifier que des transactions en provenance d’une adresse IP donnée n’utilisent pas un nombre trop élevé d’IBAN différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

Exemple

Le tableau suivant décrit l'évolution de l'historique IBAN/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 IBAN par mois (30 j), pour une même adresse IP :


Date de la transaction	Détails du paiement	Résultat de la règle	IBAN/IP	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 IP : 105.24.68.102 IBAN : IBAN1	OK	1	TR1 01/10/2018 105.24.68.102 IBAN1
07/10/2018	Transaction TR2 IP : 105.24.68.102 IBAN : IBAN2	OK	2	TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN2
12/10/2018	Transaction TR3 IP : 105.24.68.102 IBAN : IBAN3	OK	3	TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN2 OK TR3 12/10/2018 105.24.68.102 IBAN3
20/10/2018	Transaction TR4 IP : 105.24.68.102 IBAN : IBAN4	KO	4 (> 3)	TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN2 OK TR3 12/10/2018 105.24.68.102 IBAN3 OK TR4 20/10/2018 105.24.68.102 IBAN4
25/10/2018	Transaction TR5 IP : 254.24.78.175 IBAN : IBAN4	OK	1	TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN2 OK TR3 12/10/2018 105.24.68.102 IBAN3 OK TR4 20/10/2018 105.24.68.102 IBAN4 KO TR5 25/10/2018 254.24.78.175 IBAN4
27/10/2018	Transaction TR6 IP : 105.24.68.102 IBAN : IBAN1	OK	3	TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018 105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102 CB4 KO TR5 25/10/2018 254.24.78.175 CB4 OK TR6 27/10/2018 105.24.68.102 CB1
02/03/2018 (> 30 j)	Transaction TR7 IP : 105.24.68.102 IBAN : IBAN5	OK	1	TR7 02/03/2018 105.24.68.102 IBAN5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du MEX
et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal d'IBAN	1 IBAN sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD)	0	II;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre d’IBAN différents provenant de la même adresse IP sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	II;N;MAX=A:B*	MAX=A:B*
L’adresse IP n’est pas renseignée (en Sips Office )	0
Le nombre d’IBAN différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée	0

*A : le nombre de d'IBAN utilisés par la même adresse IP sur la période.

B : le nombre maximum d'IBAN acceptés pour la même adresse IP.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=MaxIbanPerIp

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerIp</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxIbanPerIp"]
}

Limites d'utilisation

L'historique IBAN/adresse IP n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre d'adresses IP par IBAN

Description de la règle

Cette règle vous permet de vérifier qu’un IBAN n’est pas utilisé par un nombre trop élevé d’adresses IP différentes sur une période.

La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

Exemple

Le tableau suivant décrit l'évolution de l'historique adresse IP/IBAN dans le cas où vous avez choisi de limiter les achats sur votre site à 3 adresses IP par mois (30 j) pour un même IBAN :


Date de la transaction	Détails du paiement	Résultat de la règle	IP/IBAN	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 IP : 105.24.68.101 IBAN : IBAN1	OK	1	TR1 01/10/2018 105.24.68.101 IBAN1
07/10/2018	Transaction TR2 IP : 105.24.68.102 IBAN : IBAN1	OK	2	TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN1
12/10/2018	Transaction TR3 IP : 105.24.68.103 IBAN : IBAN1	OK	3	TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018 105.24.68.103 IBAN1
20/10/2018	Transaction TR4 IP : 105.24.68.104 IBAN : IBAN1	KO	4 (> 3)	TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018 105.24.68.103 IBAN1 OK TR4 20/10/2018 105.24.68.104 IBAN1
25/10/2018	Transaction TR5 IP : 105.24.68.104 IBAN : IBAN2	OK	1	TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018 105.24.68.103 IBAN1 OK TR4 20/10/2018 105.24.68.104 IBAN1 KO TR5 25/10/2018 105.24.68.104 IBAN2
27/10/2018	Transaction TR6 IP : 105.24.68.101 IBAN : IBAN1	OK	3	TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2 07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018 105.24.68.103 IBAN1 OK TR4 20/10/2018 105.24.68.104 IBAN1 KO TR5 25/10/2018 105.24.68.104 IBAN2 TR6 27/10/2018 105.24.68.101 IBAN1
02/03/2018 (> 30 j)	Transaction TR7 IP : 105.24.68.105 IBAN : IBAN1	OK	1	TR7 02/03/2018 105.24.68.105 IBAN1

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre maximum d'adresses IP et la durée du cumul via l’onglet fraude du MEX
et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal d'adresses IP	1 adresse IP sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD)	0	IJ;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre d’adresses IP différentes avec le même IBAN sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	IJ;N;MAX=A:B*	MAX=A:B*
L’adresse IP n’est pas renseignée (en Sips Office )	0
Le nombre d’adresses IP différentes avec le même IBAN sur la période est inférieur à la limite acceptée	0

*A : le nombre d'adresses IP utilisées par le même IBAN sur la période.

B : le nombre maximum d'adresses IP acceptées pour le même IBAN.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST

      fraudData.bypassCtrlList=MaxIpPerIban

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxIpPerIban</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxIpPerIban"]
}

Limites d'utilisation

L'historique adresse IP/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de clients par IBAN

Description de la règle

Cette règle vous permet de vérifier qu’un IBAN n’est pas utilisé par un nombre trop élevé de clients différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client et l’identifiant du client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

Exemple

Le tableau suivant décrit l'évolution de l'historique ID client/IBAN dans le cas où vous avez choisi de limiter les achats sur votre site à 3 clients par mois (30 j) avec le même IBAN :


Date de la transaction	Détails du paiement	Résultat de la règle	Clients/IBAN	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 ID client : cust1 IBAN : IBAN1	OK	1	TR1 01/10/2018 cust1 IBAN1
07/10/2018	Transaction TR2 ID client : cust2 IBAN : IBAN1	OK	2	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust2 IBAN1
12/10/2018	Transaction TR3 ID client : cust3 IBAN : IBAN1	OK	3	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1
20/10/2018	Transaction TR4 ID client : cust4 IBAN : IBAN1	KO	4 (> 3)	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1 OK TR4 20/10/2018 cust4 IBAN1
25/10/2018	Transaction TR5 ID client : cust4 IBAN : IBAN2	OK	1	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1 OK TR4 20/10/2018 cust4 IBAN1 KO TR5 25/10/2018 cust4 IBAN2
27/10/2018	Transaction TR6 ID client : cust1 IBAN : IBAN1	OK	3	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1 OK TR4 20/10/2018 cust4 IBAN1 KO TR5 25/10/2018 cust4 IBAN2 OK TR6 27/10/2018 cust1 IBAN1
02/03/2018 (> 30 j)	Transaction TR7 ID client : cust5 IBAN : IBAN1	OK	1	TR7 02/03/2018 cust5 IBAN1

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du MEX
et transmettre l’identifiant client dans la requête (champ customerId ).


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal de clients	1 client sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD)	0	CJ;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre de clients différents utilisant le même IBAN sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	CJ;N;MAX=A:B*	MAX=A:B*
L’identifiant client n’est pas renseigné	0
Le nombre de clients différents utilisant le même IBAN sur la période est inférieur à la limite acceptée	0

*A : le nombre de clients utilisant le même IBAN sur la période.

B : le nombre maximum de clients acceptés pour le même IBAN.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=MaxCustidPerIban

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>MaxCustidPerIban</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["MaxCustidPerIban"]
}

Limites d'utilisation

L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre d'IBAN par client

Description de la règle

Cette règle vous permet de vérifier qu’un client n’utilise pas un nombre trop élevé d’IBAN différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’identifiant du client est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir de l’identifiant client (customerId) et de l’IBAN sur une période donnée.

Exemple

Le tableau suivant décrit l'évolution de l'historique IBAN/ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 3 IBAN par mois (30 j) pour un client :


Date de la transaction	Détails du paiement	Résultat de la règle	IBAN/client	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 ID client : cust1 IBAN : IBAN1	OK	1	TR1 01/10/2018 cust1 IBAN1
07/10/2018	Transaction TR2 ID client : cust1 IBAN : IBAN2	OK	2	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust1 IBAN2
12/10/2018	Transaction TR3 ID client : cust1 IBAN : IBAN3	OK	3	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3
20/10/2018	Transaction TR4 ID client : cust1 IBAN : IBAN4	KO	4 (> 3)	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3 OK TR4 20/10/2018 cust1 IBAN4
25/10/2018	Transaction TR5 ID client : cust2 IBAN : IBAN4	OK	1	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3 OK TR4 20/10/2018 cust1 IBAN4 KO TR5 25/10/2018 cust2 IBAN4
27/10/2018	Transaction TR6 ID client : cust1 IBAN : IBAN1	OK	3	TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3 OK TR4 20/10/2018 cust1 IBAN4 KO TR5 25/10/2018 cust2 IBAN4 OK TR6 27/10/2018 cust1 IBAN1
02/03/2018 (> 30 j)	Transaction TR7 ID client : cust1 IBAN : IBAN5	OK	1	TR7 02/03/2018 cust1 IBAN5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du MEX
et transmettre l’identifiant client dans la requête (champ customerI d).


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal d'IBAN	1 IBAN sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD)	0	IC;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre d’IBAN différents utilisés par le même client sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	IC;N;MAX=A:B*	MAX=A:B*
L’identifiant client n’est pas renseigné	0
Le nombre d’IBAN différents utilisés par le même client sur la période est inférieur à la limite acceptée	0

*A : le nombre d'IBAN utilisés pour un même client sur la période.

B : le nombre maximum d'IBAN acceptés pour le même client.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=MaxIbanPerCustid

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerCustid</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["MaxIbanPerCustid"]
}

Limites d'utilisation

L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de mandats par adresse IP

Description de la règle

Cette règle vous permet de vérifier qu’une adresse IP n’utilise pas un nombre trop élevé de mandats SDD, désignés par leurs RUM (Référence Unique de Mandat), différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir du mandat et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

Exemple

Le tableau suivant décrit l'évolution de l'historique mandat/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 mandats par mois (30 j) pour une adresse IP :


Date de la transaction	Détails du paiement	Résultat de la règle	Mandats/IP	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 IP : 105.24.68.102 Mandat : RUM1	OK	1	TR1 01/10/2018 105.24.68.102 RUM1
07/10/2018	Transaction TR2 IP : 105.24.68.102 Mandat : RUM2	OK	2	TR1 01/10/2018 105.24.68.102 RUM1 OK TR2 07/10/2018 105.24.68.102 RUM2
12/10/2018	Transaction TR3 IP : 105.24.68.102 Mandat : RUM3	OK	3	TR1 01/10/2018 105.24.68.102 RUM1 OK TR2 07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018 105.24.68.102 RUM3
20/10/2018	Transaction TR4 IP : 105.24.68.102 Mandat : RUM4	KO	4 (> 3)	TR1 01/10/2018 105.24.68.102 RUM1 OK TR2 07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018 105.24.68.102 RUM3 OK TR4 20/10/2018 105.24.68.102 RUM4
25/10/2018	Transaction TR5 IP : 254.24.78.175 Mandat : RUM4	OK	1	TR1 01/10/2018 105.24.68.102 RUM1 OK TR2 07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018 105.24.68.102 RUM3 OK TR4 20/10/2018 105.24.68.102 RUM4 KO TR5 25/10/2018 254.24.78.175 RUM4
27/10/2018	Transaction TR6 IP : 105.24.68.102 Mandat : RUM1	OK	3	TR1 01/10/2018 105.24.68.102 RUM1 OK TR2 07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018 105.24.68.102 RUM3 OK TR4 20/10/2018 105.24.68.102 RUM4 KO TR5 25/10/2018 254.24.78.175 RUM4 OK TR6 27/10/2018 105.24.68.102 RUM1
02/03/2018 (> 30 j)	Transaction TR7 IP : 105.24.68.102 Mandat : RUM5	OK	1	TR7 02/03/2018 105.24.68.102 RUM5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet 'Fraude' du MEX ,
paramétrer le nombre maximum de mandats et la durée du cumul également via l’onglet 'Fraude' du MEX
et transmettre l’adresse IP de l'acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Nombre maximal de mandats	1 mandat sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD)	0	MJ;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre de mandats différents provenant de la même adresse IP sur la période dépasse la limite acceptée	0 à -4 selon paramétrage	MJ;N;MAX=A:B*	MAX=A:B*
L'adresse IP n’est pas renseignée	0
Le nombre de mandats différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée	0

*A : le nombre de mandats utilisés pour une même adresse IP sur la période.

B : le nombre maximum de mandats acceptés pour la même adresse IP.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=MaxMandatePerIp

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>MaxMandatePerIp</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["MaxMandatePerIp"]
}

Limites d'utilisation

L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Encours par mandat

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant des transactions cumulé) du mandat SDD, désigné par son RUM (Référence Unique de Mandat), sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité d’un mandat sur une période donnée. Vous devez obligatoirement fournir le nombre des transactions et/ou le montant des transactions cumulé et la durée de la période lors du paramétrage du profil.

Exemple

Le tableau suivant décrit l'évolution de l'historique du mandat dans le cas où vous avez choisi de limiter les achats sur votre site à 3 fois pour un même mandat, pour un montant total de 500 € et par mois (30 j) :


Date de la transaction	Détails du paiement	Résultat de la règle	Encours par mandat (nombre de transactions)	Encours par mandat (montant cumulé)	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 Montant : 100 € Mandat : RUM1	OK	1	100 €	TR1 01/10/2018 RUM1 100 €
07/10/2018	Transaction TR2 Montant : 400 € Mandat : RUM2	OK	1	400 €	TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 €
10/10/2018	Transaction TR3 Montant : 400 € Mandat : RUM2	KO	2	800 € (> 500)	TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 € OK TR3 10/10/2018 RUM2 400 €
12/10/2018	Transaction TR4 Montant : 200 € Mandat : RUM1	OK	2	300 €	TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 € OK TR3 10/10/2018 RUM2 400 € KO TR4 12/10/2018 RUM1 200 €
15/10/2018	Transaction TR5 Montant : 100 € Mandat : RUM1	KO	3 (> 2)	400 €	TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 € OK TR3 10/10/2018 RUM2 400 € KO TR4 12/10/2018 RUM1 200 € OK TR5 15/10/2018 RUM1 100 €
02/11/2018 (> 30)	Transaction TR6 Montant : 300 € Mandat : RUM1	OK	1	300 €	TR6 02/11/2018 RUM1 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du MEX


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Montant cumulé maximal	0.01 sur la période en devise du commerçant	9999999
Nombre maximal de transactions	1 transaction sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD)	0	EM;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec ce mandat sur la période dépasse(nt) la/les limite(s) acceptée(s)	0 à -4 selon paramétrage	EM;N;TRANS=A:B; CUMUL=C:D*	TRANS=A:B; CUMUL=C:D*
Le nombre des transactions effectuées et la somme des montants cumulés avec ce mandat sur la période sont inférieurs aux limites acceptées	0	EM;N;TRANS=A:B; CUMUL=C:D*	TRANS=A:B; CUMUL=C:D*

*A : le nombre de transactions effectuées avec ce mandat sur la période.

B : le nombre maximum de transactions acceptées avec un mandat sur la période.

C : la somme des montants cumulés sur la période avec ce mandat.

D : la somme maximum des montants cumulés acceptés avec un mandat sur la période.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=VelocityMandate

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityMandate</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["VelocityMandate"]
}

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, de l’annulation et du remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Encours par IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant cumulé des transactions) de l’IBAN sur une période.

La règle contrôle l’activité d’un IBAN sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période.

Exemple

Le tableau suivant décrit l'évolution de l'historique du mandat dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour un même IBAN, pour un montant total de 500 € et par mois (30 j) :


Date de la transaction	Détails du paiement	Résultat de la règle	Encours par IBAN (nombre de transactions)	Encours par IBAN (montant cumulé)	État de l'historique (30 derniers jours)
01/10/2018	Transaction TR1 Montant : 100 € IBAN : IBAN1	OK	1	100 €	TR1 01/10/2018 IBAN1 100 €
07/10/2018	Transaction TR2 Montant : 400 € IBAN : IBAN2	OK	1	400 €	TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 €
10/10/2018	Transaction TR3 Montant : 400 € IBAN : IBAN2	KO	2	800 € (> 500)	TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 € OK TR3 10/10/2018 IBAN2 400 €
12/10/2018	Transaction TR4 Montant : 200 € IBAN : IBAN1	OK	2	300 €	TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 € OK TR3 10/10/2018 IBAN2 400 € KO TR4 12/10/2018 IBAN1 200 €
15/10/2018	Transaction TR5 Montant : 100 € IBAN : IBAN1	KO	3 (> 2)	400 €	TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 € OK TR3 10/10/2018 IBAN2 400 € KO TR4 12/10/2018 IBAN1 200 € OK TR5 15/10/2018 IBAN1 100 €
02/11/2018 (> 30)	Transaction TR6 Montant : 300 € IBAN : IBAN1	OK	1	300 €	TR6 02/11/2018 IBAN1 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du MEX .


Paramètre	Valeur minimale	Valeur maximale
Période	En heures : 1 heure En jours : 1 jour En semaines : 1 semaine	En heures : 720 heures En jours : 30 jours En semaines : 4 semaines
Montant cumulé maximal	0.01 sur la période en devise du commerçant	9999999
Nombre maximal de transactions	1 transaction sur la période	9999

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD)	0	EI;N;NOT_APPLICABLE	NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cet IBAN sur la période dépasse(nt) la/les limite(s) acceptée(s)	0 à -4 selon paramétrage	EI;N;TRANS=A:B; CUMUL=C:D*	TRANS=A:B; CUMUL=C:D*
Le nombre des transactions effectuées et la somme des montants cumulés avec cet IBAN sur la période sont inférieurs aux limites acceptées	0	EI;N;TRANS=A:B; CUMUL=C:D*	TRANS=A:B; CUMUL=C:D*

*A : le nombre de transactions effectuées avec cet IBAN sur la période.

B : le nombre maximum de transactions acceptées avec un IBAN sur la période.

C : la somme des montants cumulés sur la période avec cet IBAN.

D : la somme maximum des montants cumulés acceptés avec un IBAN sur la période.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=VelocityIban

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityIban</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["VelocityIban"]
}

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, de l’annulation et du remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Règles diverses

Réputations d'adresse IP

Description de la règle

Cette règle vous permet de décider de refuser ou non un achat provenant d’une adresse IP dont la réputation est dangereuse.

La règle va interroger la base de réputations d’adresses IP afin de connaître la réputation de l’adresse IP de l’acheteur et vérifier l’appartenance de cette réputation de l’adresse IP à la liste des réputations d’adresses IP indésirables que vous avez définie. Cette adresse IP provient :

de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

En l’absence d’une liste de réputations d’IP indésirables, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste des réputations d'adresse IP indésirables via l’onglet fraude du MEX
et transmettre l’adresse IP de l'acheteur dans la requête (champ customerI pAddress), si vous êtes sur Sips Office .

Pour connaître les réputations d’adresses IP paramétrables, veuillez-vous référer à l’Annexe 3 : réputations d'adresse IP.

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
L’information n’est pas connue	0	IR;N;U;IP_REP=XXX*	IP_REP=XXX*
La réputation de l'adresse IP appartient à la liste des réputations d'adresse IP indésirables	0 à -4 selon paramétrage	IR;N;Y;IP_REP=XXX*
La réputation de l'adresse IP n'appartient pas à la liste des réputations d'adresse IP indésirables	0	IR;N;N;IP_REP=XXX*

* XXX : réputation d'adresse IP (voir Annexe 3 : réputations d’adresse IP)

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=IpReputations

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>IpReputations</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["IpReputations"]
}

Carte en opposition

Description de la règle

Cette règle vous permet de décider de refuser ou non un achat provenant d’une carte en opposition.

La règle est exécutée sur toutes les transactions de paiement avec carte CB, Visa et MasterCard.

La règle vérifie si la carte est présente dans la base des cartes en opposition.

Le fichier des cartes en opposition est alimenté en se basant sur la liste des cartes de l'opposition du réseau CB. La mise à jour du fichier est effectuée plusieurs fois par jour.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du MEX .

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	OP;N;NOT_APPLICABLE	NOT_APPLICABLE
L’accès au serveur oppotota a échoué	0	OP;N;U	--
La carte est en opposition	0 à -4 selon paramétrage	OP;N;Y
La carte n'est pas en opposition	0	OP;N;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=HotList

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>HotList</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["HotList"]
}

Carte virtuelle

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation payée par un porteur de carte virtuelle émise par une banque Française.

La règle est exécutée sur toutes les transactions de paiement carte.

La règle vérifie dans la base de données de plages porteuses si la carte est une carte virtuelle.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du MEX .

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	EC;N;NOT_APPLICABLE	NOT_APPLICABLE
L'information n'est pas connue	0	EC;N;U	--
La carte est une carte virtuelle dynamique	0 à -4 selon paramétrage	EC;N;Y
La carte n'est pas une carte virtuelle dynamique	0	EC;N;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=ECard

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>ECard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["ECard"]
}

Carte à autorisation systématique

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation payée par un porteur de carte à autorisation systématique.

La règle est exécutée sur toutes les transactions de paiement carte.

La règle vérifie dans la base de données de plages porteuses si la carte est une carte à autorisation systématique.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du MEX .

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	SA;N;NOT_APPLICABLE	NOT_APPLICABLE
L'information n'est pas connue	0	SA;N;U	--
La carte est une carte à autorisation systématique	0 à -4 selon paramétrage	SA;N;Y
La carte n'est pas une carte à autorisation systématique	0	SA;N;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=SystematicAuthorizationCard

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>SystematicAuthorizationCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["SystematicAuthorizationCard"]
}

Carte commerciale (et pays de la carte)

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en se basant sur le fait que la carte soit :

une carte commerciale ;
une carte commerciale appartenant à une liste de pays émetteurs autorisés ou interdits.

La règle est exécutée sur toutes les transactions de paiement avec une carte.

La règle va d’abord interroger une base de données des informations de cartes afin de vérifier l’appartenance de la carte à une plage de BIN correspond aux cartes commerciales afin de déterminer s’il s’agit d’une carte commerciale. Selon le contrôle demandé, le serveur vérifie si le pays d'émission de cette carte commerciale appartient à votre liste des pays autorisés/interdits.

En l’absence de la liste des pays d’émission de la carte commerciale autorisés ou interdits, le serveur vérifie simplement si la carte est une carte commerciale.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste des pays d’émission de la carte commerciale autorisés ou interdits (si vous souhaitez intercepter les cartes commerciales de certains pays). Pour cela, vous devez :
- paramétrer la liste via l’onglet fraude du MEX ,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	CC;N;NOT_APPLICABLE	NOT_APPLICABLE
L'information n'est pas connue	0	CC;N;U; CARD_COUNTRY=XXX	CARD_COUNTRY=XXX*
La carte est une carte commerciale, et la liste des pays de carte commerciale autorisés/interdits n’est pas définie	0 à -4 selon paramétrage	CC;N;Y; CARD_COUNTRY=XXX*	CARD_COUNTRY=XXX*
Le pays de la carte est dans la liste des pays de carte commerciale interdits ou n'est pas dans la liste des pays de carte commerciale autorisés	0 à -4 selon paramétrage	CC;N;Y; CARD_COUNTRY=XXX*
Le pays de la carte n'est pas dans la liste des pays de carte commerciale interdits ou est dans la liste des pays carte commerciale autorisés	0	CC;N;N; CARD_COUNTRY=XXX*
La carte n’est pas une carte commerciale	0	CC;N;N; CARD_COUNTRY=XXX*

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de pays de la carte commerciale. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

Les 2 paramètres applicables à cette règle sont :

AllowedCommercialCardCountryList pour la liste des pays de carte commerciale autorisés ;
DeniedCommercialCardCountryList pour la liste des pays de carte commerciale interdits.

Exemple en version POST :

      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedCommercialCardCountryList,riskManagementDynamicValue=(FRA,BEL)}

Exemple en version SOAP :

      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCommercialCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedCommercialCardCountryList”,
                    “riskManagementDynamicValue”:“(FRA,BEL)”
          }
     ]
}

Pour les 2 méthodes, la liste envoyée doit contenir :

soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) séparés par des virgules ;
soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

➤ Exemple en version POST :

      fraudData.bypassCtrlList=CorporateCard

➤ Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>CorporateCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["CorporateCard"]
}

Plage de montants

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle du montant.

La règle va vérifier si le montant de la transaction se trouve dans la plage de montant que vous souhaitez.

En l’absence de paramétrage des limites minimum et maximum du montant, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX ,
et paramétrer le montant minimum et/ou le montant maximum via l’onglet fraude du MEX .


Paramètre	Valeur minimale	Valeur maximale
Montant minimum	0.01 en devise du commerçant	9999999
Montant maximum	0.01 en devise du commerçant	9999999

Attention: en mode de configuration avancée, il est possible de paramétrer deux plages de montants. L’une ayant une influence positive et l’autre une négative , contrairement au mode de configuration simple, qui ne comporte qu’une seule plage négative de montants.

Restitution du résultat

Mode par défaut :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Le montant de la transaction est hors de la plage des montants souhaités	0 à -4 selon paramétrage	CA;N;MIN=A:B;MAX=A:C*	MIN=A:B;MAX=A:C*
Le montant de la transaction est dans la plage des montants souhaités	0	CA;N;MIN=A:B;MAX=A:C*	MIN=A:B;MAX=A:C*

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Le montant de la transaction est dans la plage des montants désavantagés	0 à -4 selon paramétrage	CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX= A:C; POSITIVE_MIN= A:D; POSITIVE_MAX=A:E*	NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D; POSITIVE_MAX=A:E
Le montant de la transaction est hors des plages de montants avantagés et désavantagés	0	CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D; POSITIVE_MAX=A:E*
Le montant de la transaction est dans la plage des montants avantagés	0 à +4 selon paramétrage	CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D; POSITIVE_MAX=A:E*

__________

* A : montant de la transaction.

B : montant minimum accepté.

C : montant maximum accepté.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=CapCollarAmount

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>CapCollarAmount</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["CapCollarAmount"]
}

Carte réseau CB

Description de la règle

Cette règle vous permet de décider de refuser ou non un achat provenant d’une carte du réseau CB.

La règle est exécutée sur toutes les transactions de paiement avec carte.

Elle vérifie dans la base des plages porteuses si la carte fait partie du réseau Carte Bancaire.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du MEX .

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	NC;N;NOT_APPLICABLE	NOT_APPLICABLE
Le BIN de la carte n’est pas connu	0	NC;N;U	--
La carte ne fait pas partie du réseau carte bancaire	0 à -4 selon paramétrage	NC;N;Y
La carte fait partie du réseau carte bancaire	0	NC;N;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=CBScheme

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>CBScheme</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["CBScheme"]
}

Adresse e-mail gratuite

Description de la règle

Cette règle vous permet de mesurer le risque de la fraude d’un achat provenant d’un client dont l’adresse e-mail est gratuite.

La règle vérifie si l’adresse e-mail du client fait partie d’un domaine d’adresses e-mail gratuites.

Les adresses e-mail vérifiées sont :

l’adresse e-mail du client ;
l’adresse e-mail du porteur du moyen de paiement (il est possible que le client utilise le moyen de paiement d’un proche) ;
l’adresse e-mail du contact de la facturation ;
l’adresse e-mail du contact de la livraison.

Si une des adresses e-mail disponibles est présente dans la liste, un résultat négatif sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et transmettre au moins une adresse e-mail de l’acheteur dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Au moins une adresse e-mail est présente dans la liste des adresses e-mail gratuites	0 à -4 selon paramétrage	FE;N;Y	--
Aucune adresse e-mail n’est présente dans la liste des adresses e-mail gratuites	0	FE;N;U
Aucune adresse e-mail n’a été transmise	0	FE;N;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=FreeEmail

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>FreeEmail</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["FreeEmail"]
}

Authentification 3-D Secure

Description de la règle

Cette règle vous permet de mesurer le risque sur une transaction avec authentification 3-D Secure en fonction du statut de 3-D Secure. Ici, l’authentification 3-D Secure inclut les programmes d’authentification 3-D Secure de Visa, SecureCode de MasterCard, SafeKey d’American Express, authentification de Bancontact/Mister Cash, etc.

La règle est exécutée sur toutes les transactions de paiement carte avec une authentification 3-D Secure.

Elle vérifie si le statut d’authentification du porteur appartient à une liste de statuts refusés.

En l’absence de liste de statuts refusés, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer la liste des statuts d’authentification 3-D Secure interdits via l’onglet fraude du MEX .

Veuillez vous référer à l'Annexe 5 : statuts d'authentification 3-D Secure.

Attention: en mode de configuration avancée, il est possible de paramétrer deux listes. L’une ayant une influence positive et une négative . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative .

Restitution du résultat

Mode par défaut (configuration simple) :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement ne propose pas d’authentification 3-D Secure ou vous ne participez pas au programme d’authentification 3-D Secure)	0	A3;N;NOT_APPLICABLE	NOT_APPLICABLE
Le statut 3-D Secure est interdit	0 à -4 selon paramétrage	A3;N;Y	--
Le statut 3-D Secure n'est pas interdit	0	A3;N;N	--

Mode de configuration avancée :


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement ne propose pas d’authentification 3-D Secure ou vous ne participez pas au programme d’authentification 3-D Secure)	0	A3;N;NOT_APPLICABLE	NOT_APPLICABLE
Le statut 3-D Secure est dans la liste des statuts désavantagés	0 à -4 selon paramétrage	A3;N;Y	--
Le statut 3-D Secure n'est pas dans les listes de statuts avantagés et désavantagés	0	A3;N;N
Le statut 3-D Secure est dans la liste des statuts avantagés	0 à +4 selon paramétrage	A3;N;Y

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=3DSStatus

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>3DSStatus</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["3DSStatus"]
}

Syntaxe d'adresse e-mail

Description de la règle

Cette règle vous permet de mesurer le risque en fonction de la validité des syntaxes des adresses e-mail de la transaction.

La règle va vérifier si la syntaxe des adresses e-mail de la transaction est valide.

Les adresses e-mail vérifiées sont :

l’adresse e-mail du client ;
l’adresse e-mail du porteur du moyen de paiement (il est possible que le client utilise le moyen de paiement d’un proche) ;
l’adresse e-mail du contact de la facturation ;
l’adresse e-mail du contact de la livraison.

Si une des adresses e-mail présentées a une syntaxe incorrecte, la règle retourne un résultat négatif.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et transmettre au moins une adresse e-mail de l’acheteur dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
La syntaxe de l’adresse e-mail est erronée	0 à -4 selon paramétrage	ES;N	--
La syntaxe de l’adresse e-mail est correcte	0
Aucune adresse e-mail n’a été transmise	0

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=EmailSyntax

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>EmailSyntax</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["EmailSyntax"]
}

Vérification d'adresse (InfoScore)

Description de la règle

Le contrôle d'adresse, délégué à InfoScore, sert à vérifier l'adresse de livraison soumise lors d’une transaction ELV. Il est effectué à l'aide de la base de données AZ Direct GmbH, ce qui en limite le fonctionnement aux adresses allemandes.

Le contrôle ne s’effectue que pour les paiements ELV et les adresses de livraisons en Allemagne ( countryCode valant « DEU »).

Le résultat de la vérification d'adresse est retourné par InfoScore sous la forme d'un indicateur. Pour connaître les indicateurs, veuillez consulter l'Annexe 6 : InfoScore adresse vérification indicateur.

À l'aide des réglages, vous pourrez accepter ou refuser certaines valeurs.

Par exemple, vous pourrez choisir de ne faire confiance qu'aux adresses avec des contrôles PPB et PHB positifs.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

avoir souscrit à l'option InfoScore ;
activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste des indicateurs autorisés/interdits via l’onglet fraude du MEX
et transmettre l'adresse postale de livraison de l'acheteur dans la requête.

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (InfoScore ID absent ou l’adresse de livraison n’est pas en Allemagne)	0	AV;N;NOT_APPLICABLE	NOT_APPLICABLE
Information non connue	0	AV;N;U;IS_INDIC=XXX*	IS_INDIC=XXX*
Le type d’adresse retourné par InfoScore fait partie de la liste des types interdits par la règle ou ne fait pas partie de la liste des types autorisés	0 à -4 selon paramétrage	AV;N;Y;IS_INDIC=XXX*	IS_INDIC=XXX*
Le type d’adresse retourné par InfoScore fait partie de la liste des types autorisés par la règle ou ne fait pas partie de la liste des types interdits	0	AV;N;N;IS_INDIC=XXX*	IS_INDIC=XXX*

* XXX : indicateur retourné par InfoScore.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=AddressVerification

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>AddressVerification</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["AddressVerification"]
}

Vérification de compte (InfoScore)

Description de la règle

La vérification de compte, déléguée à InfoScore, sert à vérifier le compte de débit utilisé lors d’une transaction ELV. Il est effectué à l'aide de la base de données Rücklastschriften-Präventions-Pool (RPP) d’InfoScore Consumer Data GmbH (ICD).

Le contrôle ne s’effectue que pour les paiements ELV.

Le pool de prévention de rejet des débits directs RPP est un ensemble de données interprofessionnelles qui contient des informations bancaires relatives à différents secteurs d'activité et industries. L'objectif de RPP est d'empêcher les problèmes de connexion lors de l'utilisation de la méthode de paiement « débit direct ».

De plus, la base de données RPP contient des informations sur les comptes dits « non consommateurs » dont les références peuvent être publiques (ex. : comptes d’associations, compte gouvernemental, sociétés…).

Lorsqu'un compte est identifié, les informations sont retournées dans la réponse d’InfoScore vers WL Sips .

Le contrôle retournera une valeur négative si :

le compte est un compte « non consommateur » ;
le compte fait partie du programme PAP (Proprietary Account Protection) : liste de comptes dont les propriétaires ont interdit l’utilisation sur Internet ;
le compte fait partie de la liste KUNO (Kriminalitätsbekämpfung im unbaren Zahlungsverkehr unter Nutzung nichtpolizeilicher Organisationen) : liste de comptes bloqués en Allemagne pour diverses raisons.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

avoir souscrit à l'option InfoScore ;
activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer la liste des indicateurs autorisés/interdits via l’onglet fraude du MEX .

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (InfoScore ID absent)	0	BV;N;NOT_APPLICABLE	NOT_APPLICABLE
Information non connue	0	BV;N;U;VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*	VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*
Le compte n’est pas un compte consommateur, ou se trouve dans les listes PAP ou KUNO	0 à -4 selon paramétrage	BV;N;Y;VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*	VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*
Le compte est un compte consommateur	0	BV;N;N;VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*	VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*

* AAA : resultCode InfoScore (00 = le compte bancaire est valide).

BBB : valeur de l’indicateur InfoScore NCA.

CCC : valeur du RppContentCode pour InfoScore NCA KO.

DDD : valeur de l’indicateur InfoScore PAP.

EEE : valeur du RppContentCode pour InfoScore PAP KO.

FFF : valeur de l'indicateur InfoScore RPP.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=AccountVerification

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>AccountVerification</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["AccountVerification"]
}

Date d'expiration de la carte

Description de la règle

Cette règle vous permet de détecter les paiements dont la carte arrive à expiration dans les prochains mois. Elle est notamment utile dans le cadre d'un paiement en plusieurs fois afin de s’assurer que la carte sera toujours valide lors des prochaines échéances du paiement.

La règle est exécutée sur toutes les transactions carte.

Elle vérifie si le nombre de mois avant expiration de la carte est supérieur au nombre de mois que vous avez indiqués.

En l’absence de paramétrage du nombre de mois minimum avant expiration, la règle considère que ce nombre est de zéro.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer le nombre minimum de mois avant expiration de la carte via l’onglet fraude du MEX .

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	0	PE;N;NOT_APPLICABLE	NOT_APPLICABLE
La durée de validité du moyen de paiement est inférieure à la durée souhaitée	0 à -4 selon paramétrage	PE;N;Y;EXPIRY=AAA:BBB*	EXPIRY=AAA:BBB*
la durée de validité du moyen de paiement est supérieure à la durée souhaitée	0	PE;N;N;EXPIRY=AAA:BBB*	EXPIRY=AAA:BBB*

* AAA : date d'expiration de la carte au format MMYY.

BBB : deadline pour le contrôle au format MMYY.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=ExpiryDate

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>ExpiryDate</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["ExpiryDate"]
}

Règles de listes

Généralités

Le moteur de gestion de la lutte contre la fraude permet de gérer plusieurs listes de données. Trois types différents de règles peuvent être appliqués à ces listes :

vérification dans une liste noire ;
vérification dans une liste grise ;
vérification dans une liste blanche.

La différence entre ces règles dépend du résultat de la règle ainsi que de la manière dont vous gérez la liste :

une liste noire est une liste du type négatif utilisée pour des actions sévères, elle entraîne généralement un rejet des transactions ;
une liste grise est une liste du type négatif utilisée pour des cas douteux nécessitant une attention particulière ;
une liste blanche est une liste du type positif utilisée pour porter une attention spéciale et positive à certains clients.

Voici les résultats possibles en fonction du type de règle :


Valeur de donnée présente	Résultat liste noire (type NÉGATIF)	Résultat liste grise (type NÉGATIF)	Résultat liste blanche (type POSITIF)
NON	Neutre	Neutre	Neutre
OUI	Négatif	Négatif	Positif

D'une manière générale, les achats sur Internet présentent pour vous un risque de fraude plus élevé que lorsque la carte est présentée. Les commandes par téléphone/courrier/Internet sont des vecteurs majeurs de fraude si vous vendez et expédiez des produits. Si la carte n'est pas physiquement présente, vous devez compter sur le porteur de carte (ou quelqu'un qui affirme l'être) pour donner les informations de manière indirecte, que ce soit par courrier, téléphone ou Internet.

Il se peut que vous souhaitiez suivre les clients (ou des propriétés afférentes) avec lesquels vous avez eu une bonne ou une mauvaise expérience lors d'un précédent achat. Par exemple, si vous avez livré un produit à une adresse mais n'avez pas été réglé car la carte utilisée pour le paiement était frauduleuse, vous pouvez mettre ce numéro de carte en liste noire afin que la demande de paiement soit rejetée si cette carte est à nouveau utilisée sur votre boutique.

Autre exemple : vous pouvez ajouter un nom de client à une liste si vous pensez que ce client a des problèmes de solvabilité, par exemple si une tentative d'autorisation financière a été rejetée avec un code indiquant un « solde insuffisant » du compte. Dans ce cas, peut-être ne voulez-vous pas rejeter la transaction immédiatement mais être alerté si ce nom est utilisé à nouveau dans une transaction.

Vous pouvez aussi gérer ce nom dans ce que l'on appelle une liste grise. Vous pouvez ainsi recevoir une alerte si l'une des propriétés est utilisée de nouveau lors d'une transaction différente, et traiter la nouvelle transaction avec une attention particulière, effectuer une vérification manuelle, etc. Les listes grises sont également un moyen de gérer les propriétés (données transactionnelles) que l’on suppose liées à la fraude.

D'autre part, il se peut que vous ayez eu de mauvaises expériences avec certains clients, mais aussi des expériences très positives avec d'autres. Vous pouvez ainsi, par exemple, traiter certains clients comme des « VIP ». Les clients B2B peuvent également s'avérer suffisamment fiables. Les listes dites blanches représentent le moyen approprié de gérer ces clients.

Liste partagée

Par défaut, une boutique a sa propre liste pour chaque règle de type liste. Ces listes sont appelées « listes privées ».

Il est également possible de partager une liste pour plusieurs boutiques.

Une liste est partageable au niveau du groupe commercial.

5 listes partagées peuvent être créées par type de liste.

Toutes les boutiques attachées à cette liste partagée peuvent modifier les éléments de la liste.

L'élément ajouté par un utilisateur d’une boutique ne peut être modifié ou supprimé que par un utilisateur de cette boutique ou un administrateur, mais pas par les utilisateurs d’une autre boutique. Les éléments de la liste sont utilisés pour toutes les boutiques la partageant.

Pour mettre en place une liste partagée, vous devez contacter votre gestionnaire de compte pour la configuration. Cette dernière s’effectue en deux étapes :

tout d'abord créer une liste commune en choisissant son type (liste d’adresses e-mail, liste de numéros de carte, etc.) et sa couleur (noir, gris ou blanc) ;
puis associer la liste partagée aux boutiques.

Lors de l'exécution des contrôles antifraudes, si la règle appropriée est activée, la liste partagée sera appliquée à la place de la liste privée par défaut.

Adresses e-mail

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat lié à une adresse e-mail qui appartient à la liste noire ou grise des adresses e-mail.
et/ou de décider d'honorer ou non un achat lié à une adresse e-mail qui appartient à la liste blanche des adresses e-mail sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des adresses e-mail VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins une adresse e-mail transmise par vos soins.

La règle va vérifier l’appartenance de toutes les adresses e-mail disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les adresses e-mail vérifiées sont :

l'adresse e-mail du client ;
l’adresse e-mail du porteur du moyen de paiement (il est possible que le client/acheteur utilise le moyen de paiement d’un proche) ;
l’adresse e-mail du contact de la facturation ;
l’adresse e-mail du contact de la livraison.

Si une des adresses e-mail disponibles est présente dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste noire, grise et/ou blanche des adresses e-mail ;
et transmettre une ou plusieurs adresses e-mail précédemment citées dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email ).

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Au moins une adresse e-mail fait partie de la liste	Noire	0 à -4 selon paramétrage	BM;N;Y	--
	Grise	0 à -4 selon paramétrage	GM;N;Y
	Blanche	0 à +4 selon paramétrage	WM;P;Y
Aucune adresse e-mail ne fait partie de la liste	Noire	0	BM;N;N
	Grise		GM;N;N
	Blanche		WM;P;N
Aucune adresse e-mail n’a été transmise	Noire		BM;N;U
	Grise		GM;N;N
	Blanche		WM;P;U

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackEmail

Liste grise :

      fraudData.bypassCtrlList=GreyEmail

Liste blanche :

      fraudData.bypassCtrlList=WhiteEmail

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackEmail</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyEmail</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteEmail</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackEmail"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyEmail"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteEmail"]
}

Adresses IP

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat lié à une adresse IP qui appartient à la liste noire ou grise des adresses IP.
et/ou de décider d'honorer ou non un achat lié à une adresse IP qui appartient à la liste blanche des adresses IP, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des adresses IP VIP.

La règle va vérifier l’appartenance de l'adresse IP à la liste noire, grise et/ou blanche que vous avez définie(s). Cette adresse IP provient :

de la détection automatique via le navigateur de l'acheteur en Sips Paypage ;
ou du transfert que vous effectuez dans la requête en Sips Office .

Si l'adresse IP est présente dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste noire, grise et/ou blanche des adresses IP ;
et transmettre l'adresse IP de l'acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sips Office .

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
L’adresse IP n’est pas renseignée (en Sips Office )	Noire	0	BY;N;U	--
	Grise		GY;N;U
	Blanche		WY;P;U
L’adresse IP appartient à la liste	Noire	0 à -4 selon paramétrage	BY;N;Y
	Grise	0 à -4 selon paramétrage	GY;N;Y
	Blanche	0 à +4 selon paramétrage	WY;P;Y
L’adresse IP n’appartient pas à la liste	Noire	0	BY;N;N
	Grise		GY;N;N
	Blanche		WY;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackIp

Liste grise :

      fraudData.bypassCtrlList=GreyIp

Liste blanche :

      fraudData.bypassCtrlList=WhiteIp

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackIp</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyIp</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteIp</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackIp"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyIp"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteIp"]
}

Codes postaux par pays

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat lié à un code postal qui appartient à la liste noire ou grise des codes postaux par pays.
et/ou de décider d'honorer ou non un achat lié à un code postal qui appartient à la liste blanche des codes postaux, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des codes postaux VIP.

Si la règle est présente dans votre profil, elle sera effectuée sur toutes les transactions de paiement avec au moins un code postal transmis par vos soins.

La règle va vérifier l’appartenance de tous les codes postaux disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les codes postaux vérifiés sont :

le code postal du contact de la facturation ;
le code postal du contact de la livraison.

Si un des codes postaux disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste noire, grise et/ou blanche des codes postaux ;
et transmettre un ou plusieurs codes postaux ci-dessus dans la requête (champs billingAddress.zipCode, deliveryAddress.zipCode ).

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Aucun code postal n'a été transmis	Noire	0	BZ;N;U	--
	Grise		GZ;N;U
	Blanche		WZ;P;U
Au moins un code postal fait partie de la liste	Noire	0 à -4 selon paramétrage	BZ;N;Y
	Grise	0 à -4 selon paramétrage	GZ;N;Y
	Blanche	0 à +4 selon paramétrage	WZ;P;Y
Aucun code postal ne fait partie de la liste	Noire	0	BZ;N;N
	Grise		GZ;N;N
	Blanche		WZ;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackPostalCode

Liste grise :

      fraudData.bypassCtrlList=GreyPostalCode

Liste blanche :

      fraudData.bypassCtrlList=WhitePostalCode

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackPostalCode</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyPostalCode</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhitePostalCode</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackPostalCode"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyPostalCode"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhitePostalCode"]
}

Identifiants clients

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat lié à un identifiant client qui appartient à la liste noire ou grise des identifiants clients.
et/ou de décider d'honorer ou non un achat lié à un identifiant client qui appartient à la liste blanche identifiants clients, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des identifiants clients VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec un identifiant client soumis dans la requête/transmis par vos soins.

La règle va vérifier l’appartenance de l'identifiant client à la liste noire, grise et/ou blanche des identifiants clients que vous avez définie(s).

Si l'identifiant client est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste noire, grise et/ou blanche des identifiants clients ;
et transmettre l'identifiant client de l'acheteur dans la requête (champ customerId ).

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
L’identifiant client n’est pas fourni	Noire	0	BI;N;U	--
	Grise		GI;N;U
	Blanche		WI;P;U
Au moins un identifiant client fait partie de la liste	Noire	0 à -4 selon paramétrage	BI;N;Y
	Grise	0 à -4 selon paramétrage	GI;N;Y
	Blanche	0 à +4 selon paramétrage	WI;P;Y
L’identifiant client ne fait pas partie de la liste	Noire	0	BI;N;N
	Grise		GI;N;N
	Blanche		WI;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackCustomerId

Liste grise :

      fraudData.bypassCtrlList=GreyCustomerId

Liste blanche :

      fraudData.bypassCtrlList=WhiteCustomerId

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCustomerId</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCustomerId</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerId</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackCustomerId"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyCustomerId"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteCustomerId"]
}

Noms de clients

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat lié à un nom de client qui appartient à la liste noire ou grise des noms de clients.
et/ou de décider d'honorer ou non un achat lié à un nom de client qui appartient à la liste blanche des noms de clients, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des noms de clients VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins un nom de client transmis par vos soins.

La règle va vérifier l’appartenance de tous les noms disponibles à la liste noire, grise et/ou blanche des noms de clients que vous avez définie(s). Les noms vérifiés sont :

le nom du client ;
le nom du porteur du moyen de paiement (il est possible que le client/acheteur utilise le moyen de paiement d'un proche) ;
le nom du contact de la facturation ;
le nom du contact de la livraison.

Si un des noms disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste noire, grise et/ou blanche des noms de clients ;
et transmettre au moins un nom de client dans la requête (champs billingContact.lastName, customerContact.lastName, deliveryContact.lastName, holderContact.lastName ).

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Aucun nom de client n'a été transmis	Noire	0	BN;N;U	--
	Grise		GN;N;U
	Blanche		WN;P;U
Au moins un nom de client fait partie de la liste	Noire	0 à -4 selon paramétrage	BN;N;Y
	Grise	0 à -4 selon paramétrage	GN;N;Y
	Blanche	0 à +4 selon paramétrage	WN;P;Y
Aucun nom de client ne fait partie de la liste	Noire	0	BN;N;N
	Grise		GN;N;N
	Blanche		WN;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackCustomerName

Liste grise :

      fraudData.bypassCtrlList=GreyCustomerName

Liste blanche :

      fraudData.bypassCtrlList=WhiteCustomerName

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCustomerName</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCustomerName</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerName</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackCustomerName"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyCustomerName"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteCustomerName"]
}

Numéros de carte

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat provenant d'une carte qui appartient à votre liste noire ou grise .
et/ou de décider d'honorer ou non directement un achat provenant d'une carte qui appartient à votre liste blanche , sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste de cartes VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement par carte transmises par vos soins.

La règle va vérifier l’appartenance du numéro de carte soumis pour autorisation (si applicable) à la liste noire, grise et/ou blanche de vos numéros de carte.

Si le numéro de carte en question est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer la liste noire, grise et/ou blanche des numéros de carte ( cardNumber ).

La liste peut être paramétrée :

via l’onglet 'Fraude' et Sips Office Extranet . Les données doivent être ajoutées par le biais d'un identifiant de la transaction. Dans ce dernier cas, la valeur de la donnée stockée pour la transaction liée à l’identifiant de la transaction sera ajoutée à la liste ;
et par le batch d’alimentation de Sips Office Batch .

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	Noire	0	BC;N;U	--
	Grise		GC;N;U
	Blanche		WC;P;U
Le numéro de la carte fait partie de la liste	Noire	0 à -4 selon paramétrage	BC;N;Y
	Grise	0 à -4 selon paramétrage	GC;N;Y
	Blanche	0 à +4 selon paramétrage	WC;P;Y
Le numéro de la carte ne fait pas partie de la liste	Noire	0	BC;N;N
	Grise		GC;N;N
	Blanche		WC;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackCard

Liste grise :

      fraudData.bypassCtrlList=GreyCard

Liste blanche :

      fraudData.bypassCtrlList=WhiteCard

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCard</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCard</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackCard"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyCard"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteCard"]
}

Numéros de téléphone

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat lié à un numéro de téléphone qui appartient à la liste noire ou grise des numéros de téléphone.
et/ou de décider d'honorer ou non un achat lié à un numéro de téléphone qui appartient à la liste blanche des numéros de téléphone, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des numéros de téléphone VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins un numéro de téléphone transmis par vos soins.

La règle va vérifier l’appartenance de tous les numéros de téléphone disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les numéros de téléphone vérifiés sont :

les numéros de téléphone fixe/portable du client ;
les numéros de téléphone fixe/portable du porteur du moyen de paiement (en effet, il est possible que le client/acheteur utilise le moyen de paiement d’un proche) ;
les numéros de téléphone fixe/portable du contact de la facturation ;
les numéros de téléphone fixe/portable du contact de la livraison.

Si un des numéros de téléphone disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX ,
paramétrer la liste noire, grise et/ou blanche des numéros de téléphone ;
et transmettre dans la requête un ou plusieurs des numéros de téléphone énumérés ci-dessus (champs billingContact.phone, customerContact.phone, deliveryContact.phone, holderContact.phone, billingContact.mobile, customerContact.mobile, deliveryContact.mobile, holderContact.mobile ).

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Aucun numéro de téléphone n’a été transmis	Noire	0	BP;N;U	--
	Grise		GP;N;U
	Blanche		WP;P;U
Au moins un numéro de téléphone fait partie de la liste	Noire	0 à -4 selon paramétrage	BP;N;Y
	Grise	0 à -4 selon paramétrage	GP;N;Y
	Blanche	0 à +4 selon paramétrage	WP;P;Y
Aucun numéro de téléphone ne fait partie de la liste	Noire	0	BP;N;N
	Grise		GP;N;N
	Blanche		WP;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackPhoneNumber

Liste grise :

      fraudData.bypassCtrlList=GreyPhoneNumber

Liste blanche :

      fraudData.bypassCtrlList=WhitePhoneNumber

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhitePhoneNumber</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackPhoneNumber"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyPhoneNumber"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhitePhoneNumber"]
}

Plages de BIN

Description de la règle

Cette règle vous permet :

de décider de refuser ou non un achat effectué avec une carte dont le BIN appartient à votre liste noire ou grise de BIN.
et/ou de décider d'honorer ou non directement un achat effectué avec une carte dont le BIN appartient à votre liste blanche de BIN, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste de plages de BIN VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement par carte transmises par vos soins.

La règle va vérifier l’appartenance du numéro de BIN de la carte à votre liste noire, grise et/ou blanche de plages de BIN.

Si le numéro BIN de la carte en question est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer la liste noire, grise et/ou blanche des numéros de BIN ( cardNumber ).

Note: veuillez consulter le glossaire pour plus d'informations sur les BIN.

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte)	Noire	0	BB;N;U	--
	Grise		BR;N;U
	Blanche		WB;P;U
Le numéro de BIN de la carte fait partie de la liste	Noire	0 à -4 selon paramétrage	BB;N;Y
	Grise	0 à -4 selon paramétrage	BR;N;Y
	Blanche	0 à +4 selon paramétrage	WB;P;Y
Le numéro de BIN de la carte ne fait pas partie de de la liste	Noire	0	BB;N;N
	Grise		BR;N;N
	Blanche		WB;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackBinCard

Liste grise :

      fraudData.bypassCtrlList=GreyBinCard

Liste blanche :

      fraudData.bypassCtrlList=WhiteBinCard

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackBinCard</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyBinCard</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteBinCard</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackBinCard"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyBinCard"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteBinCard"]
}

BIC (Bank Identifier Code)

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat lié à un BIC (Bank Identifier Code) qui appartient à la liste noire, grise et/ou blanche de BIC, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste de BIC VIP).

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.

La règle va vérifier l’appartenance du BIC à la liste noire, grise et/ou blanche de BIC que vous avez définie(s).

Si le BIC est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Tip: vous pouvez transmettre le BIC dans la requête. Sinon il sera automatiquement retrouvé à partir de l’IBAN que vous devez obligatoirement transmettre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer la liste noire, grise et/ou blanche de BIC.

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Le BIC fait partie de la liste	Noire	0 à -4 selon paramétrage	BE;N;Y	--
	Grise	0 à -4 selon paramétrage	GM;N;Y
	Blanche	0 à +4 selon paramétrage	WE;P;Y
Le BIC ne fait pas partie de la liste	Noire	0	BE;N;N
	Grise		GM;N;N
	Blanche		WE;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackBic

Liste grise :

      fraudData.bypassCtrlList=GreyBic

Liste blanche :

      fraudData.bypassCtrlList=WhiteBic

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackBic</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyBic</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteBic</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackBic"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyBic"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteBic"]
}

IBAN (International Bank Account Number)

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat lié à un IBAN (International Bank Account Number) qui appartient à la liste noire, grise et/ou blanche d'IBAN, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste d'IBAN VIP).

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.

La règle va vérifier l’appartenance de l'IBAN utilisé par le mandat SDD à la liste noire, grise et/ou blanche d'IBAN que vous avez définie(s).

Si l'IBAN est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer la liste noire, grise et/ou blanche d'IBAN.

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
L'IBAN fait partie de la liste	Noire	0 à -4 selon paramétrage	BA;N;Y	--
	Grise	0 à -4 selon paramétrage	GA;N;Y
	Blanche	0 à +4 selon paramétrage	WA;P;Y
L'IBAN ne fait pas partie de la liste	Noire	0	BA;N;N
	Grise		GA;N;N
	Blanche		WA;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackIban

Liste grise :

      fraudData.bypassCtrlList=GreyIban

Liste blanche :

      fraudData.bypassCtrlList=WhiteIban

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackIban</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyIban</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteIban</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackIban"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyIban"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteIban"]
}

Mandats

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat lié à un mandat SDD qui appartient à la liste noire, grise et/ou blanche de mandats, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste de mandats VIP).

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.

La règle va vérifier l’appartenance du mandat, basé sur son RUM (Référence Unique de Mandat), à la liste noire, grise et/ou blanche de mandats que vous avez définie(s).

Si le mandat est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

activer la règle dans le profil via l’onglet fraude du MEX
et paramétrer la liste noire, grise et/ou blanche de mandats.

Restitution du résultat


Cas d'utilisation		ScoreValue	ScoreInfo	Rule DetailedInfo
Le RUM du mandat fait partie de la liste	Noire	0 à -4 selon paramétrage	TB;N;Y	--
	Grise	0 à -4 selon paramétrage	TG;N;Y
	Blanche	0 à +4 selon paramétrage	TW;P;Y
Le RUM du mandat ne fait pas partie de la liste	Noire	0	TB;N;N
	Grise		TG;N;N
	Blanche		TW;P;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackMandate

Liste grise :

      fraudData.bypassCtrlList=GreyMandate

Liste blanche :

      fraudData.bypassCtrlList=WhiteMandate

Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackMandate</urn:bypassCtrlList>
</urn:fraudData>

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyMandate</urn:bypassCtrlList>
</urn:fraudData>

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteMandate</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackMandate"]
}

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyMandate"]
}

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteMandate"]
}

Règles de panier

Généralités

Le moteur de gestion de la lutte contre la fraude permet de prendre en compte la composition du panier de la transaction pour en mesurer le risque. Pour ce faire, il utilise des listes de produits à risque que vous définissez vous-même.

Un produit à risque est un produit que vous vendez et considèrez comme potentiellement associé à des transactions à risque selon certains critères qui vous appartiennent : catégorie ou type de produit, prix du produit, utilisation régulière d’un produit dans des transactions frauduleuses, etc.

Vous avez la possibilité de définir jusqu’à 3 listes de produits à risque pour votre boutique. Vous pouvez ainsi ajouter tout ou partie des produits que vous vendez dans une ou plusieurs listes selon le niveau de risque du produit.

Par exemple, vous pouvez choisir de créer les 3 listes de produits à risques suivantes :

une liste de produits à faible risque ;
une liste de produits à risque modéré ;
et une liste de produits à haut risque.

Les listes de produits à risque sont exploitées par des règles de détection de risque du contenu du panier du client qui effectue un achat sur votre site. Si ces règles sont activées, elles vont analyser le contenu du panier et le comparer aux listes de produits à risque que vous avez définies afin d'évaluer le risque de la transaction. Vous pouvez ainsi limiter l‘achat de certains produits à une certaine quantité ou un certain ratio du montant global.

IMPORTANT: les produits sont identifiés par le moteur de lutte contre la fraude sur la base de leur code produit, qui doit se trouver à la fois dans les listes de produits à risque et dans les données du panier de la transaction. Il est essentiel que ces codes concordent entre les listes et le panier.

Listes partagées

Par défaut, une boutique possède ses propres listes de produits à risque (jusqu'à 3 listes). Ces listes sont appelées « listes privées ».

Vous pouvez également réaliser des listes communes à plusieurs boutiques afin de n’administrer qu’un seul jeu de produits à risque pour les boutiques concernées. Ce sont des listes dites « partagées ».

Une liste est partageable au niveau du groupe commercial. Vous pouvez créer et associer aux boutiques 5 listes partagées de produits à risque. Toutes les boutiques associées à une liste partagée donnée peuvent modifier les éléments de la liste. Les éléments de la liste sont utilisés pour toutes les boutiques la partageant.

Pour mettre en place une liste partagée, vous devez contacter votre gestionnaire de compte pour la configuration. Cette dernière s’effectue en deux étapes :

tout d'abord créer une liste commune en choisissant son type (liste d’adresses e-mail, liste de numéros de carte, etc.) et sa couleur (noir, gris ou blanc) ;
puis associer la liste partagée aux boutiques.

L’association d’une boutique à une liste partagée se fait en utilisant une liste partagée existante au niveau du groupe commercial, dans l’écran de configuration des listes de produits de la boutique.

Lors de l'exécution des contrôles antifraudes, si la règle appropriée est activée et qu’elle est paramétrée pour utiliser la liste partagée, alors cette dernière sera utilisée.

Liste de produits à risque

Description de la règle

Cette règle vous permet de vérifier la présence ou non de produits à risque dans le panier du client.

La règle va interroger les listes de produits à risque définies par vos soins et paramétrées dans la règle afin de vérifier si l’un des produits du panier du client contient un produit que vous considérez comme potentiellement risqué.

Si la requête que vous envoyez ne contient pas de liste de produits à risque pour la boutique ou de contenu du panier, la règle retourne un résultat neutre.

Attention: cette règle ne peut pas être décisive afin de ne pas bloquer toutes les transactions d’une boutique. En effet les produits contenus dans les listes de produits à risque sont forcément des produits que vous vendez, tout comme les produits présents dans le panier.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du MEX ,
paramétrer au moins une liste de produits à risque via l’onglet fraude du MEX
et transmettre le contenu du panier du client dans la requête, notamment le code produit de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	Rule DetailedInfo
Au moins un produit du panier appartient à une liste de produits à risque	0 à -3 selon paramétrage	RP;N;Y	--
L'information n'est pas connue	0	RP;N;U;
Aucun produit du panier n’appartient à une liste de produits à risque	0	RP;N;N

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=RiskyProductList

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductList</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["RiskyProductList"]
}

Quantité de produits à risque

Description de la règle

Cette règle vous permet de limiter dans le panier la quantité de produits appartenant à l’une de vos listes de produits à risque.

La règle va analyser le contenu du panier et vérifier que :

la quantité d’un même produit du panier du client appartenant à l’une de vos listes de produits à risque n’excède pas le seuil paramétré dans la règle ;
la quantité totale de tous les produits du panier du client appartenant à une même liste de produits à risque n’excède pas le seuil paramétré dans la règle.

Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du MEX ,
paramétrer au moins une liste de produits à risque via l’onglet fraude du MEX
et transmettre le contenu du panier du client dans la requête, notamment le code produit et la quantité de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Au moins un produit du panier appartenant à une liste de produits à risque a une quantité supérieure au seuil paramétré dans la règle et/ou la quantité totale des produits appartenant à une liste de produits à risque est supérieure au seuil paramétré dans la règle.	0 à -4 selon paramétrage	PQ;N;Y; MAX_QUANTITY_PER_ RISKY_PRODUCT=L:A:B; MAX_QUANTITY_PER_ LIST=L:C:D*	MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY_PER_ LIST=L:C:D*
L'information n'est pas connue	0	PQ;N;U	--
Aucun produit du panier n’appartient à une liste de produits à risque ou aucun produit du panier appartenant à une liste de produits à risque n’a une quantité supérieure au seuil paramétré dans la règle et la quantité totale des produits appartenant à une liste de produits à risque est inférieure ou égale au seuil paramétré dans la règle.	0	PQ;N;N; MAX_QUANTITY_PER_ RISKY_PRODUCT=L:A:B; MAX_QUANTITY_PER_ LIST=L:C:D*	MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*

*L : le nom de la liste de produits à risque concernée.

A : la quantité la plus grande d’un produit du panier appartenant à cette liste de produits à risque.

B : la quantité maximum acceptée pour un produit appartenant à cette liste de produits à risque.

C : la somme des quantités des produits du panier appartenant à cette liste de produits à risque.

D : la quantité maximum acceptée pour tous les produits du panier appartenant à cette liste de produits à risque.

Note: jusqu’à 3 listes de produits à risque peuvent être paramétrées pour cette règle. Les valeurs MAX_QUANTITY_PER_RISKY_PRODUCT et MAX_QUANTITY_PER_LIST sont restituées dans le champ complementaryInfo pour chacune de ces listes. Pour cette règle il est donc possible d’avoir ces valeurs jusqu’à 3 fois dans le champ complementaryInfo .

MAX_QUANTITY_PER_RISKY_PRODUCT=L1:A1:B1;MAX_QUANTITY_PER_LIST=L1:C1:D1; MAX_QUANTITY_PER_RISKY_PRODUCT=L2:A2:B2;MAX_QUANTITY_PER_LIST=L2:C2:D2; MAX_QUANTITY_PER_RISKY_PRODUCT=L3:A3:B3;MAX_QUANTITY_PER_LIST=L3:C3:D3

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=RiskyProductQuantity

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductQuantity</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["RiskyProductQuantity"]
}

Ratio de produits à risque

Description de la règle

Cette règle vous permet de détecter un comportement anormal relatif au ratio entre le montant d’un ou de tous les produits appartenant à une liste de produits à risque et le montant total du panier du client.

La règle va analyser le contenu du panier et vérifier que :

le ratio entre le montant total (quantité x prix unitaire) d’un même produit du panier appartenant à une liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle ;
le ratio entre le montant total (quantité x prix unitaire) de tous les produits du panier appartenant à une même liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle.

Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du MEX ,
paramétrer au moins une liste de produits à risque via l’onglet fraude du MEX
et transmettre le contenu du panier du client dans la requête, notamment le code produit, le montant unitaire et la quantité de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Le plus grand ratio entre le montant total pour au moins un produit appartenant à une liste de produits à risque et le montant total du panier est supérieur au seuil paramétré dans la règle et/ou le ratio entre le montant total de tous les produits appartenant à une liste de produits à risque et le montant total du panier est supérieur au seuil paramétré dans la règle	0 à -4 selon paramétrage	PQ;N;Y; MAX_RATIO_PER_ RISKY_PRODUCT=L:A:B; MAX_RATIO_PER_ LIST=L:C:D*	MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*
L'information n'est pas connue	0	PQ;N;U	--
Aucun produit du panier n’appartient à une liste de produits à risque ou Le ratio entre le montant total pour un produit appartenant à une liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle et le ratio entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle	0	PQ;N;N; MAX_RATIO_PER_ RISKY_PRODUCT=L:A:B; MAX_RATIO_PER_ LIST=L:C:D*	MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*

*L : le nom de la liste de produits à risque concernée.

A : le plus grand ratio entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.

B : le ratio maximum accepté entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.

C : le plus grand ratio entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.

D : le ratio maximum accepté entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.

Note: jusqu’à 3 listes de produits à risque peuvent être utilisées pour cette règle. Les valeurs MAX_RATIO_PER_RISKY_PRODUCT et MAX_QUANTITY_PER_LIST sont restituées dans le champ scoreInfo pour chacune de ces listes. Pour cette règle il est donc possible d’avoir ces valeurs jusqu’à 3 fois dans le champ scoreInfo .

MAX_RATIO_PER_RISKY_PRODUCT=L1:A1:B1;MAX_RATIO_PER_LIST=L1:C1:D1; MAX_RATIO_PER_RISKY_PRODUCT=L2:A2:B2;MAX_RATIO_PER_LIST=L2:C2:D2; MAX_RATIO_PER_RISKY_PRODUCT=L3:A3:B3;MAX_RATIO_PER_LIST=L3:C3:D3

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=RiskyProductRatio

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductRatio</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["RiskyProductRatio"]
}

Quantité de produits

Description de la règle

Cette règle vous permet de limiter la quantité d’un même produit dans le panier d’un client.

La règle va analyser le contenu du panier et vérifier que la quantité de chaque produit n’excède pas le seuil que vous avez paramétré dans la règle. Cette règle n’utilise pas de listes de produits à risque.

Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

activer la règle dans le profil via l’onglet fraude du MEX
et transmettre le contenu du panier du client dans la requête, notamment le code produit et la quantité de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat


Cas d'utilisation	ScoreValue	ScoreInfo	RuleDetailedInfo
Au moins un produit du panier a une quantité supérieure au seuil paramétré dans la règle	0 à -4 selon paramétrage	QP;N;Y; PRODUCTQUANTITY=A:B*	PRODUCTQUANTITY =A:B*
L'information n'est pas connue	0	QP;N;U; PRODUCTQUANTITY=XXX:B*	PRODUCTQUANTITY =XXX:B*
Aucun produit du panier n’a une quantité supérieure au seuil paramétré dans la règle	0	QP;N;N; PRODUCTQUANTITY=A:B*	PRODUCTQUANTITY =A:B*

* A : la quantité du premier produit trouvé dont la quantité est supérieure au seuil défini dans la règle.

B : la quantité maximum de chaque produit acceptée dans le panier.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Exemple en version POST :

      fraudData.bypassCtrlList=MaxQuantityPerProduct

Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>MaxQuantityPerProduct</urn:bypassCtrlList>
</urn:fraudData>

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["MaxQuantityPerProduct"]
}

Configurer des profils anti-fraude avec le MEX

Ce chapitre vous présente la marche à suivre pour configurer les profils de lutte contre la fraude dans votre portail.

Utiliser l'onglet Fraude

Cliquez sur l'onglet Fraude pour accéder à la page d'accueil de l'outil de gestion des profils antifraude.

Attention: si un message s'affiche et indique un problème de droits d'accès, veuillez vous rapprocher de votre support afin d'activer l'option de lutte contre la fraude sur votre boutique.

Vous pouvez sélectionner la langue de votre choix (EN, FR) dans la partie supérieure droite.

Liste des boutiques

Dans la partie supérieure de la page, vous pouvez retrouver la liste des boutiques auxquelles vous avez accès.

Cliquez sur l'icône pour déplier cette partie et sélectionner une autre boutique.

Note: lorsqu'une boutique est sélectionnée, cette partie est automatiquement repliée.

Utilisez le champ de saisie situé en haut de cette partie pour filtrer les boutiques selon tout ou partie de leur nom ou ID.

Cliquez sur l'une des boutiques pour la sélectionner et afficher ses profils.

Partie principale

Le menu en haut de cette partie vous permet d’accéder à l’administration des profils et des listes de la boutique en ligne sélectionnée.

Tip: à différents endroits de l’interface, cliquez sur les icônes

pour accéder à des informations détaillées sur les éléments auxquels ils se rapportent.

Attention: gestion des droits

Les actions que vous pouvez effectuer dépendent du/des rôle(s) attribué(s) à votre profil MEX .

Administrer les profils antifraude

Dans la barre de menu, cliquez sur Gérer les profils pour accéder à cette section.

Liste des profils

La page d'accueil de cette section présente la liste des profils de la boutique :

Si vous avez souscrit à l'option permettant d’appliquer des contrôles antifraude avant l’authentification, une barre d’onglets permet de naviguer entre la liste des profils avant authentification et la liste des profils avant autorisation :

La colonne Statut live permet de constater l'état d'activation d'un profil.


profil désactivé	profil activé

Un profil est en état désactivé :

s'il n'a jamais été publié ;
s'il a été manuellement désactivé ;
ou s’il a été automatiquement désactivé par l’activation d’un autre profil en conflit par rapport aux moyens de paiement attribués.

Tip: profil par défaut actif

Pour éviter que le profil du distributeur ne soit appliqué, il est préférable qu’il y ait toujours un profil par défaut actif.

La colonne Statut brouillon permet de connaître l'état de publication d'un profil :


Statut	État de publication
	Le profil a été créé mais n’a jamais été publié.
	Le profil a été publié et est utilisé pour l’évaluation des transactions s’il est activé (cf. ci-dessus).
	Le profil a été modifié depuis sa dernière publication. Il doit être republié pour que les modifications soient prises en compte pour l’évaluation des transactions. Important : ceci n’affecte pas le fonctionnement de la version publiée du profil, qui continue de fonctionner de la même manière que précédemment.

Attention: version de travail et version publiée

Un profil est composé de deux entités : une version de travail et une version publiée.

La version de travail est celle que vous pouvez modifier et sauvegarder à loisir, sans effet sur les transactions de la boutique. Elle peut être considérée comme un brouillon de profil. A la création d’un nouveau profil, c’est la version de travail qui est en fait créée.

Lorsque vous êtes satisfait des modifications apportées sur la version de travail, vous pouvez la publier pour créer la version publiée. C’est cette version du profil qui est utilisée pour évaluer les transactions.

Un profil doit donc être à la fois actif et publié pour pouvoir être appliqué. Un profil actif mais ayant un statut « À republier » ne s'appliquera pas.

La colonne Moyens de paiement permet de connaître les moyens de paiement attribués à un profil.

Les profils peuvent être spécialisés pour des moyens de paiement particuliers. Cette colonne en récapitule la liste.

Les moyens de paiement sur fond coloré sont ceux attribués à la version publiée du profil.

Les moyens de paiement en couleur grise sont ceux présents uniquement dans la version de travail, et donc inactifs du point de vue de l’évaluation des transactions.

Dans cet exemple, Mastercard et Visa sont attribués au profil publié et CB est uniquement dans la version de travail :

Vous pouvez cliquer sur l'intitulé des colonnes afin de trier la liste selon le critère concerné.

Cliquez sur l'un des profils pour consulter et éditer le détail du paramétrage du profil.

Cycle de vie des profils

Exemple de cycle de vie d'un profil :

Créer un profil

Cliquez sur le bouton pour créer un nouveau profil. Les options de création sont les suivantes :

Profil Business Score
Si cette option est autorisée par le distributeur, sélectionnez le choix Profil Business Score dans la liste du bouton-menu Créer un profil . Vous accédez alors à la page de création d’un nouveau profil.

Choisissez Copier un existant pour créer un nouveau profil à partir d’un profil existant sur la boutique. Une fenêtre popup s'affiche et vous permet de choisir le profil à copier.

Une fois le profil à copier choisi, vous accédez à la page de création du profil.

À partir d'un modèle de profil
De la même manière que pour la copie d’un profil existant, une fenêtre popup vous permet de choisir, dans une liste de modèles de profil disponibles, celui qui va servir de base au nouveau profil créé.

Vous accédez ensuite à la page de création du profil :

Nom du profil :
Le nom du profil doit être unique pour une boutique donnée et peut contenir un maximum de 30 caractères parmi les suivants : A-Z, a-z, 0-9, _ (tiret bas) et espace.

Seuils :
Vous pouvez configurer l’étendue des zones rouge, orange et verte à l’aide des deux curseurs de seuil. La valeur du seuil apparaît en dessous du curseur.
La couleur des curseurs rappelle la couleur de l’évaluation du risque si le score calculé atteint la valeur du seuil. Dans l’exemple ci-dessus, un score de -1 donnera la couleur verte et un score de -2, la couleur orange.
Les bornes min et max du score sont recalculées dynamiquement en fonction des modifications apportées sur l’activation et le poids des règles. Par exemple, activer une règle avec un poids de -3 ajustera la valeur de la borne minimale de -3. Activer une règle avec un poids de +2 augmentera la valeur de la borne maximale de +2.

Si, suite à une modification des règles, un seuil a une valeur en dehors des bornes recalculées, sa valeur est ajustée automatiquement à la borne la plus proche et un message d’alerte est affiché :

Par exemple, si le seuil orange est positionné à -15 et que suite à une modification des règles, la borne minimale devient -10, le seuil orange sera ajusté automatiquement à -10.

Note: vérifier les seuils après modification des règles
Lorsqu’une règle est activée ou désactivée ou que son importance est modifiée, le maximum et le minimum du score évoluent en conséquence. Une fois les modifications sur les règles effectuées, il est donc nécessaire de réviser les seuils définissant les zones rouges, orange et vertes pour en ajuster les proportions au besoin.

Moyens de paiement :
Vous pouvez décider si le profil doit s’appliquer à un ou plusieurs moyens de paiement particuliers. Cochez les cases des moyens de paiement souhaités. La liste des moyens de paiement disponibles dépend des contrats actifs sur la boutique et configurés dans le MEX .

Note: profils par défaut
si le profil doit prendre en charge tous les moyens de paiement, il s’agit alors d’un profil par défaut . Il est alors inutile de cocher quoi que ce soit.

Un moyen de paiement apparaissant grisé et accompagné d’une balise vous avertit que ce moyen de paiement est déjà sélectionné dans un autre profil actif. Vous pouvez toutefois le cocher si tel est votre choix. Il sera alors enlevé de l’autre profil. Un message d’avertissement s'affiche au moment où vous cochez le moyen de paiement :

Note: un seul profil pour un moyen de paiement donné
Il ne peut y avoir qu’un seul profil actif éligible à un moyen de paiement donné. L’interface de configuration garantit cela en supprimant automatiquement les moyens de paiement des autres profils si un conflit se pose avec un profil nouvellement édité. Au moment de sa publication, ce dernier aura donc l’entière responsabilité des moyens de paiement concernés.

Prise en compte des transactions refusées dans les règles d'encours
Cochez cette option afin de prendre en compte les transactions refusées dans les compteurs (en plus des transactions acceptées).

Devise des paramètres
Si une boutique possède des contrats sur des moyens de paiement dans de multiples devises, il lui est possible de choisir dans quelle devise est effectué le paramétrage des montants dans le détail des règles.

Note: attention
Toutes les transactions peuvent être évaluées par un profil, quelle que soit leur devise respective. En effet, ce paramètre n’indique en aucun cas que le profil ne s’applique qu’aux transactions dont le montant est exprimé dans la devise choisie.

Dans le cas où la transaction est dans une devise différente de celle paramétrée dans le profil, une conversion de change est effectuée.

Règles du profil
La section Gérer vos règles de la page de création du profil vous permet de choisir les règles à appliquer pour le profil. Pour plus de détails consultez le paragraphe Administrer les règles dans les profils .

Le profil est enregistré lorsque l'utilisateur clique sur le bouton . À cet instant, le profil n'est pas encore activé. Vous devez ensuite le publier (voir le paragraphe Éditer et publier un profil ).

Le bouton permet d'annuler la création du profil et de revenir à la liste des profils de la boutique.

Éditer et publier un profil

La page d'édition de profil est pratiquement identique à la page de création d'un profil. En mode édition, le nom du profil n'est pas modifiable.

Statut du profil
La partie droite de la page donne des détails sur le statut du profil :

On y retrouve le statut (voir le paragraphe 'Liste des profils'), la date de publication et la devise des paramètres. La date de modification correspond à la date de dernière sauvegarde de la version de travail.

Actions disponibles en mode édition


Action	Description
	Permet de sauvegarder les modifications effectuées sur la version de travail. La sauvegarde ne publie pas les modifications. Pour ce faire, il vous faudra utiliser le bouton « Publier » .
	Permet de restaurer un profil dont la version de travail a été modifée, dans l’état où il était lors de sa dernière publication. Cette action n’est disponible que si le profil a été publié et qu’il a été modifié depuis (son statut est alors « À republier » ).
	Permet de supprimer un profil non publié. Cette action n’est plus accessible de cette page si le profil a été publié. Il vous faudra consulter la version publiée du profil pour la supprimer.
	Permet de publier la version de travail du profil et donc de la rendre effective pour l’évaluation des transactions. La couleur orange vous indique que cette action aura un effet potentiel sur les transactions de la boutique.

Cliquez sur pour revenir à la liste des profils.

Cliquez sur pour consulter la version publiée du profil le cas échéant.

Consulter un profil publié

Vous pouvez consulter la version publiée d'un profil en cliquant sur le bouton dans la page d'édition d'un profil.

La page suivante s'affiche :

Cet écran vous permet de consulter les détails du profil publié et de ses règles.

Actions disponibles sur un profil publié


Action	Description
	Permet d’activer le profil publié et inactif. Ce profil devient alors effectif pour l’évaluation des transactions.
	Permet de désactiver le profil publié et actif. Ce profil n'est alors plus effectif pour l’évaluation des transactions.
	Permet de supprimer un profil publié.

La couleur orange vous indique que cette action aura un effet potentiel sur les transactions à venir de la boutique.

Le bouton vous permet de revenir à la version de travail du profil.

Activer et désactiver un profil

Pour activer ou désactiver un profil publié , vous devez vous rendre sur la page de consultation de sa version publiée :

choisissez le profil à activer ou à désactiver dans la liste des profils de la boutique ;
dans le détail du profil, cliquez sur ;
enfin, cliquez sur les boutons ou selon l'état d'activation du profil.

Pour activer un profil non publié , il suffit de le publier.

Supprimer un profil

Pour supprimer un profil publié vous devez, comme pour l'activation et la désactivation, accéder à la page de consultation de la version publiée du profil (voir le paragraphe 'Activer et désactiver un profil').

Supprimez ensuite le profil en cliquant sur le bouton .

Pour supprimer un profil non publié, accédez à sa version de travail (voir le paragraphe 'Éditer et publier un profil') et cliquez sur le bouton .

Administrer les règles dans les profils

Activer et paramétrer une règle

Les règles sont regroupées par catégories. cliquez sur l'intitulé d'une catégorie pour la déployer et en consulter les règles.

L'icône indique que la règle est désactivée pour ce profil et n'a donc aucune influence sur les transactions. Cliquez sur cette icône pour activer la règle.

L'icône indique que la règle est active pour ce profil et sera donc utilisée pour l'évaluation des transactions lorsque le profil sera lui-même publié et actif. Cliquez sur cette icône pour désactiver la règle.

L'icône permet d'obtenir des détails sur la règle.

À côté de chaque règle, un menu déroulant permet d'en préciser l'importance.

Certaines règles sont paramétrables. Cliquez sur l'icône pour en afficher le détail (consultez les chapitres suivants pour plus d'informations sur le paramétrage des règles).

Il est possible qu'une règle ne soit pas activable, désactivable ou configurable en conséquence des choix du distributeur ou de contraintes autres.

Ordonner les règles décisives

Si le profil comporte plusieurs règles décisives, vous pouvez préciser l'ordre dans lequel elles doivent se dérouler en cliquant sur l'icône . Les règles décisives que vous avez activées apparaissent alors dans une fenêtre pop-up :

Utilisez ensuite les boutons et pour réordonner la liste.

Filtrer les règles par moyen de paiement

Certaines règles sont liées à un moyen de paiement (ex : SDD) ou un type de moyen de paiement (ex : carte) en particulier. Citons par exemple l’encours carte qui ne s’applique que pour une carte de paiement (CB, Visa, Mastercard) ou l’encours par IBAN qui ne s’applique que pour un paiement SDD.

Lors du paramétrage du profil, les règles proposées sont filtrées en fonction des moyens de paiement auxquels vous avez souscrit. Ainsi, vous ne pourrez pas activer les règles dépendant de certains moyens de paiement ou types de moyen de paiement si vous n'avez pas souscrit à ceux-ci.

Lorsqu’une règle ne s’applique qu’à un certain moyen de paiement ou type de moyen de paiement, une étiquette est affichée à côté du nom de la règle pour le préciser :

Paramétrer les règles de géolocalisation : adresses et pays

Pays de la carte

Cette section permet de configurer la liste des pays autorisés ou interdits par la règle. Cette liste peut apparaître sur plusieurs pages. Le champ Résultat correspond au score de la règle pour le pays concerné.

Les boutons radio Statut permettent de préciser si la liste qui suit est une liste de pays autorisés ou interdits.

Le champ Pays de la carte permet d’ajouter un pays à la liste par saisie manuelle de son nom dans le champ (avec auto-complétion possible).

Le bouton ouvre une fenêtre popup permettant de sélectionner un ou plusieurs pays dans une liste :

Lorsque vous effectuez une saisie manuelle, la liste est filtrée en fonction de la saisie, ce qui vous permet de constater si le pays saisi s'y trouve déjà :

Le bouton vous permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager des pays (qui vont donc donner respectivement un résultat positif ou négatif) :

Vous pouvez exporter le contenu de la liste dans un fichier au format CSV en cliquant sur le bouton . Cette action génère un fichier qui va contenir tous les éléments de la liste. Ce fichier est automatiquement téléchargé par votre navigateur.

Reportez-vous à l' Annexe 9 : format de fichier d'export de liste pour en savoir plus sur le contenu du fichier CSV.

Pays de la carte et de l'adresse IP

Cette section permet de configurer la liste des couples de pays autorisés ou interdits par la règle. Le champ Résultat correspond au résultat de la règle pour le pays concerné.

Les boutons radio Statut vous permettent de préciser si la liste qui suit est une liste de couple de pays autorisés ou interdits.

Le champ Pays de l’adresse IP vous permet de saisir manuellement le pays de l’adresse IP du couple à ajouter à la liste.

Si vous souhaitez préciser d’emblée une liste de pays d’adresses IP, cliquez sur le bouton : une fenêtre popup s'affiche et vous permet de sélectionner les pays souhaités. Une fois la liste sélectionnée, la mention liste de pays apparaît dans la zone de saisie.

Le champ Pays de la carte permet de préciser le pays de la carte du couple à ajouter à la liste et fonctionne de la même manière que le champ Pays de l’adresse IP .

Lorsque vous avez saisi les pays manuellement ou via la fenêtre popup, cliquez sur le bouton pour ajouter le ou les couples sélectionnés à la liste du contrôle.

Vous pouvez également cliquer sur le bouton pour ajouter les couples et leurs réciproques à la liste. Par exemple, si vous sélectionnez pays de l’adresse IP = France et pays de la carte = Belgique, ce bouton ajoute les couples France/Belgique et Belgique/France à la liste des couples.

Lorsque vous effectuez une saisie manuelle, la liste est filtrée en fonction de la saisie, ce qui vous permet de constater si le couple saisi s'y trouve déjà. Cette liste peut apparaître sur plusieurs pages.

Le bouton Activer le mode avancé vous permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager des pays (qui vont donc donner respectivement un résultat positif ou négatif).

Reportez-vous à l' Annexe 9 : format de fichier d'export de liste pour en savoir plus sur le contenu du fichier CSV.

Autres règles

Le paramétrage se fait de la même manière pour de nombreuses règles :


Vous voulez paramétrer la règle...	Veuillez consulter le paramétrage de la règle...
Pays de livraison et de la carte Pays de facturation et de la carte Pays de livraison et de l'IBAN Pays du numéro de tél. et de l'IBAN Pays de l'adresse IP et de l'IBAN	Pays de la carte et de l'adresse IP
Pays de l'adresse IP Pays de l'IBAN	Pays de la carte
Pays de livraison et de facturation	Cette règle ne nécessite pas de configuration particulière.
Codes postaux de livraison et de facturation	Cette règle ne nécessite pas de configuration particulière, mais vous ne pouvez pas l'ajouter sans (ou la positionner avant) la règle de vérification des pays de livraison et de facturation.

Paramétrer les règles d'encours

Encours carte

Les champs Période permettent de préciser les périodes sur lesquelles le cumul du nombre et le cumul des montants des transactions sont effectués pour la carte concernée. Vous pouvez préciser ces périodes en heures, jours ou semaines en cliquant sur les boutons .

Le champ Nombre maximum de transactions permet de préciser le nombre maximum de transactions autorisé sur la période.

Le champ Montant cumulé maximum permet de préciser le montant cumulé maximum des transactions sur la période. Un rappel de la devise d’expression du montant cumulé est affiché au début de ce champ.

Il n'est pas obligatoire de préciser à la fois un montant cumulé maximum et un nombre maximum de transactions. Un des deux suffit.

De la même manière, il n’est pas obligatoire de paramétrer le nombre maximum de transactions et le montant cumulé maximum. Le paramétrage d’un des deux suffit.

Nombre de clients par carte

Le champ Période permet de préciser la période sur laquelle le décompte du nombre de clients pour la carte concernée se fait. Il est possible de préciser cette période en heures, jours ou semaines à l'aide du bouton .

Encours partagé

Si l’offre distributeur permet les encours partagés, lorsque vous configurez un profil, une icône située à droite du nom de la règle vous informe si l’encours est partagé avec d’autres boutiques ou s’il est privé :

indique que l'encours est partagé.

indique que l'encours est privé.

Passez le curseur de votre souris au-dessus d'une icône pour obtenir plus d'informations :

Autres règles

Le paramétrage se fait de la même manière pour de nombreuses règles :


Vous voulez paramétrer la règle...	Veuillez consulter le paramétrage de la règle...
Encours par adresse IP Encours par identifiant client Encours par mandat Encours par IBAN	Encours carte
Nombre de cartes par client Nombre de cartes par adresse IP Nombre d'IBAN par adresse IP Nombre d'adresses IP par IBAN Nombre de clients par IBAN Nombre d'IBAN par client Nombre de mandats par adresse IP	Nombre de clients par carte

Paramétrer les règles diverses

Réputations d'adresse IP

Vous pouvez mettre à jour la liste des statuts d’adresse IP non autorisés :

cliquez sur le bouton pour faire passer l'élément sélectionné de la colonne Disponible à la colonne Statuts d'adresse non autorisés ;
ou cliquez sur le bouton pour retirer l'élément sélectionné de la liste des statuts d'adresse non autorisés .

Veuillez consulter l'Annexe 3 : réputations d'adresse IP, pour plus d'informations.

Plage de montants

Le champ Montant minimum permet de préciser le montant minimum autorisé pour une transaction. Un rappel de la devise d’expression du montant minimum est indiqué au début de ce champ.

Le champ Montant maximum permet de préciser le montant maximum autorisé pour une transaction.

Le bouton Activer le mode avancé permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager des plages de montants impliquant respectivement un résultat positif ou négatif. Le résultat est neutre si le montant n’est dans aucune des deux plages.

Adresse-e-mail-gratuite

Le champ Nom de domaine vous permet de saisir un nom de domaine pour l’ajouter à la liste des noms de domaine interdits.

Dans l’exemple ci-dessus, hotmail.com a été ajouté à la liste, ce qui signifie que les adresses e-mail en @hotmail.com seront interdites.

Vous pouvez utiliser un astérisque pour la dernière partie du nom de domaine afin de prendre en compte toutes les possibilités. Par exemple, vous pouvez ajouter hotmail.* à la liste afin de refuser les adresses en @hotmail.com, @hotmail.fr, @hotmail.be , etc.

Authentification 3-D Secure

La liste des statuts non autorisés se met à jour selon la même logique que pour les réputations d'adresse IP.

Cette liste ne présente que les statuts 3-D Secure ayant une pertinence en termes de filtrage par le contrôle de risque. Vous n’y retrouverez notamment pas les statuts SUCCESS, CANCEL ou BYPASS. Le distributeur peut imposer des règles d’acceptation de statuts 3-D Secure en amont des contrôles de lutte contre la fraude. Il est donc possible que des transactions ayant certains statuts de cette liste soient interrompues avant même qu’un contrôle de lutte contre la fraude soit effectué. Pour plus de détails sur les statuts 3-D Secure, reportez-vous à l’Annexe 5 : statuts d'authentification 3-D Secure.

Le bouton Activer le mode avancé vous permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager les statuts 3-D Secure (qui vont donc donner respectivement un résultat positif ou négatif). Vous pouvez obtenir un résultat neutre si le statut est dans la liste des statuts disponibles .

Date d'expiration de la carte

Le champ Période vous permet de préciser le nombre de mois avant expiration de la carte en dessous duquel la transaction sera refusée.

Autres règles

Le paramétrage se fait de la même manière pour de nombreuses règles :


Vous voulez paramétrer la règle...	Veuillez consulter le paramétrage de la règle...
Carte commerciale (et pays de la carte)	Pays de la carte Attention cependant, la règle Carte commerciale (et pays de la carte) n'est pas éligible au mode de configuration avancé.
Vérification d'adresse (InfoScore)	Authentification 3-D Secure
Carte en opposition Carte virtuelle Carte à autorisation systématique Carte réseau CB Syntaxe d'adresse e-mail Vérification de compte (InfoScore)	Ces règles ne nécessitent pas de configuration particulière.

Paramétrer les règles de liste

Alimenter les listes

Les règles de liste ne nécessitent pas de configuration particulière.

Mais activer une règle de liste dans un profil ne suffit pas : vous devez aussi gérer la liste en elle-même. Vous disposez pour cela de trois possibilités :

ajouter des éléments dans la liste via Sips Office Batch ou
ajouter des éléments dans la liste via Sips Office SOAP ou JSON ou
utiliser l'onglet Alimenter les listes .

Note: les solutions utilisant Sips Office SOAP, Sips Office JSON ou Sips Office Batch sont décrites dans les guides utilisateurs des applications correspondantes. Nous n'expliquerons dans cette documentation que la solution utilisant l'interface de lutte contre la fraude.

Pour alimenter les listes via le MEX , suivez cette procédure :

Cliquez sur l'onglet "Alimenter les listes".

En accédant à cette rubrique vous obtenez l'accès aux listes à votre disposition : celles-ci varient en fonction de l'offre à laquelle vous avez souscrit. Veuillez consulter la liste des règles pour connaître l'ensemble des règles de listes existantes.

Après avoir cliqué sur l'onglet approprié, vous pouvez choisir de gérer la liste noire, grise ou blanche en cliquant sur la flèche correspondante sur la droite :

Lors de la modification d'une liste, vous pouvez :

ajouter une valeur à la liste en précisant un motif d'ajout ;
effacer un élément de la liste ;
déplacer un élément d'une liste grise vers une liste noire.

Ajouter une valeur à une liste

Vous devez saisir dans le champ de données approprié la valeur que vous souhaitez ajouter à une liste :

En cliquant sur le bouton , une fenêtre popup apparaît et vous permet de sélectionner un motif d'ajout de la valeur.

Ajouter une valeur à la liste des numéros de cartes

La gestion des numéros de carte sur les listes noire, grise ou blanche est différente de la gestion des autres listes.

Vous pouvez ajouter un numéro de carte :

via la référence de transaction liée au numéro de carte ;
via le numéro de carte ;
via le token de la carte.

Après avoir sélectionné le mode d’ajout via une liste déroulante, vous pouvez saisir le token, le numéro de carte ou la référence de transaction.

Vous pouvez ajouter des numéros de cartes par références de transactions, en utilisant des références de transactions (clé primaire WL Sips 2.0), ou en utilisant des identifiants et dates de transactions (clé primaire WL Sips 1.0).

L'ajout par token est uniquement disponible si vous possédez l'option associée.

Sélectionner un motif d'ajout d'élément à une liste

Après avoir cliqué sur le bouton , sélectionnez le motif dans la fenêtre popup et cliquez sur OK , l'élément est ajouté à la liste.

Ajouter un motif peut s'avérer pratique ultérieurement (par exemple pour ajouter un certain identifiant client à une liste blanche). Les motifs peuvent être sélectionnés parmi une liste prédéfinie en fonction du type approprié à la liste. Mais vous pouvez également décider de conserver la valeur par défaut « Non mentionné ».

Les motifs sont affichés à côté des éléments :

Ils sont identiques pour les listes noires et grises. Voici un récapitulatif de ces motifs :


Type de liste	Motifs pour les listes blanches	Motifs pour les listes noires et grises
Adresses e-mail	Non mentionné VIP Adresse e-mail approuvée Client B2B	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale Adresse e-mail inconnue Impayé Débit impossible Répudiation porteur Tentative de paiement multiple
Adresses IP	Non mentionné VIP Client B2B Adresse IP approuvée	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale Adresse IP inconnue Impayé Débit impossible Répudiation porteur Tentative de paiement multiple
Codes postaux	Non mentionné Expérience positive	Non mentionné Fraude suspectée Expérience négative Liste noire externe Code postal inconnu Suspicion générale
Identifiants client	Non mentionné VIP Client B2B Client approuvé Participant promotion	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale Impayé Débit impossible Répudiation porteur Tentative de paiement multiple
Noms de clients	Non mentionné VIP Client B2B Nom approuvé	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale Impayé Débit impossible Répudiation porteur Tentative de paiement multiple
Numéros de carte	Non mentionné VIP Client B2B Numéro de carte de confiance Carte de voyage	Non mentionné Fraude suspectée Expérience négative Liste noire externe Carte perdue Carte volée Carte inconnue Carte interdite Impayé Débit impossible Répudiation porteur Tentative de paiement multiple
Numéros de téléphone	Non mentionné VIP Client B2B Numéro de téléphone approuvé	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale Numéro de téléphone inconnu Impayé Débit impossible Répudiation porteur Tentative de paiement multiple
Plages de BIN	Non mentionné Plage de BIN approuvée	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale
BIC	Non mentionné	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale
IBAN	Non mentionné VIP Client B2B IBAN approuvé	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale Tentative de paiement multiple Débit impossible
Mandats	Non mentionné VIP Client B2B ID de mandat approuvé	Non mentionné Fraude suspectée Expérience négative Liste noire externe Suspicion générale Tentative de paiement multiple Débit impossible

Exporter une liste

Il est possible d’exporter le contenu d’une liste dans un fichier au format CSV en cliquant sur le bouton . Un fichier contenant tous les éléments de la liste est alors généré et automatiquement téléchargé par votre navigateur.

Veuillez consulter l' Annexe 9 : format de fichier d'export de liste pour en savoir plus sur le contenu du fichier CSV.

Supprimer une valeur de la liste

Vous pouvez également effacer des valeurs de la liste, par exemple si elles ne sont plus valables ou ont été ajoutées par erreur :

sélectionnez une ou plusieurs valeurs à effacer en cochant la case à côté de l'entrée appropriée ;
puis cliquez sur le bouton Supprimer les entrées sélectionnées .

Pour éviter qu'une valeur ne soit effacée par erreur, vous devez cliquer sur Confirmer dans la fenêtre de confirmation.

Déplacer une valeur

Une valeur peut être déplacée d'une liste grise vers une liste noire, par exemple si la gravité d'un cas augmente. Cela vous évite d'avoir à effacer une valeur de la liste grise et de devoir la saisir de nouveau dans la liste noire. Voici la procédure :

sélectionnez une ou plusieurs valeurs à déplacer en cochant les cases en regard des entrées désirées ;
puis déplacez-les en utilisant le bouton Déplacer l'élément sélectionné vers la liste noire .

Pour éviter qu'un élément ne soit effacé par erreur, vous devez cliquer sur Oui dans la fenêtre de confirmation.

Attention: une valeur ne peut appartenir qu'à une seule liste. Il n'est par exemple pas possible de placer la même valeur dans une liste grise et dans une liste noire.

Listes partagées

Une offre distributeur permettant les listes partagées donne la possibilité à une boutique de partager ses éléments avec d’autres boutiques appartenant au même groupe commercial. Il est toujours possible d’avoir une liste privée uniquement utilisée par une seule boutique.

La configuration des profils

Lorsque vous configurez un profil, des icônes situées à droite des noms de règles vous indiquent si la liste est partagée avec d'autres boutiques ou si elle est privée :

indique que la liste est partagée.

indique que la liste est privée.

Passez le curseur de votre souris au-dessus d'une icône pour obtenir plus d'informations :

Les listes elles-mêmes

Une boutique peut partager ses éléments avec d’autres boutiques appartenant au même groupe commercial. Il est toujours possible d’avoir une liste privée uniquement utilisée par une seule boutique.

Vous pouvez voir si une liste est privée ou partagée au-dessus du formulaire permettant d’ajouter un nouvel élément dans la liste :

indique que la liste est partagée.

indique que la liste est privée.

Quand la boutique sélectionnée partage une liste, la gestion des listes est identique à ce qui est décrit dans les sections précédentes. La seule différence est qu’une boutique ne peut supprimer uniquement que les éléments qu’elle a préalablement ajoutés. Il n’est pas possible de supprimer un élément ajouté par une autre boutique.

La boutique ayant ajouté un élément dans la liste est affichée dans la colonne ID de boutique . Cette colonne est visible uniquement lorsque la liste est partagée :

Un système de « verrou » permet à plusieurs boutiques d’ajouter le même élément dans la liste. Chaque boutique ajoutant un élément ajoute un « verrou » sur cet élément. Si au moins un verrou existe sur un élément, il est dans la liste. Un élément est considéré comme absent de la liste lorsque chaque verrou sur cet élément est supprimé par la boutique l’ayant ajouté.

Listes volumineuses

Lorsqu’une liste blanche, grise ou noire devient trop volumineuse, les éléments de la liste affichés dans l’interface sont limités aux 600 premiers éléments trouvés.

Dans ce cas, un message d’alerte s'affiche au-dessus de la liste et une fonctionnalité de recherche s’active afin de vous permettre de retrouver les éléments présents dans la liste et non affichés dans l’interface :

Si vous sélectionnez Ajout d’élément , le formulaire vous permet d'ajouter de nouveaux éléments (voir les paragraphes 'Ajouter une valeur à une liste' et 'Ajouter une valeur à la liste des numéros de carte').

Si vous sélectionnez Recherche d’élément(s) , le formulaire vous permet d’effectuer une recherche à partir d’une valeur précise (recherche spécifique) ou partielle (filtrage). Cliquez sur le bouton pour rafraîchir la liste avec le ou les élément(s) présent(s) dans la liste et correspondant à la valeur saisie dans le champ de recherche :

Recherche d'un élément spécifique

Filtrage de la liste

Après avoir fait une ou plusieurs recherches successives, le bouton vous permet de revenir à l’affichage initial des 600 premiers éléments de la liste.

Paramétrer les règles panier

Administrer les listes de produits à risque

L'administration des listes de produits à risque s'effectue en cliquant sur l'onglet Listes de produits à risque :

Vous accédez à la page d'administration des listes de produits à risque :

Vous y retrouvez l'ensemble des listes de produits à risque déjà créées.

Cliquez sur pour modifier une liste ou sur pour la supprimer.

Créer une liste

Cliquez sur le bouton pour créer une nouvelle liste de produits à risque.

Vous disposez alors de deux possibilités :

Créer une nouvelle liste

Renseignez le nom de la nouvelle liste puis cliquez sur OK .

Utiliser une liste partagée

Il vous suffit de sélectionner dans le menu déroulant la liste partagée à utiliser.

Les listes choisies et/ou créées sont ensuite visibles sur la page d’administration des listes de produits à risque : vous pouvez y effectuer des opérations sur chaque liste et sur la page de paramétrage de profil afin de vous permettre de choisir vos listes.

Exporter/importer une liste

Vous avez la possibilité d'exporter la liste au format Excel (.CSV) en cliquant sur le bouton . Le fichier généré contient tous les produits de la liste et est téléchargé automatiquement par votre navigateur.

Vous pouvez également importer une liste (fichier au format .CSV) en cliquant sur le bouton . Une fois l’import effectué, l’ensemble de la liste est mis à jour avec les produits contenus dans le fichier importé. Les produits ne se trouvant pas dans le fichier sont supprimés de la liste.

Veuillez consulter l' Annexe 9 : format de fichier d'export de liste pour en savoir plus sur le contenu du fichier CSV.

Ajouter/modifier/supprimer un produit

Vous pouvez ajouter manuellement un produit à une liste en cliquant sur le bouton .

Pour ajouter un produit à une liste, vous devez remplir trois champs :

le code du produit ;
le libellé ;
la date de validité.

IMPORTANT: le code du produit est l’information utilisée pour retrouver les produits du panier. Il est donc important que le code concorde entre les listes de produits et les paniers des transactions.

Une fois ces champs remplis et validés, le produit est ajouté directement à la liste des produits à risque.

Cliquez sur l'icône pour modifier un produit, ou sur l'icône pour le supprimer.

Liste de produits à risque

Cette section vous permet de configurer la liste des produits à risque à utiliser. Les différentes listes affichées dans cette section sont celles qui ont été créées au préalable depuis l’onglet Alimenter les listes -> Listes de produits à risque.

Cochez les listes de produits à risque que vous souhaitez utiliser. Plusieurs listes peuvent être utilisées simultanément.

indique que la liste est partagée.

indique que la liste est privée.

Quantité de produits

Vous pouvez paramétrer la quantité maximale de produits dans un panier en saisissant manuellement la quantité désirée dans le champ ci-dessous :

Quantité de produits à risque

Les différentes listes affichées dans cette section sont celles qui ont été créées au préalable depuis l’onglet Alimenter les listes -> Listes de produits à risque .

Cochez les listes que vous souhaitez utiliser. Plusieurs listes peuvent être utilisées simultanément.

Pour chaque liste de produits, vous pouvez définir la quantité maximale par produit et la quantité maximale de tous les produits en saisissant manuellement ces quantités dans les deux champs numériques affichés sous chaque liste :

indique que la liste est partagée.

indique que la liste est privée.

Ratio de produits à risque

Cette règle se configure de la même manière que la règle 'Quantité de produits à risque', à l'exception des valeurs saisies qui sont des ratios et non des quantités.

Partager des listes

La page d'administration des listes partagées de produits à risque se présente comme suit :

On y retrouve les mêmes fonctionnalités que celles présentées dans le paragraphe 'Administrer des listes de produits à risque' : vous pouvez donc utiliser les listes créées à partir de cette page en vous rendant sur la page d’administration des listes de produits à risque.

Historisation des actions sur l'interface

Une historisation des modifications faites via l’interface est disponible dans l’onglet Historisation .

Vous pouvez y voir toutes les modifications faites sur vos profils, mais également les changements impactant votre lutte contre la fraude : la publication d’un modèle de profil ou l’association à un groupe/une liste partagé(e). Les modifications de contenu de vos listes marchandes (liste d’e-mail, de nom, etc.) ne sont pas sauvegardées.

Tableau des modifications

Lorsque vous arrivez sur la page des modifications, le tableau n’est pas filtré et contient toutes les modifications concernant la boutique ordonnées de la plus récente à la plus ancienne.

La partie supérieure du tableau vous permet de filtrer la liste des résultats selon 4 critères : une date minimum, une date maximum, un nom d’utilisateur ou un type d’historique (profil marchand, modèle de profil ou association de groupe).

Après avoir cliqué sur , l'application recharge le tableau avec les données filtrées.

Chaque ligne du tableau présente la date à laquelle l’action a été effectuée, l’utilisateur ayant effectué l’action, l’entité modifiée ainsi qu’une brève description de l’action.

Cliquez sur l'icône pour comparer l’état de l’objet avant et après modification.

Détail des modifications

Profil marchand et modèle de profil

Après avoir cliqué sur l’icône , une fenêtre popup apparaît et vous présente une comparaison entre le profil avant et après modification(s). Cette fenêtre n'affiche par défaut que les modifications mais vous pouvez afficher également les valeurs inchangées en cochant la case Afficher les valeurs inchangées (toutes les données du profil) .

La comparaison est composée de 3 parties :

informations générales sur le profil : nom, moyens de paiement, devise ;
liste des règles décisives ;
liste des règles informatives.

Modification sur une règle

La modification des règles suit un code couleurs :


Couleur	Signification
Le nom de la règle est en rouge et le symbole la précède.	La règle a été supprimée du profil.
Le nom de la règle est en vert et le symbole la précède.	La règle a été ajoutée au profil.
Le nom de la règle est en orange et le symbole la précède.	La règle a été déplacée dans le profil : cela signifie qu’elle a changé de mode (de décisive à informative et vice-versa) ou qu’elle est décisive et que son rang d’exécution a changé.
Le nom de la règle est en noir .	Le contenu de la règle a changé.
Le nom de la règle est en gris .	La règle n'a pas changé (uniquement visible lorsque la case correspondante est cochée).

Exemples :


Nom de la règle et couleur	Signification
	La règle n'a pas été modifiée.
	La règle a été ajoutée en 2e position dans l'ordre d'exécution.
	Le mode de la règle est passé de décisif à informatif.
	La règle a été déplacée dans l'ordre d'exécution de la position 2 à la position 1.
	Le mode de la règle a été modifié d'informatif à décisif avec un ordre d'exécution à 2.
	La règle a été supprimée.
	La règle n'a pas été déplacée mais le contenu de la règle a été modifié.

Modification sur une valeur

La modification des valeurs suit elle aussi un code couleurs :


Valeur	Signification
Valeur en vert .	Il s'agit d'une nouvelle valeur.
Valeur en rouge et barrée .	Il s'agit d'une ancienne valeur.
Valeur en noir .	La valeur est inchangée.

Dans le cas d'une modification, l'ancienne valeur en rouge sera suivie de la nouvelle valeur en vert.

Association de groupe/liste

Après avoir cliqué sur l’icône , une fenêtre popup apparaît et vous présente une comparaison entre le nouveau groupe (ou la nouvelle liste) auquel la boutique est rattachée, et l’ancien groupe (ou l'ancienne liste). Vous voyez donc l’ancien groupe en rouge barré et le nouveau groupe en vert :

Annexes

Annexe 1 : désactivation dynamique de certaines règles du profil

Si vous souhaitez empêcher l’exécution d’une des règles de votre profil pour une transaction, vous devez envoyer l'élément correspondant à la règle dans l'élément fraudData de la demande de paiement.


fraudData.bypass3DS	Désactiver l'authentification 3D
fraudData.bypassCtrlList	Désactiver les règles standards
fraudData.bypassInfoList	Obsolète

fraudData.bypass3DS


Valeur	Description
ALL	Ignorer la procédure 3DS (pour les paiements CB, VISA, MASTERCARD et AMEX)
MERCHANTWALLET	Ignorer la procédure 3DS pour les paiements en 1 clic (pour les paiements CB, VISA, MASTERCARD et AMEX)

fraudData.bypassCtrlList


Valeur	Description
AccountVerification	Désactiver la règle Vérification de compte (InfoScore)
AddressVerification	Désactiver la règle Vérification d’adresse (InfoScore)
BlackBic	Désactiver la règle Liste noire de BIC
BlackBinCard	Désactiver la règle Liste noire de plages de BIN
BlackCard	Désactiver la règle Liste noire de numéros de carte
BlackCustomerId	Désactiver la règle Liste noire d’identifiants de clients
BlackCustomerName	Désactiver la règle Liste noire de noms de clients
BlackEmail	Désactiver la règle Liste noire d’adresses e-mail
BlackIban	Désactiver la règle Liste noire d’IBAN
BlackIp	Désactiver la règle Liste noire d’adresses IP
BlackMandate	Désactiver la règle Liste noire de mandats
BlackPhoneNumber	Désactiver la règle Liste noire de numéros de téléphone
BlackPostalCode	Désactiver la règle Liste noire de codes postaux
CapCollarAmount	Désactiver la règle Plage de montants
CardCountry ForeignBinCard (déprécié)	Désactiver la règle Pays de la carte
CBScheme	Désactiver la règle Carte réseau CB
CommercialCard CorporateCard (déprécié)	Désactiver la règle Carte commerciale (et pays de la carte)
EmailSyntax	Désactiver la règle Syntaxe d’adresse e-mail
ECard	Désactiver la règle Carte virtuelle
ExpiryDate	Désactiver la règle Date d’expiration de la carte
FreeEmail	Désactiver la règle Adresse e-mail gratuite
GreyBic	Désactiver la règle Liste grise de BIC
GreyBinCard	Désactiver la règle Liste grise de plages de BIN
GreyCard	Désactiver la règle Liste grise de numéros de carte
GreyCustomerId	Désactiver la règle Liste grise d’identifiants de clients
GreyCustomerName	Désactiver la règle Liste grise de noms de clients
GreyEmail	Désactiver la règle Liste grise d’adresses e-mail
GreyIban	Désactiver la règle Liste grise d’IBAN
GreyIp	Désactiver la règle Liste grise d’adresses IP
GreyMandate	Désactiver la règle Liste grise de mandats
GreyPhoneNumber	Désactiver la règle Liste grise de numéros de téléphone
GreyPostalCode	Désactiver la règle Liste grise de codes postaux
HotList	Désactiver la règle Carte en opposition
IbanCountry	Désactiver la règle Pays de l’IBAN
IpCountry	Désactiver la règle Pays de l’adresse IP
IpReputations	Désactiver la règle Réputation d’adresse IP
MaxCardPerCustomerId	Désactiver la règle Nombre de cartes par client
MaxCardPerIp	Désactiver la règle Nombre de cartes par adresse IP
MaxCustidPerIban	Désactiver la règle Nombre de clients par carte
MaxCustomerIdPerCard	Désactiver la règle Nombre de clients par carte
MaxIbanPerCustid	Désactiver la règle Nombre d’IBAN par client
MaxIbanPerIp	Désactiver la règle Nombre d’IBAN par adresse IP
MaxCardPerIp	Désactiver la règle Nombre de cartes par adresse IP
MaxIpPerIban	Désactiver la règle Nombre d’adresses IP par IBAN
MaxMandatePerIp	Désactiver la règle Nombre de mandats par adresse IP
MaxQuantityPerProduct	Désactiver la règle Quantité de produits
RiskyProductList	Désactiver la règle Liste de produits à risque
RiskyProductQuantity	Désactiver la règle Quantité de produits à risque
RiskyProductRatio	Désactiver la règle Ratio de produits à risque
SimilarityBillingCardCountry	Désactiver la règle Pays de livraison et de la carte
SimilarityDeliveryBillingCountry	Désactiver la règle Pays de livraison et de facturation
SimilarityDeliveryBillingPostalCode	Désactiver la règle Codes postaux de livraison et de facturation
SimilarityDeliveryCardCountry	Désactiver la règle Pays de livraison et de la carte
SimilarityDeliveryIbanCountry	Désactiver la règle Pays de livraison et de l’IBAN
SimilarityIpCardCountry SimilityIpCard (déprécié)	Désactiver la règle Pays de la carte et de l’adresse IP
SimilarityIpIbanCountry	Désactiver la règle Pays de l’IBAN
SimilarityPhoneIbanCountry	Désactiver la règle Pays du numéro de téléphone et de l’IBAN
SystematicAuthorizationCard	Désactiver la règle Carte à autorisation systématique
VelocityCard	Désactiver la règle Encours carte
VelocityCustomerId	Désactiver la règle Encours par identifiant client
VelocityIban	Désactiver la règle Encours par IBAN
VelocityIp	Désactiver la règle Encours par adresses IP
VelocityMandate	Désactiver la règle Encours par mandat
WhiteBic	Désactiver la règle Liste blanche de BIC
WhiteBinCard	Désactiver la règle Liste blanche de plages de BIN
WhiteCard	Désactiver la règle Liste blanche de numéros de carte
WhiteCustomerId	Désactiver la règle Liste blanche d’identifiants de clients
WhiteCustomerName	Désactiver la règle Liste blanche de noms de clients
WhiteEmail	Désactiver la règle Liste blanche d’adresses e-mail
WhiteIban	Désactiver la règle Liste blanche d’IBAN
WhiteBinCard	Désactiver la règle Liste blanche de plages de BIN
WhiteIp	Désactiver la règle Liste blanche d’adresses IP
WhiteMandate	Désactiver la règle Liste blanche de mandats
WhitePhoneNumber	Désactiver la règle Liste blanche de numéros de téléphone
WhitePostalCode	Désactiver la règle Liste blanche de codes postaux
3DSStatus	Désactiver la règle Authentification 3-D Secure
All	Désactiver tous les règles

Annexe 2 : couleurs


Valeurs	Description
Empty	Aucun contrôle.
BLACK	Couleur du score noire.
GREEN	Couleur du score verte.
ORANGE	Couleur du score orange.
RED	Couleur du score rouge.
WHITE	Couleur du score blanche.

Annexe 3 : réputations d'adresse IP

Une adresse IP peut avoir une ou plusieurs de ces réputations si elle a déjà été récemment concernée par l’un des cas suivants :


Adresse IP utilisée pour :	Description
Botnets	Les botnets sont des virus qui infectent un grand nombre de machines afin de : relayer du spam pour du commerce illégal ou pour de la manipulation d'information (par exemple des cours de bourse) ; réaliser des opérations de phising ; identifier et infecter d’autres machines par diffusion de virus et de programmes malveillants (malwares) ; participer à des attaques groupées (DDoS) ; générer de façon abusive des clics sur un lien publicitaire au sein d’une page web ; capturer de l’information sur les machines compromises (vol puis revente d'information) ; exploiter la puissance de calcul des machines ou effectuer des opérations de calcul distribué notamment pour cassage de mots de passe ; mener des opérations de commerce illicite en gérant l'accès à des sites de ventes de produits interdits ou de contrefaçons via des techniques de fast-flux, simple ou double-flux ou RockPhish.
Déni de service	Une attaque par déni de service est une attaque informatique ayant pour but de rendre indisponible un service, d'empêcher les utilisateurs légitimes d'un service de l'utiliser. Il peut s'agir de : l’inondation d’un réseau afin d'empêcher son fonctionnement ; la perturbation des connexions entre deux machines, empêchant l'accès à un service particulier ; l'obstruction d'accès à un service à une personne en particulier ; également le fait d'envoyer des milliards d'octets à une box internet.
Phishing	Le Phishing consiste, pour les fraudeurs, à récupérer des informations confidentielles (financières, d'identification sur le système de votre entreprise etc.) grâce à un spam qui met en oeuvre une copie miroir frauduleuse et piégée d'une page réelle.
Proxy anonymes	Un Proxy anonyme permet de naviguer anonymement. En général, c'est un serveur/proxy qui masque les informations personnelles (adresse IP, système d'exploitation, navigateur...) aux sites visités.
Scanners	Permet de savoir si plusieurs machines ont la même adresse IP car ils appartiennent au même réseau.
Source de Spam	Il s'agit en général d'envois d’e-mail en grande quantité effectués à des fins publicitaires.
Attaques web	Les vulnérabilités des applications web peuvent être catégorisées de la manière suivante : vulnérabilités du serveur web. Ce type de cas est de plus en plus rare car au fur et à mesure des années les principaux développeurs de serveurs web ont renforcé leur sécurisation ; manipulation des URL, consistant à modifier manuellement les paramètres des URL afin de modifier le comportement attendu du serveur web ; exploitation des faiblesses des identifiants de session et des mécanismes d'authentification ; injection de code HTML et Cross-Site Scripting ; injection de commandes SQL.
Sources infectées	Adresses IP émettant des requêtes HTTP avec un indice de réputation faible ou qui sont des sites malveillants connus.
Exploits Windows	Adresses IP ayant exploité des trous de sécurité contre les ressources Windows en utilisant des navigateurs, des programmes, des fichiers téléchargés, des scripts ou des vulnérabilités du système d'exploitation.

Annexe 4 : codes pays alphabétiques ISO 3166


ABW	Aruba	AFG	Afghanistan	AGO	Angola
AIA	Anguilla	ALB	Albanie	AND	Andorre
ANT	Antilles Néerlandaises	ARE	Emirats arabes unis	ARG	Argentine
ARM	Arménie	ASM	Samoa américaines	ATA	Antarctique
ATF	Terres australes françaises	ATG	Antigua et Barbuda	AUS	Australie
AUT	Autriche	AZE	Azerbaïdjan	BDI	Burundi
BEL	Belgique	BEN	Bénin	BFA	Burkina faso
BGD	Bangladesh	BGR	Bulgarie	BHR	Bahreïn
BHS	The Bahamas	BIH	Bosnie Herzégovine	BLR	Bélarus
BLZ	Belize	BMU	Bermudes	BOL	Bolivie
BRA	Brésil	BRB	Barbade	BRN	Brunéi Darussalam
BTN	Bhoutan	BVT	Bouvet, île	BWA	Botswana
CAF	Centrafricaine, République	CAN	Canada	CCK	Cocos (Keeling), îles
CHE	Suisse	CHL	Chili	CHN	Chine
CIV	Côte d'Ivoire	CMR	Cameroun	COG	Congo
COK	Cook, îles	COL	Colombie	COM	Comores
CPV	Cap-Vert	CRI	Costa rica	CUB	Cuba
CXR	Christmas, îles	CYM	Caïmanes, îles	CYP	Chypre
CZE	Tchèque, république	DEU	Allemagne	DJI	Djibouti
DMA	Dominique	DNK	Danemark	DOM	Dominicaine, république
DZA	Algérie	ECU	Equateur	EGY	Egypte
ERI	Erythrée	ESH	Sahara occidental	ESP	Espagne
EST	Estonie	ETH	Ethiopie	FIN	Finlande
FJI	Fidji	FLK	Falkland, îles (Malouines)	FRA	France
FRO	Féroé, îles	FSM	Micronésie, Etats fédérés de	ATM	Gabon
GBR	Royaume-uni	GEO	Géorgie	GHA	Ghana
GIB	Gibraltar	GIN	Guinée	GLP	Guadeloupe
GMB	Gambie	GNB	Guinée-Bissau	GNQ	Guinée équatoriale
GRC	Grèce	GRD	Grenade	GRL	Groenland
GTM	Guatemala	GUF	Guyane française	GUM	Guam
GUY	Guyana	HKG	Hong-kong	HMD	Heard, île et McDonald, îles
HND	Honduras	HRV	Croatie (nom local: Hrvatska)	HTI	Haïti
HUN	Hongrie	IDN	Indonésie	IND	Inde
IOT	Océan indien, Territoire britannique de l'	IRL	Irlande	IRN	Iran, république islamique d'
IRQ	Iraq	ISL	Islande	ISR	Israël
ITA	Italie	JAM	Jamaïque	JOR	Jordanie
JPN	Japon	KAZ	Kazakhstan	KEN	Kenya
KGZ	Kirghizistan	KHM	Cambodge	KIR	Kiribati
KNA	Saint Kitts and Nevis	KOR	Corée, République de	KWT	Koweït
LAO	Lao, République démocratique populaire	LBN	Liban	LBR	Libéria
LBY	Libyenne, Jamahiriya arabe	LCA	Saint Lucia	LIE	Liechtenstein
LKA	Sri Lanka	LSO	Lesotho	LTU	Lituanie
LUX	Luxembourg	LVA	Lettonie	MAC	Macao
MAR	Maroc	MCO	Monaco	MDA	Moldova, République de
MDG	Madagascar	MDV	Maldives	MEX	Mexique
MHL	Marshall, îles	MKD	Macédoine, l'ex-république yougoslave de	MLI	Mali
MLT	Malte	MMR	Myanmar	MNG	Mongolie
MNP	Mariannes du nord, îles	MOZ	Mozambique	MRT	Mauritanie
MSR	Montserrat	MTQ	Martinique	MUS	Maurice
MWI	Malawi	MYS	Malaisie	MYT	Mayotte
NAM	Namibie	NCL	Nouvelle-Calédonie	NER	Niger
NFK	Norfolk, île	NGA	Nigéria	NIC	Nicaragua
NIU	Niué	NLD	Pays-bas	NOR	Norvège
NPL	Népal	NRU	Nauru	NZL	Nouvelle-Zélande
OMN	Oman	PAK	Pakistan	PAN	Panama
PCN	Pitcairn	PER	Pérou	PHL	Philippines
PLW	Palaos	PNG	Papouasie-Nouvelle-Guinée	POL	Pologne
PRI	Porto Rico	PRK	Corée, République populaire démocratique de	PRT	Portugal
PRY	Paraguay	PYF	Polynésie française	QAT	Qatar
REU	Réunion	ROM	Roumanie	RUS	Russie, Fédération de
RWA	Rwanda	SAU	Arabie saoudite	SDN	Soudan
SEN	Sénégal	SGP	Singapour	SGS	Géorgie du sud et les îles Sandwich du sud
SHN	Sainte-Hélène	SJM	Svalbard et île Jan Mayen	SLB	Salomon, îles
SLE	Sierra leone	SLV	El Salvador	SMR	Saint-Marin
SOM	Somalie	SPM	Saint-Pierre-et-Miquelon	STP	Sao Tomé-et-Principe
SUR	Suriname	SVK	Slovaquie	SVN	Slovénie
SWE	Suède	SWZ	Eswatini (anciennement Swaziland)	SYC	Seychelles
SYR	Syrienne, république arabe	TCA	Turks et Caïques, îles	TCD	Tchad
TGO	Togo	THA	Thaïlande	TJK	Tajikistan
TKL	Tokelau	TKM	Turkménistan	TLS	Timor-Leste
TON	Tonga	TTO	Trinité-et-Tobago	TUN	Tunisie
TUR	Turquie	TUV	Tuvalu	TWN	Taïwan, Province de Chine
TZA	Tanzanie, République-unie de	UGA	Ouganda	UKR	Ukraine
UMI	Iles mineures éloignées des Etats-Unis	URY	Uruguay	USA	Etats-Unis
UZB	Ouzbékistan	VAT	Saint-Siège (Etat de la cité du Vatican)	VCT	Saint Vincent et les Grenadines
VEN	Vénézuéla	VGB	Iles Vierges britanniques	VIR	Iles Vierges des Etats-Unis
VNM	Viet Nam	VUT	Vanuatu	WLF	Wallis et Futuna
WSM	Samoa	YEM	Yémen	YUG	Yougoslavie
ZAF	Afrique du Sud	ZAR

Plus de docs

Solution Business Score

Introduction

À qui s'adresse ce document

Vue d'ensemble

Accéder au MEX

Comprendre la lutte contre la fraude

Définition d'une règle antifraude

Qu'est-ce qu'une règle antifraude ?

Règle positive et règle négative

Règle positive

Règle négative

Configuration avancée

Modes d'exécution et leurs impacts sur l'acceptation

Mode pré-autorisation

Mode pré-authentification

Définition d'un profil antifraude

Qu'est-ce qu'un profil antifraude ?

Profils moyen de paiement et profil par défaut

Paramétrage pondéré ou décisif des règles

Paramétrage pondéré

Paramétrage décisif

Définition des plages rouge, orange et verte

Déroulement et résultat d'un profil antifraude

Débrayage dynamique des règles

Surcharge dynamique des règles

Calcul du score global

Résultat global

Gestion du résultat orange

Restitution du résultat des règles

Mode pré-autorisation

Mode pré-authentification

Limites d'utilisation

Moyens de paiement

Opérations

Paiement en n fois

Transfert de données dans la requête

Mode d'exécution et règles

Liste des règles

Description et mise en œuvre des règles

Règles de géolocalisation : adresse et pays

Pays de la carte

Description de la règle

Conditions d'utilisation

Restitution du résultat

Surcharge dynamique

Débrayage dynamique

Pays de l'adresse IP

Description de la règle

Conditions d'utilisation

Restitution du résultat

Surcharge dynamique

Débrayage dynamique

Pays de la carte et de l'adresse IP

Description de la règle

Conditions d'utilisation

Restitution du résultat

Surcharge dynamique

Débrayage dynamique

Pays de livraison et de facturation

Description de la règle

Conditions d'utilisation

Restitution du résultat

Surcharge dynamique

Débrayage dynamique

Codes postaux de livraison et de facturation

Description de la règle

Conditions d'utilisation

Restitution du résultat

Surcharge dynamique

Débrayage dynamique

Pays de livraison et de la carte

Description de la règle

Conditions d'utilisation

Restitution du résultat

Surcharge dynamique

Débrayage dynamique

Pays de facturation et de la carte

Description de la règle

Conditions d'utilisation