Banques et fintech : le calendrier de leur entente forcée

Banques et fintech : le calendrier de leur entente forcée L'entrée en vigueur le 13 janvier 2018 de la directive européenne sur les services de paiement, plus connue sous le sigle DSP2, n'est qu'un début. D'autres échéances sont à venir.

En 2018, les institutions financières devront être sur tous les fronts réglementaires. Révision de la directive sur les marchés d'instruments financiers (MiFID 2), règlement européen sur la protection des données (RGPD), révision de la directive européenne sur les services de paiement (DSP2)… Cette dernière qui entrera en vigueur le 13 janvier 2018 obligera les banques à partager les données de leurs clients à des acteurs tiers, dont les fintech. Mais cette date est plutôt symbolique. Les parties concernées attendent de pied ferme une autre échéance : la publication des normes techniques réglementaires (RTS) qui doit être rendue publique par la Commission européenne dans les jours à venir.

Ces standards sont au cœur de la DSP2 car ils déterminent la façon dont les fintech se connecteront aux banques. A ce jour, elles utilisent le screen scraping, une technique qui permet d'accéder aux données d'un client d'une banque en utilisant ses codes d'accès. Cette méthode est décriée par les banques car jugée peu sécurisée. Sans grande surprise, les RTS imposeront l'utilisation d'API, une interface de programmation qui permet à des applications de communiquer entre elles. Ces RTS ne seront pas applicables dans l'immédiat. Ils doivent encore être votés par le Parlement européen dans un délai maximal de trois mois. Et peuvent donc être rejetés. Peu enclines à partager leurs données, "les banques vont tout faire pour que le texte ne passe pas. Du coup, on repartirait de zéro et cela prendrait plusieurs mois pour publier de nouveaux RTS", s'inquiète Joan Burkovic, CEO de l'agrégateur Bankin'. Si les RTS sont finalement votés, il faudra encore attendre 18 mois pour leur entrée en vigueur, soit à en septembre 2019.

Janvier 2018 : décrocher un agrément

Les agrégateurs et les initiateurs de paiement (des entreprises qui fournissent des solutions de paiement pour l'e-commerce) doivent quant à eux être conformes sur plusieurs points pour le 13 janvier 2018. Tout d'abord, ils  doivent obtenir un agrément d'établissement de paiement auprès de leur régulateur local. Depuis plusieurs mois, les fintech françaises concernées multiplient les échanges avec le régulateur. "Nous avons soumis notre dossier à l'ACPR. Normalement, nous serons des établissements de paiement dès janvier 2018. Par conséquent, nous devrons faire des reporting, nous aurons des procédures particulières… C'est assez lourd mais les potentiels partenaires et les utilisateurs qui hésitaient encore à s'inscrire sur notre application car ils considéraient notre activité illégale et non sécurisée vont être rassurés", estime Joan Burkovic. Côté banques, pas besoin de faire de dossiers puisqu'elles ont déjà des licences bancaires.

"Nous espérons que les banques iront plus vite que l'horizon 2019 car nous voulons tester leurs API avant"

Début 2018, les tiers de paiement pourront accéder aux données de paiement des consommateurs par le screen scraping ou par API (si la banque en propose déjà). "Nous continuerons à opérer de la même façon mais la sécurité sera reconnue puisque nous seront régulés. La seule différence est que nous serons désormais authentifiés par les banques alors qu'aujourd'hui nous accédons aux données de façon anonyme", précise Joan Burkovic.

La DSP2 imposera quelques adaptations mineures pour les deux camps. "Par exemple, nous devons mettre en place des procédures pour permettre des remboursements à J+1 en cas d'incident de paiement sauf si le TPP (tiers de paiement, ndlr) est responsable. Il doit alors rembourser immédiatement la banque ", illustre Franck Oniga, directeur marketing de La Banque Postale.

Janvier 2018 à septembre-2019 : les API en test

C'est durant les 18 mois qui suivront le vote du Parlement que les choses sérieuses commenceront. Les banques auront ce laps de temps pour lancer leurs API afin que les fintech s'y connectent. "Ce délai de 18 mois est suffisant. Nous arriverons facilement à nous adapter aux disponibilités de l'API", estime Bruno Van Haetsdaele, CEO de l'agrégateur Linxo. "Nous espérons que les banques iront plus vite que l'horizon 2019 car nous voulons tester leurs API avant", espère de son côté Jérôme Traisnel, CEO de Slimpay, spécialiste du paiement par prélèvement.

"Rien n'empêcherait La Banque Postale de brancher ses API à des systèmes de réservation d'hôtel" 

Pour les banques, ces 18 mois ne seront pas de tout repos. "Nous allons procéder à "l'APIsation" de plusieurs systèmes d'informations. Cela va nous permettre de renforcer nos applicatifs et de sécuriser les nouveaux acteurs qui accèdent au compte", souligne Franck Oniga. La Banque Postale envisage de donner accès à son API de paiement le plus rapidement possible, sans donner de date précise. Elle étudie des pistes pour se lancer dans l'initiation de paiement ou dans l'agrégation. "Rien ne nous empêcherait de brancher nos API à des systèmes de réservation d'hôtel. Par exemple, il serait possible de réserver une chambre d'hôtel depuis une banque en ligne", imagine le dirigeant.

De leur côté, les fintech pourront utiliser les API au fur et à mesure qu'elles apparaîtront sur le marché. "Nous avons six mois pour tester chaque API. Si ces tests ne sont pas concluants, elles pourront être rejetées par une commission qui rassemble banques et fintech au niveau européen. Dans ce cas, nous continuerons à faire du screen scraping", explique Joan Burkovic.

Septembre 2019 : le début des API

Si les API des banques sont disponibles en septembre 2019, les fintech pourront s'y connecter et profiter de plus d'avantages qu'avec le screen scraping. "Les API vont nous permettre d'accéder à des informations du compte qui peuvent être pertinentes. Par exemple, quand quelqu'un paiera avec une carte bancaire, on pourra créer un automatisme pour vérifier s'il a suffisamment d'argent sur son compte. Cela nous permettra de diminuer le risque de non-paiement", illustre le patron de Slimpay. "Si les API fonctionnent, et ce dans toute l'Europe, nous pourrons connecter plus de banques dans plus de pays et fournir un service plus stable. De plus, l'API est un gain de temps énorme. On diviserait par quatre le temps de développement", se réjouit Joan Burkovic.

"On trouve que l'API est une bonne technologie mais à condition qu'elles nous permettent de faire ce qu'on fait actuellement"

Ce système d'API a cependant deux inconvénients pour les fintech. A commencer par le contenu des API elles-mêmes. "Avec le screen scraping, on peut tout faire. On ne sait pas si avec les API on pourra accéder à un portefeuille d'informations pertinentes", note Jérôme Traisnel. "On trouve que l'API est une bonne technologie mais à condition qu'elles nous permettent de faire ce qu'on fait actuellement. Nous devons être sûr que les données soient à jour", renchérit le patron de Linxo.

Deuxième bémol : les API ne concerneront que les données de paiement. "Pour nos services le paiement n'est pas suffisant. Nous avons besoin d'avoir accès aux comptes d'épargne, aux informations relatives aux crédits…", regrette Bruno Van Haetsdaele. "En général, 80% des comptes connectés sur les agrégateurs ne sont pas des comptes de paiement. On va donc continuer à faire du screen scraping non authentifié pour les autres comptes. On va devoir se battre point par point. Cela va encore durer des dizaines d'années", estime Joan Burkovic.

La Banque Postale a de son côté prévu d'étendre son API à d'autres données que le paiement. "Nous voulons APIser l'ensemble de nos chaînes. Cela nous permettra de créer des passerelles plus directes avec nos propres filiales et créer plus de valeur avec les fintech, qui sont des partenaires", indique Franck Oniga. "Notre objectif est de tout APIser à l'été 2019", conclut-il.