La Commission Européenne a publié en décembre 2015 la deuxième Directive sur les Services de Paiement (DSP2). Cette mesure vise à structurer le secteur bancaire en encadrant les pratiques des différents acteurs afin de mieux servir les consommateurs.

Le contexte

La directive européenne DSP2 a été créée afin d’apporter des solutions dans un système bancaire en besoin de structuration. L’analyse de l’environnement a mené la Commission Européenne à faire plusieurs constats :

• Les banques sont bien établies dans le marché européen, le paysage bancaire n’a pas beaucoup évolué au cours des dernières années avec les principales institutions se partageant des parts de marché relativement stagnantes. On observe donc un manque d’innovation et de compétition, ce qui défavorise les consommateurs ;
• De nouveaux acteurs appelés « Fintechs » ont fait leur irruption dans le secteur bancaire. Ce sont des entreprises opérant dans le milieu de la finance à l’aide de la technologie afin d’améliorer les services proposés et l’expérience des utilisateurs.
• Internet a pris une place considérable dans les habitudes de consommation des clients. L’e-commerce est en plein boom (80 milliards d’euros aujourd’hui) et par conséquent, les paiements en ligne aussi. Cependant, il existe encore aujourd’hui de nombreux problèmes : sécurité des transferts (de nombreuses fraudes ont lieu chaque année), protection des données, confiance de l’utilisateur…

À travers DSP2, on cherche à améliorer le système bancaire, à le sécuriser afin d’améliorer l’expérience bancaire des utilisateurs et à stimuler la compétition et l’innovation.

Les acteurs

La directive DSP2 concerne de nombreux acteurs du milieu bancaire qui vont voir leurs pratiques évoluer.

Les banques vont devoir faire face à un grand chamboulement de leur environnement. Elles sont les premières concernées par les évolutions imposées par la directive DSP2 : partage des données des clients aux prestataires de services tiers, renforcer l’authentification, installer de nouvelles technologies, intensification de la concurrence avec la législation des nouveaux acteurs… Ainsi afin de garder leur place de leader du marché les banques vont devoir innover et s’adapter rapidement.

Les prestataires de services tiers aussi appelés TPP (Third Parties Payment Service Provider) sont ces nouvelles entités qui disruptent le secteur bancaire. En effet, en utilisant la technologie pour proposer des services bancaires, elles concurrencent les banques traditionnelles. Jusqu’à l’entrée en vigueur de la directive DSP2 leurs activités étaient mal régulées. En effet, elles ont du utiliser la technique de web scraping (demander les identifiants des clients pour ensuite se connecter à leur place grâce à un robot sur le compte de leur institution bancaire et y récupérer des informations précises) afin d’assurer leurs services. Cependant le web scraping pose des limites de sécurité et de légalité. Grâce à la directive, les TPP n’auront plus à exercer ces pratiques, et pourront disposer des données souhaitées à travers une API (XS2A). Dans ce sens, nous distinguons différents types de TPP:

• Account Information Service Provider (AISP): ces prestataires proposent d’agréger tout les comptes bancaires sur une interface afin d’en avoir un aperçu global. À travers des fonctionnalités de visualisation de l’état des comptes (par exemple : catégoriser les sorties d’argent en fonction des postes de dépenses), l’AISP offre une meilleure gestion de son argent au client. En France, on retrouve plusieurs applications répertoriées dans ce secteur: Linxo, Bankin ou Nestor.
• Payment Initiation Service Provider (PISP): ces prestataires offrent la possibilité d’effectuer des paiements en ligne directement à partir de leur plateforme sans avoir à passer par celle de la banque du client.
• Payment Instrument Issuer Service Provider (PIISP): le PIISP offre au client une carte de paiement directement relié à son compte bancaire.

Les clients aussi appelés PSU sont les premiers bénéficiaires de la directive DSP2. En effet, ils vont à la fois pouvoir profiter de services diversifiés, innovants, et sécurisés.

Les mesures à retenir

Des mesures phares structurent la directive DSP2 :

• Légaliser les pratiques des TPP : jusqu’alors aucune règle ne s’appliquait aux TPP, cependant à travers DSP2, l’étendue de leur pouvoirs et devoirs sont délimitées. Une série d’obligations est donnée à la DSP2: demander le consentement explicite au client pour l’accès à ses données, assurer la sécurité et protection de ses données, utilisation limitée des données, garantir le bon déroulement des opérations grâce à une sécurité renforcée… Ces règles permettent de donner un cadre d’action aux TPP pour protéger les clients.

• Elargir l’accès aux données : la mesure qui génère le plus de débats est l’ouverture des données bancaires aux TPP qu’on appelle aussi Access to Account (XS2A). Grâce à cette règle, le client peut directement payer ou avoir ses informations de compte sans passer par sa banque. Ainsi pour répondre aux défis techniques de cette mesure (comment la banque peut transmettre telle information à une entité particulière tout en respectant au maximum les règles de sécurité), il faut mettre en place une API (Application Programming Interface) pour mettre fin à la technique de web scraping. On peut donc identifier des défis de sécurité dans l’échange des données personnelles, ainsi que de confiance des consommateurs. Ces derniers sont relativement inquiets à l’idée de partager leurs données personnelles.

• Assurer la protection des données : pour être sécuritaire, la directive DSP2 impose de mettre en place un système d’authentification aussi appelé Strong Customer Authentication (SCA). En effet, afin de protéger les informations échangées grâce à XS2A, il est demandé à l’utilisateur de passer par un processus d’identification en deux étapes lors de chaque transaction. Le but est de s’assurer de l’identité du client afin d’éviter les fraudes, pour cela, le consommateur doit fournir deux des trois éléments suivants : quelque chose qu’il sait (code PIN), qu’il détient (code envoyé sur son téléphone portable) ou qu’il est (données biométriques). On trouve déjà certains systèmes conformes avec SCA comme 3DSecure ou ApplePay.

• Interdiction d’appliquer des charges supplémentaires en fonction du moyen de paiement

Le rôle d’une API

Afin de mettre en place le partage de données entre TPP et les banques, il est nécessaire pour ces dernières d’adapter leur structure informatique. En effet, le défi se situe dans le transfert des données précises demandées par le TPP au TPP en question. Pour exécuter cette tâche, les banques vont devoir mettre en place des APIs (Application Programming Interface). Ce sont des interfaces permettant à deux systèmes indépendants de se connecter, et par lesquelles de nombreux échanges d’informations ont lieu. Dans ce sens, nous pouvons noter quelques avantages de l’APIsation des échanges :

• universalité : indépendamment du langage d’un système il est possible pour l’API de recevoir des informations et des ordres.
• possibilité d’échanger des données brutes
• contrôle des données échangées aux entités tierces (dans le cas de DSP2 contrôle des informations données aux TPP) avec une partition par TPP.

Analyse du secteur bancaire et de son APIsation

La directive DSP2 a été adoptée par la Commission Européenne en 2016, les banques doivent donc suivre un échéancier concernant l’application de ces obligations. Concernant l’API, il est demandé aux banques de se munir au plus tard en mars 2019 de cette technologie. S’en suivra alors une phase de test avant l’entrée en vigueur des RTS (Regulatory Technical Standards) six mois plus tard.

On peut dès lors mener une analyse de l’environnement bancaire européen pour évaluer le degré d’APIsation des banques par pays.

France

• BNP Paribas
  Un ensemble d’API permettant d’obtenir des informations de compte et d’initier des paiements.
  Cet ensemble d’API est fourni par l’Open Bank project. Il s’agit d’une sandbox avec des accès à des comptes fictifs.
• Crédit Agricole
  Une API Rest permettant d’accéder aux informations de compte et d’initier un virement (la création d’IBAN n’est pas possible)
• Société Générale
  Une sandbox Github liée au projet Open Bank.
• Banque Postale
  Même interface API que BNP Paribas, reposant sur le standard Open Bank Project.
  Il s’agit d’une sandbox avec des accès à des comptes fictifs.
• AXA
  Une API dédiée à l’assurance. Pas d’API concernant les services bancaires d’AXA.

Royaume-Uni

• HSBC
  Une API (uniquement des requêtes de lecture « GET ») pour avoir des informations sur la localisation d’agences ou de bornes de retrait, des informations sur des comptes particulier ou entreprise et des informations liées aux prêts PME
• Lloyds Banking Group
  Une API complète pour obtenir des informations de compte ou initier des paiements à destination des TPP (PISP ou AISP).
• Royal Bank of Scotland
  RBS fait partie des bons élèves avec une API permettant d’initier des paiements et de consulter de l’information de comptes.
• Barclays
  Une API permettant la gestion du consentement, localisation des agences et des distributeurs (ATM), initiation de paiement, information de compte.
• Standard Chartered
  des API pour le retail banking et pour le corporate banking. Nécessité de se logguer pour accéder à la documentation. L’API permet d’accéder à de l’information sur les comptes et d’initier des paiements.
• NatWest
  Une API permettant d’initier des paiements et de consulter de l’information de compte.
• Ulster Bank
  Documentation  identique à NatWest et qui permet d’initier des paiements et de consulter de l’information liée aux comptes.
• Allied Irish Bank
  Une API qui suit les standards open banking et qui propose d’initier des paiements et d’obtenir de l’information de compte.

Suisse

• Raiffeisen Bank
  Une API encore incomplète permettant d’obtenir des informations sur les comptes et les transactions. Une seconde API permet de gérer les autorisations.

Danemark

• Nordea
  Une API complète d’initiation de paiement, d’information de compte et de gestion d’accès pour les TPP. L’API dispose aussi d’une console de test en ligne et d’un swagger. En parallèle, une API liée aux taux de change est aussi disponible en premium (FX). Il s’agit pour nous de l’une des APIs bancaires les plus abouties. La roadmap à venir est visible à travers un Trello public.
• Danske Bank
  L’API n’est pas encore disponible mais il est possible d’être tenu informé de sa publication en s’inscrivant sur le site.

Espagne

• BBVA
  Un des pionniers des API bancaires avec surement un des catalogues les plus fournis en terme de fonctionnalités disponibles.
  Informations de compte pour les particuliers et les entreprises, initiation de paiement, notification, statistiques …

Grèce

• Hellenic Bank
  Cette API permet de gérer des paiements de compte à compte. Elle permet aussi d’obtenir des informations de reporting liées aux comptes.

Finlande

• OP
  La banque finlandaise possède plusieurs API dont certaines permettant d’obtenir de l’information de compte et d’initier des paiements.

Allemagne

• Deutsche Bank
  Deutsche Bank propose une API d’accès aux informations de compte ainsi qu’un historique de transaction de 12 mois.
  L’initiation de paiement n’est par contre pas encore disponible. Deutsche Bank propose par contre l’obtention d’un score de solvabilité client ; pratique pour évaluer la capacité de paiement d’un consommateur.
• Fidor Bank
  Fidor Bank gère des fonctionnalités différentes selon le type de TPP enregistré et ayant un accès.  Toutes les fonctionnalités requises par DSP2 sont bien présentes avec des informations de compte et de l’initiation de paiement. Plusieurs méthodes de paiement sont proposées : SEPA, transfert interne, FPS (fast payment system). L’API propose également un batch de paiement ; bien pratique pour initier simultanément plusieurs paiements.
• Solaris Bank
  L’API Solaris Bank n’est pas disponible publiquement.

Pays – Bas

• ABN AMRO
  Un catalogue fourni d’API permettant d’obtenir de l’information sur les comptes (avec un petit plus pour partager sur Whatsapp, SMS, Messenger…) et d’initier des paiements. ABN propose aussi d’effectuer des paiements par batch permettant de payer plusieurs transactions en même temps.

Belgique

• ING Bank
  ING propose un éventail de micro-services pour initier des paiements et gérer les informations des comptes (transactions, balances, devises, IBAN…)

Autriche

• Erste Group
  Erste propose une API avec les fonctionnalités basiques pour initier des paiements et obtenir des informations sur les comptes.

Slovaquie

• Tatra Banka
  L’API de Tatra Banka permet d’initier des paiements SEPA ou étrangers et d’obtenir de l’information de compte.

Vous cherchez à APIser votre système d’information ? Contactez-nous pour en discuter !