L'open banking décrit la manière dont les banques autorisent les prestataires de services financiers agréés à accéder aux données des titulaires de comptes bancaires, à les utiliser et à les partager après le consentement de l’utilisateur. Si, auparavant, les clients des banques devaient se rendre dans leur agence pour gérer leurs finances, aujourd'hui, la gestion financière est digitale. Consultation de comptes, transfert d’argent, initiation de paiement : tout peut s’opérer à partir d’un ordinateur portable ou d’un simple smartphone.
L'open banking permet d’améliorer l'expérience client en s’appuyant sur les prestataires de services tiers (TPP) pouvant offrir de nouveaux services grâce à l’exploitation des données des titulaires de comptes : consultation de comptes, initiation de paiements, obtention de l'historique du compte, mais aussi conseils budgétaires, notifications d'épargne… Les finances personnelles passent soudainement du stade de la réactivité à celui de la proactivité et tous y trouvent avantage. À date, 24,7 millions de personnes dans le monde ont utilisé des services bancaires ouverts. D’après une étude Worldwide de mars 2021, ce nombre devrait atteindre 132,2 millions en 2024.
La logique d’un écosystème avec de nouveaux acteurs
Techniquement, le partage des données s'effectue souvent par le biais d'une interface de programmation d'applications (API). Ce conduit intelligent et sécurisé permet le flux de données entre les systèmes de manière contrôlée et transparente. Les API sont utilisées depuis des années dans le secteur bancaire. Toutefois, compte tenu des percées réalisées dans le domaine de l'analyse avancée et de l'essor commercial de nombreuses fintechs non bancaires, les API font l'objet d'un regain d'attention en tant que moyen d'améliorer la fourniture de services financiers aux particuliers et aux entreprises.
Si l'open banking est susceptible de profiter aux utilisateurs finaux et de favoriser l'innovation dans de nouveaux domaines de concurrence entre les banques et les non-banques, il ouvre la voie à un écosystème de services financiers entièrement nouveau incluant de nouveaux acteurs et offrant différents services ou fonctionnalités :
– facilitateurs de l'open banking ;
– connectivité API pour l'initiation des paiements ;
– connectivité API pour la récupération de données ;
– solutions et services de données à valeur ajoutée ;
– gestion des consentements ;
– vérification et référentiel des fournisseurs tiers ;
– solutions et propositions pour l'utilisateur final ;
– fraude, risque et sécurité ;
– banque traditionnelle/banque en tant que service/infrastructure bancaire de base.
Un besoin de sécurité, tant réglementaire que technique
Ce nouvel écosystème présente de nombreux enjeux, en particulier pour les banques (voire encadré). Le défi principal de l’open banking est de simplifier fortement les échanges entre banques et commerçants et d’améliorer ainsi l’expérience client, tout en garantissant la sécurité des données des titulaires de comptes bancaires avec une approche couvrant les aspects réglementaires et techniques. Cela nécessite la prise en compte des aspects réglementaires et sécuritaires dans l’implémentation de l’infrastructure « open banking » par l’ensemble des parties prenantes. Notamment sur la gestion des données des clients, des interfaces de communication et des accès.
L'open banking a émergé en Europe depuis l’adoption de la Directive sur les services de paiement (DSP2). En mars 2018, l’Autorité bancaire européenne (ABE) a publié, en collaboration avec la Banque centrale européenne (BCE) et les banques centrales nationales, le RTS (Regulatory Technical Standards – Normes réglementaires techniques) pour définir, d’une part, les modalités d’échange entre ASPSP et TPP et, d'autre part, les modalités d’authentification de l’utilisateur (PSU). En effet, le RTS vise à harmoniser la mise en œuvre opérationnelle des mesures de sécurité autour de l’authentification forte et la sécurité des échanges entre les banques, les clients et TPP (Third Party Provider – PSP tiers). Ces spécifications techniques viennent renforcer la DSP2. Les parties prenantes de cet écosystème sont soumises à la DSP2 et contraintes de mettre leur infrastructure en conformité par rapport aux RTS. Pour engager une démarche de mise en conformité RTS, il est important, pour ces parties prenantes, de délimiter le périmètre et identifier les différents parcours clients.
Les nombreux actifs à sécuriser
L’open banking permet aux banques et, plus généralement, aux prestataires de services de paiement teneur de compte (ASPSP) au sein desquelles le client (PSU) détient un au plusieurs comptes et/ou au sein duquel le PSU initie des paiements, d’attribuer aux TPP – Prestataire de services d’information sur les comptes (AISP), Prestataire de services d’initiation de paiement (PISP) et Émetteur d’instrument de paiement lié à une carte (CBII) – des droits d’accès en lecture et/ou écriture aux données des titulaires de comptes, sous réserve du consentement du client (PSU), via des interfaces de programmation applicative (API) pour offrir des micro-services bancaires.
Etant donné l'architecture fonctionnelle de l'open banking (voir schéma), nous pouvons identifier une liste non exhaustive d’actifs à sécuriser :
– les personnes physiques : PSU, développeurs d’API, administrateurs d’infrastructures et de bases de données (TPP et ASPSP), personnel interagissant avec l’écosystème ;
– les logiciels : applications mobiles, sites Web, API, antivirus, systèmes d’exploitation ;
– les technologies et infrastructures : serveurs (applicatifs, bases de données, hyperviseurs…), réseaux (firewalls, switchs, routeurs, SIEM, WAF…), solutions de gestion de l’authentification de l’utilisateur et des interfaces de communication (entre TPP et ASPSP) ;
– les certificats numériques : pour l’authentification et la sécurisation des échanges ;
– les données des titulaires de comptes.
Avec l’ouverture des données à des tiers, les ASPSP principalement, mais aussi les TPP s’exposent à plusieurs risques de sécurité (vol de données, usurpation d’identité, accès illégitime…). Ces acteurs, opérants au sein de l’écosystème open banking doivent donc garantir la confidentialité, l’intégrité et la disponibilité des données de titulaires de comptes.
Des bonnes pratiques à mettre en œuvre
La mise en place de bonnes pratiques permet de s'aligner avec les objectifs des exigences techniques de sécurité listés dans le RTS. Nous mettons en exergue neuf recommandations.
Partager les données uniquement avec des TPP certifiés ou agréés. Les AISP, CBPII et PISP peuvent obtenir un agrément d’établissement de paiement auprès des autorités nationales. En France, l’autorité concernée est l’Autorité de contrôle prudentiel et de résolution (ACPR).
Utiliser des certificats conformes au règlement eIDAS (électronic IDentification And trust Services). Pour l’accès aux comptes, l’usage de certificats conformes eIDAS sert à authentifier les ASPSP, les AISP et les PISP. Ils s’appuieront sur les autorités de certification reconnues, qui garantiront l’authenticité de l’agrément de chaque établissement et son rôle.
Utiliser des standards et protocoles de communication sécurisée. Les ASPSP doivent mettre à disposition des TPP une interface dédiée pour leur communiquer, de façon sécurisée, les informations et ressources nécessaires pour les services de paiement CBPII, PISP et AISP.
Sécuriser les environnements des ASPSP et TPP. Implémenter des configurations robustes et sécurisées sur les composants et technologies de l’écosystème.
Effectuer des mises à jour régulières sur l’ensemble des systèmes et composants de l’écosystème. Déployer régulièrement sur l’ensemble des composants systèmes, logiciels et applicatifs de l’écosystème les versions publiées par les éditeurs.
Tester et surveiller régulièrement les composants réseaux et applicatifs. Cela concerne principalement les composants systèmes, logiciels et applicatifs, ainsi que les équipements de sécurité.
Utiliser les systèmes de stockage de données sécurisés. Chiffrer les données et limiter l’accès aux seuls besoins métiers.
Sécuriser le processus de développement des applications. Respecter les règles de sécurité dans le développement (Open Web Application Security Project).
Sécuriser l’accès PSU aux environnements du TPP et ASPSP. Cette authentification forte requiert au minimum deux facteurs faisant partie d’au moins deux des trois catégories suivantes :
– « quelque chose que je sais » (connaissance) : ce que seul le client connaît (un code PIN, une information privée) ;
– « quelque chose que je suis » (inhérence) : ce que le client est (un élément biométrique, comme l’empreinte digitale) ;
– « quelque chose que j’ai » (possession) : ce que seul le client détient (une carte de paiement sécurisée, une ligne téléphonique ou un compte mail où est reçu un one time password, une adresse où est reçu un courrier).
