Dans quelle mesure la DSP2 est-elle compatible avec les « Fintech » ?

Le secteur émergent des « Fintech » (entreprises de technologie financière) d’Europe continentale est actuellement confronté à plusieurs défis posés par la directive révisée sur les services de paiement (DSP2). J’évoque ici les plus importants de ces défis et tente de proposer des solutions potentielles.

L’aspect le plus caractéristique des « Fintech » est qu’elles sont capables de comprendre les besoins des clients et de concevoir rapidement de nouveaux services sur un marché financier autrement traditionnel.

Selon moi, trois raisons principales expliquent pourquoi les « Fintech » sont capables de répondre aussi rapidement aux besoins des clients :

elles sont réactives grâce à leur mentalité sobre et agile ;
elles proposent des processus numériques simples, mais efficaces ;
elles sont entièrement axées sur la résolution d’un ensemble restreint de problèmes clients.

Toutefois, est-ce suffisant pour résoudre les problèmes engendrés par la DSP2 ?

Investissez dans la confiance

Avant la DSP2, le seul moyen de collaborer avec une banque consistait à établir des partenariats à long terme ou à recourir à des méthodes « alternatives » telles que le screen scraping*. La DSP2 uniformise les règles du jeu en offrant un accès plus aisé aux comptes de paiement des clients. Cela signifie que les « Fintech » disposent désormais d’un cadre juridique approprié leur permettant d’accéder à certaines des informations dont elles ont besoin pour développer des services innovants.

Certaines banques sont encore réticentes à l’idée de collaborer avec des « Fintech » qui agissent en tant que prestataires de services de paiement tiers (PSPT)** en raison des différents niveaux d’appétit pour le risque. Dans cet environnement de plus en plus sensible aux questions de sécurité, les « Fintech » devront donc démontrer la mise en œuvre de mesures organisationnelles et techniques appropriées pour protéger les données de leurs clients, et ce, afin d’accroître cette confiance.

Par ailleurs, certaines banques craignent de perdre leur avantage concurrentiel en ouvrant certaines parties de leurs systèmes dorsaux. Et on ne peut pas leur en vouloir : un système bancaire ouvert implique d’énormes changements pour les banques. Pas seulement en matière de système, de processus ou de réglementation, mais également sur le plan de la mentalité. L’un des principaux défis consistera à saisir les opportunités au bon moment en tirant parti de réglementations telles que la DSP2.

Les « Fintech » devront également investir énormément de temps pour gagner la confiance des clients des banques. Ceux-ci veulent savoir à quoi serviront leurs données financières et dans quel but elles seront utilisées. D’aucuns pourraient être effrayés à l’idée de laisser un nouvel acteur du marché accéder à leurs comptes bancaires. Il faudra donc du temps pour établir une relation de confiance avec ces clients. Cependant, il est crucial que les « Fintech » gagnent cette confiance. Le jeu en vaut la chandelle.

Se mettre en conformité et le rester

Une « Fintech » qui agit en tant que PSPT et qui souhaite obtenir un accès direct aux données des clients devra se conformer à plusieurs législations et réglementations européennes.

Dans le domaine des services de paiement, les trois principales réglementations concernées sont la DSP2, la directive anti-blanchiment (un ensemble de règles visant à lutter contre la fraude et le blanchiment de capitaux dans l’UE) et le règlement général sur la protection des données (RGPD), le règlement européen de 2018 qui vise à harmoniser les législations relatives à la protection des données personnelles.

Chacune de ces réglementations engendre des défis qui lui sont propres, ce qui rend leur mise en œuvre extrêmement compliquée, notamment en raison de plusieurs divergences entre ces différentes réglementations.

De manière générale, je conseille aux « Fintech » de prendre en compte les recommandations suivantes :

obtenez et traitez le consentement et l’autorisation des clients de manière transparente ;
traitez les paiements transférés et les données personnelles de manière sécurisée ; ne cherchez pas à réinventer la roue et choisissez des méthodes éprouvées par le secteur ;
définissez les responsabilités, car la DSP2 n’exige aucune relation contractuelle entre les banques et les PSPT ; une « Fintech » agissant en tant que PSPT doit garantir un niveau approprié de sécurité des données ;
évaluez et mettez en place les contrôles et processus anti-blanchiment pertinents aux bons endroits de la chaîne DSP2 ;
documentez correctement les rôles et responsabilités de chacun des maillons de la chaîne ;
n’oubliez pas que le régulateur local peut vous contrôler à tout moment…

Pas de normes API pour les banques

Les « Fintech » feront ce que fait chaque start-up : elles choisiront la voie qui oppose le moins de résistance. Si elles trouvent une solution d’intégration bancaire de qualité équivalente, mais plus rapide qu’une solution qui les forcerait à s’occuper elles-mêmes de la mise en œuvre, la plupart privilégieront cette première option. C’est la valeur ajoutée que des agrégateurs d’API*** tels qu’Ibanity peuvent apporter. Certains PSPT investiront le temps et l’argent nécessaires pour s’intégrer à chaque banque séparément. Gardez toutefois à l’esprit qu’il n’existe actuellement aucune norme belge ou européenne faisant consensus concernant les API bancaires. Cela signifie que chaque intégration est nouvelle et potentiellement unique. Les « Fintech » ne doivent pas perdre leur temps. L’activité principale de la plupart des « Fintech » ne doit pas être l’intégration bancaire. Elles doivent se concentrer sur la prestation de services financiers conviviaux et sur la résolution de problèmes clients spécifiques.

Du point de vue de la conformité, la collaboration avec des agrégateurs ou de grands PSPT pourrait être la solution pour les « Fintech » qui souhaitent externaliser les processus liés à la conformité. Toutefois, cela ne signifie pas que les « Fintech » peuvent ignorer leurs obligations les plus élémentaires, car elles restent responsables. Elles doivent donc veiller à trouver le bon équilibre au moment de sous-traiter ces processus.

Les experts DSP2 d’Isabel Group au sein d’Ibanity ont préparé un livre blanc gratuit sur les consentements et autorisations dans les agrégateurs d’API (EN).

* Le screen scraping (capture de données d’écran) consiste à collecter les données d’affichage d’une application et à les convertir afin qu’une autre application puisse les afficher. Ce procédé sert habituellement à capturer les données d’une application existante afin de les afficher à l’aide d’une interface utilisateur plus moderne (comme l’explique, en anglais, le site Techopedia).

** Les prestataires de services de paiement tiers (PSP) sont des prestataires de services de paiement moins traditionnels comme iDEAL, PayPal et Amazon Payments.

*** Une interface de programmation applicative, plus connue sous l’acronyme API (pour Application Programming Interface), fait partie d’un serveur qui reçoit des demandes et envoie des réponses. Il s’agit essentiellement d’un moyen de communication entre serveurs (Petr Gazarov explique très clairement, en anglais, de ce dont il s’agit).