Retour petit déjeuner DSP2

Le 9 octobre dernier se tenait dans nos locaux un petit déjeuner sur le thème API et DSP2, l’occasion de revenir sur les dernières évolutions réglementaires, la version 1.4 de l’API STET mais également sur notre API PSD2++. Retour sur cette matinée d’échanges et de rencontres.

Les évolutions introduites par la DSP2

Marc Giordanengo, du cabinet Ailancy, a ouvert cette matinée en nous présentant les (nombreuses) implications fonctionnelles structurantes induites par la DSP2 et le « millefeuille » réglementaire qui s’en suit (RTS, Guidelines de l’EBA, …).  

L’implication majeure est une véritable ouverture à la concurrence poussant les établissements bancaires à ouvrir leur système d’information pour exposer les données clients à des tiers comme Budget Insight via des API.

Le timing de mise en oeuvre de ces API est serré et doit déboucher sur une mise en production en septembre 2019. La mise en production sera précédée d’une phase de test de 6 mois débutant en mars 2019 et qui devra permettre de valider ou non le bon fonctionnement des interfaces mises à disposition par les établissements bancaires.

En parallèle, un mécanisme d’urgence (fallback) doit être mis à disposition si :

  • l’API n’est pas exemptée de fallback
  • l’API préalablement exemptée est indisponible, impliquant ainsi la révocation de l’exemption

Présentation de STET 1.4

Hervé Robache, de la STET, a présenté la version 1.4 de la norme d’API DSP2 poussée par la chambre de compensation.

Il est notamment revenu sur un des changements majeurs introduits par la 1.4 concernant la gestion du consentement.

Alors que l’idée retenue était de laisser à l’ASPSP le soin de présenter, au travers du redirect, la liste des comptes pour lesquels le PSU donne le consentement sur les comptes qu’il souhaite partager à l’AISP, la version 1.4 laisse côté TPP la gestion du consentement.

À noter que dans un mode dit « mixte », l’ASPSP peut réclamer l’information concernant le consentement.

Le TPP indique à l’ASPSP la liste des comptes (représentés par leur IBAN ou tout autre identifiant de compte) pour laquelle le PSU a consenti l’accès aux soldes ou aux transactions.

Cette matinée a également permis de revenir sur une autre évolution notable : l’introduction de la « Trusted Beneficiaries List », la liste d’exemption à la SCA (Strong Customer Authentication) prévue par la DSP2 pour les bénéficiaires de virements.

La mécanique proposée par l’API STET ne consiste pas à manipuler une liste de bénéficiaires vers lesquels les virements peuvent seulement être émis, mais à pouvoir initier des virements vers n’importe quel IBAN, qui seront validés ou non par une SCA en fonction de la présence de celui-ci sur la liste d’exemption.

La présentation de cette nouvelle version a suscité beaucoup de questions de la part de l’auditoire et cela montre une nouvelle fois à quel point les enjeux fonctionnels sont majeurs et dépendants des spécificités de l’API STET.

Le standard PSD2++

Romain Bignon, co-fondateur de Budget Insight, est revenu sur le rôle de la fintech au sein de l’écosystème DSP2. Un focus a été fait sur une nouvelle initiative portée par les TPP, à savoir un nouveau standard d’API, intitulé PSD2++.

En effet, dans l’optique d’accompagner les banques qui feraient le choix de mettre l’ensemble des comptes dans leurs API, ce standard, compatible STET, introduit de nouveaux modèles de données pour les comptes en dehors du scope de la PSD2 (les comptes d’épargne, les comptes titres, les produits d’épargne salariale, les crédits, etc.), mais également des fonctionnalités sur les actes d’achats et de ventes d’actifs, ou encore la gestion de webhooks.

La première release arrivera courant novembre, et sera mise à disposition sous licence Creatives Commons CC-BY au sein d’un dépôt git contenant la spécification OpenAPI Swagger et les guidelines d’implémentation. La spécification suivra les évolutions à venir de l’API STET.

Plus d’informations à venir lors de la parution de la première version !