Absence de communication et parcours SCA indigne : les TPP en attendent plus des API bancaires

Absence de communication et parcours SCA indigne :  les TPP en attendent plus des API bancaires Les TPP regrettent notamment la disparité des performances des API mais saluent dans le même temps les efforts consentis par les banques.

Présentée par la Commission européenne en juin 2023 et actuellement examinée à Bruxelles, la troisième directive sur les services de paiement, dites DSP 3, souhaite moderniser la DSP 2, la directive qui met en place l'open banking. Suite à cette dernière, les banques ont dû développer deux types d'API réglementaires pour que les TPP (third party provider) aient accès à deux fonctionnalités : la consultation et l'agrégation de compte et l'initiation de paiement.

Avant le vote de la DSP 3, cinq TPP (Linxo, Bridge, Fintecture, Lyra et Powens) ont souhaité rendre compte des (mauvaises) performances de ces API bancaires via une étude publiée en janvier. "Les banques ont développé leur propre écosystème d'API", indique Alain Lacour, président du groupe Lyra. Résultat : les TPP déplorent une trop grande disparité dans la qualité des interfaces développées par les banques. "La réglementation est européenne mais la réalité du terrain est plus locale. La qualité des API diffère selon les pays ou les banques", déplore Olivier Binet, CEO de Bridge. "On a fait cette étude pour montrer ces disparités mais aussi pour définir des critères qui mesurent les résultats des API. Un peu comme en Angleterre où les banques doivent rendre des comptes sur leurs performances".

L'initiation de paiement bloque

Les résultats de l'étude indiquent des réalités différentes selon les types d'API. Pour la partie consultation et agrégation de compte, celles-ci affichent "un taux de succès de 95%" et sont "fiables", admet Alain Lacour. C'est donc la partie initiation de paiement qui pose problème. En effet, seules 44% des opérations qui transitent par les API bancaires aboutissent. Un chiffre en apparence faible mais pas illogique selon Olivier Binet : "Les virements sont souvent utilisés pour des montants plus élevés que pour les paiements par carte bancaire donc c'est plutôt normal que le taux de rejet soit assez élevé".

Mais de quoi se plaignent les TPP alors ? "Le problème provient de la communication entre les banques et les fintechs", dénonce Alain Lacour. Ou plutôt de l'absence de communication. L'étude précise en effet que dans 84% des cas de rejet, les banques ne proposent aucune réponse à l'initiateur de paiement sur les raisons de l'échec du virement. "Le simple fait d'avoir des réponses précises de la part des banques serait une grande amélioration", indique Olivier Binet. "Actuellement, dans la majorité des cas, on ne sait pas si l'échec est dû à une tentative de fraude, si l'utilisateur à un problème d'identification, si le refus est causé par un problème technique".

"Une banque allemande peut demander jusqu'à neuf étapes de validation pour finaliser un virement"

Egalement pointée par l'étude, la qualité des parcours SCA (authentification forte du client) irrite les TPP : "Parfois, c'est uniquement le parcours d'identification prévue par la banque qui fait échouer la transaction", regrette Olivier Binet. Là aussi, les disparités entre les banques sont pointées du doigt : "Une banque allemande peut demander jusqu'à neuf étapes de validation pour finaliser un virement", fait remarquer Alain Lacour. "Avoir un parcours SCA digne d'une expérience en ligne serait la moindre des choses", insiste Olivier Binet. "On appelle à un sursaut des banques et des pouvoirs publics pour que l'open banking fonctionne mieux. Je rappelle qu'il s'agit d'une obligation légale et que des milliers d'entreprises comptent dessus".

Contactées, les principales banques françaises n'ont pas souhaité répondre à ces critiques. Mais elles peuvent compter sur les arguments… des TPP eux-mêmes. Et notamment sur la défense de Faysal Oudmine, CEO de Fintecture : "Dans le texte initial de la DSP 2, il y avait deux volontés : cadrer l'agrégation de compte et cadrer les paiements marchands. C'est pour cela que les API ont été créées. Et de ce point de vue-là, on peut dire que le contrat de base est plutôt rempli". Par ailleurs, les attentes autour de ces API seraient "trop élevées". "Certains acteurs veulent que ce soit une solution complète. Nous, on l'envisage comme une base qu'il faut compléter avec des outils développés en interne". De son côté, Alain Lacour souligne que les banques françaises "sont celles qui fournissent le plus d'efforts avec les banques hollandaises" tandis qu'Olivier Binet constate "une meilleure volonté des banques". Le CEO de Bridge espère toutefois que cette "amélioration de la bienveillance se transforme en amélioration de la performance".

Rémunérer les banques, une solution ?

Cette "amélioration de la performance" viendra-t-elle avec la DSP 3 ? "Il ne faut pas s'attendre à des miracles", prévient Faysal Oudmine. "La DSP 2 a été présentée il y a presque dix ans et ses premiers effets sont apparus seulement à partir de 2020. Donc si la DSP 3 amène des changements, ils ne seront visibles que dans quelques années". Mais peu importe le délai, Alain Lacour espère que le nouveau texte prendra en compte les revendications des TPP, dont une "harmonisation de la qualité des API à l'échelle européenne", "une publication des performances des API, comme au Royaume-Uni" ou encore "la mise en place d'une entité de régulation afin d'appliquer des sanctions en cas de défaillance ou de non-respect des normes".

Parmi les changements que la DSP 3 pourrait introduire, la rémunération des banques pour la mise en place d'API est étudiée. Actuellement, ce service est fourni gratuitement. Si Olivier Binet estime que ce changement est "nécessaire" et qu'Alain Lacour juge que "le tout gratuit n'est pas un modèle économique à long terme", Faysal Oudmine semble plus sceptique : "Les banques françaises dépensent plusieurs milliards d'euros par an sur l'IT. Si elles pouvaient rendre leurs API plus efficaces, elles l'auraient déjà fait car elles seraient ravies de réduire leur budget en IT". Une manière de souligner que le problème provient davantage d'une "incapacité technique" que d'une "mauvaise volonté".