Guide FIDA Open Finance 2026 : la préparation des banques en 5 phases (méthode Nehos)

#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 (à confirmer par les normes techniques de réglementation), 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 a déjà réalisé une partie significative du chantier FIDA technique.

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, dont la durée dépend du niveau de départ et de 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 : elle varie selon la taille de l'établissement et son niveau de départ, de quelques semaines pour une fintech déjà mature à plusieurs mois pour une banque universelle multi-marchés. Budget : sur devis, chiffré en 48 h après un premier échange. 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 adopté par un nombre croissant de 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 — Exemple de situation : une banque mutualiste prépare FIDA

Exemple de situation construit pour illustrer la méthode. Ce n'est pas la description d'un client réel : aucun résultat chiffré n'y figure.

#Le contexte

Une banque mutualiste régionale française, avec un réseau d'agences sur quelques départements, une clientèle de particuliers et de professionnels, et des produits couverts par FIDA : comptes courants et d'épargne, prêts, assurance vie et titres en partenariat avec des acteurs régionaux. Son API DSP2 est déjà en place. Un Compliance Officer DORA et un RSSI existent, mais pas encore de fonction Open Banking dédiée.

#Phase 1 — Diagnostic

L'audit data accessibility évalue, produit par produit, ce qui est déjà exposable : les comptes de paiement et l'épargne héritent d'une API DSP2 robuste, le crédit existe mais avec des schémas non alignés sur le Berlin Group étendu, l'assurance vie et les titres sont en silo chez les partenaires, avec des identifiants client non unifiés.

Recommandation type : démarrer par l'épargne et le crédit, traiter l'assurance et les titres dans un second paquet avec les partenaires métier.

#Phase 2 — Plateforme API

Conception de l'architecture cible : API OpenAPI 3.1 et FAPI 2.0 documentées. Décision stratégique : construction interne du portail API pour les produits cœur (épargne, crédit), partenariat avec un infrastructure provider pour les produits en partenariat (assurance, titres), afin de mutualiser l'intégration avec les fournisseurs métier. Plan de mise en œuvre piloté par un comité Open Finance.

#Phase 3 — Consentement et CMP

Déploiement de la Consent Management Platform, intégrée au tunnel d'authentification existant. Journalisation immuable par hash chain avec horodatage qualifié. Dashboard self-care intégré à l'espace client web et mobile. Audit RGPD croisé par le DPO interne.

#Phase 4 — Préparation FISP ACPR (volet stratégique)

Préparation de la création d'une filiale FISP, par exemple une filiale « Patrimoine » proposant un service d'agrégation et de conseil patrimonial multi-banques à la clientèle haut de gamme. Livrables : statuts de la filiale, plan de capital, gouvernance documentée, dispositif AML mutualisé avec la banque mère, sécurité IT adossée au SI de la banque. Dossier d'enregistrement ACPR préparé en amont de la publication finale de FIDA.

#Phase 5 — Monétisation et go-to-market

Structuration du modèle économique : pricing API B2B pour les FISP tiers (abonnement selon volume, revenue share au-delà d'un seuil), tarification interne neutre vers la filiale FISP, packaging de l'offre Patrimoine (tableau de bord client, conseil patrimonial assisté par IA conforme AI Act, alertes d'opportunités fiscales, comparateur d'allocation d'actifs). Plan de lancement commercial en pilote, puis généralisation.

#Ce qu'on suit à l'issue de la mission

À l'issue de la mission, on compare la maturité FIDA à l'état de départ : architecture API documentée et adoptée, CMP en production, dossier FISP ACPR prêt, calendrier de dépôt et de lancement. Le ROI d'une nouvelle ligne d'activité Open Finance se construit ensuite avec la banque, produit par produit : nous ne l'annonçons pas à l'avance.

Voir aussi le service Open Banking DSP3 Nehos pour échanger sur votre propre situation.

#Chapitre 8 — Opportunités business : agrégateurs, conseil patrimonial, super-apps

FIDA n'est pas qu'un chantier de conformité. C'est aussi l'ouverture d'un marché européen de l'open finance en construction. 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. Cible : les ménages disposant d'un patrimoine financier diversifié. Modèle économique typique : freemium B2C, premium 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. 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, 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. Voir le service Open Banking DSP3 Nehos et le secteur Banque-Assurance-Finance Nehos.

Photos : RDNE Stock project, fauxels, Kampus Production sur Pexels.