Où en sont aujourd’hui les banques dans la mise en œuvre de leurs API ?
Aujourd’hui, le principal enjeu des banques est de parvenir à se conformer aux standards imposés par la DSP 2 dans des délais très serrés. Il est fort probable que tous les établissements ne seront pas prêts an mars 2019, date à laquelle les API bancaires devraient commencer à être testées pour une ouverture au grand public en septembre 2019. Car il faut construire les API mais aussi tenir compte des obligations d’authentification forte également prévues par la DSP 2, qui s’appliquent non seulement aux API mais aussi au site Web des banques, car la DSP 2 spécifie que le site web doit avoir le même niveau de sécurité que les API.
Concrètement, la mise en œuvre des API est une révolution technologique qui plonge la banque dans le monde de l’internet pur. Une banque traditionnellement fonctionnait sur un système d’information autonome dialoguant avec d’autres systèmes d’information par des réseaux sécurisés propriétaires des banques. Aujourd’hui, on lui demande d’ouvrir ses réseaux, tout en les sécurisant, grâce aux API. Techniquement une API consiste à mettre à disposition de tiers, des fonctions bancaires utilisables sous forme d’un web service. Certes l’utilisation de ces fonctions en web service existe déjà en interne dans certaines banques, notamment les plus grandes qui ont des services informatiques étoffés et les compétences nécessaires. Mais c’est moins le cas des banques plus spécialisées qui doivent à la fois s’approprier ces nouvelles technologies en web service et en organiser la mise à disposition vers des tiers via les API.
Quels vont être les apports de ces APIS pour les services bancaires ?
Les API développées dans le cadre de la DSP 2 seront construites sur les standards de la STET ou du Berlin Group et vont normaliser les échanges entre les acteurs pour accéder aux données des comptes de paiement. Les agrégateurs ou les initiateurs de paiement, qui appelaient les systèmes d’information des banques par des moyens non sécurisés (le client leur communiquant ses mots de passe et identifiants), devront se conformer à des process de sécurité d’accès plus contraignants mais pourront consulter plus facilement les comptes ou initier des paiements, puisque la manière d’appeler ces informations via les API sera la même pour tous les établissements.
Mais au-delà de cette seule standardisation, les API peuvent conduire à des changements de business models. La DSP 2 impose aux banques d’ouvrir un accès gratuit à leurs données sur les comptes de paiement, alors même qu’elles doivent investir lourdement pour y parvenir, ce qui définit un business model déséquilibré et doit inciter les banques à réfléchir aux possibilités nouvelles ouvertes par les APIS. Un premier cas concret peut se poser pour les clients qui seraient prêts, dans le cadre d’un service d’agrégation, à exposer leurs données d’épargne : la banque va-t-elle faire payer les PSP pour avoir accès à des données via ses API qui ne sont pas dans le périmètre défini par la DSP 2 ? Est-ce qu’à terme les banques vont s’implanter dans ce nouveau métier qui consiste à se rémunérer par l’exposition des données qu’elles gèrent, au-delà de leur métier de banquier d’origine ? Et dans quelles conditions ? Certaines études montrent que ce qui différencie une banque d’un GAFA dans l’esprit du client est que sa banque n’exposera pas ses données à tout va : comment concilier la nécessité de trouver un business model rémunérateur au travers de l’exposition des données, sans mettre à mal la confiance des clients ?
Un autre développement rendu possible par les API est la construction d’offres de services en croisant les API : par exemple, une banque peut offrir de souscrire en ligne un crédit, et y adjoindre via une API un comparateur d’assurance crédits. L’opération permet d’offrir au client en temps réel un service complet autour du crédit. À l’inverse, des commerçants en ligne peuvent vouloir enrichir leurs offres de services marchands avec des services de paiement performants : sur leur site web, ils peuvent appeler une API bancaire.
Les vainqueurs dans ces évolutions seront ceux dont les API seront les plus utilisées. Sans oublier que dans le domaine des services financiers, de très nombreux acteurs non bancaires peuvent aussi proposer des API, qu’il s’agisse d’éditeurs informatiques, de FinTechs, voire de GAFA…
Quels seront les effets de la mise en œuvre des APIS sur le business model des nouveaux prestataires de services de paiement ?
Ceux-ci risquent également de voir leur business model perturbé : jusqu’à présent ils avaient gratuitement accès aux données mais dans des conditions techniques et de sécurité assez questionnables ; désormais ils devront respecter des processus d’accès sécurisés mais ne pourront consulter qu’un volume limité de données. Ils doivent réfléchir à réadapter leur business model : l’activité d’agrégation n’est pas rémunératrice en tant que telle ; elle ne peut le devenir que si les agrégateurs peuvent proposer, à partir des données récupérées, des nouveaux services aux clients. D’ores et déjà, certains agrégateurs se réorientent en proposant leurs savoir-faire de gestionnaires d’API aux banques et autres acteurs.
