Fraude APP : comment DSP3 et le règlement PSR inversent la charge de responsabilité sur les prestataires de paiement européens

La fraude APP — Authorized Push Payment — est la forme de fraude en paiement qui connaît la plus forte croissance en Europe. Elle consiste à manipuler une victime pour qu’elle initie elle-même un virement vers un compte frauduleux. DSP3 et le règlement PSR, dont la période de transition court sur 21 mois à compter de leur entrée en vigueur début 2026, changent fondamentalement la règle du jeu : c’est désormais le prestataire de paiement qui est présumé responsable si les mécanismes de vérification n’ont pas été mis en place.

Qu’est-ce que la fraude APP et pourquoi elle explose

La fraude dite APP — Authorized Push Payment, ou fraude au paiement push autorisé — est une technique dans laquelle le fraudeur ne pirate pas les systèmes bancaires. Il manipule la victime elle-même, généralement par usurpation d’identité via SMS, appel téléphonique ou e-mail, pour la convaincre d’initier un virement vers un compte qu’il contrôle. Parce que c’est la victime qui a techniquement « autorisé » le paiement, les mécanismes de protection existants — notamment la responsabilité des prestataires en cas de transaction non autorisée — ne s’appliquaient pas sous DSP2.

Le résultat est prévisible : la fraude APP est devenue la forme de fraude en paiement à la croissance la plus rapide en Europe, précisément parce qu’elle exploite un angle mort réglementaire. Les pertes liées à la fraude financière au sens large sont projetées à 40 milliards de dollars à l’échelle mondiale en 2026, avec une hausse de plus de 70% des tentatives de fraude en temps réel depuis 2020. (Sources : MEXC FinTech Security 2026, Observatoire de la sécurité des moyens de paiement / Banque de France.) Ce contexte explique pourquoi la lutte contre la fraude APP a été placée au cœur des priorités de DSP3 et du règlement PSR.

Sous DSP2, si vous avez été trompé et avez vous-même effectué le virement, vous étiez présumé avoir autorisé le paiement. Vous supportiez donc la perte. DSP3 et PSR changent cette logique : si le prestataire n’a pas mis en place les mécanismes de vérification requis, c’est lui qui est présumé responsable. (Source : Powens, European Commission, 2026.)

Ce que DSP3 et PSR imposent concrètement aux PSP

Le premier mécanisme clé est la vérification IBAN/nom — dite VoP (Verification of Payee) — qui devient obligatoire avant l’exécution de tout virement. Avant DSP3, cette vérification n’existait que de manière facultative dans quelques banques pionnières. Désormais, tout prestataire de services de paiement doit, avant d’exécuter un virement, vérifier que l’IBAN saisi correspond bien au nom du bénéficiaire enregistré dans la base du prestataire destinataire. (Source : Powens, European Commission.)

Le deuxième mécanisme est le remboursement obligatoire en cas de fraude APP, sous réserve que la victime n’ait pas fait preuve de négligence grave. Cette inversion de la présomption est structurellement majeure : elle transfère le risque financier de la fraude du client vers le prestataire. Ce dernier a donc désormais un intérêt économique direct à investir dans des outils de détection de fraude en temps réel et dans des mécanismes de prévention — non plus pour des raisons de conformité, mais pour protéger ses propres marges.

Le troisième mécanisme est le partage d’information entre prestataires de paiement. DSP3 et PSR imposent aux PSP d’échanger des informations sur les tentatives de fraude identifiées, afin de permettre la détection en temps réel de comportements suspects à l’échelle du système. C’est un changement culturel aussi profond que réglementaire : des acteurs en concurrence directe doivent partager des données de sécurité qui constituent aussi de l’information stratégique. (Source : Powens, European Commission.)

Les implications opérationnelles pour les fintechs françaises

La période de transition de 21 mois à compter de l’entrée en vigueur officielle — attendue entre fin T1 et début T2 2026 — place la date d’application effective autour de la fin 2027. Mais les fintechs qui attendent l’échéance pour agir prendront un retard significatif. La mise en place des API de vérification IBAN/nom suppose des accords avec les prestataires destinataires — une infrastructure qui n’existe pas encore dans un format standardisé à l’échelle européenne et dont la construction prend du temps.

Pour les fintechs de paiement dont le modèle économique repose sur la rapidité d’exécution — paiements instantanés, initiation de virements, solutions B2B — l’obligation de vérification IBAN/nom ajoute une étape dans le tunnel de paiement. Cette étape doit être architecturée de manière à ne pas dégrader l’expérience utilisateur. Les acteurs qui réussiront cette transition sont ceux qui auront intégré la vérification comme un signal de confiance pour l’utilisateur plutôt que comme une friction supplémentaire.

Ce que cela dit du positionnement concurrentiel

La responsabilité accrue des PSP en matière de fraude APP crée une barrière à l’entrée supplémentaire pour les nouveaux acteurs du paiement. Les systèmes de détection de fraude en temps réel, les modèles de machine learning entraînés sur des historiques de transactions, les partenariats avec des fournisseurs de données comportementales : ces investissements sont coûteux et bénéficient aux acteurs qui ont déjà une masse critique de données. C’est une dynamique qui favorise la consolidation — exactement ce que nous observons dans l’écosystème fintech européen depuis 18 mois.