La DSP2 et l'Open-Banking

Depuis quelques années, les métiers de la banque font face à l'émergence de nouveaux entrants digitaux :  on peut notamment citer les « fintechs » (de l'anglais financial technology) ou encore les GAFA (Google, Amazon, Facebook et Apple).

Cette mutation du secteur bancaire s'inscrit dans un nouveau contexte juridique, celui de la seconde Directive sur les Services de Paiements (DSP2). Celle-ci est entrée en vigueur le 13 janvier 2018 en Europe et ouvre la voie à l'Open Banking : il s'agit d'une stratégie visant à inciter les banques à ouvrir leurs systèmes d'information afin de stimuler la concurrence et l'innovation dans le secteur.

L'un des volets de la DSP2 est donc relatif à l'ouverture du marché à de nouveaux acteurs de paiements. Il s'agit de leurs donner accès aux informations sur les comptes de paiement via des canaux de communication sécurisé : les API.

Il convient de définir ce qu'est une API.  Une Interface de Programmation Applicative API (de l'anglais Application Programming Interface) est un moyen structuré permettant à des applications tierces d'exposer des services ou des données internes. On parle d'Open API, lorsque les API sont exposées à des tiers extérieurs à la structure : les TPP.

La Figure 1 représente schématiquement comment les Open API servent d'interface entre les prestataires de services de paiement tiers (TPP) et les banques (ASPSP) :

Figure 1 : Architecture d’interfaçage par API pour l’Open Banking (source : Livre Blanc Galitt et DS Avocats - Open Banking)

Les services mis à disposition des TPP

Un TPP, de l'anglais Third Party Provider, est un prestataire tiers de services pouvant proposer, au regard de la DSP2, les trois services ci-dessous :

• Le service d'initiation de paiement (PISP : « Payment Initiation Service Provider ») initie un ordre de paiement à la demande d'un utilisateur et à partir d'un compte de paiement détenu auprès d'une banque (ASPSP[1] : « Account Servicing Payment Service Provider ») ;
• Le service d'information sur les comptes (AISP : « Account Information Service Provider ») agrège les informations concernant un ou plusieurs comptes de paiement détenus par un utilisateur auprès d'une ou de plusieurs autres banque (ASPSP).
• Le service d'émission d'instrument de paiement lié à une carte?(CBPII : « Card-based Payment Instrument Issuer ») permet de vérifier en temps réel la disponibilité des fonds sur le compte à vue d'un client.

[1] Un ASPSP est une institution financière (une banque en général, une fintech…) au sein duquel un utilisateur détient un compte de paiement et à partir duquel l'utilisateur peut initier un paiement. Un ASPSP doit détenir l'agrément d'établissement de paiement (EP).

L'ouverture du marché à ces trois nouveaux services de paiement ouvre donc la possibilité à un tiers (TPP) de faire l'intermédiaire entre un utilisateur et une banque (ASPSP).

Le schéma (Figure 2) représente le fonctionnement d'un service d'initiation de paiement (PISP) au regard de la DSP2.

Figure 2 : Fonctionnement prévu d'un PISP selon la DSP2 (source : Livre Blanc Galitt et DS Avocats - Open Banking)

Cette situation (Figure 2) est susceptible de se présenter dans le cas d’un paiement sur un site de commerce en ligne. Au moment du paiement, les clients pourront choisir d’utiliser un PISP (Lydia par exemple) à côté des méthodes traditionnelles (CB / Visa / Mastercard). S’il choisit cette méthode, le client devra au préalable autoriser le PISP à accéder à son compte. Pour cela, il lui suffira de s’authentifier auprès de sa banque.

Coté LCL, avec le Projet DSP2-Chantier3 (SNI/BPI) nous travaillons à la conception de ces interfaces dédiées (API DSP2) afin que les tiers prestataires de services de paiement (TPP) puissent délivrer leurs services d'agrégation ou d'initiation de paiement.

Afin de se conformer à cette réglementation, nous devons donc proposer aux Tiers de paiement agréés (TPP) un accès aux comptes de paiement de nos clients communs.

Cet accès s'effectue de façon sécurisée, en effet la DSP2 impose également aux TPP :

• D'être agréé par une National competent authority (NCA), un organisme de supervision national (l'ACPR en France ou la CSSF au Luxembourg par exemple) ;
• D'utiliser deux certificats eIDAS pour établir les connexions aux API (certificat QWAC) et signer leurs requêtes (certificat QSEAL).

Trois API DSP2 sont actuellement en Production chez LCL :

• API Set-Up : permet à un TPP de s'enregistrer afin d'utiliser nos API AISP et PISP
• API AISP - Private & Business : permet à un TPP d'agréger des comptes LCL pour le marché RETAIL CLI/CLA
• API PISP - Private & Business : permet à un TPP d'initier des virements pour le marché RETAIL CLI/CLA

Plus d'une vingtaine de TPP ont déjà intégré nos API DSP2 LCL, parmi lesquelles Linxo et Bankin' (les principaux TPP français) ou encore Sofort/Klarna (Allemagne), Tink (Suède).

Nous prévoyons encore de publier trois nouvelles API :

• AISP - Business & Corporate (développements terminés en cours de validation fonctionnelle – mise en production prévu pour fin T1 2022) : permettra à un TPP d'agréger des comptes LCL pour le marché PRO et ENT.
• PISP - Business & Corporate (à l'étude) : permettra à un TPP d'initier des virements pour le marché PRO et ENT.
• CBPII : permettra à un TPP de vérifier en temps réel la disponibilité des fonds sur le compte à vue d'un client LCL.

Ci-dessous, le lien vers notre store API. C'est ici que nous publions toute la documentation technique (les swaggers) nécessaire aux TPP pour l'intégration de nos API :

https://developer.lcl.fr/

Pour plus d’informations sur le sujet, veuillez contacter Samir GOMRI (SNI/BPI).