Conformité DSP3 et open banking : combien budgéter en 2026 ?

#DSP3 : un programme de conformité, pas un simple patch technique

La transposition de DSP3 en droit français est attendue entre fin 2026 et mi-2027. Pour les équipes techniques des banques, des PSP et des fintechs, la question n'est plus « faut-il se conformer ? » mais « combien va coûter la mise en conformité, et comment la budgéter ? ».

Sur les projets open banking que nous menons, les budgets DSP3 sont souvent sous-estimés. La raison : la DSP3 ne se résume pas à une mise à jour d'API. C'est un programme qui touche l'infrastructure, la sécurité, la gestion des consentements, le monitoring et la gouvernance des données.

Pour beaucoup d'institutions, l'infrastructure API DSP2 actuelle ne répond pas aux exigences de qualité DSP3. Le chantier de mise à niveau est structurel, pas cosmétique.

---

#Les 5 postes budgétaires de la conformité DSP3

#1. Développement et migration des API open banking (le poste le plus lourd)

C'est le poste le plus lourd. DSP3 impose des API conformes aux spécifications Berlin Group NextGenPSD2 dans leur version évoluée, avec des exigences que la majorité des API DSP2 actuelles ne respectent pas.

Ce que cela implique techniquement :

• Migration vers des endpoints REST standardisés (AIS, PIS, PIIS, CoF) avec réponses JSON normalisées
• Intégration OAuth 2.0 + FAPI 2.0 avec PKCE et DPoP obligatoires
• Implémentation de l'IBAN name check (Verification of Payee) sur tous les flux virement SEPA
• Sandbox développeurs permanente avec données de test réalistes
• Webhooks temps réel pour les événements de compte et de consentement
• Documentation OpenAPI 3.1 conforme aux spécifications EPC

Ce qui fait varier le coût :

Le delta entre une fintech et une banque tient à la complexité du SI. Une fintech construit sur une architecture API-first moderne peut migrer plus vite. Une banque avec un core banking COBOL et des couches d'intégration accumulées depuis des années a un chantier bien plus long.

Nehos développe ces API en stack Node.js/NestJS ou Python/FastAPI, avec une couche d'abstraction qui isole la logique DSP3 du core banking. Ce pattern d'encapsulation API legacy permet de se conformer sans refondre le SI en profondeur.

#2. Certification et agrément ACPR

Toute entité opérant des services de paiement ou d'information sur les comptes en France doit être agréée par l'ACPR (Autorité de Contrôle Prudentiel et de Résolution). DSP3 modifie les conditions d'agrément et de passeport européen.

Postes de coût pour une fintech :

• Dossier d'agrément ACPR (PISP ou AISP) : conseil juridique et préparation
• Fonds propres réglementaires (PISP) : selon le volume de paiements ; pas d'exigence de fonds propres pour l'AISP
• Assurance de responsabilité professionnelle
• Passeport européen : frais juridiques de notification aux autres États membres
• Renouvellement et reporting annuel ACPR

Pour une fintech en phase de lancement, l'agrément et les fonds propres pèsent lourd la première année. Ce poste baisse ensuite (renouvellement et reporting uniquement). Les montants exacts sont à valider auprès de l'ACPR et d'un cabinet spécialisé en droit des paiements.

Pour les banques déjà agréées, le coût se limite à la mise à jour du dossier d'agrément pour intégrer les nouvelles exigences DSP3 : conseil juridique et conformité.

#3. Audit de sécurité et tests d'intrusion

DSP3 renforce les exigences de sécurité des API open banking. Un audit de sécurité spécifique est nécessaire avant mise en production, puis sur une base annuelle.

Périmètre d'un audit DSP3 :

• Tests d'intrusion (pentest) sur les endpoints API AIS/PIS
• Audit de la chaîne OAuth 2.0 / FAPI 2.0 (tokens, refresh, révocation)
• Vérification de l'IBAN name check (contournement, injection)
• Audit du consent management (durée, révocation, propagation)
• Test de résilience DDoS sur l'API gateway
• Revue de code sécurité sur les modules critiques
• Conformité DORA pour les tests TLPT (Threat-Led Penetration Testing)

Types d'audit à prévoir : pentest API open banking (boîte noire et grise), audit FAPI 2.0 / OAuth 2.0, revue de code sécurité des modules critiques, test TLPT DORA (si applicable) et audit annuel de renouvellement. Chaque audit se chiffre auprès du prestataire retenu.

Ces audits doivent être réalisés par un prestataire certifié PASSI (Prestataire d'Audit de la Sécurité des Systèmes d'Information) pour les entités soumises au DORA Act. Pour les fintechs non soumises à DORA, un pentest classique par un cabinet spécialisé suffit, mais l'ACPR recommande le référentiel PASSI.

La sécurité des systèmes IA est un sujet connexe pour les fintechs qui intègrent des modèles ML dans leur scoring ou leur détection de fraude — l'audit doit couvrir les deux dimensions.

#4. Infrastructure de monitoring SLA 99,5 %

DSP3 impose un SLA de disponibilité de 99,5 % sur les API open banking — soit un budget de downtime annuel de 43,8 heures maximum. Ce seuil implique une infrastructure dédiée et un monitoring temps réel.

Architecture de monitoring DSP3 :

• API Gateway haute disponibilité : déploiement multi-zone avec failover automatique (AWS API Gateway, Kong ou Nginx + Lua)
• Monitoring temps réel : Prometheus + Grafana ou Datadog avec alertes sur latence p95, taux d'erreur et disponibilité
• Dashboard de reporting ACPR : publication mensuelle des métriques de performance API (disponibilité, latence, incidents)
• Incident management : procédure de déclaration aux autorités sous 72h pour les interruptions > 30 minutes
• Log centralisé : ELK Stack ou Loki pour l'audit trail réglementaire avec rétention 5 ans

Postes de coût : API Gateway HA (mise en place + récurrent), stack de monitoring (Prometheus/Grafana), dashboard de reporting ACPR, log centralisé avec rétention de 5 ans, astreinte 24/7 (équipe interne ou service managé). L'astreinte est souvent le poste récurrent le plus lourd.

Le choix entre un hébergement cloud souverain OVH/Scaleway et un hyperscaler (AWS, GCP) dépend des exigences de souveraineté de l'institution. Pour les données de paiement, un hébergement en France ou dans l'UE est fortement recommandé — et sera probablement imposé par les guidelines ACPR post-DSP3.

Pour les fintechs avec des budgets contraints, une infrastructure managée (OVH Managed Kubernetes ou Scaleway Kapsule) réduit le coût initial en mutualisant la charge opérationnelle.

#5. Gestion des consentements FAPI 2.0

Le consent management est un module critique sous DSP3 : il gère le cycle de vie complet des autorisations données par les utilisateurs aux tiers AISP/PISP.

Exigences DSP3 pour le consent management :

• Durée maximale configurable par consentement (90 jours par défaut, renouvelable)
• Périmètre granulaire : comptes autorisés, types de données, opérations permises
• Révocation en temps réel par l'utilisateur (propagation < 24h aux tiers)
• Interface utilisateur dédiée (dashboard de consentements actifs)
• Journal d'audit immuable (chaque accès, chaque modification, chaque révocation)
• Conformité RGPD croisée : base légale du traitement, droit d'accès, droit à l'oubli

Postes de coût : développement du module de consentement, interface utilisateur (dashboard), intégration RGPD (DPO, registre des traitements), tests de conformité.

Le consent management est aussi le module qui conditionne la conformité au règlement FIDA (open finance) : sans consent management robuste, l'accès aux données d'assurance et d'épargne prévu par FIDA sera impossible. Investir dans un consent management de qualité aujourd'hui prépare l'infrastructure pour les opportunités open finance de demain.

---

#Budget total par profil d'institution

Le tableau ci-dessous synthétise les ordres de grandeur d'effort selon le profil d'institution.

Délais indicatifs, à valider par un audit de conformité initial. Le périmètre inclut développement, certification, audit, infrastructure et première année de maintenance.

Le coût récurrent annuel (maintenance, monitoring, audits, reporting ACPR) est un poste souvent oublié dans les estimations.

---

#Le coût de la non-conformité : pourquoi attendre coûte plus cher

L'ACPR dispose de pouvoirs de sanction renforcés sous DSP3/PSR. Les conséquences d'une non-conformité sont concrètes et chiffrables.

Sanctions ACPR possibles :

• Amende administrative : jusqu'à 10 % du chiffre d'affaires annuel (PSR, article sur les sanctions harmonisées)
• Retrait ou suspension de l'agrément PISP/AISP — interdiction de commercialiser des services de paiement
• Publication de la sanction (naming and shaming) — impact réputationnel direct
• Astreinte journalière jusqu'à correction effective

Coûts indirects de la non-conformité :

• Perte de contrats avec les banques partenaires (les banques refuseront les connexions API non conformes)
• Impossibilité de bénéficier du passeport européen DSP3 — marché limité à la France
• Risque de responsabilité en cas de fraude sur les flux non conformes (IBAN check non implémenté)
• Retard concurrentiel : les fintechs conformes captent les marchés FIDA (open finance) en premier

L'investissement dans la conformité est un calcul économique rationnel, pas uniquement réglementaire : le montant de l'amende potentielle, rapporté au chiffre d'affaires, dépasse en général largement le coût de la mise en conformité.

Les obligations NIS2 s'ajoutent pour les PSP considérés comme « entités essentielles » — la convergence DSP3 + NIS2 + DORA impose une approche de conformité intégrée pour éviter les doublons de dépense.

---

#Stratégie de budgétisation : 3 approches selon votre situation

#Approche 1 : Fintech en lancement — MVP conforme

Pour une fintech pré-agrément qui construit son premier produit open banking, la stratégie est de livrer un MVP conforme le plus rapidement possible.

Stack que nous recommandons :

• Backend : NestJS + TypeScript sur un monolithe modulaire (pas de microservices prématurés)
• Agrégateur : Powens ou Bridge selon la couverture bancaire cible
• Auth : OAuth 2.0 PKCE via un serveur Keycloak ou Auth0 configuré FAPI 2.0
• Consent management : module custom intégré au backend (pas de solution tierce pour garder le contrôle)
• Monitoring : Prometheus + Grafana sur Kubernetes managé
• Base de données : PostgreSQL avec chiffrement AES-256 au repos

Ce MVP couvre les endpoints AIS (agrégation de comptes) et PIS (initiation de paiement) nécessaires pour l'agrément ACPR, avec un consent management conforme et un monitoring SLA 99,5 %. Le passage à l'échelle se fait ensuite par modules.

Délai de livraison : 4-6 mois. Le dossier d'agrément ACPR peut être préparé en parallèle du développement — Nehos fournit la documentation technique requise (architecture, sécurité, plan de continuité).

#Approche 2 : Fintech établie — migration DSP2→DSP3

Pour une fintech déjà agréée avec une infrastructure DSP2 fonctionnelle, la stratégie est de capitaliser sur l'existant et de ne modifier que les composants non conformes DSP3.

Chantiers typiques :

• Migration OAuth 2.0 vers FAPI 2.0 (DPoP + PKCE obligatoires)
• Implémentation de l'IBAN name check sur les flux PIS
• Mise à niveau du consent management (durée, granularité, révocation temps réel)
• Migration des endpoints vers la spécification Berlin Group NextGenPSD2 évoluée
• Mise en place du monitoring SLA 99,5 % si inexistant
• Audit sécurité DSP3 + mise à jour du dossier ACPR

Le gain par rapport à une refonte complète peut être important. La condition : que l'architecture existante soit suffisamment modulaire pour accueillir les nouveaux composants sans effet de bord. Une architecture event-driven facilite cette migration incrémentale.

#Approche 3 : Banque retail — programme de transformation

Pour une banque retail avec un SI hérité, la conformité DSP3 s'inscrit dans un programme de transformation plus large. La stratégie recommandée : un strangler fig pattern qui isole la couche open banking dans un service dédié sans toucher au core banking.

Architecture cible :

• API Gateway dédié open banking (isolé du portail banque en ligne)
• Couche d'abstraction entre le core banking et les API DSP3 (pattern encapsulation API legacy)
• Consent management centralisé avec interface client intégrée à la banque en ligne mobile
• Monitoring et reporting ACPR automatisés
• Sandbox développeurs avec données synthétiques

Ce programme se décompose en 3 phases (gap analysis, migration technique, open finance) comme décrit dans notre guide DSP3 vs DSP2. Le pattern strangler fig permet de progresser sans risque de régression sur les services de paiement en production.

---

#Grille tarifaire Nehos pour les projets fintech DSP3

Nous menons des projets open banking et fintech. Nos tarifs reflètent la spécificité de ces projets (conformité réglementaire, exigences de sécurité, coordination avec les autorités).

En régie, le développement est facturé 275 € HT/jour. Devis détaillé après l'audit de conformité initial.

Nous recommandons d'associer à chaque projet fintech un profil technique spécialisé paiement et un profil conformité qui connaît les attentes de l'ACPR. Cela évite les allers-retours entre l'équipe technique et le cabinet juridique, une source de surcoûts sur les projets mal organisés.

---

#Calendrier de mise en conformité recommandé

#T3 2026 : Audit et gap analysis

Lancez l'audit de conformité DSP3 maintenant. L'objectif : identifier les écarts entre votre infrastructure actuelle et les exigences DSP3/PSR, et produire un plan d'action chiffré avec priorisation.

Livrables attendus : rapport d'audit détaillé, cartographie des écarts par composant, budget prévisionnel par phase, calendrier de mise en oeuvre.

#T4 2026 : Développement des composants critiques

Priorisez les composants réglementairement obligatoires : migration FAPI 2.0, IBAN name check, consent management. Ces modules ont le plus long délai de développement et de certification.

#T1 2027 : Tests, audit sécurité et sandbox

Déployez la sandbox développeurs, lancez l'audit de sécurité (pentest + revue de code), et ouvrez les tests avec les agrégateurs partenaires. La sandbox doit être opérationnelle avant la transposition nationale pour permettre aux tiers de se préparer.

#T2 2027 : Mise en production et reporting ACPR

Mise en production progressive, activation du monitoring SLA, premiers reportings ACPR. Prévoyez une période de stabilisation de 2 à 3 mois avec un support renforcé.

Ce calendrier est cohérent avec l'application pleine de DSP3 estimée fin 2027. Commencer maintenant laisse une marge de sécurité raisonnable — commencer en 2027 crée un risque de non-conformité à la date d'entrée en vigueur.

La conformité RGPD croisée avec l'AI Act doit être intégrée dans ce calendrier si votre plateforme utilise des modèles ML pour le scoring ou la détection de fraude.

---

#Exemple de situation : plateforme de paiement B2B et migration DSP3

Cet exemple est une situation type construite pour illustrer la démarche. Ce n'est pas un client réel.

Contexte : une fintech B2B agréée PISP propose de l'initiation de paiement pour les flux fournisseurs de PME, connectée à plusieurs banques françaises via un agrégateur comme Bridge. Elle doit passer de DSP2 à DSP3.

Les chantiers à budgéter :

• Migration FAPI 2.0 + DPoP
• Module IBAN name check
• Refonte du consent management
• Infrastructure de monitoring SLA 99,5 %
• Audit de sécurité et pentest API
• Mise à jour du dossier ACPR

Ce qu'il faut viser : une disponibilité de l'API conforme au SLA, un dossier ACPR validé sans remarque bloquante, et, si l'ambition est européenne, une notification de passeport pour opérer dans d'autres États membres.

Le raisonnement économique est le même pour toute fintech : comparer le coût de la mise en conformité à l'exposition à une sanction pouvant atteindre un pourcentage du chiffre d'affaires. Le choix d'un agrégateur open banking adapté limite le budget d'intégration quand l'agrégateur est déjà connecté aux banques partenaires.

Photos : Mikhail Nilov, Pavel Danilyuk sur Pexels.