Tribunes

La sécurité et l'authentification au centre de la régulation des paiements en ligne

---

Les 127 pages peu lisibles de la directive DSP 2 ne doivent pas être négligées. La DSP 2 devra être transposée avant le 13 janvier 2018 et elle change considérablement l'univers bancaire et celui des paiements dématérialisés. Et les problèmes de sécurité IT induits sont loin d'être résolus.

PublicitéLa Directive 2015/2366 du 25 novembre 2015 « concernant les services de paiement dans le marché intérieur » (dite DSP2) fait partie de ces textes européens au contenu aussi abscons (127 pages avec les annexes dont la moitié consacrée à des considérants et des définitions !) qu'essentiel.

Aujourd'hui, les paiements en ligne s'opèrent principalement avec des cartes bancaires et des solutions de paiement telles que Paypal, ce dernier étant un établissement de crédit luxembourgeois. L'objectif de la DSP2 est de faciliter l'arrivée de nouveaux acteurs pour les paiements électroniques et veiller à ce qu'ils fournissent des services de paiement sûrs et efficaces.

La DSP2 intervient à la suite de la DSP1 de 2007 dont la transposition était intervenue en France en 2009. La DSP1, transposée dans le Code Monétaire et Financier, était déjà à l'origine de modifications profondes et complexes de notre législation en matière bancaire. La peinture est encore fraîche qu'il faut déjà intégrer de nouvelles évolutions, et non des moindres. La date limite de transposition en droit français de la DSP2 est fixée au 13 janvier 2018.

Une interconnexion forcée avec le SI des établissements bancaires

Dans l'objectif d'offrir de nouvelles solutions de paiement en ligne, la DSP 2 crée un nouveau statut juridique pour deux nouveaux acteurs réglementés : le « prestataire de services d'information sur les comptes » (« AIS » pour « account information services ») et le « prestataire de services d'initiation de paiement » (« PIS » pour « payment initiation services », lesquels sont regroupés sous l'acronyme TPP (pour « Third party providers »).

Encore peu répandus en France, ces services se sont développés dans d'autres pays européens comme l'Allemagne.

S'agissant du « PIS », ce service de paiement intervient en établissant « une passerelle logicielle » entre le site marchand et le PIS en vue d'initier un virement depuis le compte bancaire du payeur vers celui du marchand. Basé sur le système du virement (dont chacun aura pu apprécier qu'ils sont aujourd'hui longs à effectuer en ligne), il permet aux consommateurs de faire des achats en ligne même s'ils ne possèdent pas de carte de paiement et de manière instantanée, sans paramétrer un virement.

S'agissant de l' « AIS », ce service uniquement informatif, à vocation à permettre à une personne titulaire de plusieurs comptes dans plusieurs établissements d'agglomérer et de gérer dans une interface unique l'ensemble de ses informations bancaires.

Pour procéder à l'opération de paiement souhaitée ou pour accéder aux données de compte d'un utilisateur, PIS et AIS doivent utiliser, pour le compte de leur client, les codes d'accès au service de banque en ligne de ce dernier.

PublicitéL'obligation de préserver la sécurité de ces données est cruciale pour protéger les fonds de l'utilisateur et pour limiter les risques liés à la fraude et à l'accès non autorisé aux comptes.

Les articles 66 et 67 de la directive viennent poser un principe de droit d'accès au compte par les PIS et AIS et d'obligation de « communication sécurisée » entre l'établissement teneur du compte et les TTP. Les banques ne pourront donc pas refuser la transaction informatique entre leur système de banque en ligne et celui de ces nouveaux prestataires de services.

Il s'agit d'un exemple rare où une législation oblige les systèmes d'information de deux acteurs privés à s'interconnecter.

Ce principe souffre d'une réserve : le gestionnaire du compte peut refuser l'accès à un TTP « pour des raisons objectivement motivées et documentées liées à un accès non autorisé ou frauduleux au compte de paiement ».

Cette exception met en lumière l'importance qu'il y a à authentifier la personne à l'origine de la demande d'accès au compte.

Un partage forcé des données d'identification de banque en ligne

La directive exige que les prestataires de services de paiement appliquent une « authentification forte » pour initier un paiement en ligne « comprenant des éléments qui établissent un lien dynamique entre l'opération, le montant et le bénéficiaire ».

Par authentification forte il faut entendre, selon la directive : une authentification reposant sur l'utilisation de deux éléments ou plus appartenant aux catégories « connaissance » (mot de passe), « possession » (téléphone mobile) et « inhérence » (données biométriques) et indépendants en ce sens que la compromission de l'un ne remet pas en question la fiabilité des autres.

La directive ne définit pas, en revanche, ce qu'il faut entendre par lien « dynamique ». Si l'on s'en réfère à la pratique des paiements 3D-Secure, on peut comprendre qu'il s'agit d'utiliser un « One Time Password » reçu par l'utilisateur à l'origine du paiement par SMS.

Il faudra donc intégrer le PIS dans la chaîne de communication sécurisée et d'authentification du payeur. L'article 97 de la directive oblige à procéder à cette intégration puisque le PIS pourra se fonder sur les procédures d'authentification prévues par le gestionnaire du compte.

Un travail normatif important à produire

Quelles seront les modalités techniques de ces échanges « sécurisés » et de ses « authentifications fortes » ? Sur ce point, la directive renvoie abondamment à la définition de normes techniques.

Leur définition est à venir. L'article 98 de la directive prévoit que l'Autorité bancaire européenne « après avoir consulté toutes les parties concernées », élabore avant le 13 janvier 2017 des projets de normes techniques précisant les exigences applicables aux normes ouvertes communes et sécurisées de communication. Ces normes devront être adoptées par la Commission européenne.

Quelle preuve et quel partage de responsabilité ?

Le processus de paiement faisant apparaître un nouvel acteur, le PIS, se pose inévitablement la question de la responsabilité si l'opération de paiement s'exécute mal ou si elle est le fruit d'une fraude informatique.

Au centre de la problématique, se trouvera donc la preuve du déroulement des opérations.

Sur ce point, la directive se veut protectrice des consommateurs : lorsqu'un utilisateur nie avoir autorisé une opération de paiement, il incombe au prestataire de services de paiement de prouver que l'opération en question a été authentifiée, dûment enregistrée et comptabilisée et qu'elle n'a pas été affectée par une déficience technique (article 72).

L'article va même au-delà en précisant que lorsqu'un utilisateur nie avoir autorisé une opération, l'enregistrement de cette opération par le prestataire ne suffit pas en tant que telle à prouver que l'opération de paiement a été autorisée par le payeur ou que celui-ci a agi frauduleusement ou n'a pas pris les mesures « raisonnables » pour protéger ses identifiants. C'est aux prestataires de services de paiement, dont les PIS, de prouver la fraude ou la négligence grave commise par l'utilisateur.

L'article 73 de la directive pose un principe de protection du consommateur final : en cas d'opération de paiement non autorisée, le prestataire de services de paiement du payeur rembourse au payeur le montant de cette opération au plus tard à la fin du premier jour ouvrable suivant la détection de l'incident.

Si un PIS est responsable du paiement non autorisé, il devra indemniser le gestionnaire du compte pour les sommes remboursées au payeur. C'est au PIS qu'incombe la charge de prouver que, pour ce qui le concerne, l'opération en question a été authentifiée et dûment enregistrée et qu'elle n'a pas été affectée par une déficience technique.

A la suite de l'adoption de cette directive, la Fédération Bancaire Française n'a pas manqué de souligner les questions importantes qu'elle laisse sans réponse : ainsi, « les exigences de sécurité applicables aux TTP restent floues » et « la traçabilité des transactions afin d'identifier les responsabilités de chacun des acteurs n'est pas prévue ».

Article rédigé par

Etienne Papin, Avocat associé du cabinet Feral-Schuhl / Sainte-Marie
Avocat au Barreau de Paris, Etienne Papin exerce dans les domaines du droit de l'informatique, de l'internet et des médias. Il conseille des SSII, éditeurs de logiciels, grandes entreprises et personnes publiques pour la rédaction et la négociation de leurs contrats informatiques. Il assiste également ces entreprises lors de procédures judiciaires. Il est associé du cabinet Feral-Schuhl / Sainte-Marie.
Suivez l'auteur sur Google+, Linked In, Twitter

Partager cet article