DSP2 : trois mois après, Budget Insight fait le bilan

« Ça va, personne n’est mort ? », lance en introduction, avec un grand sourire, un représentant de l’ACPR (Autorité de Contrôle Prudentiel et de Résolution). Cette scène se déroule le mardi 30 septembre 2019 au CNPS (Comité National des Paiements Scripturaux), à une des (nombreuses) réunions tenues depuis près de deux ans entre le régulateur, les ASPSP (Account Servicing Payment Service Providers : prestataires de services de paiement gestionnaires de comptes, principalement les banques) et les TPP (Third Party Providers : prestataires de services de paiement tiers, essentiellement agrégateurs et initiateurs de paiement). Effectivement, personne n’est mort, et pour cause, au 14 septembre, à l’heure où réglementairement tous les tiers de confiances avaient pour obligation de passer par les API des banques, rien ne s’est passé. Car personne n’était prêt.

En séance, L’ACPR annonce la liste des ASPSP qui sont « exemptés » de mécanisme de secours devant une salle atterrée. Car si la loi prévoit une attribution de ces exemptions après constatation d’une utilisation massive (« widely used ») des API, aucun de ces établissement ne peut se targuer d’avoir vu son API utilisée en production ne serait-ce que par un seul TPP. La page de redirection du Crédit Agricole présentait encore quelques semaines auparavant, et sur une longue période, un bug la rendant inopérante. Pas de quoi rassurer Bankin’, Linxo et nous-mêmes pour faire reposer dessus la connectivité vers l’un des établissements bancaires français représentant le plus de trafic.

Aux TPP demandant la marche à suivre si de tels problèmes surviennent dans le futur, le régulateur répond qu’ils peuvent “toujours utiliser le mécanisme de secours ». Sauf que… cette banque est exemptée de mise à disposition d’un mécanisme de secours !

C’est avec ce tableau ainsi posé que débute la période de trois mois accordée par l’ACPR pour laisser les TPP et les ASPSP assurer la transition vers les API et l’authentification forte.

Des sandbox non représentatives

Le calendrier réglementaire prévoyait initialement une période de six mois entre la publication des sandbox (14 mars 2019) et le passage aux API de production (14 septembre 2019). Très rapidement, nous nous sommes rendu compte que les sandbox, à part fournir un tableau faussé d’une API STET ou BerlinGroup retournant des données fictives, ne sont en rien représentatives des véritables API. Les jeux de données sont en général insuffisants, les bugs ne sont pas les mêmes selon les environnements, les parcours de redirection non plus, et il est impossible de s’assurer de l’équivalence des données avec l’accès direct. Nous avons donc rapidement compris que les sandbox représenteraient une perte de temps et nous avons concentré nos efforts sur les API de production.

Absence de certificats eIDAS

Ces API n’ont été mises à disposition que tardivement, mais surtout, nous avons rencontré un autre problème de taille pour pouvoir nous y connecter : l’absence de certificat eIDAS. Les QTSP (Qualified Trust Services Providers : autorités de certification reconnues par l’Europe pour délivrer des certificats eIDAS) ont commencé à se positionner fin 2018, et n’ont été en mesure de délivrer leurs premiers certificats en juin 2019. Par conséquent, la plupart des TPP n’ont pu commencer leurs tests sur les quelques API de production disponibles qu’à partir de juillet.

Ainsi, alors que le 14 septembre devait annoncer la fin des travaux d’intégration, nous n’en étions encore qu’au début. Une semaine après la réunion du CNPS, le mardi 3 octobre, la réunion trimestrielle API WorkingGroup de l’EBA s’est tenue à Paris (Brexit oblige). À cette occasion, les banques ont assuré que tout allait bien et les TPP que tout allait mal. La vérité se situe entre les deux.

L’un des arguments régulièrement opposé aux TPP historiques est que si certains parviennent à se connecter aux API, cela signifie qu’elles sont fonctionnelles. Et en effet, lorsqu’un nouveau TPP arrive sur le marché, il utilise ce qu’il trouve à sa disposition. Nous, « les anciens », qui passions par le scraping, étions habitués à avoir la même qualité de service que le PSU (Payment Service User, les clients des banques) et la même quantité de données que celles à laquelle il a accès. Et il est normal que l’on se plaigne face à une liste de comptes non identifiés par un IBAN, à des transactions avec des libellés tronqués, à l’absence des opérations à venir, à une liste de bénéficiaires incomplète…

Nous savons que les banques font des efforts. Lorsque BNP Paribas affirme lors de cette réunion à l’EBA que le programme de mise en conformité DSP2 a coûté au groupe des dizaines de millions d’euros, je veux bien le croire et je le déplore. Malgré tout je pense, comme je le disais il y a quelques mois, qu’il ne s’agit pas, pour les banques, d’une énième facture de mise en conformité réglementaire mais d’une opportunité qui va leur permettre de s’insérer dans la nouvelle économie d’API.

L’authentification forte tous les 90 jours menace l’activité des TPP

De cette réunion, je n’attendais pas grand chose, mis à part concernant l’authentification forte déléguée. Mais ce mince espoir a été déçu. Larisa Tugui, experte de l’EBA, a même demandé pourquoi ce sujet revenait systématiquement sur la table, alors qu’il est pour nous LE vrai problème de la DSP2. Car nous pouvons espérer qu’à plus ou moins long terme, les API seront conformes et fonctionnelles. Mais il subsiste un énorme point noir dans les textes : la réauthentification forte (SCA) tous les 90 jours. Et malgré tous les groupes de travail sur un « redirect fluide », c’est cette disposition qui va tuer beaucoup de cas d’utilisation des API AIS. Comment envisager par exemple qu’un chef d’entreprise donnant l’accès aux comptes bancaires de son entreprise à son expert-comptable soit obligé d’entrer de nouveau tous les 90 jours son identifiant, son mot de passe et un second facteur d’authentification pour l’ensemble de ses banques ? Alors que le mandat EBICS (Electronic Banking Internet Communication Standard) signé manuscritement et donnant accès à des fichiers CFONB (Comité français d’organisation et de normalisation bancaire) via FTP a une durée de vie illimité?

Il sera en tout cas opposé aux TPP que le principe de délégation de la SCA n’est pas contraire aux textes, mais qu’elle nécessite un accord bilatéral. Autant dire un travail de fourmi si l’on espère parvenir à une couverture complète du marché (ce qui est illusoire).

Les TPP prennent les discussions en main

Depuis plusieurs mois, nous avions réussi à faire imposer un groupe de travail réunissant ASPSP et TPP sous l’égide de l’AFEPAME (l’Association Française des Établissements de Paiement et de Monnaie Électronique), avec la bienveillance de l’ACPR, et ce malgré le fait qu’il ait été boycotté initialement par plusieurs grandes banques françaises. La séance du jeudi 8 octobre a été très constructive, en portant sur des problèmes fonctionnels ou techniques, notamment l’accès aux IBAN des comptes des utilisateurs, la capacité de savoir s’il s’agit d’un compte particulier ou professionnel, l’identification des opérations de cartes à débit différé ou les dates de déploiement des mécanismes de SCA.

Le jeudi 24 octobre, Budget Insight a aussi organisé à Station F un débat fort intéressant réunissant représentants de banques et TPP mais également Julien Lassalle, principal interlocuteur de la Banque de France sur la DSP2 avec Geoffroy Goffinet (adjoint au directeur des autorisations de l’ACPR). Le débat fut riche. Principal point d’achoppement : la gestion de la SCA par les banques et sa conséquence directe – le manque de fluidité évident des parcours redirect proposés.

Fluidité du redirect

Les réunions à la STET étaient fréquentes en 2018 pour travailler sur la définition du standard STET. Ce sont des réunions que j’affectionnais particulièrement. Techniques et boudées par les politiciens (aussi bien ASPSP que TPP), elles permettaient dès lors plus aisément d’avoir des échanges rationnels et constructifs. Néanmoins, durant celle du jeudi 31 octobre 2019, nous avions pas grand chose à nous dire. Car les problèmes qui sont rencontrés par les TPP concernent soit des non respects du standard STET, soit des choix qui ne peuvent être résolus par des spécifications techniques. Par exemple, aujourd’hui, savoir si l’on documente PKCE (Proof Key for Code Exchange) comme extension de OAuth 2.0 n’a pas trop d’intérêt, puisque les banques ont déjà toutes implémenté STET comme elles le souhaitent.

Les réunions AFEPAME et CNPS qui suivirent les lundi 4 et mardi 5 novembre étaient en revanche plus intéressantes. Le principal sujet abordé fut celui de la fluidité du parcours de « redirection web », le seul proposé aujourd’hui par les banques, et ce alors que l’EBA a rappelé l’obligation qu’ont les ASPSP de fournir un parcours « app-to-app ». Un exemple de ce dernier parcours peut être trouvé sur cette vidéo de Yolt qui montre leur intégration avec Starling Bank. Aux antipodes de ce que l’on peut trouver chez la plupart des établissements français, et ce en dépit des nombreux ateliers « redirects fluides » qui ont eu lieu en 2018 entre les ASPSP et les TPP. C’est à cette occasion que nous avons compris que nous allions devoir scraper les redirects qui ne seront pas considérés comme suffisamment fluides.

Un autre sujet qui a émergé à cette occasion, et trop tardivement, est l’impossibilité de réaliser des virements vers des comptes internes à la banque via les API de plusieurs établissements. En effet, sur la plupart des banques en ligne, lorsque l’on souhaite réaliser un virement depuis un compte courant, il est possible de choisir un compte épargne dans la liste des bénéficiaires. On pourrait dès lors s’attendre à les retrouver également dans l’API, puisqu’il s’agit d’une opération sur des comptes de paiement. Or, certains ASPSP estiment que puisque les comptes cibles sont des comptes d’épargne, ce serait mettre les pieds sur un terrain glissant que de les intégrer dans l’API. Résultat : par exemple, si je suis client Crédit Mutuel et que je souhaite épargner via un agrégateur comme Lydia ou Max, je pourrais le faire vers mon compte épargne Société Générale mais pas vers celui du Crédit Mutuel ! L’ACPR a vivement fait remarquer l’incongruité de cette situation, et a fortement incité les banques à y remédier.

De la même manière, plusieurs API ne permettent pas de réaliser des virements vers des non bénéficiaires – les banques arguant que ce n’est pas possible depuis l’interface en ligne. Or, il s’agit de l’essence même de la DSP2 de permettre la réalisation de paiements marchands… et la SNCF se trouve rarement être dans les listes de bénéficiaires ! Sur ce sujet, le régulateur a conclu que si cette fonctionnalité n’existe pas dans l’API, alors celle-ci doit fournir un moyen de rajouter un bénéficiaire préalablement à la réalisation d’un virement.

Aujourd’hui, arrivé au terme de cette période de trois mois au cours de laquelle l’EBA a « jeté un voile pudique » concernant la conformité des acteurs au calendrier de la directive, nous sommes loin d’en avoir fini avec la migration sur les API. Le fait que la FBF (Fédération Bancaire Française) ait décidé de se retirer des réunions AFEPAME ne lance pas un signal encourageant quant à la poursuite des travaux. Au dernier CNPS du mardi 3 décembre, à l’approche de l’échéance, le régulateur a botté en touche lorsque la question fut posée. De fait, elle va rester ouverte, explicitement ou non, pendant encore un moment.