DSP3 Transposition France — Êtes-vous prêts pour 2026 ?

#DSP3 vs DSP2 : les 5 différences structurelles que vous devez connaître

La tentation est forte de traiter DSP3 comme une 'mise à jour' de DSP2. C'est une erreur d'appréciation. Avec 340 articles contre 115 pour DSP2, c'est un texte quasi-entièrement réécrit — même si 60 % des obligations de DSP2 perdurent. Les cinq différences structurelles qui impactent directement les équipes produit, conformité et tech :

#1. SCA améliorée : moins d'exemptions, meilleure attribution de responsabilité

Sous DSP2, la SCA (Strong Customer Authentication) comptait une liste d'exemptions complexe que beaucoup de PSP utilisaient généreusement. DSP3 rationalise ces exemptions et les conditionne à des seuils de fraude mesurés. Si votre taux de fraude sur les transactions exemptées dépasse les seuils EBA, vous perdez l'accès aux exemptions correspondantes.

Autre évolution majeure : la responsabilité partagée en cas de paiement frauduleux autorisé par le client (victime de manipulation psychologique, vishing, spoofing). DSP2 laissait souvent le consommateur sans recours dans ce cas. DSP3 impose aux PSP d'indemniser le consommateur sauf s'ils prouvent une négligence grave de sa part, et met en place un mécanisme de partage de responsabilité avec la banque du bénéficiaire (si celle-ci a laissé passer une transaction suspecte).

#2. API bancaires standardisées : fin des 'obstacles volontaires'

Sous DSP2, les banques devaient ouvrir des API aux tiers agréés (AISP, PISP) mais les textes d'application laissaient une marge d'interprétation importante. Résultat : de nombreuses banques maintenaient des API peu fiables, peu documentées, ou avec des délais de réponse volontairement dégradés — ce qu'on appelait dans le secteur les 'obstacles volontaires'.

DSP3 interdit explicitement ces pratiques. Les banques doivent garantir des API avec un niveau de disponibilité et de performance équivalent à leurs propres interfaces clients. En cas de performance dégradée chronique, la banque perd le droit d'exiger que les AISP/PISP utilisent ses API — et doit autoriser l'accès via l'interface client classique (screen scraping encadré). C'est un changement majeur pour la qualité réelle de l'Open Banking en France.

Le standard API privilégié en Europe reste Berlin Group NextGenPSD2, adopté par la majorité des grandes banques françaises. DSP3 n'impose pas un standard unique mais renforce les obligations de performance qui le rendent incontournable en pratique.

#3. Nouvelles règles pour les agrégateurs AISP

Les AISP (Account Information Service Providers — agrégateurs de comptes) voient leur cadre renforcé sur deux points. Premier point : les conditions d'accès aux données bancaires sont clarifiées — le consentement explicite de l'utilisateur doit être renouvelé tous les 90 jours (vs 90 jours déjà sous DSP2, mais avec des exigences de forme plus précises). Deuxième point : les AISP ne peuvent accéder qu'aux données bancaires strictement nécessaires à leur service. Toute collecte extensive ou stockage de données non justifiée par le cas d'usage est explicitement interdite.

Pour les fintechs construisant sur des agrégateurs comme Bridge, Tink ou Powens : ces contraintes s'appliquent à l'agrégateur directement, pas à vous. Mais votre contrat de service et votre UX de consentement doivent être alignés avec ces règles.

#4. Initiateurs de paiement PISP : nouvelles protections consommateur

Les PISP (Payment Initiation Service Providers) bénéficient de nouvelles règles de protection du consommateur. Si un paiement initié par un PISP est non autorisé ou frauduleux, la responsabilité du PISP est explicitement engagée (avant DSP3, les règles d'attribution de responsabilité entre banque et PISP étaient floues). Les délais de remboursement sont durcis.

Côté positif pour les PISP : la directive interdit aux banques d'imposer des délais supplémentaires, des vérifications redondantes ou des frais spécifiques pour les paiements initiés par un tiers. Cela devait éliminer les derniers obstacles à l'adoption des paiements Open Banking dans le commerce électronique.

#5. Protection renforcée contre la fraude : obligations de monitoring partagé

DSP3 introduit l'obligation pour les PSP de partager des données de fraude entre eux via des mécanismes encadrés — ce que la directive appelle le 'fraud data sharing'. C'est un pas vers des systèmes de lutte anti-fraude collectifs, similaires à ce qui existe dans les cartes (Visa, Mastercard fraud intelligence networks). Les modalités exactes de mise en œuvre restent à préciser dans les normes techniques de l'EBA (RTS et GL attendus en 2025-2026).

#Le calendrier réglementaire DSP3 : ce que vous pouvez anticiper

Un point souvent mal compris : DSP3 est une directive, pas un règlement. Elle doit être transposée en droit national par chaque État membre dans un délai de 18 mois à compter de sa publication au Journal Officiel de l'UE. Le PSR (Payment Services Regulation), son texte jumeau, est un règlement d'application directe — il entre en vigueur sans transposition nationale.

Notez que les normes techniques (RTS et GL) rédigées par l'EBA pour préciser les modalités d'application seront publiées progressivement après la directive — certaines pourraient ne pas être finalisées avant 2027. Cela crée une situation d'incertitude pour les acteurs qui attendent les textes de niveau 2 pour lancer leur mise en conformité. Notre recommandation : ne pas attendre les RTS pour les sujets structurels (SCA, API bancaires, gouvernance interne).

→ 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.

#Qui est concerné ? Cartographie précise des entités impactées

#Banques et établissements de crédit

Impact maximal : obligations API renforcées, SCA améliorée côté émetteur, mécanismes de partage de données fraude, nouvelles règles de remboursement consommateur. Le chantier technique le plus lourd est souvent la refonte ou la montée en version des API Open Banking exposées aux tiers — notamment pour les banques mutualistes dont les API DSP2 sont parfois vieillissantes.

#PSP et établissements de paiement (EP)

Impact fort : nouvelles règles SCA, obligations de monitoring fraude, exigences de rapport renforcées à l'ACPR. Les EP qui opèrent en mode PISP doivent revoir leurs mécanismes de responsabilité contractuelle avec leurs partenaires bancaires.

#Fintechs AISP / agrégateurs de comptes

Impact modéré sur le modèle, fort sur l'implémentation : nouvelles exigences de consentement, limitations renforcées sur l'accès aux données, contraintes sur la durée de stockage. Si vous passez par Bridge, Tink ou Powens : l'essentiel de la conformité est leur responsabilité, mais vos contrats et votre UX doivent être mis à jour.

#E-commerçants et marketplaces

Impact indirect mais réel : si vous proposez du paiement par virement Open Banking (initiation de paiement PISP) à vos clients, vos conditions générales et votre flux de paiement doivent refléter les nouvelles protections consommateur de DSP3. Si vous êtes uniquement sur carte, l'impact est limité à la SCA améliorée côté PSP acquéreur.

#Fintechs Luxembourg (spécificité marché)

Luxembourg transposera DSP3 dans le même calendrier que la France (délai UE identique). La CSSF publie régulièrement ses positions sur les textes en attente de transposition — nous recommandons de suivre les circulaires CSSF parallèlement aux publications ACPR.

#Notre approche : audit de conformité DSP3 en 4 phases

#Phase 1 — Cartographie d'exposition (3 jours)

Identification de toutes les activités de votre organisation soumises à DSP3 : quels services de paiement, quels flux AISP/PISP, quelles API exposées à des tiers, quels volumes SCA. Output : matrice d'exposition DSP3 avec scoring par domaine.

#Phase 2 — Gap analysis réglementaire (5 jours)

Comparaison point par point entre votre état actuel (documentation, implémentations techniques, contrats tiers) et les exigences DSP3. On s'appuie sur notre grille de lecture des 340 articles DSP3 et des RTS EBA disponibles. Output : rapport de gap analysis avec priorisation des chantiers.

#Phase 3 — Plan de remédiation (2 jours)

Planification des chantiers techniques et organisationnels : refonte API, mise à niveau SCA, révision contrats agrégateurs, formation équipes conformité. Budget estimatif par chantier. Output : roadmap de conformité sur 12-18 mois.

#Phase 4 — Accompagnement mise en œuvre (variable)

Suivi opérationnel des chantiers : refonte API Open Banking, intégration nouveaux mécanismes SCA, formation équipes. Tarification au temps passé ou au forfait selon scope.

Tarification globale : audit complet phases 1 à 3 — 12 000 à400 000 € selon complexité (banque régionale : haut de fourchette, fintech AISP simple : bas de fourchette). Accompagnement mise en œuvre : 25 000 à720 000 € supplémentaires selon périmètre.

#Les 3 erreurs fréquentes dans les projets de conformité DSP3

Erreur 1 : attendre la publication des RTS EBA pour démarrer. Les normes techniques de niveau 2 précisent les modalités d'application, elles ne changent pas les obligations de fond. Votre architecture API, votre gouvernance de la fraude, votre cadre de consentement — ces sujets sont déjà clairs dans le texte DSP3. Attendre les RTS revient à perdre 12 à 18 mois.

Erreur 2 : traiter DSP3 comme un projet réglementaire isolé. DSP3 interagit directement avec DORA (cyber-résilience, tiers ICT), avec FIDA (données financières élargies), et avec NIS2 (sécurité des systèmes d'information). Un audit DSP3 standalone sans prise en compte de ces intersections produit une vue incomplète — et souvent des doublons de chantiers coûteux.

Erreur 3 : confier la conformité DSP3 uniquement à l'équipe juridique. Les nouvelles obligations API, SCA et monitoring fraude ont des composantes techniques profondes. Sans un expert tech qui lit le texte DSP3 et traduit les exigences en spécifications d'implémentation, vous obtiendrez soit une sur-conformité coûteuse, soit des trous dans la raquette sur les sujets techniques.

#Ce que DSP3 ne résout pas (limites à connaître)

DSP3 est une avancée réelle. Mais il faut avoir les yeux ouverts sur ses limites. Le texte ne règle pas le problème de la qualité des données bancaires exposées via API — les banques peuvent techniquement respecter les SLA de performance tout en exposant des données incomplètes ou peu structurées. L'interopérabilité réelle entre tous les systèmes bancaires européens restera imparfaite encore plusieurs années.

DSP3 ne couvre pas non plus les données financières non-bancaires (épargne, assurance, crédit) — c'est le périmètre de FIDA, dont les délais d'application sont plus longs (2027-2028). Si votre projet Open Finance inclut ces données, FIDA est le texte prioritaire à anticiper.

Enfin, DSP3 n'harmonise pas complètement les sanctions entre États membres. Les amendes ACPR pour non-conformité DSP3 en France pourraient différer de celles de la BaFin en Allemagne ou de la CSSF au Luxembourg — attendez les textes de transposition nationaux pour une cartographie précise des risques de sanction.