La DSP2 est un nouveau jalon dans le renforcement de la sécurité sur les services de paiement. Elle apporte des mesures adaptées aux besoins et à la multiplication des acteurs numériques dans le secteur. Malgré cet apport en sécurité conséquent, les limitations de la directive apparaissent dues notamment à son périmètre d’application mais également aux standards existants.

Les limites de la DSP2

La limitation du périmètre aux seuls comptes de paiement

La DSP2, en tant que directive sur les services de paiement régit les opérations en ligne des acteurs de ces services uniquement sur les périmètres concernés qui sont les comptes intervenant dans les opérations de paiements.

Dans les faits cependant, les acteurs, et en particulier les agrégateurs, réalisent aujourd’hui des opérations sur l’ensemble des comptes des utilisateurs, notamment leurs comptes d’épargne. Un des enjeux de ces agrégateurs étant de fournir des services à valeur ajoutée touchant à l’ensemble de l’activité de l’utilisateur sur ses comptes : comptes courants, comptes d’épargnes, chèque, cartes, crédits, plan en actions, …

En réglementant uniquement sur l’accès aux comptes de paiement, la commission européenne et l’ABE mettent en lumière le fonctionnement des agrégateurs (rejeu des secrets de connexion utilisateurs) sans fournir une solution à l’ensemble des problématiques des échanges entre ces acteurs non bancaires (agrégateurs) et les banques.

Dans l’intérêt du développement des agrégateurs, des solutions devront donc être actées pour élargir cette législation. Par ailleurs, les travaux engagés par les banques dans le cadre de la DSP2 les ayant amenées à construire l’architecture nécessaire à l’exposition de services sur internet, une évolution de ces services à plus des comptes et à plus de services utilisateurs est probablement à venir.

Incompatibilité avec les standards existants

Contrairement à l’initiative OpenBanking UK, basé sur le standard reconnu du groupe de travail Financial API, au sein de la fondation OpenID, les nouveaux services offerts par les banques dans le cadre de la DSP2 se fondent sur des exigences réglementaires plutôt que sur des standards de sécurité établis.

Consentement utilisateur

Le consentement utilisateur est un bon exemple de cet éloignement entre le standard, ici OpenID Connect, et la réglementation.

La directive implique que le consentement de l’utilisateur à l’utilisation d’un ou plusieurs comptes pour un agrégateur :

• Doit être recueilli par le TPP (donc l’application qui va consommer les API) ;
• Doit être appliqué et vérifié par l’ASPSP (hébergeant les API).

Ceci est réalisé à rebours du standard OpenID Connect (implémenté dans le cadre de OpenBanking UK), dans lequel le consentement doit être recueilli par le service hébergeant les données et les API.

Cinématique authorization code

Mise en œuvre pour l’usage des AISP, la cinématique authorization code requiert une redirection de l’utilisateur de l’AISP vers le service d’authentification et de consentement de l’ASPSP, puis en retour une nouvelle redirection vers l’application de l’AISP.

Cette redirection peut être considérée comme un obstacle à l’utilisation des services comme le mentionne en exemple l’article 32 des RTS. En conséquence elle peut s’avérer illégale et des travaux sont en cours pour trouver des alternatives conformes ou non aux standards OAuth2.

L’acceptation de l’usage de cette cinématique pour les besoins de la DSP2 relève alors de chaque autorité nationale, ce qui a pour effet de limiter l’uniformisation européenne de ces interfaces. Actuellement, en France, l’ACPR a validé l’usage de cette redirection.

Figure 3: Les acteurs de la DSP2 en scène

Conclusion

Dans un environnement numérique en constante mutation, la DSP2 prend le parti de favoriser le développement des acteurs intermédiaires de services de paiement, pour mieux standardiser les échanges et apporter une meilleure ergonomie de navigation des utilisateurs et une meilleure sécurité des transactions.

Elle comporte des apports importants sur des sujets de sécurité, qui imposent des évolutions des SI bancaires : l’ouverture des services sur internet et le changement des moyens d’authentification sont en particulier un sujet compliqué pour les banques historiques.