Actualités

Akerva

Faites l’expérience de la sécurité active & réactive

Presse

[ PRESSE ] L’Open Banking mode d’emploi

Presse | 06/06/2019 Publié dans Informatique News, le 5 juin 2019 Le cabinet ce conseil en cybersécurité Akerva explique le contenu de la directive de la DSP2, dont le premier...

Publié dans Informatique News, le 5 juin 2019

Le cabinet ce conseil en cybersécurité Akerva explique le contenu de la directive de la DSP2, dont le premier rendez-vous important s’est joué le 14 mars 2019, avec l’ouverture des API bancaires aux Tiers de paiement.

Nous y sommes… Le premier rendez-vous important avec la DSP2 était ce 14 mars 2019, date à laquelle les APIs bancaires se sont ouvertes aux Tiers de Paiement. Le moment opportun pour faire le point sur les travaux de conformité, à 6 mois de l’entrée en vigueur du RTS (Regulary Technical Standards).

Qu’est-ce que la DSP2 ?

Émise en abrogation de la première Directive sur les Services de Paiement, la DSP2 s’inscrit dans une politique globale de convergence vers un marché unique européen. Sa déclinaison en France est particulièrement attendue, au sein d’une concurrence des établissements financiers à la suite de l’avènement de la loi macron sur la mobilité bancaire. De manière intrinsèque, la directive met en relief plusieurs cas d’usage dont deux principaux.

Consultation et paiement en ligne

L’un des avantages des agrégateurs réside dans la consolidation des informations d’un client. L’agrégateur contacte par des canaux sécurisés les différentes banques du client pour obtenir les données à afficher. Dans cette cinématique, le client est authentifié, soit par sa banque via un mécanisme de redirection, soit suivant une « approche embarquée » à l’initiative de l’agrégateur.

Les Tiers de Paiement (TPP) pourront en effet initier des paiements à la demande de leurs utilisateurs. Ces derniers reçoivent ensuite un élément de validation de la transaction, renvoyé à la banque par l’intermédiaire du TPP. L’approche est dite découplée.

La directive vise en outre une transformation en profondeur du Business Model bancaire, en mettant l’accent sur deux enjeux majeurs :

– L’ouverture du marché à de nouveaux acteurs de la FinTech
Le client pourra bénéficier d’une offre de service plus large, avec des moyens de paiement rapides et à moindres coûts, une comparaison des frais appliqués par ses banques, une vision consolidée de ses comptes, des simulateurs budgétaires… Autour d’une concurrence saine et « bien encadrée » entre les acteurs de la monétique.

– L’authentification forte et la sécurisation des communications
Le partage des données bancaires des clients (solde, historique des transactions…) nécessite une authentification tous les 90 jours et un consentement explicite. De plus, tout paiement d’un montant supérieur à 30 euros est assujetti à une authentification forte, en fournissant deux des trois critères suivants : ce que le client connaît (mot de passe…), ce que le client détient (smartphone, carte à puce…), et ce que le client est (données biométriques, structure osseuse du visage…). Pour chacun de ces traitements, les échanges entre les prestataires de services de paiement gestionnaires de comptes (ASPSP) et les nouveaux acteurs (TPP) doivent être sécurisés de bout en bout.

Grâce à l’exposition des ressources bancaires à travers des APIs, la totalité de l’offre de service est accessible aux agrégateurs (AISP), aux fournisseurs de cartes prépayées (CBPII) et aux initiateurs de paiement (PISP). Les groupes de travaux autour du STET, mandaté pour ériger un cadre d’échanges des parties prenantes de la DSP2 en France, ont permis de choisir le protocole OAuth2 qui répond aux exigences en matière d’authentification et d’autorisation des clients et des TPP.

« On n’y arrivera difficilement… »

Les agrégateurs et initiateurs de paiement ont déjà débarqué sur le marché de la monétique en proposant des solutions innovantes mais basées sur le Web Scrapping des interfaces bancaires. Cette approche présente plusieurs limites : la maintenabilité, l’absence de garantie sur des critères fondamentaux de sécurité tels que l’intégrité des données et surtout la traçabilité.

Par la ratification de cette directive, l’Union Européenne aspire, en toute transparence vis-à-vis des acteurs historiques et des nouveaux acteurs (articles 38 – 60 de la directive), à enrichir l’expérience utilisateur et sollicite les métiers de la cybersécurité pour adresser les problématiques sous-jacentes.

Les conséquences de  la mise en conformité au RTS

– La plupart des banques s’appuient encore sur des standards anciens. La migration vers un modèle basé sur les APIs bouleverse complètement leur fonctionnement actuel, sans parler des investissements lourds à consentir ;
– Les TPP ont perdu une bataille importante dans l’exploitation des zones d’ombre de la directive. L’intérêt de leurs applications se retrouve limité par la limitation de l’historique des transactions consultables à 90 jours
– L’exemption de procédures alternatives (fallback), dont bénéficient les banques en cas de provision d’un service complet et fiable, met en péril le fonctionnement des applications TPP en cas d’indisponibilité des API ;
– Une barrière supplémentaire à laquelle les TPP se heurtent ! L’article 68 de la directive limite l’accès des initiateurs de paiement aux comptes de paiement, sachant que cette cible ne représente que 20% des comptes agrégés
– L’utilisateur s’authentifie et se ré-authentifie encore et encore… La durée maximale d’une session applicative est fixée à 90 jours, forçant ainsi l’utilisateur à s’authentifier de nouveau au-delà… cela peut être usant à la longue
– L’utilisateur va recevoir encore plus de notifications, notamment lorsqu’une transaction est supérieure à 30 euros (article 63)… une raison de plus qui pousse à croire que la directive n’a pas été pensée « utilisateur »

LIRE L’ARTICLE EN ENTIER

Actualités & blog

Restez informé des dernières actualités

RESTEZ INFORMÉ DES ACTUALITÉS AKERVA

ABONNEZ-VOUS À NOTRE NEWSLETTER