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 expliquait quelles approches permettent d’intégrer la cybersécurité aux partenariats entre ces deux acteurs. Dans le deuxième, il se penchait 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.
Dans cet article, j’examine 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é dans mon précédent article, cette architecture leur permet d’envoyer et de partager en toute sécurité des données sans enfreindre les réglementations de l’UE pour, in fine, améliorer leur offre de services.
Une architecture de référence indique aux établissements financiers quelles sont les briques à utiliser pour renforcer la résilience de leur infrastructure. Dans quel objectif ?
- Contrer les cyberattaques du mieux possible
- Faciliter les opérations de récupération en recherchant la rapidité et la fluidité
- Favoriser la coordination des réactions et des actions de résolution entre les différents partenaires, organismes de réglementation et autres parties prenantes en cas d’attaque
Exigences en matière de cybersécurité
Dans la première partie, nous indiquions quelles étaient les principales mesures de cybersécurité à adopter pour la mise en œuvre d’une initiative d’Open Banking par les établissements financiers. Il s’agissait notamment de :
- authentifier leurs clients ;
- obtenir le consentement (l’autorisation) de ces clients avant de partager leurs données avec leurs partenaires tiers fournissant des services de paiement (PSP tiers) ;
- 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).
Normes techniques de réglementation (RTS) relatives à l’authentification forte du client (SCA)
Dans la première partie, nous décrivions également le processus d’authentification et d’autorisation qui permet aux établissements financiers d’obtenir le consentement de leurs clients avant de communiquer leurs données aux tiers fournisseurs de services de paiement (PSP tiers). L’article montrait quelles étaient les briques nécessaires à la mise en place d’un tel workflow via les protocoles OAuth2.0 et OpenID Connect.
Par ailleurs, les normes techniques de réglementation relatives à l’authentification forte des clients et les normes ouvertes communes et sécurisées de communication (souvent désignées sous l’acronyme « RTS SCA » de l’anglais Regulatory Technical Standards no Strong Customer Authentication), qui entrent en vigueur en septembre 2019, précisent que les prestataires de services de paiement gestionnaires de comptes (ASPSP, Account Servicing Payment Service Provider) peuvent utiliser une interface dédiée au prestataire tiers, ou adapter leur application de banque en ligne pour la mise en œuvre de l’authentification.
Il existe trois grandes méthodes pour authentifier et autoriser un utilisateur via une interface dédiée :
- La redirection : l’utilisateur est redirigé de l’application FinTech ou de l’application du tiers fournissant un service de paiement vers le serveur d’autorisation de la banque, et renvoyé vers le client FinTech une fois l’autorisation accordée.
- L’approche intégrée : les données d’authentification de l’utilisateur sont échangées entre la FinTech et l’établissement financier via l’interface, ce qui permet à l’utilisateur de consentir à la transaction via le client FinTech.
- L’approche découplée (ou une combinaison des deux) : la banque demande à l’utilisateur d’autoriser le paiement, par exemple via une application mobile dédiée ou toute autre application ou dispositif indépendant du front-end de la banque en ligne.
L’établissement financier choisira la méthode la mieux adaptée aux procédures d’authentification qu’il propose à sa clientèle sur sa propre interface client en ligne.
Sécurisation des couches d’application et de transport en réponse aux exigences de la Directive DSP2 concernant l’authentification forte des clients (RTS SCA)
L’authentification et l’autorisation du client (autrement dit, l’utilisateur de services de paiement ou « USP » dans le langage de la Directive sur les services de paiement DSP2) reposent sur un niveau de sécurité plus poussé. L’objectif étant de s’assurer que la FinTech ou le tiers fournissant des services de paiement, l’établissement financier (le « service de paiement gestionnaire du compte » également appelé « ASPSP » dans la DSP2) et les messages qu’ils s’échangent sont bien ce qu’ils prétendent être.
Le Framework NextGenPSD2 du Berlin Group décrit une interface d’accès aux comptes (XS2A) basée sur une API. Le framework comprend une couche d’application et une couche de transport.
- La couche Application comprend les définitions des services de compte et les modèles de données pour les services de base et les services étendus.
- La couche Transport englobe la composition des messages et le mécanisme d’échange de messages.
Au niveau de la couche applicative, on utilise, à des fins d’identification, des certificats qualifiés pour cachets électroniques afin de sécuriser les données et les documents provenant du prestataire de services de paiement (c.-à-d. la FinTech ou l’établissement financier). Le cachet garantit l’authenticité du document ou des données — en confirmant que le document ou les données proviennent bien du prestataire de services de paiement et n’ont pas été modifiés. Conformément au règlement eIDAS, les certificats qualifiés sont délivrés par un prestataire de services de confiance qualifié (PSCQ). Sur le certificat doivent figurer tous les rôles que la FinTech est autorisée à exercer ainsi que son numéro d’autorisation délivré par une autorité nationale compétente (ANC).
Au niveau de la couche Transport, la communication entre la FinTech et l’établissement financier est sécurisée par une connexion TLS. Selon les normes techniques de réglementation, un certificat qualifié pour l’authentification de sites Web doit être émis par un prestataire de services de confiance qualifié, comme le requiert le règlement eIDAS.
Une architecture de référence pour les ASPSP et les PSP
La réussite de l’intégration repose sur la fourniture de certains éléments par les établissements financiers et la FinTech :
Le client utilise une interface Web ou une application client fournie par la FinTech.
La FinTech s’appuie sur les moyens suivants pour fournir ses services :
- un serveur Web qui héberge l’application client utilisée par le client ;
- un serveur d’identité pour authentifier son client ; et
- un serveur de signature pour demander un certificat DSP2 qualifié au prestataire de services de confiance qualifié.
L’établissement financier autorise la FinTech à accéder à certaines données clients en procédant comme suit :
-
• Exposition de ses services par le biais de l’interface d’accès sécurisé aux comptes (XS2A) via la passerelle API
• Vérification de l’identité et de l’intégrité de la FinTech et de ses messages au moyen d’un certificat qualifié DSP2
• Recueil du consentement du client au partage de ses informations via le serveur d’autorisation
• Ouverture de l’accès aux données clients contenues sur son serveur de ressources
Le prestataire de services de confiance qualifié (PSCQ) est le garant de la sécurité du partenariat entre l’établissement financier et la FinTech :
- Confirmation d’enregistrement de la FinTech auprès de l’autorité compétente dans l’État membre de l’UE de la FinTech
- Fourniture de certificats qualifiés à la demande de la FinTech
- Fourniture de certificats qualifiés contenant toutes les données exigées par la DSP2
- Révocation des certificats sur demande de la FinTech (objet du certificat) ou de l’autorité nationale compétente
Application de l’architecture de référence à l’établissement de partenariats Open Banking
L’architecture de référence décrite ci-dessus constitue la trame d’une stratégie visant à faire rimer interopérabilité avec sécurité pour permettre aux FinTech et aux établissements bancaires traditionnels d’élargir leur offre client. Le succès de leur démarche dépendra de leur capacité à :
- attirer des partenaires et développer davantage d’options visant à améliorer le parcours client ;
- faciliter la tâche des clients pour qu’ils puissent aisément consentir (ou retirer leur consentement) au partage sécurisé d’informations sensibles avec leurs partenaires et des fournisseurs tiers ; et
- s’assurer que ces partenaires et fournisseurs utilisent de puissantes fonctionnalités de cybersécurité pour protéger les informations clients partagées.
Dans mon prochain billet, j’examinerai les options d’implémentation de chacune des briques de l’architecture de référence pour répondre aux exigences des normes techniques de réglementation (RTS) de la DSP2 en matière de cybersécurité.
Pour en savoir plus sur la Directive DSP2 et l’authentification forte des clients (SCA), y compris les dates à retenir, je vous invite à consulter notre page dediée — Tout savoir sur la DSP2.
À propos de l’auteur
Consultant et formateur, Jon Scheele aide les établissements financiers 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.
