OPEN BANKING

L’application de la directive des services de paiement -DSP2- contraint les banques à faire évoluer leur système d’information dans le cadre de nouveaux services aux consommateurs, clients des banques.

De nouveaux services sur les comptes sont fournis par des Fintech dénommés Third Party Providers -TPP.

Les TPP fournisseurs de services d’information sont des Account information service providers -AISP- plus généralement appelés agrégateurs de comptes.De même les TPP peuvent être des prestataires de services d’initiation de paiement -PISP-  pouvant initier des ordres sur des comptes tenus par d’autres établissements.

Les Card Based Payment Instrument Issuer – CBPII-  utilisent les cartes de paiement reliées au compte bancaire et doivent s’assurer de la disponibilité des fonds auprès de la banque avant chaque transaction.

Pour les banques, devenues Account Servicing Payment Service Providers – ASPSP-, le passage d’un modèle « client-banque » à un modèle « Client-TPP-Banque » accroît la vulnérabilité des systèmes ce qui exige un nouveau modèle de confiance.

Ainsi le client doit donner l’autorisation à sa banque (ASPSP) d’accorder à un TPP l’accès à ses données de compte sans divulgation de ses identifiants de connexion. De fait, la gouvernance et les contrôles de sécurité des informations doivent être renforcés afin que les clients soient protégés lors d’appels aux services d’intermédiaires des TPP.

Les ASPSP doivent respecter ces nouvelles contraintes réglementaires liées à la cybersécurité et au partage de données. Elles doivent fournir les accès via une série d’API sécurisées et standardisées, permettant à leurs clients d’accéder à leurs informations de compte et d’effectuer des paiements.

Les API seront connectées à leur Core Banking afin de fournir ces services informations sur les comptes de leurs clients selon le concept de l’OPEN BANKING.


CERTIFICATS eIDAS

Pour assurer le niveau de sécurité requis par la DSP2, les banques et les TPP doivent réciproquement s’équiper de certificats électroniques.

Le certificat eIDAS QWAC (Qualified Website Authentication Certificate)  permet aux serveurs d’un TPP et d’une banque de s’authentifier mutuellement et de maintenir les communications chiffrées.

Le certificat eIDAS Qseal (Qualified electronic Seal Certificate) permet aux serveurs d’un TPP et d’une banque de sceller le contenu d’une transaction. Ces certificats sont fournis par des tiers de confiance QTSP (Qualified Trust Services Providers)

La vérification réciproque de l’identité des deux acteurs permet la poursuite du processus  jusqu’à la finalité de l’opération souhaitée : consultation ou paiement. Elle permet d’assurer la traçabilité des échanges et de garantir une authentification mutuelle entre les deux parties.


AUTHENTIFICATION FORTE

L’authentification forte est la combinaison de deux facteurs d’authentification, minimum, parmi les trois catégories suivantes : possession (smartphone, appareil connecté, etc), connaissance (mot de passe, question secrète, etc) et inhérence (empreinte digitale, reconnaissance faciale, etc)

L’authentification numérique, et en particulier l’authentification forte, permet de créer ce socle de confiance. Elle apporte un niveau de garantie élevé quant à la personne (physique ou morale) rattachée à une identité numérique. Contrairement à une authentification dite « faible », elle participe à la création d’une identité qui réduit les risques d’usurpation, rendant les transactions électroniques plus sûres.


API

L’Autorité bancaire européenne (ABE) a défini les normes techniques réglementaires (RTS) et fait le choix de privilégier des API comme solutions d’accès aux comptes de paiement par les agrégateurs et les initiateurs de paiement au sein de l’Union européenne. Une API (Application Programming Interface) est une interface d’échange de données entre deux applications via internet.

L’Open Banking va faíre évoluer le  modèle traditionnel  économique des banques à travers l’usage des APIs.

Par rapport au web scraping la normalisation des APls  va renforcer  la  sécurité  et automatiser les processus au sein des services financiers.

En France, l’opérateur de clearing STET a défini, à l’initiative de la FBF,  les API et leurs spécifications définissant un protocole de communication et un échange commun des données entre les différents acteurs. En Europe, d’autres opérateurs ont adopté la même démarche : Berlin Group.

Différentes autorisations peuvent être utilisées, selon le rôle du TPP et le cas d’utilisation à appliquer. Le protocole OAUTH2 est appliqué en vérifiant l’identité du TPP pendant les procédures OAUTH2 via le certificat eIDAS du TPP.

Trois approches différentes peuvent être utilisées par un TPP pour permettre l’authentification du client par l’ASPSP. Ces approches reposent sur une identification du client reconnues par l’ASPSP.


SIB

fournit des API aux ASPSP permettant la prise en compte des requêtes des TPP en :

fournissant une authentification sécurisée croisée entre le TPP et l’ASPSP,

donnant un accès aux TPP via un système OAuth2,

permettant une gestion du consentement des clients au vu du rôle du TPP,

contrôlant la validité d’accès du TPP et son droit sur les différentes données des clients ou actions possibles,

fournissant les informations du client selon le rôle du TPP.