Offres DSP2 : les banques devront-elles être prêtes en septembre ?

Le 14 septembre prochain, les banques devront mettre en production des API à la disposition des agrégateurs de comptes, des initiateurs de paiement et des prestataires de services émetteurs de supports de paiement travaillant avec leurs clients. Cette exigence est issue des RTS, texte délégué de la deuxième directive sur les services de paiement. La question de l’authentification forte des clients n’est pas l’objet de cet article, mais elle entre bien sûr dans les éléments à intégrer. Ce contexte réglementaire laisse penser que les banques ont de nombreuses contraintes et que les PSP ont beaucoup d’opportunités. Creusons un peu cette situation pour voir si le tableau est si sombre.

L’exigence du 14 septembre contraint les banques à mettre en place des API pour que les PSP accèdent aux données de leurs clients. Si le délai n’est pas respecté, les banques retardataires s’exposent au maintien de l’utilisation de la méthode du web scrapping par les PSP tiers. Les banques ont tout intérêt à avoir développé des API pour les PSP tiers au 14 septembre 2019. Mais cette échéance ne vise que les comptes de paiement ; les PSP tiers continueront certainement d’utiliser le web scrapping pour les comptes d’épargne. Le principal impact envisagé pour les banques est qu’elles ne serviront que de back-office au traitement des opérations de leur client, et perdront la relation avec leurs clients au profit des fintech. C’est un scénario noir à long terme qui, s’il s’avérait vrai, pourrait impacter le modèle économique des banques.

Au titre de l’expression qui considère que l’attaque est la meilleure des défenses, les banques peuvent aussi se positionner comme PSP tiers. Leur statut d’établissement de crédit le leur permet. Elles peuvent donc utiliser les API en « sens inverse », c’est-à-dire en constituant des offres d’agrégateurs de comptes et d’initiateurs de paiement et interroger les autres banques sur les données de leurs clients ou en leur transmettant des demandes de paiement. Plusieurs banques de la place envisagent la construction d’une telle offre, tant pour les particuliers que pour les professionnels ou pour les entreprises. Ce choix stratégique soulève derrière de nombreuses questions sur l’orientation de l’offre en termes d’expérience client. L’utilisation de l’open banking ne peut pas se limiter à un nombre restreint de services en renvoyant les clients sur la banque en ligne pour le reste si les banques souhaitent embarquer le plus grand nombre de leurs clients. Il faut alors penser à une offre globale, éventuellement par segment de clientèle, qui digitalise via l’open banking une gamme de services ciblés. Ces offres peuvent être mises en place par des développements internes, ou grâce à des partenaires, eux-mêmes fintech ou pas. Le fait de construire une nouvelle offre globale complètement orientée expérience client demande de la réflexion, des études de faisabilité, des développements, etc. Le délai du 14 septembre peut alors être un peu court pour proposer l’offre à ses clients.

Le 14 septembre est pour les banques une échéance ciblée sur certains services. L’avènement des API est pour les banques l’occasion d’envisager leur utilisation de manière beaucoup plus large. Les ouvertures de compte, les financements, les rapprochements, les assurances, etc. pourraient s’ajouter aux offres proposées. Finalement, la réponse à la question pourrait être : les banques ont besoin d’être prêtes en septembre afin de respecter le délai réglementaire, mais pour la constitution de leur offre, une mutation interne doit s’opérer et une nouvelle approche des services proposés est nécessaire, et peut prendre plusieurs années. Cela semble cependant incontournable.