Troisième étape de notre voyage dans le monde merveilleux de l’Initiation de Paiement.
Après les cas d’usage dans l’épisode 1 : Les Promesses de l’Initiation Paiement, et la fluidité du parcours utilisateur dans l’épisode 2 : Initiation des paiements, quels parcours clients ?, Grégoire illustre pour nous les modes Redirect / Decoupled / Embedded et leur impact sur le parcours client dans la mise en œuvre de l’Authentification Forte (DSP2 / SCA)…
Poursuivons notre voyage dans le monde merveilleux de l’Initiation de Paiement.
Après les cas d’usages dans l’épisode 1 : Les Promesses de l’Initiation Paiement, Grégoire aborde la question critique de la fluidité du parcours utilisateur :
Illustration au travers de différents parcours utilisateurs…
Petite synthèse à chaud des débats de la table ronde organisée par le GT RED (Groupe de Travail Règles, Evolutions & Déploiements) du France Payments Forum. Le thème « Bilan des API DSP2 » était d’actualité quelques semaines après le 14 septembre.
2 heures d’échanges fournis et directs (la règle avait été partagée : « on est là pour se dire les choses… ») entre :
2 banques : Alain BENEDETTI (BNP Paribas) et Dominique BEAUCHAMP (NATIXIS PAYMENT SOLUTIONS) et
2 TPP : Romain BIGNON (BUDGET INSIGHT) et Mathieu PERE (TINK),
animées par Ludovic VATHELOT (TREEZOR).
Emmanuel NOBLANC (SAB) avait démarré avec une KeyNote pour poser le contexte.
J’avais la charge de restituer une synthèse pour conclure…
Que retenir à chaud, à la fin des débats ?
A défaut d’une analyse posée, j’ai surtout retenu la différence de ton entre les échanges sur :
la DSP2 et les RTS, vécus par tous comme une contrainte, avec des choix pris dans un contexte et étendus abusivement (par exemple entre Agrégation et Initialisation) et générant des positions défensives
l’OpenBanking, avec l’illustration de cas d’usage et d’initiatives, avec un enthousiasme communicatif à l’ensemble de l’auditoire.
Pour commencer, il était utile de rappeler que TPP et ASPSP ont plus en commun que la DSP2 ne le laisse voir : les ASPSP sont aussi des TPP ! Chacun a d’ailleurs noté le caractère schizophrénique de cette double posture des ASPSP :
réticence du fait que les API réglementaires sont imposées sans rémunération
vs. initiatives des ASPSP dans l’initiation de paiement (pour illustration, les cas d’usage de Natixis Payments Solutions avec Foncia et System U).
Ceci dit, les acteurs ont largement souligné les difficultés rencontrées dans la mise en œuvre des RTS, avec un constat unanime de progrès significatifs depuis le 14 septembre, mais encore aucune utilisation opérationnelle significative des API déployées. Les obstacles sont multiples :
Problèmes techniques de stabilité, bien sûr
Complexité générée par l’hétérogénéité
Implémentations techniques différentes (malgré les travaux de standardisation menés autour de STET ou de Berlin Group),
Ecarts fonctionnels (divergences de vue sur le périmètre de la règlementation, sur les données requises, mais au-delà sur ce qui apparaît même comme des incohérences de la DSP2 : comment concilier l’esprit de la Directive d’étendre l’offre de service, notamment l’initiation de paiement marchands et la lecture stricte de présenter via API l’équivalent de son offre de Banque en Ligne),
Parcours clients variant de 2 à 7 étapes utilisateurs (avec la problématique de SCA), rassemblés dans une offre d’agrégation soulignant les différences de fluidité…
Exigence de continuité du service déjà déployé par les TPP, qui ne peuvent basculer sur les API qu’une fois atteint un niveau de fiabilité équivalent aux alternatives actuelles de Direct Access (Scraping, Reverse Engineering).
Et puis, l’illustration de différents parcours utilisateurs et la projection sur les cas d’usage nous ont projeté dans une autre dynamique d’échange, où l’on parlait de :
Expérience client,
Services à valeur ajoutée,
Valorisation de la donnée,
Différenciation et avantage concurrentiel,
Initiatives bilatérales entre banque et TPP,
Modèle économique gagnant-gagnant (la clé du sujet !)…
Le miroir était franchi
Oubliées les postures défensives et la vision strictement réglementaire
Bienvenue dans le monde concurrentiel, avec « les yeux qui brillent » à l’évocation du potentiel de l’initialisation de paiement (combiné à l’Instant Payment) pour offrir les nouveaux services à valeur ajoutée attendus par le marché (et au fondement de la Directive elle-même…).
Au final, c’est bien le consommateur qui validera les meilleures offres !
Il faudra donc encore du courage et de la ténacité pour atteindre la conformité à la DSP2, mais la perspective nous projette déjà plus loin, avec un nouvel élan !
But still, it’s a long way… Un chemin que notre Groupe de Travail au France Payments Forum poursuivra et auquel vous êtes invités à contribuer si vous le souhaitez.
A très bientôt pour un autre événement sur le même thème !
Avec la DSP2, le régulateur a voulu, d’une part renforcer la protection des consommateurs, et d’autre part, réguler les nouveaux entrants dans le monde des paiements, ces fameux TPP.
Pour cela il a renforcé ses exigences en matière de sécurité en obligeant les banques à :
Consacrer un canal dédié sécurisé (CSC) pour l’accès aux comptes de paiement à l’usage de ces nouveaux acteurs : les API
Mettre en place une authentification forte du client (SCA)
Ces API permettent non seulement la consultation des comptes de paiement, mais également l’initiation de paiements (SCT, SCTInst,..).
L’initiation de paiement par ce biais devient un nouveau moyen de payer qui peut quelque peu remuer le monde des moyens de paiements.
Grégoire vous propose une série de 3 épisodes, pour pénétrer le monde merveilleux de l’Initiation de Paiement, des cas d’usage aux méthodes Redirect, Decoupled, Embedded…
[Episode 1] Commençons par des exemples de cas d’usages: quelles sont les opportunités de l’initiation de paiement ?
Les cas d’usages de l’initiation de paiement comme alternative à la carte ou au chèque, dans quels cas cela fait réellement sens. Exploration de quelques cas d’usages.
Une opportunité pour les TPP
Les TPP peuvent utiliser les API mises en place par les banques pour initier des paiements sans aucun frais.
Actuellement, les TPP qui font de l’agrégation de compte et de la gestion de finance personnelle s’en servent essentiellement pour faire des virements entre les comptes des clients, faire de la micro épargne, du nivellement etc..
L’initiation de paiement pour régler un achat, ou une facture, aujourd’hui marginale peut rapidement se développer :
Les TPP peuvent proposer ce nouveau moyen de payer aux commerçants en complément des autres outils traditionnels.
C’est facile à mettre en œuvre (pas de TPE, le téléphone du client suffit pour réaliser la transaction)
Le client ne transmet aucune information (pas de numéro de carte à saisir, ni d’IBAN)
C’est un service fourni gratuitement par la banque !
La guerre de la fluidité
Pour un commerçant, il faut que l’acte d’achat rencontre le moins d’obstacles possibles pour éviter l’abandon avant d’être finalisé.
La saisie d’un numéro de carte ou d’un IBAN peut se révéler rédhibitoire dans certains cas et l’initiation de paiement peut être une réelle alternative.
Les TPP s’emploieront donc à rendre le parcours client de paiement le plus simple possible.
Reste la problématique de l’authentification forte du client qui reste du ressort de la banque.
Des solutions existent pour simplifier cet aspect, gageons qu’on les verra émerger rapidement.
Le syndrome « Kodack »
Les banques ont dépensé des sommes conséquentes pour mettre en place les API DSP2, et par là offrir GRATUITEMENT de l’initiation de paiement aux TPP.
L’initiation de paiement vient concurrencer directement leur offre déjà en place (TPE, et autres moyens de paiement) qui leur apporte un chiffre d’affaire important.
Ne pas s’y mettre risque de laisser le champ libre aux TPP.
Elles ont pourtant l’avantage énorme d’avoir déjà la clientèle.
Une facilité pour le client
Pour tous les cas où payer peut-être fastidieux (envoyer un chèque pour payer une facture, se connecter à sa banque en ligne pour faire un virement,..) ou risqué (renseigner son numéro de cartes sur un site de e-commerce inconnu), l’initiation de paiement peut être une alternative intéressante.
Cette série de publications propose d’explorer :
Les cas d’usage où l’initiation de paiement se révèle particulièrement pertinent.
Les enjeux de la fluidité à travers quelques exemples de parcours clients
Les aspects de l’authentification forte entre contrainte et fluidité.
Chaque année, elle arrive au mois de novembre. Le contenu en est connu depuis presque un an, mais c’est souvent dans l’urgence que des établissements financiers s’en préoccupent pour respecter l’échéance.
Alors à quelques semaines du terme du 17 novembre 2019, savez-vous ce qui vous attend dans cette nouvelle Release ?
Bonne nouvelle ! Pas d’évolution sur le SDD !
En revanche, si de 2014 à 2017, le virement européen a connu peu d’évolution, 2019 prolonge le mouvement initialisé en 2018, avec l’apparition d’une nouvelle famille de R?messages (ou “messages connexes”) : les “Inquiries”, avec ses mises à jour associées.
La Release 2019 complète également les “Requests” et leur ajoute les “Status Updates” associés.
Retour vers le Futur
Petit rappel de la construction des messages liés au Virement SCT : l’origine remonte à 2008, avec un complément en 2010 :
Tableau 1 – Les messages historiques du SEPA Credit Transfer
Les Requests
Les Requests s’enrichissent dans cette release 2019 : ces “requêtes entre banques” sont des messages destinés à interroger le confrère sur le sort d’une demande antérieure.
Par exemple, après un Recall (message historique de rappel de fonds), en l’absence de réponse, la banque émettrice s’enquiert de sa demande via un Request for Recall (message apparu en 2018).
Cette famille, apparue en novembre 2018, annonçait le prélude à une multiplication des messages qui se concrétise dans la release 2019.
En Novembre 2019, il sera possible de faire des Request for Status Update qui permettront de connaître la destinée des messages précédemment envoyés.
Tableau 2 – Les Requests et les Status Updates
Les Requests for Status Update accompagnent les Requests et Inquiries : ils ont été définis pour rappeler au destinataire qu’une requête (Request), qu’une enquête (Inquiry) ou qu’un rappel de fonds (Recall) a été émis et reste à ce jour sans réponse.
En principe, une banque se doit de faire un retour sur tous les R-messages imposant une réponse. Ces messages permettront d’identifier plus facilement les établissements qui, par habitude, ne répondent pas aux messages.
Les Inquiries
La famille des Inquiries est la nouveauté 2019. Les Inquiries sont des messages d’investigation.
Par exemple, l’émetteur demande d’enquêter sur l’absence de réception d’un virement ou sur une demande de modification de date de valeur.
Ces messages peuvent améliorer certains processus internes dans les banques, comme dans le traitement des vérifications et des contestations ; plus globalement, l’objectif européen est d’encadrer des pratiques existantes de gré à gré entre banques.
Ces nouveaux messages bénéficieront surtout aux banques ne disposant pas des relations interbancaires suffisantes pour gérer par téléphone auprès d’une banque estonienne, le cas d’un virement non reçu.
Ils affranchissent en effet les Back-Offices bancaires des barrières linguistiques et des décalages horaires.
Tableau 3 – Nouveauté 2019 – les Inquiries
Les Inquiries peuvent faire l’objet d’une Request for Status Update pour rappeler au confrère qu’une demande est en cours (cf. §2).
Une Release souvent jugée à faible Valeur Ajoutée par les Banques Françaises…
Le socle européen de base du virement SEPA s’étend à présent à 19 messages (sans compter les ajouts nationaux, comme les ACVS et les CAI pour la France).
Fallait-il s’imposer ces nouvelles contraintes, se demanderont sans doute les banques, pour traiter des cas d’exception ?
La Release s’impose à tous !
Outre la force de la réglementation, la Release s’impose pour suivre les prochaines évolutions réglementaires et fonctionnelles.
D’un côté, la Release 2019 démontre bien la disparité entre les pratiques nationales : elle est bien accueillie en Allemagne et plus froidement en France. Mais n’est-ce pas précisément la volonté et le rôle du régulateur d’uniformiser les pratiques à l’échelle de l’Europe et faire émerger des acteurs pan-européens ?
D’un autre côté, les banques voient les coûts de mise en oeuvre de la Release. Alors qu’elles investissent pour se transformer au numérique et à l’instantanéité, ces changements sont le plus souvent subis et les banques peinent à y trouver un retour sur investissement.
La nouvelle réglementation, un paradoxe avec le SCT Inst…
Le rapprochement entre la Release 2019 et le passage au numérique instantané souligne un paradoxe.
En effet, que penser des nouveaux messages de correction des dates de valeur alors que l’autre virement européen, le SCT Inst (alias Instant Payment) fait disparaître la notion-même de date de valeur et de règlement ? Si le SCT Inst se présente de plus en plus généralement comme le remplaçant (“the new standard”) du SCT classique dans plusieurs pays européens, fallait-il créer ces nouveaux messages ?
En synthèse, l’adoption de la Release SEPA 2019 au sein des banques se fait sans enthousiasme, avec un contenu chargé (l’un des plus lourd qu’ait connu le SCT) et sans retour sur investissement clairement identifié.
Néanmoins, elle reste obligatoire pour toutes les banques européennes, même si certaines essaieront de conserver un traitement manuel sur certains processus.
Et puisqu’il faudra bien y passer, autant bien comprendre les mécanismes européens et les attendus de cette Release. C’était l’objet de cet article, que nous pouvons poursuivre en bilatéral sur demande… parallèlement aux actions à engager pour accélérer le déploiement du SCT Inst et s’affranchir du SCT Classique !
Si la mise en place de la DSP2 semble prendre l’apparence d’une querelle entre anciens et modernes – les banques contre les fintech – la réalité s’avère plus complexe…
Ouvrir à des tiers l’accès aux données et à l’initiation de paiement pour stimuler la concurrence tout en consolidant la sécurité des paiements. C’est l’ambition de la DSP2 (directive européenne sur les services de paiement) entrée en vigueur en janvier 2018 et dont la mise en œuvre est jalonnée par de grandes étapes définies dans les normes techniques et réglementaires (aussi appelées RTS), notamment sur les interfaces d’accès (API) et l’authentification forte.
Une première échéance est tombée le 14 mars 2019, date à laquelle les banques devaient avoir déployé un portail d’API afin de mettre à disposition la documentation et un bac à sable permettant aux TPP (Tiers Prestataires de Paiement) de les éprouver. Une autre suivra le 14 septembre 2019 avec l’ouverture officielle des APIs de production. Dans le contexte de tension entre fournisseurs d’API (teneurs de comptes) et consommateurs (nouveaux acteurs), cette échéance a relancé le débat sur la capacité des banques à respecter le calendrier…
La DSP2, une transformation lourde à marche forcée
Dans ces débats, un même coupable est souvent pointé du doigt : les banques. Qui complexifieraient la sécurité ou encore publieraient des API bien trop partielles pour être exploitables. La réalité est un peu plus… complexe. Et les enjeux ne peuvent se résumer à une querelle entre les anciens (les banques installées) et les modernes (les acteurs de la fintech). Rappelons que la DSP2 est un sujet plutôt nouveau, qui concerne « juste » la sécurité des paiements et la protection des données du client. Et comme pour toute transformation lourde, les acteurs impliqués découvrent en marchant les clarifications qui doivent encore être apportées.
Oui, les différents textes, de la directive aux RTS, ont bien posé des fondamentaux. Trois catégories ont été définies pour les fameux TPP (Tiers Prestataires de Paiement), des agrégateurs de comptes aux initiateurs de paiement en passant par les émetteurs de moyens de paiement.
Des obligations pour les tpp et les banques
Pour entrer dans le jeu, ces TPP doivent remplir des conditions : obtenir un agrément auprès d’une autorité nationale, un certificat (dit « eIDAS ») auprès d’une autre autorité ou encore renoncer (quand des API sont disponibles) au webscraping. Pour rappel, cette technique consiste à collecter les données à partir des sites de banque en ligne, en utilisant les identifiants et mots de passe des clients. Les banques pour leur part doivent respecter le calendrier de déploiement et mettre à disposition les API de production pour les trois catégories de TPP le 14 septembre prochain après avoir mis en ligne, en mars dernier, bac à sable (sandbox) et documentation.
Si les règles du jeu et le calendrier sont là, que manque-t-il ? Nous pourrions résumer en disant « des délais plus cohérents et des modalités plus précises ». À défaut, pour les TPP comme pour les banques, la route manque de lisibilité.
Quelques exemples pour comprendre :
Globalement, le planning de l’autorité de régulation (ACPR, Autorité de Contrôle Prudentiel et de Résolution) a été publié fin décembre pour des actions à lancer mi-janvier et des mises en production mi-avril. Un planning plus que tendu.
Sans surprise, dans ces délais les progiciels bancaires ne sont pas prêts pour intégrer les spécificités de la DSP2.
Selon les prestataires impliqués, les certificats eIDAS ne pourraient entrer en production qu’au 3e trimestre. Compliqué dans ce contexte d’être prêt pour le 14 septembre.
Pas simple non plus pour les TPP de suivre le rythme pour revoir leur mode d’accès aux données (passer du webscraping aux API) ou encore obtenir les certificats adéquats.
Le Fallback et son exemption cristallisent aussi les critiques. Le « Fallback » désigne un mécanisme de secours en cas d’indisponibilité ou de mauvais fonctionnement des API. Les banques peuvent demander une dérogation à ce sujet. Mais le planning n’a pas été aligné en cohérence avec l’échéance 14 mars 2019 et le dossier à fournir demeure complexe. Le mécanisme de Fallback lui-même souffre d’imprécisions.
Comment recueillir le consentement des clients ? Selon quel parcours ? En imposant une redirection vers l’établissement teneur de compte ? Évidemment, ce n’est pas du goût des TPP. Pour l’heure, même à l’échelle française, aucun consensus n’émerge vraiment sur le sujet.
Le renouvellement de l’authentification ? Les RTS prévoient actuellement d’obliger les utilisateurs à se réauthentifier tous les 90 jours auprès de leurs banques. Les TPP estiment le mécanisme incompatible avec une expérience utilisateur digne de ce nom.
Gageons justement que cette expérience client, un peu perdue de vue au fil des textes réglementaires, devrait s’imposer comme l’alpha et l’oméga des discussions à venir. Et comme un objectif commun à l’ensemble des acteurs. Parce que chacun a autant à perdre qu’à gagner. Parce que, aussi, cette expérience dépend de business modèles à caler de part et d’autre.
Une certitude : la DSP2, sujet restructurant à l’échelle bancaire, appelle des investissements lourds dans des délais serrés. Et seule la coopération permettra à chacun d’y trouver des bénéfices – et pas seulement financiers –, en apportant au client final, les nouveaux services fluidifiant le paiement dans son parcours utilisateur.
