Intervention de Anne-Marie Barbat-Layani

La directive DSP 2 porte sur le marché intérieur des paiements. L'objectif de la Commission européenne est de développer le marché intérieur des paiements, pas celui de l'épargne. Nous ne sommes donc pas dans le même domaine. Les raisons qui ont poussé la Commission européenne à proposer ce texte sont doubles. Cette directive ouvre le marché des paiements à un certain nombre de nouveaux acteurs, ce à quoi la profession bancaire n'est pas opposée. En outre, et c'est la raison pour laquelle nous sommes favorables à ce texte, dans le domaine des paiements, elle permet de renforcer la sécurité. Des activités s'étaient en effet développées en marge de la réglementation et utilisaient les identifiants et codes d'accès des clients pour accéder à leurs comptes. Or, cela ne correspondait pas à nos obligations contractuelles. Et, jusqu'à présent, ce problème de sécurité n'avait pas été traité.

Toutefois, les dispositifs de sécurisation rencontrent une certaine limite, venant du fait que les considérations de sécurité ont été introduites de manière tardive dans une directive centrée au départ sur la concurrence. Pour nous, une malfaçon évidente est le fait que les considérations de sécurité n'entreront en vigueur qu'à l'été 2019, alors que les autres dispositions de la directive sont déjà en vigueur. Nous sommes ainsi dans une situation ou la directive ouvre, sans que la banque ne puisse s'y opposer, l'accès à des tiers aux comptes de paiement des clients que nous sommes censés protéger. Mais nous n'avons aucune possibilité de vérifier la qualité des opérateurs qui interviennent. Aussi, nous saluons l'initiative du Gouvernement, qui consiste à permettre l'entrée en vigueur des interfaces sécurisées au plus tôt, dès qu'elles auront été développées. D'ailleurs, le secteur bancaire est seul responsable du développement des interfaces de sécurité qui permettront à des tiers d'accéder aux comptes de nos clients. Nous sommes ainsi en charge de développer ces infrastructures. Nous le faisons bien volontiers compte tenu des risques majeurs en termes de cybersécurité.

Il y a, en outre, à nos yeux, un enjeu de responsabilité, puisque les tiers de paiement interviennent sur le compte de nos clients. S'il y a un problème - une fraude, ou un piratage de leur système, entraînant une fraude sur les comptes de nos clients -, c'est la banque qui doit rembourser le client. Il lui revient ensuite de se retourner vers les opérateurs et de demander des remboursements pour les opérations frauduleuses ou erronées. Le texte a prévu des obligations d'agrément et d'assurance. Je signale que ces obligations d'assurance, par nature, ne pourront être vérifiées par le régulateur que pour les activités réglementées, c'est-à-dire celles portant sur les comptes de paiement. Bien évidemment, si on devait envisager toute extension du régime en vigueur pour les paiements à l'épargne ou au crédit, la question des assurances devrait être reposée, et il reviendrait aux opérateurs d'être agréés à nouveau pour de nouveaux types d'opération. Nous avons critiqué ce régime de responsabilité, car il nous met en risque de devoir payer pour le compte d'autrui, puis de devoir se retourner vers les opérateurs fautifs. De ce point de vue, il est plutôt sécurisant d'avoir un régime d'agrément. Nous nous interrogeons toutefois sur la façon de procéder, le cas échéant, si les opérateurs fautifs n'étaient pas établis en France et agréés dans un autre pays. Le dispositif est alors très compliqué.

En ce qui concerne les API, le secteur bancaire a demandé à une société, qui est gestionnaire d'infrastructures de paiement, de développer des spécifications techniques, pour que les banques puissent, sur ces bases, développer les interfaces sécurisées. Cette entreprise s'est tournée vers l'ensemble des opérateurs. Personne n'a ainsi été exclu des réflexions. La concertation sur les spécifications à mettre en place avance. La France est aujourd'hui dans une situation pionnière, puisque nous sommes la seule communauté bancaire à être quasiment en situation de développer les API. Nous espérons que ces interfaces pourront être mises en place d'ici la fin 2018. On pourrait ainsi gagner quelques mois en termes de sécurité par rapport aux dispositions de la directive, grâce à l'amendement gouvernemental.

Je souhaite, enfin, revenir sur l'extension du champ de la directive aux comptes d'épargne. Pour moi, il serait très étonnant que l'intégration des comptes d'épargne se fasse au stade de la transposition d'une directive portant clairement sur le marché intérieur des paiements. Si on souhaite intégrer ces comptes, le seul lieu de discussion possible pour le faire est le niveau européen. C'est d'ailleurs la position de la Commission européenne qui m'a confirmé récemment qu'effectivement le texte de la directive DSP2 portait sur les paiements et non sur les comptes d'épargne La situation de ces derniers est très complexe, puisque les activités dont il est question ne sont pas réglementées. En tant que représentants du secteur bancaire, il ne nous appartient pas de nous prononcer sur des activités non réglementées. Enfin, je souhaite rapidement évoquer le risque de blanchiment de capitaux et de financement du terrorisme. Le dernier rapport de Tracfin est intéressant à cet égard car il rappelle que les nouveaux acteurs consacrés par la directive DSP 2 n'ont pas la même culture contre le risque de blanchiment que les établissements bancaires. Le rapport pose également un certain nombre de questions sur la supervision de ces nouveaux acteurs.