La fallback ne sera pas une option

Plus nous avançons dans les tests des API mises à disposition par les ASPSP, plus nous en sommes convaincus : une période de transition sera nécessaire après le 14 septembre 2019. Cela va passer par la mise en place de la fameuse fallback option, le mécanisme d’« urgence » permettant aux AISP et PISP de continuer à utiliser l’accès direct du PSU pour opérer leur service.

Depuis des mois existe un débat sur la manière dont doit être implémenté l’authentification du TPP.

L’article 33 des RTS donne des indications claires sur la nature de cette fallback :

As part of a contingency mechanism, payment service providers referred to in Article 30(1) shall be allowed to make use of the interfaces made available to the payment service users for the authentication and communication with their account servicing payment service provider, until the dedicated interface is restored to the level of availability and performance provided for in Article 32.

Est-ce que la mise en place d’une copie du site est conforme ?

Certaines banques souhaitent mettre en place une instance de leur site dédiée aux TPP, sur lequel les requêtes requièrent l’utilisation du certificat client QWAC, et qui ne présenterait que les comptes de paiement.

Cette solution n’est selon nous pas conforme puisqu’il ne s’agit pas de l’accès direct du PSU.

Ajouté à cela, plusieurs risques ont également été identifiés.

Le premier est qu’à la vue du temps qui est pris par les différents TPP pour tester les API de sandbox ou de production, et le nombre de retours qui sont nécessaires pour tendre vers un accès dédié fonctionnel, nous n’envisageons pas de passer autant de temps pour tester la fallback. Le principe même d’une notion de « recette » de fallback n’a aucun sens puisqu’il doit s’agir encore une fois de l’accès direct.

Le second est que contrairement aux API, la fallback doit être utilisée dès le 14 septembre. Or il est illusoir ici de penser que cette solution soit mise en œuvre correctement à la date butoir, et que l’on soit passé sur l’ensemble de nos connecteurs. La non continuité de service est quasiment garantie.

Bien qu’au dernier CNPS et à l’atelier de l’AFEPAME de ce matin cette solution ait été envisagée, je réinsiste sur le fait que ce n’est pas une bonne idée, outre la non conformité aux RTS, cela sera plus coûteux pour les ASPSP et pour les TPP.

Est-ce que les applications mobiles sont exclues ?

Lorsque les RTS disent « use of the interfaces made available to the PSU », cela concerne le site web mais également l’application mobile. Le régulateur s’est beaucoup référé au web scraping dans le sens où il s’agissait il y a quelques années de la méthode la plus utilisée pour accéder aux données mais depuis, l’essor des applications mobiles a incité beaucoup de TPP à utiliser cette interface.

Techniquement, la méthode est la même, nous étudions le comportement du site web ou de l’application mobile pour réaliser les mêmes appels HTTP et analyser les réponses.

Concernant les néobanques, il s’agit d’ailleurs de la seule interface disponible puisque beaucoup d’entre elles ne disposent que d’une application mobile.

La réponse est donc encore non, le TPP doit pouvoir utiliser cet accès en cas d’indisponibilité de l’API PSD2.

Quelle solution mettre en œuvre ?

Les TPP ont proposé depuis longtemps de s’appuyer sur le mécanisme de signature des requêtes tel qu’il est défini par la norme d’API PSD2 STET, et s’appuyant sur le draft de RFC « Signing HTTP Messages », car il s’agit de la méthode la moins intrusive pour les TPP et les ASPSP.

Techniquement, il s’agit de rajouter un en-tête Signature qui contient l’URL du certificat utilisé (keyId), les algorithmes utilisés (algorithms), la liste des en-têtes signés (headers) et la signature (signature). Une requête de scraping ressemblera alors à ça :


POST /account/login.html HTTP/1.1
Date: 2019-07-04T09:33:55.375+02:00
PSU-Date: 2019-07-04T09:33:55.954+02:00
Accept: application/html; charset=utf-8
Referer: https://aspsp.net/account.login.html
Accept-Charset: utf-8
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36
Accept-Language: en-US
Content-Type: application/x-www-form-urlencoded
Digest: SHA-256=T7FMsJqT/o8xiHbq/GoeI879JoC0Je77w5fTUlpCyrM=
Content-Length: 1589
Signature: keyId="https://biapi.pro/certs/bi/qsealc.crt",algorithm="rsa-sha256",headers="date accept referer accept cookies accept-charset accept-encoding user-agent accept-language content-type digest content-length (requesttarget)",signature="tCYCZAGxVZLMlo87gHeXyPs2RkoNvOhCdsPvjkGhwkHlU1kT8xRBT3lybCT2UcjFrd2WroWaXexC3pYNYHJTwPN9HRV6dVXNRn3Ba2/BOA2n2g/+RELeAX318buwuEzQqAUOfci9d6d52X00+a5Dpb7h91T0zZuMBsPcxK6n2Sw="

À défaut de documentation d’une fallback correcte par les ASPSP qui ne bénéficient pas d’une exemption, il s’agit de la solution que nous utiliserons en standard sur l’ensemble de nos connecteurs en accès direct.