Pourquoi les banques doivent investir dans l’Open Banking

L’application de la DSP2 sera finalement moins contraignante pour les banques que l’esprit de la directive n’aurait pu le laisser croire. Les RTS (Regulatory Technical Standards) édictés par l’Autorité bancaire européenne (EBA) réclament l’interdiction des pratiques de web scraping des nouveaux acteurs. Dans le même temps, les banques n’auront l’obligation de fournir un accès aux transactions bancaires que quatre fois par jour -un frein pour les agrégateurs puisque les paiements en temps réel seront bientôt introduits dans toute l’Union européenne. Pour se connecter plus souvent aux API des banques, les acteurs-tiers (les agrégateurs de comptes dits AISP, Account Information Service Providers, ou les solutions de paiement pour e-commerçants comme l’allemand SoFort dits PISP, Payment Initiation Service Provider) devront signer un accord bilatéral avec la banque… qui gardera donc le pouvoir de leur faire payer l’accès. Reste aussi à savoir ce qu’il adviendra des comptes d’épargne et de crédit, a priori pas concernés par la DSP2, mais que Bercy compte par exemple bien inclure dans l’application française pour ne pas laisser de zone grise.

Peur de la désintermédiation

Les banques freinent des quatres fers et rechignent à ouvrir leurs données de paiement. “Elles voient l’intérêt pour le consommateurs mais l’équation économique est loin d’être évidente car créer les API et les faire fonctionner va avoir un coût certain”, note Jérémy Borot, de McKinsey. Résultat : si les responsables innovation sont enthousiastes, les décisions volontaristes ont du mal à suivre… D’autant que les départements IT sont peu enclins à engager des chantiers extrêmement coûteux d’APIsation. La peur de la désintermédiation par les nouveaux entrants surpasse les gains possibles. “La majorité des banques hésitent encore à ouvrir leur SI même pour monétiser leurs API ouvertes via des partenariats, confirme Bruno Cambounet vice-président des services bancaires et financiers chez Axway, fournisseur de solutions de gestion d’API. Elles se contentent de se préparer à la DSP2, a minima.”

Vision globale du patrimoine et services BtoB

Pourtant, souligne Jérémie Borot, de McKinsey, “la DSP2 est une très belle opportunité d’offrir un meilleur niveau de services à leurs clients. D’abord, parce qu’en utilisant les API de leurs concurrentes, les banques pourront analyser de manière bien plus précise les comptes des clients et avoir une vue globale de leur activités financière.” Le consultant évoque aussi des opportunités pour le credit scoring ou en BtoB. “Le corporate est le grand oublié de la DSP2. Mais la directive peut permettre aux banques de développer différemment les offres de cash management pour les entreprises par exemple.” Sans compter les apports de business potentiels issus de partenariats noués avec de nouveaux entrants. “Nous voulons révéler la capacité d’emprunt de l’utilisateur donc si une banque veut vendre des prêts via notre application, nous pouvons devenir un apporteur d’affaires”, assure par exemple Joan Burkovic, CEO de l’agrégateur Bankin.

Si les acteurs traditionnels qui s’empressent de se conformer sont rares, les néo-banques, elles, se montrent bien moins frileuses. La britannique Starling a par exemple organisé un hackathon les 7, 8 et 9 avril pour inaugurer le lancement de son API ouverte. C’est le premier établissement de crédit britannique à publier 11 API conformes à la DSP2, pour récupérer des informations ou initier des paiements. Starling espère ainsi greffer de nouveaux services autour de son offre naissante, agrégateurs ou chatbots par exemple.

Aller plus loin dans l’Open Banking

Si la DSP2 initie un mouvement d’ouverture autour des comptes de paiement, les acteurs bancaires devraient par ailleurs déjà réfléchir à élargir le périmètre de leurs API ouvertes. D’abord, parce que le secteur se dirige inexorablement vers l’Open Banking, poussé par le régulateur ou non : les nouveaux entrants misent sur des hubs de fintech pour offrir les meilleurs services à leurs clients tandis que les acteurs traditionnels peinent à développer en interne des offres similaires, malgré leur budget, les acquisitions et les prestations en marque blanche. Mais aussi parce que si en ce qui concerne les paiements, l’ouverture des données à des acteurs tiers agréés présente en effet un danger de désintermédiation sans aucun revenus en contrepartie, dans bien d’autre domaines la banque peut encore garder la main et monétiser ses API.

La néo-banque communautaire allemande Fidor, fondée en 2009 rachetée par BPCE l’an dernier, a été fondée sur l’idéal de l’Open Banking. “Étant une start-up, nous ne pouvons pas tout faire, raconte Sophie Guibaud, vice-présidente pour l’expansion européenne. Nous nous concentrons sur des offres simples, comme le compte courant, des crédits basiques, de l’épargne. Et ensuite, nous misons sur des partenariats construits par le biais de nos API.” Et d’ajouter : “nous ne pouvons pas être pertinent pour toutes les cibles du marché et la désintermédiation nous permet de posséder toutes les offres dont le client peut avoir besoin.” Les développeurs qui souhaitent créer une application commencent à coder dans une “sandbox” de test puis passent par un processus de validation.

Fidor : 50 applications tierces sur sa marketplace

Grâce à ses API, Fidor propose à ses clients des services de paiement P2P, de transfert d’argent à l’international, de change de devises, de crédit à la consommation, de crowdfunding, de crypto-monnaie… “L’intégration est plus ou moins forte. Parfois c’est seulement de l’affiliation et parfois nous allons jusqu’au partage de KYC (Goldmoney et Currencycloud par exemple, ndlr), pour améliorer l’expérience utilisateur”, explique Sophie Guibaud. En d’autres termes, certaines fintech sont totalement intégrées à l’application Fidor, tandis que d’autres sont listées sur sa marketplace Finance Bay (une cinquantaine, en Allemagne). Dans ce cas, Fidor noue des contrats de partage de revenus, en fonction du nombre de transactions ou d’utilisateurs. Et la néo-banque monétise aussi son système d’API par un autre biais : les fintech doivent s’acquitter d’un abonnement à 14,99 euros par mois pour accéder aux API et figurer sur FinanceBay.

CA Store garde le contrôle sur la marque

Certaines banques traditionnelles commencent à faire des efforts d’ouverture. Crédit Agricole a créé le CA Store en 2013, un App store destiné à ses clients et sur lequel sont proposées des applications développées en interne ou bien par des développeurs tiers, en marque blanche. L’utilisation des API est gratuite et les développeurs sont ensuite rémunérés si leur application a du succès… mais ils ne peuvent pas y publier leurs propres applications et conserver leur propre marque. Le CA Store affiche 47 applications, mais la grande majorité (33) ont été développées en interne tandis que les autres proviennent essentiellement d’agences Web, pas de fintech. Bewoopi, par exemple, a développé trois applications de 2013 à 2015 (gestion de comptes multi-lingue, versions régionales de l’application Crédit Agricole et gestion des frais kilométriques). L’agence avait été contactée par Crédit Agricole. “L’intérêt pour nous était de nous faire connaître du Crédit Agricole pour ensuite répondre à des demandes des caisses régionales ayant besoin d’une agence digitale”, décrit Charlotte Pauchet, directrice marketing. Les trois applications, qui ne sont pas monétisées, comptent environ 500 utilisateurs réguliers. Crédit Agricole refuse de communiquer sur l’utilisation de son CA Store ou les revenus issus des applications.

Le modèle marketplace prévaut

Pour s’assurer davantage de participation des développeurs tiers, les banques semblent désormais plutôt s’orienter vers un modèle de marketplace intégrée à leur application, qui renvoie vers des applications tierces, suivant l’exemple de Fidor. C’est par exemple le cas de BBVA, qui a lancé en mars 2016 un portail pour les développeurs – mais n’a pas communiqué depuis sur les résultats. L’australien NAB, après quelques mois en version bêta, a aussi lancé son portail pour développeurs en février. Timidement : la banque ne propose pour l’instant que deux API, pour accéder aux taux de change et aux informations sur la localisation et les horaires de ces agences. Mais NAB a annoncé le lancement prochain de trois API supplémentaires, pour accéder aux informations sur les comptes, utiliser l’authentification de la banque et récupérer les données personnelles des clients.

Fournisseurs de solutions d’APisation

Des fournisseurs de solution d’APIsation comme Apigee, Axway ou encore Restlet, se positionnent sur le créneau, elles qui travaillaient déjà sur l’APIsation interne pour moderniser l’infrastructure des acteurs. Apigee, racheté par Google en 2016, compte par exemple le Crédit Agricole parmi ses clients. “Nous commençons à travailler dans le secteur bancaire sur des business models qui ont prouvé leur efficacité dans d’autres secteurs, décrit David Andrzejek, directeur. Nous avons par exemple aidé la chaîne de pharmacie américaine Walgreens, dont le domaine est très régulé aussi, à bâtir une série d’API depuis 2012 et à s’enrichir d’applications. Résultat : plus de 300 partenaires et un trafic e-commerce aux Etats-Unis qui provient désormais à 40% des API.” Apigee commercialise sa solution plusieurs centaines de milliers voire quelques millions de dollars par an pour les plus grosses banques mondiales. La société travaille avec plusieurs institutions européennes sur la DSP2.

Tesobe pousse la standardisation des API

L’allemand Tesobe, de son côté, commercialise une licence auprès des banques à partir de 50 000 euros par an pour donner accès à un catalogue de 130 API standards (qui ouvrent l’accès aux comptes, aux transactions et aux paiements, pour se conformer à la DSP2, mais aussi au KYC, à l’onboarding, à la gestion de cartes…). Cet “open bank project” compte une communauté de 6 000 développeurs qui construisent des applications fintech sur les API, de la gestion de budget au chatbot en passant par des applis dédiées aux PME… A la banque, ensuite, de choisir son business model : faire payer pour ses API (mises à part les 10 API DSP2, dont l’accès doit être gratuit, 90% du catalogue est monétisable, précise Ismail Chaib, COO), donner un accès privilégié aux start-up, réclamer que toutes les applications soient en marque blanche… BNP Paribas est déjà client de Tesobe mais n’utilise pour l’instant la solution qu’en version test (“sandbox”, facturé 25 000 euros), pour son programme de hackathon, pas encore pour une mise en production globale.

En tout cas, souligne Bruno Cambounet, d’Axway, “à partir du moment où les banques auront travaillé, afin d’être conformes avec la DSP2, sur la mise en place de contrôles pour le fonctionnement des API ouvertes (identifier le tiers, s’il est bien homologué, ce que le client final a autorisé ou non, etc…) elles pourront les étendre à d’autres services à valeur ajoutée et d’autres partenaires plus facilement”. De quoi peut être espérer une accélération de l’Open Banking à la suite de l’entrée en vigueur de la directive…