Outre votre offre d’agrégation de comptes distribuée sous la marque Linxo, vous avez développé une offre BtoB à destination de banques. Comment fonctionne-t-elle ?
Nous avons effectivement décidé de mettre en œuvre la mission que nous nous sommes fixée – aider les particuliers et les professionnels à gérer leur argent pour mieux réaliser leurs projets – à travers deux canaux : en direct avec la marque Linxo et via une offre
Comment s’articule la notion d’API ouverte dans votre modèle ?
Pour l’instant, elle concerne uniquement notre offre sous marque Linxo, mais pourrait très bien être proposée dans le futur à nos partenaires BtoB. Il s’agit de valoriser l’accès aux données bancaires que Linxo agrège en les rendant accessibles à des partenaires FinTech, et ce via une API
- Grisbee, qui propose une analyse patrimoniale automatisée et des recommandations en matière de placements et de fiscalité : les clients Linxo qui souhaitent utiliser ce service peuvent le faire en se connectant via leur compte Linxo et faire remonter automatiquement les informations liées aux comptes qu’ils ont synchronisés sur notre plate-forme ;
- Birdycent, qui permet d’arrondir ses dépenses à l’euro supérieur pour épargner sur une cagnotte en ligne : les clients Linxo se connectent directement et font automatiquement remonter leurs transactions à Birdycent ;
- OneUp pour les professionnels, qui fournit un ERP et un logiciel de comptabilité en mode SaaS : grâce à l’API de Linxo, les flux bancaires sont automatiquement intégrés dans le système de comptabilité.
Symétriquement, collectez-vous les données des comptes des clients Linxo par l’intermédiaire d’API bancaires ?
Très peu de banques disposent d’API ouvertes : à ce jour, on peut uniquement citer Axa Banque et CA Store. Nous avons utilisé les premières pendant un temps, mais elles n’exposaient pas toutes les données dont nous avions besoin et le système manquait de stabilité. Les API du CA Store n’ont pas été conçues à l’origine pour l’agrégation de comptes donc à ce jour, nous ne les utilisons pas. Ceci pourrait changer.
Vous avez donc recours au « web scraping »…
Nous utilisons les espaces web des banques auxquels nous accédons en entrant les identifiants et mots de passe que les utilisateurs stockent, de manière hautement chiffrée, chez nous. Ceux-ci sont conservés dans plusieurs modules très sécurisés au sein de différents coffres-forts numériques auxquels nos salariés n’ont pas accès. Grâce à la DSP 2 et la mise en place d’API ouvertes, on verra peut-être émerger un système de jetons d’accès qui remplaceraient la transmission des identifiants et mots de passe. C’est ainsi que fonctionne déjà notre propre API proposée à nos partenaires FinTechs : ils n’ont ainsi jamais accès aux identifiants bancaires des clients.
Faudrait-il que toutes les données soient accessibles sous forme d’API ?
C’est le sens de l’histoire. Il est intéressant pour l’utilisateur de pouvoir agréger ses données en un même endroit grâce à des API puis de les exposer à des applications partenaires, là aussi via une API. En matière d’utilisation des données financières d’une personne, aucune entreprise n’aura le monopole des idées et de la valeur créée. Les banques qui comprendront que leurs clients multibancarisés ne veulent pas d’outils trop « maison » toucheront les meilleurs dividendes de ce que permet la DSP2. Nous pouvons jouer le rôle de facilitateur de cette ouverture.
Diriez-vous que les API vont vous permettre de gagner en sécurité et en souplesse ?
Notre méthode actuelle est très sécurisée, mais nous gagnerons en productivité si nous pouvons travailler avec les banques via des interfaces bien définies. C’est ce à quoi doivent aboutir les travaux de l’EBA sur les standards techniques de la DSP2.
Que pensez-vous des propositions de la consultation sur le RTS dédié aux questions d’authentification et de
Elles sont améliorables si l’on veut créer un cadre moderne qui puisse durer dans le temps. Il est ainsi envisagé de demander une authentification forte non seulement à la première utilisation de l’agrégateur – ce qui est souhaitable – mais aussi tous les trente jours – alors qu’il existe des solutions techniques autres pour obtenir plus de sécurité sans imposer une telle contrainte à l’utilisateur. Il serait également question de limiter le nombre d’accès de l’agrégateur au système bancaire.
À travers le web scraping, accédez-vous autant de fois que vous le voulez aux comptes des clients ?
En théorie oui. Cela a certes un coût pour la banque, mais aussi pour l’agrégateur. Il y a donc un équilibre à trouver, l’idée étant de ne pas créer de charge non justifiée d’un côté ou de l’autre. Nous échangeons sur ce sujet avec certaines banques, afin par exemple de nous connecter à des heures creuses. Cela contribue d’ailleurs à lisser leurs pics de connexion : par exemple, si nous synchronisons à 5 heures du matin les comptes des clients, nous pouvons décharger les banques d’un pic de connexion à 9 heures, car nos clients vérifient leurs comptes auprès de nous plutôt qu’auprès de leurs banques. Les bonnes solutions se trouvent dans des échanges constructifs que l’on peut avoir avec les établissements.
Comment transmettez-vous vos propositions ?
Nous souhaitons échanger avec tous les acteurs qui le veulent. Nous sommes ainsi demandeurs pour participer aux groupes de travail qui peuvent se tenir sur ces sujets à la FBF. Ce serait utile pour créer le bon écosystème. Jusqu’à présent, nous avons travaillé entre agrégateurs : nous avons préparé des réponses communes avec Bankin et Budget Insight, que nous avons soumises à l’EBA. Un groupe de travail entre agrégateurs s’est aussi formé au niveau européen. En France, nous faisons partie de France FinTech et nous avons rejoint
Est-il difficile de réglementer des sujets aussi techniques ?
Il n’est pas toujours aisé de trouver le bon équilibre entre les grands principes juridiques que traduisent les RTS et les solutions techniques à mettre en œuvre. Un texte juridique va graver dans le marbre des contraintes d’utilisation, comme l’authentification forte tous les 30 jours, alors que les solutions techniques à ces exigences de sécurité vont continuer d’évoluer dans le temps.
La DSP 2 va créer deux nouveaux statuts : celui d’agrégateur de comptes de paiement et celui d’initiateur de paiement. Qu’est-ce que cela change pour vous ?
À l’heure actuelle, nous n’avons besoin d’aucun agrément pour exercer notre activité. Nous avons toutefois appelé à une réglementation car nous avons conscience que nous touchons à des données sensibles. Nos procédures sont déjà à un degré élevé de maturité et nous préférons la contrainte de l’agrément afin de profiter simultanément de ses bénéfices en matière de réassurance. Nous allons donc prendre le statut d’agrégateur
Disposer d’un statut européen pour les API est-il essentiel de votre point de vue ?
Pas nécessairement. Aujourd’hui, nous avons un travail de développement spécifique à faire pour nous connecter à chaque banque : une API par pays réduirait déjà beaucoup cette charge. Fixer trop de normes au niveau européen risque d’avoir des effets néfastes sur l’innovation, en nivelant l’offre sur le plus petit dénominateur commun.
