Le 14 mars dernier a débuté la période des six mois de tests publics des interfaces de programmation applicative (application programming interface – API) conformes à la DSP 2, que les banques ont dû mettre à la disposition des FinTechs. Objectif : que tout soit en état de marche pour le 14 septembre 2019, date d’entrée en vigueur des normes techniques de réglementation (RTS). État des lieux.
Comment utilise-t-on les API chez Bankin’ ?
Bankin’ a obtenu un double agrément pour un double service : information sur les comptes et initiation de paiement. Les API nous servent à connecter les comptes bancaires des clients, à récupérer la donnée pour la traiter et à la leur restituer de manière intelligente. Elles permettent aussi à nos clients d'effectuer des virements depuis notre application. Nos services transmettent l’ordre à leur banque, laquelle initie le virement.
Les banques vous ont-elles donné accès à leurs API réglementaires, comme le prévoyaient les normes techniques de réglementation (RTS) de la DSP 2 ?
Le 15 mars dernier, les banques devaient en effet avoir mis leurs API à la disposition des prestataires de services de paiement, afin que nous puissions réaliser six mois de tests, auxquels s’ajoutent les deux mois de traitement nécessaires au régulateur pour examiner la qualité de ces API.
Or nous avons constaté que la plupart des banques ne sont pas en avance. Certains établissements sont arrivés, in extremis, à sortir une première version d’API dans les délais. Dans la plupart des cas, il n’y a pas eu d’itération réalisée avec les TPP (Third Party Provider) en amont. Comme tout projet informatique, la probabilité pour que ce premier jet soit bon est assez faible. Il nous faut entrer dans une phase de collaboration intense, et d’itération, entre les TPP et les prestataires de services de paiement gestionnaires de comptes (Account Servicing Payment Service Providers – ASPSP), pour avoir une chance que les API soient suffisamment performantes et ne présentent pas d’obstacle. Et qu’elles permettent d'exempter les banques de l’obligation d’obtenir un mécanisme de secours d’ici le 15 septembre.
Pourquoi les banques ont-elles accumulé un tel retard ?
Il y a eu beaucoup d’intérêts divergents. Les représentations bancaires étaient réticentes dès le début et elles ont perdu beaucoup de temps en essayant d’en faire le moins possible. Tant que les objectifs n’étaient pas figés, il était compliqué pour les banques de lancer le moindre développement. Quand enfin il y a eu un peu plus de visibilité sur ce qu’il fallait faire, il restait très peu de temps aux banques pour se préparer. Elles font au mieux maintenant, avec le temps dont elles disposent.
Comment avez-vous anticipé la période des tests d’API, qui s’est ouverte en mars ?
Les TPP ont toujours appelé à la collaboration. Nous avons invité les banques à nos ateliers en janvier. Dans ces ateliers, nous voulions discuter certains points, envisager comment pouvait se faire l’implémentation, initier des points de contact. Très peu de banques ont répondu à notre appel. Le groupe Arkéa, Boursorama, Fortuneo, Orange Bank, étaient là. Deux banques étaient représentées au premier atelier, Société Générale et LCL, mais n’ont plus donné suite pour les ateliers suivants. Je pense que certaines banques ou organisations bancaires ont fait en sorte qu’il y ait très peu de participation à ces ateliers… C’est dommage. Nous avons pourtant toujours été dans une démarche constructive. Cette collaboration est nécessaire et même prévue dans les textes réglementaires.
Désormais, nous entrons dans une phase où nous allons tous devoir collaborer, alors qu’il n’y a pas eu d’itération. Nous découvrons tout juste ce qu’il y a dans ces API. Connecter une API, ce n’est déjà pas évident. Dans cette situation où toutes les banques sortent la leur dans un délai très court, c’est très compliqué ! Je regrette que cette collaboration que nous souhaitions, pour anticiper au maximum, n’ait pas eu lieu. Nous entrons désormais dans une collaboration forcée.
Ma crainte est d’avoir face à moi certains acteurs bancaires qui viennent à reculons, et que la collaboration se transforme en une bataille constante.
Avec les institutions qui ont répondu à votre appel, quels sujets avez-vous abordés ?
Nous avons cherché à comprendre comment pouvaient être réalisés les tests dans de bonnes conditions pour les TPP mais aussi pour les ASPSP, si un protocole de test était prévu, si nous disposions du même référentiel, comment seraient gérés les certificats, comment seraient traitées les questions de l’expérience utilisateur et de la sécurité… Il fallait aussi envisager ce qui se passerait si l’API n’était pas au niveau, ou si elle rencontrait un problème technique – car une API reste un programme informatique. Il y a parfois des bugs. Enfin, nous devions comprendre comment fonctionnerait le système de secours, le « fallback ».
Diriez-vous que la DSP 2 est une chance pour les nouveaux prestataires de services de paiement ?
Beaucoup de banques ne font que le strict minimum. Nous ne pourrons pas faire nos métiers avec ce minimum. C’est très simple : Bankin’ a 2,9 millions d’utilisateurs. Nous ne pouvons pas, du jour au lendemain, parce qu’une banque a décidé de faire le minimum, ne plus fournir notre service. C’est inimaginable. Soit il nous est possible de maintenir une bonne qualité de service avec les API, soit – et ce serait un comble – nous obtenons une meilleure qualité de service avec le web scraping et l’accès direct. Si c’est le cas, c’est que l’API n’est pas de bonne qualité.
Les textes sont clairs. Valdis Dombrovskis, vice-président de la Commission européenne chargé de la stabilité financière, des services financiers et de l'Union des marchés des capitaux l’a répété : il ne peut pas y avoir de régression de service pour les TPP. Si l’API n’est pas au moins aussi performante que l’accès direct, nous serons autorisés à utiliser l’accès direct.
Pourtant, la technologie de l’accès direct est très compliquée pour le prestataire de services de paiement. Il faut construire un connecteur par banque, qui puisse lire les pages web, et enregistrer chaque modification. Cette technologie n’est pas stable, elle nécessite énormément de maintenance. Nous n’avons aucun intérêt à passer par l’accès direct. Mais si les API ne sont pas de bonne qualité ou qu’elles ne fournissent pas le spectre des fonctionnalités nécessaires à nos métiers, nous continuerons, même si cela nous demande un effort considérable, à faire de l’accès direct, pour continuer à fournir notre service.
Les RTS obligent les API bancaires à donner accès aux comptes courants, mais pas aux comptes d’épargne, aux assurances vie, aux crédits, etc. Comment envisagez-vous la suite ?
Je comprends que l’ouverture de tous les comptes représente un investissement supplémentaire et qu’il faille y aller par étapes. Mais nous savons tous, y compris le législateur et les banques, que l’intégralité des comptes se retrouvera bientôt dans les API. C’est un secret de Polichinelle. Il serait complètement illogique de maintenir l’accès direct pour tous les comptes autres que les comptes de paiement.
À ce jour, nous accédons aux comptes d’épargne, assurances vie et crédits, en dehors d’un cadre réglementaire.
Même sans passer par les API, nous pourrions d’ores et déjà augmenter le niveau de sécurité pour ces autres comptes. Le système d’authentification entre le TPP et la banque signale à la banque qu’il s’agit bien d’un acteur agréé par la Banque de France. À partir de ce système d’authentification, la banque pourrait valider l’accès aux comptes épargne, d’assurance vie et de crédit, même sans passer par l’API. Mais certaines banques s’y refusent. Elles préfèrent fermer les yeux et ne pas voir quel prestataire se connecte, qu’il soit agréé ou non, pour récupérer les données des autres comptes. Notre intérêt commun serait d’activer cette authentification, également pour les comptes épargne, d’assurance vie et les crédits.
Il s’agit d’un sujet concurrentiel et politique. Beaucoup de banques ne veulent pas officialiser l’accès aux comptes d’épargne et crédits, ni ouvrir encore plus la concurrence.
Depuis cinq ans, j’ai eu de nombreuses fois l’occasion de me rendre compte de la mauvaise volonté de certains acteurs. Les textes de la DSP 2 sont très clairs : ils ont été conçus pour ouvrir la concurrence, et favoriser l’innovation et la compétition dans le milieu bancaire, tout en garantissant la sécurité. Or beaucoup d’acteurs ne jouent pas le jeu. J’y vois du protectionnisme pour éviter que la DSP 2 soit appliquée.
