DSP2 Directive révisée sur les Services de Paiement

DSP2

Directive révisée sur les Services de Paiement

 

Introduction

La première Directive sur les Services de Paiement (DSP) est entrée en vigueur le 13 novembre 2007. Il s’agit d’une directive européenne. Chaque état membre avait alors jusqu’à novembre 2009 pour la transposer en droit national.

Elle avait pour objet de permettre aux Prestataires de Services de Paiement (PSP) d’intervenir sur le marché des paiements de l’ensemble de l’UE, jusqu’ alors relativement cloisonné par Etat, et de renforcer la protection des consommateurs.

L’apparition de nouveaux types de services de paiement et l’évolution des paiement électroniques et mobiles ont rendu cette première directive inadaptée.

La DSP 2 a donc été publiée par le parlement européen le 25 novembre 2015. Elle remplace la première directive DSP 1, qui a été abrogée.

Elle a pour objet de sécuriser le marché des paiements intégrés, en tenant compte des nouveaux acteurs et des innovations technologiques, et d’améliorer encore la protection des consommateurs.

 

Dates clés

  • 1er février 2013: Au cours du 1er forum européen sur la sécurité des moyens de paiement de détails, les autorités de surveillance des prestataires de services de paiement et superviseurs des 31 états membres de l’Espace Economique Européen (EEE) initient les premières recommandations su­r la sécurité des paiements sur internet.
    • Ces recommandations ont pour principaux objectifs de :
      • Sécuriser les paiements initiés sur Internet­ en employant un process d’authentification précis, limiter les tentatives de connexion et d’authentification ;
      • Identifier, signaler et bloquer les opérations illégales ;
      • Accroître le nombre de contrôles sur les transactions afin de réduire les risques de fraude détectés
      • Sensibiliser les clients sur les risques de la sécurité sur internet
    • Ces mesures doivent être respectées par l’ensemble des Prestataires de Service de Paiement (PSP) proposant des services de paiement sur internet (transaction par carte bancaire ou virement sur internet, sauvegarde d’informations confidentielles sur une opération, génération de mandats électroniques pour les prélèvements…)
  • 19 décembre 2014: l’Autorité Bancaire Européenne (ABE) définit les orientations finales sur la sécurité des paiements sur internet :
    • Ces axes se basent sur la 1e Directive sur les Services de Paiement (DSP) 2007/64/CE
    • Des mesures de sécurité renforcées sont prises sur les paiements en ligne. Celles-ci concernent principalement :
      • La vérification de l’identité du client dans le cadre de la lutte anti-blanchiment
      • La mise en place d’un certain nombre de contrôles pour vérifier que le paiement initié pour un client est bien autorisé par celui-ci
      • La limitation du nombre de tentatives de connexions et d’authentification du client (réception d’un mot de passe unique pour valider une transaction par exemple) ainsi que la suspension d’une session de paiement sur internet active dépassant un délai prédéfini
      • Adaptation de l’ensemble des mesures de sécurité par rapport aux évolutions des systèmes d’information
      • Historisation de toutes les opérations de paiement traitées par les PSP
    • Enfin, la sensibilisation du client par rapport à ces risques implique que les PSP doivent renforcer leur communication avec leurs clients pour les informer de l’état de leur compte, ou encore les avertir en cas de fraude sur leurs opérations

 

Principes de la réglementation DSP2

La DSP1 avait pour objet d’harmoniser les règles en matière de paiement électronique au sein de l’EEE afin d’ouvrir des accès équitables au marché des paiements. Cette dernière est vite devenue obsolète et a été remplacée par la DSP 2.

L’obsolescence de la DSP 1 s’explique par :

  • L’arrivée des nouveaux types de services de paiement
  • Evolution rapide des paiements sur internet ;
  • Protection insuffisante des consommateurs et des entreprises

Les quatre principaux axes de la DSP2 sont :

 

Encadrement de nouveaux acteurs

Depuis 2007 et l’élaboration de la DSP 1, de nouveaux services de paiement ont émergé ou certains services ont évolué.

L’objectif direct de la DSP2 est d’accroître la concurrence et l’innovation sur le marché de paiement européen tout en renforçant la sécurité des utilisateurs.

L’arrivée de DSP 2 a pour objet d’encadrer les nouveaux acteurs déjà présents sur le marché, plus communément appelés les tiers de paiement notamment :

  • Les prestataires de services d’initiation de paiement (PSIP) : ces services interviennent dans le cadre du commerce électronique. Il s’agit d’une passerelle entre le site du marchand et la plate-forme de la banque de l’acheteur. Le paiement s’effectue sous forme de virement.

Exemple : slimpay, soforbanking

 

  • Les prestataires de services d’information sur les comptes (PSIC) : ce sont des nouveaux services qui sont apparus et qui permettent d’obtenir une vision de la totalité de ses comptes de paiements, issus d’un ou plusieurs PSP (Prestataire de Service de Paiement).

Exemple : tink, eurobits

 

La DSP 2 permet au PSP d’accéder uniquement aux données du compte client pour lequel ce dernier a donné explicitement son accord. La DSP 2 leur interdit d’accéder à toute autre nature de données clients. Les PSP n’accèderont plus aux données des clients via « screen scraping» (capture de données d’écran), mais par le moyen d’un canal « Application Programming Interface » (API) que la banque aura mis en place pour leur permettre d’accéder aux données dont ils ont besoin. Ce canal est également un moyen de sécuriser davantage l’accès aux données du client car les PSP et les banques seront obligés de s’identifier pour accéder
aux données

 

Renforcement de la sécurité et normes de communication

Face aux techniques de paiement toujours en évolution, au volume croissant des transactions à l’échelle mondiale et à l’apparition de nouveaux types de paiement, les risques liés à la sécurité des paiements en ligne augmentent.

À ce titre, la DSP2 (art. 98) a confié à l’ABE le soin de rédiger des normes techniques de réglementation (RTS) concernant :

  • L’authentification forte du client ;
  • La communication sécurisée entre les acteurs des services de paiement

L’authentification forte du client

La DSP 2 requiert la généralisation de l’authentification forte du client (SCA : Strong Client Authentification) afin de sécuriser les opérations notamment dans les cas suivants :

  • Lorsque le client accède à son compte de paiement en ligne ;
  • Lorsqu’il procède à une opération de paiement en ligne
  • Lorsque le risque de fraude de paiement est avéré et que l’action est effectuée via un mode de communication à distance

 

L’authentification forte d’un client désigne la combinaison d’au moins 2 facteurs parmi les 3 catégories suivantes :

  • « Quelque chose que le client sait » : mot de passe, code PIN…
  • « Quelque chose que le client détient » : ordinateur, téléphone portable, tablette…
  • « Quelque chose que le client est » : empreinte digitale, reconnaissance vocale ou rétinienne…

Les opérations du client devront faire également l’objet d’un suivi par les PSP afin que ceux-ci prennent en compte l’historique des opérations du client, ou encore les tentatives de fraude par exemple.

Certaines dérogations au protocole d’authentification forte pourront être demandées dans les cas suivants :

  • Authentification forte nécessaire à la 1e connexion puis à terme tous les 90 jours ;
  • Paiement sans contact pour des opérations dont le montant n’excède pas un certain plafond ;
  • Transaction répétée pour un même bénéficiaire

Communication sécurisée entre les acteurs des services de paiement

L’ABE est également en charge de la définition des exigences relatives aux normes ouvertes communes et sécurisées de communication (CSC) qui régiront les échanges d’identification, d’authentification, de notification et d’information entre :

  • Prestataires de Services de Paiement
  • Agrégateurs et initiateurs de paiement
  • Gestionnaires de compte
  • Payeurs et bénéficiaires

Les interfaces d’échanges entre ces acteurs doivent respecter certaines exigences :

  • Échanger les spécifications techniques qui permettront de mettre en place la connexion entre les différents acteurs
  • Avertir 3 mois à l’avance sur toute évolution portant sur l’interface de connexion
  • Les informations échangées devront être formatées en respectant les standards internationaux de type ISO 20022)
  • Créer des environnements de tests

 

La dernière version finalisée du projet RTS a été transmis le 22 février 2017 à la Commission Européenne.

La date prévisionnelle d’entrée en vigueur du projet RTS est avril 2019.

 

Renforcement des pouvoirs de contrôles des autorités

Les autorités compétentes nationales sont responsables de l’agrément d’établissements de paiement et des contrôles sur ces derniers.

Dans le cadre de DSP2, il a été prévu de renforcer le lien entre les autorités compétentes des États membres de l’ABE (Autorité Bancaire Européenne) notamment sur :

  • Les informations échangées entre ces autorités
  • L’application de la nouvelle directive DSP2

À ce titre, certaines mesures ont été prises pour faciliter la coopération entre ces autorités dans le cadre de la directive 2007/64/CE :

  • L’ABE devra résoudre d’éventuels différents entre les autorités compétentes des États membres
  • L’ABE devra mettre en place un certain nombre de règles portant sur la coopération et les échanges de données
  • L’ABE devra instaurer et gérer un registre central listant toutes les entités délivrant des services de paiement. Ce seront les États membres qui devront mettre à jour régulièrement cette liste.

 

Durcissement des conditions de délivrance d’agrément

Avec l’arrivée de la DSP 2, les nouveaux acteurs (les tiers paiement) doivent obligatoirement obtenir un agrément. En effet, le dossier d’agrément doit traiter de la politique de gestion des risques conformément aux dispositions de la directive 2005/60/CE [2].

Les PSP sont soumis à un contrôle de leur actionnariat. En effet, les autorités compétentes doivent être informées de toutes les opérations sur le capital et pourront décider le cas échéant.

Les prestataires de paiement sont également obligés de sécuriser les fonds de leurs utilisateurs.

Ils devront également être couverts par une assurance responsabilité civile professionnelle équivalente couvrant les territoires où ils fournissent leurs services et dont le montant minimal devra être défini selon des critères définis par une orientation à venir de l’EBA.

Les AISP et les PISP pourront recevoir un agrément dès janvier 2018.

 

DSP2 et Instant Payment

Le projet SEPA (Single Euro Payments Area) se place dans la continuité de la Directive européenne sur les Services de Paiement (2007/64/CE, du 13 novembre 2007). Elle a pour objectif de garantir un accès équitable et ouvert aux marchés des paiements et à renforcer la protection des consommateurs.

Ce projet inclut 34 pays dans lequel les règles et les moyens de paiement sont en cours d’harmonisation.

 

Implémentation de l’Instant Payment

Dans le contexte actuel d’innovation en matière de solutions de moyens de paiements en temps réel, le comité ERPB (Euro Retail Payments Board) en charge du développement d’un marché intégré, innovant et compétitif pour les paiements en euros souhaite mettre en place une solution de paiement immédiat « L’Instant Payment » au niveau pan-européen pour 2017-2018.

Ce système de paiement immédiat a déjà été implémenté depuis plusieurs années dans certains pays comme par exemple au Royaume-Uni avec le Faster Payments Service (FPS).

L’Instant Payment correspond à un virement SEPA dont le montant maximal sera plafonné à 15 000 € et dont  le délai d’exécution ne devra pas excéder 10 à 20 secondes maximum.

L’Instant Payment impacte différents secteurs tels que :

  • les transferts de fonds
  • les paiements e-commerce mais aussi de proximité tels que la grande distribution

 

Fonctionnement des transactions SCTinst entre plusieurs PSP

Le schéma ci-dessous décrit les différentes étapes d’une transaction SCTinst entre plusieurs PSP.

 

Enjeux de l’Instant Payment pour les PSP

Dans ce cadre, l’ERPB a instauré des règles de contrôles et d’information que devront respecter les PSP comme par exemple : générer des confirmations de validation ou de rejet au payeur et au bénéficiaire, avertir si les fonds sont disponibles, etc.

Le déploiement des paiements instantanés représente un enjeu réel pour les différents acteurs du marché en Europe à savoir les banques, et les prestataires de services de paiement.

La mise en place de cette nouvelle technique de paiement instantané bouleversera donc les moyens de paiements actuels (le paiement en espèce, chèque…).

En effet, la technique de paiement instantané dépend d’une part des fournisseurs de services de paiement (PSP), qui devront s’adapter afin de développer leurs fonctionnements en intégrant cette nouvelle dimension et fournir des services de paiement SCTinst.

D’autre part cela demandera également de mettre à disposition des infrastructures de marché sous-jacentes, sûres et efficaces qui pourront traiter des paiements instantanés à travers l’Europe. Exemple : les paiements mobiles de personne à personne.

L’apport du paiement instantané au client est non négligeable, car cela permet d’échanger des fonds en 10s à 20s pour un montant allant jusqu’à 15 000€, ce qui aujourd’hui prend 1 journée.

Le parcours du client est ainsi optimisé, sécurisé et plus rapide.

La sécurisation de ces nouveaux types de paiement doit être également revue.

Face à l’adaptation permanente des cyber fraudeurs aux nouvelles techniques de paiement, les risques de fraude sont davantage accrus avec l’introduction de l’Instant Payment sur le marché. En effet, des attaques de type phishing ou malwares permettent de prendre le contrôle à distance d’objets mobiles et de récupérer les données bancaires confidentielles des clients. Ainsi, l’Instant Payment facilitera aux fraudeurs l’accès à des fonds en quelques secondes.

 

Innovation et DSP2

Evolution des interactions entre les différents acteurs bancaires avec l’apparition d’un prestataire de services d’initiation de paiement (PSIP) :

Avant DSP2 :

Après DSP2 :

Evolution des interactions entre les différents acteurs bancaires avec l’apparition d’un prestataire de services d’information sur les comptes (PSIC) : 

 

Avant DSP2 :

Après DSP2 :

Quelles sont les innovations attendues avec DSP2 ?

  • De nouveaux protocoles d’échanges entre ces nouveaux acteurs et les banques: de nouveaux standards ISO20022 devront être mis en place entre les banques et les acteurs externes pour échanger les données confidentielles des clients via les APIs ;
  • L’extension de nouvelles offres fournies par les banques : en confiant le développement de ses API à différents développeurs externes, ceux-ci seront mis directement en concurrence entre eux. Pour se différencier, ces développeurs externes seront continuellement à la recherche de nouvelles solutions bancaires innovantes à usage des clients. Les banques élargiront et diversifieront ainsi leurs offres de service par les propositions de leurs partenaires.

Exemple : Le Crédit Agricole, a été la 1ere banque au monde à proposer un service sur l’Apple TV via son CAStore.   

  • La modernisation et l’innovation dans les systèmes d’information de la banque: Les acteurs externes en charge du développement de ces API contribueront à la modernisation des systèmes d’information des banques. En effet, les systèmes d’information des banques peuvent aujourd’hui traiter d’importantes volumétries d’opération en s’appuyant sur des processus robustes développés à partir d’anciennes technologies. Les développeurs externes pourront proposer de nouvelles technologies qui pourront s’intégrer aux systèmes bancaires de la banque sans les refondre totalement. Les API pourront également introduire le système multicanal avec les banques. Ceci aura pour effet de rendre les banques plus réactives face aux besoins émergents et s’adapter à l’accélération du « time to market ».

 

  • De la création de valeur et de nouveaux clients: une banque pourra augmenter sa clientèle en mettant à disposition de ses clients une API qui lui est propre et en ajoutant à son processus utilisateurs des API issus d’autres compagnies. Cela crée de la valeur ajoutée d’un point de vue client.

Exemple : BPCE possédait initialement une API interne qui donnait à ses clients l’accès aux données des clients et aux services des multiples filiales du groupe. Elle a ensuite élargi son service en ouvrant une API externe développée par une de ses filiales S-money à ses clients pour encaisser des paiements.

 

Limites de DSP2 en termes d’innovation

Dans un contexte d’«open banking» où la banque va garantir l’accès à ses services (consultation de compte, émission d’un virement) à des acteurs externes, des problématiques sont soulevées sur la standardisation et la sécurisation proposée par DSP2 des accès aux informations confidentielles de la banque.

Les API devront en effet respecter certains standards techniques visant à harmoniser les moyens d’échange de données et de communications entre une banque et ses différents PSPs. Pour les PSP soutenus principalement par des starts up et des fintechs, le challenge économique et technique est important à cause de la diversité des programmations des APIs.

L’ensemble des standards techniques réglementaires (RTS) visant à renforcer la sécurité sur l’accès aux comptes en banque contre les risques de fraudes et de saturation des canaux d’accès aux banques représentent un frein au développement des API bancaires :

  • L’authentification forte mensuelle demandant au client d’une banque de saisir obligatoirement tous les mois ses identifiants pour s’authentifier auprès de sa banque peut représenter un frein à une utilisation fluide de l’API bancaire
  • La limitation à 2 connexions par jour au système d’information de chaque banque ne permet pas à l’utilisateur de connaître sa situation en temps réel sur ses comptes.

 

Apports et limites des API pour les différents acteurs du marché bancaire

Aujourd’hui les FinTech se basent sur la technique du « screen-scraping » pour fonctionner. Avec l’adoption de la DSP2 cette technique est interdite et remplacée par l’API.

  • Qu’est-ce que cela engendre pour les Fintech ? Sont-elles menacées ?

La technique du « screen-scraping » est un vrai avantage pour les FinTechs car cette dernière leur permet d’accéder à l’ensemble des données client. Le « screen-scraping » est une technique simulant une connexion client grâce à un robot. Cela permet d’accéder aux données du client pour les récupérer et les présenter au client d’une manière plus ergonomique et plus agrégée (agrégateur de compte par exemple). Ces informations confidentielles peuvent être également stockées et analysées. Cette technique de connexion nécessite des informations très confidentielles du client tel qu’un identifiant et un mot de passe. Même si ce dernier donne son accord explicite pour que les PSP puissent utiliser ses informations, il enfreint d’un autre côté le contrat qu’il a signé avec sa banque.

Les APIs apparaissent comme la solution la plus adéquate pour prendre en compte et répondre à l’ensemble des exigences mentionnées par la DSP2.

Une API est un moyen d’extraire et de présenter des données via un accès contrôlé et sécurisé. L’API fonctionne avec une logique de questions-réponses. Les agrégateurs de données par exemple lancent une requête depuis leurs applications afin de récupérer via la passerelle sécurisée des données bien définies. En conclusion, l’API est plus sûr et s’inscrit dans la continuité de l’authentification forte du client contrairement à la méthode de « screen-scraping ».

  • Quels impacts sur les FinTechs ?

L’arrivée de l’API représente pour les Fintechs – qui ont développé tout un savoir-faire et une connaissance technique de « screen-scaping » – une perte d’avantage concurrentiel ainsi qu’un retour à la case départ pour développer de nouvelles connaissances autour de l’API. Elles ont jusqu’à mi-2019 pour faire entrer en vigueur l’API et l’interdiction « screen-scraping ».

Les FinTechs sont donc prises par le temps et devront engranger des moyens et des coûts non négligeables pour se développer autour de l’API et se positionner au-devant de la scène afin de gagner un maximum de part de marché. Sans compter la perte et le coût du développement de la méthode « screen-scraping » qui sera obsolète dans un peu plus d’une année.

A noter que le coût de maintien et l’ajout de données, pour tout type d’API, a un impact financier non négligeable.

Le développement des API a néanmoins des avantages pour les FinTechs qui n’auront plus besoin de s’adapter en permanence aux systèmes en ligne de chaque banque et pourront utiliser un API pour plusieurs banques.

Pour les banques, l’enjeu est de mettre en place les API et les nouveaux types monétaires de demain. Il faut également choisir les données et les services à exposer pour profiter des possibilités offertes par l’Open Banking. Charge désormais aux banques de trouver leur place dans ce nouvel écosystème pour garder leur position vis à vis de la relation client et sur les différents services créateurs de valeurs.

L’apparition des GAFA représente une vraie menace pour les banques. Les GAFA disposent d’une capacité financière qui leur offre une vraie liberté d’innovation.

 

Comment BIA vous accompagne

Bia apporte son expertise dans la mise en conformité́ du SI afin de produire les déclarations, dans des délais raisonnables. Les fiscalistes et spécialistes règlementaires de Bia vous accompagnent dans :

  • l’analyse des besoins émis par les autorités règlementaires,
  • la formalisation de ces besoins en spécifications,
  • l’intégration de ces besoins dans le système d’information

 

Lexique

  • ABE: Autorité Bancaire Européenne
  • AISP: Account Information Service Provider
  • API: Application Programming Interface
  • ASPSP : Account Servicing Payment Service Provider
  • BCE: Banque Centrale Européenne
  • DSP1: Directive sur les Services de Paiement 2007/64/EC
  • DSP2 : Directive sur les Services de Paiement (EU) 2015/2366
  • EBA : European Banking Authority
  • GAFA: Google, Apple, Facebook et Amazon
  • PSIC : Prestataires de services d’information sur les comptes
  • PSIP: Prestataires de services d’initiation de paiement
  • RTSG : Regulatory Technical Standards and Guidelines
  • SCA: Strong Customer Authentification
  • TP-PSP Third Party – Payment Service Provider (Or TDD Third Party Providers)
  • TIPS : Target Instant Payment Settlement
Liens de Référence