Entrée en vigueur le 13 janvier 2018, la deuxième directive sur les services de paiement (DSP 2) précise la notion de « fournisseur de service de paiement » (Payment Service Provider, PSP), introduite par la précédente version. Parmi ces PSP, elle distingue notamment les « fournisseurs de service de paiement gestionnaire de compte » (Account Servicing Payment Service Provider, ASPSP), à savoir les établissements bancaires. Elle définit aussi formellement différents services :
- un service d’information sur les comptes (Account Information Service, AIS) permettant à un client d’obtenir une vision agrégée de l’ensemble des comptes qu’il détient auprès de différents établissements bancaires ;
- un service d’initiation de paiement (Payment Initiation Service, PIS) destiné notamment aux acteurs du commerce ;
- un service destiné aux fournisseurs de moyens de paiement de type carte (Payment Issuer Instrument Service, PIIS) permettant de vérifier si le montant d’un achat peut être couvert par les fonds disponibles sur le compte associé à une carte de paiement.
Les solutions techniques préexistantes
Ces services ne sont pas nouveaux : la plupart existent au travers de technologies de screen scraping où le fournisseur de service, empruntant les identifiants du client final, se connecte aux services de banque en ligne des établissements bancaires afin de récupérer les données nécessaires.
Ces technologies posent plusieurs problèmes, notamment en termes d’optimisation et de sécurité. En effet, l’utilisateur final est amené à confier à un tiers ses éléments d’identification et d’authentification pour l’accès aux services de banque en ligne. Si, à la suite d’une attaque informatique, les informations détenues par le tiers sont divulguées, l’utilisateur final court le risque de voir ses comptes bancaires impactés par des opérations frauduleuses. La traçabilité des accès n’est plus formellement assurée, le partage des identifiants de connexion ne permettant plus de savoir qui, du client final ou du fournisseur de service, est effectivement connecté. Enfin, l’ensemble des données disponibles (comptes, prêts, assurances…) est alors accessible au fournisseur de tiers, sans que le client puisse en restreindre le périmètre.
Les solutions d’API
Les technologies de screen scraping sont amenées à être remplacées par des technologies d’API (Application Programming Interface) grâce auxquelles un établissement bancaire peut offrir des services d’accès aux données ou de traitement via un protocole clairement spécifié et dans des conditions de sécurité optimales.
La publication de spécifications communes pour les API permet une mise en œuvre homogène par un ensemble d’établissements bancaires. Ainsi, le fournisseur de service DSP 2, FinTech ou établissement bancaire, voit, en tant que client de ces API, ses efforts de développement minimisés et standardisés.
Au travers de ces API, les contraintes de sécurité sont mises en œuvre, notamment dans le respect des standards de sécurité (
- l’authentification forte est privilégiée, remplaçant la simple utilisation d’un mot de passe statique par celle de certificats électroniques, mots de passe dynamiques, facteurs biométriques… Le stockage des mots de passe statiques est désormais reconnu comme un risque systémique, au vu des risques massifs d’attaque et de divulgation ;
- l’authentification forte concerne l’ensemble des acteurs, établissements bancaires, fournisseurs de services et clients finaux, notamment lorsque ces derniers accéderont à leurs données bancaires, que ce soit directement au travers des banques en ligne ou via un agrégateur ;
- cette authentification est complétée par des mécanismes de délégation d’autorisation d’accès permettant au client final de contrôler le périmètre exact du fournisseur de service ;
- l’ensemble des données, notamment les données bancaires, est échangé de façon à assurer leur confidentialité et peut également faire l’objet de mécanismes de signature électronique afin de garantir l’authenticité, voire assurer la non-répudiation.
- celles d’open banking, au Royaume-Uni, sont issues d’un projet plus large que le périmètre initial de la DSP 2 et auquel les grands établissements britanniques ont participé ;
- celles de STET, qui a travaillé avec la Place française pour la constitution d’une interface commune proposée par la communauté bancaire française pour ses besoins propres, mais ouverte à d’autres communautés ;
- celles du Berlin Group, qui a adopté une démarche paneuropéenne regroupant de nombreux acteurs bancaires de l’Union européenne ;
- d’autres initiatives nationales sont également publiées, ou en passe de l’être, en Pologne et en Slovaquie ;
- certains établissements bancaires européens proposent par ailleurs leurs propres interfaces d’API.
Une démarche européenne et au-delà
L’annonce et la publication des différentes initiatives d’API ont conduit les acteurs du marché, autorités, établissements bancaires, fournisseurs de service, représentants des consommateurs et du commerce, à se réunir au sein d’un groupe de travail de l’ERPB (Euro Retail Payments Board) afin de partager une même compréhension du sujet, d’analyser les points nécessitant clarification et de définir une démarche commune.
Les différentes initiatives d’API ont été invitées à se rapprocher afin de comparer leurs travaux respectifs, d’analyser leurs différences et d’imaginer comment les résoudre. C’est ainsi que le Berlin Group et STET ont entamé des travaux de convergence importants permettant d’harmoniser certaines structures de données ou certains paramètres techniques. Ces travaux, qui ont déjà eu pour résultat une nouvelle publication de spécifications de part et d’autre, sont amenés à se poursuivre, en intégrant si possible les autres acteurs.
Toutefois, le sujet des API bancaires est beaucoup plus global et concerne également de nombreux pays en dehors de l’Europe, notamment la Chine, les États-Unis, le Canada, Singapour…
Dans ce cadre, l’Organisation internationale de normalisation (International Organisation for Standardisation – ISO) a initié un groupe de travail spécifique sur l’élaboration de standards d’API bancaires. La communauté bancaire française et STET en sont des membres actifs.
STET a par ailleurs initié des travaux de modélisation de son API dans le cadre du référentiel ISO 20022. Ils seront prochainement élargis au Berlin Group, dans le cadre des travaux de convergence entre les deux API.
Les spécifications de l’API STET
À l’été 2016, STET a donc été mandatée par ses actionnaires pour coordonner les travaux des établissements bancaires français en vue de produire une spécification commune d’API. Destinée à la communauté bancaire française, elle ne devrait toutefois pas y être limitée, afin d’être utilisable par d’autres communautés.
Une première version a été publiée en juillet 2017, après un an de travaux consacrés aux sujets bancaires et techniques. Ces travaux ont également intégré des études juridiques et les réflexions menées au niveau européen.
À la suite de la publication finale des standards de sécurité, rédigés par l’ABE, amendés par la Commission européenne et adoptés par le Parlement et le Conseil européen en mars 2018, une nouvelle version des spécifications STET a été publiée dès le mois
Cette version sert actuellement de base aux travaux du groupe de travail créé par le Comité national des paiements scripturaux (CNPS) en vue de valider l’adéquation fonctionnelle et réglementaire de l’API STET avec l’ensemble des acteurs de la Place française. Une démarche analogue a été initiée à l’échelle européenne, à la demande de la Commission, par la mise en place d’un groupe de travail d’évaluation des API (API Evaluation Group).
Caractéristiques techniques et fonctionnalités
Les spécifications de l’API STET s’appuient sur des standards techniques reconnus mondialement. Les exigences de sécurité sont ainsi mises en œuvre à travers l’utilisation des protocoles TLS et OAUTH2, et la mise en œuvre de certificats électroniques conformes au règlement européen eIDAS. Les données sont échangées au moyen d’une interface REST en utilisant le format de données JSON et en se basant sur la définition des structures de données ISO 20022.
Les services d’information sur les comptes sont assurés par l’API au travers des fonctionnalités suivantes :
- liste des comptes de paiement accessibles ;
- liste des soldes applicables sur un compte de paiement ;
- liste des transactions imputées ou en attente d’imputation sur un compte de paiement.
Le service d’initiation de paiement permet au fournisseur de service :
- d’initier une demande de paiement à la demande d’un commerçant et d’en suivre le traitement ;
- d’initier, à la demande du titulaire du compte, une demande de transfert vers l’un de ses bénéficiaires.
D’une contrainte à une opportunité
L’adoption de la DSP 2 a conduit les établissements bancaires européens à imaginer une alternative aux technologies de screen scraping actuellement utilisées par les fournisseurs de services. Cette démarche a été initialement considérée comme une contrainte, la DSP 2 imposant un accès gratuit et sans autre barrière que le respect du consentement de l’utilisateur final. Elle interdit en particulier que cet accès soit soumis à un contrat. Toutefois, la possibilité pour les établissements bancaires d’agir eux-mêmes en tant que fournisseurs de services DSP 2 vis-à-vis des utilisateurs finaux est, en soi, une opportunité.
L’initiative « Open Banking », au Royaume-Uni, montre par ailleurs qu’au-delà de la DSP 2, certaines données gérées par les établissements bancaires peuvent être également rendues accessibles au travers d’une API : géolocalisation des DAB/GAB, services bancaires proposés et coûts d’utilisation… Du fait des conditions contractuelles d’utilisation qui peuvent s’appliquer dans ce cadre, la démarche API devient alors également source d’opportunités.
Enfin, dans le périmètre strictement interne de son système d’information (SI), la démarche API constitue une voie intéressante dans la réorganisation et la refonte de l’architecture de ce SI.
