Table of Contents

Introduction

Cette documentation a pour objectif de fournir une compréhension claire et complète des mécanismes de lutte contre la fraude mis en place par Axepta BNP Paribas. Elle couvre les règles de vélocité, les listes blanches et noires, ainsi que les bonnes pratiques pour sécuriser les transactions.

Règles de Vélocité

Règles de Géolocalisation

Les règles de géolocalisation permettent de vérifier l'origine des transactions pour détecter les activités suspectes.

Pays d’émission de la carte

• Objectif : Vérifier que la carte utilisée pour la transaction provient d'un pays autorisé par le marchand.
• Action : Bloquer les transactions provenant de pays non autorisés.

Pays d’origine de l’adresse IP

• Objectif : Vérifier que l'adresse IP utilisée pour la transaction provient d'un pays autorisé par le marchand.
• Action : Bloquer les transactions provenant de pays non autorisés.

Règles de Vélocité

Les règles de vélocité permettent de limiter le nombre de transactions effectuées dans un délai donné pour éviter les abus.

Nombre de transactions par adresse IP

• Objectif : Limiter le nombre de transactions effectuées depuis une même adresse IP.
• Seuil par défaut : 4 transactions en 24 heures.

Nombre de transactions par carte

• Objectif : Limiter le nombre de transactions effectuées avec une même carte.
• Seuil par défaut : 4 transactions en 24 heures.

Nombre de cartes par adresse IP

• Objectif : Limiter le nombre de cartes utilisées depuis une même adresse IP.
• Seuil par défaut : 3 cartes en 24 heures.

Paramètres de transaction

• Objectif : Limiter le nombre de transactions avec les mêmes identifiants (ID de transaction, numéro de référence, adresse électronique).
• Seuil par défaut : À définir selon les besoins du marchand.

Règles de Vélocité – Combinatoire

Les règles combinatoires permettent de limiter les transactions en fonction de plusieurs critères simultanés.

Vérification de l’adresse IP et du montant

• Objectif : Limiter le montant total des transactions effectuées depuis une même adresse IP.
• Seuil par défaut : 3000 euros en 24 heures.

Vérification du nombre de cartes et du montant

• Objectif : Limiter le montant total des transactions effectuées avec une même carte.
• Seuil par défaut : XX euros en 24 heures.

Listes Blanches et Listes Noires

Liste Blanche Secure Pay

Usage

• Permet de contourner les règles de vélocité pour des cartes ou adresses IP spécifiques.

Exemple

• Une carte ajoutée à la liste blanche peut être utilisée plus de 4 fois en 24 heures.

Périmètre

• Numéro de carte
• Adresse IP

Durée du blocage

• Pas de limite.

Paramétrage & Gestion

• Back-Office : Consultation, ajout, suppression.
• Détail d’une transaction : Ajout d’un numéro de carte ou d’une adresse IP.

Liste Noire Secure Pay

Usage

• Bloquer automatiquement les données ayant atteint les seuils définis dans les règles de vélocité.

Exemple

• Une carte utilisée 5 fois en 24 heures est ajoutée à la liste noire pour 24 heures.

Périmètre

• Numéro de carte
• Adresse IP
• Paramètres
• Combinaisons (adresse IP + numéro de carte, adresse IP + montant, montant + numéro de carte)

Durée du blocage

• 24 heures.

Paramétrage & Gestion

• Back-Office : Consultation, suppression.
• Déblocage ........

Liste Blanche

Usage

• Restreindre les transactions à des cartes spécifiques (BIN ou pays d’émission).

Exemple

• Accepter uniquement les cartes d'une plage de BIN spécifique.

Périmètre

• BIN de carte
• Pays d’émission

Durée du blocage

• Pas de limite.

Paramétrage & Gestion

• Back-Office : Consultation, ajout, suppression.
• Demande au support ........

Liste Noire 

Usage

• Bloquer systématiquement les transactions effectuées avec des cartes, tokens, IBAN ou pays d’émission frauduleux.

Exemple

• Bloquer un token spécifique.

Périmètre

• Cartes ou tokens
• IBAN
• Pays d’émission

Durée du blocage

• Pas de limite.

Paramétrage & Gestion

• Back-Office : Consultation, ajout, suppression.
• Détail d’une transaction : Ajout d’une carte dans la liste noire.
• Demande au support .....

Conclusion

Cette documentation fournit une vue d'ensemble des mécanismes de lutte contre la fraude mis en place par Axepta BNP Paribas. En suivant ces règles et en utilisant les outils disponibles, les marchands peuvent sécuriser leurs transactions et minimiser les risques de fraude

The DSP2 (Second Payment Services Directive) is a European directive aimed at encouraging innovation, improving consumer protection, and enhancing the security of payment services. The RTS (Regulatory Technical Standards) related to DSP2 mandates the use of the authentication process for all e-commerce payments initiated by the cardholder. The goal is to meet the requirements of strong customer authentication (Strong Customer Authentication - SCA) to minimize risk for merchants while simplifying and streamlining the user journey.

Glossary on 3DSV2

Strong Customer Authentication (SCA)

Strong customer authentication (SCA) is a regulatory requirement introduced under DSP2. During an online payment, strong two-factor authentication may be requested from the cardholder, confirming that the person making the payment is indeed the cardholder. An authentication is considered strong when it combines two of the following three authentication factors:

• Something known to the cardholder (a password, a secret code, etc.)

• Something possessed by the cardholder (mobile phone via the bank's application, a bank card, etc.)

• Something inherent to the cardholder (a fingerprint, voice recognition, etc.)

Frictionless

The merchant has the option to request an exemption from cardholder authentication during online payment. The final decision is left to the issuing bank.

In a "frictionless" transaction, passive authentication of the cardholder is performed without any action on their part. In summary, this is a process that reduces buyer intervention during the payment process.

In the case of a frictionless transaction, liability shift depends on the card brand. For more details, refer to our documentation on Liability Shift and 3D-Secure Matrices.

Merchant Preferences: no Preference / challenge / mandate

The merchant can request the issuer to grant or not grant an exemption from strong authentication. Several options are available:

• The merchant takes no action (no preference): The choice of exemption is left to the issuer.

• The merchant requests strong authentication (challenge):

  • Mandatory (mandate): The issuer must authenticate the buyer (e.g., for the first transaction of a subscription).

  • Preferred (request): The merchant wishes to authenticate the buyer. The final choice remains with the issuer.

• The merchant requests an exemption from strong authentication (no Challenge - Frictionless): The issuer will accept or reject the merchant's request based on the information provided (data to be transmitted).

Liability shift depends on the merchant's choice and the card brand. For more details, refer to our documentation on Liability Shift and 3D-Secure Matrices.

Soft Decline

In the case of a transaction made without SCA (3DS Strong Authentication), issuers may respond with a Soft Decline. This means that the transaction authorization request is refused by the issuer; however, the same transaction can be initiated again. The main reason why Soft Declines occur in the context of 3D Secure is that issuers do not accept SCA exemptions requested by the merchant when they request a payment without prior authentication.

With the automated Soft Decline management feature, based on configuration, the Axepta BNP Paribas platform will react to the Soft Decline response by automatically restarting the payment by forcing strong authentication. The Axepta BNP Paribas platform will then automatically initiate a new payment on behalf of the merchant and include the 3-D Secure flow.

Important:

• From the user's perspective, customers will notice no difference and will not need to re-enter their credit card details. The entire process is managed by the Axepta BNP Paribas platform.

• Please note that this solution is not available for server-to-server integrations, as the Axepta BNP Paribas platform does not control the client (browser) to initiate the 3-D Secure process. For server-to-server integration, the merchant is responsible for reactivating the payment with the 3-D Secure flow and, above all, forcing SCA via the available JSON parameter threeDSPolicy (challengePreference = mandateChallenge).

Transactions Not Subject to SCA

Under this new regulation, some payment cases may be exempt from strong customer authentication:

• Recurring payments (MIT - Merchant Initiated Transactions): The initial payment requires strong authentication; however, subsequent payments will be exempt. In the case of a change in the subscription amount, the buyer will need to go through a strong authentication procedure again.

• MoTo (Mail Orders and Telephone Orders) transactions: This type of transaction is not considered an electronic payment.

Exemptions

The merchant can request an exemption from authentication for some transactions subject to strong authentication:

• Low-value transactions (less than €30): Banks must, however, request authentication if the exemption has been used five times since the last successful authentication of the cardholder or if the sum of previously exempted payments exceeds €100.

• Low-risk transactions (TRA: Transaction Risk Analysis): An exemption from the strong authentication obligation may be granted. For this, prior agreement from the acquirer is required (based on a real-time risk analysis of each operation).

Promoting 'Frictionless' Payments

Several parameters can be added to the payment request to promote frictionless payments. For more details, refer to our documentation on Frictionless Payments and Exemptions.