Romain Bignon et Bertrand Jeannet (Budget Insight) : “Seuls 30 à 40 % des utilisateurs des TPP renouvellent l’authentification forte tous les 90 jours”

Un an après l’entrée en vigueur de la DSP2, le 14 septembre 2019, quelle est la part de connexions des TPP (prestataires de services tiers) basculée sur les APIs DSP2 par les TPP ?

Bertrand Jeannet. Le volume de connexions des TPPs aux APIs des banques est transmis au CNPS (Comité national des paiements scripturaux) par Bankin’, Linxo, nous-mêmes et les TPP étrangers, et cela reste relativement faible.

Romain Bignon. Depuis environ un mois, l’ACPR qui commence à trouver le temps long pousse vraiment le marché et les banques à avancer pour pouvoir réellement éprouver les APIs et passer à une mise en production massive. Nous sommes en train d’opérer le changement, pas sans heurts cependant. Nous rencontrons des problèmes que l’on n’avait pas anticipés et qui sont parfois dus aux volumes. Nous avons dû aussi faire des adaptations de notre côté.

Avec la plupart des grandes banques, nous avons commencé à faire la bascule et le trafic va augmenter. D’ici quelques mois, nous ne ferons plus de scraping pour les comptes de paiement, hormis pour quelques établissements plus petits. Nous voulons de toute façon éviter le scraping, car nous savons que la bascule est inéluctable, et que cela va probablement affecter notre activité pendant un temps. Nous voulons donc nous brancher sur l’API pour les comptes de paiement si l’établissement de crédit la fournit et si elle a un niveau de qualité suffisant. Nous allons aussi nous battre pour aller chercher les comptes de tutelle, par exemple, que les banques rechignent à intégrer. 

Est ce que certaines banques ont préféré ne proposer que le mécanisme de repli, une solution de scraping authentifié ? 

Bertrand Jeannet. La plupart des grosses banques, qui représentent 95% du marché, ont des APIs. Rares sont celles, comme HSBC, qui n’ont qu’un mécanisme de repli (fallback mechanism) pour l’instant. Par contre, toutes les petites et moyennes banques n’auront probablement pas d’APIs… et pas même, parfois, de mécanisme de repli. Nous continuerons à les scraper mais cela ne représente que 5 à 10% du marché.

À la suite des réunions entre banques et TPP au CNPS, l’ACPR a tranché sur plusieurs points de blocage. Quels sont-ils et les changements sont-ils effectifs ?

Bertrand Jeannet. L’ACPR a en effet confirmé que les banques doivent bel et bien transmettre l’IBAN aux TPP lors de l’initiation de paiement, que les comptes de personnes protégées doivent être intégrés dans l’API s’ils sont disponibles sur l’interface en ligne de la banque, que l’exemption de solution de secours sur les API ne pourra pas être accordée aux établissements qui n’assurent pas une redirection fluide et enfin que l’API doit proposer la même offre d’émission de virement que l’espace de banque en ligne, avec potentiellement l’enregistrement d’un bénéficiaire. 

Romain Bignon. Quand l’ACPR acte l’une de ces règles, les banques se mettent en ordre de marche pour rectifier ce qui a été pointé du doigt. Elles ont toutes un plan de correction et de remédiation à ces obstacles… Mais ce n’est pas toujours très rapide.

L’un des points les plus bloquants, depuis le début de la mise en conformité, est la question du parcours d’authentification forte (SCA), souvent peu fluide et qui risque donc de pénaliser l’expérience client des TPP. Quel bilan en tirez-vous aujourd’hui ?

Bertrand Jeannet. La SCA pose plusieurs problèmes. D’abord, si les banques se conforment à l’authentification forte tous les 90 jours pour les comptes des particuliers, certaines la réitèrent tous les jours pour les comptes des professionnels et entreprises [C’est par exemple le cas du Crédit Mutuel, sauf si l’utilisateur le désactive dans ses paramètres, ndlr]. En Allemagne, la Bafin s’est exprimée sur le sujet en expliquant que cela devait également être espacé tous les 90 jours, et nous espérons que l’ACPR va s’aligner car cela rend le service inopérant. Des cas d’usage comme les PFM ou l’accès aux comptes par l’expert comptable sont fortement touchés.

Autre problème : dans sa publication du 4 juin, l’EBA a malheureusement répété que l’authentification forte (SCA) et son renouvellement doivent être gérés par l’ASPSP, c’est-à-dire la banque. Nous espérons une seconde version des RTS qui laisserait les TPP gérer au moins le renouvellement de la SCA – dans ce cas, la première authentification serait traitée par la banque puis le renouvellement au compte par le TPP, pour plus de simplicité. En l’absence de cette règle, nous pourrions tenter de signer des avenants bilatéraux avec les banques pour le faire, mais ce n’est pas notre priorité – nous nous concentrons déjà sur le passage massif aux APIs – et les banques n’ont pas l’air très ouvertes sur la question. Actuellement, l’authentification forte est donc bien souvent un processus de “redirect” compliqué, avec des nombreuses fenêtres. Cela prend souvent pas loin d’une minute à l’utilisateur. Le CM-CIC fait figure d’exception avec un parcours app-to-app correct. Résultat : les premiers chiffres de conversion du renouvellement SCA sont catastrophiques : 30 à 40 % des utilisateurs de TPP renouvellent l’authentification forte en moyenne. Le Berlin Group travaille sur le sujet de la délégation SCA avec les banques et TPP et nous allons suivre de près ces discussions. 

Quels autres points restent encore en suspens ?

Romain Bignon. Il y a un autre sujet pour les entreprises : il n’y a pas du tout d’APIs chez toutes les grosses banques pour accéder aux comptes de paiement des corporates (au-delà des comptes des petits professionnels). Certains de nos clients ont eux-mêmes des clients corporates et nous devons donc recourir au scraping.

Bertrand Jeannet. Outre le problème de réauthentification systématique sur les comptes professionnels et des parcours compliqués de SCA à la main des banques, qui sont surtout des problèmes réglementaires, nous devons gérer de nombreux sujets techniques ponctuels qui sont tout de même bloquants. Comment faire concorder la donnée en scraping et la donnée de l’API, comment migrer notre base utilisateurs en scraping sur des APIs de manière indolore… ? Si demain nous intégrons les APIs DSP2 sur un nouveau marché où nous n’avons pas d’historique ni de legacy, ça sera plus simple. Un autre problème est celui de la stabilité des APIs des banques, qui n’est pas toujours au rendez-vous. 

Justement, cela ne va-t-il pas faciliter l’arrivée sur le marché français d’acteurs étrangers comme Tink, qui n’ont pas d’historique et de legacy et vont par ailleurs bénéficier de votre travail sur les APIs au CNPS ?

Romain Bignon. Nous aussi, nous pourrons bénéficier dans leurs pays respectifs de leur travail d’évangélisation. Nous n’avons pas vraiment de churn sur notre base de clients depuis leur arrivée car ces acteurs, même s’ils commencent à bâtir une offre de services, n’ont souvent que les comptes de paiement et beaucoup moins de connecteurs que nous. Et même s’ils cassent les prix, car ils ont levé beaucoup d’argent, proposer des connecteurs sans services complémentaires n’est pas différenciant. De notre côté, nous vendons des connecteurs mais aussi du service pour intégrer nos APIs et construire les cas d’usage autour des APIs, et les étrangers n’en sont pas encore là. Or, les gros acteurs ont besoin de cet accompagnement.

Si un acteur français souhaite une connectivité européenne, on peut être mis en difficulté face aux acteurs étrangers sur d’autres pays. Mais en France, et même face aux autres acteurs français [Bridge de Bankin’ et Linxo, ndlr], le fait d’avoir fait du BtoB une spécificité depuis des années est un élément différenciant. 

Concernant l’initiation de virements (PIS), la migration est-elle plus avancée ?

Romain Bignon. Nous sommes en production sur 25 APIs pour l’AIS [Account Information Services, accès aux données des comptes bancaires, ndlr], dont quelques banques belges et luxembourgeoises, et connectés à une vingtaine d’APIs en PIS. Sur l’initiation de virement, nous intégrons les APIs un peu plus facilement, car nous avons moins de difficultés de migration de notre base d’utilisateurs. Nous avons encore peu de cas d’usage en production, hormis celui de Lydia, pour alimenter les wallets et faire des virements de compte à compte, et celui annoncé avec notre actionnaire Arkéa en juillet, qui permet de faire du paiement par QR code. L’initiation sert aussi pour les professionnels, pour des paiements de salaires dans les logiciels de gestion par exemple. Enfin, dans l’e-commerce, pour certaines niches comme les paiements à gros montants qui peuvent être gênés par les plafonds cartes, comme les billets d’avion, nous pensons que l’initiation de virement peut se développer, mais nous n’avons pas encore de mise en production sur ce cas d’usage. 

Quel impact ont les travaux de mise en conformité sur votre activité ?

Romain Bignon. La mise en conformité est très chronophage. Le temps de nos développeurs est, au global, dédié au moins à 50% à ces sujets. Et cela n’est pas qu’une question de mobilisation de ressources humaines. Nous avons dû décaler des projets et cela nuit à la croissance fonctionnelle, d’autant plus que comme nos actifs sous-jacents sont en transition, on ne peut pas capitaliser dessus et faire évoluer notre modèle sur le récupération de données ou sur l’initiation de virement, puisque le scraping et les APIs ont des modes de fonctionnement différents. Nous voulons construire de la valeur sur le nouveau fonctionnement par APIs mais nous n’avons pas encore tous les connecteurs donc cela nous bloque. C’est aussi pour cela que nous voulons accélérer sur la mise en production des connecteurs APIs même s’ils présentent des défauts, pour pouvoir enfin construire des capacités au-dessus.

Pouvez-vous faire un point sur votre croissance ?

Romain Bignon. Depuis un an, nous sommes passés de 35 à 70 collaborateurs. Nous sommes passés en production avec BPCE (Natixis) ce mois-ci, avec Carrefour Banque il y a quelques mois, avec PSA, Vazee, UnifiedPost, Prismea, la néobanque de Crédit du Nord, Moka (ex-Mylo)… Nous comptons désormais plus de 200 clients. [La société a enregistré un chiffre d’affaires de 3,49 millions d’euros en 2019, contre 3 millions d’euros en 2018, pour une perte nette de près d’un million d’euros, contre une perte de 273 000 euros en 2018, ndlr].

Où en est votre développement à l’international ?

Romain Bignon. Nos connecteurs couvrent déjà environ 80 % du marché en Belgique, où nous avons quelques petits clients et où un gros sortira bientôt en production, et au Luxembourg, où aucun client n’est encore sorti en production. Nous nous attaquons désormais à l’Italie, où nous développons la couverture pour l’un de nos clients français qui a une présence dans le pays pour un lancement début 2021.

Jusqu’à maintenant, nous nous sommes déployés à l’étranger de manière opportuniste, mais nous allons nous structurer pour mettre des efforts commerciaux dans ces pays en 2021. Une équipe commerciale sera spécialisée sur l’international.

Quelles synergies ont été mises en place avec Arkéa depuis le rachat, en juillet 2019 ?

Romain Bignon. Le projet de paiement par QR code sorti en juillet est le premier que l’on a développé ensemble. D’autres sont dans les tuyaux. Notre solution est utilisée par Aumax pour moi ; et les caisses CMB et CMSO et Fortuneo sont aussi en train de migrer sur notre plateforme. 

Nous sommes en lien avec la direction financière et la conformité mais nous disposons d’une très grande autonomie dans notre fonctionnement. Nous rapportons au conseil de surveillance du groupe, avec qui nous validons la stratégie et les points d’étape.

Où en est le projet de création d’une offre de Credit-as-a-Service ?

Bertrand Jeannet. Aujourd’hui, nous proposons des APIs sur étagère. Demain, nous souhaitons en effet plutôt proposer des cas d’usage sur étagère avec des parcours de bout en bout. Un chef de projet dédié permettra au client de piloter le cas d’usage en lien avec des partenaires – par exemple, sur du crédit, avec des acteurs comme Algoan pour le scoring ou Ubble pour l’authentification. Actuellement, nos clients le font eux-mêmes ou passent par des cabinets de conseil mais nous  sommes légitimes à aller plus loin que l’accompagnement technique et les conseils sur le cas d’usage, jusqu’à sa concrétisation.
Nous avons déjà travaillé sur l’interopérabilité entre notre solution et celle d’autres acteurs, pour nos clients existants. Plusieurs partenaires seront probablement possibles pour chaque cas d’usage. Cela fait partie des projets qui ont été repoussés à cause de la mise en conformité DSP2, mais nous sommes en pilote avec quelques clients et nous souhaitons le lancer de manière industrielle en 2021.