La DSP2 (Directive sur les Services de Paiement 2) est entrée en vigueur en 2018. L’authentification forte (SCA) s’est imposée, les APIs d’Open Banking ont proliféré, des centaines de fintechs se sont positionnées sur l’agrégation et l’initiation de paiements. Trois ans après les échéances réglementaires, il est temps de faire un bilan honnête : qu’est-ce qui a tenu ses promesses ? Qu’est-ce qui a échoué ? Et vers quoi va-t-on ?
Ce qui a fonctionné
L’agrégation de comptes : un marché qui existe
L’agrégation de comptes (AISP, Account Information Service Provider) est probablement le cas d’usage Open Banking qui a trouvé le plus de traction réelle.
Les plateformes de gestion de finances personnelles (Bankin’, Linxo, Fintecture) ont construit des bases d’utilisateurs significatives. Plus intéressant : les usages B2B ont décollé, scoring crédit alternatif basé sur les flux bancaires, vérification de revenus pour les demandes de crédit, analyse de trésorerie pour les PME.
Quelques acteurs ont réussi à transformer l’agrégation en vrai avantage compétitif : les fintechs de crédit qui peuvent scorer un emprunteur en temps réel sur la base de ses relevés bancaires ouvrent des marchés auxquels les banques traditionnelles n’accédaient pas (travailleurs indépendants, primo-accédants sans historique, TNS).
L’authentification forte : une sécurité améliorée malgré la friction
L’obligation de SCA (Strong Customer Authentication) a mécaniquement réduit la fraude sur les paiements en ligne. Les chiffres sont sans ambiguïté : la fraude au paiement par carte sur les transactions soumises à SCA a diminué significativement.
Le prix à payer est la friction. L’obligation de rediriger l’utilisateur vers l’application de sa banque pour valider un paiement a créé des taux d’abandon non négligeables, particulièrement sur mobile. Mais c’est un coût que la filière a globalement accepté comme nécessaire.
Ce qui coince encore
L’initiation de paiements : une promesse partiellement tenue
L’initiation de paiements (PISP, Payment Initiation Service Provider) était censée révolutionner les paiements en ligne en permettant de payer directement depuis son compte bancaire, sans passer par les réseaux carte. La promesse : des frais réduits, une instantanéité améliorée, une dépendance moindre aux schémas de carte.
La réalité est plus nuancée. Les APIs PISP des banques sont hétérogènes en qualité, en disponibilité et en performance. Le taux de réussite moyen d’une initiation de paiement varie considérablement selon la banque du payeur. Certains établissements maintiennent des APIs qui échouent régulièrement ou ont des temps de réponse incompatibles avec une expérience utilisateur acceptable.
Résultat : les marchands qui ont investi sur l’Open Banking comme alternative aux cartes ont souvent dû maintenir les deux canaux en parallèle, ce qui annule une partie des gains économiques attendus.
La qualité des APIs : un problème structurel non résolu
La DSP2 a imposé des obligations d’ouverture, pas des standards d’implémentation. Le résultat : une fragmentation technique massive. Chaque banque a implémenté ses APIs différemment : structures de données variantes, gestion des erreurs hétérogène, authentification non standardisée.
Les agrégateurs ont dû construire des couches d’abstraction et de normalisation dont la maintenance représente une charge significative. Pour les petits acteurs qui veulent intégrer directement sans passer par un agrégateur, le travail d’intégration est prohibitif.
Le Berlin Group et STET ont fourni des frameworks de standardisation, mais l’adoption est incomplète. La promesse d’une API unique pour accéder à toutes les banques européennes reste une aspiration plutôt qu’une réalité.
L’expérience utilisateur de la redirection : un frein persistant
Le flow d’authentification SCA implique une redirection vers l’application ou le site de la banque. Sur desktop, c’est gérable. Sur mobile, c’est souvent une suite de redirections qui casse le contexte applicatif, désoriente l’utilisateur et génère des abandons.
Les banques ont des délais d’implémentation des “decoupled authentication” (authentification hors bande, via notification push) très variables. Cette méthode permettrait de garder l’utilisateur dans l’interface du tiers sans redirection, mais elle n’est pas encore universellement disponible.
PSD3 et le règlement sur les paiements : ce qui change
La Commission européenne a publié ses propositions de PSD3 (révision de la DSP2) et d’un nouveau règlement sur les services de paiement. Les principales évolutions :
Standardisation des APIs
PSD3 impose une standardisation plus poussée des interfaces d’accès. L’objectif est de réduire la fragmentation qui a nui à l’Open Banking depuis son lancement. Des “interfaces d’accès dédiées” avec des spécifications techniques minimales obligatoires.
Open Finance : l’extension du périmètre
La révision élargit le périmètre au-delà des comptes de paiement : assurances, investissements, crédits, épargne. C’est le passage à l’Open Finance, un écosystème dans lequel les prestataires peuvent accéder à l’ensemble des données financières d’un client avec son consentement.
Paiements instantanés comme défaut
Le règlement sur les paiements instantanés impose aux prestataires de paiement de proposer des virements instantanés (SEPA Instant Credit Transfer) au même prix que les virements standard. C’est un changement majeur pour l’initiation de paiements : si le virement instantané devient la norme, les avantages de l’Open Banking sur les délais de règlement deviennent une réalité quotidienne.
Ce que ça signifie pour votre architecture
Si vous êtes déjà intégré DSP2
Deux priorités :
- Surveiller l’évolution de vos SLA de connexion aux APIs bancaires, la pression réglementaire va forcer les banques à améliorer leur qualité de service
- Préparer la migration vers les nouveaux standards PSD3 quand ils seront définitifs (publication attendue 2025-2026 pour la directive, transposition 2027-2028)
Si vous intégrez aujourd’hui
Passer par un agrégateur (Bridge, Powens, Token.io, Tink) plutôt que d’intégrer directement les APIs bancaires. Le coût de la couche d’abstraction est largement compensé par l’économie de maintenance et la meilleure couverture.
Concevoir votre architecture d’intégration pour être indépendant du provider d’agrégation : l’interface avec votre système doit abstraire le prestataire sous-jacent pour pouvoir en changer sans refonte.
Pour l’Open Finance
Anticiper l’extension du périmètre. Les systèmes qui seront bien positionnés pour l’Open Finance sont ceux qui ont un modèle de consentement utilisateur flexible et traçable, pas ceux qui ont hardcodé des logiques pour les seuls comptes de paiement.
Conclusion
L’Open Banking n’a pas tenu toutes ses promesses initiales. La fragmentation des APIs et la friction de la SCA ont limité l’adoption de certains cas d’usage. Mais il a créé des usages réels, notamment sur l’agrégation et le scoring alternatif, qui n’existaient pas avant.
PSD3 et le règlement sur les paiements vont corriger les principaux défauts structurels. Les acteurs qui ont investi tôt dans l’Open Banking, malgré ses imperfections, sont mieux positionnés pour tirer parti de la prochaine vague.
Vous avez des intégrations Open Banking à faire évoluer ou à concevoir ? Parlons-en.