Audit FIDA — Conformité Financial Data Access Regulation (open finance UE 2026-2028)

#Pourquoi l'audit FIDA devient urgent en 2026

FIDA — Financial Data Access Regulation, proposé par la Commission européenne en juin 2023 — est encore en cours de négociation, et son calendrier peut évoluer. Quand le texte sera adopté, une période de mise en conformité progressive suivra. Beaucoup d'établissements considèrent encore que 2027 est loin.

C'est une erreur. Exposer des APIs FIDA conformes prend rarement moins de 12 mois côté SI, et il faut compter en plus le temps de cartographie des données, de gouvernance, de préparation du dossier d'agrément.

Ce qui change réellement avec FIDA, ce n'est pas la technique — c'est le périmètre. DSP2 (2018) a ouvert les comptes de paiement aux AISP et PISP. DSP3 (en discussion finale aussi) reste sur le périmètre paiement avec un meilleur cadre (authentification forte, fraude, supervision).

FIDA bascule l'ouverture à l'ensemble du patrimoine financier : épargne bancaire, OPCVM, crédits, assurance vie et IARD, mutuelles santé, retraite supplémentaire, investissement. Pour la première fois, une institution financière non bancaire — un assureur, un gestionnaire d'actifs, une institution de prévoyance — devra exposer des APIs ouvertes vers des tiers agréés. C'est un changement de monde.

Une nuance honnête : la définition FIDA que nous publions dans le glossaire Nehos précise le périmètre exact et le calendrier prévisionnel sous réserve d'aboutissement du trilogue. Le texte peut encore évoluer marginalement sur les schémas de données et les délais de mise en conformité.

Notre méthode prend en compte cette incertitude : nous lançons l'audit gap dès maintenant pour donner aux clients une visibilité chiffrée, mais nous ne déclenchons les chantiers techniques lourds qu'après publication du texte final pour éviter les retravaux.

#FIDA vs DSP2 vs DSP3 — Comprendre la mécanique

C'est la question que posent le plus souvent les acteurs de la banque et de l'assurance. Voici la mécanique exacte.

DSP2 (Directive UE 2015/2366, application 2018) — directive qui a créé les statuts AISP (Account Information Service Provider) et PISP (Payment Initiation Service Provider). Périmètre limité aux comptes de paiement (comptes courants, cartes). Permet à un tiers agréé d'agréger les comptes d'un client avec son consentement, ou d'initier un paiement en son nom.

Authentification forte (SCA) obligatoire. Régulateur en France : ACPR pour l'agrément, Banque de France pour la supervision technique.

DSP3 (en cours, application prévue 2027) — révision de DSP2. Étend les obligations aux comptes de paiement au sens large (incluant monnaie électronique, certains comptes d'épargne très liquides). Renforce les obligations d'authentification, la lutte contre la fraude, la qualité des API. Crée un cadre supervision plus robuste. Reste dans le périmètre paiement — pas d'extension aux autres produits financiers.

FIDA (en cours, application prévue 2027-2028) — règlement européen (donc d'application directe sans transposition nationale) qui étend l'open banking à l'ensemble des données financières détenues par un établissement régulé. Périmètre cible : épargne et placements bancaires (livrets, comptes à terme, OPCVM, FCP), crédit (consommation, immobilier, professionnel), assurance non-vie (auto, habitation, santé, MRH), assurance vie et capitalisation, produits de retraite (PER individuel et entreprise, Madelin, articles 39/82/83), produits d'investissement, crypto-actifs sous MiCA.

Le schéma mental à retenir : DSP2/DSP3 traitent du « payer » (flux de paiement). FIDA traite du « savoir financier complet » (stock de données patrimoniales). Les deux textes sont publiés en paquet et conçus pour fonctionner ensemble dans un cadre cohérent d'open finance européen.

#Les obligations FIDA — Ce que l'auditeur vérifie

#Obligation 1 : APIs sortantes standardisées

Chaque institution financière détentrice de données client devra exposer des APIs ouvertes permettant à des FISP agréés d'accéder à ces données, avec consentement explicite et révocable du client. Les standards techniques exacts seront précisés par des RTS (Regulatory Technical Standards) publiés par l'EBA et l'EIOPA après publication du règlement.

Les schémas de données sont structurés par grande catégorie de produit (épargne, crédit, assurance, retraite, investissement) avec des champs harmonisés.

Ce qu'on vérifie en audit : inventaire des données client existantes par produit, qualité et fraîcheur des données (data lineage, freshness SLA), capacité technique du core banking ou du système de gestion à exposer ces données en temps quasi-réel, conformité aux schémas EBA prévisionnels (en attendant les RTS finaux, nous utilisons les proposals 2024-2025), performance (latence cible à fixer avec vous sur les requêtes simples).

#Obligation 2 : Interfaces de gestion des permissions citoyennes

FIDA impose que le client puisse, à tout moment, voir quelles permissions il a accordées, à quels FISP, sur quels produits, et révoquer ces permissions à la demande. Concrètement, chaque banque et chaque assureur devra mettre à disposition un tableau de bord consentements dans son espace client digital, lisible par tous les segments (y compris seniors), avec les fonctionnalités obligatoires : visualisation des permissions actives, durée et portée de chaque permission, révocation en un clic, historique des accès passés.

Écueil fréquent : sous-estimer la complexité UX du tableau de bord. Un bon tableau de bord consentements n'est pas une liste technique de logs API — c'est une interface citoyenne qui explique en langage clair ce qu'un FISP voit, pourquoi, pendant combien de temps. Nous recommandons un design sprint UX dédié.

#Obligation 3 : Traçabilité complète des accès

Chaque accès à une donnée client par un FISP doit être tracé de manière auditable : identité du FISP, identifiant du client, données consultées, horodatage, base légale (consentement), durée de conservation des logs. Les autorités (ACPR, AMF, EBA) peuvent demander ces logs en cas de contrôle ou d'incident. La durée de rétention des logs se fixe en cohérence avec les obligations LCB-FT et RGPD.

En audit, on vérifie : architecture de logging conforme (SIEM Wazuh, Splunk, Sentinel ou équivalent), volumétrie soutenable, capacité d'extraction en cas de demande ACPR, articulation avec le journal des traitements RGPD, mise en cohérence avec les obligations DORA (gestion incidents). Erreur courante chez les fintechs : avoir un logging technique correct mais aucun process de réponse à une demande d'extraction réglementaire.

#Obligation 4 : Sanctions et supervision

FIDA étant un règlement, les sanctions devraient être harmonisées au niveau européen, avec des amendes administratives et un pouvoir de retrait d'agrément FISP, mais leur niveau exact dépendra du texte final. La supervision conjointe ACPR/AMF/EBA pourra publier les sanctions. Les manquements visés sont notamment le refus d'accès non motivé, la qualité d'API dégradée et l'atteinte à l'intégrité des données.

#Le statut FISP — Nouvelle catégorie créée par FIDA

FIDA crée un nouveau statut d'acteur : le FISP (Financial Information Service Provider). C'est l'équivalent open finance de l'AISP en open banking. Un FISP est un tiers agréé par l'ACPR (ou autorité compétente) pour accéder aux données financières client avec consentement, et fournir un service à valeur ajoutée : agrégation patrimoniale 360°, scoring crédit alternatif, comparateurs assurance, optimisation retraite, conseil patrimonial augmenté, portabilité de contrats.

Pour les fintechs déjà AISP au titre de DSP2, FIDA est une opportunité d'extension de business model : un AISP qui passe FISP peut élargir son offre des comptes de paiement à l'ensemble du patrimoine du client. Concrètement, plusieurs fintechs françaises (Bridge, Tink/Powens, Bankin', Linxo, Budget Insight) préparent déjà leur extension AISP → FISP. Pour un néo-courtier ou un comparateur assurance qui n'a pas le statut AISP, le statut FISP est la porte d'entrée directe.

Notre conseil pour les fintechs : démarrer la gap analyse FISP dès maintenant. Un agrément ACPR demande plusieurs mois entre le dépôt du dossier complet et la notification : mieux vaut préparer le dossier en amont.

#Qui est concerné — Le périmètre FIDA

FIDA s'applique à toutes les institutions financières détentrices de données client en Europe. Périmètre détaillé : banques de détail et de financement, établissements de crédit, banques mutualistes, assureurs vie et IARD, mutuelles santé et prévoyance, institutions de retraite professionnelle (IRP), gestionnaires d'OPCVM et de FIA, sociétés de gestion d'actifs, plateformes de crypto-actifs sous MiCA, plateformes de financement participatif (ECSP), conseillers en investissement financier (CIF).

C'est ce point qui distingue FIDA de DSP2/DSP3 : toutes les institutions, pas seulement bancaires. Un assureur vie historique qui n'a jamais exposé d'API ouverte va devoir construire une infrastructure complète. Un gestionnaire d'actifs qui ne distribuait que via des conseillers physiques va devoir s'organiser pour répondre à des demandes d'API entrantes de FISP. C'est un chantier transformation pour beaucoup d'acteurs.

Des proportionnalités existent. Les très petits acteurs (microentreprises au sens UE : moins de 10 salariés et CA inférieur à 2 M€) bénéficient d'allègements. Les grands groupes bancaires et assurantiels (banques d'importance systémique, assureurs significatifs) auront des obligations renforcées en matière de qualité de service API, de gouvernance et de supervision.

Les acteurs qui se préparent activement sont surtout des banques mutualistes régionales (réutilisation de l'infrastructure DSP2 + extension), des assureurs vie et IARD historiques, des fintechs AISP visant le statut FISP et des mutuelles santé.

#Méthode Nehos audit FIDA

Notre méthode en quatre temps, calibrée par nos missions DSP2/DSP3 livrées entre 2022 et 2026.

Phase 1 — Audit gap FIDA (3 à 5 semaines selon le scope) : cartographie des données financières concernées par produit (épargne, crédit, assurance vie, IARD, retraite, investissement), inventaire des APIs existantes (DSP2 si applicable, APIs partenaires existantes, APIs internes), mesure du gap réglementaire FIDA (schémas EBA prévisionnels, performance, sécurité, consentement), entretiens avec les parties prenantes (direction, RSSI, DPO, métiers banque/assurance, IT, conformité), restitution chiffrée avec plan d'action priorisé. Livrables : rapport d'audit, matrice de conformité produit par produit, gap list priorisée, devis détaillé phase 2.

Phase 2 — Architecture APIs FIDA (1-2 semaines de design + 12 à 26 semaines de build) : conception des APIs sortantes selon standards EBA prévisionnels, design des schémas de données par produit, architecture du tableau de bord consentements citoyens, infrastructure de logging et traçabilité, intégration avec le core banking (banques) ou les systèmes de gestion (assureurs, gestionnaires d'actifs). Build itératif avec démos régulières en comité projet.

Phase 3 — Préparation agrément autorité (selon statut visé) : pour les banques et assureurs déjà régulés, dossier de notification à l'ACPR ou l'AMF selon périmètre. Pour les fintechs visant le statut FISP, dossier d'agrément complet (programme d'activités, organisation, gouvernance, RSSI, plan de continuité, fonds propres). Le délai entre dépôt et notification dépend de l'autorité.

Phase 4 — MCO conformité (selon scope) : pour toutes les entités, MCO conformité annuelle (audit annuel, mise à jour cartographie données, accompagnement contrôles ACPR/AMF ad hoc), évolution des APIs au rythme des RTS et des Q&A EBA, gestion incidents et notification autorités si applicable.

#Articulation FIDA avec les autres réglementations 2026-2028

FIDA n'arrive pas seule. Pour le secteur financier français, la convergence réglementaire 2026-2028 inclut : DSP3 (paquet avec FIDA, publication finale Q3 2026), DORA (déjà en application depuis 17 janvier 2025), AI Act (Règlement UE 2024/1689, en application 1er août 2026, scoring crédit et assurance vie classés haut risque), NIS2 (transposition FR octobre 2024), RGPD (toujours), MiCA (en application juin 2024 pour les crypto-actifs).

Notre angle : on traite FIDA + DSP3 + DORA + AI Act dans un programme intégré quand l'établissement le souhaite, parce qu'une part importante des actions techniques se recoupent (gouvernance, gestion incidents, traçabilité, audit, APIs, sécurité). Cela évite de refaire plusieurs fois le même travail.

Voir notre audit DORA conformité Règlement UE 2022/2554 pour le volet résilience, et notre service Open Banking DSP3 pour le volet paiements.

#Tarification — sur devis

Le budget d'un programme de conformité FIDA dépend du profil de l'établissement. Chaque programme est chiffré sur devis, en 48 h après un premier échange.

• Audit gap FIDA seul : sur devis selon le scope (fintech, banque, assureur mid-market, banque mutualiste régionale). Durée 3-5 semaines.
• Fintech AISP étendant vers statut FISP : programme complet (architecture + agrément + maintien 6 mois), sur devis. Durée 14-22 semaines + délai d'agrément.
• Assureur vie ou IARD ouvrant APIs FIDA aux partenaires : sur devis. Durée 18-30 semaines.
• Banque mutualiste régionale anticipant FIDA : sur devis, en réutilisant l'infrastructure DSP2 existante et en l'étendant à l'épargne et au crédit. Durée 22-36 semaines.

Devis détaillé sous 48 heures après un premier échange. Pour les acteurs qui veulent une visibilité chiffrée avant publication du texte FIDA final, nous proposons un audit gap court qui donne déjà une bonne partie de la feuille de route utile.