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 partiesle Mandats et l’ICS à travers des API ou des Web Services
Les SDD Core en anomalie sont retournés vers le Participant Direct, accompagnés du reason code normalisé SEPA.
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 faire é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.
Les éléments de la solution.
Les ASPSP, ou Banques, doivent gérer les requêtes des TPP pour :
- Permettre une authentification sécurisée croisée entre le TPP et l’ASPSP,
- Donner un accès aux TPP via un système OAuth2,
- Permettre une gestion du consentement des clients au vu du rôle du TPP,
- Contrôler la validité d’accès du TPP et son droit sur les différentes données des clients ou actions possibles,
- Fournir les informations du client selon le rôle du TPP.