La seconde Directive sur les Services de Paiement (DSP2), entrée en vigueur le 13 janvier 2018, ouvre le marché à de nouveaux acteurs en donnant accès aux comptes bancaires via le canal de communication API (Application Programming Interface), en particulier via :

• Le service d’accès aux comptes, à destination des acteurs AISP (Account Information Service Provider), tels que des agrégateurs comme Bankin’ ou Linxo par exemple,
• Le service d’initiation de paiement par accès direct au compte du client, à destination des acteurs PISP (Payment Initiation Services Provider).

Cette directive s’accompagne d’exigences techniques, les RTS (Regulatory Technical Standards) qui fournissent un cadre à suivre pour ce nouveau canal.

Le jalon du 14 mars 2019, positionné six mois avant le jalon d’entrée en vigueur réglementaire des RTS, marquait la date limite à laquelle les banques européennes devaient mettre à disposition des tiers un environnement de type « bac à sable » (sandbox) ainsi que la documentation associée afin de leur permettre de tester leurs solutions avec des données anonymisées.

Dans cet article, nous partageons quelques observations sur les environnements de test et solutions retenues en France et Belgique.

1. Les grandes banques évoluant en France et en Belgique ont mis à disposition un environnement de test et la documentation de leurs APIs

Les principales banques évoluant en France et en Belgique ont, dans leur grande majorité, répondu à temps aux exigences de la directive en la matière.

Ci-dessous un échantillon non exhaustif des portails développeur disponibles :

PAYS	CATEGORIES	BANQUE	PORTAIL OPEN API DSP2
FRANCE	Banques françaises traditionnelles	BNP Paribas	Lien
		BPCE	Lien
		CIC	Lien
		Crédit Agricole	Lien
		Crédit Mutuel	Lien
		La Banque Postale	Lien
		Société Générale	Lien
	Banques traditionnelles étrangères implantées en France	HSBC	Lien
		ING	Lien
	Banques digitales / Néo-banques implantées en France	Boursorama	Lien
		Orange Bank	Lien
		Revolut	Lien
	Banques traditionnelles
		ABN Amro	Lien
		Axa Bank	Lien
		Belfius	Lien
		BNPP Fortis	Lien
		Crelan	Lien
		KBC	Lien
		Rabobank	Lien
	Banques digitales
		Beobank	Lien
		Keytrade Bank	Lien

 

2. Les banques françaises ont adopté le standard STET là où la majorité des banques belges se sont alignées sur NextGenPSD2

Les RTS constituent des exigences mais n’offrent pas directement un standard interopérable, par exemple elles ne définissent pas de format pour les API.

Afin de faciliter la mise en œuvre et de permettre une collaboration simplifiée entre les différents acteurs du marché, différentes initiatives de standardisation ont émergé dans l’UE. A l’OBIE anglaise se sont notamment ajoutées les initiatives du Berlin Group (qui est à l’origine du standard NextGenPSD2) et celle de la STET.

Récapitulatif des standards suivis par les banques traditionnelles et les néo banques :

PAYS	CATEGORIES	BANQUE	STANDARD(S) SUPPORTE(S)
			STET	OBIE	NextGenPSD2
FRANCE	Banques françaises traditionnelles	BNP Paribas
		BPCE
		CIC
		Crédit Agricole
		Crédit Mutuel
		Société Générale
		La Banque Postale
	Banques traditionnelles étrangères implantées en France	HSBC			En cours
		ING
	Néo-banques implantées en France	Boursorama
		Orange Bank
		Revolut
BELGIQUE	Banques belges traditionnelles	Axa Bank
		Beobank
		BNPP Fortis
		Crelan
		KBC
		Keytrade
		Rabobank

Ce tableau nous amène aux constats suivants :

• La majorité des banques en France a décidé d’adopter les normes de la STET.
• La majorité des banques en Belgique a décidé d’adopter les normes NextGENPSD2. En volume, la situation est toutefois fragmentée puisque BNPP Fortis qui est un acteur majeur du marché a lui fait le choix d’adopter STET.
• Il n’y a pour l’instant qu’un seul acteur multi standards dans le panel étudié. Il s’agit d’HSBC qui utilise simultanément les normes de STET et d’OBIE, tout en travaillant sur l’intégration des standards du Berlin Group.

On peut toutefois penser que la situation actuelle est probablement transitoire. A long terme, il est probable que la situation évolue soit dans le sens d’une convergence et/ou une interopérabilité des standards, soit vers la généralisation du support multi standards (en tout cas pour les banques avec une présence internationale).

Même en partageant un standard, l’expérience Open Banking anglaise a déjà mis en évidence que les différences d’interprétation entre acteurs peuvent être significatives.

Dans un contexte de standards multiples, ceci impose un effort important d’intégration pour les TPPs. Ceci est d’autant plus vrai dans le cas de NextGenPSD2 on est en fait en présence d’une boîte à outils. Cette dernière permet d’avoir des éléments communs mais du fait qu’elle propose de nombreuses options l’interopérabilité entre les acteurs l’ayant retenu ne va pas forcément de soi suivant les combinaisons d’options choisies.

C’est bien sûr vrai pour les acteurs avec un positionnement international, mais aussi pour les acteurs locaux s’ils veulent disposer d’une couverture complète des acteurs bancaires implantés dans le pays.

Pour les utilisateurs, cette situation risque de se traduire à court terme par des restrictions quant aux banques supportées par certains de leurs TPPs, des expériences non homogènes et des niveaux de services variables selon les combinaisons de TPPs et banques utilisées.

3. Le modèle de redirection règne en maître et le modèle intégré est absent

S’agissant de l’authentification forte, deux grands modèles s’opposent :

Principes	Impact	SCA 100% géré par la banque	Expérience intégrée
Le modèle de redirection (redirection model)	Redirige l’utilisateur vers l’interface de sa banque dans laquelle l’authentification forte est faite	En étant redirigé vers le service d’authentification forte fourni par sa banque, le client sort « virtuellement » de l’interface de son TPP et lui donne l’impression d’être sur son portail bancaire.	Oui	Non
Le modèle intégré (embedded model)	L’authentification forte est entièrement faite sur l’interface du TPP qui transmettra directement les informations à la banque	Cette méthode coupe la banque de tout contact direct avec son client. L’expérience client est complètement intégrée et maîtrisée par le TPP.	Non	Oui

 

Il existe également un modèle découplé, relativement proche de la redirection à la différence près que l’utilisateur n’est pas redirigé mais ouvre un parcours parallèle. Pour plus de détails sur ces différents modèles et notamment des schémas explicatifs vous pouvez vous reporter aux liens suivants :

• Introduction
• Vision plus détaillée préparée par l’API Evaluation Group

A la lumière des éléments actuellement disponibles, toutes les banques du panel semblent supporter le modèle de redirection et aucune banque ne semble supporter le modèle intégré.

Ce choix impacte fortement les agrégateurs déjà en place (Ex : Linxo, Bankin’…) et leurs utilisateurs. Les TPPs ne seraient en effet plus en capacité de contrôler le parcours client de leurs propres utilisateurs, un point d’autant plus important que la DSP2 impose de renouveler régulièrement cette authentification forte (a minima tous les 90 jours).

Il s’agit d’un sujet majeur de friction avec les TPPs : certains, frustrés de l’absence de progrès sur le sujet, vont jusqu’à évoquer des scénarios de scraping sur les front-ends de redirection.

Ce point ne doit pas être négligé dans un contexte où l’utilisation des APIs par les TPPs et la prise en compte des retours de TPPs est un élément nécessaire à l’acceptation des APIs des banques par le régulateur (en particulier pour les demandes d’exception à la solution de repli).

4. La qualité de l’expérience utilisateur-développeur varie fortement entre les portails

Si certaines banques proposent des portails développeurs intuitifs, détaillés et mettant à disposition une documentation exhaustive, d’autres ont pris la décision de mettre en place des portails relativement basiques, peu intuitifs et parfois difficiles d’accès (certains portails nécessitant la création d’un compte pour la simple consultation de la documentation).

Si cette situation est peut-être temporaire pour certains établissements pressés par le temps, cet écart peut aussi être perçu comme révélateur d’une dualité stratégique de la part des banques : certaines interprètent la DSP2 comme une directive à laquelle se conformer, d’autres l’abordent comme une opportunité à saisir.

En tout cas, la qualité des portails développeurs est de notre point de vue un enjeu majeur comme nous l’avons développé dans notre étude « Competing in a new era ».

Les banques ayant déployé un portail fluide, détaillé et facile d’accès pourront tirer profit de toutes les interactions rendues possibles par les développeurs avec des tiers, tandis que les autres s’exposent au risque de bénéficier de fonctionnalités et compatibilités tierces plus limitées.

Conclusion

Le jalon de mi-mars a permis de voir que, si une bonne partie des banques sont formellement au rendez-vous sur le plan réglementaire, il reste du chemin à parcourir pour tenir la promesse d’un écosystème réellement plus ouvert.

Les positions prises par les banques sont accueillies très fraîchement par les TPPs. C’est le cas en particulier des modèles d’authentification mais plus largement les TPPs se plaignent du fait que les APIs ne répondent pas aux attentes.

Les prochaines étapes dans lesquelles les banques vont devoir démontrer leur conformité vont donc être particulièrement importantes à suivre.

Prochaines étapes critiques :

• Préparation des dossiers d’exemption de mise en place d’une solution de repli (fallback). Pour les banques françaises l’échéance de dépôt des dossiers a été fixée par l’ACPR au 14 juillet 2019.
  • A noter, qu’une des conditions est de prouver à cette date que son interface a fait l’objet d’une utilisation étendue conformément aux orientations de l’ABE durant les 3 mois précédents.
• Ajustement si nécessaire des interfaces sur la base des retours des TPP
• Préparation de la communication client.