La banque ouverte repose sur des API ouvertes, un logiciel qui intègre les systèmes entre les banques et les tiers afin que les données des clients puissent être partagées.
Il s'agit d'un mouvement basé sur l'idée que les clients sont les propriétaires de leurs données et devraient être autorisés à insister pour que les banques les mettent à la disposition des fintechs ou d'autres acteurs, qui à leur tour peuvent développer des applications grand public, soit avec les banques, soit en opposition avec elles.
Les banques ne sont généralement pas de grands fans de cette approche, et il existe maintenant des recherches qui suggèrent que de nombreux opérateurs européens traitent les opérations bancaires ouvertes comme un exercice de cocher des cases.
Un nouveau rapport de Salt Edge, une société basée au Royaume-Uni qui met en place des plateformes API pour aider les banques et les tiers à se connecter, suggère que au Royaume-Uni et en Europe, la vision de l'open banking s'effrite car les API des banques sont souvent de mauvaise qualité.
"Ces chiffres sont vraiment choquants", a déclaré Ned Lowe, CTO chez SingLife, des conclusions du rapport.
Par exemple, la plupart des banques en Europe proposent désormais la «disponibilité des API», ce qui signifie qu'elles ont des API. C'est le cas de plus de 90% des banques au Royaume-Uni, au Portugal et en République tchèque, la conformité chutant sur d'autres marchés. Mais cela ne se traduit pas par les API des banques qui répondent réellement aux demandes des TPP (fournisseurs tiers). En tchèque, seul un tiers des API des banques répondent réellement; en Europe, la moitié des banques en moyenne ne répondent pas aux demandes de connexion.
Pire: 39% des banques ont des points de terminaison cassés dans leur portail de développeur, ce qui signifie que les liens sont inactifs, les portails ne répondent pas, les formulaires d'inscription ne fonctionnent pas ou la banque ne répond pas à la nécessité de tester les API.
Autres résultats de l'enquête de Salt Edge sur plus de 2,000 31 initiations API (demandes d'interaction avec des banques) dans XNUMX pays européens, dont le Royaume-Uni:
- 38% des API bancaires ne répondent pas aux normes réglementaires de l'UE ou du Royaume-Uni
- 58% des intégrations prennent plus de 10 jours
- 43% des banques ne prennent pas en charge les enregistrements automatisés pour accéder aux API pertinentes
- 46% des banques n'autorisent pas les TPP à tester des scénarios avec les données à utiliser dans les applications grand public
- 37% des environnements de bac à sable des banques ne ressemblent pas à leurs environnements vivants
- 22% des API sont livrées avec une documentation défectueuse
- Et un dernier gémissement: 28% des API ont connu des temps d'arrêt lors de l'intégration.
Ces échecs généralisés sont des violations évidentes de la PSD2. Mais la question va au-delà de savoir si les régulateurs devraient punir les banques. Cela signifie que la structure destinée à ceindre la banque ouverte ne fonctionne pas.
À Singapour, la Monetary Authority exige que tout système jugé critique ait un temps de disponibilité de 99.95% du temps sur 365 jours. Cela équivaut à seulement quatre heures par an d'indisponibilité autorisées, explique Lowe.
Le degré d'échecs des API en Europe montre que ses banques ne prennent pas au sérieux la banque ouverte. Ils ne la traitent pas comme critique.
(Salt Edge a mis en évidence quelques banques qui se sont démarquées par d'excellentes API, y compris des banques challenger telles que Monzo et Revolut, mais aussi des opérateurs historiques tels que Lloyds Bank, Commerzbank et Nordea, entre autres.)
Cela soulève la question de savoir si les API ouvertes doivent être «critiques». Il n'est probablement pas essentiel d'aider les données agrégées à alimenter une application de budget client. Mais si l'ouverture bancaire doit être obligatoire, elle échouera si le système n'est pas fiable. Les clients se retrouveront avec des applications qui ne fonctionnent pas.
«Lorsque les gens de l'industrie parlent d'open banking, ils se concentrent généralement sur la réglementation, les données et les cas d'utilisation», a déclaré Ankit Suri, co-fondateur de Hong Kong fintech Planète. «Ce dont ils ne parlent pas, c'est de l'expérience de développeur des API. Mais les API doivent fonctionner. "
Cela signifie simplifier les intégrations afin que l'ajout d'une carte de crédit ou d'une société de paiement soit réduit à quelques lignes de code. Plus l'intégration est facile, plus les développeurs peuvent consacrer de temps à la création d'applications et à de bons parcours utilisateur.
Les banques ont reculé parce qu'on leur a ordonné de faire quelque chose qu'elles n'aiment pas. Mais ils trouvent également les API difficiles. La technologie d'open-banking ne correspond pas parfaitement aux systèmes bancaires de base hérités. Il est difficile de concevoir une API en temps réel pour se connecter à un système qui fonctionne par traitement par lots.
En Europe, au moins, il existe un processus d'octroi de licences pour les PPT, de sorte que les banques peuvent avoir une certaine confiance dans qui obtient les données de leurs clients. À Hong Kong et à Singapour, les autorités de réglementation ont jusqu'à présent refusé de le faire, laissant le fardeau et le risque aux banques.
«Qui dit au consommateur ce qui est sûr? La banque », a déclaré Victor Lang, co-fondateur de entreprise gini, une fintech de Hong Kong. «C'est pourquoi rien ne se passe. Toutes les API que nous voyons sont à sens unique. " Par exemple, une banque s'intègre à un site de commerce électronique pour commercialiser une carte de crédit aux acheteurs, mais elle ne donne pas ses propres données à des tiers qui pourraient vouloir développer des applications avec elle.
Aux États-Unis, en revanche, les autorités ont béni l'open banking et permis aux TPP de collecter des informations mais n'ont rien mandaté. C'est au marché de décider quoi faire. Certaines banques proposent des API, d'autres non. Ceux qui résistent verront quand même les données des clients grattées à l'écran.
"Il y a une énorme opportunité commerciale aux États-Unis, donc si une banque essaie de bloquer les API, les autres parties jetteront beaucoup de ressources sur le grattage d'écran", a déclaré Ray Wyand, PDG et co-fondateur de gini. «Le rapport [de Salt Edge] suggère que ce n'est pas une priorité au Royaume-Uni»
Les États-Unis ont donc vu l'essor de sociétés d'infrastructure telles que Stripe et Plaid pour aider à connecter les banques avec les utilisateurs, les commerçants et les partenaires fintech. Dans le même temps, les États-Unis ont également vu l'essor de grands fournisseurs d'applications grand public, tels que Acorns et Clarity Money (qui a été acquis en 2018 par Goldman Sachs et intégré à sa banque numérique Marcus).
Certains marchés asiatiques ont connu un énorme succès avec l'open banking. L'Inde, grâce à la pile numérique construite par son gouvernement pour l'identité et les paiements, est de facto un marché bancaire ouvert. Les banques numériques coréennes ont exploité la taille des sociétés mères de commerce électronique et de télécommunications pour faire de même. Les banques australiennes, à la suite d'un rapport cinglant l'an dernier sur les abus des consommateurs, ont été des partenaires API plus fiables.
Mais l'Europe a été l'avant-garde de l'open banking - et elle l'a bâclée. L'une des raisons pour lesquelles l'Europe compte si peu de géants de la fintech est peut-être que, malgré plus d'une décennie d'encouragement ou d'imposition de normes bancaires ouvertes, ses banques ont traîné les pieds et n'ont pas créé d'API fiables. Et si l'infrastructure n'est pas sécurisée, personne n'est incité à investir dans la création d'applications grand public risquées.
Pour des endroits comme Hong Kong et Singapour, l'avertissement aux régulateurs est que s'ils veulent vraiment voir des opérations bancaires ouvertes, ils doivent considérer l'équilibre des passifs, des obligations et des résultats commerciaux pour les banques. Souhaitent-ils voir leurs banques cocher les cases ou s'associer à des tiers pour innover?
Cela pourrait signifier donner des dents aux mandats: par exemple, les régulateurs pourraient exiger que les API des banques respectent les niveaux de disponibilité MAS pour les systèmes critiques.
Ou cela pourrait signifier laisser cela aux forces du marché. Les petites cités-États n'ont pas l'échelle nécessaire pour obtenir des résultats commerciaux similaires à ceux de l'Amérique. Mais Covid-19 signifie que les banques doivent aller en ligne pour acquérir de nouveaux clients et interagir avec les clients existants.
"Avant, les API étaient un projet", a déclaré Suri. «Maintenant, ils planifient la continuité, car l'entreprise ne fonctionnera pas sans acquérir de clients en ligne.»
Les banques devront voir les API ouvertes comme commercialement utiles.
"Il y a un énorme avantage concurrentiel pour les banques qui le font bien", a déclaré Lowe: SingLife déplace l'argent via DBS parce que l'insurtech faisait confiance aux capacités de l'API grand public de la banque.
