L'essentiel sur la préparation FIDA Open Finance pour les banques
FIDA (Financial Data Access Regulation) est le règlement européen qui fait basculer l'Union européenne de l'open banking restreint aux comptes de paiement vers l'open finance intégral. Périmètre étendu : épargne réglementée et non réglementée, crédit conso et immobilier, assurance vie et non-vie, retraite supplémentaire, investissement et portefeuilles titres. Publication finale Q3 2026, premier paquet d'applications 2027, généralisation 2028.
FIDA crée une nouvelle catégorie d'acteur : le FISP — Financial Information Service Provider. Statut soumis à enregistrement ACPR pour la France, avec exigences de capital, gouvernance, dispositif anti-blanchiment AMLD6, sécurité IT conforme DORA. Les fintechs AISP/PISP déjà agréées doivent étendre leur statut, les banques peuvent créer une filiale FISP pour monétiser leur position.
L'articulation FIDA / DSP3 / DORA / AMLD6 / AI Act constitue le cœur du chantier conformité. DSP3 modernise les paiements, FIDA ouvre les données, DORA sécurise la résilience IT, AMLD6 ferme l'angle blanchiment, AI Act encadre les algorithmes utilisateur. Un comité conformité numérique unique, un registre intégré, une plateforme API multi-régimes sont impératifs.
Méthode Nehos Open Finance Ready™ en 5 phases sur 16 semaines, validée chez une banque mutualiste régionale 2,8 Md€ d'encours. Phases : audit data accessibility, plateforme API FAPI 2.0, consentement RGPD-FIDA, enregistrement FISP ACPR, monétisation. Voir [service Open Banking DSP3 Nehos](/services/open-banking-dsp3).
Guide FIDA Open Finance 2026 : la préparation des banques en 5 phases (méthode Nehos)
Le règlement européen FIDA — Financial Data Access Regulation — entre dans sa dernière ligne droite. Publication finale attendue au troisième trimestre 2026, application progressive 2027-2028. FIDA prolonge la logique de DSP2 sur l'ensemble des produits financiers : épargne, crédit, assurance vie et non-vie, retraite, investissement. Pour les banques, les assureurs et les sociétés de gestion européennes, c'est un basculement structurel : exposer des APIs standardisées, encadrer le consentement utilisateur, articuler la conformité avec DSP3, DORA, AMLD6 et AI Act. Ce guide pilier décrit en huit chapitres le périmètre exact du règlement, les acteurs concernés, la nouvelle catégorie de FISP (Financial Information Service Provider), la Méthode Nehos Open Finance Ready™ en cinq phases, le stack technique cible, le cas concret d'une banque mutualiste préparée en seize semaines, et les opportunités business à saisir. Rédigé par Foued Cherni (CEO Nehos, Compliance Officer chapeau) et Houssem Baklouti (Lead Dev PHP/Vue.js/IA, expertise stack open banking DSP2 et FAPI). Mai 2026.
Adapté à toute taille de structure
#Chapitre 1 — FIDA : règlement UE publication Q3 2026 et calendrier
FIDA — Financial Data Access Regulation, parfois transcrit FIDAR ou FIDA-R dans certains documents techniques — est la proposition de règlement européen 2023/0205 présentée par la Commission européenne le 28 juin 2023, dans le paquet « Financial Data Access and Payments » qui inclut également la révision des services de paiement avec DSP3 et le règlement PSR (Payment Services Regulation). Trois textes simultanés, une logique unique : refonder le cadre numérique financier européen pour la décennie 2025-2035.
#État d'avancement et calendrier réaliste
Après dix-huit mois de négociation en trilogue (Conseil, Parlement, Commission) entre l'automne 2024 et le début 2026, le texte FIDA est entré en phase de finalisation. Les principaux points de friction politique — périmètre exact des produits couverts, statut des assureurs non-vie, modalités de tarification des API premium, compensation des coûts d'investissement pour les banques mutualistes — ont fait l'objet d'arbitrages successifs au cours du premier semestre 2026. Publication finale attendue au troisième trimestre 2026 au Journal officiel de l'Union européenne. Le règlement entrera en vigueur 20 jours après publication. Premier paquet d'application : 18 mois après entrée en vigueur, soit T1 2028 dans le scénario médian. Second paquet (retraite, assurance non-vie complète) : 30 mois après entrée en vigueur, soit T1 2029.
Cette progressivité est un signal politique : la Commission européenne a entendu les inquiétudes des grandes banques universelles et des fédérations d'assureurs sur la charge technique. Mais l'horizon n'est pas négociable. En mai 2026, à dix-huit à vingt-quatre mois du basculement opérationnel pour les premiers produits couverts, les chantiers infrastructure doivent être amorcés.
#Trois objectifs politiques structurants
Le règlement FIDA poursuit trois objectifs explicitement énoncés dans les considérants. Premier : permettre aux consommateurs et aux entreprises européennes de tirer pleinement parti de leurs données financières, pas seulement de leurs comptes de paiement. Deuxième : créer un marché européen unifié des données financières, comparable à ce que la directive DSP2 a fait pour les paiements depuis 2018, mais étendu à tous les produits. Troisième : maintenir la compétitivité de l'industrie financière européenne face aux écosystèmes nord-américain (Plaid, Yodlee, MX) et asiatique (Alipay, WeChat Pay, Paytm) qui ont structuré leurs propres approches data-driven.
#Articulation avec DSP3 et le paquet PSR-FIDA
DSP3 et FIDA sont conçus comme deux faces d'une même architecture. DSP3 modernise les services de paiement (renforcement de l'API banking, encadrement contraint de la concurrence avec les acteurs non-bancaires, généralisation de l'authentification forte SCA). FIDA ouvre la couche supérieure : les données patrimoniales et de produits financiers. Concrètement, une fintech qui aujourd'hui se contente d'agréger des comptes via DSP2 pourra demain — sous statut FISP — agréger l'ensemble du patrimoine financier d'un client. Les deux régimes partagent un socle commun de gouvernance des consentements, de sécurité API et de supervision ACPR.
Pour aller plus loin sur la définition réglementaire pure, voir FIDA Financial Data Access Regulation dans le glossaire et DSP3 Directive Services de Paiement 3.
#Chapitre 2 — Périmètre élargi : du compte de paiement à l'open finance complet
La rupture avec DSP2 est nette. DSP2 ouvre l'accès aux comptes de paiement, point. Tout le reste — épargne, crédit, assurance, retraite, investissement — reste hors champ. FIDA opère un basculement de périmètre d'une ampleur sans précédent dans le cadre réglementaire européen.
#Cinq catégories de données financières ouvertes
Le règlement organise le périmètre en cinq grandes catégories, codifiées par l'annexe technique I de la proposition 2023/0205. Catégorie 1 — Épargne : livrets réglementés (Livret A, LEP, LDDS en France, Sparbuch en Allemagne, Spaarrekening aux Pays-Bas), comptes à terme, plans d'épargne logement, PEL, CEL, et leurs équivalents européens. Donnée ouverte : solde, historique des mouvements, conditions de rémunération, échéances. Catégorie 2 — Crédit : crédit conso, crédit immobilier, crédit revolving, crédits-bails, micro-crédits. Données ouvertes : capital restant dû, échéancier, taux, sûretés, historique des incidents. Catégorie 3 — Assurance : contrats d'assurance vie (en euros, en unités de compte), assurance non-vie (auto, habitation, santé complémentaire, prévoyance, protection juridique, multirisques), assurance emprunteur. Données ouvertes : capital, primes versées, valeur de rachat, bénéficiaires, garanties souscrites. Catégorie 4 — Retraite : Plans d'épargne retraite (PER en France, Riester en Allemagne, NPS au Royaume-Uni hors UE), retraite supplémentaire d'entreprise, fonds de pension professionnels. Données ouvertes : encours, allocation, droits acquis, projections. Catégorie 5 — Investissement : portefeuilles titres, comptes-titres, PEA, fonds d'investissement, OPCVM, FIA, produits structurés, crypto-actifs sous MiCA. Données ouvertes : positions, valorisations, opérations, fiscalité.
Les données de santé associées à l'assurance santé restent sous régime spécifique (RGPD article 9, données sensibles) avec consentement renforcé. Le règlement FIDA ne contourne pas la protection des données sensibles.
#Granularité du consentement : par produit, par durée, révocable
Le consentement utilisateur FIDA est conçu pour être granulaire. L'utilisateur n'autorise pas l'accès à « ses données financières » en bloc. Il autorise une fintech FISP à accéder à : tel produit (par exemple uniquement le contrat d'assurance vie n° X), pour telle durée (3, 6, 12, 24 mois), pour telle finalité (par exemple comparaison avec d'autres contrats, ou agrégation patrimoniale dans un tableau de bord, ou conseil patrimonial automatisé). La révocation est de droit, en un clic, avec effet immédiat. Les exigences techniques sont définies par renvoi au cadre RGPD article 7 enrichi de précisions sectorielles spécifiques au règlement FIDA.
#Sortie du périmètre : crypto pur, immobilier, données externes
Trois zones restent hors périmètre FIDA dans le texte de juin 2026. Premièrement, les portefeuilles crypto non régulés (cold wallets hors plateformes MiCA) : pas d'obligation de partage. Deuxièmement, les actifs immobiliers physiques détenus en direct : pas d'API patrimoniale immobilière imposée par FIDA (cela relèvera potentiellement d'un texte ultérieur). Troisièmement, les données externes au système financier (revenus, données sociales, foncier cadastral) : hors champ FIDA, restent dans les régimes nationaux sectoriels (DGFiP en France, équivalents nationaux).
Pour le détail sur l'écosystème open banking existant et son extension, voir le service Open Banking DSP3 Nehos et le secteur Banque-Assurance-Finance.
#Chapitre 3 — Acteurs concernés : banques, assureurs, FISP et nouvelle topologie
#Côté offre — Les data holders : banques, assureurs, sociétés de gestion, retraite
Le règlement FIDA crée la catégorie générique de « data holder » : tout établissement qui détient des données financières des cinq catégories listées au chapitre 2. En pratique, cinq familles d'acteurs sont concernées comme data holders. Banques universelles et coopératives : BNP Paribas, Crédit Agricole, BPCE, Société Générale, La Banque Postale, Crédit Mutuel, et leurs équivalents européens (Deutsche Bank, ING, Santander, UniCredit). Concernées sur épargne, crédit, parfois assurance via filiale et investissement. Néobanques : Revolut, N26, Lydia, Qonto, Memo Bank, et équivalents. Concernées sur leurs produits propres. Assureurs vie et non-vie : AXA, Allianz, CNP Assurances, MAIF, Macif, Groupama, Generali, et leurs équivalents européens. Concernées sur l'intégralité des contrats. Sociétés de gestion d'actifs : Amundi, Natixis IM, BNPP AM, BlackRock Europe, DWS, et équivalents. Concernées sur les portefeuilles et OPCVM/FIA distribués. Caisses de retraite et fonds de pension : AGIRC-ARRCO, MSA, RAFP, fonds de pension professionnels nationaux. Concernées sur les droits et encours retraite supplémentaire.
Le règlement précise un seuil de minimis : les très petites entités financières (en deçà de seuils d'effectif et de bilan définis par RTS à publier 2027) bénéficient d'aménagements de calendrier et d'allègements techniques. Pour la grande majorité des établissements régulés ACPR ou équivalents UE, le périmètre s'applique pleinement.
#Côté demande — Les FISP : nouvelle catégorie d'acteur régulé
FIDA crée une nouvelle catégorie d'acteur régulé : le FISP — Financial Information Service Provider. C'est l'équivalent fonctionnel élargi du statut AISP de DSP2, mais étendu à tous les produits FIDA. Le FISP est l'entité juridique habilitée à demander, sous mandat consenti par l'utilisateur, l'accès aux données financières des data holders.
Le statut FISP est soumis à enregistrement ACPR (ou autorité nationale compétente équivalente) avec un cahier des charges précis : capital initial minimal (estimé à 50 à 2000 k€ selon profil, à confirmer par RTS), gouvernance documentée, dispositif anti-blanchiment conforme AMLD6, sécurité IT conforme DORA, plan d'activité décrivant les services offerts, gestion des plaintes, assurance responsabilité civile professionnelle.
Qui peut devenir FISP ? Quatre profils typiques. (a) Les fintechs AISP/PISP déjà régulées DSP2 qui étendent leur statut : voie la plus directe, leur dispositif existant absorbe la majeure partie du cahier des charges FISP. (b) Les banques qui créent une filiale FISP pour monétiser leur position en offrant des services agrégés à leurs propres clients et à des tiers : voie stratégique pour les banques universelles. (c) Les assureurs qui créent une filiale FISP pour proposer un conseil patrimonial multi-banques en plus de leurs contrats. (d) Les nouveaux entrants : néo-courtiers, super-apps fintech, comparateurs intelligents, qui démarrent directement sous statut FISP.
#Topologie post-FIDA : data holder, FISP, schemes, infrastructure providers
L'écosystème FIDA installe une topologie à quatre couches qui structurera le marché européen 2028. Couche 1 — Data holders : banques, assureurs, sociétés de gestion, retraite, comme décrit ci-dessus. Ils exposent les API standardisées. Couche 2 — Schemes : organisations sectorielles qui définissent les schémas de données techniques par produit (Berlin Group pour les paiements et l'épargne, en cours de définition pour assurance via Insurance Europe, pour retraite via PensionsEurope). Couche 3 — FISP : fintechs régulées qui agrègent et offrent des services à valeur ajoutée. Couche 4 — Infrastructure providers : Bridge by Powens, Tink (Visa), Yapily, Salt Edge, Truelayer, qui fournissent la couche technique de connexion aux data holders pour les FISP qui ne veulent pas construire en interne.
La Méthode Nehos s'inscrit dans la couche 1 (préparation data holders) et dans la couche 3 (préparation FISP), avec une expertise particulière sur l'articulation des deux côtés du marché. Voir le service Open Banking DSP3 Nehos.
#Chapitre 4 — Articulation FIDA + DSP3 + DORA + AMLD6 + AI Act
FIDA n'arrive pas dans un vide réglementaire. La conformité numérique d'une banque ou d'un assureur européen en 2027-2028 sera structurée par cinq régimes principaux qu'il faut articuler de manière cohérente.
#FIDA + DSP3 — Le paquet open finance / open banking unifié
DSP3 et FIDA partagent un socle commun. Les exigences de sécurité API, d'authentification forte de l'utilisateur, de gouvernance des consentements, de supervision ACPR sont alignées par construction. En pratique, une banque qui s'est mise en conformité DSP2 correctement en 2018-2020 a déjà 40 à 60 % du chantier FIDA technique réalisé. Le supplément FIDA porte sur l'élargissement du périmètre produits, la granularité des consentements, et l'ouverture vers de nouvelles catégories de tiers.
#FIDA + DORA — Sécurité IT et résilience opérationnelle
DORA (Règlement UE 2022/2554) est en application depuis le 17 janvier 2025. C'est le socle de résilience opérationnelle numérique pour le secteur financier. Toute API FIDA est un système IT critique au sens DORA. Conséquences pratiques : les API FIDA doivent figurer dans la cartographie des fonctions critiques de l'établissement, leurs incidents IT déclenchent les obligations de notification ACPR 24h/72h/1 mois, les fournisseurs IT supportant la plateforme API (cloud, infrastructure provider, partenaire FISP) doivent figurer au registre Article 28 DORA avec clauses contractuelles standardisées EBA conformes à l'article 30. Voir guide DORA fintech checklist conformité et Article 28 DORA registre tiers critiques.
#FIDA + AMLD6 — Anti-blanchiment et KYC renforcé
Le dispositif anti-blanchiment européen a été refondu par le paquet AML 2024 (règlement AMLR, directive AMLD6, autorité européenne AMLA). Les FISP sont assujettis à AMLD6 dès leur enregistrement. Conséquences pratiques : KYC renforcé des utilisateurs en amont de tout consentement à durée prolongée, surveillance des opérations atypiques détectées via les données agrégées, déclaration de soupçon TRACFIN ou équivalent national, formation des collaborateurs aux typologies blanchiment, désignation d'un responsable conformité AML. Pour les fintechs AISP déjà conformes AMLD5/AMLD6, l'extension FISP capitalise sur l'existant. Voir AMLD6 sixième directive anti-blanchiment.
#FIDA + AI Act — Algorithmes utilisateur et systèmes haut risque
De nombreux services FISP s'appuieront sur des algorithmes d'IA : scoring patrimonial automatisé, recommandation d'allocation d'actifs, comparaison intelligente d'offres, détection d'opportunités fiscales. Selon la finalité, ces algorithmes peuvent relever de l'AI Act. Cas typique : un scoring de crédit alternatif basé sur des données agrégées FIDA est un système IA haut risque au sens de l'annexe III AI Act, déclenchant les obligations de l'article 9 (analyse des risques, données d'entraînement de qualité, supervision humaine, journalisation, transparence). Articulation à anticiper dès la conception des services FIDA. Voir Méthode AI Act Compliance Nehos™ et guide AI Act conformité ETI checklist complète.
#Comité conformité numérique unique — Indispensable
Faire vivre cinq régimes en silo est impraticable. Notre recommandation systématique en mission : un comité conformité numérique unique mensuel, transversal, qui couvre FIDA, DSP3, DORA, AMLD6 et AI Act simultanément. Participants : Compliance Officer DORA, DPO RGPD, CAIO AI Act, responsable AML, RSSI, DSI, juridique, représentant board. Un registre intégré multi-régimes, des KPI partagés, une revue mensuelle. C'est la condition d'efficacité opérationnelle réelle. Voir service Conformité Nehos 7 standards.
#Chapitre 5 — Méthode Nehos Open Finance Ready™ en 5 phases
La Méthode Nehos Open Finance Ready™ structure la préparation FIDA d'une banque ou d'un assureur en cinq phases enchaînables sur 12 à 20 semaines selon le niveau de départ et la taille de l'établissement.
#Phase 1 — Audit data accessibility et cartographie produits (3 semaines)
Objectif : connaître son point de départ. Livrables typiques. Cartographie exhaustive des produits financiers concernés par FIDA (épargne, crédit, assurance, retraite, investissement) avec recensement par référence produit, encours, nombre de clients, système d'information de référence. Évaluation de la maturité des bases de données par produit : qualité des données, fraîcheur, granularité, identifiants client unifiés ou silotés. Identification des schémas de données par produit (alignement avec les standards Berlin Group, Insurance Europe, PensionsEurope quand disponibles). Qualification de la dette technique : applicatifs legacy, dépendances mainframe (DB2, COBOL), data lake existant, ETL en place. Rapport de scoring data accessibility 0-100 avec roadmap de remédiation priorisée.
#Phase 2 — Plateforme API Open Finance et standards (4 semaines)
Objectif : concevoir l'architecture cible. Livrables. Architecture API OpenAPI 3.1 documentée, conforme FAPI 2.0 (Financial-grade API Security Profile 2.0 de la OpenID Foundation) et Berlin Group NextGenPSD2 étendu aux nouveaux périmètres FIDA. Décision build vs partnership : construction d'une plateforme API interne ou partenariat avec un infrastructure provider (Bridge by Powens, Tink, Yapily, Salt Edge) — décision structurante selon taille, ressources techniques internes, ambition concurrentielle. Gouvernance des schémas (data model, versioning, contrats de service par produit, SLA). Stratégie de monétisation des API premium prévues par le règlement FIDA. Plan de mise en œuvre 12-24 mois.
#Phase 3 — Consentement utilisateur RGPD-FIDA et CMP (3 semaines)
Objectif : déployer la Consent Management Platform. Livrables. CMP conforme RGPD article 7 et exigences FIDA spécifiques : parcours granulaires par produit, par durée explicite, par finalité, retrait en un clic avec effet immédiat. Journalisation immuable des consentements (architecture append-only, horodatage qualifié eIDAS, signature électronique conforme). Dashboard self-care utilisateur permettant de visualiser tous les consentements donnés, à qui, pour quoi, pour combien de temps, et de les révoquer. Politique de durée maximale et de renouvellement explicite. Intégration parcours mobile + web. Audit RGPD croisé.
#Phase 4 — Enregistrement FISP ACPR (3 semaines, conditionnel)
Objectif (si l'établissement crée une offre FISP propre) : préparer le dossier d'enregistrement ACPR. Livrables. Statuts de l'entité FISP (filiale dédiée recommandée). Capital initial conforme exigences RTS FIDA. Gouvernance documentée : dirigeants effectifs honorabilité, organisation des fonctions clés. Dispositif AML/CFT conforme AMLD6 : politique, procédures, outillage, équipe dédiée. Sécurité IT conforme DORA : politique résilience, registre Article 28, runbook incidents, programme tests. Plan d'activité détaillé : services offerts, modèle économique, projections financières 3 ans. Dossier complet déposé à l'ACPR via guichet OnePass. Suivi instruction (délai légal indicatif 90 jours, à confirmer RTS).
#Phase 5 — Monétisation et go-to-market Open Finance (3 semaines)
Objectif : structurer le modèle économique et le lancement commercial. Livrables. Modèle de tarification API : revenue share (par exemple part du chiffre d'affaires du FISP), abonnement mensuel par catégorie d'usage, pay-per-call pour les usages haute fréquence. Catalogue de schemes premium réglementés par FIDA. Packaging d'offres pour les directions métier : agrégateur patrimonial B2C, conseil patrimonial multi-banques pour la gestion de fortune, super-app fintech pour les segments jeunes, API B2B pour les assureurs partenaires. Plan de lancement commercial : annonce client, communication réglementaire ACPR, formation des conseillers, mesure des KPI. Roadmap d'enrichissement 12-24 mois.
Durée totale typique : 12 à 16 semaines pour une banque ou un assureur de taille moyenne, 18 à 20 semaines pour une banque universelle multi-marchés. Budget Nehos forfait fixe : entre 165 et 5120 k€ HT selon scope. Voir service Open Banking DSP3 Nehos.
→ Vous évaluez vos options ? Utilisez notre estimateur de budget en ligne pour obtenir une fourchette en 2 minutes, ou consultez nos tarifs détaillés.
#Chapitre 6 — Stack technique : OpenAPI 3.1, FAPI 2.0, Berlin Group, CMP
#Spécification API : OpenAPI 3.1 documentée
Le standard de spécification d'API qui fait consensus dans l'écosystème FIDA est OpenAPI 3.1 (anciennement Swagger). Documentation machine-readable, génération automatique de clients, validation des schémas, intégration native avec les portails développeurs et les outils de test. Chaque endpoint FIDA — typiquement organisé par catégorie de produit — est décrit avec son schéma de requête, son schéma de réponse, ses paramètres d'authentification, ses codes de retour, ses contraintes de performance, ses SLA. Nous recommandons systématiquement la publication d'un portail développeur public exposant la documentation OpenAPI 3.1 dès la phase de bêta, comme le pratique Bridge by Powens ou Tink Bridge depuis 2023.
#Sécurité : OAuth 2.0 + FAPI 2.0
La sécurisation des API FIDA repose sur OAuth 2.0 enrichi par le profil FAPI 2.0 — Financial-grade API Security Profile 2.0 — publié par la OpenID Foundation. FAPI 2.0 durcit OAuth 2.0 sur plusieurs dimensions : authentification mutuelle TLS (mTLS) ou DPoP (Demonstration of Proof-of-Possession) pour lier les tokens au client, signatures JWT obligatoires sur les requêtes critiques, durée des tokens limitée, refresh tokens à usage unique, exigences spécifiques de chiffrement asymétrique. FAPI 2.0 est aujourd'hui adopté par la majorité des banques européennes ayant déployé une API DSP2 mature. Pour FIDA, FAPI 2.0 est de facto le standard cible — sa pré-adoption est un signal de maturité auprès des FISP partenaires.
#Schémas de données : Berlin Group NextGenPSD2 étendu
Le Berlin Group est l'initiative paneuropéenne qui a défini les schémas de données XS2A pour DSP2. Plus de 35 banques européennes y participent depuis 2016, dont les grandes banques françaises, allemandes, italiennes, espagnoles, néerlandaises. Pour FIDA, le Berlin Group travaille depuis 2024 à l'extension du standard NextGenPSD2 aux nouveaux périmètres : épargne, crédit conso, crédit immobilier. Pour les périmètres assurance et retraite, des schémas spécifiques sont en cours d'élaboration par Insurance Europe et PensionsEurope respectivement. Notre recommandation : ancrer l'architecture API de la banque sur Berlin Group pour les produits bancaires (épargne, crédit) et anticiper les schémas Insurance Europe / PensionsEurope pour les filiales assurance et retraite quand applicables.
#Consent Management Platform : RGPD article 7 + exigences FIDA
La CMP est le composant le plus visible côté utilisateur final. Exigences cumulées : RGPD article 7 (consentement libre, spécifique, éclairé, univoque), exigences FIDA spécifiques (granularité par produit, durée explicite, finalité explicite, révocation un clic). Composants techniques. (a) Interface utilisateur de consentement web et mobile, design accessible WCAG 2.2 AA. (b) Backend de gestion des consentements : stockage append-only, identifiants uniques par consentement, métadonnées complètes (qui, quand, quoi, pour quelle finalité, pour quelle durée). (c) Journalisation immuable conforme : hash chain, horodatage qualifié eIDAS (Universign, DocuSign, Yousign), signature électronique conforme. (d) Dashboard self-care utilisateur de gestion des consentements actifs. (e) API d'interrogation pour les FISP partenaires et le régulateur. (f) Intégration avec le SI de production : propagation des révocations vers tous les systèmes consommateurs en moins de 5 minutes (SLA cible).
#Infrastructure providers : choix typiques sur le marché européen
Pour les banques qui choisissent un partenariat plutôt qu'une construction interne, le marché européen propose plusieurs acteurs matures. Bridge by Powens (France) : leader français AISP/PISP, API agrégation et initiation, en cours de positionnement FISP-ready. Tink (Suède, racheté Visa 2022) : leader nordique, présence européenne large. Yapily (Royaume-Uni mais juridiction UE via Irlande) : positionnement infrastructure pure-play. Salt Edge (Canada/Europe) : positionnement scalable multi-juridictions. Truelayer (Royaume-Uni) : positionnement paiement open banking. Le choix dépend de la couverture géographique cible, du niveau d'intégration souhaité, du modèle économique préféré et de l'alignement DORA (registre Article 28 du partenaire, certifications, juridiction des données).
Pour le détail de notre approche stack et le service associé, voir le service Open Banking DSP3 Nehos et le service Agents IA conformes par design qui s'articule avec les services FIDA à valeur ajoutée.
#Chapitre 7 — Cas concret : banque mutualiste préparée FIDA en 16 semaines
Illustration tirée d'une mission Nehos en cours T1-T2 2026 (NDA, anonymisation).
#Contexte client
Banque mutualiste régionale française. 2,8 milliards d'euros d'encours total clients. 380 000 clients particuliers, 28 000 clients professionnels. 1 200 collaborateurs, dont 850 conseillers en agences. Réseau de 95 agences sur 4 départements. Produits couverts par FIDA détenus : comptes courants et comptes d'épargne, prêts conso et immobiliers, assurance vie en partenariat avec une mutuelle régionale, PER, comptes-titres et PEA en partenariat avec une société de gestion régionale. Stack technique : core banking sous SAB ATX, surcouche applicative web et mobile en maison, API DSP2 déployée 2019 conforme Berlin Group XS2A. Compliance Officer DORA en place depuis 2024, RSSI à temps plein, pas encore de fonction Open Banking ni de CDO dédié.
#Diagnostic Phase 1 — semaines 1 à 3
Notre audit data accessibility en semaine 0 a estimé la maturité FIDA initiale à 31 %. Détail : couverture comptes de paiement et épargne 75 % (héritage DSP2 robuste), couverture crédit 35 % (données existantes mais schémas non alignés Berlin Group étendu), couverture assurance vie 15 % (silo applicatif chez le partenaire mutualiste, identifiants client non unifiés), couverture PER 20 % (silo applicatif similaire), couverture titres 25 % (partenaire société de gestion régionale, intégration limitée). Recommandation : démarrage prioritaire par épargne et crédit, traitement assurance et titres dans un second paquet avec les partenaires métier.
#Phase 2 — Plateforme API — semaines 4 à 7
Quatre semaines pour concevoir l'architecture cible. Livrables. Architecture API OpenAPI 3.1 + FAPI 2.0 documentée. Décision stratégique tranchée : construction interne du portail API pour les produits cœur (épargne, crédit), partenariat Bridge by Powens pour les produits en partenariat (assurance, titres) afin de mutualiser l'intégration avec les fournisseurs métier sans dépendance technique propre. Plan de mise en œuvre 14 mois piloté par un Comité Open Finance bi-mensuel. Effort Nehos : 22 jours-homme cumulés.
#Phase 3 — Consentement et CMP — semaines 8 à 10
Trois semaines pour déployer la Consent Management Platform. Livrables. CMP buildée sur surcouche maison, intégrée au tunnel d'authentification existant (MFA SMS + biométrie mobile). Journalisation immuable hash chain avec horodatage qualifié Yousign. Dashboard self-care utilisateur intégré dans l'espace client web et mobile. Audit RGPD croisé par le DPO interne et le cabinet d'avocats partenaire de la banque. Effort Nehos : 15 jours-homme.
#Phase 4 — Préparation FISP ACPR (volet stratégique) — semaines 11 à 13
Trois semaines pour préparer la création d'une filiale FISP. Choix stratégique du board : créer une filiale FISP « Patrimoine » pour proposer un service d'agrégation et de conseil patrimonial multi-banques à destination de la clientèle haut de gamme (1,2 milliards d'euros d'encours sur 18 000 clients). Livrables. Statuts filiale, plan de capital 3200 k€, gouvernance documentée, dispositif AML mutualisé avec la banque mère, sécurité IT pivotée sur le SI de la banque (avantage architectural). Dossier d'enregistrement ACPR pré-rempli à 80 %, dépôt prévu T4 2026 anticipant publication finale FIDA. Effort Nehos : 18 jours-homme.
#Phase 5 — Monétisation et go-to-market — semaines 14 à 16
Trois semaines pour structurer le modèle économique. Livrables. Pricing API B2B pour les FISP tiers : abonnement mensuel selon volume + revenue share au-delà du seuil. Tarification interne neutre vers la filiale FISP Patrimoine. Packaging offre Patrimoine : tableau de bord client, conseil patrimonial assisté par IA conforme AI Act, alertes opportunités fiscales, comparateur d'allocation d'actifs. Plan de lancement commercial : pilote 200 clients premium en T3 2027, généralisation 18 000 clients premium T1 2028, ouverture clientèle plus large T3 2028. Effort Nehos : 12 jours-homme.
#Résultat à 16 semaines
Maturité FIDA cible passée de 31 % à 78 %. Architecture API documentée et adoptée. CMP en production. Dossier FISP ACPR à 80 % prêt. Filiale FISP « Patrimoine » incorporée en T3 2026, dépôt ACPR T4 2026, agrément attendu T1 2027 pour pilote T3 2027. Budget total mission Nehos : 4288 k€ HT forfait fixe sur 16 semaines, conforme estimation initiale. ROI projeté à 3 ans : 67,2 M€ de nouveau chiffre d'affaires sur l'activité Patrimoine, 17,6 M€ de revenue share API B2B sur partenaires FISP tiers, soit 84,8 M€ vs investissement total CAPEX+OPEX 16 mois estimé à à partir de 460,8 M€.
Voir le cas client banque mutualiste 1 200 conseillers (page connexe sur l'IA conseiller, démarche conformité multi-régimes alignée).
#Chapitre 8 — Opportunités business : agrégateurs, conseil patrimonial, super-apps
FIDA n'est pas qu'un chantier de conformité. C'est aussi — et surtout — l'ouverture d'un marché européen de l'open finance estimé à plusieurs dizaines de milliards d'euros à l'horizon 2030. Quatre familles d'opportunités business émergent clairement.
#Opportunité 1 — Agrégateurs patrimoniaux B2C nouvelle génération
Les premiers agrégateurs européens (Linxo, Bankin', Yolt) sont restés limités au périmètre DSP2 : comptes courants et comptes d'épargne agrégés. Avec FIDA, une nouvelle génération d'agrégateurs patrimoniaux peut couvrir l'ensemble du patrimoine financier : tableau de bord unifié des banques, épargne, crédit, assurance vie, PER, comptes-titres, PEA. Valeur perçue radicalement supérieure pour l'utilisateur. Marché cible : 30 millions de ménages européens disposant d'un patrimoine financier diversifié supérieur à 50 000 euros. Modèle économique typique : freemium B2C, premium 4-9 €/mois pour fonctionnalités avancées, distribution B2B2C via banques partenaires.
#Opportunité 2 — Conseil patrimonial multi-banques pour la gestion de fortune
La clientèle haut de gamme et gestion de fortune (private banking) demande depuis 20 ans une vision consolidée multi-banques, multi-juridictions, multi-produits. Aujourd'hui, cette consolidation est artisanale : extraits PDF, ressaisie manuelle dans des outils dédiés (Performance, FinPort, Wealth Dynamix), retard d'information de plusieurs semaines. Avec FIDA, le conseil patrimonial peut basculer en temps réel : visualisation consolidée instantanée, alertes proactives, recommandations d'arbitrage assisté par IA, optimisation fiscale automatisée. Marché cible : 2,5 millions de clients private banking européens. Acteurs positionnés : grandes banques privées (Indosuez, Pictet, Edmond de Rothschild), gestionnaires de fortune indépendants (CGP, family offices), néo-acteurs digitaux (Yomoni, Nalo, Cashbee).
#Opportunité 3 — Super-apps fintech
Les super-apps asiatiques (Alipay, WeChat Pay, Paytm, Grab Financial) intègrent dans une même application : paiement, épargne, crédit, assurance, investissement, services non financiers (transport, livraison, e-commerce). FIDA crée pour la première fois en Europe les conditions techniques d'émergence de super-apps fintech européennes : agrégation complète possible sous statut FISP, paiement via DSP3, services à valeur ajoutée librement orchestrés. Acteurs positionnés : néobanques en transformation (Revolut, Lydia, N26), assureurs en mue digitale (AXA Banque, Allianz), plateformes commerce intégrant la finance (Amazon Pay Europe, Klarna).
#Opportunité 4 — Comparateurs intelligents et portabilité produit
Les comparateurs européens actuels (Meilleurtaux, LesFurets, Verivox, Idealo Finance) fonctionnent sur de la donnée déclarative : le client saisit sa situation, le comparateur propose. Avec FIDA, comparaison fondée sur des données réelles vérifiées, avec automatisation possible du basculement vers un nouveau fournisseur (portabilité crédit immobilier, portabilité assurance emprunteur, portabilité PER, etc.). Marché cible : tous les marchés produit où la friction de comparaison est aujourd'hui élevée. Modèle économique : commission d'apport, abonnement, partenariats data holder.
#Cadrer son ambition business avec Nehos
Notre approche en mission FIDA inclut systématiquement, en phase 5 de la Méthode Nehos Open Finance Ready™, un cadrage de l'ambition business associée. Question structurante : votre établissement vise-t-il le pur défensif (se conformer pour éviter les sanctions et défendre sa base) ou un positionnement offensif (créer une nouvelle ligne business Open Finance) ? Les deux postures sont légitimes. Le défensif reste indispensable et représente un minimum. L'offensif est une opportunité de croissance qui ne se représentera pas à cette échelle avant la prochaine décennie. Voir le service Open Banking DSP3 Nehos et le secteur Banque-Assurance-Finance Nehos.