DSP2 / DSP3
#Définition DSP2 / DSP3
La DSP2 (Directive (UE) 2015/2366 sur les services de paiement dans le marché intérieur) est le cadre réglementaire européen qui a instauré l'open banking. Trois piliers fondateurs : (1) Ouverture APIs bancaires — les établissements de crédit sont tenus d'exposer des APIs standardisées permettant aux TPP (Third Party Providers) agréés par l'ABE d'accéder aux comptes clients avec consentement ; (2) SCA (Strong Customer Authentication) — obligation d'authentification multi-facteurs (au moins 2 éléments parmi : possession, connaissance, inhérence) pour les transactions de paiement en ligne et l'accès aux données de compte ; (3) Cadre AISP/PISP — deux nouvelles catégories de prestataires agréés : AISP (Account Information Service Provider = agrégateur de comptes) et PISP (Payment Initiation Service Provider = initiateur de virement depuis l'interface d'un tiers). Pour approfondir, consultez la page service Open Banking DSP3 Nehos.
Du point de vue technique, En France : transposée par ordonnance n° 2017-1252 et arrêtés techniques RTS EBA (EBA/RTS/2017/02). DSP3 (proposition COM/2023/366) : révision annoncée en juin 2023, adoptée EU Parlement 2025. Apports DSP3 vs DSP2 : (1) Renforcement SCA — exemptions réduites, meilleur encadrement des transactions récurrentes ; (2) Données enrichies — accès temps réel au solde IBAN, historique 24 mois, catégorisation transactions ; (3) Responsabilité fraude — réallocation de la charge de preuve en faveur du consommateur, obligation de remboursement immédiat en cas de fraude avérée ; (4) Harmonisation technique — standards APIs unifiés (Berlin Group NextGenPSD2 étendu) remplaçant les implémentations divergentes actuelles.
Calendrier : adoption définitive UE 2025, transposition nationale France/Belgique/Luxembourg 2026-2027. FIDA (Financial Data Access) : règlement parallèle couvrant l'open finance (assurance, épargne, crédit) — périmètre distinct de DSP3.
La compréhension fine de DSP2 / DSP3 différencie les équipes qui livrent des résultats de celles qui accumulent de la dette.
#DSP2 / DSP3 expliqué simplement
Vous connaissez Bankin', Linxo ou Lydia qui agrègent tous vos comptes bancaires en un seul endroit ? Ou encore PayFit qui vire les salaires directement depuis votre interface RH ? Ces services n'existaient pas avant la DSP2. La directive a littéralement obligé les banques à ouvrir leurs données (avec votre accord) à des applications tierces.
Avant, les banques gardaient jalousement vos données et refusaient que des tiers y accèdent. La DSP2 a mis fin à ce monopole de l'information bancaire en Europe. La DSP3 va plus loin : vos données bancaires seront accessibles en temps réel (plus de délais de 24-48h), avec plus d'informations (catégorisation automatique des dépenses, solde instantané), et votre banque devra vous rembourser plus vite en cas de fraude.
Pour les fintechs et les PSP (comme Stripe, Adyen, Mangopay), ce changement de réglementation n'est pas anodin : il faut mettre à jour les systèmes, revoir les APIs, former les équipes juridiques. C'est un chantier de plusieurs mois.
Imaginez que vous dirigez une PME ou une scale-up. La différence entre théorie et terrain ? Les chiffres. Et les chiffres, on les a.
#Cas d'usage concrets
Exemple de situation : fintech de crédit — mise en conformité DSP3 avec AISP enrichi — Exemple de situation : une fintech de crédit à la consommation agréée utilise des données AISP issues de la DSP2 pour scorer ses dossiers. Avec la DSP3, l'accès au solde en temps réel et à un historique plus long permet d'affiner le scoring.
Il faut adapter l'API d'agrégation au standard Berlin Group NextGenPSD2 v3 et mettre à jour les politiques de consentement RGPD + DSP3. La conformité se vérifie avec le superviseur (ACPR).
Exemple de situation : PSP marketplace — implémentation de la SCA DSP3 et gestion des exemptions — Exemple de situation : un PSP spécialisé marketplace B2B voit la DSP3 réduire les exemptions SCA sur les transactions récurrentes. Il cartographie les flux de paiement impactés, développe un déclenchement dynamique de la SCA (exemption si la transaction est à faible risque d'après un scoring temps réel) et intègre 3DS v2.3 pour les cas hors exemption. L'enjeu : maintenir le taux d'abandon du paiement malgré le renforcement de la SCA.
Exemple de situation : banque régionale — ouverture des API DSP3 et partenariats PISP — Exemple de situation : une caisse régionale souhaite tirer parti de sa conformité DSP3 par des partenariats avec des PISP. Elle audite ses API DSP2 existantes (Berlin Group NextGenPSD2 v2), identifie les écarts avec le standard DSP3, met à jour son portail développeurs et crée un programme partenaires PISP avec une sandbox dédiée.
#DSP2 / DSP3 chez Nehos Groupe
Chez Nehos, on part du terrain. Notre service Open Banking DSP3 Nehos couvre ce périmètre de A à Z.
Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : audit conformité FIDA Nehos.
#Termes associés
Ce terme s'inscrit dans un écosystème plus large.
Explorez chaque définition pour construire une vision complète du sujet.
Applications Concrètes
« Exemple de situation : une fintech de crédit à la consommation agréée utilise des données AISP issues de la DSP2 pour scorer ses dossiers. Avec la DSP3, l'accès au solde en temps réel et à un historique plus long permet d'affiner le scoring. Il faut adapter l'API d'agrégation au standard Berlin Group NextGenPSD2 v3 et mettre à jour les politiques de consentement RGPD + DSP3. La conformité se vérifie avec le superviseur (ACPR). »
« Exemple de situation : un PSP spécialisé marketplace B2B voit la DSP3 réduire les exemptions SCA sur les transactions récurrentes. Il cartographie les flux de paiement impactés, développe un déclenchement dynamique de la SCA (exemption si la transaction est à faible risque d'après un scoring temps réel) et intègre 3DS v2.3 pour les cas hors exemption. L'enjeu : maintenir le taux d'abandon du paiement malgré le renforcement de la SCA. »
« Exemple de situation : une caisse régionale souhaite tirer parti de sa conformité DSP3 par des partenariats avec des PISP. Elle audite ses API DSP2 existantes (Berlin Group NextGenPSD2 v2), identifie les écarts avec le standard DSP3, met à jour son portail développeurs et crée un programme partenaires PISP avec une sandbox dédiée. »
Questions & réponses
Questions fréquentes sur DSP2 et DSP3
La DSP2 a posé les fondations de l'open banking : obligation d'ouvrir les APIs bancaires aux TPP agréés, instauration de la SCA, création du cadre AISP/PISP. La DSP3 est une évolution, pas une révolution. Trois différences majeures : (1) Données enrichies — DSP3 étend l'accès aux données disponibles via API : solde IBAN en temps réel, historique de transactions jusqu'à 24 mois, catégorisation enrichie. En DSP2, certaines banques fournissaient des données minimales. DSP3 harmonise et enrichit le standard. (2) Protection fraude renforcée — DSP3 impose un remboursement plus rapide des victimes de fraude et réalloue la charge de la preuve côté banque/PSP. (3) SCA clarifiée — les cas d'exemption sont mieux encadrés, les transactions récurrentes et les paiements B2B ont des règles précisées. En synthèse : DSP2 = règles du jeu. DSP3 = règles du jeu améliorées.
La SCA (Strong Customer Authentication, ou Authentification Forte du Client en français) est l'obligation d'utiliser au moins deux facteurs d'authentification distincts parmi trois catégories : ce que vous savez (mot de passe, PIN), ce que vous possédez (téléphone, carte physique), ce que vous êtes (empreinte digitale, Face ID). Instaurée par la DSP2, elle se manifeste par les validations d'application bancaire que vous recevez lors de paiements en ligne. Avec DSP3 : les exemptions (petits montants, paiements de confiance, transactions B2B) sont mieux définies et harmonisées entre États membres — ce qui corrige les divergences d'interprétation constatées depuis 2018. Pour les PSP : l'enjeu est de maintenir un taux de conversion paiement élevé tout en respectant les nouvelles obligations, via une gestion fine des exemptions SCA basée sur le scoring de risque temps réel.
Deux textes distincts, souvent confondus car proposés simultanément par la Commission européenne en juin 2023. DSP3 (révision directive paiements) : périmètre limité aux comptes bancaires de paiement et aux services de paiement. Régule l'accès aux données de compte courant, les virements, les paiements. Vise les banques, les PSP, les fintechs paiement. FIDA (Financial Data Access, Règlement EU proposé parallèlement) : périmètre étendu à toutes les données financières — assurance vie, épargne, crédit immobilier, retraite complémentaire, investissements. Logique d'open finance vs open banking limité. Vise les assureurs, les asset managers, les banques de détail. Calendrier : DSP3 transposition 2026-2027. FIDA : adoption prévue 2026, application 2027-2028. Pour une fintech crédit : DSP3 + FIDA sont tous deux pertinents. Pour un agrégateur épargne-retraite : FIDA principalement.
Calendrier synthétique DSP3. Juin 2023 : publication des propositions législatives par la Commission européenne (PSD3 + PSR — Payment Services Regulation). Fin 2023 — début 2024 : consultations Parlement européen et Conseil. 2024-2025 : trilogues Commission / Parlement / Conseil. 2025 : adoption définitive par le Parlement européen (avec modifications). 18-24 mois après adoption : délai de transposition nationale. France, Belgique, Luxembourg : transposition attendue entre mi-2026 et fin 2027 selon rythme parlementaire. Application effective : les PSP et banques auront un délai supplémentaire pour adapter leurs systèmes techniques après publication des RTS ABE (Autorité Bancaire Européenne). Recommandation Nehos : anticiper dès maintenant — les chantiers de mise à jour API et SCA prennent plusieurs mois selon la taille du système.
Six obligations principales pour les PSP soumis à DSP3. (1) APIs conformes NextGenPSD2 v3 (Berlin Group) : mise à jour des endpoints d'accès aux comptes pour fournir les nouvelles données enrichies (solde temps réel, historique 24 mois). (2) SCA mise à jour : adaptation des flux d'authentification aux nouvelles règles d'exemption, intégration 3DS v2.3. (3) Remboursement fraude accéléré : processus interne de traitement des réclamations fraude à revoir (délais raccourcis DSP3). (4) Documentation technique renforcée : sandbox disponible pour TPP tiers, SLA de disponibilité API opposables. (5) Gestion consentement RGPD + DSP3 : alignement des politiques de consentement sur les nouvelles exigences d'accès aux données. (6) Reporting ABE/ACPR : notifications d'incidents opérationnels et de fraude selon nouveaux seuils. Pour une fintech de taille moyenne : prévoir plusieurs mois de chantier ; le coût dépend de la complexité du stack technique et se chiffre après un audit des écarts.
Impact significatif sur quatre points. (1) Initiation de virements PISP enrichie : DSP3 clarifie et étend le périmètre des paiements pouvant être initiés via PISP, y compris virements instantanés SCT Inst — ce qui ouvre de nouveaux cas d'usage B2B (paiement fournisseur depuis ERP via PISP sans interface bancaire). (2) Accès données enrichies pour scoring crédit B2B : les données de compte DSP3 (solde, historique 24 mois, IBAN confirmé) permettent des évaluations de risque crédit plus précises pour le B2B Pay Later. (3) Réconciliation comptable automatisée : l'accès temps réel aux données bancaires via AISP DSP3 alimente directement les logiciels comptables (Pennylane, Sage, QuickBooks) pour une réconciliation automatique sans export manuel. (4) Confirmation IBAN : DSP3 introduit la vérification de concordance IBAN/nom du bénéficiaire avant virement — réduit drastiquement la fraude au virement bancaire B2B.