Retour sur l’obligation d’authentification forte de la DSP2

Alexandre Mandil
février 4 2020

La révolution numérique et la globalisation des échanges ont considérablement modifié les habitudes de consommation et de paiement des européens. Toutefois, l’apparition de nouveaux types de services de paiement et la croissance rapide des paiements électroniques et mobiles a mis en exergue les limites du cadre légal européen reposant principalement sur la directive 2007/64/CE (DSP). Dans un document du 11 janvier 2012 intitulé « Vers un marché européen intégré des paiements par carte, par internet et par téléphone mobile », la Commission européenne a montré ces limites et l’insécurité juridique en résultant pour certains acteurs désireux de proposer de nouvelles offres de paiement innovantes.

Abrogeant la directive 2007/64/CE, la Directive européenne 2015/2366 (DSP2), adoptée le 25 novembre 2015 et entrée en vigueur le 13 janvier 2018, a été transposée en droit français dans le Code monétaire financier (CMF) par l’Ordonnance n°2017-1252 du 9 août 2017.

Cette nouvelle règlementation poursuit quatre objectifs principaux :

  • Elle cherche à améliorer les règles européennes existantes en matière de paiements électroniques en tenant compte de l’émergence de services de paiement innovants, comme ceux par internet et téléphone mobile.
  • Elle vise à ouvrir les marchés des paiements à de nouveaux acteurs pour renforcer la concurrence, permettre plus de choix et des prix plus intéressants pour les consommateurs et améliorer l’intégration du marché européen des paiements. Elle consacre notamment les prestataires de services d’information sur les comptes[1] et de services d’initiation de paiement[2].
  • Elle renforce les droits des consommateurs, notamment en matière de transparence, de responsabilité et de remboursement.
  • Enfin, elle instaure des exigences de sécurité plus strictes pour les paiements électroniques et la protection des données financières des consommateurs afin de réduire les risques de fraude, dans un contexte de forte croissance des paiements par internet et par téléphone mobile.

Ce dernier objectif de réduction des risques de fraude, proclamé au considérant 95 de la DSP2, est en particulier incarné par son article 97[3] qui consacre le principe de l’obligation pour les prestataires de services de paiement (PSP), tels que définis à l’article 4.11 de la DSP2 (et au Livre V du CMF) et notamment les établissements de paiement, les établissements de crédit et les émetteurs de monnaie électronique, d’authentifier fortement leurs clients utilisateurs de services de paiement, que ces derniers soient une personne physique ou morale[4].

Comme prévu par l’article 98 de la DSP2, le Règlement délégué (UE) 2018/389 de la Commission du 27 novembre 2017 (RTS SCA) élaboré par l’ABE puis publié le 13 mars 2018 par la Commission européenne est venu préciser cette obligation d’authentification forte et en préciser les modalités d’application (1). Cette obligation est destinée à s’appliquer à l’ensemble des opérations entrant dans le champ d’application de la DSP2 (2). Toutefois, les RTS SCA prévoient plusieurs dérogations à ce principe d’authentification forte pour les opérations présentant par nature un faible risque de fraude (3).

1. Qu’est-ce que l’authentification forte

En matière de paiement, l’authentification est une procédure visant à vérifier l’identité d’un utilisateur de services de paiement ayant donné son consentement à l’opération de paiement et/ou la validité de l’utilisation d’un instrument de paiement spécifique.

Pour être considérée comme forte et ainsi répondre aux exigences de la DSP2, la procédure d’authentification doit respecter plusieurs conditions cumulatives prévues par le législateur.

1.1. Les éléments de l’authentification forte

L’authentification forte doit reposer sur l’utilisation d’au moins deux éléments appartenant aux trois catégories que sont :

Ces éléments doivent être indépendants en ce sens que la compromission de l’un ne doit pas remettre en question la fiabilité des autres, notamment lorsque l’un de ces éléments est utilisé au travers d’un dispositif multifonctionnel, à savoir un dispositif tel une tablette ou un téléphone mobile, qui peut servir tant pour donner l’instruction d’effectuer le paiement que pour le processus d’authentification[5].

1.1.1. OTP SMS

La condition de l’indépendance a donné lieu à une interprétation restrictive de l’ABE dès juin 2018, plusieurs fois renouvelée depuis et suivie par l’OSMP et à la remise en cause de la solution d’authentification forte la plus utilisée par les acteurs du e-commerce et qui avait pourtant permis de massivement faire baisser la lutte contre la fraude aux paiements par carte sur internet. S’appuyant sur le protocole 3DS sécure V1, cette solution reposait sur deux facteurs d’authentification : la possession de la carte (le payeur renseignant les informations y figurant) ainsi que sur celle du téléphone du payeur (le payeur renseignant le code envoyé par SMS sur son appareil), également dénommée SMS OTP[6].

Cette remise en cause est intervenue en trois étapes :

Toutefois, soucieux de ne pas pénaliser les acteurs du e-commerce et les consommateurs, l’OSMP a proposé en juillet 2019 un plan de migration élaboré avec le concours de l’ensemble des acteurs impliqués (banques, commerçants, systèmes de paiement par carte et associations de consommateurs) et conforme aux orientations de l’ABE. Ce plan prévoit le remplacement progressif du recours aux codes SMS à usage unique pour la protection des paiements en ligne par des solutions plus avancées, reposant par exemple sur la saisie d’un code confidentiel ou d’une empreinte biométrique au travers de l’application mobile de banque en ligne.

1.1.2. Biométrie

Cette position restrictive des autorités à l’encontre de la méthode SMS OTP a ainsi conduit de nombreuses banques françaises et européennes à accélérer le déploiement de nouvelles solutions biométrique (validation par empreinte digitale, par reconnaissance faciale ou encore reconnaissance de l’arborescence veineuse…), des solutions sur lesquelles elles travaillent depuis des années et bien souvent déjà largement implantées en Asie. Pour satisfaire à l’exigence des deux éléments, ces solutions biométriques se combinent en pratique avec un dispositif liant l’application mobile qui constitue un élément de possession s’ajoutant à celui de l’inhérence.

D’après des prédictions réalisées par Juniper Research, le nombre de paiements mobiles authentifiés via la biométrie serait ainsi passé de 600 millions en 2016 à deux milliards en 2017 avec une prévision de plus de 18 milliards d’opérations d’ici 2021 ! Ces solutions biométriques reposent toutefois sur des données à caractère personnel sensibles protégées par l’article 9 du RGPD qui, comme le rappelle la CNIL, contrairement à un mot de passe, peuvent ne pas être communiquées consciemment et ne peuvent pas être modifiées, y compris en cas de compromission…

1.2. La génération d’un code d’authentification

L’authentification fondée sur deux ou plusieurs éléments appartenant aux trois catégories mentionnées précédemment doit ensuite donner lieu à la génération d’un code d’authentification directement lié à l’opération pour laquelle l’authentification est requise.

Ce code d’authentification doit être :

  • Infalsifiable, que ce soit dans son intégralité ou par la divulgation de l’un des éléments sur la base desquels il a été généré ;

Comme le précisent les RTS SCA, dans les cas ou un payeur a donné son consentement à l’exécution d’une série d’opérations de paiement électronique à distance en faveur d’un ou de plusieurs bénéficiaires, le code d’authentification doit être spécifique au montant total de la série d’opérations de paiement et aux bénéficiaires désignés.

  • Limité dans le temps : les RTS SCA prévoient ainsi que le délai maximal d’inactivité du payeur, une fois que celui-ci s’est authentifié pour accéder à son compte de paiement en ligne, ne peut dépasser pas cinq minutes.

En revanche, les autorités européennes ont tenu à assurer une certaine neutralité sur le plan des technologies utilisée pour la mise en œuvre des codes d’authentification en se gardant d’en promouvoir une en particulier (génération et validation de mots de passe à usage unique, signatures numériques, moyens de validation basés sur la cryptographie…).

1.3. Les exigences de sécurité et de confidentialité

Enfin, la procédure d’authentification forte doit être conçue de manière à protéger la confidentialité et l’intégrité des données d’authentification, des données de sécurité personnalisées et des données relatives à l’opération elle-même (montant de l’opération, bénéficiaire…), c’est-à-dire, sécuriser les sessions de communication de ces données et prévoir des procédures visant à déceler les tentatives de manipulation par des tiers non autorisés.

L’article 4 des RTS SCA détaille en outre les cas dans lesquels le nombre de tentatives d’authentification infructueuses consécutives conduit à un blocage de la procédure d’authentification.

2. Dans quels cas l’obligation d’authentification forte s’applique-t-elle ?

Nouveauté de la DSP2, l’obligation pour les PSP d’authentifier fortement leurs clients utilisateurs de services de paiement n’est toutefois pas absolue dans la mesure ou seules les opérations entrant dans le champ d’application de la DSP2 et mentionnée par son article 97 sont concernées.

2.1. Ratione temporis

Les dispositions des RTS SCA relatives à l’authentification forte sont entrées en vigueur le 14 septembre 2019[7]. L’ensemble des acteurs concernés est par conséquent tenu de s’y conformer depuis cette date.

Toutefois, consciente des importants difficultés des acteurs du paiement, en particulier en matière de paiement par carte, à se conformer aux RTS SCA dans les délais impartis, l’ABE a annoncé le 21 juin 2019 qu’elle allait permettre aux autorités nationales compétentes de définir une période de tolérance pendant laquelle les autorités ne devraient pas sanctionner les acteurs concernés à condition qu’ils respectent le plan de migration défini par l’autorité nationale compétente. Le 21 septembre 2019, l’OSMP a ainsi rendu public son plan de migration applicable à la place française. Prenant acte du fait que les échanges relatifs à l’authentification des paiements par carte sur internet s’effectuent au travers d’une architecture informatique de place appuyée par le protocole 3D-Secure et que l’implémentation actuelle de ce protocole (3D-Securev1) ne permet pas d’appliquer de manière satisfaisante les dispositions des RTS SCA, le plan prévoit une période de migration progressive qui fera l’objet d’un suivi mensuel par l’OSMP.

Ce plan prévoyait à l’origine une date limite fixée à mars 2021. Cependant, dans un souci d’harmonisation au niveau européen entre les plans de migration des différentes autorité nationales, l’ABE, dans un avis du 16 octobre 2019, a fixé cette date limite au 31 décembre 2020, ce dont s’est félicité l’OSMP dans un communiqué du 28 octobre 2019. 

En revanche, consciente de ne pas être compétente pour décider du report d’un disposition prévue dans une directive européenne, l’ABE insiste explicitement dans ce même avis du 16 octobre 2019 sur le fait qu’il ne s’agit que d’une tolérance dans les contrôle des autorités mais que tout PSP ne se conformant aux RTS SCA depuis le 14 septembre 2019 est en infraction avec la loi[8]. Elle précise que, le régime de responsabilité prévu à l’article 74 de la DSP2 s’appliquant sans délai, les PSP sont par conséquent responsables des opérations de paiement non autorisées par le payeur pour lesquelles aucune authentification forte n’a été demandée[9].

L’objectif de l’ABE est donc clairement de rappeler que, tout en bénéficiant d’une politique de tolérance des autorités de contrôle en matière de sanction à condition que les plans nationaux de migration soient suivis, les PSP ont tout intérêt à appliquer sans délai les dispositions des RTS SCA pour ne pas voir leur responsabilité engagée par leurs clients.

2.2. Ratione loci

Les RTS SCA s’appliquent aux opérations de paiement réalisées au sein de l’Union européenne et  de l’Espace Economique Européen, lorsque les PSP intervenant dans l’opération  y sont situés, conformément au articles 2 de la DSP2 et L133-1 du CMF. L’ABE a eu l’occasion de préciser sa position lorsqu’un seul PSP est situé dans l’EEE (paiements on leg), en recommandant aux PSP, dans son « Opinion Paper » publié le 13 juin 2018, de fournir leurs « meilleurs efforts ». L’ABE a ensuite affinée sa position en précisant que :

  • Lorsque seul le PSP du bénéficiaire est situé hors de l’EEE (« one leg in transaction »), le PSP du payeur doit authentifier fortement le payeur. Lorsqu’il ne peut techniquement pas imposer l’authentification forte, il est tenu d’évaluer l’opération et décider de la bloquer ou de rembourser le payeur dans l’hypothèse où celle-ci n’aurait pas été autorisée.
  • Lorsque seul le PSP du payeur est situé hors de l’EEE (« one leg out transaction« ), il n’est pas soumis à la DSP2. Le PSP du bénéficiaire doit lui en revanche être en mesure d’accepter l’authentification forte.

La localisation du payeur ou du bénéficiaire (un commerçant par exemple) n’importe donc pas.

2.3. Ratione materiae

Le principe de l’authentification forte concerne des opérations qui vont au-delà des paiements. En effet, l’article 97.1 de la DPS2 (article L133-44 du CMF) prévoit que les PSP sont tenus d’authentifier fortement leur client lorsque ce dernier :

Le deuxième critère (initiation par le payeur d’une opération de paiement électronique) peut être lui-même être décomposé en deux conditions cumulatives : une authentification forte sera obligatoire à condition que celui qui initie l’opération de paiement[10] soit le payeur ET qu’il s’agisse d’un paiement électronique.

2.3.1. L’initiation de l’opération de paiement par le payeur

Cette première condition s’explique par le fait que, depuis la DSP1 et l’ordonnance de transposition n° 2009-866 du 15 juillet 2009, le cadre juridique régissant les services de paiement n’est plus centré sur les instruments de paiement mais sur des cinématiques, c’est-à-dire sur une analyse pratique de la manière dont un ordre de paiement est initié. En effet, une opération de paiement[11] peut être initiée[12] :

  • Directement par le payeur, « qui donne un ordre de paiement à son PSP ». Cette cinématique correspond notamment au cas des virements (SCT).
  • Par le payeur, « qui donne un ordre de paiement par l’intermédiaire du bénéficiaire qui, après avoir recueilli l’ordre de paiement du payeur, le transmet au PSP du payeur, le cas échéant, par l’intermédiaire de son propre PSP ». C’est en pratique le cas le plus fréquent de paiement par carte.
  • Par le bénéficiaire, « qui donne un ordre de paiement au PSP du payeur, fondé sur le consentement donné par le payeur au bénéficiaire et, le cas échéant, par l’intermédiaire de son propre PSP ». C’est notamment le cas des prélèvements (SDD).

La cinématique applicable à une opération de paiement sera ainsi déterminante pour identifier si une authentification forte du payeur est obligatoire ou non :

  • Elle sera obligatoire lorsque l’opération de paiement est initiée par le payeur, soit directement, soit par l’intermédiaire du bénéficiaire[13].
  • Elle sera facultative lorsque l’opération de paiement a été initiée par le bénéficiaire (Merchant Initiated Transactions – MIT), c’est-à-dire lorsque le payeur n’est physiquement pas intervenu, bien qu’il ait légalement donné son consentement[14].

L’initiation d’une opération de paiement par un bénéficiaire correspond généralement au cas d’un prélèvement (SDD), défini comme telle à l’article 4.23 de la DSP2 et par le Règlement n° 260/2012. Dès lors, ces derniers ne sont donc pas soumis à l’obligation de l’authentification forte. En revanche, lorsque le mandat donné au bénéficiaire par le payeur d’initier ces opérations est fourni à distance, la mise en place d’un tel mandat est soumise à une authentification forte, car cette action peut impliquer un risque de fraude au paiement au sens de l’article 97.1 c) de la DSP2.

Les opérations de paiement par carte impliquent en revanche le plus souvent une initiation par le payeur (en rentrant sa carte dans un TPE ou en tapant les informations de sa carte en ligne par exemple) puis une transmission de l’ordre de paiement par le bénéficiaire au PSP du payeur via son propre PSP. Les opérations par carte sont donc le plus souvent considérées comme des opérations de paiement initiées par le payeur par l’intermédiaire du bénéficiaire, ce que prévoient également les définition de la carte prévues dans le Règlement 2015/751.

Toutefois, la cinématique au cours de laquelle une opération de paiement est initiée directement par le bénéficiaire est explicitement envisagée dans le cadre d’une opération de paiement par carte par l’article 75 de la DSP2[15]. Elle a également été précisée par l’ABE le 1er mars 2019 qui indique qu’une opération de paiement liée à une carte peut être initiée par le bénéficiaire lorsque :

  • Le payeur a donné un mandat autorisant le bénéficiaire à initier une opération ou une série d’opérations au moyen d’un instrument de paiement qui a été émis pour être utilisé par le payeur pour initier des opérations de paiement, ET
  • Le mandat est fondé sur un accord entre le payeur et ce bénéficiaire pour la fourniture de produits ou services, ET
  • Ces opérations ne nécessitent aucune action spécifique du payeur pour déclencher l’initiation de l’opération.

Dans ce cas, si l’opération de paiement initiale, initiée par le payeur, devra faire l’objet d’une authentification forte, les opérations (récurrentes) initiées ultérieurement par le bénéficiaire en vertu d’un tel mandat seront considérées comme en dehors du champ d’application de l’article 97 de la DSP2. Dès lors, s’agissant de ces opérations ultérieures, l’authentification forte du payeur, en pratique extrêmement difficile à réaliser en raison de l’absence physique de ce dernier, sera facultative.

2.3.2. L’initiation d’une opération de paiement électronique

Outre la condition d’une initiation de l’opération par le payeur, l’article 97.1 b) de la DSP2 prévoit que l’opération devra faire l’objet d’une authentification forte lorsqu’il s’agit d’un paiement électronique, qu’il soit réalisé dans un environnement en ligne ou hors ligne.

Le Considérant 95 de la DSP2 précise à ce sujet que « tous les services de paiement proposés par voie électronique devraient être sécurisés » mais qu’en revanche, « il ne semble pas nécessaire de garantir le même niveau de protection aux opérations de paiement initiées et exécutées par des moyens autres que l’utilisation de plates-formes ou de dispositifs électroniques, telles que les opérations de paiement sur support papier, les ordres de paiement passés par courrier ou par téléphone » (MOTO – mail order/telephone order).

Cette précision a été reprise par l’OSMP et par l’ABE à propos des solutions de réponse vocale interactive (Interactive Voice Response – IVR).

2.3.3. Autres opérations de paiement non concernées par l’obligation d’authentification forte

Par ailleurs, certaines opérations de paiement ne sont pas concernées, que ce soit de par leur nature ou en raison d’une exclusion explicite du champ d’application de la DSP2 :

  • Ainsi, les opérations réalisées à partir d’instruments de paiement spécifiques qui ne peuvent être utilisés que de manière limitée, c’est à dire qu’ils ne permettent, soit d’acquérir des biens ou des services qu’au sein d’un réseau limité de prestataires de services, soit d’acquérir un éventail très limité de biens ou de services [16]. C’est notamment le cas des cartes utilisables exclusivement auprès de certaines enseignes ou des cartes permettant uniquement de régler des repas par exemple.
  • De plus, comme le précise le considérant 8 des RTS SCA, les paiements effectués par l’intermédiaire d’instruments de paiement anonymes ne sont, en raison même de leur nature, pas soumis à l’obligation d’authentification forte du client.

En revanche, aucune distinction n’est opérée par la DSP2 et les RTS SCA entre les cartes commerciales et non commerciales.

3. Dans quels cas un PSP peut-il déroger à l’obligation d’authentification forte

Si en principe un PSP devra en principe authentifier obligatoirement son client utilisateur du service de paiement préalablement à chaque opération entrant dans le champ d’application de la DSP2 et de son article 97, les RTS SCA prévoient de nombreuses dérogations à cette obligation.

L’existence de ces nombreuses dérogations s’expliquent par la volonté du législateur européen, de l’EBA et de la Commission européenne de ne pas pénaliser les acteurs économiques, en particulier du commerce électronique, en faisant peser sur elle cette obligation contraignante d’un point de vue économique et logistique, lorsque l’opération présente en pratique de faibles risques de fraude.

En effet, si comme il a été vu précédemment cette obligation ne pose pas de problème particulier en commerce de proximité, il n’en est pas de même en commerce électronique. En effet, le recours à une authentification fondée sur au moins deux facteurs conduit de nombreux consommateurs à abandonner leur achat en ligne (taux de conversion) alors même que les nouvelles méthodes d’analyse de risque en temps réel et de scoring pourraient limiter les risques de fraude sans toutefois impacter le parcours client.

En conséquence, les RTS SCA intègrent plusieurs dérogations autorisant le PSP à ne pas appliquer l’authentification forte de l’utilisateur du service de paiement. C’est le cas lorsque :

  • L’utilisateur du service de paiement accède à des informations sur son compte de paiement pour prendre connaissance du solde de ce dernier ou des opérations de paiement exécutées durant les 90 derniers jours, sans que des données de paiement sensibles soient divulguées. Cette dérogation ne s’applique toutefois pas au premier accès ou quand plus de 90 jours se sont écoulés depuis le dernier accès.
  • Le payeur initie un virement pour lequel le payeur et le bénéficiaire sont la même personne physique ou morale et que les deux comptes de paiement sont détenus auprès du même PSP gestionnaire du compte.
  • L’opération de paiement réalisée à distance correspond à un montant inférieur à 30 EUR et que :
    • le montant cumulé des précédentes opérations à distance non authentifiées ne dépassent pas 100 EUR ; ou que
  • L’opération de paiement a été initiée au moyen de procédures ou de protocoles de paiement dédiés qui sont uniquement mis à la disposition de payeurs qui ne sont pas des consommateurs (quel que soit le type d’instrument de paiement, y compris une carte) lorsque les autorités compétentes ont acquis la certitude que lesdits procédures et protocoles garantissent des niveaux de sécurité au moins équivalents à ceux prévus par la DSP2.
  • L’opération de paiement à distance est considérée par le PSP comme présentant un faible niveau de risque, c’est-à-dire que :
    • Une analyse en temps réel des risques de fraude a été réalisées sur la base de données qui concernent notamment le payeur (comportement, localisation…), ses habitudes de consommation, le dispositif ou le logiciel qu’il utilise pour l’opération ainsi que le bénéficiaire.

Cette analyse en temps réel des risques de fraude s’appuie ainsi sur de très nombreuses données donnant lieu à des échanges entre les différents acteurs de la chaine du paiement (échange des coordonnées postales téléphoniques et électroniques du client etc.). Etant pour la plupart des données à caractère personnel, leur traitement doit se conformer au Règlement (UE) 2016/679 (RGPD) et, s’agissant de la France, par la Loi n° 78-17 du 6 janvier 1978 modifiée. Les enjeux liés au partage de ces données à caractère personnel ont d’ailleurs fait l’objet d’un précédent article.

L’ensemble de ces dérogations pourra être appliqué à l’initiative du PSP de l’utilisateur du service de paiement (la banque du payeur). Dans un contexte d’opération de paiement liée à une carte de paiement, le PSP du bénéficiaire (la banque du commerçant) pourra également décider d’appliquer les dérogations du sans contact, des automates de transport, des opérations récurrentes et de faible valeur ainsi que celle de l’analyse de risque (à condition que son taux de fraude soit inférieur au seuil prévu). Toutefois, le PSP du payeur aura toujours le dernier mot et pourra ainsi décider en dernier ressort d’authentifier ou non fortement le payeur ou de refuser l’opération.

Dans l’hypothèse où le bénéficiaire ou son PSP passerait outre le choix du PSP du payeur, il engagerait alors sa responsabilité conformément à l’article 74.2 de la DSP2[20].

Par conséquent, pour éviter en pratique d’avoir à endosser la responsabilité d’une opération de paiement non autorisée pour laquelle aucune authentification forte n’a été demandée par le bénéficiaire, ce dernier a tout intérêt à déployer une solution conforme à la DSP2 et permettant l’utilisation des dérogations des RTS SCA (reposant par exemple sur le protocole EMV 3DS 2.0 notamment recommandé par l’ABE).


Alexandre MANDIL

Avocat à la Cour

[1] Les services d’information sur les comptes permettent à l’utilisateur de services de paiement d’avoir une vue d’ensemble de sa situation financière à tout moment et de gérer au mieux ses finances personnelles

[2] Les services d’initiation de paiement permettent aux consommateurs de payer leurs achats en ligne par simple virement, tout en donnant aux commerçants l’assurance que le paiement a été initié de sorte que les biens peuvent être livrés ou les services fournis sans délai.

[3] Transposé à l’article L133-44 Code monétaire et financier par l’Ordonnance n°2017-1252 du 9 août 2017.

[4] Considérant 7 des RTS SCA

[5] Considérant 6 des RTS SCA

[6] One time password

[7] Article 38 des RTS SCA.

[8] “Rather, the requirements apply as of 14 September 2019, as imposed in the Directive, and this means that any PSP not complying with them is in breach of law.”

[9] “Furthermore, NCAs should also communicate to their PSPs that the liability regime under Article 74 of PSD2 also applies, without any delay, that issuing and acquiring PSPs are therefore liable for unauthorised payment transactions and that PSPs should therefore have a self-interest to migrate to SCA-compliant solutions and approaches in an expedited way.”

[10] Selon les articles 4 de la DSP2, 2.26 du règlement MIF et L133-3 I du CMF, une opération de paiement est une action consistant à verser, transférer ou retirer des fonds, indépendamment de toute obligation sous-jacente entre le payeur et le bénéficiaire.

[11] Pour le CMF et la DSP2, l’initiation d’un ordre de paiement et l’initiation d’une opération de paiement renvoient sont deux expressions interchangeables : pour initier une opération de paiement, il faut initier un ordre de paiement.

[12] Article L133-3 II du CMF

[13] EBA-Op-2018-04 : “As explained in the final report on the draft RTS published in February 2017, the EBA’s view, after discussing it with the European Commission, is that SCA applies to all payment  transactions initiated by a payer, including to card payment transactions that are initiated through the payee”

[14] EBA/RTS/2017/02 (page 7) :   “13.In  relation  to  payment  instruments,   and  as  stated  in  the  CP,  the  EBA  understands  that  Article 97(1)(b)    applies  to  electronic  payments  initiated  by  the  payer,  or  by  the  payer  through  the  payee such  as  credit  transfers  or  card  payments,  but  does  not  apply  to  electronic  payments initiated  by  the  payee  only.”

[15] Transposé à l’article L133-42 du CMF

[16] Article 3 k) de la DSP2

[17] En France, les établissements bancaires ont choisi d’abaisser ce seuil à 30 euros.

[18] Voir aussi le paragraphe 43 de l’Avis de l’ABE sur l’implémentation des RTS SCA.

[19] A savoir la valeur totale de toutes les opérations non autorisées ou frauduleuses divisée par la valeur totale de toutes les opérations de paiement pour les paiements par carte ou les virements.

[20] Des règles spécifiques s’appliquent en outre aux opérations de paiement initiées par l’intermédiaire d’un prestataire de services d’initiation de paiement (PISP).

Categories:

DSP2 & RTS SCAFintech & paiements
Mentions légales & CGU | Données personnelles & Cookies | Copyright©2019-2022 MANDIL Avocats. Tous droits réservés.