Agrégation bancaire multi-sources : comment ça fonctionne ?

Fournir une visualisation centralisée aux utilisateurs de leurs données bancaires, particuliers comme entreprises, est au cœur de nos activités. Chez Budget Insight, nous avons recours au multi-sources. L’intérêt : remonter un maximum d’informations avec une grande profondeur d’accès grâce au web scraping, excellent complément à la DSP2. Découvrez de quoi il s’agit concrètement et comment nous gérons l’agrégation multi-sources.

Pionnier de l’agrégation avec le web scraping

Budget Insight est l’un des tout premiers acteurs à avoir eu recours au web scraping afin de mener l’activité d’agrégation bancaire à travers une API. Le but : libérer les usages et faire émerger de nouveaux services. Grâce au web scraping, nous nous connectons aux sites des banques au nom des utilisateurs, et automatisons la récupération de données, qui sont nettoyées puis stockées dans une base de données mise à jour quotidiennement.

Le web scraping présente l’avantage de pouvoir couvrir un vaste domaine, des comptes de paiement aux documents, en passant par les produits patrimoniaux et les cryptomonnaies.

DSP2, le Cap d’un grand changement

Avec la mise en place d’un nouveau cadre légal européen sont arrivées les API DSP2 pour que les banques fournissent leurs données de manière authentifiée.
Trois types d’acteurs se distinguent : les ASPSP (les banques fournissant les API), les TPP (consommateurs des API tels que Budget Insight) et les PSU (les utilisateurs qui détiennent les comptes).

La DSP2 s’accompagne de contraintes pour les TPP : d’une part, l’obligation de consommation des API en lieu et place des sites web des banques lorsqu’il s’agit des comptes de paiement. D’autre part, l’obligation d’authentification forte (SCA). Auparavant, il suffisait aux PSU de nous confier de manière sécurisée leurs identifiants pour que l’on établisse une connexion sûre. Avec la généralisation des SCA (à la fois sur les API et sur les sites bancaires), la connexion doit se faire en deux étapes, ce qui génère régulièrement une incompréhension chez les PSU.

Mais la DSP2 présente aussi deux avantages. Elle rend les API d’agrégation plus stables que les sites web (la couche sécuritaire est standardisée pour la communication, les changements sont annoncés en amont) et, toutes les banques européennes étant couvertes par la DSP2, nous pouvons déployer notre technologie pour en intégrer davantage.

Implémentation de la DSP2 dans la technologie existante

API DSP2 : nos évolutions techniques pour la sécurité et la rapidité de développement

Après des expérimentations avec quelques banques sur leur sandbox et leur pré-production, nous avons obtenu les très attendus certificats eIDAS pour accéder aux API de production. Les certificats contenant des clés privées jugées sensibles, nous avons décidé d’ajouter une brique à notre stack technique : un proxy qui intercepte les requêtes et y présente les certificats si le connecteur de la banque le requiert.

Le proxy, en coordination avec le module de la banque, va aussi ajouter des headers de signatures comme le demande les différentes normes d’API DSP2. Malgré des standard d’API comme STET et le Berlin Group, la partie signature a été implémentée de manière distincte entre les différentes banques. Pour chaque nouvelle implémentation, nous avons dû vérifier que celle-ci était compatible avec les signatures préexistantes, et dans le cas contraire en créer une nouvelle.

Par la suite, certaines banques ont mis à disposition une nouvelle route d’API permettant d’enrôler les TPP. L’enrôlement permet d’obtenir un client_id et un client_secret, tels des identifiants permettant de nous brancher sur leurs API. Nous avons sauté sur l’occasion pour automatiser l’enrôlement des clients en marque blanche, qui utilisent leur propre agrément. La console d’administration s’est adaptée à notre backend pour permettre l’automatisation de ces enrôlements.

Plusieurs types d’enrôlement sont disponibles en fonction des banques :

Les enrôlements manuels, via le portail web correspondant ou en envoyant un mail à la banque. Si ce mode semble être simple, beaucoup de pièges sont à éviter, comme la souscription à la production ou la souscription à certaines API. Surtout, ils nécessitent un temps humain non négligeable sur lequel nous ne pouvons que vous accompagner.
Les enrôlements automatiques, par simple clic sur un bouton de la console.
Les enrôlements hybrides : une partie doit être faite sur le portail et une autre via l’API. Pour être francs, ce n’est pas notre mode préféré car il nécessite un accompagnement tout particulier.
Les numéros d’agréments : aucun enrôlement n’est nécessaire dans ce cas, les certificats et le numéro d’agrément, en tant que client_id, sont suffisants pour reconnaître le TPP. La plupart des connecteurs étrangers (en majorité avec le standard du Berlin Group) fonctionnent ainsi. Ce mode a l’avantage d’une implémentation facile mais ne permet pas de customiser l’interface de la banque (ex : pas de possibilité d’afficher le nom et logo du TPP).

Il est dommage qu’il n’y ait pas eu une contrainte plus forte de la part des standards DSP2 sur l’enrôlement. Pour éviter de perdre nos clients durant cette étape, la documentation doit être maintenue pour chaque banque pour laquelle nous avons développé un connecteur DSP2. Nous mettons justement en place une structure afin de gérer cette maintenance.

Toutefois, la standardisation nous a permis d’établir des notions de parenté entre nos différents connecteurs DPS2, qui nous évitent de partir de zéro lorsqu’on veut implémenter une nouvelle API. À partir d’une classe parente qui gère le parcours OAuth2 de nos connecteurs, nous avons pu établir des abstractions pour chaque standard. Néanmoins les divergences (liées à la divergence avec le standard ou à des points laissés à libre interprétation par la banque) sont directement gérées dans le connecteur de la banque.

L’intégration des API dans notre modèle s’est généralement réalisée selon deux types de cas : soit le connecteur n’existait pas encore, soit nous avions déjà un connecteur où nous réalisions le scraping. Dans ce second cas, nous avons eu comme contrainte de maintenir une continuité de la connectivité des connexions et de s’assurer de la cohérence des données. Pour ceci nous avons introduit la notion de source. Selon cette logique, chaque connexion ou connecteur est lié à des sources (scraping ou API DSP2). Les sources doivent donc cohabiter ensemble tout en restant au maximum transparentes pour nos clients.

Mécanismes d’authentification en fonction des cas d’usages : s’adapter à la profondeur de donnée voulue

L’arrivée des nouvelles sources et de la mise en place des authentifications fortes sur les sources préexistantes ont modifié le parcours des PSU. Tout d’abord, concernant les authentifications fortes sur les sources historique de web scraping, plusieurs types de parcours ont été mis en place :

Authentification “cross-browser” : lorsque le PSU valide son authentification forte sur un appareil, celle-ci n’est plus nécessaire pendant 90 jours sur n’importe quel autre appareil. L’avantage de ce type d’authentification est que le PSU peut réaliser son authentification forte de façon autonome, sans la réaliser avec nous. Cependant, si l’authentification n’a pas été réalisée au moment d’établir la connexion chez nous, nous indiquerons au PSU qu’une action est requise. Si nous pouvons gérer la SCA sans que le PSU quitte notre solution nous le ferons, mais il est parfois difficile de développer cette partie car l’authentification n’apparaît qu’une fois tous les 90 jours.
Authentification “non cross-browser” : le PSU doit réaliser son authentification forte sur chaque nouvel appareil. Le connecteur gère alors cette authentification. Le parcours devient plus fluide, mais peut être source d’erreurs, ou le mode d’authentification peut ne pas être encore géré, ou tout simplement non gérable, comme les authentifications par certificats. De plus, la résolution de certaines erreurs dans ce parcours d’authentification ne peut se faire sans l’aide d’un PSU.
Authentification systématique : généralement établie pour les clients entreprises et couplée à une authentification forte toutes les 24 heures sur l’API de la banque. Nous pouvons gérer ces authentifications, mais sa durée de validité est un frein à la synchronisation automatisée des données pour les PSU et nos clients. Précisons qu’une décision récente de l’EBA a déclaré qu’il n’était plus possible de demander une SCA au PSU au travers un TPP plus fréquemment que 90 jours.

Ajoutons maintenant à ce parcours la source DSP2 qui nécessite elle aussi une authentification forte tous les 90 jours. En fonction de l’implémentation du connecteur, nous proposons deux types de parcours pour cette nouvelle source :

Parcours “webauth” : nous effectuons une redirection totale du PSU sur l’interface dédiée de la banque, où il devra réaliser sa double authentification de son côté avant que la banque nous redonne la main et l’accès aux données de l’API.
Parcours “credentials” : nous implémentons le scraping de la redirection, où notre connecteur gère lui-même l’authentification forte.

NB : le mode d’authentification “credentials” sera progressivement déprécié pour les APSP proposant une authentification par redirection uniquement.

Le parcours webauth a pour avantage de s’affranchir de la gestion des différents modes d’authentification, et donc d’avoir une maintenance moindre sur cette partie. Néanmoins, nous n’avons pas la main sur les éventuelles erreurs de l’interface. Parmi celles-ci, on relève régulièrement des soucis dans la fonctionnalité App2App. Là où, sur un parcours initié sur mobile, l’interface devrait mener directement à l’application de la banque, et donc faciliter l’authentification, nous avons rencontré des problèmes de compatibilités qui empêchent le parcours en fonction de la version de l’application ou de l’OS. Pour toute erreur, l’audit peut s’avérer frustrant : l’erreur qui apparaît sur la partie banque est techniquement intraçable (pas de logs de notre côté). Néanmoins, l’erreur pourra nous être remontée, et l’on pourra communiquer avec la banque à ce sujet.

En fonction du besoin du client, nous pouvons adapter le parcours. Par exemple, si le client ne s’intéresse qu’aux comptes de paiement, le parcours webauth peut s’avérer intéressant car le PSU qui sera redirigé vers l’interface de sa banque sera plus facilement mis en confiance. Dans le cas où le client s’intéresse à des types de comptes hors du scope de la DSP2 (comme des comptes d’épargne), le mode credentials sera à privilégier. En effet, si le client a choisi le parcours webauth, le PSU devrait rentrer ses identifiants une première fois sur l’interface de la banque puis sur l’interface de Budget Insight (ou du client) pour les utiliser sur la source de scraping. Le but est tout de même que le PSU puisse faire ses authentifications dans un temps le plus court possible et de la manière la plus fluide. Pour que cette expérience utilisateur soit réussie, nous travaillons parfois avec les banques pour optimiser leurs parcours. À l’avenir il est possible que la réglementation nous pousse à généraliser le parcours webauth pour les sources DSP2.

Une mission de qualité de service

Lors de la mise en production de nouvelles sources DSP2, notre mission est d’assurer la continuité du service et de la donnée remontée, de manière la plus transparente possible. Il faut se souvenir qu’une fois les authentifications fortes réalisées, nos connexions récupèrent une partie de leurs comptes sur la source DSP2, et une autre sur le site bancaire. Si l’API DSP2 ne répond pas, nous devons pouvoir récupérer les mêmes informations pour ces premiers comptes sur le site bancaire, et nous ferons donc une bascule de manière automatique jusqu’à résolution de la panne.

Lorsque l’on construit un nouveau connecteur on s’assure donc, grâce à notre connaissance métier de la donnée bancaire, que les informations sont cohérentes des deux côtés, web scraping et API DSP2. Par exemple, que les soldes sont bien identiques, que les dates de paiements avec une CB soient bien présentes, ou encore que l’on accède bien à la liste exhaustive des transactions… Au final, peu importe la source, sans même en avoir conscience, une personne utilisant nos services doit trouver les mêmes données pour pouvoir suivre ses comptes.

Partis d’une composition 100 % web scraping, la problématique était de rajouter la source DSP2 et de garantir, pour les comptes de paiement, un résultat identique après que ces comptes sont remontés par l’API à la place du site. Cela peut paraître immédiat mais en fait, pour répondre à notre objectif de qualité, la construction d’un nouveau connecteur API suit plusieurs étapes :

Ouverture des comptes au sein des banques concernées. Par expérience, très peu de banques proposent des sandboxes fonctionnelles avec des données réalistes et dont l’API réagit de la même manière que l’API de prod. Il nous faut donc absolument de la donnée réelle.
Test approfondi de l’API : solidité, codes d’erreurs, limitations, données identiques à celles sur le site. Par exemple : récupère-t-on bien trois mois de transactions dans le passé, mais également celles qui ne sont pas encore débitées ? Les libellés des transactions et des comptes sont-ils lisibles et identiques à ce qu’on trouve sur le site ? Pour les cartes à débit différé, a-t-on bien les montants totaux de débit à la fin de chaque mois, mais aussi le détail de chaque transaction, avec la date réelle de paiement ? Les IBAN sont-ils bien présents ? Nous avons en effet déjà observé des problèmes sur chacun de ces items chez de multiples banques.
Tests sur le contexte de l’API. Quelle est la qualité de la webview ? Est-elle stable ? Remonte-t-elle des messages clairs au PSU en cas d’erreurs comme un mauvais mot de passe ? L’App2App est-il bien implémenté ? Un exemple observé de parcours bloquant pour le PSU concerne une interface qui envoie pour toute erreur l’image d’un nuage qui pleure avec le message obscur “Une erreur est survenue”. Nous prenons en charge un certain niveau d’audit, quitte à remonter les erreurs à la banque plutôt que de mettre un connecteur en production au risque de recevoir des plaintes de clients plus tard.
Audit du comportement en mode intégré à notre propre API. Il s’agit de tester que non seulement une connexion est possible, mais qu’une centaine l’est tout autant. C’est là que l’on peut observer des problèmes de synchronisation journalière, éventuellement des problèmes de charge, ou encore des soucis de type donnée remontée que l’on ne pouvait voir avec notre seul compte de test. Par exemple, l’API fonctionne parfaitement pour le segment des particuliers, mais pas du tout pour celui des professionnels.
Complément aux contrôles sur la cohérence même des données, telle que décrite plus haut, dès les premières connexions établies.

Vous comprendrez aisément que pour développer de nouveaux connecteurs tout en gardant une exigence de qualité, il est nécessaire de passer par une étape importante de bêta test. Elle se traduit généralement par une mise en production en en avance de phase sur des domaines internes, puis chez un client volontaire, avant déploiement complet.

Conclusion

La DSP2 représente à la fois un challenge et une belle opportunité. Pour l’intégrer, nous avons pleinement joué la carte de l’expérimentation des nouvelles API, en essuyant quelques pots cassés. Depuis trois ans nous avons éprouvé et déployé les API de la majorité des banques françaises, et remonté aux régulateurs les difficultés dûes à une lecture minimaliste du cadre DSP2 par les banques. Une victoire récente a d’ailleurs été d’obtenir de l’Autorité de prolonger l’exemption d’authentification forte (SCA) de 90 à 180 jours.

Pour garantir une offre complète et solide et l’adapter au plus grand nombre, nous sommes convaincus qu’il faut continuer à jouer sur les deux tableaux, en proposant uniquement les sources API aux clients qui sont exclusivement intéressés par l’agrégation de données bancaires couvertes par la DSP2, et offrir notre expertise en web scraping avec nos sources dédiées aux autres données. Nous avons également rendu notre technologie plus résiliente : grâce au multi-sources, nous sommes en mesure de pouvoir récupérer la donnée à tout moment et mettre à jour les connexions de la manière la plus transparente, et ce même si un site ou une API bancaire est indisponible.

Surtout, les API DSP2 donnent la possibilité de nous ouvrir très rapidement au marché européen. Néanmoins, dans un souci de qualité, il ne s’agit pas simplement de se brancher aux API, mais de les tester en avance de phase, avec des clients et nos propres comptes. Nous avons toute l’expertise maintenant pour conquérir l’Europe.