Définition
Le PSR (Payment Services Regulation, ou RSP pour règlement sur les services de paiement) est le règlement européen que la Commission a proposé le 28 juin 2023 avec la DSP3, sous la référence COM(2023) 367. La DSP3 garde l'agrément et la supervision des établissements. Le PSR reprend le reste de la DSP2 : les droits et obligations liés aux paiements, l'accès des TPP aux comptes, la SCA et la lutte contre la fraude.
Les numéros d'articles cités sur cette page sont ceux du texte de compromis du 17 avril 2026 (Conseil, doc. 8221/26). Cette numérotation est provisoire, et la relecture des juristes-linguistes la changera probablement avant la publication au Journal officiel.
Pourquoi un règlement
La DSP2 est une directive. Chaque État l'a transposée à sa façon, et les banques comme les TPP travaillent avec des règles nationales un peu différentes. Un règlement s'applique tel quel dans tous les États membres, sans transposition. Les autorités nationales restent chargées du contrôle et doivent faire retirer les obstacles qu'un TPP leur signale (art. 48), mais le texte qu'elles appliquent est le même partout.
Où en est le texte
Le PSR n'est pas adopté et n'est pas publié au Journal officiel. Sa procédure, la 2023/0210(COD), suit le même chemin que celle de la DSP3.
| Date | Étape |
|---|---|
| 28 juin 2023 | Proposition de la Commission |
| 23 avril 2024 | Position du Parlement en première lecture |
| 18 juin 2025 | Mandat de négociation du Conseil |
| 27 novembre 2025 | Accord provisoire en trilogue |
| 17 avril 2026 | Texte de compromis final diffusé par le Conseil |
| 22 avril 2026 | Confirmation par le Coreper |
| 5 mai 2026 | Approbation par la commission ECON du Parlement |
| À venir | Position du Conseil en première lecture, puis vote du Parlement en deuxième lecture |
Au 4 octobre 2026, l'Observatoire législatif du Parlement indique une séance plénière le 14 décembre 2026, à titre indicatif. Le texte agréé n'existe pour l'instant qu'en anglais.
Comment se calcule l'application
L'article 112 ne donne aucune date calendaire. Le règlement entre en vigueur le vingtième jour après sa publication au Journal officiel. On note cette date T.
- À T, seuls les articles 85a (dispense de SCA pour certains virements récurrents) et 108a (paiements en jetons de monnaie électronique) s'appliquent.
- À T + 21 mois, tout le reste du règlement s'applique et la DSP2 est abrogée (art. 48 de la DSP3).
- À T + 27 mois, la vérification du bénéficiaire étendue à tous les virements (art. 50) et la responsabilité qui l'accompagne (art. 57) s'appliquent.
Jusqu'à T + 21 mois, la DSP2 et le règlement délégué 2018/389 sur la SCA et la communication restent la règle. L'EBA doit remettre ses nouveaux projets de RTS sur la SCA et les interfaces douze mois après l'entrée en vigueur (art. 89). Le texte ne dit pas ce que devient le règlement 2018/389 après T + 21 mois si ces RTS ne sont pas encore applicables.
L'open banking, articles 33 à 48
L'interface dédiée devient obligatoire pour toute banque qui propose un compte de paiement accessible en ligne (art. 35(1)). Le mécanisme de secours par l'interface client, que les RTS actuels imposent sauf exemption, disparaît. Il reste deux portes de sortie. L'autorité peut, sur demande de la banque, l'autoriser à exposer son interface client à la place ou la dispenser d'interface (art. 39). Un TPP peut aussi passer « exceptionnellement » par une autre interface sûre et efficace (art. 45(1)), avec l'accord de la banque d'après le considérant 68a.
Le texte ne fixe aucun seuil chiffré de disponibilité, de latence ou de taux d'erreur. Il impose la parité avec l'interface client pour le temps de réponse, la disponibilité et la performance (art. 36(1)(c), 37(1) et 38). L'interface est présumée indisponible après cinq requêtes consécutives qui reçoivent une erreur serveur ou restent sans réponse sous 30 secondes. Une maintenance planifiée s'annonce un mois à l'avance et tombe normalement entre 0 h et 6 h, heure locale de la banque (art. 38). La banque publie chaque trimestre ses statistiques de disponibilité et de performance, à côté de celles de son interface client (art. 35(5)). L'EBA doit en préciser le format et le délai de rétablissement après une panne dans un RTS attendu neuf mois après l'entrée en vigueur (art. 38(5)).
Un changement des spécifications de l'interface se publie au moins deux mois avant sa mise en production, contre trois mois aujourd'hui (art. 35(4)).
La banque doit intégrer à son interface un tableau de bord des consentements donnés aux AISP, et aux PISP pour des paiements multiples ou récurrents (art. 43). Le client y voit le TPP, le compte, la finalité, la durée et les catégories de données. Il peut retirer un accès à tout moment, le rétablir dans les 48 heures et consulter l'historique pendant deux ans. Le TPP transmet à la banque les informations de chaque nouveau consentement, et la banque prévient le TPP de tout retrait, dans les deux cas « sans retard injustifié ». Le texte n'impose pas de temps réel.
L'article 44 liste douze obstacles interdits, et la liste n'est pas limitative. On y trouve par exemple le fait de demander plus de SCA que dans le canal direct de la banque, d'ajouter des étapes dans un parcours en redirection ou découplé, ou d'exiger deux SCA dans un même parcours d'initiation.
Côté AISP, la banque sert les requêtes que le client soit présent ou non (art. 41). La limite de quatre accès par jour sans le client, qui figure dans les RTS actuels, n'apparaît pas dans le compromis.
Côté PISP, l'article 36(4) fixe un minimum : ordres permanents, paiements à date future, paiements à plusieurs bénéficiaires, vérification du nom du titulaire du compte avant l'initiation. Le PISP reçoit une réponse oui ou non sur la disponibilité des fonds (art. 36(5)). Le service autonome de confirmation de fonds pour les émetteurs de cartes (CBPII, article 65 de la DSP2) est supprimé.
L'accès réglementé reste sans contrat avec la banque (art. 34). Une banque peut proposer des API payantes pour des services qui vont au-delà du règlement, et le considérant 56 cite les paiements récurrents variables.
La SCA, articles 85 à 89
La définition de la SCA ne change pas (art. 3(35)). La banque n'applique sa SCA qu'au premier accès d'un AISP donné, sauf soupçon de fraude (art. 86(3)). Ensuite, c'est l'AISP qui applique une SCA quand le client consulte ses données chez lui, au moins tous les 180 jours, avec sa propre SCA ou celle de la banque (art. 86(4)).
Le PISP choisit la procédure d'authentification quand la banque en propose plusieurs (art. 36(4)(ha)). Les exemptions sont renvoyées aux RTS de l'EBA, qui en fixera les critères (art. 85(11)). Le compromis ne contient aucun seuil en euros. Un PSP doit enfin proposer gratuitement au moins un moyen de SCA adapté à chaque client, et ne peut pas faire dépendre la SCA de la possession d'un smartphone, sauf si le client a choisi un service uniquement mobile (art. 88).
Fraude et remboursement
L'article 59 crée un seul nouveau droit au remboursement. Il vise le consommateur manipulé par quelqu'un qui se fait passer pour sa propre banque, en utilisant des canaux attribués à cette banque (numéro, adresse e-mail, site, application, y compris leurs copies frauduleuses). La banque rembourse le montant total si le client l'a prévenue sans retard et a porté plainte. Elle a quinze jours ouvrables pour rembourser ou motiver un refus. Les autres fraudes par manipulation (faux placement, arnaque sentimentale, fausse facture, faux policier) ne sont pas couvertes par ce droit.
Les PSP doivent participer à des dispositifs de partage de données de fraude (art. 83a). La vérification du bénéficiaire s'étend à tous les virements, y compris hors euro, à T + 27 mois (art. 50). Le délai pour contester une opération non autorisée passe de 13 à 18 mois (art. 54).
Sanctions
Pour les manquements au chapitre open banking et aux articles 85 à 87 sur la SCA, les États membres doivent prévoir une amende dont le maximum atteint au moins 10 % du chiffre d'affaires annuel pour une personne morale, et au moins 3 millions d'euros pour une personne physique (art. 97). Des astreintes journalières sont possibles pendant six mois au plus (art. 98).
Ce qui reste à écrire
Le compromis confie à l'EBA onze normes et orientations pour le PSR et sept pour la DSP3, d'après un décompte fait sur les textes. Fin septembre 2026, l'EBA n'avait publié ni liste, ni feuille de route, ni consultation. Les premiers projets sont dus neuf mois après l'entrée en vigueur (statistiques des interfaces), puis douze mois (SCA, exemptions, standards de communication) et dix-huit mois (données sur l'accès des TPP à remettre aux autorités, art. 48(8)). Le texte ne parle ni de certificats eIDAS ni d'un standard d'API particulier. L'identification des TPP sera précisée par ces RTS (art. 89), et d'ici là les certificats qualifiés du règlement 2018/389 restent la règle.
PSR vs DSP3 : qui contient quoi
- La DSP3 (directive) porte l'agrément, le capital, la protection des fonds et la supervision des établissements de paiement, émetteurs de monnaie électronique compris.
- Le PSR (règlement) porte les règles d'exécution des paiements : information des clients, open banking, SCA, fraude, responsabilités et remboursements.
Dans l'écosystème PSD2
Pour une banque ou un TPP, le PSR est le texte à lire. Les articles 35 à 44 et 85 à 89 décrivent déjà la plupart des obligations d'interface. Ce qui manque est connu : l'identification des TPP, les seuils d'exemption de SCA et le format des statistiques.
Exemples concrets
- Une banque qui maintient aujourd'hui une interface de secours pourra la fermer. Elle devra en revanche publier chaque trimestre la disponibilité et la performance de son interface dédiée, comparées à celles de son site et de son application.
- Un agrégateur ne renverra plus ses clients vers la banque pour une nouvelle SCA tous les 180 jours. Il appliquera lui-même une SCA quand le client consulte ses comptes chez lui. Côté banque, les durées de vie de tokens et de consentements calées sur la règle actuelle sont à revoir.
- Un client qui retire l'accès d'un agrégateur depuis le tableau de bord de sa banque peut le rétablir pendant 48 heures. Il faut donc une API dans les deux sens entre banque et TPP. STET 1.6.3 n'a aujourd'hui ni statut de consentement ni notification pour cet échange.
- Un client appelé par un faux conseiller qui affiche le numéro de sa banque, et qui fait un virement sur ses instructions, pourra demander le remboursement intégral s'il a prévenu sa banque et porté plainte. Le même client victime d'un faux placement en cryptos n'a pas ce droit au titre du PSR.
- Un PISP pourra programmer un virement permanent ou payer plusieurs bénéficiaires dans toutes les banques, puisque l'article 36(4) en fait un minimum.