PSD3, le règlement sur les services de paiement et FiDA : la refonte européenne des paiements

Trois textes réécrivent les paiements européens en même temps, et on les présente souvent comme un seul et même chantier alors qu'ils ne le sont pas. PSD3 et le règlement sur les services de paiement remplacent la DSP2. FiDA, lui, étend l'accès aux données bien au-delà des paiements, à tout le reste des services financiers. Champs d'application, calendriers, degrés de certitude : tout les sépare.

Si vous développez des produits de paiement, des intégrations bancaires, des logiciels comptables ou quoi que ce soit qui consomme des API d'open banking, c'est le dossier qui pèsera le plus sur votre architecture dans la seconde moitié de la décennie.

Où en est chacun d'eux

PSD3 et le PSR. Le Conseil et le Parlement sont parvenus à un accord politique provisoire le 27 novembre 2025. C'est le texte le plus avancé. L'adoption formelle viendra ensuite, suivie d'une période de transposition et d'application. Une application réaliste se situe plutôt en fin de décennie.

FiDA. Le dossier le plus tourmenté de la législation financière européenne. Proposé aux côtés de PSD3 en juin 2023, presque abandonné, puis relancé. Les négociations en trilogue se sont enlisées début 2026 avant de repartir. Une application réaliste s'échelonnerait entre 2027 et 2030, et le champ définitif reste très incertain.

La distinction entre directive et règlement compte. PSD3 est une directive : les États membres la transposent, et l'agrément comme la supervision varieront donc d'un pays à l'autre. Le PSR est un règlement : il s'applique directement et uniformément. Les règles de conduite, les dispositions sur la fraude et les exigences d'open banking figurent pour l'essentiel dans le règlement, ce qui est une bonne nouvelle pour quiconque a subi les 27 transpositions nationales de la DSP2.

Ce que changent PSD3 et le PSR

La responsabilité en cas de fraude se déplace

C'est le changement majeur. La DSP2 répartissait la responsabilité des opérations non autorisées, mais laissait pour l'essentiel à la charge de la victime la fraude au virement autorisé, celle où l'on manipule la victime pour qu'elle effectue elle-même le paiement.

Le nouveau cadre étend la responsabilité dans des cas précis, notamment la fraude par usurpation, quand un escroc se fait passer de façon crédible pour la banque ou pour un autre tiers de confiance. Les prestataires de services de paiement deviennent responsables dans des situations définies.

Ce que cela change côté ingénierie : la détection de fraude cesse d'être un centre de coûts destiné à limiter vos propres pertes pour devenir un instrument de maîtrise de votre responsabilité. Le calcul de rentabilité d'un investissement en détection change du tout au tout quand c'est vous qui encaissez la perte.

L'authentification forte du client évolue

L'authentification forte s'applique depuis 2019 et a produit son lot de frictions, d'exemptions et de contournements. Le nouveau cadre retouche le régime : gestion des exemptions clarifiée, obligations d'accessibilité de l'authentification pour les utilisateurs qui ne peuvent pas se servir d'un smartphone, et dispositions visant l'exemption fondée sur l'analyse du risque de transaction.

Ce que cela change : si vous avez mis en place votre authentification forte en 2019 sans jamais y revenir, prévoyez une refonte. L'accessibilité de l'authentification, en particulier, est une exigence bien réelle qui recoupe la directive européenne sur l'accessibilité.

La correspondance IBAN et nom s'étend

L'obligation de vérification du bénéficiaire apparue avec le règlement sur les paiements instantanés en octobre 2025 est étendue et généralisée par le nouveau cadre : elle couvrira davantage de types de paiement, et plus seulement les virements en euros.

Ce que cela change : le traitement des quatre résultats que vous avez mis en place pour les paiements instantanés devient la règle générale, et non plus un cas particulier.

La performance des interfaces d'open banking devient sanctionnable

La DSP2 obligeait les banques à fournir des interfaces d'accès. Elle n'imposait en revanche aucune obligation réelle de qualité. Résultat : des années de plaintes des prestataires tiers sur les indisponibilités, les données incohérentes, les réauthentifications abusives et des interfaces dédiées moins performantes que le canal grand public.

Le PSR y répond par des exigences de performance, une interdiction des obstacles à l'accès et la suppression de l'obligation d'interface de repli, en contrepartie de vraies normes de qualité sur l'interface dédiée.

Ce que cela change : si vous consommez des API d'open banking, le plancher de fiabilité remonte. Si vous en fournissez, la barre passe de l'existence à la performance.

Les régimes établissement de paiement et monnaie électronique fusionnent

Deux catégories d'agrément n'en font plus qu'une. Pour la plupart des acteurs, cela simplifie les choses. Pour ceux qui détiennent les deux, ou dont le modèle économique se tenait précisément d'un côté de la frontière, il y aura du travail de transition.

Ce que changerait FiDA

C'est FiDA qui pèserait le plus lourd sur les architectures, s'il arrivait tel qu'il a été proposé, car il étend le modèle de l'open banking à l'ensemble des services financiers.

Aujourd'hui, l'accès réglementé aux données se limite aux comptes de paiement. FiDA l'étendrait à l'épargne, aux comptes-titres, aux retraites, aux crédits immobiliers ou encore à l'assurance non-vie, en créant au passage une catégorie réglementée inédite : le prestataire de services d'information financière.

Le mécanisme diffère de la DSP2 sur un point décisif. La DSP2 imposait l'accès. FiDA s'articule autour de dispositifs de partage de données financières : des accords négociés par le marché entre détenteurs et utilisateurs de données, qui fixent eux-mêmes les normes techniques et le modèle de rémunération. Les détenteurs pourraient facturer les utilisateurs, alors qu'avec la DSP2 l'accès est gratuit.

Pourquoi cela compte : c'est la réponse au principal grief des banques contre la DSP2, à savoir qu'elles devaient construire et maintenir des interfaces dont d'autres tiraient profit sans rien financer. Cela veut dire aussi que les conditions commerciales se négocient au lieu d'être fixées par la loi, ce qui apporte son lot d'incertitudes.

Pourquoi cela a coincé : le champ est immense, le modèle de rémunération est contesté, le secteur de l'assurance s'est fermement opposé à son inclusion, et l'intérêt économique saute moins aux yeux que pour les paiements. Le texte a bien failli être retiré.

Ce que cela change si vous développez du logiciel financier

Si vous consommez des API d'open banking

La vie s'améliore, lentement. Obligations de performance, interdiction des obstacles et règles de réauthentification plus claires répondent aux griefs opérationnels qui rendent l'agrégation si pénible. Attendez-vous à une amélioration inégale selon les banques.

Si FiDA aboutit, le gisement de données accessible s'élargit considérablement, mais il faudra vous attendre à payer l'accès et à adhérer à un dispositif plutôt qu'à vous appuyer sur un droit réglementaire.

Si vous fournissez des services de paiement

Le déplacement de la responsabilité en cas de fraude est le sujet à anticiper. Chiffrez votre exposition sous le nouveau régime avant qu'il ne s'applique : la réponse détermine le niveau d'investissement en détection qui se justifie.

L'authentification est à reprendre, à la fois pour les changements d'exemption et pour l'accessibilité. L'extension de la correspondance de nom réclame le même traitement à quatre états que les paiements instantanés.

Si vous développez des intégrations comptables, de trésorerie ou ERP

Vous êtes en aval de tout cela. Concrètement, les données que vous pouvez récupérer deviennent plus larges et plus fiables, et les allers-retours d'authentification se normalisent. Le principal risque est de coder en dur les bizarreries propres à chaque banque, celles-là mêmes que les nouvelles règles de performance vont faire disparaître.

Si vous développez un tunnel d'achat

Moins d'effets directs qu'on ne pourrait le croire. Ce qui vous atteint, ce sont les ajustements sur l'authentification et le mouvement de fond vers les paiements de compte à compte, qu'incarnent aussi Wero et l'euro numérique.

Le point d'architecture qui mérite d'être posé

Les trois textes, plus le règlement sur les paiements instantanés, plus Wero, plus l'euro numérique, plus le portefeuille européen d'identité numérique, vont tous dans le même sens : en Europe, les paiements et les données financières s'orientent vers des rails de compte à compte, une identité vérifiée au niveau de l'infrastructure, des interfaces normalisées et une tarification encadrée.

La conséquence architecturale est la même dans tous les cas. Les systèmes qui traitent un moyen de paiement, une source de données ou un mécanisme d'authentification comme un connecteur interchangeable absorbent tout cela à moindre coût. Ceux dont les spécificités sont disséminées dans tout le code paient chaque changement séparément.

S'il ne fallait retenir qu'une chose : c'est exactement le même travail d'abstraction qui sert pour chacun de ces textes. Le faire une fois pour Wero suffit à le rentabiliser, et tout ce qui vient après ne coûte presque plus rien.

Le calendrier, sans détour

PSD3 et le PSR font l'objet d'un accord politique, le fond est donc largement arrêté. L'application reste à plusieurs années de là, et les normes techniques qui détermineront ce que vous développerez vraiment ne viendront qu'après l'adoption. Se lancer maintenant serait prématuré. Savoir où l'on va ne l'est pas.

FiDA, lui, reste réellement incertain. Il peut arriver avec un champ large, arriver nettement rogné, ou ne jamais arriver. Développer dès aujourd'hui en visant FiDA serait imprudent. Concevoir votre modèle de données pour qu'ajouter une nouvelle source de données financières relève du paramétrage et non d'un projet est prudent de toute façon.

Où cela s'inscrit

La file législative complète figure dans notre panorama législatif numérique de l'UE. Les règles de paiement déjà applicables sont traitées dans notre guide des paiements instantanés et de la vérification du bénéficiaire, et l'ensemble de la surface de conformité dans notre guide de la conformité numérique européenne 2026.

Obtenir de l'aide

Nous développons des intégrations de paiement, de la connectivité bancaire et des systèmes financiers pour des entreprises actives dans toute l'Europe, y compris l'agrégation open banking, le rapprochement et ce travail sur les machines à états dont dépend la fiabilité des flux de paiement.

Si votre couche de paiement a besoin du travail d'abstraction que tout cela finit par payer, ou si vous voulez une lecture de votre exposition à la responsabilité pour fraude sous le nouveau régime, écrivez à office@c9group.dev. Vous trouverez plus de détails sur notre travail européen sur la page entrée sur le marché européen.

Nous sommes ingénieurs, pas conseils réglementaires. Les questions d'agrément et les prises de position sur la responsabilité relèvent de vos conseils juridiques.