Dans le cadre de la deuxième Directive sur les Services de Paiement (DSP 2), un Prestataire de Service de Paiement Gestionnaires de Compte (PSPGC) doit s’équiper, d’ici le 14 septembre 2019, d’une interface dédiée d’accès aux comptes de paiement accessible en ligne pour permettre une identification et un échange sécurisé entre l’utilisateur de paiement, les Prestataires de Services d’Initiation de Paiement, les Prestataires de Services d’Information sur les Comptes et les prestataires de services de paiement émetteur d’instrument de paiement lié à des cartes (TPP).
À cette fin, un PSPGC doit :
- déterminer l’interface de programmation (API) sur la base de laquelle il construira son interface dédiée ;
- avoir sollicité et obtenu de son Autorité Nationale Compétente (ANC) une exemption de solution de repli en cas de défaillance de son interface dédiée ; et
- avoir mis un dispositif d’essai de cette interface dédiée à la disposition des TPP d’ici le 14 mars 2019.
1. LES 3 NIVEAUX (LEVELS) DU CADRE RÉGLEMENTAIRE EUROPÉEN
1.1 Le niveau 1 : la DSP 2
Pour mémoire, la DSP 2 a été adoptée le 25 novembre 2015 et est entrée en vigueur le 13 janvier 2018.
L’article 98 de la directive donne mandat à l’Autorité Bancaire Européenne (ABE) pour soumettre à la Commission un Projet de Normes Techniques (RTS) relatif à l’authentification forte et à la communication sécurisée en vue de leur adoption sous forme de règlement délégué.
1.2 Le niveau 2 : le règlement délégué 2018/389, pierre maîtresse des API
Les principales dispositions du règlement délégué 2018/389
L’article 30 dispose que les PSPGC doivent mettre à disposition des TPP, le 14 mars 2019, un dispositif d’essai pour permettre aux TPP de tester les logiciels et applications qu’ils utiliseront pour proposer des services de paiement aux utilisateurs de services de paiement à partir du 14 septembre en lien avec les API.
Commentaire sur l’article 30 : ce dispositif d’essai implique des échanges entre PSPGC et TPP.
L’article 31 dispose que le PSPGC doit mettre à disposition soit, une interface dédiée, soit permettre l’utilisation par les TPP des interfaces servant à l’authentification et à la communication entre l’utilisateur de services de paiement et son PSPGC.
Commentaire sur l’article 31 : les PSPGC optent plutôt en pratique pour l’interface dédiée d’accès aux comptes de paiement.
L’article 32 dispose que les PSPGC qui mettent en place une interface dédiée doivent veiller à ce que cette interface n’entrave pas les prestations des services d’initiation de paiement et d’information sur les comptes.
Commentaire sur l’article 32 : volonté du législateur européen de favoriser le développement des TPP face aux acteurs traditionnels.
L’article 33 stipule que le PSPGC doit concevoir son interface dédiée avec une « solution de repli » (fall-back solution), c’est-à-dire des mesures d’urgence au cas où l’interface ne fonctionnerait pas conformément à l’article 32, ou serait indisponible de façon imprévue.
Le PSPG peut toutefois être exempté de construire cette solution de repli par son ANC si son interface dédiée remplit les quatre conditions suivantes :
- elle est conforme aux obligations prévues à l’article 32 ;
- elle est conçue et testée conformément à l’article 30, c’est-à-dire à la satisfaction des TPP qui l’ont testée ;largement testée par des TPP ; et tout problème lié à l’interface est résolu sans retard injustifié.
L’article 33 organise par ailleurs une concertation entre l’ABE et les ANC des États membres pour garantir une harmonisation au niveau européen des conditions d’exemption de « solution de repli » des interfaces dédiées.
Commentaire sur l’article 33 : volonté du législateur européen d’organiser une concertation entre l’ABE et les ANC sur les conditions que les interfaces dédiées doivent remplir pour être conformes au règlement délégué 2018/389.
1.3 Le niveau 3 : l’avis de l’ABE du 13 juin 2018 sur la mise en œuvre de l’authentification forte et la communication sécurisée
2. L’API EVALUATION GROUP (API EG) : un exercice d’autoréglementation voulu par la Commission
En laissant volontairement une marge d’interprétation du règlement délégué 2018/389 aux autorités publiques et acteurs privés pour l’élaboration des API et interfaces dédiées, il a fallût prévoir l’harmonisation future de ces interprétations.
Cela a été rendu possible par la mise en place :
d’abord au niveau européen, sous l’impulsion de la Commission européenne, de l’API EG
puis par la mise en place au niveau de chaque État membre, sous l’impulsion de l’ABE, de groupes de travail nationaux rassemblant autorités publiques et acteurs nationaux. En France un GT « Interface DSP 2 d’accès aux comptes de paiement » a été mis en place le cadre du Comité National des Paiements Scripturaux.
2.1 L’API EG
L’API EG a pour objectif d’évaluer les initiatives d’API qui serviront de base aux interfaces dédiées des PSPGC, au regard des fonctionnalités requises par la DSP 2.
Les trois associations bancaires européennes (FBE, EACB et ESBG), des représentants de TPP, des consommateurs et commerçants participent à l’API EG.
La Commission européenne, la Banque Centrale Européenne et l’ABE font office d’observateurs. Son secrétariat est assuré par « European Payments Council » (EPC).
L’API EG a dû répondre à des questions juridiques indispensables à la conception des API, concernant notamment le consentement que le PSU doit donner lorsqu’il utilise une interface dédiée.
2.2 Question juridique sur le « consentement explicite » du PSU lors de l’intervention d’un TPP
L’expression « consentement explicite » existe à la fois dans la DPS2 et le RGPD qui lui est postérieur.
L’article 94.2 de la DSP 2 relatif à la protection des données stipule que les TPP « n’ont accès à des données à caractère personnel nécessaire à l’exécution de leurs services de paiement, ne les traitent et ne les conservent qu’avec le consentement explicite de l’utilisateur de services de paiement ».
La question est de savoir si cette expression a le même usage dans les deux textes d’une part et si le PSPGC doit ou non vérifier que l’utilisateur du service de paiement a effectivement donné son consentement pour l’intervention d’un TPP d’autre part.
La position de la Commission :
le terme consentement explicite de l’article 94.2 de la DSP 2 ne doit pas être rapproché de l’usage de ce terme dans le RGPD ;
s’agissant des rapports entre le TPP et l’utilisateur de service de paiement, qui par hypothèse sont régis par un contrat, le traitement des données est licite parce qu’il est nécessaire à l’exécution du contrat conclu entre eux. Le consentement de l’utilisateur repose sur le contrat conclu entre eux => fondement de l’article 6.1 b du RGPD ;
s’agissant des rapports entre le PSPGC et le TPP, qui par hypothèse ne sont régis par aucun contrat puisque la fourniture de services de paiement n’est pas subordonnée à l’existence de relations contractuelles entre eux, la transmission de données entre le PSPGC et le TPP est licite car il s’agit d’une obligation légale résultant de la DSP 2 => fondement de l’article 6.1 c du RGPD ;
le PSPGC ne doit pas vérifier si l’utilisateur de service de paiement a donné son consentement au TPP.
Cette position de la Commission a été confirmée tout à la fois pas par le Comité Européen de la Protection des Données (Lettre 05/07/2018 Sophie in’t Veld) et par L’avis de l’ABE du 13 juin 2018 sur la mise en œuvre des RTS.
2.3. Les fonctionnalités des API et interfaces dédiées
L’API EG travaille sur un document recensant :
les fonctionnalités que doivent remplir les initiatives d’API pour servir de base à des interfaces dédiées qui puissent être conformes à la DSP 2 ;
les fonctionnalités que doivent remplir les interfaces dédiées elles-mêmes, pour obtenir de leur ANC une exemption de solution de repli, étant précisé que chaque PSGC est libre de retenir une partie seulement des fonctionnalités offertes par l’API dont il se sert.
L’API EG s’inspire des préconisations publiées par l’ABE le 13 juin 2018, dans un avis relatif à la mise en œuvre des RTS sur l’authentification forte et la communication sécurisée.
L’avis de l’ABE comporte notamment un tableau des principales conditions devant être remplies par les interfaces dédiées et les API (voir tableau 2).
Enfin, des réunions de l’API EG ont été programmées jusqu’en fin 2018 pour permettre la convergence des initiatives nationales d’API.
3. Les travaux du GT « Interface DSP 2 d’accès aux comptes de paiement » dans le cadre du Comité National des Paiements Scripturaux en France
Objectif du GT : définir les fonctionnalités d’une API de place répondant aux exigences de la DSP 2 et ayant vocation à établir un consensus entre les PSPGC, les PSIC et les PSIP, en s’appuyant sur l’initiative française d’API de STET.
Il est coprésidé par la Banque de France et la Direction Générale du Trésor.
Il rassemble les acteurs concernés par les projets d’interfaces d’accès DSP 2, du côté des PSPGC, PSIC et PSEIPC.
