DSP2 Deadline le 14 Mars: Les Questions à Se Poser
Prêts ou non, voici la première deadline pour la directive DSP2
Il y a un an, le 12 janvier 2018, tous les États membres de l’UE avaient obligation de transposer en loi nationale la directive révisée sur les services de paiement (DSP2) Aujourd’hui, les banques voient arriver la première des deux deadlines de mise en conformité avec les normes techniques de règlementation imposées par la DSP2.
- Pour donner aux tiers au moins six mois pour tester l’autorisation des services de paiement, toutes les banques doivent mettre en place un environnement « sandbox » de test qui inclut API, documentation et support, avant le 14 mars 2019.
- La deadline finale de mise en conformité avec la directive DSP2 est fixée au 14 septembre 2019; cela inclut notamment une authentification client forte, un accès aux comptes (XS2A) et une multitude d’autres exigences.
Que doivent précisément mettre en place les banques avant le délai du 14 mars?
Une installation de test disponible pour le public, communément appelée environnement « sandbox », avec API sécurisées, documentation et support.
Que se passe-t-il si vous ne respectez pas le délai DSP2?
Si vous ne parvenez pas à mettre en place l’environnement sandbox requis, vous devez fournir un « mécanisme de contingence » permettant aux fournisseurs tiers (TPP) d’accéder aux données de comptes clients, comme autorisé par la DSP2. Il peut s’agir d’une interface web ou mobile dédiée, adaptée à l’utilisation par des tiers et se limitant à certaines fonctions de l’interface numérique globale du consommateur.
La majorité des banques n’étant pas ouvertement portées à approuver la capture des données d’écran, ce « mécanisme de contingence » n’est pas réellement une option idéale pour vous. Vos clients n’apprécient pas nécessairement l’insécurité, mais sans API financières sécurisées en place, les clients bien au fait de la finance et du numérique vont continuer à utiliser les applications fintech orientées clients des fournisseurs tiers. Et pour ce faire, ils vont continuer à donner leurs identifiants bancaires.
Vos API de test sont-elles déjà en place?
OUI. Quelle est la prochaine étape?
Félicitations ! Maintenant que les API, la documentation et le support sont en place, vos API sont-elles sécurisées ? Il est important que vous évaluiez vos composants actuels de gestion des accès et de sécurité afin de vous assurer qu’ils sont spécifiquement capables de protéger les ressources API, étant donné que la plupart des systèmes WAM existants ne le sont pas.
Si vous voulez d’abord savoir à quoi ressemble la sécurité des API modernes, côté client et côté back-end (notamment workflows OpenID Connect et OAuth), nous avons créé une Quickstart Private Sandbox for DSP2 afin d’accélérer les tests pratiques et le déploiement des exemples d’applications fintech client et de plusieurs composants clés de la plateforme Ping Intelligent Identity visant à protéger les API bancaires. Et au-delà des flux de sécurité OAuth, de nombreuses entreprises prennent en main la surveillance du trafic API et de la cybersécurité grâce à l’IA.
NON. J’ai besoin de trouver un partenaire de confiance.
Le délai approchant rapidement, nous ne recommandons pas de créer vous-mêmes les API et le profil de sécurité. Le chemin le plus court vers la conformité consiste à trouver la bonne combinaison de partenaires technologiques en mesure de vous fournir un ensemble prêt à l’emploi d’API financières sécurisées. Le réseau mondial de partenaires Ping compte des sociétés technologiques dédiées, spécialisées dans la finance, au service des banques. Beaucoup d’entre elles ont créé des plateformes ou proposent une couche API/portail, souvent en tant que service géré avec toutes les API conformes à la directive DSP2 dont vous avez besoin avant la date limite.
Ces sociétés technologiques peuvent accélérer l’obtention des API dont vous avez besoin, mais leur sécurisation reste un composant important. Et c’est là le rôle principal de Ping. Plutôt que de créer entièrement un système de gestion de la sécurité et des accès, nombre de ces sociétés utilisent les fonctionnalités Ping comme composant de sécurité, soit en marque blanche soit ouvertement proposées par la plateforme Ping. Ping aide les banques à explorer le paysage des partenaires technologiques de la finance afin de trouver la solution adéquate et l’expertise nécessaire pour accélérer la mise en conformité avec la directive DSP2.
Quel format d’API adoptez-vous?
La critique la plus courante faite au sujet de la directive DSP2 est qu’elle oblige les banques à fournir des API ouvertes sans spécifier de format standard à l’échelle de l’UE. Si chaque banque développait sa propre interface API propriétaire, il en résulterait d’énormes coûts et une immense complexité en termes de réseau. Plusieurs initiatives en Europe et dans le reste du monde permettent donc de spécifier et de standardiser les formats d’API.
OAuth 2.0 et OpenID Connect (OIDC) constituent la base de nombreuses initiatives de standardisation d’API dans différents secteurs. Il existe toutefois de légères différences parmi les principales structures de standardisation d’API qui ont fait leur apparition spécifiquement dans le domaine de la finance, comme OpenID, Open Banking (R.-U.), the Berlin Group, Financial Data Exchange, ou d’autres encore.
OpenID FAPI
La spécification FAPI (Financial-grade API) a été ébauchée par un groupe de travail international constitué de techniciens qui sont leaders d’opinion en définition de normes de sécurité des identités pour les principaux cas d’usage, dans le monde entier. Pour les spécifications financières, ils travaillent à modéliser des API pour la sécurité et la confidentialité, notamment protection avec jetons OAuth sécurisés et recommandations de schémas de données REST/JSON. Ce travail de standardisation effectué par le groupe présente l’avantage de n’être associé à aucune motivation politique ou économique régionale spécifique, puisqu’il s’agit d’une communauté mondiale ouverte de développeurs, fournisseurs et utilisateurs.
Open Banking Standard
Si vous êtes au Royaume-Uni, inutile pour votre sécurité de chercher au-delà de l’Open Banking Standard. Souhaitant anticiper l’avenir et dans un souci d’indépendance face à la menace planante du Brexit, les grandes banques du Royaume-Uni ont formé l’Open Banking Implementation Entity, chargée de définir une norme, de gérer un registre fiable pour toutes les banques et tous les tiers concernés et de certifier la conformité afin que tous les acteurs puissent interagir de manière sécurisée. L’Open Banking respecte aussi strictement les attributs ISO20022 et les exigences RGPD en matière de minimisation des données.
L’utilité de l’Open Banking Standard ne se limite pas au Royaume-Uni: grâce à son adoption rapide et à sa maturation constante, de nombreux leaders d’opinion dans le monde utilisent cet Open Banking Standard comme tremplin pour définir leur propre norme légèrement modifiée. Une autre chose à noter est que l’Open Banking Standard est de plus en plus aligné avec la spécification FAPI dans la durée. On pourra certainement très bientôt dire que l’Open Banking Standard et la spécification FAPI sont essentiellement la même chose.
NextGenPSD2 du Berlin Group
The Berlin Group, une initiative européenne qui regroupe banques et processeurs de paiement, a créé le cadre Access to Account (XS2A) reposant sur les exigences de la directive DSP2 et des normes techniques règlementaires de l’EBA. Ce cadre présente une belle flexibilité en termes de formats de messages au-delà de JSON et de l’expérience utilisateur. Tandis que FAPI et Open Banking sont des normes prescriptives sur les API, NextGenPSD2 est un cadre plus flexible permettant de créer vos propres normes.
Il inclut le modèle de données (au niveau des données conceptuelles, logiques et physiques) et les messages associés pour chacun des cas d’usage mentionnés dans la DSP2, y compris la confirmation des fonds. Ce cadre est davantage apprécié des FinTechs que l’Open Banking Standard, car il possède un ensemble standard de champs de données légèrement plus complet, inclus dans les API de la banque, ainsi que la possibilité pour les banques de demander des attributs de données supplémentaires avec approbation par le Berlin Group.
Norme Durable Data API (DDA) du Financial Data Exchange
Le Financial Data Exchange (FDX) a été lancé en octobre 2018 pour accompagner la norme Durable Data API (DDA). L’objectif était de simplifier et de sécuriser, pour les consommateurs, l’utilisation des données et des applications financières, et de les aider à prendre de bonnes décisions. Aux États-Unis, les consommateurs se préoccupent énormément des questions de sécurité et de confidentialité liées aux données financières. Selon une enquête menée en août 2018, 67 % des personnes interrogées se sont déclarées « extrêmement préoccupées » ou « très préoccupées » de la confidentialité des données lors de l’utilisation d’applications fintech et 56 % ont souhaité pouvoir contrôler quels comptes et quels types de données sont accessibles aux tiers.
La majorité des membres du FDX se trouvent aux États-Unis, où aucune règlementation n’impose aux banques des API ouvertes. Toutefois, la plupart des établissements financiers s’accordent pour dire que la capture des données d’écran n’est pas sécurisée et que des API standard constituent une solution appropriée. Cette nouvelle norme répond à toutes les exigences de la DSP2, intègre OAuth 2.0 et peut être utilisée par les banques, les agrégateurs de données, les fintechs, ainsi que par les sociétés d’assurance, les courtiers/revendeurs, etc.
API DSP2 du STET
Le STET, qui appartient à six grandes banques françaises, a créé une API DSP2 v1.4 permettant aux ASPSP européens de mettre en œuvre un ensemble de services simples et sécurisés, côté serveur. Le STET collabore activement avec de nombreux acteurs et autres initiatives de standardisation dans l’UE, dans l’objectif de disposer d’une API DSP2 de qualité qui apportera satisfaction à tous les acteurs européens.
Elle offre des fonctionnalités pour l’authentification, l’autorisation, la gestion des preuves et la détection des fraudes ; elle a été créée selon les normes technologiques les plus récentes avec REST, OAuth2, JSON et signature HTTP. Elle repose sur des éléments ISO20022 pour structurer les données à échanger entre TPP et ASPSP.
Polish API Standard
La norme Polish API Standard est la réponse du secteur des paiements polonais à la nécessité de renforcer l’innovation financière en Pologne de manière durable et non discriminatoire. Elle vise à réduire les coûts de mise en œuvre de la DSP2 pour les ASPSP et les TPP. Les créateurs de cette norme pensent que de nouvelles versions seront en constant développement afin de suivre l’évolution des marchés polonais et européen. À noter : PolishAPI Standard est peut-être la seule norme de l’UE qui n’embrasse pas l’idée des API RESTful (au moins dans sa version initiale).
Ping Identity participe à l’élaboration des normes API
La flexibilité de la plateforme Ping Intelligent Identity et notre participation aux processus de définition des normes sur l’identité numérique garantit, quel que soit le modèle d’API standard choisi (leurs objectifs sont similaires), que Ping Identity va rester un partenaire de confiance pour les établissements financiers, aujourd’hui et à l’avenir. Nous assurons actuellement une conformité totale à la spécification FAPI 2 et à l’Open Banking v2 et nous travaillons sur des tests de conformité pour l’Open Banking v3. Étant donné que NextGenPSD2 du Berlin Group rassemble de nombreuses approches, Ping peut vous aider à définir l’approche à adopter et la technologie qui lui correspond.
Pour en savoir plus sur ce que Ping Identity peut proposer comme solution DSP2 à votre banque, découvrez comment bénéficier d’une pleine expérience client via la conformité DSP2 ou consultez le guide des solutions techniques pour savoir comment mettre en place une stratégie de sécurité via les API financières.