Lorsque la DSP2 est entrée en vigueur en 2018, les prestataires de services d'information sur les comptes (AISP) ont acquis une existence juridique officielle. Les banques ont eu l'obligation d'ouvrir leurs API à des tiers agréés, et les consommateurs ont obtenu le droit légal d'autoriser ces tiers à accéder aux données de leurs comptes de paiement. Sept ans plus tard, des centaines d'AISP sont enregistrés à travers l'Europe, et ce modèle s'est étendu au Royaume-Uni, au Brésil, à l'Australie et à certaines régions du Moyen-Orient.
Mais la réalité de la construction sur une infrastructure AISP est plus complexe que ne le suggère la réglementation. La qualité des API bancaires varie d'une banque à l'autre et d'un pays à l'autre. Ce que vous pouvez construire à partir des données AISP dépend non seulement de ce que l'AISP peut extraire de la banque, mais aussi de ce qui se passe une fois que ces données quittent la banque : où elles aboutissent et quel système les réconcilie. Pour les banques et les fintechs qui évaluent la place des AISP dans leur stratégie produit, les détails des deux côtés du pipeline importent plus que le concept lui-même.
Ce qu'un AISP fait réellement (et ce qu'il ne fait pas)
Un AISP dispose d'un accès en lecture seule aux comptes de paiement d'un utilisateur, accordé par un consentement explicite et authentifié via l'authentification forte du client (SCA). Il peut extraire des données de transaction et des métadonnées de base telles que la devise et l'IBAN. Il ne peut en aucun cas transférer de l'argent ou modifier les données du compte. L'initiation de paiement relève d'une licence distincte.
En pratique, les AISP extraient des données de transaction structurées des banques via des API dédiées et les agrègent dans une vue unique. Un client possédant des comptes dans plusieurs banques peut consulter ses soldes et ses transactions au même endroit, sans avoir à se connecter à chaque application bancaire séparément. Cette couche d'agrégation constitue le fondement de la gestion des finances personnelles, de la comptabilité automatisée et du scoring de crédit.
Dans le cadre de la DSP2, le consentement de l'utilisateur est valable 180 jours avant une nouvelle authentification. La DSP3 et le règlement associé (PSR) ont fait l'objet d'un accord politique provisoire le 27 novembre 2025, avec une publication attendue au premier semestre 2026 et une application complète prévue entre fin 2027 et début 2028. Les mécanismes de consentement évoluent de deux manières importantes. Premièrement, la banque n'effectue la SCA que lors du premier accès de l'utilisateur via un AISP donné. L'AISP gère ensuite lui-même la réauthentification continue tous les 180 jours, supprimant ainsi la friction liée à la redirection vers la banque à chaque renouvellement. Deuxièmement, les API bancaires doivent correspondre aux performances et à la disponibilité des données des canaux directs de la banque, comblant ainsi l'une des lacunes les plus persistantes de la DSP2.
Le problème de connectivité que personne n'a résolu avec la première directive
La DSP2 imposait aux banques de fournir des API. Elle n'exigeait pas que ces API soient de qualité. Le résultat a été inégal. Certaines banques ont mis en œuvre des API conformes aux normes Berlin Group ou STET, avec une disponibilité solide et des structures de données cohérentes. D'autres ont fourni le strict minimum, avec des pannes fréquentes et des formats de réponse non standard qui rendaient les cas d'usage en temps réel impraticables.
C'est important car la valeur des produits basés sur les AISP dépend de la fiabilité du pipeline de données. Un outil de gestion des finances personnelles qui affiche des soldes obsolètes ou des transactions mal catégorisées fait plus de tort que l'absence d'outil. Un modèle de scoring de crédit qui ingère des historiques de transactions incomplets produit de moins bons résultats qu'un modèle utilisant les données traditionnelles des bureaux de crédit.
La couche d'agrégation a émergé en raison de cette fragmentation. Tink (acquis par Visa en 2022) et TrueLayer ont construit un middleware qui normalise les connexions entre des centaines de banques, gérant les différences de formats d'API et de flux d'authentification afin que l'application en aval n'ait pas à le faire. Pour la plupart des fintechs qui s'appuient sur les données de l'open banking, se connecter à un agrégateur plutôt que d'intégrer banque par banque est la voie la plus pragmatique. Vous construisez une seule intégration au lieu de dizaines, et l'agrégateur assure la maintenance des connecteurs.
Le compromis est que vous héritez de la couverture et de la latence de l'agrégateur. S'ils ne prennent pas en charge une banque particulière dans un pays donné, votre produit ne fonctionnera pas là-bas. Si leur logique de normalisation catégorise mal un type de transaction, vos données héritent de cette erreur. Choisir un agrégateur est une décision d'achat qui a des conséquences sur le produit.
L'autre moitié du pipeline : l'Open Accounting
La plupart des discussions sur les produits basés sur les AISP s'arrêtent à l'API bancaire. Ce n'est que la moitié de l'histoire. Chaque cas d'usage qui consomme des données bancaires doit également transmettre ces données, ou les informations qui en découlent, quelque part. Pour les PME et les entreprises, la destination est presque toujours un système comptable ou un ERP.
L'Open Accounting est le terme utilisé par l'Open Banking Tracker pour désigner ce second pipeline. Il décrit la même idée que l'Open Banking appliquée aux données comptables : un accès standardisé et programmatique aux enregistrements conservés dans les systèmes comptables et les ERP, échangés via des API. Les mécanismes ressemblent à ceux de l'intégration AISP, mais le cadre réglementaire diffère sur un point important : il n'existe aucun cadre réglementaire.
Aucune directive n'a forcé Intuit ou Xero à exposer des API. Ils l'ont fait pour des raisons liées à leur écosystème. Leurs API varient tout autant en termes de portée et de modèles d'authentification que les API bancaires que la DSP2 était censée standardiser. Le même modèle d'agrégateur qui a pris le dessus dans l'Open Banking est apparu du côté de la comptabilité. Apideck propose des API comptables unifiées qui se connectent à plus de 40 plateformes comptables et ERP via une intégration unique. Rutter et Merge offrent une couverture similaire avec des modèles commerciaux différents et la prise en charge d'un nombre moindre de connecteurs.
Pour une banque ou une fintech qui développe des produits couvrant les deux pipelines, ignorer cette couche signifie devoir la reconstruire. Une intégration QuickBooks prend des semaines. Étendre cette intégration à Xero et NetSuite, puis à la longue traîne des plateformes qui les suivent, se transforme en mois de travail et en maintenance continue. L'agrégateur d'Open Accounting est à la comptabilité ce que Tink et TrueLayer sont à la banque : la couche qui vous permet de déployer une seule intégration au lieu de dizaines.
Là où les deux flux alimentent des produits réels
L'agrégation de comptes pour la gestion des finances personnelles (PFM) demeure le cas d'usage le plus établi pour les AISP. Plusieurs grandes banques européennes proposent désormais des vues agrégées permettant aux clients d'avoir une vision financière complète, même lorsqu'ils détiennent des comptes ailleurs. Il s'agit à la fois d'une stratégie de rétention (votre banque devient le point d'accès unique pour toutes les finances) et d'une stratégie de données (vous apprenez où les clients dépensent leur argent en dehors de votre écosystème). L'agrégation est également ce qui bénéficie le plus de la réduction des frictions liées à l'authentification forte (SCA) prévue par la DSP3.
La prise de décision en matière de crédit est le domaine où la pression réglementaire est la plus forte actuellement. Les prêteurs dans l'UE se préparent à la CCD2, la directive révisée sur le crédit aux consommateurs, qui s'applique à partir de novembre 2026 et oblige les prêteurs à vérifier que les emprunteurs ont les moyens de rembourser leurs engagements. Les données de transaction provenant des AISP offrent une vue granulaire des revenus, des dépenses récurrentes et des habitudes de consommation, allant bien au-delà d'une vérification traditionnelle auprès d'un bureau de crédit. Pour les fournisseurs de BNPL, cette question est urgente, car la CCD2 les soumet aux mêmes exigences d'évaluation de la solvabilité que les prêteurs à la consommation traditionnels.
Qu'est-ce que la CCD2 ? Le contexte, le calendrier et ce que cela signifie réellement pour les prêteurs et le BNPL
L'automatisation de la tenue de livres est l'exemple le plus clair de l'importance de ces deux flux. L'AISP récupère les transactions bancaires dans un format structuré. Un moteur de correspondance rapproche ces transactions des enregistrements comptables en croisant les montants et les libellés de paiement. Le résultat réconcilié est ensuite réinjecté dans le système comptable utilisé par le client. Le volet bancaire de cette boucle est résolu par un AISP. Le volet comptable est résolu par un agrégateur de comptabilité ouverte. Si vous faites l'impasse sur l'une de ces couches, vous vous retrouvez à devoir développer des dizaines d'intégrations.
La banque intégrée aux ERP est le cas d'usage qui retient le plus l'attention des équipes de banque commerciale en 2025 et 2026. L'idée est d'intégrer les fonctionnalités bancaires directement dans l'ERP ou le système comptable que l'entreprise utilise au quotidien. L'intégration de Monzo avec Xero synchronise les transactions et les catégories de suivi sans quitter l'application Monzo. Allica Bank envoie des flux bancaires de qualité ERP directement dans les systèmes comptables utilisés par ses clients PME, avec des montants de transaction et des informations sur les marchands enregistrés sous forme de données structurées. J.P. Morgan et HSBC développent des solutions similaires pour leurs clients entreprises. Q2 a lancé son produit Direct ERP en mai 2025 pour permettre aux petites banques et coopératives de crédit américaines d'offrir la même capacité sans avoir à la développer elles-mêmes. Datos Insights estime le marché de la banque intégrée aux ERP entre 11 et 19 milliards de dollars, avec une croissance proche de 10 % par an. Rien de tout cela ne peut voir le jour sans la connexion des deux flux.
Ce que change le FIDA (et quand)
Le règlement sur l'accès aux données financières (FIDA), proposé parallèlement à la DSP3 et au PSR en juin 2023, étend le modèle de l'open banking au-delà des comptes de paiement. Il couvre les données d'investissement et de retraite sous une nouvelle catégorie de prestataire de services d'information financière (FISP), tout en incluant également les polices d'assurance et les données de prêts hypothécaires.
Le calendrier du FIDA est moins certain que celui de la DSP3. Le premier trilogue a débuté en avril 2025. Certains observateurs tablent sur une adoption au premier semestre 2026, avec une application 24 mois après son entrée en vigueur. D'autres notent que les trilogues ont été laborieux et que le FIDA apparaît comme un dossier en attente dans le programme de travail 2026 de l'UE, ce qui laisse la porte ouverte à de nouveaux retards. Le mécanisme de compensation entre les détenteurs de données et les utilisateurs de données, c'est-à-dire qui paie qui pour quelles données, reste le point le plus contesté des négociations.
Pour les banques et les fintechs qui s'appuient déjà sur une infrastructure AISP, le FIDA représente une extension significative de ce que peuvent inclure les vues financières consolidées. Un outil de PFM qui affiche aujourd'hui des comptes bancaires et des cartes de crédit pourrait, grâce au FIDA, afficher également des soldes de retraite et des portefeuilles d'investissement. La surface de produit s'élargit. La complexité d'intégration aussi, car les données d'assurance et d'investissement résident dans des systèmes encore plus fragmentés que les données comptables.
Les enregistrements AISP existants devraient être intégrés au régime de la DSP3 avec un minimum de ré-autorisation. Les entreprises prévoyant de s'étendre aux données d'investissement ou d'assurance dans le cadre du FIDA auront besoin de la nouvelle licence FISP, mais le parcours réglementaire est conçu pour étendre le cadre AISP plutôt que de le remplacer.
Choisir sa méthode de connexion
Pour une banque ou une fintech qui décide de la manière d'intégrer des capacités AISP dans un produit, l'éventail des possibles va de l'autonomie totale à l'externalisation complète.
À une extrémité, vous obtenez votre propre licence AISP (ou PISP, si vous avez également besoin de l'initiation de paiement) et vous vous intégrez individuellement à l'API de chaque banque. Vous bénéficiez d'un contrôle maximal sans dépendance vis-à-vis d'un agrégateur, mais vous devez maintenir les connecteurs pour chaque banque supportée et gérer les flux SCA à travers les juridictions. Cela est pertinent si l'intégralité de votre modèle économique repose sur les données de compte.
À l'autre extrémité, vous vous intégrez une seule fois à un agrégateur qui maintient des centaines de connexions bancaires. Vous bénéficiez d'une large couverture et d'une mise sur le marché rapide, mais vous dépendez de la qualité de leurs données et de leur tarification. Pour la plupart des fintechs qui lancent leur première fonctionnalité d'open banking, c'est le choix pragmatique.
Une solution intermédiaire courante pour les banques consiste à devenir un AISP afin d'accéder aux données d'autres établissements, tout en exposant leurs propres API à des tiers agréés. Vous pouvez ainsi proposer une agrégation multi-bancaire à vos clients tout en participant à l'écosystème plus large de l'open banking en tant que source de données.
La même logique s'applique à l'Open Accounting. Vous pouvez développer vous-même des connecteurs vers les principales plateformes comptables, ou souscrire à une API comptable unifiée pour gagner en rapidité. La plupart des banques qui développent des produits bancaires pour ERP optent pour la seconde solution, car l'alternative impliquerait de maintenir une équipe d'intégration permanente pour une activité qui n'est pas leur cœur de métier.
Ce qui est concret aujourd'hui
Le paysage réglementaire évolue. La publication de la DSP3 est attendue pour le premier semestre 2026, avec une mise en conformité totale prévue fin 2027 ou début 2028. Le cadre FIDA suivra un calendrier similaire, bien que plus lent. Les banques qui considéreront 2026 comme une année de préparation plutôt que d'attendre les textes définitifs seront mieux armées lorsque les échéances de mise en œuvre arriveront.
Côté produit, les cas d'usage offrant le meilleur retour sur investissement sont actuellement l'agrégation de comptes, l'octroi de crédit et les services bancaires pour ERP. Tous trois bénéficient de la réduction des frictions liées à l'authentification forte (DSP3) et de l'amélioration de la qualité des API imposée par la nouvelle réglementation. Les cas d'usage qui exploitent les deux canaux, comme les services bancaires pour ERP et l'automatisation comptable, nécessitent une couche d'Open Accounting pour être déployés dans des délais raisonnables.
Pour les banques qui investissent déjà dans l'enrichissement des données de transaction (transformer des libellés de paiement bruts en noms de marchands et catégories lisibles), les données AISP constituent un complément naturel. Les données enrichies issues de vos propres transactions par carte, combinées aux données agrégées des comptes externes d'un client, vous offrent une vision financière qu'aucune de ces sources ne peut fournir seule. Associez cette vision à une capacité d'écriture dans le système comptable du client, et vous obtenez les bases nécessaires pour proposer des analyses de dépenses inter-établissements et des produits bancaires intégrés aux ERP, capables de couvrir l'ensemble de la situation financière d'un client, et non plus seulement ce qui se passe au sein de votre propre établissement.
