Dans une série d’articles axés sur le cadre réglementaire européen, le conseiller et formateur en open banking Jon Scheele aborde l’implémentation des nouvelles technologies dans les établissements financiers et les FinTech.
Dans son premier article, il nous a expliqué quelles approches permettent d’intégrer la cybersécurité aux partenariats entre ces deux acteurs. Aujourd’hui, il se penche sur les conséquences des réglementations de l’UE pour la cybersécurité à l’ère post-open banking et sur le rôle que les API sécurisées ont à jouer.
Des mesures de régulation comme l’Open Banking initiative au Royaume-Uni et la deuxième mouture de la Directive européenne sur les services de paiement (DSP2) visent à stimuler l’innovation, la concurrence et à ouvrir le marché des transactions.
Les établissements financiers novateurs y voient une occasion d’élargir leur offre à leurs clients par l’intermédiaire de partenariats avec de nouveaux acteurs du secteur, les FinTech, et à l’aide d’API (Application Programming Interface) ouvertes.
Toutefois, ces établissements (notamment les banques) doivent aussi respecter les nouvelles contraintes réglementaires liées à la cybersécurité et au partage de données. Avant de dresser la liste de leurs obligations, passons en revue les réglementations ayant une incidence sur les partenariats d’open banking.
Réglementations concernant les partenariats d’open banking
eIDAS
Comme GlobalSign l’a si bien expliqué dans un précédent article intitulé « Sur la voie de l’eIDAS » :
« Le règlement sur les services électroniques d’identification et d’authentification (eIDAS) a été adopté [...] par l’UE sur un marché numérique en pleine mutation. L’eIDAS établit une norme d’identification électronique visant à simplifier et sécuriser les transactions en ligne effectuées en Europe. La réglementation s’appuie pour cela sur les services de confiance électroniques. »
Avant l’eIDAS, les établissements financiers britanniques accordaient relativement peu d’importance aux services de gestion des identités numériques, par rapport aux services de paiement et d’agrégation de comptes. Toutefois, dans d’autres pays de l’UE, les identités numériques constituaient déjà une priorité. Par exemple, le gouvernement italien a lancé le SPID (Sistema Pubblico Identita Digitale). Ce système national de gestion des identités permet d’accéder à tous les services publics à l’aide d’une seule et même identité numérique. À la clé : une amélioration de l’efficacité et le développement de l’économie italienne.
Aujourd’hui, la France, les Pays-Bas et l’Allemagne lui emboîtent le pas, tandis que les pays nordiques ont depuis longtemps une longueur d’avance.
À l’heure où les établissements financiers développent des partenariats basés sur les API avec les FinTech, ils devront envisager la création d’un framework agile unique pour le déploiement des services de reporting requis à travers différents domaines d’activité, voire différents pays et infrastructures disparates.
PSD2
La Directive DSP2 contraint les établissements financiers (notamment les banques) à donner accès à leurs informations clients et à leurs réseaux de paiement à des fournisseurs externes. Ces établissements doivent fournir cet accès via une série d’API sécurisées et standardisées qui permettront à leurs clients d’accéder à leurs informations de compte et d’effectuer des paiements.
Pour garantir la sécurité de ces services, ils doivent d’abord identifier leurs clients par des méthodes d’authentification forte. En clair, les simples paires nom d’utilisateur-mot de passe ne suffisent plus. Les établissements financiers doivent appliquer l’authentification multifacteur, basée sur au moins deux attributs clients.
Ils pourront utiliser une information seulement connue du client (catégorie « connaissance » du DSP2), un certificat numérique intégré à son téléphone mobile (catégorie « possession »), ou encore des données biométriques comme les empreintes digitales et les scans de l’iris (catégorie « inhérence »).
Ce nouveau cadre réglementaire poursuit plusieurs objectifs.
- Expansion de l’écosystème de cybersécurité au-delà de l’infrastructure et des applications d’un établissement financier : toujours responsables de la sécurité et de la confidentialité des informations et des fonds de leurs clients, ces établissements doivent vérifier soigneusement les processus et contrôles de leurs partenaires dans ce domaine.
- Montée en charge des fonctionnalités de cybersécurité des établissements financiers pour faire face à la diversité et au nombre croissants de partenariats, et ainsi protéger et surveiller leur surface d’attaque étendue (une conséquence de la collecte et du partage croissants de données).
- Définition de normes et politiques qui régissent les partenariats entre FinTech et établissements financiers : les banques devront accompagner les FinTech qui peuvent tout ignorer de l’intégration sécurisée.
- Juste équilibre entre sécurité et expérience client satisfaisante.
La Directive DSP2 permet à ces FinTech, des fournisseurs de services de paiement par exemple, d’entrer sur le marché européen des transactions et d’accéder aux données sensibles des clients afin de leur offrir de nouveaux services pratiques et sécurisés. En effet, si ces services visent à nous simplifier la vie, ils doivent également instaurer des garde-fous supplémentaires pour toutes les données sensibles que brasse cet écosystème.
Normes techniques de réglementation relatives à l’authentification forte du client (RTS SCA)
De leur côté, les normes techniques de réglementation relatives à l’authentification forte du client (RTS SCA) entreront en vigueur en septembre 2019. Elles apportent diverses précisions sur l’authentification forte du client et les normes ouvertes communes et sécurisées de communication tel qu’entendu dans la Directive DSP2. Par exemple, ces normes définissent précisément les éléments indispensables à cette authentification forte, notamment l’utilisation de l’authentification multifacteur (définie plus haut dans cet article).
Règlement général sur la protection des données (RGPD)
Quant au Règlement général sur la protection des données (RGPD), il contraint les banques à intégrer le consentement client à leur stratégie de partenariat. En d’autres termes, les clients doivent pouvoir décider des données qu’ils souhaitent partager, avec qui et à quelles fins. Ils doivent également pouvoir retirer leur consentement et demander la suppression de leurs données à tout moment.
Votre conformité en six points
Dans le cadre d’un projet d’open banking sécurisé, les établissements financiers doivent donc :
- authentifier leurs clients ;
- obtenir le consentement (l’autorisation) de ces clients avant de partager leurs données avec leurs partenaires ;
- conserver une trace de ce consentement à des fins d’audit ;
- permettre aux clients de retirer leur consentement ;
- évaluer au préalable leurs partenaires et leurs dispositifs de cybersécurité ;
- accorder à leurs partenaires un accès sécurisé à leurs informations clients (uniquement celles que les clients acceptent de partager).
Consentement et authentification des clients dans le cadre de l’open banking
Les réglementations et exigences que nous venons de détailler donnent à tous les services financiers (tant les FinTech que les établissements traditionnels) l’occasion d’élargir leur offre à leurs clients. Pour y parvenir, ils doivent :
- attirer des partenaires et développer davantage d’options afin d’améliorer le parcours client ;
- faciliter la tâche des clients prêts à consentir (ou qui souhaitent retirer leur consentement) au partage sécurisé d’informations sensibles avec leurs partenaires et des fournisseurs tiers ; et
- veiller à ce que ces partenaires et fournisseurs utilisent de puissantes fonctionnalités de cybersécurité pour la protection des informations clients partagées.
Quant aux développeurs des établissements financiers, ils doivent commencer à implémenter des mesures d’identification de leurs clients et de collecte de leur consentement avant même de partager des données avec les FinTech. À cet égard, vous trouverez nos recommandations de workflow ci-dessous.
Workflow recommandé pour l’authentification via des API
Les bonnes pratiques actuelles reposent sur des protocoles standard ouverts comme OAuth et OpenID Connect pour l’octroi d’accès externe aux informations de compte et le maintien de la confidentialité des informations de connexion du client. Pour certaines opérations comme le transfert de fonds et les paiements, une réauthentification pourra également être exigée.
Le workflow d’authentification passe par les étapes suivantes :
- Le client utilise l’application d’un partenaire. Cette application a besoin de son autorisation avant de tenter d’accéder à son compte.
- L’application est dirigée vers le serveur d’authentification de l’établissement financier. C’est ce serveur qui présente l’interface par laquelle l’utilisateur accepte ou refuse la requête.
- Le client est authentifié à l’aide d’OpenID Connect via l’authentification multifacteur (par ex., en utilisant un certificat numérique intégré à son appareil).
- Le client doit alors autoriser (consentir) le partage de données avec l’application utilisateur. Les données en question dépendront du champ d’application du consentement.
- Le client est redirigé vers l’application utilisateur et son consentement est approuvé à l’aide d’un code d’autorisation.
- L’application demande alors au serveur d’authentification d’échanger son code d’autorisation contre un jeton (token). Cette étape supplémentaire permet au serveur d’effectuer d’autres vérifications afin d’authentifier l’application utilisateur.
- Cette application fournit son jeton d’autorisation au serveur de ressources de l’établissement financier pour accéder aux informations que le client a consenti à partager.
Les contraintes réglementaires évoquées plus tôt imposent la mise en œuvre de bonnes pratiques d’identification et d’authentification afin de fixer des niveaux préalables de cybersécurité. L’objectif : instiller davantage de confiance sur le marché européen des transactions. Tant les FinTech que les établissements financiers doivent commencer à intégrer ces outils et ces standards à leurs services et partenariats sans plus tarder.
Dans mon prochain article, je me pencherai sur l’architecture de référence des API d’open banking. Nous découvrirons ensemble comment les établissements financiers et les FinTech peuvent envoyer et partager des données de façon sécurisée sur cette architecture. Combinée au workflow d’authentification abordé aujourd’hui, elle leur permet d’améliorer leurs services sans compromettre leur conformité aux nouvelles réglementations de l’UE.
Pour en savoir plus sur la Directive DSP2 et sur les normes techniques de réglementation RTS SCA, y compris les dates à retenir, consultez cette infographie (en anglais) du Conseil européen des paiements.
À propos de l’auteur
Consultant et formateur, Jon Scheele aide les institutions financières et les FinTechs à créer de nouvelles propositions de valeur pour leurs clients à l’aide de partenariats axés sur les API. Jon forme des professionnels des services financiers à la stratégie, la conception, la mise en œuvre et la gestion des API dans le cadre de son programme de formation « Building Financial Services Open APIs » (Construire des API ouvertes pour les services financiers).
Note : ce billet de blog a été écrit par un rédacteur externe afin de varier les contenus proposés à nos lecteurs. Les opinions exprimées par l’auteur de cet article sont exclusivement les siennes et ne reflètent pas nécessairement les opinions de GlobalSign.
