Réglementation financière

Quand l’innovation sert la régulation

La directive révisée sur les moyens de paiement ouvre les données bancaires aux acteurs du web moyennant agrément. En contrepartie elle entend sécuriser l’environnement dans lequel s’effectuent les paiements en ligne et l’accès aux comptes

Comment favoriser le développement des nouvelles technologies financières tout en garantissant la sécurité de leurs utilisateurs ?  L’Union européenne affiche depuis plusieurs années sa volonté de sécuriser les paiements en ligne et d’autoriser les sociétés financières et technologiques (fintech) à récupérer en toute régularité les informations clients stockées par les banques. Ce qui suppose en amont de poser un cadre législatif propre aux prestataires de service de paiement (agrégateurs d’information et initiateurs de paiement). Tel est l’objectif de la seconde directive sur les moyens de paiement (DSP2) [1] entrée en vigueur le 13 janvier 2018. Un autre volet de cette directive renforce la sécurité des opérations de paiement et d’accès aux comptes, soumis désormais à une authentification forte de l’identité du client. Un dispositif censé être effectif au 14 septembre 2019. Or, confrontée à l’impréparation des acteurs de la chaîne de paiement, l’Autorité bancaire européenne, pragmatique, a décidé du report de l’authentification forte.

Agrément des PSP. Jusqu’à l’adoption de la DSP2, les fintech proposant des services d’agrégation d’informations et d’initiation de paiement échappaient à la réglementation de la Commission européenne. Depuis, leur activité est régie par l’Autorité de contrôle prudentiel et de résolution (ACPR) qui leur impose un cahier des charges précis pour obtenir le statut de prestataires de service de paiement. Toutefois, à la différence des établissements de paiement, les fintech bénéficient d’un régime d’agrément allégé. « De cette façon, le régulateur tente d’encadrer au mieux ces activités en instaurant des règles proportionnelles, tout en favorisant l’innovation et l’implantation de ces acteurs sur le territoire »,  observe Gérard Haas, avocat associé du cabinet Haas Associés. « Autre point, la régulation ne doit pas impliquer de coûts trop importants pour la jeune structure, ou des mesures exorbitantes à mettre en œuvre, d’où l’importance d’instaurer une procédure beaucoup plus souple ». 

Modalités de l’agrément. Avant d’attribuer ce précieux agrément, l’ACPR réalise une série de contrôles. Dans un premier temps, elle s’assure que le fournisseur dispose d’une assurance responsabilité civile couvrant la mauvaise exécution des paiements ou l’accès non-autorisé ou frauduleux aux données des comptes de paiement vis-à-vis du client ou du gestionnaire de compte. Le montant minimal de l’assurance dépend d’un certain nombre de critères pour chacun des services (nombre de clients, volume de paiements initiés, valeur des plaintes reçues…). Le régulateur vérifie également les systèmes de contrôle interne mis en place dans l’entreprise ainsi que la gouvernance et l’actionnariat de la société. Les agrégateurs n’ont aucune obligation de capital social, à l’inverse, les initiateurs doivent disposer d’un capital initial d’au moins 50.000 euros. En outre, certains changements sociaux sont soumis à l’autorisation préalable de l’ACPR. Ces points contrôlés, l’ACPR devra encore obtenir un avis sécuritaire de la Banque de France avant de pouvoir octroyer son agrément. « En matière de lutte contre le blanchiment et de financement du terrorisme (LCB-FT), les agrégateurs sont hors-champ du dispositif. Quant aux initiateurs, ils sont identifiés en risque faible, puisque le contrôle repose sur les banques », ajoute Geoffroy Goffinet, adjoint au directeur des autorisations de l’ACPR.

Traitement des données personnelles. En revanche, les agrégateurs et initiateurs sont au cœur du règlement général pour la protection des données personnelles (RGPD), dont l’une des priorités est de restituer la maîtrise des données à leurs titulaires. Côté fintech, « les usagers peuvent exercer leur droit à la portabilité et récupérer leurs données dans un format ouvert et lisible par machine » souligne Gérard Haas, « étant précisé que cette demande ne peut pas être facturée (sauf demande manifestement infondée ou excessive) ». Les informations collectées par le PSP ne peuvent être conservées au-delà de la durée nécessaire pour la mise en œuvre du traitement. « Ainsi, les données recueillies par les initiateurs de paiement, doivent en général être conservées pendant cinq ans à partir de la fin de la relation d’affaire ou de la clôture du compte, en application de la réglementation LCB-FT », précise l’avocat.

Blockchain et RGPD. Comment exercer son droit à la portabilité ou à l’oubli lorsque les fintech utilisent la blockchain ? Ce registre dans lequel les utilisateurs peuvent lire et écrire des données, sans que celles-ci puissent être modifiées ou supprimées. « Si la sécurité de cette technologie est assurée par l’usage de la cryptographie et du chiffrement des données, les caractéristiques mêmes de la blockchain – l’impossible suppression ou modification des data qu’elle contient -, rendent de fait plus compliqué l’exercice des droits à l’oubli et de mise à jour des données », reconnaît Gérard Haas. « Toutefois, des solutions techniques existent pour se rapprocher des exigences de conformité du RGPD. Par exemple, concernant le droit à l’effacement, la Cnil recommande de couper l’accessibilité de la donnée. Elle conseille par ailleurs de ne pas inscrire une donnée à caractère personnel en clair sur la blockchain ».

 

OPEN BANKING

Modalités d’échange des données. L’open banking prend corps. Dans le cadre de la directive sur les services de paiement, les acteurs bancaires sont contraints d’ouvrir leurs bases de données clients aux prestataires de services d’information sur les comptes (agrégateurs). Ainsi, depuis le mois de mars, les gestionnaires de comptes travaillent à la mise en place d’interfaces sécurisées, les API (pour application programming interfaces en anglais), dédiées aux agrégateurs. Un portail en ligne qui permet aux prestataires de récupérer les données bancaires de leurs clients. « D’ailleurs, pour faciliter les échanges avec les fintech, les banques françaises ont mis en place des spécifications communes, qui font que les agrégateurs bénéficient d’un format unique d’API auprès de tous les établissements », souligne Christine Guillaumet, directrice adjointe de l’offre cartes et paiements innovants chez BNP Paribas. Les établissements qui décident de développer une unique API, sans solution de secours - censée pallier d’éventuels dysfonctionnements - doivent obligatoirement obtenir une exemption de l’ACPR. « L’objectif étant de s’assurer que les interfaces dédiées disposent de la même robustesse que celles destinées aux utilisateurs directs des banques. Au préalable, les gestionnaires de compte doivent obligatoirement passer par une phase de test et par une phase de mise en production d’au moins trois mois, pour s’assurer de la fonctionnalité de leurs API. Si nous jugeons l’interface suffisamment solide, nous autorisons l’établissement à ne pas déployer de mécanisme alternatif », précise Geoffroy Goffinet. Une fois l’exemption obtenue « les agrégateurs n’ont pas d’autre choix que d’utiliser les API et de renoncer au web scraping », détaille Julien Maldonato, directeur FSI Fintech, Deloitte conseil.

Solutions alternatives aux API. Les banques qui ne proposent pas d’API, ou celles dépourvues d’exemption parce que leurs portails ne sont pas fonctionnels, doivent disposer de solutions de secours, faute de quoi les prestataires de service de paiement pourront utiliser le web scraping à titre alternatif. Une technique qui consiste à extraire, avec l’accord du client, les informations bancaires disponibles depuis le site de sa banque. « En contrepartie, l’agrégateur doit se connecter au moyen d’un certificat e-IDAS et d’une clé de sécurité pour pouvoir être identifié par les banques », indique le directeur FSI Fintech de chez Deloitte conseil. Initialement les banques avaient jusqu’au 14 septembre pour se positionner sur l’une de ces trois solutions.

Retard dans la mise en place des API. A la mi-septembre « seules 8% des API des établissements bancaires français testés se révélaient être conformes aux exigences de la nouvelle directive, 23% étaient partiellement fonctionnelles, 4% non fonctionnelles », relève Romain Bignon, CEO de Budget Insight, « sans compter que 50% des API n’étaient pas encore en production, c’est-à-dire indisponibles à l’utilisation. Etant précisé que ces difficultés, ne relèvent pas tant de la mauvaise volonté des banques, que de la complexité technique de faire interagir deux systèmes informatiques », reconnaît le CEO de Budget Insight. « Globalement nos relations avec les banques sont bonnes », conclut-il. Pour le moment, « la plupart des grandes banques françaises recourent à une API, doublée d’une solution de secours, mais celles-ci envisagent de demander une exemption d’ici la fin de l’année ou début d’année prochaine », explique Geoffroy Goffinet. En dépit de ces difficultés, certaines banques ont obtenu leur exemption dès le 14 septembre, parmi elles Crédit Agricole, Consorsbank et DAB - succursales allemandes de BNP Paribas-, Rothschild Martin Maurel, Banque Neuflize OBC, ainsi que la Mufg Bank Ltd – un groupe bancaire japonais issu de la fusion de The Bank of Tokyo-Mitsubishi et UFJ Bank, et Qatar National Bank. Le groupe BPCE avait annoncé dès le 7 mars 2019 l’ouverture de ses API réglementaires, sans figurer à ce jour sur la liste des exemptés. A l’image de ses filiales allemandes, « BNP Paribas France demandera son exemption à compter d’octobre 2019, à l’issue du délai de mise en production de trois mois de nos interfaces », confie Christine Guillaumet. Le bras de fer entre banques et fintech semblerait presque appartenir au passé.

Un accès limité aux comptes. Un point d’achoppement demeure entre les acteurs, puisque la DSP2 ne vise que les comptes de paiement et non pas les comptes d’épargne. « Pourtant, le 14 mars 2018, le Sénat avait proposé d’étendre l’accès des agrégateurs à tous les comptes bancaires, y compris les comptes épargne », expose Gérard Haas, « or après avoir été adopté, cet amendement a finalement été retiré le 24 juillet 2018 ». Pour le moment, la Commission a confirmé que les comptes non régulés par la directive restaient accessibles au web scraping, à défaut d’être intégrés dans les API. Aujourd’hui, « les agrégateurs sont dans une zone grise. Aucun texte ne leur interdit d’accéder aux comptes d’épargne par web scraping et aucune disposition n’oblige les banques à définir des API en ce sens », explique Julien Maldonato. Sur ce point la position de BNP Paribas est claire, « nos API ne transmettent que l’accès et les informations sur les comptes de paiement. Elles ne sont pas définies pour les comptes d’épargne, et d’ailleurs la question n’est pas d’actualité », tranche Christine Guillaumet. « Pour l’instant la priorité c’est de terminer le travail sur les comptes de paiement dans les délais impartis », insiste-t-elle. Pourtant le directeur de Budget Insight note l’émergence d’une certaine volonté politique, poussée par la Commission européenne et la Direction générale du Trésor en France, pour ouvrir davantage les API.

L’échéance du 14 septembre était d’autant plus difficile à honorer que le même jour, les banques devaient, généraliser les paiements et l’accès aux comptes par authentification forte. Un chantier qui a forcément empiété sur la mise en production des API.

 

PAIEMENT ET ACCES AUX COMPTES

Identification forte des paiements en ligne. Avec 69,2 milliards de paiements par carte par an en Europe, la sécurisation des transactions en ligne est une priorité. La première mesure, à l’attention des acteurs de la chaîne de paiements, consiste à remplacer progressivement l’identification par SMS par une solution d’authentification forte. La seconde prévoit la mise à niveau de l’infrastructure technique « 3D Secure ». A terme, l’identification forte sera systématique dans les pays de l’Union et l’actuel code unique envoyé par SMS devrait disparaître d’ici 2022, d’après le calendrier fixé par l’Autorité bancaire européenne (ABE). Or, pour le moment seuls 45 % des cyberacheteurs français sont informés de l’arrêt prochain du SMS d’identification, comme le révèle l’étude publiée par le cabinet Enov le 12 septembre 2019. Dans le détail, ce second volet de la directive impose aux banques (et aux e-commerçants) de vérifier l’origine des transactions de paiement initiées au moyen de deux des trois éléments de sécurité suivants : une information que l’usager est le seul à connaître (mot de passe, code secret, question secrète, …), l’utilisation d’un appareil qui n’appartient qu’à lui (téléphone portable, carte à puce, montre connectée…) ou une caractéristique personnelle (données biométriques…). Alors que ce dispositif était réputé obligatoire à compter du 14 septembre 2019, l’ABE a annoncé son report le 21 juin dernier.

Un an et demi de sursis. Bien que décidée à temporiser, l’Autorité européenne a rappelé à l’ordre les acteurs, qui connaissaient dès 2015, les conditions des nouvelles procédures d’identification clients. Sans compter que la seconde directive leur avait déjà accordé un délai supplémentaire de 18 mois - à compter de l’adoption des normes d’application - pour se mettre en conformité. Soit jusqu’au 14 septembre dernier. Pour autant, l’ABE n’a prévu aucune date de report et s’en remet aux autorités nationales pour la fixer en concertation avec les établissements bancaires et les prestataires de paiement. Dans ces conditions, les autorités nationales ont proposé différents aménagements réglementaires et mesures de transition concernant les paiements électroniques. En France, l’Observatoire de la sécurité des moyens de paiement (OMSP) a établi un plan de migration prévoyant une mise en place progressive de l’authentification forte sur les transactions en ligne et sur le volet « 3D Secure ». Pour les paiements, les banques et les plateformes commerciales ont 15 mois, soit jusqu’à fin 2020, pour migrer la grande majorité des utilisateurs vers des nouvelles formes d’authentification. Un délai supplémentaire, pouvant aller jusqu’à 18 mois, pourra être accordé pour la migration d’utilisateurs présentant des caractéristiques spécifiques (populations fragiles par exemple) vers des solutions sur mesure appropriées. Concernant le volet « 3D Secure », le délai accordé est de 18 mois. Les professionnels de la chaîne de paiements ont jusqu’à la fin du mois de mars 2021, pour mettre à niveau l’infrastructure technique « 3D Secure » selon les règles de fonctionnement définies par la DSP2.

Double authentification forte. Sur le même principe que l’authentification forte sur les paiements en ligne, la DSP2 impose que l’accès aux comptes soit également soumis à une authentification forte, pour une meilleure indentification du client. Ce qui signifie que l’usager qui consulte ses comptes bancaires via sa banque à distance, devra tous les 90 jours renouveler son consentement au moyen d’une authentification à deux critères. Bien que la responsabilité de l’identification forte incombe aux banques, cette contrainte impacte nécessairement l’environnement des agrégateurs qui doivent adapter leurs solutions d’agrégation en prenant en compte ce nouveau paramètre d’authentification. « Dans ces conditions, il n’est pas exclu d’imaginer déléguer au prestataire de service d’information que nous sommes, la gestion de l’authentification forte, au même titre que la gestion du consentement », avance Romain Bignon. « Ainsi l’agrégateur notifierait systématiquement la banque lorsqu’il réalise une authentification forte pour le compte du client, et renouvellerait pour 90 jours le jeton d’autorisation. D’ailleurs ce sujet a trouvé un écho auprès des membres de la Commission européenne, et fera l’objet de discussion au sein de l’ABE ».  En attendant, le dispositif d’authentification forte qui devait être fonctionnel en septembre a été reporté de quatre mois. 

 

[1] Directive n°2015/2366 du 25/11/15

Fichiers: