Square

Open banking : les prémices d’une standardisation

Créé le

18.10.2017

-

Mis à jour le

27.10.2017

La mise en place d’un environnement d’open banking, tel que promis par la DSP 2, implique que les systèmes d’information (SI) des différentes parties prenantes – banques d’un côté, agrégateurs de comptes et initiateurs de paiement de l’autre – puissent communiquer. Plus les SI parleront le même langage, plus efficace sera l’écosystème. C’est en substance l’objectif poursuivi par les standards d’API [1] que l’industrie est en train de concevoir. Plusieurs initiatives, à vocation européenne, sont en cours. La dernière en date, celle du Berlin Group (à laquelle participent STET et Société Générale), a soumis à consultation début octobre des normes communes pour coder ces API. En juillet dernier, c’était d’un côté la Place britannique via l’Open Banking Implementation Entity et, de l’autre, la Place française via STET, qui publiaient des spécifications similaires. Mandatée par ses actionnaires bancaires, STET a ainsi travaillé avec les six principaux établissements hexagonaux pour mettre au point des normes d’API répondant strictement aux prérequis de la DSP 2 : « la documentation technique que nous avons publiée est open source et peut être utilisée par l’ensemble des acteurs. Nous travaillons à la promouvoir en Europe », explique Rodolphe Meyer, directeur marketing et développement de STET.

Le risque de fragmentation

Trois standards pour un même type d’API, n’est-ce pas deux de trop ? « Aujourd’hui, les tiers de paiement fonctionnent en screen scraping, ce qui équivaut à 4 000 interfaces différentes. Est-ce bien grave qu’il y ait un standard par pays ? Il faut poursuivre la standardisation mais ces initiatives sont déjà un progrès », argumentait fin septembre lors du Workshop Revue Banque Alain Benedetti, qui suit le dossier chez BNP Paribas. « Conceptuellement, un standard unique serait une bonne chose, mais il est certain qu’il faudra composer avec plusieurs », se résigne Bruno Cambounet, chez Axway. Par ailleurs, rien n’empêche les banques – en tout cas non britanniques – de créer leur API en dehors de tout standard. C’est l’option que privilégie le groupe paneuropéen ING. « Nous voulons disposer d’une interface centrale qui fonctionne dans l’ensemble des pays où nous opérons », explique Éric Tak, directeur des paiements du groupe hollandais, avant de regretter le fait que « des sous-standards locaux risquent de rendre in fine très difficile, pour les acteurs innovants, le déploiement de leur offre à l’échelle paneuropéenne ». Une forte fragmentation du marché viendrait contrecarrer l’un des objectifs poursuivis par l’Europe avec la DSP 2 – l’accroissement de la concurrence – et forcerait les autorités à réagir. Déjà début octobre, la Commission a montré sa sensibilité aux questions de concurrence en menant des inspections surprises au sein d’institutions ou associations bancaires suspectées de bloquer l’accès aux comptes par des tiers. Les Pays-Bas et la Pologne ont confirmé faire l’objet d’une enquête.

Au-delà des API

Cette détermination européenne à ouvrir le secteur des services bancaires va de pair avec celle, à première vue contradictoire, de renforcer la sécurité du système et la protection des données – à travers le RGPD principalement. Cet aspect essentiel de l’open banking est jusqu’ici abordé de manière assez conflictuelle par les différents protagonistes, ceux qui tiennent les comptes et ceux qui veulent y avoir accès. « Il faut garder à l’esprit que la question des API et de leurs standards ne sont que la partie émergée de l’iceberg en matière d’open banking, insiste Bruno Cambounet. Une fois ces questions d’accès réglées, les acteurs, établissements historiques ou nouveaux entrants, pourront s’atteler au fond du sujet et travailler main dans la main par exemple sur les questions de sécurité, comme c’est déjà le cas au Royaume-Uni. » Tout en œuvrant chacun de leur côté à une offre différenciante. « Toutes essentielles qu’elles soient, les données du compte bancaire ne sont que du carburant que l’on utilisera indifféremment dans une 2 CV ou une Ferrari, illustre Bruno Cambounet. La différence entre les deux véhicules, ce sera l’expérience client que l’on saura créer à partir de ces données. »

 

1 Interface de programmation permettant, dans le cas de la DSP 2, aux tiers de paiement (agrégateurs et initiateurs) d’accéder aux données du compte de paiement du client qui les mandatent directement sur le SI de la banque qui tient le compte.

À retrouver dans la revue
Revue Banque Nº813
Notes :
1 Interface de programmation permettant, dans le cas de la DSP 2, aux tiers de paiement (agrégateurs et initiateurs) d’accéder aux données du compte de paiement du client qui les mandatent directement sur le SI de la banque qui tient le compte.
RB