DSP3 vs DSP2 : les 8 changements qui redéfinissent l'open banking en Europe en 2026

#DSP3 : la nouvelle directive paiement européenne

La DSP2 (Directive sur les Services de Paiement 2, Directive 2015/2366/UE) est entrée en application en janvier 2018. Elle a posé les premières fondations de l'open banking européen en obligeant les banques à ouvrir leurs API aux tiers agréés (AISP, PISP) et en introduisant l'authentification forte (SCA). Huit ans plus tard, le bilan est mitigé.

Les lacunes identifiées par la Commission européenne sont structurelles : les API proposées par les banques étaient souvent de mauvaise qualité (disponibilité insuffisante, documentation lacunaire, réponses lentes), rendant l'open banking inutilisable en production pour de nombreuses fintechs. L'authentification forte — nécessaire sur le principe — était si contraignante dans son implémentation qu'elle dégradait massivement l'expérience utilisateur, notamment sur mobile. Et malgré DSP2, la fraude aux paiements a continué d'augmenter : selon l'EBA, les pertes liées à la fraude aux virements dépassent 1,5 milliard d'euros par an dans l'UE.

La Commission européenne a proposé en juin 2023 un paquet législatif composé de deux textes complémentaires : DSP3 (qui remplace DSP2 sous forme de directive) et le PSR (Payment Services Regulation — règlement directement applicable), tous deux adoptés par le Parlement européen en 2024. La transposition nationale de DSP3 est attendue entre fin 2026 et mi-2027 dans la plupart des États membres, dont la France, avec une application pleine visée pour fin 2027.

#Objectifs du paquet DSP3/PSR

Le paquet DSP3/PSR poursuit trois ambitions distinctes :

Harmonisation réglementaire renforcée. Le PSR est un règlement — directement applicable sans transposition nationale, contrairement à DSP3 qui reste une directive. Cette dualité volontaire permet d'harmoniser les règles les plus critiques (SCA, IBAN check, droits des prestataires) tout en laissant une marge de manœuvre nationale sur certains aspects de mise en œuvre.

Stimulation de l'open banking dans l'UE. DSP2 avait ouvert la porte ; DSP3 impose des standards de qualité d'API et élargit le périmètre de données accessibles. L'objectif affiché est de faire de l'open banking européen un vrai standard industriel comparable à ce qui existe au Royaume-Uni (Open Banking Implementation Entity) ou au Brésil (Open Finance).

Protection accrue des consommateurs et des entreprises. Les nouvelles règles de remboursement en cas de fraude, l'IBAN name check et le renforcement de la SCA visent à réduire les pertes dues aux arnaques au virement (SCAM) qui ont explosé depuis 2020.

#Ce qui change vs DSP2 : les 8 évolutions clés

#1. IBAN name check obligatoire

C'est probablement la mesure anti-fraude la plus visible. Le vérificateur de bénéficiaire (Verification of Payee / IBAN name check) devient obligatoire pour tous les virements SEPA. Avant d'exécuter un virement, le prestataire de paiement du payeur doit vérifier que le nom saisi correspond au titulaire du compte IBAN de destination.

Cette vérification cible directement les arnaques au changement de RIB (Business Email Compromise, fraude au faux fournisseur) et les virements frauduleux initiés par des tiers malveillants. Elle était déjà obligatoire au Royaume-Uni depuis 2019 (Confirmation of Payee) et aux Pays-Bas : les résultats sont probants, avec une réduction significative des fraudes aux virements.

Pour les banques et PSP, l'implémentation technique implique un accès à une base de données d'IBAN/nom harmonisée au niveau européen — la Commission travaille avec le schéma SEPA (EPC) pour définir le protocole d'interconnexion.

#2. SCA renforcée avec nouvelles exemptions harmonisées

DSP3 maintient l'obligation de SCA (Strong Customer Authentication) mais réforme ses exemptions. L'un des problèmes majeurs de DSP2 était la fragmentation des exemptions : chaque État membre interprétait différemment les cas d'usage exemptés (paiements récurrents, faible valeur, bénéficiaires de confiance), créant une Europe des paiements à plusieurs vitesses.

Le PSR harmonise directement les exemptions SCA au niveau européen :

• Paiements inférieurs à à partir de 480 € (sous réserve du plafond cumulé de à partir de 1 225 €)
• Paiements récurrents de même montant vers un même bénéficiaire
• Virements entre comptes détenus par le même titulaire dans le même établissement
• Bénéficiaires de confiance explicitement définis par l'utilisateur
• Analyse de risque transactionnel (TRA) avec taux de fraude certifié en dessous des seuils EBA

Une nouveauté : l'harmonisation des exemptions B2B, permettant aux entreprises de déployer des solutions de paiement automatique inter-entreprises sans SCA systématique, sous conditions de sécurité renforcées.

#3. Obligation d'accès par API standardisée — fin du screen scraping

DSP2 interdisait théoriquement le screen scraping (récupération automatique des données bancaires en simulant un utilisateur), mais des exceptions persistaient faute d'API de qualité. DSP3 met fin définitivement à cette tolérance : les banques doivent obligatoirement proposer une API dédiée de qualité certifiée.

Les nouveaux critères de qualité imposés aux API bancaires incluent :

• Disponibilité minimale de 99,5% (contre aucun seuil défini sous DSP2)
• Latence maximale de réponse alignée sur les transactions directes (pas de SLA dégradé pour les tiers)
• Documentation conforme aux spécifications Berlin Group NextGenPSD2 évoluées
• Sandbox obligatoire ouverte aux développeurs tiers
• Monitoring public de la performance de l'API avec reporting mensuel aux autorités compétentes

Ces exigences signifient qu'une banque ne peut plus proposer une API bancale pour décourager les fintechs. L'ACPR disposera de nouveaux leviers de sanction en cas de non-conformité des API.

#4. Nouveaux prestataires PISP/AISP avec agrément simplifié

DSP3 simplifie le parcours d'agrément pour les PISP (Payment Initiation Service Providers — prestataires d'initiation de paiement) et les AISP (Account Information Service Providers — prestataires d'information sur les comptes). Le passeport européen est renforcé : un agrément obtenu dans un État membre ouvre l'accès à tous les marchés de l'UE avec des procédures de notification simplifiées.

Les exigences en fonds propres pour les PISP/AISP sont aussi recalibrées pour les petites structures, permettant à des fintechs à impact réduit d'accéder au marché sans les coûts de conformité des établissements de paiement complets.

#5. Règles open finance étendues — assurance, épargne, investissement

C'est la transformation structurelle de long terme. DSP3 s'inscrit dans un mouvement plus large d'open finance porté par le règlement FIDA (Financial Data Access — en cours de négociation finale), qui étend le principe de partage de données au-delà des comptes bancaires : contrats d'assurance, plans d'épargne, portefeuilles d'investissement, contrats de crédit.

Concrètement, un AISP pourra demain agréger dans une seule application : le compte courant BNP, le PEA Boursorama, l'assurance-vie Axa et le contrat de prévoyance Malakoff Humanis — avec le consentement explicite du titulaire. Ce niveau d'agrégation financière globale était impossible sous DSP2.

#6. Renforcement de la protection consommateur

Le PSR élargit les obligations de remboursement en cas de fraude. Sous DSP2, les règles de responsabilité laissaient souvent le consommateur dans une zone grise difficile à résoudre. DSP3/PSR introduit :

• La responsabilité partagée entre banque du payeur et banque du bénéficiaire en cas d'arnaque au virement (le principe « follow the money »)
• Des délais de remboursement réduits (sous 10 jours ouvrés pour les cas non contestés)
• Un mécanisme de réversibilité des virements pour les cas de fraude avérée, avec coopération bancaire obligatoire

#7. Super-wallets réglementés

DSP3 reconnaît explicitement la catégorie des super-wallets — applications mobiles (comme Apple Pay, Google Wallet, PayPal ou des solutions fintech natives) capables d'initier des paiements, de stocker des instruments de paiement et de proposer des services financiers complémentaires. Ces acteurs doivent désormais obtenir un agrément PSIP (Payment Service and Infrastructure Provider) harmonisé, soumis à des exigences de capital, de sécurité et d'interopérabilité.

L'enjeu pour les grandes plateformes tech non-bancaires est significatif : opérer un super-wallet en Europe nécessitera soit un agrément dédié, soit un partenariat avec un établissement agréé.

#8. Open banking B2B encadré

DSP2 était essentiellement pensé pour les particuliers (B2C). DSP3 encadre formellement l'open banking B2B : accès API pour les entreprises, initiation de paiement pour les virements commerciaux, agrégation de comptes d'entreprise multi-banques. Les exemptions SCA B2B sont élargies pour faciliter l'automatisation des paiements entre entreprises, à condition de respecter des standards de sécurité spécifiques aux flux inter-entreprises.

#Impact sur les DSI bancaires

Pour les directions des systèmes d'information des banques et des établissements de paiement, DSP3 représente un programme technique d'ampleur. La migration ne peut pas être un simple rafraîchissement de façade.

#Migration vers des API standardisées

Les API propriétaires développées sous DSP2 doivent évoluer vers les spécifications Berlin Group NextGenPSD2 dans leur version DSP3. Ce standard européen, maintenu par le Berlin Group (consortium de plus de 40 banques et PSP européens), définit les endpoints REST, les formats de données JSON, les flux OAuth 2.0 et les webhooks nécessaires à l'open banking. L'alignement sur cette norme est désormais une obligation légale, pas un choix architectural.

#OAuth 2.0 + FAPI 2.0

L'authentification et l'autorisation doivent migrer vers OAuth 2.0 avec FAPI 2.0 (Financial-grade API Security Profile 2.0), un profil de sécurité renforcé développé par la OpenID Foundation spécifiquement pour les services financiers. FAPI 2.0 impose notamment :

• PKCE (Proof Key for Code Exchange) pour tous les flows d'autorisation
• DPoP (Demonstration of Proof-of-Possession) pour lier les tokens d'accès à un client spécifique et prévenir le vol de tokens
• Durée de vie des tokens réduites et rotation obligatoire des refresh tokens

Pour une DSI bancaire, cela signifie mettre à jour ou remplacer son serveur d'autorisation OAuth et revalider l'ensemble des flows d'authentification des tiers agréés.

#Gestion des consentements granulaires

DSP3 renforce les exigences sur la gestion des consentements : durée maximale, périmètre des données accessible, révocation en temps réel par l'utilisateur. Une plateforme de consent management conforme doit permettre à l'utilisateur de voir tous ses consentements actifs, les données partagées avec chaque tiers, et de révoquer individuellement tout consentement — avec propagation effective en moins de 24 heures vers les AISP/PISP concernés.

L'architecture de consent management doit être découplée de la couche d'API elle-même et journalisée de manière immuable pour les besoins d'audit réglementaire.

#Tests de conformité ACPR et sandbox obligatoire

DSP3 impose aux banques de maintenir une sandbox permanente accessible aux développeurs tiers, avec un environnement de test représentatif de la production. L'ACPR devrait publier un guide de certification des API bancaires DSP3 — les établissements qui ne passent pas ces tests s'exposent à des sanctions similaires à celles prévues pour une API indisponible.

#Monitoring SLA API

Le seuil de 99,5% de disponibilité de l'API est non négociable. Pour une API bancaire en production, cela représente un budget de downtime annuel maximum de 43,8 heures. Les incidents doivent être déclarés aux autorités via un canal dédié, avec un rapport post-mortem sous 72 heures pour les interruptions dépassant 30 minutes — un niveau d'exigence proche des standards SRE des grandes plateformes tech.

Pour les DSI, cela implique une architecture haute disponibilité dédiée à l'API open banking (infrastructure séparée de la banque en ligne grand public), un monitoring temps réel avec alerting automatique, et une procédure de bascule documentée.

#Opportunités pour les fintechs et néobanques

Si DSP3 est un chantier pour les banques, c'est un accélérateur de marché pour les fintechs et néobanques agiles.

#Nouveaux agréments PSP simplifiés

Le passeport européen harmonisé permet à une fintech agréée en France (ACPR) d'opérer dans les 27 États membres avec une simple procédure de notification — sans repassage d'agrément local. Le marché addressable passe instantanément de 68 millions de Français à 450 millions d'Européens.

#Accès données assurance et épargne via FIDA

Le règlement FIDA (Financial Data Access) ouvre aux AISP agréés l'accès aux données d'assurance, d'épargne et d'investissement avec le consentement des titulaires. Pour une application de gestion de patrimoine ou de conseil financier automatisé, c'est l'accès à une profondeur de données sans précédent — solde PEA, provisions d'assurance-vie, cotisations retraite — permettant un conseil personnalisé réellement global.

#Payment Initiation B2B

L'encadrement du payment initiation B2B permet aux fintechs B2B de proposer des solutions de virement comptable automatique (déclenchement de paiement depuis un ERP ou un outil de facturation) sans passer par un PSP intermédiaire. La réduction des coûts de traitement des virements fournisseurs et clients est l'argument commercial principal.

#Account Aggregation enrichie

Avec DSP3, l'agrégation de comptes dépasse le simple relevé de solde. Les données accessibles incluent les transactions catégorisées, les informations de crédit, les données d'épargne et (via FIDA) les données assurantielles. Pour les applications de Personal Finance Management ou de conseil B2B, cela ouvre des cas d'usage de scoring, d'analyse de trésorerie et de projection financière bien plus précis.

#Embedded Finance dans les apps tierces

DSP3 facilite l'intégration de services de paiement dans des applications non financières (ERP, marketplaces, outils SaaS B2B) via des API dédiées. L'embedded finance — paiements et services financiers intégrés nativement dans un workflow non-bancaire — devient plus accessible techniquement et juridiquement.

#Open Banking B2B : les cas d'usage business

L'ouverture de l'open banking aux flux B2B sous DSP3 génère des cas d'usage à fort potentiel de valeur pour les entreprises.

#Réconciliation comptable automatique

Chaque virement entrant ou sortant peut déclencher automatiquement une écriture comptable via l'API open banking. Couplé à un moteur de reconnaissance ML, un ERP peut rapprocher une facture fournisseur avec son règlement bancaire en temps réel — éliminant le processus manuel de lettrage qui mobilise plusieurs heures par semaine dans la plupart des PME. La facturation électronique 2026 + open banking créent ensemble une chaîne de traitement comptable quasi-automatisée.

#Trésorerie temps réel multi-banques

Une PME avec plusieurs comptes (BNP Pro, CIC Pro, Crédit Agricole) peut, via une API d'agrégation DSP3, visualiser sa position de trésorerie consolidée en temps réel, programmer des sweepings automatiques et optimiser l'allocation de liquidité entre entités juridiques. Ce cas d'usage, réservé aux grandes entreprises sous DSP2 (via des solutions bancaires premium coûteuses), devient accessible aux TPE/PME via des apps SaaS.

#Factoring digital instantané

L'accès en temps réel aux données de compte du débiteur (via API AISP, avec son consentement) permet à un factor ou à une plateforme d'affacturage de valider une créance en quelques secondes — solde disponible, historique de paiement, absence d'incident. Le délai de financement passe de 48-72 heures à moins d'une heure. Les agents IA pour l'automatisation couplés à l'open banking B2B créent une chaîne de financement de créance entièrement automatisée.

#KYC bancaire automatisé

Pour les plateformes nécessitant une vérification d'identité bancaire (prêt, crédit fournisseur, garantie locative), l'open banking DSP3 permet de valider en temps réel le solde, l'historique de transactions et la cohérence des mouvements sans demander de documents : le processus KYC passe de plusieurs jours à quelques minutes.

#Scoring crédit PME temps réel

L'accès aux données de compte B2B permet de construire un score de crédit PME basé sur les flux réels (chiffre d'affaires observé, régularité des paiements, saisonnalité) plutôt que sur les bilans comptables avec 18 mois de retard. Les plateformes de lending fintech peuvent prendre des décisions de crédit en temps quasi-réel, avec un risque mieux calibré.

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

#Agrégateurs open banking 2026 : comparatif

Pour une fintech ou une DSI souhaitant intégrer l'open banking sans développer sa propre connectivité bancaire, les agrégateurs open banking (aussi appelés TPP providers ou AIS/PIS platforms) sont la voie privilégiée.

#Les acteurs du marché européen

Bridge (Bankin'). Acteur français historique, Bridge couvre plus de 350 banques françaises et européennes. Son API REST est documentée et son SDK JavaScript facilite l'intégration. Fort sur le B2C (agrégation compte, catégorisation transactions), Bridge a développé depuis 2023 une offre B2B dédiée avec webhooks temps réel et data enrichment ML.

Tink (Visa). Racheté par Visa en 2021 pour 1,8 milliard d'euros, Tink est le leader en termes de couverture géographique européenne (3 500 banques connectées, 18 pays). Sa certification DSP2/DSP3 est exemplaire et son infrastructure est dimensionnée pour les volumes enterprise. Tarification plus élevée que les acteurs pure-play.

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

Powens (ex-Budget Insight). Acteur français certifié AISP, Powens est positionné sur le marché B2B et les DSI. Son SDK Python + Node.js est apprécié des équipes techniques, et sa couverture des banques professionnelles françaises (CIC Pro, LCL Pro, BNP Pro) est l'une des meilleures du marché. Choix privilégié pour les intégrations comptables et ERP.

Plaid. Dominant aux États-Unis, Plaid a une présence européenne limitée et des incertitudes réglementaires persistantes dans l'UE. À éviter pour des projets nécessitant une couverture complète des banques françaises ou une certification ACPR.

Nordigen (GoCardless). Racheté par GoCardless en 2022, Nordigen propose une API freemium couvrant les banques de plus de 30 pays européens via le framework Open Banking EU. Bon rapport qualité/prix pour les startups, avec des limites de volumétrie qui le cantonnent aux projets à trafic modéré.

#Critères de sélection pour une intégration Next.js

Pour une intégration dans un stack Next.js 16, les critères techniques prioritaires sont : webhooks temps réel (pour éviter le polling), SDK TypeScript officiel, sandbox de développement stable, et documentation des schémas de données normalisés (idéalement Berlin Group compatible). Powens et Bridge se distinguent sur ces critères pour le marché français. L'event-driven architecture basée sur des webhooks est le pattern recommandé pour consommer les événements open banking sans état de polling.

#Architecture d'une intégration open banking

Une architecture open banking de production suit un pattern technique éprouvé en plusieurs couches.

#Couche d'authentification : OAuth 2.0 PKCE

L'utilisateur s'authentifie auprès de sa banque via un flow OAuth 2.0 Authorization Code avec PKCE : le code verifier est généré côté client, le code challenge est transmis à l'autorisation, et le code verifier est échangé avec le token endpoint. Ce flow protège contre l'interception du code d'autorisation et est obligatoire sous FAPI 2.0. La sécurité des agents IA OWASP partage des patterns de sécurité similaires pour les tokens d'accès sensibles.

#Consent Management

Une base de données PostgreSQL dédiée stocke les consentements actifs avec leur périmètre (comptes autorisés, durée, types de données), les tokens OAuth associés (chiffrés), et le journal immuable des accès effectués. La révocation d'un consentement déclenche un event qui invalide le token côté agrégateur et archive le consentement en base avec timestamp.

#API Gateway

Un API Gateway (Kong, AWS API Gateway ou Nginx + LUA) centralise les appels sortants vers les agrégateurs open banking : rate limiting par tenant, retry avec backoff exponentiel, circuit breaker pour gérer les indisponibilités temporaires de l'agrégateur, et logging structuré de chaque requête pour l'audit réglementaire.

#Webhook Handler

Les événements asynchrones (nouveau mouvement de compte, consentement révoqué, erreur API) sont reçus via des webhooks signés (HMAC-SHA256) par l'agrégateur et traités par un handler NestJS. Le handler valide la signature, publie l'événement sur une queue (Redis Streams ou AWS SQS), et acquitte immédiatement le webhook — le traitement métier est asynchrone pour ne pas bloquer le producer. Ce pattern rejoint les principes de l'event-driven architecture appliqués aux données financières.

#Normalisation des données

Les données renvoyées par les différents agrégateurs sont normalisées selon un schéma interne inspiré du Berlin Group (transaction ID, booking date, value date, amount, creditor/debtor name, IBAN, category). Cette normalisation isole le code métier des variations entre agrégateurs et facilite un éventuel changement de fournisseur.

#Stockage sécurisé

Les données bancaires sont stockées dans PostgreSQL avec chiffrement AES-256 au repos pour les données sensibles (IBAN, soldes, transactions). Un audit log immuable (append-only table) trace chaque accès aux données, chaque consentement et chaque révocation — obligatoire pour justifier la conformité DSP3 lors d'un contrôle ACPR. Les tokens OAuth sont chiffrés en base et n'apparaissent jamais en clair dans les logs. L'OCR IA pour les factures peut s'intégrer dans ce pipeline pour enrichir les transactions avec les données des factures correspondantes.

#Cas Nehos : SaaS comptabilité pour 2 000 TPE clientes

#Le problème initial

Nehos a développé pour un client éditeur SaaS B2B une plateforme de comptabilité pour TPE. Sur 2 000 clientes actives, moins de 20% importaient régulièrement leurs relevés bancaires — via un processus manuel OFX/CSV exigeant une exportation depuis la banque, un téléchargement, une importation dans le logiciel. Résultat : 80% des TPE avaient des données comptables en retard de plusieurs semaines, rendant le module de rapprochement bancaire pratiquement inutilisable.

#La solution Nehos : intégration Powens open banking

Nehos a conçu et intégré une connexion open banking via l'API Powens, avec les composants suivants :

Onboarding bancaire dans le flux d'inscription. À l'étape 3 du wizard de création de compte, le nouvel utilisateur est invité à connecter sa banque professionnelle. Le flow OAuth 2.0 PKCE redirige vers l'interface d'authentification Powens, qui redirige vers la banque pour authentification forte. L'intégralité du flow prend moins de 90 secondes.

Parsing automatique des transactions. Dès la connexion établie, l'historique des 12 derniers mois est importé et parsé. Un modèle ML de catégorisation (fine-tuné sur un corpus de transactions TPE françaises) assigne automatiquement chaque transaction à un compte du plan comptable général (PCG 2025). Le taux de catégorisation correcte dépasse 87% sans intervention humaine.

Webhook temps réel. Les nouveaux mouvements sont poussés par Powens via webhook dans les 15 minutes suivant leur apparition sur le relevé bancaire. Le rapprochement comptable est déclenché automatiquement : si une facture émise correspond à un virement entrant (montant + délai), elle est lettrée automatiquement.

#Résultats mesurés

Six mois après le déploiement de l'intégration open banking :

• 78% des TPE connectent leur banque dès l'onboarding (vs 20% avec l'import manuel)
• Rapprochement comptable 0 manuel : 100% des virements sont traités automatiquement, avec révision humaine uniquement pour les cas ambigus (< 13% des transactions)
• Churn réduit de 22% sur la cohorte de clientes ayant activé l'open banking vs celles ne l'ayant pas activé — la connexion bancaire est le principal prédicteur de rétention sur cette plateforme
• NPS +18 points sur la fonctionnalité de rapprochement automatique

Ce projet illustre comment l'agent IA pour l'automatisation couplé à l'open banking transforme une corvée comptable en processus invisible. L'architecture RAG pourrait compléter cette solution en permettant aux TPE d'interroger leurs données financières en langage naturel.

#Feuille de route DSP3 pour une DSI

#Court terme : 0-6 mois — Audit et gap analysis

Avant toute décision d'investissement, la première étape est un audit de conformité DSP2 existante. De nombreuses banques et PSP ont des angles morts : des API propriétaires non documentées, des flux de screen scraping tolérés encore actifs, des contrats AISP/PISP jamais mis à jour depuis 2018. La gap analysis DSP3 dresse l'inventaire précis des écarts et priorise les chantiers.

Points d'attention spécifiques :

• Inventaire des APIs actuellement exposées aux tiers (format, version, disponibilité réelle)
• Audit du système de gestion des consentements (durée, granularité, révocation)
• Vérification de la conformité des contrats avec les agrégateurs tiers
• Analyse de la couverture SCA actuelle vs nouvelles exemptions harmonisées

Budget indicatif : 15 000 –640 000 € selon la complexité du SI.

#Moyen terme : 6-12 mois — Migration API et IBAN check

La deuxième phase adresse les chantiers techniques prioritaires : migration vers des API Berlin Group NextGenPSD2 complètes, déploiement de l'IBAN name check sur tous les flux virement SEPA, mise à niveau OAuth 2.0 + FAPI 2.0, et déploiement de la sandbox développeurs.

L'IBAN name check mérite une attention particulière : l'implémentation nécessite une connexion au réseau européen de vérification de bénéficiaire (dont le protocole définitif sera publié par l'EPC en 2026) et une refonte des interfaces de saisie de virement pour intégrer le retour de vérification en temps réel sans dégrader l'UX.

La migration monolith vers microservices peut s'avérer nécessaire si l'architecture de la banque en ligne ne permet pas d'isoler le service open banking dans un composant indépendant à haute disponibilité.

Budget indicatif : 150 000 –9 600 000 € selon la complexité SI et le nombre d'API à refondre.

#Long terme : 12-24 mois — Open finance et B2B payment initiation

La troisième phase intègre les opportunités créées par DSP3 et le règlement FIDA : connexion aux APIs d'assurance et d'épargne (dès publication des standards techniques FIDA), déploiement du payment initiation B2B pour les flux inter-entreprises, et développement de nouveaux produits open finance (agrégation patrimoniale, scoring crédit PME, embedded finance).

Cette phase est aussi celle de la différenciation compétitive : les banques et fintechs qui auront construit une infrastructure open banking de qualité sous DSP3 pourront lancer des produits open finance avant leurs concurrents, capturant la valeur créée par l'accès aux données élargies.

Le DORA Act s'appliquant simultanément, cette phase doit intégrer les exigences de résilience DORA pour les APIs open banking critiques — notamment les tests TLPT et le registre des tiers pour les agrégateurs utilisés.

Budget indicatif total : 80 000 –4 000 000 € pour une fintech ou PSP de taille moyenne. Pour une banque retail, les ordres de grandeur sont supérieurs d'un facteur 3 à 10.

#Conformité DSP3, NIS2 et DORA : la convergence réglementaire

Les DSI du secteur financier font face à une convergence réglementaire inédite en 2026-2027 : DSP3/PSR, DORA, NIS2, AI Act et RGPD s'appliquent simultanément avec des exigences partiellement redondantes mais pas toujours alignées. Une approche par référentiel unique (GRC intégré) est recommandée pour éviter les doublons de conformité et les angles morts.

L'AI Act et ses obligations pour les entreprises françaises touche directement les systèmes de scoring crédit IA et les moteurs de catégorisation ML utilisés dans les architectures open banking — les équipes produit doivent anticiper les exigences de transparence algorithmique. De même, les systèmes insurtech IA bénéficieront directement du règlement FIDA pour accéder aux données d'assurance et construire des modèles de souscription plus précis.

Nehos accompagne les équipes produit et les DSI dans la conception d'architectures open banking DSP3-native : audit de conformité, choix d'agrégateur, intégration technique et documentation réglementaire. Contactez nos services d'intégration API pour un premier échange.