Budget Insight vient d’obtenir auprès de l’ACPR le double agrément d’agrégateur des comptes (AISP) et d’initiateur de paiement (PISP), nouveaux statuts créés par la DSP 2. Quels changements cela implique-t-il pour vous ?
Cela impacte peu les services que nous offrons – c’était d’ailleurs l’objectif de la directive : conserver ces activités qui fonctionnent tout en les encadrant –, mais cet agrément change profondément notre statut puisque nous sommes désormais une entité régulée. C’est un sésame qui rassure nos clients et nous donne un cadre de travail pour développer nos fonctionnalités pour eux. L’essentiel de notre activité est réalisé en BtoB : nos technologies sont utilisées par des experts-comptables, des FinTechs, des banques et des assurances, soit une centaine d’applications différentes. Notre activité BtoC, sous la marque Budgea, sert surtout à tester nos technologies.
Obtenir ce statut a-t-il nécessité des réorganisations ?
Nous avons dû restructurer les process internes de l’entreprise, effectuer des recrutements dédiés à la conformité, se mettre en capacité de fournir du reporting, en particulier sur les questions de sécurité. Il a notamment fallu acquérir de nouveaux serveurs, plus chers, souscrire une assurance responsabilité professionnelle spécifique à notre activité, elle aussi assez coûteuse. Pour une entreprise de notre taille, c’est un investissement important, que nous avons financé par la marge et la dette.
N’avez-vous pas eu à lever du capital réglementaire ?
Ce sont des statuts où le capital réglementaire n’est pas un enjeu. Nos fonds propres – 1 million d’euros – étaient suffisants pour l’ACPR. En revanche, elle a exigé que nous structurions un Conseil d’administration pour faire contrepoids face à mon associé et moi-même, qui sommes les seuls actionnaires et dirigeants effectifs.
Les standards techniques réglementaires associés à la DSP 2 laissent aux teneurs de comptes – les banques – le choix dans la manière de communiquer avec les tiers de paiement comme vous : si l’API est privilégiée, l’accès direct n’est pas exclu. Quelle solution a votre préférence ?
Notre préférence, c’est de pouvoir travailler. Nous avons trouvé un positionnement et nous apportons de la valeur dans un contexte de transformation digitale de la banque ; nous voulons pouvoir continuer à le faire. Nos interlocuteurs s’orientent tous vers la solution API, ce qui en soi nous convient. Le web scraping coûte très cher aux tiers de paiement. Beaucoup de mes développeurs travaillent aujourd’hui uniquement à maintenir les connecteurs permettant le web scraping : avec l’API et la stabilité qu’elle offre, je pourrais les employer sur des développements d’algorithmes à valeur ajoutée. Mais pour cela, l’API doit donner accès aux mêmes fonctionnalités que le web scraping, comme le demande le régulateur. À ce stade, celui des travaux de Place, ce n’est pas le cas. C’est pourtant dans l’intérêt de tous de développer des API qui permettent au marché de se développer correctement.
Quels blocages de fonctionnalités vous apparaissent aujourd’hui comme problématiques ?
Le sujet principal est celui de l’égalité de traitement : la directive dit que toute fonctionnalité relative aux comptes de paiement mise à disposition de l’utilisateur en direct sur son espace de banque en ligne doit être également rendue disponible dans l’API. Or pour l’initiation de paiement, par exemple, nous n’avons pour l’instant pas accès à la liste des bénéficiaires d’exemptions à l’authentification forte. L’API ne permet pas non plus, à ce stade, les paiements récurrents. Pour l’agrégation, le sujet en discussion touche à l’authentification de l’utilisateur final et à la présence ou non d’une redirection lorsqu’il souhaite se connecter. Cette redirection n’est acceptable pour nous que si elle génère une expérience de qualité. Pour l’instant, à l’échelle européenne, seule l’API de la néobanque britannique Starling Bank répond à ce critère. À l’opposé, la redirection proposée par d’autres banques implique sept pages successives !
Quelles sont les instances de dialogue mises en place pour trouver un terrain d’entente sur la forme de ces API ?
Au niveau européen, nous faisons partie de l’API Evaluation Group et nous sommes responsables du sous-groupe dédié à l’analyse de l’API de STET. Nous avons transposé en France cette analyse au sein d’un groupe de travail du
D’une manière générale, quelles sont les bonnes pratiques pour développer une API ?
L’API est un système expert auquel on peut poser des questions et qui répond. Le développeur a donc besoin de connaître les typologies de questions et de réponses qui peuvent être traitées. Cela implique une documentation des fonctionnalités offertes. Le second sujet est celui de la sécurisation de ce dialogue : il faut préciser les conditions d’authentification, du tiers comme de l’utilisateur final, ainsi que les modalités de traçage de ces interactions. Un bac à sable doit permettre de tester l’API avec de faux appels.
Pour en revenir à votre offre, vous avez récemment complété votre activité historique d’agrégation de comptes par un service d’initiation de paiement. Que permet-il de faire ?
Nous avons effectivement lancé l’initiation de paiement sur Budgea et en partenariat avec quelques grands clients comme Lydia. Ce service permet par exemple d’alimenter son wallet Lydia sans utiliser sa carte bancaire ni se rendre sur le site de sa banque pour faire un virement. Il permet aussi d’effectuer un paiement sur le compte bancaire d’un bénéficiaire même si celui-ci ne dispose pas de compte Lydia.
L’initiation de paiement peut-elle concurrencer le paiement par carte bancaire ?
Je crois peu à ce scénario pour le paiement en magasin : l’authentification forte imposée par la DSP 2 à l’initiation de paiement complexifie le parcours client, là où la carte bancaire offre une expérience de plus en plus fluide, avec des solutions comme Apple Pay. En revanche, l’initiation de paiement a un rôle à jouer pour le paiement en ligne, pour lequel la carte n’est pas bien adaptée.
D’une manière plus prospective, que peuvent apporter vos technologies au mouvement d’open banking ?
L’agrégation et l’initiation de paiement sont un moyen de piloter ses comptes à distance. C’est intéressant, mais pas révolutionnaire. Ce qui l’est, en revanche, c’est la contextualisation de l’argent que cela permet. Par exemple, connecter les comptes d’une entreprise à l’outil d’expertise-comptable permettra à l’entrepreneur de piloter plus simplement et finement sa gestion financière. Sa comptabilité se fera en temps réel. Grâce à l’initiation de paiement, il pourra payer ses salaires et ses fournisseurs en un clic, directement dans l’outil qui gère ses fiches de paie et ses factures.
C’est également utile pour le crédit. L’offre « Prêt Pro direct » d’ING en est un exemple : grâce à notre technologie, une entreprise peut donner accès à ses données bancaires à la banque ; ces données sont entrées dans un moteur de scoring qui donne une réponse immédiate à l’entrepreneur. Pour ce dernier, l’expérience est fluide et rapide. Et cette simplicité se paie à travers un taux un peu plus élevé que pour un crédit classique. Il existe des business models à développer sur la base de cet accès aux comptes. Ce sont ces services sur les données financières qui constituent le vrai open banking.
Qu’en est-il de la clientèle des particuliers ?
Nous voyons de belles opportunités autour de la fidélisation. Nous sommes par exemple en partenariat avec la FinTech Paylead qui permet au marchand de proposer du cashback à ses clients les plus fidèles de manière très simple, grâce à la connaissance des données bancaires.
Il y a également l’enjeu majeur de l’accès aux comptes d’épargne. Les acteurs qui délivrent du conseil en matière d’épargne sont tenus, du fait de Mifid 2 en particulier, d’avoir une vue globale de la vie financière d’un client, et ce en temps réel car le profil du client change en fonction des évolutions du marché. Nos technologies peuvent par exemple aider les robo-advisors en leur donnant accès aux données qui leur permettront ensuite de fournir un conseil.
Les comptes d’épargne ne sont pourtant pas concernés par la DSP 2 et les discussions sur les API…
Non, en effet, nous continuerons d’utiliser la technique du web scraping. Il faudra par la suite discuter du sujet des comptes autres que de paiement, mais il faut s’attendre à une grande complexité juridique : en droit, un compte titre est différent d’un compte de paiement, d’un livre réglementé ou d’un support d’assurance vie – qui n’est même pas un compte…
Quel impact a le Règlement général sur la protection des données (RGPD) sur vos activités ?
Le principe du RGPD est que le client ait la maîtrise de sa donnée. Nous lui fournissons un moyen de la partager avec des tiers en qui il a confiance et qui lui proposent un service à valeur ajoutée. Je pense donc que le RGPDP légitime l’accès aux données bancaires, quelle que soit la nature du compte d’ailleurs, pour permettre à un utilisateur qui le souhaite d’utiliser ses données en dehors de leur environnement d’origine.
Parmi vos partenaires, vous n’avez pas cité les géants du web. Peuvent-ils être intéressés par les usages permis par la DSP 2 ?
Ils sont parfaitement positionnés pour contextualiser la donnée financière. Uber l’a montré en faisant disparaître l’acte de payer à l’issue de la course. De même, Amazon a tout intérêt à rendre l’acte de paiement très simple, à proposer des paiements en plusieurs fois ou par abonnement, à gérer la fidélisation… Et la meilleure manière de se préparer à leur arrivée est de proposer dès maintenant cette qualité d’expérience client, grâce à des technologies comme les nôtres. Lorsque les GAFA arriveront, ils n’auront d’autre choix que de s’insérer dans un écosystème existant et se plier à ses règles.
Propos recueillis par S. L.
