DSP2 : droit dans le mur

La directive européenne sur les services de paiement doit être pleinement appliquée le 14 septembre prochain. En France, la situation n'est pas du tout optimale.

Le 14 septembre approche et, disons le, la situation est très inquiétante : API non fonctionnelles, manque total de visibilité, continuité d’activité des TPP menacée, interprétations inégales des textes...

Comment en sommes nous arrivés là ?

Plusieurs raisons expliquent cette situation d’urgence où les différentes parties prenantes (banques, TPP, régulateurs nationaux et instances européennes) prennent enfin conscience du mur qui approche. 

La première raison est, en France, l’absence d'organisation centralisant les travaux des banques et les tests des TPP. Alors que le Berlin Group a un programme dédié (NISP : The NextGenPSD2 Implementation Support Program) permettant de suivre les publications des banques en termes d’API et que Open Banking (au Royaume-Uni) propose également une plateforme centralisant les différents travaux, nous n’avons rien de tout cela en France. 

Nous sommes, dans le meilleur des cas, informés de la publication des API des banques par simple email, mais nous devons (trop) souvent chercher nous mêmes les portails développeurs des banques françaises. Cet amateurisme explique en grande partie la situation dans laquelle nous nous retrouvons aujourd’hui. Le manque de communication et de partage d’informations a été très préjudiciable. 

Cela est également dû à une mauvaise volonté de certaines banques françaises qui ont tout simplement boycotté le groupe de travail créé à l'initiative des TPP français et lancé le 6 février pour justement partager des éléments d’informations et faciliter les tests (et corrections) des API. 

Il a fallu attendre la réunion du CNPS du 5 juin dernier pour que le régulateur, se rendant compte de l’urgence de la situation, encourage fortement les banques à participer au groupe de travail nouvellement créé dans le cadre de l’Association française des établissements de paiement et de monnaie électronique (AFEPAME) pour suivre l’implémentation des API DSP2. Nous avons donc perdu quatre mois pendant lesquels nous aurions pu échanger en bonne intelligence avec les banques dans le cadre du groupe de travail créé à notre initiative. Fort heureusement, certaines banques ont continué à échanger avec nous en bilatéral et nous avons pu corriger certains problèmes.

Une autre raison qui explique la situation critique dans laquelle nous nous retrouvons est le délai (trop) important pour obtenir les certificats eIDAS de production auprès des QTSP. Cela nous a ralenti dans les tests des API de production (qui restent de toute façon encore peu nombreuses). 

Personnellement, nous venons tout juste de réussir un test de bout en bout avec certificat de production sur une API de production d’une banque française (cas AIS). Les itérations pour réussir ce test ont duré plus de six mois !

Le bilan à aujourd’hui

Aujourd’hui, nous (TPP) essayons tant bien que mal de trouver une solution qui garantira la continuité de notre activité au 14 septembre et poussons donc un plan de transition qui permettra de repousser la mise en application de la SCA et d’intégrer de façon progressive les API des banques disponibles. C’est le seul moyen de garantir la continuité de l’activité des TPP et c’est donc indispensable ! 
Le bilan des test des API disponibles n’est, jusqu’à maintenant, pas réjouissant et le nombre d’API qui seront exemptées de mécanisme d’urgence (fallback option) devrait être famélique voire nul. 

Non respect des spécifications STET, non respect des spécifications OAuth, impossibilité de nous authentifier via certificats, données incomplètes, documentation incomplète, mécanismes d’urgence et de SCA non documentés, nombre d’écrans de redirection trop important (certaines redirections incluent même des écrans "presque fini" !) : les problèmes sont nombreux et les itérations très nombreuses pour arriver à un résultat à peine satisfaisant. 

Nous nous préparons donc à passer majoritairement par les mécanismes d’urgence des banques mais là encore le manque de visibilité est préjudiciable. Quel mécanisme d’urgence ? Si l’API est live mais pas suffisamment fonctionnelle, quelle procédure pour prévenir le régulateur et basculer sur la fallback ? Quelle méthode de SCA ? Nous commençons tout juste à recevoir les informations des banques un mois et demi avant la mise en application des API et de la SCA. Impossible de planifier sereinement nos implémentations et nos développements…

Enfin, nous apprenons ces derniers jours que certaines banques vont généraliser la SCA à chaque connexion sur leur espace en ligne et feront de même via API alors que les textes sont très clairs (Opinion of the European Banking Authority on the implementation of the RTS on SCA and CSC, page 3), c’est une seule authentification tous les 90 jours pour les AISP. Soyons extrêmement clair : une SCA à chaque connexion sur l’API tue notre activité et rend notre service inexploitable. Nous ne tolérerons pas de tels obstacles à notre activité. 

Septembre approche et il est grand temps de trouver des solutions pour garantir la continuité de notre activité. Le dialogue existe mais manque encore de transparence. Nous avons également besoin de décisions fortes de la part des instances européennes qui ne peuvent pas ignorer la criticité de la situation. 

Le positivisme qui accompagne l’arrivée de la DSP2 et de l’open banking est trompeur. Les perspectives peuvent être réjouissantes mais des décisions fortes s’imposent pour garantir l’objectif principal de la DSP2 qui est, ne l’oublions pas, de favoriser l’innovation dans le secteur financier ! 

DSP2 : droit dans le mur
DSP2 : droit dans le mur

Le 14 septembre approche et, disons le, la situation est très inquiétante : API non fonctionnelles, manque total de visibilité, continuité d’activité des TPP menacée, interprétations inégales des textes... Comment en sommes nous arrivés là ?...