FIDA open finance : le règlement qui étend l'open banking à toute la finance — guide entreprise 2026

#FIDA : le règlement qui étend l'open banking à toute la finance

La DSP2 (Directive sur les Services de Paiement 2) avait posé en 2018 le premier jalon de l'open banking européen en obligeant les banques à exposer les données de comptes courants via des API standardisées. Ce périmètre, centré sur les transactions courantes et les virements, laissait de côté l'essentiel du patrimoine financier des Européens : les contrats d'assurance-vie, les plans d'épargne retraite, les portefeuilles d'investissement, les contrats immobiliers.

En France, l'assurance-vie occupe une place centrale dans le patrimoine financier des ménages — des données entièrement hors périmètre DSP2.

FIDA (Financial Data Access), proposé par la Commission européenne en 2023 et en cours de finalisation au niveau européen, vise à combler ce vide structurel. Son ambition est explicite : ériger la portabilité des données financières universelle comme un droit fondamental du consommateur européen.

Chaque titulaire de produit financier peut autoriser, via un consentement granulaire, tout prestataire agréé à accéder à ses données — quelle que soit leur nature ou l'institution qui les détient.

Sont directement concernés par FIDA : les banques (données comptes courants, crédits), les assureurs (contrats vie, prévoyance, santé, habitation), les gestionnaires d'actifs (fonds d'investissement, OPCVM), les teneurs de comptes d'épargne (PEA, livrets réglementés, plans d'épargne entreprise), les caisses de retraite complémentaire (AGIRC-ARRCO et équivalents) et les prêteurs (crédits immobiliers, crédits à la consommation longue durée).

Une fois adopté, le règlement s'appliquera directement dans tous les États membres sans transposition nationale, avec une entrée en application progressive.

---

#Ce que FIDA oblige concrètement

FIDA impose aux institutions financières couvertes de construire et maintenir des API de données standardisées donnant accès à un ensemble de données précisément défini par le règlement.

#Données assurance

Les assureurs doivent exposer via API : les contrats en portefeuille (nature, date de souscription, bénéficiaires, garanties), l'historique des sinistres (date, nature, montant indemnisé), et les cotisations (montant, périodicité, historique des versements). Pour les contrats d'assurance-vie, la valeur de rachat et les unités de compte doivent être accessibles en temps quasi-réel.

#Données épargne

Les teneurs de comptes d'épargne exposent : les soldes et mouvements de PEA, d'assurance-vie (fonds euros + UC), et de Plan d'Épargne Retraite (PER), avec les performances historiques ventilées par actif. Les données de Plan d'Épargne Entreprise (PEE) et de Plan d'Épargne pour la Retraite Collectif (PERCO/PERCOL) sont également dans le périmètre.

#Données investissement

Les gestionnaires d'actifs et les brokers exposent la composition des portefeuilles (ISIN, quantités, valorisation temps réel ou J-1), l'historique de performance (TRI, rendement annualisé, comparaison benchmark), et les données de coût (frais de gestion, commissions).

#Données crédit long terme

Les prêteurs exposent les encours de crédit (capital restant dû, taux, échéances) pour les crédits immobiliers et les crédits à la consommation supérieurs à 75 000 euros ou de durée supérieure à 5 ans.

#Consentement granulaire obligatoire

Chaque accès à une catégorie de données est conditionné à un consentement explicite du titulaire, délivré pour un périmètre précis (institution, type de données, prestataire destinataire) et une durée maximale définie par le règlement. Le consentement est révocable à tout moment en temps réel via le Permission Dashboard.

#Calendrier de mise en conformité

Le calendrier envisagé prévoit deux échéances clés : les API assurance en premier (visées mi-2027), puis les API épargne, investissement et crédit long terme (visées fin 2028). Ces dates sont susceptibles d'évoluer avec le texte final. La priorité donnée aux données assurance reflète leur importance patrimoniale et l'absence totale de standardisation actuelle dans ce secteur.

---

#Les nouveaux acteurs que FIDA crée

#Financial Information Service Providers (FISP)

Les FISP sont la nouvelle catégorie d'acteurs agréés définie par FIDA, équivalents aux AISP de DSP2 mais avec un périmètre étendu à toutes les données financières consenties. Tout acteur souhaitant agréger des données au-delà des comptes bancaires doit obtenir un agrément FISP auprès de l'autorité compétente nationale (ACPR en France), délivré selon des critères harmonisés au niveau européen.

L'agrément FISP ouvre droit à un passeport européen : un FISP agréé en France peut opérer dans les 27 États membres. Le cas d'usage central est le conseil financier personnalisé 360° : une application FISP peut agréger compte courant, assurance-vie, PEA, PER, crédit immobilier et contrats de prévoyance pour produire une vision patrimoniale exhaustive — et y adosser du conseil automatisé ou humain.

#Customer Data Access Schemes

FIDA prévoit la création de Customer Data Access Schemes, des consortiums sectoriels rassemblant les institutions d'un même secteur (ex : tous les assureurs français, tous les gestionnaires de PEA) pour définir et maintenir les standards techniques des API d'accès aux données.

Ces schemes fonctionnent selon un modèle de gouvernance partagée, avec des spécifications techniques publiées et maintenues collectivement, sous supervision de l'EIOPA (assurance) et de l'ESMA (investissement).

#Permission Dashboard

FIDA oblige chaque institution financière à proposer à ses clients un Permission Dashboard — un tableau de bord des consentements financiers actifs. Ce tableau de bord liste exhaustivement : tous les FISP ayant accès aux données du titulaire, le périmètre exact des données partagées avec chacun, la date d'expiration de chaque consentement, et un bouton de révocation individuelle à effet immédiat. Le Permission Dashboard doit être accessible depuis l'espace client web et l'application mobile de chaque institution.

---

#Opportunités produit pour les fintechs

FIDA est un changement de paradigme pour les fintechs : il déverrouille des cas d'usage qui nécessitaient jusqu'ici des partenariats commerciaux complexes avec chaque institution.

#Agrégateur patrimonial complet

L'opportunité la plus directe : un agrégateur patrimonial 360° combinant comptes bancaires (DSP2/DSP3), assurance-vie, PEA, PER, crédit immobilier et prévoyance en une seule interface. Ce type de produit existe déjà en version dégradée (données partielles, souvent limitées aux comptes bancaires) — FIDA permet enfin de tenir la promesse de la vue patrimoniale complète.

#Comparateur assurance avec données réelles

Un comparateur d'assurance FISP peut accéder aux contrats existants du prospect et proposer des comparaisons basées sur sa situation réelle (garanties actuelles, cotisations, historique sinistres) plutôt que sur un profil déclaratif. La pertinence des recommandations est structurellement supérieure à celle des comparateurs actuels.

#Coach financier IA avec accès historique complet

Un agent IA couplé à un accès FISP peut analyser l'ensemble du patrimoine d'un utilisateur et produire des recommandations contextualisées : arbitrage PEA vs assurance-vie selon la fiscalité, optimisation de l'allocation retraite, identification de sur-assurances. L'architecture RAG est particulièrement adaptée pour interroger ces données hétérogènes en langage naturel.

#Scoring crédit enrichi

Un prêteur FISP peut remplacer les déclarations de revenus et patrimoine (souvent inexactes ou obsolètes) par des données certifiées temps réel : valorisation PEA, encours assurance-vie, historique de remboursement crédit. Le scoring basé sur les données réelles réduit le risque de sélection adverse et permet d'ouvrir le crédit à des profils sous-servis (travailleurs indépendants, expatriés) dont le patrimoine réel dépasse les signaux conventionnels.

#Planificateur retraite multi-actifs

Un outil de planification retraite FISP agrège les droits AGIRC-ARRCO (si dans le périmètre), le PER, le PERCO, et l'assurance-vie pour simuler des scénarios de rente en tenant compte de l'ensemble des actifs détenus. Ce type de projection multi-actifs est aujourd'hui impossible sans une saisie manuelle fastidieuse des données.

---

#Obligations pour les DSI des incumbents

Pour les banques, assureurs, gestionnaires d'actifs et caisses de retraite, FIDA représente un programme de transformation technique majeur.

#API de données FIDA-compliant

Les API exposées doivent respecter un standard de qualité strict : format JSON normalisé selon les spécifications des Customer Data Access Schemes sectoriels, latence de réponse inférieure à 500 ms (percentile 95), et disponibilité garantie à 99,5% — soit moins de 44 heures de downtime annuel autorisé.

Ces seuils sont analogues à ceux imposés par DSP3 pour les API bancaires, et créent les mêmes défis d'infrastructure pour les assureurs dont les systèmes legacy n'ont pas été conçus pour des contraintes de SLA temps réel.

#Gestion des consentements durables

Chaque institution doit maintenir un référentiel de consentements traçant pour chaque titulaire : la durée de validité du consentement (maximums fixés par le règlement selon la catégorie de données), le périmètre exact des données autorisées, l'identité du FISP destinataire, et la date de révocation éventuelle.

La révocation en temps réel est une obligation : un consentement révoqué par le titulaire doit couper l'accès du FISP dans un délai maximum de quelques secondes.

#Sandbox développeurs obligatoire

FIDA impose aux institutions couvertes de maintenir une sandbox de développement accessible aux FISP agréés ou en cours d'agrément, ouverte 3 mois avant le go-live des API de production. Cette sandbox doit contenir des jeux de données représentatifs (anonymisés) permettant aux développeurs de FISP de tester et valider leurs intégrations avant accès aux données réelles.

#Logging accès données

Chaque accès effectué par un FISP aux données d'un titulaire doit générer un event auditable : identifiant du FISP, périmètre des données accédées, timestamp, résultat de l'appel. Ce journal d'accès est conservé 5 ans minimum (aligné sur la prescription financière) et doit être transmissible à la CNIL ou à l'ACPR sur demande.

L'event-driven architecture avec Kafka est le pattern recommandé pour générer ces events de manière fiable et scalable.

#Certification annuelle auditeur agréé

FIDA impose une certification annuelle de conformité des API par un auditeur agréé par l'EIOPA ou l'ACPR selon le secteur. Cette certification couvre la qualité technique des API (SLA, format), la robustesse du système de consentements, et la complétude du journal d'accès. Le DORA Act crée des synergies avec cette obligation : les tests de résilience DORA et les audits FIDA peuvent être mutualisés pour réduire les coûts de conformité.

---

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Architecture d'une plateforme FIDA-ready

La mise en conformité FIDA nécessite une architecture en couches distinctes, chacune adressant une obligation réglementaire spécifique.

#API Gateway

Un API Gateway (Kong Enterprise, AWS API Gateway ou Apigee) centralise tous les appels entrants des FISP : authentification OAuth 2.0 FAPI 2.0, rate limiting par FISP et par périmètre de données, circuit breaker pour protéger les backends legacy, et transformation des formats de réponse vers le schéma FIDA normalisé.

Le cloud souverain français (OVHcloud SecNumCloud, Scaleway) est la cible naturelle pour héberger ces composants FIDA dans un contexte d'exigences RGPD et de données financières sensibles.

#Consent Management Service

Un service de gestion des consentements dédié (custom ou basé sur Mia-Platform Consent Manager) stocke et gère le cycle de vie complet des consentements : création avec périmètre granulaire, validation de cohérence (le FISP demande-t-il accès à des données qu'il est autorisé à consulter selon son agrément ?), expiration automatique, et révocation temps réel.

Ce service est la pièce critique de l'architecture — sa défaillance expose l'institution à des accès non autorisés ou à l'impossibilité de révoquer.

#Data Normalization Layer

Les données financières proviennent de systèmes hétérogènes : mainframe assurance, base Oracle investissement, SGBD propriétaire épargne. Un layer de normalisation mappe ces schémas hétérogènes vers le format JSON FIDA standardisé défini par les Customer Data Access Schemes.

Ce layer est critique pour l'indépendance du backend FIDA vis-à-vis des systèmes legacy — il peut être implémenté comme un ensemble de microservices consommant les API internes existantes. La migration monolith vers microservices peut s'avérer nécessaire si les systèmes legacy ne disposent pas d'API internes consommables.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Event Streaming

Kafka (Confluent Cloud ou MSK) assure la traçabilité immuable de chaque accès aux données : chaque appel FISP génère un event publié sur un topic Kafka dédié, consommé par le service de logging réglementaire. L'architecture event-driven garantit que le journal d'accès est complet même en cas de défaillance partielle d'un composant — une exigence d'audit critique.

#Developer Portal

Un portail développeurs (Stoplight, Redocly ou custom) publie la documentation OpenAPI 3.0 des API FIDA exposées, l'accès à la sandbox, les guides d'intégration OAuth 2.0 FAPI 2.0, et les spécifications des schémas de données. Ce portail est l'interface publique vis-à-vis des FISP souhaitant s'intégrer et doit être maintenu avec le même niveau de soin qu'une API commerciale.

#SIEM pour monitoring accès suspects

Un SIEM (Security Information and Event Management — Splunk, Elastic SIEM, Datadog Security) monitore en temps réel les patterns d'accès aux API FIDA pour détecter les comportements anormaux : volume d'appels inhabituel d'un FISP, accès à des périmètres non consentis, tentatives de replay d'anciens tokens.

La conformité NIS2 impose par ailleurs un SIEM pour les entités essentielles du secteur financier — les deux obligations peuvent partager la même infrastructure.

---

#RGPD × FIDA : quid des données sensibles financières

L'articulation entre FIDA et le RGPD soulève des questions pratiques que les DPO des institutions financières doivent traiter avant le go-live.

#Les données financières ne sont pas des données sensibles au sens strict de l'article 9 RGPD

Les données financières (soldes, contrats, transactions) n'appartiennent pas aux catégories spéciales de l'article 9 du RGPD (santé, origines raciales, opinions politiques, etc.). Elles bénéficient néanmoins d'une protection renforcée par convergence réglementaire : le secret bancaire (article L. 511-33 du Code monétaire et financier), le secret des affaires pour les données d'investissement, et les dispositions d'ePrivacy pour les communications électroniques.

Le DPO doit valider chaque nouveau cas d'usage FISP en amont : la base légale de traitement (consentement FIDA vs intérêt légitime du FISP) doit être documentée et cohérente avec les mentions d'information transmises au titulaire.

#Durée de conservation des logs

Les logs de consentement FIDA (création, périmètre, révocation) doivent être conservés 5 ans minimum pour couvrir le délai de prescription financière applicable en France. Cette durée de conservation doit être reflétée dans le registre des traitements RGPD de l'institution et dans les politiques de rétention du SIEM.

#Transferts hors UE

FIDA interdit explicitement les transferts de données financières hors UE sans clause contractuelle type (CCT) validée par l'autorité compétente. Un FISP agréé dans l'UE ne peut pas transmettre les données financières collectées à un prestataire technique établi aux États-Unis (ex : AWS us-east-1) sans CCT ou sans mécanisme de transfert équivalent reconnu par la Commission européenne.

L'AI Act impose des contraintes similaires sur les données d'entraînement des modèles IA — les architectures FIDA doivent anticiper cette convergence.

---

#Exemple de situation : une wealth tech et l'accès aux contrats d'assurance-vie

Cet exemple est une situation type, construite pour illustrer l'intérêt de FIDA. Ce n'est pas un client réel et il ne contient aucun résultat chiffré.

#Le problème

Une wealth tech propose un agrégateur patrimonial destiné aux particuliers patrimoniaux. La plateforme agrège les comptes bancaires (via DSP2 et un agrégateur comme Tink) et les portefeuilles d'actions (via API de brokers), mais ne peut pas accéder aux contrats d'assurance-vie, qui pèsent lourd dans le patrimoine de ses utilisateurs. Cette lacune dégrade la pertinence des conseils d'allocation : la « vue patrimoniale complète » est en réalité partielle.

#La solution

La plateforme intègre l'accès aux données d'assurance-vie en phase pilote via un partenaire FISP pré-agréé. L'architecture comprend un consent management service (durée de consentement configurable par assureur), un data normalization layer qui mappe les schémas propriétaires des assureurs vers un schéma interne unifié, et un developer portal qui expose les API internes aux équipes produit.

L'insurtech IA peut enrichir les données brutes avec des catégorisations intelligentes des garanties.

#Ce qu'on mesure pendant le pilote

La complétude de la vue patrimoniale (part du patrimoine réel déclaré couverte par l'agrégation), la satisfaction des utilisateurs sur le module d'agrégation et l'évolution de l'encours confié à la plateforme. Ces indicateurs se relèvent avant et après l'intégration, sur un groupe pilote.

Ce cas illustre pourquoi FIDA n'est pas seulement une contrainte réglementaire pour les assureurs : c'est un levier de croissance pour les fintechs capables de l'exploiter rapidement.

---

#Feuille de route FIDA pour une DSI

La fenêtre de mise en conformité est courte. Voici la séquence recommandée pour une institution financière.

#2026 : inventaire et gap analysis

La première étape est un inventaire exhaustif des données financières détenues par l'institution selon la taxonomie FIDA : quels types de données, dans quels systèmes, avec quels formats, accessibles via quelles API internes. La gap analysis identifie les écarts entre l'état actuel et les exigences FIDA : API manquantes, formats non standardisés, absence de gestion de consentements granulaires, logging insuffisant. Cette phase dépend de la complexité du SI.

Points d'attention spécifiques pour les assureurs : les systèmes de gestion de contrats (SGC) sont souvent des applications legacy (COBOL, Delphi, AS/400) sans API exposée. La migration COBOL vers Java moderne assistée par IA peut accélérer la création des API intermédiaires nécessaires sans refonte totale.

Budget : sur devis, selon la complexité du SI et le périmètre d'actifs couvert.

#Mi-2027 : API assurance FIDA-compliant et sandbox

L'échéance assurance (visée mi-2027) est la priorité absolue. Les chantiers parallèles : développement des API de données assurance selon le schéma normalisé du Customer Data Access Scheme assurance français, déploiement du consent management service, ouverture de la sandbox développeurs 3 mois avant go-live (soit environ trois mois plus tôt), et audit de certification par un auditeur agréé ACPR.

L'OCR IA peut accélérer la numérisation des contrats papier historiques qui n'ont pas encore de représentation numérique structurée dans le SI — un prérequis pour exposer des données contractuelles complètes via l'API FIDA.

Budget : sur devis. Une plateforme B2B complexe démarre à 50 000 € HT ; les assureurs avec un SI très legacy ou une gamme de contrats très étendue demandent un chantier nettement plus lourd.

#Fin-2028 : couverture complète épargne, investissement et crédit

La seconde vague de conformité couvre les API épargne (PEA, PER, assurance-vie fonds euros/UC avec performance temps réel), investissement (portefeuilles, performances, frais) et crédit long terme. Cette phase peut être préparée dès 2027 en réutilisant l'infrastructure (API Gateway, consent management, Kafka) déployée pour l'assurance.

Budget : sur devis, selon la complexité du SI existant et le périmètre de produits couverts. La priorisation claire : API assurance d'abord (deadline 2027, impact réglementaire immédiat), épargne et investissement ensuite (deadline 2028, fenêtre plus large).

Nehos accompagne les DSI dans toute cette séquence : de l'inventaire initial à la certification finale, en passant par la conception de l'architecture et l'intégration avec les systèmes legacy. Contactez nos services d'intégration API pour un premier échange sur votre feuille de route FIDA.

Photos : MART PRODUCTION sur Pexels.