PSD2 imposait une API aux banques. FiDA leur impose un marché.

Sous PSD2, une banque pouvait se mettre en conformité seule. Construire l'endpoint, publier la spécification, tenir l'objectif de disponibilité, terminé. La proposition Financial Data Access de la Commission européenne supprime cette option. La conformité passe par un dispositif de partage de données financières — un accord-cadre négocié entre détenteurs de données, utilisateurs de données et représentants des clients — et aucun établissement ne peut en constituer un à lui seul. Le travail technique est la moindre part. La part la plus lourde est une négociation commerciale sur le périmètre, les normes, la responsabilité et le prix, et elle se joue maintenant, pendant que la plupart des banques attendent un texte définitif.

Synthèse pour dirigeants

Le statut du texte prime sur la stratégie. FiDA a été proposé en juin 2023 dans le cadre du paquet sur l'accès aux données financières et les paiements. Le texte a figuré sur une liste de retrait ayant fuité en 2025, a survécu dans le programme de travail définitif et reste en trilogue. Rien de ce qui suit n'est du droit établi.

Le dispositif est l'objet réglementaire. Les dispositifs de partage de données financières fixent les normes communes, les exigences d'interface, les conditions de responsabilité et les mécanismes de règlement des différends. L'exposition d'une banque est déterminée par des règles qu'elle contribue à écrire ou qu'elle subit.

La rémunération redéfinit l'ensemble de l'exercice. Dès lors que l'accès porte un prix lié au coût de fourniture, une banque a besoin d'un modèle de coûts défendable, et pas seulement d'une passerelle d'API. Très peu en possèdent un.

Le chantier, ce n'est pas l'API. La plupart des établissements savent exposer un endpoint. Bien moins nombreux sont ceux qui savent localiser, normaliser et fiabiliser des données de crédit immobilier, de retraite et d'assurance qui n'ont jamais quitté leur silo produit.

Le règlement qui a failli ne jamais voir le jour

Toute stratégie construite sur FiDA doit commencer par un constat honnête de l'état réel du dossier.

La Commission l'a proposé en juin 2023, aux côtés du paquet paiements qui porte PSD3 et le règlement sur les services de paiement. Début 2025, la fuite d'un projet de programme de travail de la Commission a laissé entendre que FiDA pourrait être retiré — présenté à l'époque comme une réponse aux inquiétudes sur la charge pesant sur les établissements financiers européens. Le programme de travail définitif l'a maintenu parmi les propositions en cours, et la négociation s'est poursuivie. Le texte est passé par le trilogue et les institutions travaillent à un accord politique, les obligations devant s'appliquer progressivement après adoption, à mesure que les dispositifs se constituent.

Deux conséquences découlent de cet historique, et elles tirent en sens opposés.

La proposition est politiquement viable mais pas politiquement à l'abri : un programme qui suppose que le texte actuel sortira inchangé s'expose. Le périmètre, le calendrier et le mécanisme de rémunération sont précisément les dispositions qui bougent en trilogue.

Dans le même temps, les éléments les plus susceptibles de subsister sont les éléments structurels — gouvernance par dispositif, tableaux de bord des autorisations, principe de rémunération — parce qu'ils constituent l'architecture de la proposition plutôt que ses paramètres. Ce sont aussi ceux dont le délai de construction est le plus long.

La bonne posture n'est donc ni « attendre le texte définitif » ni « construire sur le projet actuel ». Elle consiste à bâtir les capacités que toute version plausible exigera, et à être présent là où les paramètres se décident.

Trois ruptures structurelles avec PSD2

Traiter FiDA comme un PSD2 doté d'une liste d'endpoints plus longue est l'erreur qui coûtera le plus cher.

Tableau 1 : ce qui change réellement

Dimension	PSD2	FiDA tel que proposé
Comment se conformer	Construire et publier une interface ; un acte unilatéral	Adhérer à un dispositif de partage de données financières ; un accord multipartite
Données concernées	Comptes de paiement	Crédits immobiliers, prêts, épargne, investissements, crypto-actifs, retraites, assurance non-vie
Coût de l'accès	Gratuit pour le tiers	Les détenteurs de données pourraient demander une rémunération raisonnable liée au coût de fourniture
Qui fixe la norme	Le régulateur fixe des résultats ; chaque banque choisit son implémentation	Le dispositif fixe les normes communes et les exigences d'interface
Contrôle du client	Consentement par connexion	Un tableau de bord des autorisations que le détenteur de données doit fournir
Où se situe le risque	Disponibilité et sécurité de votre interface	Également : conditions du dispositif, répartition contractuelle de la responsabilité et issue des différends

Les première et troisième lignes sont celles qui changent la forme du programme.

Le dispositif est l'objet réglementaire

Sous PSD2, la surface de conformité d'une banque était sa propre API. Sous FiDA tel que rédigé, la surface de conformité devient un règlement intérieur négocié avec des contreparties, dont les acteurs qui convoitent vos données.

Un dispositif de partage de données financières est un accord-cadre entre détenteurs de données, utilisateurs de données et représentants des consommateurs ou des clients. Il devrait élaborer les normes communes de partage de données et de requêtes d'interface, fixer la responsabilité contractuelle de ses membres et fournir un mécanisme opérationnel de règlement des différends.

Lisez cette liste comme un registre des risques et l'implication devient inconfortable. Quelqu'un décidera de la répartition de la responsabilité lorsqu'un utilisateur de données traitera mal des données clients obtenues via votre interface. Quelqu'un décidera de la norme de qualité de données à laquelle vous serez tenu, et de ce qui constitue une requête valide. Si une banque n'est pas dans la salle, ces décisions sont prises par des parties dont l'intérêt commercial est d'obtenir un accès large, des prix bas et une responsabilité portée par le détenteur.

C'est le volet le plus sous-doté du programme FiDA moyen. Les établissements ont affecté des architectes et aucun négociateur.

La rémunération transforme une obligation en produit

PSD2 obligeait les banques à céder gratuitement l'accès aux comptes de paiement. La proposition FiDA adopte une position différente : les détenteurs de données pourraient demander une rémunération raisonnable aux utilisateurs de données, liée au coût de mise à disposition, selon une méthodologie objective, transparente et non discriminatoire.

Ce seul changement convertit une obligation en quelque chose qui se rapproche d'une ligne de produits régulée — et il exige une capacité dont la plupart des banques n'ont jamais eu besoin.

Tableau 2 : ce à quoi une position de rémunération défendable doit répondre

Question	Pourquoi c'est difficile	Ce qu'il vous faut avant de pouvoir tarifer
Que coûte réellement la fourniture ?	Les coûts se répartissent entre infrastructure, sécurité, support et conformité, dont aucun n'est aujourd'hui affecté à un produit de données	Un modèle de coûts attribuant le coût des plateformes mutualisées à la fourniture de données
La méthodologie est-elle non discriminatoire ?	Les utilisateurs de données auront des volumes et des marges très différents	Un barème publié qui résiste à l'examen d'un membre du dispositif qui le conteste
Passe-t-elle à la baisse ?	La rémunération doit être orientée vers les niveaux les plus bas du marché, et non exclure par le prix	Une structure qui fonctionne pour un petit utilisateur de données, pas seulement pour un grand
Pouvez-vous en apporter la preuve ?	Un prix devient un objet prudentiel et concurrentiel dès sa publication	Une dérivation auditable, pas un chiffre négocié

Les établissements qui géreront bien ce sujet sont ceux qui commencent à chiffrer la fourniture de données dès maintenant, tant qu'il s'agit d'un exercice interne, plutôt qu'en pleine négociation de dispositif, où le chiffre devient une position à défendre.

Le chantier, ce n'est pas l'API

Le travail technique qui compte n'est pas l'interface. C'est tout ce qui se trouve derrière.

Les données de comptes de paiement étaient déjà structurées, déjà en temps réel, déjà portées par un système unique avec un propriétaire unique. Les données de crédit immobilier, de retraite, d'investissement et d'assurance ne sont rien de tout cela. Elles résident dans des silos produits d'âges différents, avec des identifiants clients différents, des référentiels différents et des définitions différentes du même champ. Une partie n'existe que sous forme de documents.

Trois capacités portent le délai de construction, et aucune ne dépend du texte définitif.

Une couche de résolution d'identité client. Servir une requête de données suppose de savoir que l'emprunteur immobilier, le titulaire de la retraite et le titulaire du compte courant sont la même personne, avec un niveau de confiance suffisant pour libérer des données sur cette base. La plupart des établissements découvrent que leur résolution d'identité est plus fragile que supposé au moment exact où ils l'éprouvent.

La normalisation des données produits. Un dispositif définira des formats communs. Quels qu'ils soient, le travail de mise en correspondance des données produits historiques vers n'importe quelle norme externe est le même travail, et c'est le poste le plus lourd du plan.

L'état des autorisations comme infrastructure. Un tableau de bord est une vue. En dessous doit se trouver un registre durable et auditable indiquant quelle autorisation a été accordée, par qui, sur quelles données, pour quelle durée, et quand elle a été retirée — interrogeable en temps réel par chaque système qui sert une requête. Les établissements qui construisent le tableau de bord avant le registre des autorisations construisent ce qu'ils devront reconstruire.

Le plan d'action opérationnel

Placez quelqu'un dans la discussion sur le dispositif. Pas un architecte — un négociateur commercial mandaté sur la responsabilité et la tarification. C'est l'action au plus fort effet de levier, et celle que l'on reporte le plus souvent.
Chiffrez la fourniture de données maintenant. Construisez le modèle d'affectation tant que la question reste interne. Une méthodologie de rémunération inventée sous pression de négociation ne résistera pas à l'examen.
Lancez la résolution d'identité avant que le périmètre soit arrêté. Toute version de FiDA suppose de savoir que votre client est un seul client. Rien de cela ne change en trilogue.
Construisez le registre des autorisations, pas le tableau de bord. L'artefact visible représente une semaine de travail front-end. Le registre en dessous se déploie sur deux ans.
Inventoriez les silos honnêtement. Identifiez les produits dans le périmètre qui sont aujourd'hui incapables de produire des données structurées et à jour. Cette liste est le véritable plan de programme.
Suivez le périmètre, pas les gros titres. Les paramètres les plus susceptibles de bouger en trilogue — quels produits, quelles données, quel calendrier — sont exactement ceux que votre plan doit pouvoir absorber sans refonte.

PSD2 a appris aux banques à traiter les données ouvertes comme un coût de conformité à minimiser. Cet instinct est le mauvais point de départ ici. Quand l'accès est tarifé, délimité par négociation et qu'il couvre les produits sur lesquels une banque gagne réellement de l'argent, les établissements qui le traitent comme un marché fixeront les conditions de ceux qui le traitent comme une charge.

Questions fréquentes

FiDA est-il déjà en vigueur ?
Non. Le texte a été proposé en juin 2023 dans le cadre du paquet sur l'accès aux données financières et les paiements et reste dans le processus législatif européen, après être passé par le trilogue. Il a figuré sur une liste de retrait ayant fuité début 2025, puis a été conservé dans le programme de travail définitif de la Commission. Le périmètre, le calendrier et le mécanisme de rémunération sont autant de dispositions qui peuvent encore bouger.

En quoi diffère-t-il de PSD2 en pratique ?
Sur trois points qui comptent. La conformité passe par un dispositif de partage de données financières plutôt que par une interface que l'on construit seul ; les détenteurs de données pourraient demander une rémunération raisonnable au lieu de fournir l'accès gratuitement ; et les données concernées vont bien au-delà des comptes de paiement, jusqu'aux crédits immobiliers, prêts, épargne, investissements, crypto-actifs, retraites et assurance non-vie.

Qu'est-ce qu'un dispositif de partage de données financières ?
Un accord-cadre entre détenteurs de données, utilisateurs de données et représentants des clients ou des consommateurs. Il devrait fixer les normes communes de données et d'interface, répartir la responsabilité contractuelle entre ses membres et assurer le règlement des différends. Parce qu'il définit les conditions auxquelles vous serez tenu, l'adhésion et l'influence sont des questions stratégiques et non administratives.

Si le texte n'est pas définitif, que peut-on utilement construire dès maintenant ?
Les éléments dont toute version aura besoin : la résolution d'identité client à travers les silos produits, la normalisation des données produits historiques vers une norme externe, et un registre durable des autorisations sous le tableau de bord. Aucun ne dépend de l'issue du périmètre ou du calendrier, et tous trois ont de longs délais de construction.

Faut-il résister à FiDA ou s'y engager ?
Résister à une proposition qui a déjà survécu à une tentative de retrait est un mauvais emploi de la fenêtre restante. La question plus productive est de savoir si votre établissement est un détenteur net ou un utilisateur net de données sur les segments qui vous intéressent — car cela détermine si vous voulez une méthodologie de rémunération haute ou basse, et cet arbitrage se règle dans le dispositif, pas à Bruxelles.

Références

Commission européenne, 2023. Paquet sur l'accès aux données financières et les paiements. Bruxelles : direction générale de la stabilité financière, des services financiers et de l'union des marchés des capitaux. Disponible à l'adresse : Commission européenne, 2023..
Commission européenne, 2023. Proposition de règlement établissant un cadre pour l'accès aux données financières, COM(2023) 360. Bruxelles : Commission européenne. Disponible à l'adresse : Commission européenne, 2023..
Parlement européen, 2026. Legislative Train Schedule : un nouveau cadre pour la finance ouverte. Bruxelles : Parlement européen. Disponible à l'adresse : Parlement européen, 2026..
Parlement européen et Conseil de l'Union européenne, 2015. Directive (UE) 2015/2366 concernant les services de paiement dans le marché intérieur (PSD2). Bruxelles : Journal officiel de l'Union européenne. Disponible à l'adresse : Parlement européen et Conseil de l'Union européenne, 2015..

Dernière révision 2026-08-08.

Republier cet article

PSD2 imposait une API aux banques. FiDA leur impose un marché. — Sebastien Rousseau

FiDA n'est pas PSD2 avec plus d'endpoints. Adhésion à un dispositif, accès aux données rémunéré et périmètre élargi : la finance ouverte devient un marché.

Cet article est sous licence Creative Commons Attribution 4.0 International. La republication nécessite l'attribution à l'URL canonique.

PSD2 imposait une API aux banques. FiDA leur impose un marché. — Sebastien Rousseau

FiDA n'est pas PSD2 avec plus d'endpoints. Adhésion à un dispositif, accès aux données rémunéré et périmètre élargi : la finance ouverte devient un marché.

Originally published at https://sebastienrousseau.com/fr/2026-07-31-fida-open-finance-data-sharing-schemes-banques-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FONDATEUR · INGÉNIEUR