Particeep décrypte pour vous la directive européenne sur les services de paiement (DSP2), son contexte, ses acteurs et sa mise en application en Europe. 

En décembre 2015, la Commission Européenne publie la deuxième directive sur les services de paiements : la directive DSP2 (ou PSD2 en anglais). L’établissement de ces nouvelles réglementations fait suite à différentes observations de l’évolution du secteur bancaire :

• Le manque de compétition empêchant une réelle évolution des services proposés par les banques dites « traditionnelles ». On trouve des monopoles bancaires dans plusieurs pays européens. En Angleterre 80% des activités bancaires sont contrôlées par les cinq banques principales.
• L’arrivée de nouveaux acteurs ; les fintechs, qui, grâce à la technologie proposent des services financiers.
• L’émergence du commerce en ligne a renforcé la demande de paiement par service tiers (l’e-commerce représente aujourd’hui 80 milliards d’euros) et la nécessité de sécuriser les transactions (Europol dénombre en 2013 à 1.44 milliards d’euros l’étendue des transactions bancaires frauduleuses).

Avec la DSP2, la Commission Européenne a de multiples objectifs : faire évoluer le secteur bancaire, stimuler son innovation, lisser les pratiques entre anciens et nouveaux acteurs, encourager les évolutions technologiques tout en les réglementant et proposer aux utilisateurs une meilleure expérience bancaire.

Les acteurs concernés par la DSP2

Les banques

Les banques ou les acteurs appelés « services de paiement gestionnaire du compte » ou « ASPSP » (Account Servicing Payment Service Providers) sont les institutions au cœur du projet de la DSP2. Cette directive est une révolution en tout point : partage de données, mise en concurrence avec de nouveaux acteurs. Les banques doivent adapter leurs systèmes d’information pour être en accord avec le régulateur (API, méthode d’authentification, protection des données et de leur partage,…), et leurs canaux d’acquisition, nouveau terrain de jeu des fintechs.

Les banques vont devoir harmoniser leurs structures informatiques à DSP2 en mettant en place des APIs ouvertes afin de partager les données bancaires ou d’initier des paiements. Elles perdront donc cet avantage compétitif d’accès privilégié aux données des consommateurs. Face à ce risque de désintermédiation, les banques ne sont pas démunies. Tout d’abord, elles peuvent compter sur l’EBA (European Banking Authority) qui protège certains de leurs intérêts. Par ailleurs, elles peuvent voir cette directive comme une opportunité pour se différencier dans un secteur aux parts de marchés établies. Seules les plus réactives pourront en profiter.

En 2018, 6 mois après l’application de la DSP2 encore 50% des banques françaises n’avaient pas mis au point la technologie API permettant de respecter la mesure.

L’Autorité bancaire européenne

L’EBA (European Banking Authority) se charge de donner un cadre à la directive DSP2 qui, sur certains détails, reste relativement floue. L’organisme propose la teneur des données qui pouvaient être partagées entre les banques et les prestataires de services de paiements.

Les données n’incluent pas les informations telles que l’adresse, la date de naissance ou le numéro de sécurité sociale. Ceci afin de ne pas livrer un KYC « tout fait » aux tiers qui devront eux même le réaliser.

Les TPP : Third Party Providers

Les prestataires de services tiers sont l’autre partie essentielle de la directive DSP2. Ce sont des fintechs qui grâce à leur technologie proposent de nouveaux services aux consommateurs. Avant la directive, ces entités n’avaient pas accès aux données des banques. Afin d’exercer leurs services, elles « demandaient » les codes d’accès de banques aux utilisateurs et se connectaient à travers des robots à leur compte bancaire afin de récupérer les informations nécessaires à l’exécution de leurs services. Cette technique de « web scraping » empêche les banques de différencier s’il s’agit du client actuel ou du prestataire de service tiers (information / paiement).

On peut distinguer ces prestataires de services tiers en deux catégories :

• AISP (Account Information Service Provider) : ils permettent aux utilisateurs de regrouper leurs informations bancaires sur une même plateforme quand ils ont de multiples comptes. Ils ont pour rôle d’agréger toutes les informations et de les représenter de manière lisible au client afin de faciliter la gestion de ses comptes. En plus de cette fonction de faciliter la visualisation de l’état de ses comptes, le service est parfois agrémenté d’un accompagnement de la gestion de son argent. En France il existe déjà de nombreuses applications qui proposent des services d’AISP, on retrouve des fintechs telles que Linxo, Bankin ou Nestor.

Source : CBanque – Aperçu de l’application Linxo d’HSBC

Ces nouveaux intermédiaires redéfinissent les points d’accès aux informations bancaires de base.

• PISP (Payment Initiation Service Provider) : permettent d’initier un paiement directement depuis leur plateforme. Ils permettent une grande flexibilité sachant qu’ils n’ont pas à passer par la banque pour effectuer le paiement.
• PIISP (Payment Instrument Issuer Service Provider) : fournit des cartes de paiement qui sont reliées au compte bancaire, le PIISP lorsque le client effectuera la transaction devra se charger de la disponibilité des fonds auprès de l’ASPSP.

Le standard Open Banking fournit une liste de TPPs autorisés.
Le site de l’ACPR (Autorité de Contrôle Prudentiel et de Résolution) fournit également une liste. Il s’agit de sociétés autorisées à fournir des services d’initiation de paiement et des services d’information sur les comptes.

Les clients

Aussi appelés PSU (Payment Service User) dans la directive, il s’agit des utilisateurs de ces nouveaux services financiers. Aujourd’hui, 90% des Français ne sont pas au courant de la directive et de ses répercussions sur leur vie quotidienne. Les 10% en ayant connaissance s’inquiètent du partage de leurs données bancaires. Cependant, la directive DSP2 représente de grands avantages pour les consommateurs car elle permet :

• Une sécurité renforcée : à travers l’API, sont proposés plusieurs critères de sécurité que doivent mettre en place les banques et les services tiers (SCA, OAuth, ConnectID…) afin d’assurer une meilleure protection des données
• L’arrivée de nouveaux acteurs régulés et de nouveaux services donnant aux consommateurs plus de transparence sur les frais (facilitant ainsi la mise en concurrence optimale), et de nouvelles interfaces et applications leur permettant de nouveaux usages quant à la gestion de leurs comptes.
• D’accroitre la concurrence: sur le long terme, les acteurs du secteur seront obligés de proposer un service de meilleure qualité afin d’assurer la fidélité du consommateur qui sera tenté d’aller de plateforme en plateforme ou d’institutions bancaires en institutions bancaires.
• D’accélérer les paiements et la transmission d’informations bancaires

Les fournisseurs de technologie

Dans le schéma standard avant DSP2, les banques étaient en relation directe avec leurs clients. L’arrivée des nouveaux entrants impose une nouvelle couche technique (« layer ») avec l’utilisation d’APIs ouvertes entre les applications tierces de TPP et les acteurs bancaires (via leur « core banking »).

Des acteurs comme Particeep se positionnent sur la fourniture de ces API permettant aux acteurs financiers de :

• donner des accès aux tiers (AISP et PISP) via un système OAuth2
• fournir une authentification sécurisée aux utilisateurs
• permettre une gestion du consentement des utilisateurs chez les tiers TPP
• contrôler la validité d’accès du TPP et son droit sur les différentes données des clients ou actions possibles

La directive DSP2 et ses préconisations techniques

DSP2 : exigences et contraintes techniques

Nous allons résumer les principales préconisations techniques de la directive Européenne DSP2, les contraintes qu’elle impose et ses exigences en terme d’expérience utilisateur :

• Pour que tout paiement soit autorisé, il faut que l’utilisateur donne son consentement explicite au TPP (art. 64)
  Ce consentement explicite doit exposer clairement les données partagées au TPP ainsi que les actions qu’il peut réaliser.
• Au dessous de 150€ : l’authentification et autres règles que doivent suivre les prestataires ne s’appliquent pas (art.63)
• Avec l’accord explicite du client, le TPP peut être en charge d’indiquer la disponibilité des fonds lors d’une transaction (art. 65)
• Les PISP sont garants du bon déroulement du paiement et sont responsables de la sécurité des données, ils doivent y avoir un accès limité qui respecte leur besoin de gestion sans plus ni moins. (art. 66)
• Les AISP doivent protéger les données récoltées, mais ne peuvent les stocker ou les utiliser que dans des mesures de sécurité. Celles-ci doivent être collectées avec un consentement explicite de l’utilisateur. (art. 67)
• Les TPP peuvent émettre des instruments de paiement. Ils doivent dans ce cadre supporter les charges et mesures de sécurité liées à l’utilisation de cet instrument par le client (art. 70).
• Le TPP doit prouver le bon déroulement d’une transaction lorsque l’utilisateur nie avoir autorisé un paiement ou qu’il s’est mal déroulé. Si le paiement n’était pas autorisé, il revient au TPP d’effectuer un remboursement immédiat et doit indemniser les différentes parties s’il se trouvait responsable de la faute. Si l’authentification demandée à l’utilisateur ce dernier ne doit alors subir aucune perte liée à l’utilisation d’un instrument de paiement (art. 72-73-74).
• Un refus de paiement par un prestataire se doit d’être toujours accompagné d’une justification à l’utilisateur (art. 79)
• Un ordre de paiement est irrévocable une fois que l’utilisateur a donné son ordre il ne peut revenir en arrière (art. 80)
• Les paiements doivent être perçus dans la limite d’un jour, le paiement doit respecter les conditions de l’utilisateur à savoir montant, bénéficiaire, etc (art. 84 à 87).
• Les TPP peuvent utiliser les données si l’accord est explicitement exprimé par les utilisateurs, ces données peuvent être utilisées, que dans le cadre de démarches sécuritaires (fraude, prévention) (art. 94)
• Les TPP se doivent de maintenir des systèmes de sécurité élevés afin de prévenir tout incident (art. 95)
• Tout incident opérationnel doit être reporté aux autorités puis à l’ABE, la BCE et aux utilisateurs des TPP (art. 96)
• Une authentification forte (2 facteurs d’authentification ou 2FA) est exigée pour l’accès au compte bancaire, le paiement électronique ou toute opération à risque de fraude.

Ces articles ne donnent pas trop de détails concernant des points pratiques pourtant nécessaires à des applications concrètes. Avant qu’une jurisprudence fournie n’existe, des standards portés par plusieurs banques ont émergé pour tenter de concrétiser et détailler les articles de la directive : Berlin Group, Open Banking, STET (détaillés ci-après).

Dates clés d’application

En 2016, la directive DSP2 a été adoptée par la Commission Européenne, cependant il reste de nombreuses étapes clés avant sa mise en place :

• Mars 2019 : les banques devront être équipées des APIs pour mettre fin à la technique de web scraping et rentrer dans une phase de test six mois avant l’entrée en vigueur des RTS (Regulatory Technical Standards).
• Septembre 2019 : implémentation des normes techniques publiées en 2017 (soit 18 mois après l’application de la Directive DSP2).

Technique de contournement actuelle : le web scraping

Plusieurs prestataires contournent le manque d’APIs fournies par les banques en utilisant une technique dite de « web scraping ». Il s’agit «d’un ensemble de techniques pour extraire le contenu d’un site Web»  afin de les utiliser dans un contexte précis (AISP ou APSP). Cette technique pose de nombreuses limites, notamment concernant la sécurité, la gestion du consentement des utilisateurs, la protection des données ainsi que leur utilisation. Jusqu’alors dans la limite de la légalité, la pratique de web scraping sera définitivement interdite par les TPP pour être remplacée par les APIs à partir de mars 2019 (dérogation faite pour les banques n’ayant pas fourni d’API).

Nouveaux acteurs et agréments

Afin de devenir TPP (AISP ou PISP), les demandeurs doivent se soumettre aux agréments des autorités compétentes. En effet, dans la directive DSP2, des indications sont données dans le titre 5 quant aux demandes d’agrément : afin d’être légalement reconnu, un TPP doit fournir un ensemble de données aux autorités compétentes de son pays.

DSP2 & FCA pour le Royaume-Uni

Le FCA établit quatre types d’acteurs pour lesquels il peut fournir un agrément: PI (« Payment Initiator » équivalent à PISP), small PI (volume de paiement inférieur à 3 millions d’euros par mois), account information service provider (AISP).

Afin de devenir PI agrémenté, toute entreprise doit suivre un processus après s’être inscrit sur le compte du FCA, ce processus est décrit dans un document. La demande doit être effectuée par des personnes précises.

Source: FCA

De nombreuses informations sont demandées à la société :

1. Programme des opérations
2. Business plan
3. Organisation de l’entreprise et son type d’affiliation avec d’autres entreprises
4. Capital initial
5. Géolocalisation des activités
6. Mesures de sécurité et d’assurance
7. Gouvernance, contrôles internes et risque de management
8. Continuité d’activité et processus en cas d’accident sécuritaire
9. Gestion des données et leur analyse statistique
10. Responsables, auditeurs
11. Assurer l’intégrité, l’honnêteté, la réputation de sa demande et de son activité

En plus d’assurer l’agrément des acteurs, la FCA donne des indications quant à la protection des données et effectue une supervision des activités. FCA se donne le droit d’intervenir dans les activités  du TPP en cas de problèmes, et suit un processus en quatre étapes afin de le résoudre : identification du problèmes, les raisons du problèmes, les solutions et leur mise en place, puis enfin évaluation ldu résultat.

Source: FCA

DSP2 & ACRP pour la France

L’ACRP fournit un agrément spécifique pour les PISP et les AISP : « établissement de paiement » et « établissement de paiement avec agrément simplifié » (volume de paiement mensuel inférieur à 3 millions d’euros).

Pour obtenir l’aval de l’ACPR , il est nécessaire  pour les sociétés qui veulent devenir AISP ou PISP de soumettre une demande afin de suivre un « calendrier prévisionnel de réalisation ». Pour la suite l’entreprise doit transmettre un dossier et les justificatifs associés. Ce dossier comprend cinq grandes parties d’information sur le TPP postulant :

1. L’entreprise : informations traditionnelles sur la société (actionnariat, capital, structure, membres…)
2. Programme d’activité : quelles activités relatives à DSP2 l’entreprise compte elle mener ?
3. Plan d’affaires : fournir une étude de marché, un business plan, faire preuve d’un apport en capital initial minimum en fonction de son statut…
4. Structure organisationnelle / contrôle interne : fournir un organigramme détaillé avec les responsables et leurs CV ainsi qu’un mécanisme de contrôle interne
5. Procédures des systèmes de sécurité : fournir des descriptions des procédures d’accès aux données, de reporting, des responsables…
6. Continuité d’activité / police de sécurité : fournir une étude d’impact sur l’activité, description des mesures d’atténuation, schéma d’architecture des systèmes et réseaux…

Dans le cas où une entreprise souhaite étendre son activité, elle devra alors soumettre une demande spécifique (contenant la stratégie suivie, le calendrier de réalisation, les impacts attendus…). Il est également possible de déposer un dossier afin de demander une exemption d’agrément en fonction des critères suivants:

• Les conditions de sécurité des moyens de paiement
• Les modalités retenues pour assurer la protection des consommateurs

 Infrastructure API et DSP2

Notion d’API ouverte

Pour être conforme avec la réglementation européenne, il faut donc que les banques mettent en place une API ouverte. Les APIs sont des interfaces permettant à des systèmes indépendants d’interagir entre eux. Par exemple, lorsque Facebook demande un login pour pouvoir se connecter aux autres applications, une API intervient. Elles proposent certains avantages :

• Une interopérabilité, dans le sens où elles permettent à des systèmes élaborés dans divers langages de recevoir de l’information ou de donner des « ordres » à l’API
• Un échange de données « brutes » (fréquemment en Json)
• Un contrôle sur les accès donnés aux entités autorisées à faire des appels à l’API
• Une partition par utilisateur ou TPP sur les données partagées ou les actions possibles (un AISP ne pourra pas faire les mêmes actions qu’un PISP)

Les différents types de Strong Customer Authentication (SCA)

Dans le cadre de la directive DSP2, une authentification forte du client (SCA) est imposée afin de répondre à un besoin de sécurité face à de nombreuses transactions frauduleuses. Ce nouveau processus vise à s’assurer de l’identité du client au travers de deux éléments au moins qui correspondent aux critères suivants: être quelque chose que le seul le client sait (code PIN par exemple) ou que seul lui détient (un code envoyé sur le téléphone portable) ou que le client est (données biométriques). Certains systèmes existants sont déjà conformes avec cette norme comme 3DSecure par exemple. Au travers de DSP2 il est possible d’avoir différentes approches techniques de SCA. Voici les trois approches et leurs particularités:

• Redirect: l’approche « redirigée » consiste à procéder à l’étape d’authentification sur la plateforme de l’ASPSP, le client « quitte » donc la plateforme du TPP pour s’authentifier sur celle de l’ASPSP puis sera redirigé vers l’interface du TPP une fois l’authentification terminée.

Source : Entiros

• Decoupled: ici l’authentification s’effectue directement au travers de l’ASPSP sans redirection. En effet, le client va donner ses identifiants d’authentification au TPP qui va par la suite le transmettre à l’ASPSP. L’ASPSP grâce à ces identifiants effectuera le processus d’authentification, sans que le client n’ai quitté pendant tout ce temps la plateforme du TPP.

Source: Entiros

• Embedded : À travers de cette approche, le client donne non pas ses identifiants, mais les clés de son authentification comme quelque chose qu’il connait ou qu’il possède au TPP (un code éphémère envoyé par le ASPSP sur le téléphone, un code PIN uniquement en possession du client). Le TPP va par la suite transmettre ces réponses à l’ASPSP pour valider l’authentification.

Source: Entiros

Les différents types de paiements

• Single : paiement unitaire normal
• Future dated : paiements programmés à une date future afin d’avoir une meilleure gestion de sa liquidité. Nécessite une API adaptée.
• Bulk : paiements de masse ou ensemble de paiements qui sont executés ensembles. Nécessite une API adaptée.

Il est à noté qu’il existe des exemptions de SCA pour les paiements récurrents. En effet, normalement avant chaque paiement le client doit s’authentifier selon les normes demandées, cependant dans le cas d’un paiement régulier et récurrent, le client doit s’identifier uniquement  pour le premier paiement de la série et non pas tous. Par ailleurs, il est intéressant de constater que seul Berlin Group propose dans la structure de l’API de supporter tous les types de paiements. Le standard d’Open Banking a évoqué par le passé le sujet, sans pour autant l’incorporer dans sa documentation technique.

Plusieurs standards d’API autour de la directive Européenne

La directive Européenne énonce de nombreuses notions (sécurité, authentification forte, consentement explicite…) sans qu’un fort degré de détails puisse permettre de construire tel quel une API calquée sur les textes de la directive.

Des standards ont alors émergé pour donner une homogénéité nécessaire à la fois aux usagers et aux TPP. Pour les TPP il s’agit -lorsqu’ils sont en lien avec de multiples banques- d’intégrer facilement une nouvelle banque et que le travail d’intégration soit marginal. Pour l’utilisateur (le PSU) il s’agit d’avoir une homogénéité dans l’expérience utilisateur et la sécurité liée aux applications qu’il utilise.

Le standard STET / DSP2

Stet a publié une version 1.3 de son API.  Une documentation est également accessible permettant de visualiser la structure des appels et des réponses au standard d’API proposé par STET.
Les contributeurs à ce groupe de travail sont des banques françaises :

• BNP Paribas
• Le Groupe BPCE
• Le Groupe Crédit Agricole
• La Banque Fédérative du Crédit Mutuel
• CIC
• La Banque Postale
• La Société Générale
• La Caisse des Dépôts et Consignations
• Le Crédit Mutuel
• ARKEA
• HSBC France
• L’OCBF

L’API STET détaille :

• les prérequis et les détails techniques :
  • Une autorité tenant un registre des acteurs : permet d’identifier les parties prenantes et leur rôle (AISP, PISP, ASPSP)
  • Authentification croisée et cryptage des données
  • Authentification forte
  • Autorisation du TPP à interroger l’ASPSP et protocole OAuth2

L’ensemble de ces détails est résumé dans un tableau synthétique des protocoles de sécurité exigés et d’autres spécifications techniques comme le format d’échange de données
Source : STET

• Un modèle fonctionnel : décrit les relations techniques entre le PSU, le TPP et l’ASPSP.  À la différence d’un standard comme celui d' »Open Banking », ces modèles fonctionnels restent purement techniques mais ne vont pas jusqu’à suggérer des bonnes pratiques liées à l’expérience utilisateur.  Le modèle fonctionnel propose aussi des structures de données types lorsque l’API est appelée sur par exemple un historique de transaction ou l’interrogation du solde d’un compte bancaire. On trouve aussi dans le modèle fonctionnel des codes de retours d’erreurs (selon la norme ISO20022) liées à des problèmes de droits d’accès, réglementaires ou bien encore sur des suspicions de fraude.
• Des cas d’application : il s’agit d’exemples concrêts d’appels à l’API sur divers cas de figures.

Le standard OPEN BANKING / DSP2

L’Open Banking Implementation Entity (OBIE) a été créé par l’autorité des marché et de la concurrence du Royaume-Uni. Il vise à fournir un standard conforme avec DSP2 et à donner de l’information à la fois aux consommateurs mais aussi aux TPP (tiers ayant accès aux comptes ou initiant des paiements) et ASPSP (banques). Le standard Open Banking est relativement plus complet que le standard Stet.

Il fournit :

• un registre des acteurs autorisés
• un standard technique relatif à l’implémentation du consentement utilisateur
• un standard relatif au consentement de l’utilisateur du point de vue « expérience utilisateur »
• un système de règlement des litiges
• une documentation à l’attention des développeurs

Les principales banques anglaises qui ont contribué au protocole Open Banking sont :

• Royal Bank of Scotland Group
• Santander
• Barclays Bank
• HSBC
• Lloyds Group
• Nationwide
• Danske Bank
• Bank of Ireland
• Allied Irish Bank

Standard technique sur le consentement – Open Banking / DSP2

Le modèle Open Banking prévoit trois phases dans le consentement du client. A chacune de ces phases une série d’étapes est proposée :

Source: Open Banking

1. Le consentement : le TPP doit demander de manière explicite et claire à l’utilisateur d’avoir accès à ses données, elles-mêmes nécessaires à la structure Read/Write API. Open Banking propose un ensemble d’informations à transmettre au client lors de son consentement. Par exemple pour les PISP :
   – nom du TPP
   – montant du paiement
   – but du paiement
   – bénéficiaire du paiement
   – son référencement
   – détails du compte client
   – charges additionnelles…pour les AISP :
   – nom du TPP
   – informations demandées
   – accès aux données d’une période précise
   – date d’expiration d’accès aux données
   – but de la collecte de données et son utilisation
   – opération récurrente ou non…
2. L’authentification : selon Open Banking cette phase doit se dérouler sur la plateforme de l’ASPSP
3. L’autorisation : à cette étape l’utilisateur autorise l’ASPSP à répondre à la requête du TPP.  Tous les éléments de la demande du TPP doivent être résumés et à nouveau présentés à l’utilisateur.
   Ainsi pour les AISP, les ASPSP devront afficher les informations suivantes:
   – nom du TPP
   – informations demandées
   – accès aux données d’une période précise
   – date d’expiration d’accès aux données
   – but de la collecte de données et son utilisation
   – opération récurrente ou non…
   Et pour les PISP:
   – nom du TPP
   – montant du paiement
   – but du paiement
   – bénéficiaire du paiement
   – son référencement
   – détails du compte client Source : Open Banking

Le PSU devrait être en capacité de rejeter ou accepter la demande cependant pas d’avoir le pouvoir choisir quels éléments de la requête il rejette et lesquels il accepte. Concernant un paiement, le choix du compte peut être fait par le client au moment du consentement, ou lors de l’autorisation. Si cette dernière solution est envisagé il est conseillé de montrer la balance du compte afin de conseiller le PSU dans son choix.

Source: Open Banking

Le processus d’authentification et d’autorisation se déroule tout les 90 jours auprès de l’ASPSP ok si la demande de l’AISP n’excède pas 90 jours d’accès aux données.

Standard « expérience utilisateur » sur le consentement – Open Banking / DSP2

L’expérience utilisateur proposée par Open Banking apporte des conseils pour accompagner le client tout au long de l’échange entre TPP et ASPSP. Il suit aussi les trois étapes clés:

1. Consentement : il est ici conseillé de faire valoir une option opt-in concernant les données que le TPP peut utiliser, tout en expliquant explicitement les manières pour retirer son consentement. Les AISP devraient suivre le concept de data minimisation (limiter leur accès aux données uniquement à leur besoins). Pour rendre l’utilisation pus facile pour le client, le consentement peut être conjoint mais présenté séparément : le client donne son consentement à l’accès aux données reliées à l’API mais aussi pour des données que doivent utiliser les TPP pour d’autres aspects.
   
2. Authentification : lors de cette phase il est jugé primordial d’établir la confiance avec le consommateur et donc de différencier au plus l’interface de l’ASPSP avec celle du TPP  précédemment utilisée pour le consentement. Open Banking propose d’effectuer une authentification découplée : la première partie s’effectue sur une plateforme TPP et l’autre partie sur une plateforme ASPSP.
   Il est aussi important de noter que les accès de l’ASPSP ne sont pas partagés au TPP, ce qui constitue un renforcement majeur de la sécurité des accès et des données notamment par rapport aux techniques de webscrapping utilisées actuellement.
3. Autorisation : Open Banking suggère de combiner cette étape avec celle de l’authentification, mais aussi de catégoriser chaque autorisation en fonction des TPP et d’envoyer par la suite un récapitulatif de tout ce qui a été autorisé, une sorte de « reçu ».

Source: Open Banking

Tout au long du processus, il faut que le client se sente en confiance. C’est pour cela qu’Open Banking propose d’utiliser une communication active quant à la protection des données, et au contrôle du processus par le client, et une forte visibilité avec un affiche par étape, et une redirection claire lorsque l’ensemble de la manœuvre est terminée.

Système de règlement des litiges – Open Banking / DSP2

Dans le cadre  de la directive DSP2 les litiges sont évoqués, cependant aucun réel processus n’est proposé. On note simplement que le client est protégé, car la directive impose à l’ASPSP ou TPP de fournir les preuves à l’utilisateur du respect du processus en cas de litiges. Open Banking a mis en place un système appelé : « Dispute Management System » permettant de gérer au mieux les litiges entre ASPSP, TPP et PSU (les utilisateurs finaux). Ce système bien que n’ayant aucune valeur légale, est une proposition de process permettant de résoudre un problème rencontré entre l’une ou plusieurs de ces trois parties prenantes afin de régler le litige. Il est composé d’un code de bonnes pratiques, de documents permettant de résoudre les problèmes liés à l’activité des AISP ou PISP.

Trois documents sont proposés:

• Résolution de litige concernant un paiement : liste des documents de preuve à fournir, établissement de l’historique et détails du problème, informations sur les parties prenantes… liste des documents de preuve à fournir, liste du résumé des informations échangées, données sur le remboursement…
• Résolution de litige concernant les informations données : liste des documents de preuve à fournir, liste du résumé des informations échangées, données sur le remboursement…
• Document de mise en contact entre acteurs concernés par le litige : description du problème et de sa découverte avec résultat de résolution de conflit souhaité

Il est possible pour une entreprise de devenir membre du DMS (Dispute Management System). Dans ce cadre là, la société doit suivre un ensemble de principes (par exemple: échanger avec le PSU de manière honnête et équitable) et de standards de comportement (par exemple: en cas de litige l’entreprise se doit de reconnaitre le litige et procéder à un processus interne pour le résoudre).

Documentation pour les développeurs 

Open Banking fournit une documentation très fournie à l’attention des développeurs. Il ne s’agit pas d’une documentation dynamique de type « swagger » mais d’une documentation qui propose une structure sur les services permettant d’initier des paiements ou d’obtenir des informations sur les comptes. Cette structure décrit des « headers » qui sont des informations envoyées à l’API et des « Responses » qui sont les retours d’information de l’API.  L’adoption d’un cadre homogène est d’une importance capitale pour les TPP lorsqu’il s’agira d’intégrer de multiples API bancaires. L’importance est de taille également du point de vue homogénéité des informations et des actions pour l’utilisateur final.

Le standard Berlin / DSP2

The Berlin Group est un regroupement pan-européen crée en 2004 ayant pour but de définir les initiatives européennes concernant les standards interbancaires. Ils ont publié en février leur cadre 1.0 de la directive DSP2 appelé NextGenPSD2. Contrairement à OpenBanking ou Stet, NextGenPSD2 est un cadre (il explique la manière dont le système fonctionne tout en laissant le choix de la méthode) et non un standard (méthode unique pour appliquer DSP2).  Il permet donc d’avoir des structures d’API différentes à condition de respecter le « framework » proposé.  Parmi les contributeurs on peut retrouver:

• Mastercard
• Deutsche Bank
• Société Générale
• Postbank
• Swedbank…

Source: The Berlin Group

On retrouve dans l’initiative NextGenPSD2 deux guides:

• Directives d’implémentation
• Directives opérationnelles

Directives d’implémentation

NextGenPSD2 offre une grande liberté aux développeurs : de multiples particularités sont proposées au sein du cadre.

• Liberté d’implémentation concernant SCA : Embedded, decoupled, redirect, combination flow, OAuth2
• Liberté concernant le langage: syntaxe  JSON ou XML
• Pour la phase d’authentification et autorisation, possibilité d’utiliser OAuth2
• Diversité des options de paiements: single, future dated, bulk paiements et de la phase de consentement : detailed, global et offered consentement

Dans le document on peut retrouver de nombreux exemples d’application selon les différentes configurations appliquées. Ainsi, tout les exemples d’initiation de flux de paiement sont donnés en fonction du type de SCA choisi par le développeur, ou bien les différents aperçus pour un AISP qui regroupe pour un client des comptes multidevises.

Ainsi beaucoup de libertés sont laissé avec le cadre NextGenPSD2 ce qui peut offrir certains avantages pour le développeur, mais on pourrait lui reprocher le manque d’unité des structures API. Ce problème se retrouve dans l’expérience utilisateur ou aucun cadre n’est donné. Ce manque d’homogénéité pourrait aller à l’encontre des effets escomptés de la directive DSP2: uniformité, simplicité pour l’utilisateur, confiance dans les paiements en ligne…

Directives opérationnelles

Au travers des directives opérationnelles, NextGenPSD2 cherche à donner un cadre pour assurer le bon fonctionnement de la structure API. Ainsi, le rôle de chacun des acteurs y est délimité, les clés de compréhension des layers d’une structure d’API sont données, et des cas d’applications sont proposés (initiation d’un paiement simple, d’un paiement récurrent, avoir la liste des comptes…). Un protocole concernant les données (paiement, information sur le client…) est également établit afin d’être conforme aux règles édictées par la DSP2 et garantir au maximum le respect des informations sur les clients.

Voici quelques exemples de pistes données dans les directives opérationnelles:

• Processus pour un bulk paiement:

Source : Berlin Group

• Processus pour un paiement à répétition:

Source: Berlin Group

L’API Particeep

Particeep propose une API qui branchée à un core banking permet d’accéder à de l’information de compte ou d’initier des paiements. L’API dispose aussi de « webhooks » permettant de notifier facilement des utilisateurs sur des actions bien précises.

Quelques informations techniques relatives à l‘API Particeep :

• Protocole applicatif : REST
• Encodage : UTF-8
• Échange de données : JSON
• Format de dates : iso 8601
• Protocole d’autorisation : HMAC-SHA1 et bientôt OAuth (gérer les  accès TPP et délimiter des périmètres d’accès aux GET/POST/PUT/DELETE)

Pour discuter avec notre équipe de l’API Particeep, cliquez ici.