Quelle est l’origine du Request-to-Pay (RTP) ?
Le principe du RTP n’est pas nouveau. En France, par exemple, les banques françaises ont appliqué très tôt son principe au sein de SEPAmail dès 2015. La logique était de pouvoir associer ensemble une facture et une demande de paiement car bien souvent, le fait d’avoir deux circuits distincts, celui de la facture et celui du paiement, entraînait des difficultés de réconciliation entre factures émises et paiements reçus, des retards de paiement, voire des non-paiements tout simplement parce que la facture s’était égarée. L’idée était donc, avec le RTP, que la « demande de paiement » en français (avec tout ce qui est utile à la bonne fin du paiement) s’accompagne en pièce jointe de la facture ou de tout justificatif de la créance sous-jacente.
Sur ces entrefaites, les instances européennes et notamment l’Euro Retail Payment Board (ERPB) ont souhaité en 2017 prolonger les travaux d’harmonisation européenne entrepris au niveau des paiements pour remonter la chaîne de valeur au niveau process et s’attaquer à la présentation et au paiement des factures au niveau européen. La profession bancaire européenne a répondu bien évidemment positivement à ce souhait et c’est logiquement au niveau de l’EPC (Euro Payment Council), l’association bancaire européenne pour les paiements, que les travaux ont été initiés.
Fort de l’expérience française de SEPAmail, la profession bancaire française m’a naturellement désigné pour la représenter au sein de l’EIPP MSG (E-Invoicing Presentment & Payment Multi Stakeholder Group) avec l’ensemble des représentants de l’offre (essentiellement côté banque) et de la demande (facturiers, entreprises, trésoriers…) sans compter l’Eurosystème et la Commission européenne.
Il fallait avant toute chose s’appuyer sur des standards connus et reconnus par l’ensemble des acteurs et au nom de la profession française, j’ai proposé très rapidement de nous appuyer sur des messages ISO 20022 et plus particulièrement les messages Pain.013/Pain.014 se dénouant par des virements. Ce sont effectivement ces messages ISO qui ont été retenus, mais il fallait néanmoins les faire évoluer pour justement pouvoir transporter des pièces jointes et répondre également aux besoins des acteurs de l’écosystème. Une fois ces évolutions réalisées au niveau de l’ISO et nos travaux présentés à l’ERPB en 2019, les instances européennes ont souhaité que nous allions plus loin que la facture électronique et que nous regardions si le RTP pouvait également être utilisé plus largement sur la partie retail (E-commerce, M-Commerce, PtoP, etc.) en parallèle des travaux de l’EIPP MSG qui se prolongeaient sur les « messages de service RTP » pour créer un véritable écosystème européen complet et autonome.
Mais qu’est-ce que le RTP, finalement ?
Le RTP apparaît très clairement comme la brique de liaison entre l’activité économique (commerce, service, facturation) et le paiement dans un contexte de digitalisation des parcours utilisateurs.
Avant toute chose, comme son nom l’indique, un créancier va émettre cette requête avec toutes les données utiles en relation avec la transaction commerciale (facture, détail du produit ou service…) mais aussi les données utiles au paiement (IBAN du créancier, référence, etc…) vers son débiteur pour non seulement se faire payer rapidement mais également faciliter la tâche de son débiteur car toutes les données du virement sont déjà « préremplies ». En un mot, si ce dernier accepte la requête, la banque du débiteur émettra en son nom un virement (instantané ou non) pour régler le créancier automatiquement.
Un concept simple, qui s’appuiera sur la puissance d’un instrument de paiement, le virement, et plus particulièrement l’Instant Payment, qui est déployé déjà dans toute l’Europe, et accepté par plus de 2 000 PSP européens.
En effet au niveau de l’ISO, ce RTP ne peut se « dénouer » que par un virement. En théorie et au plan de l’ISO stricto sensu, il pourrait se dénouer aussi par un chèque mais ce serait bien évidemment un non-sens d’utiliser ce moyen de paiement par définition non digital.
En quoi le RTP se distingue-t-il du Sepa Direct Debit (SDD) ?
Le prélèvement européen, le SDD, est un instrument de paiement ayant vocation à être entièrement maîtrisé par le créancier qui débite directement le compte de son débiteur avec l’inconvénient d’être révocable, alors que le RTP « redonne la main » au débiteur qui a le choix et initie lui-même son virement, qui lui est irrévocable.
La spécificité de ce nouveau scheme d’échange de flux est qu’il offre une expérience utilisateur de bout en bout entre les clients finaux au travers de leur RTP service provider (RTP SP) respectif. Lorsque le débiteur accepte ce RTP, il reconnaît qu’il a bien une dette vis-à-vis de son créancier et qu’il va le payer sur base des données spécifiées par ce créancier, ce qui rend le parcours client totalement fluide.
La valeur ajoutée de ce nouveau moyen de payer transeuropéen se reflète également dans ses nombreux cas d’usage potentiels.
Concrètement quels sont les cas d’application du RTP ?
Bien sûr, la livraison contre paiement (retail) peut être appliquée au commerce, entre entreprises ou entre entreprises et particuliers et même entre particuliers en PtoP : un RTP envoyé au moment de la livraison n’importe où en Europe… avec règlement en moins de 10 secondes sur toute l’Europe… Ou tout simplement le règlement de factures, lors de leur émission, sans prendre le risque des délais de paiement. Également un règlement entre particuliers… à partir de son mobile, en relation directe avec son interlocuteur. Et enfin, on peut imaginer tout type de relations de particuliers ou d’entreprises avec des organismes sociaux ou des administrations fiscales.
Ses apports seront donc assez évidents tant du côté du créancier que du côté du débiteur et ce scheme d’échange permettra de compléter la facturation électronique pour disposer d’un processus simple de règlement électronique de facture de bout en bout.
Et ce nouveau moyen de payer/d’être payé fait l’objet d’un scheme, c’est-à-dire d’un ensemble de règles que les participants de toute l’Europe s’engagent à respecter lorsqu’ils adhèrent à ce scheme. Ce scheme est organisé par l’European Payments Council (EPC), notamment à la demande des instances européennes de l’ERPB.
Où en est l’élaboration de ce scheme européen ?
Une première version des règles, dite Rule Book, a été adoptée par le board de l’EPC et publiée fin novembre 2020, et une nouvelle version est en préparation pour novembre 2021. Une consultation est en cours pour sélectionner les changements à apporter dans la deuxième version des règles.
Parallèlement, et en complément, un document de vulgarisation, dit « clarification paper », a été diffusé début février 2021 afin de préciser les cas d’usage et certaines règles du Rule Book.
Plus récemment, une ultime tâche est en cours avec la sélection d’un organisme appelé « Homologation Body » en charge de l’homologation des acteurs de ce schème – les RTP SP - via un appel d’offre lancé à la mi-février. Celui-ci sera conclu fin avril et permettra de finir la mise en place des conditions d’ouverture du service – au plus tôt - à la mi-juin prochain.
Enfin, pour parfaire le panorama, deux décisions importantes ont été prises par l’EPC en mars de cette année. Le choix du mode API comme protocole d’échange des messages entre les RTP Service Provider, API qui seront à spécifier par la RTP Task Force de l’EPC et à développer par chacun des RTP SP candidat. Le contenu de cet API est déjà bien circonscrit car il s’agit des messages du Rule Book, reste à déterminer la partie protocolaire. À cet égard, une des tâches de cet « homologation body » sera justement de vérifier que l’API développée par le RTP SP est bien conforme aux spécifications.
L'utilisation potentielle des messages ISO d’enrôlement et d’activation (issus des travaux de l’EIPP MSG qui a défini ces « RTP service messages ») pour supporter les processus, d’enrôlement des créanciers (dans un Directory, répertoire qui devra déjà contenir les RTP SP) et permettra de sécuriser l’origine des émissions de RTP ; et d’activation du lien entre débiteur et créancier représentant le consentement entre ces deux acteurs à recevoir/envoyer des RTP.
Quels sont les points saillants de ce schème ? Quels sont les changements à apporter dans la deuxième version que vous évoquez ?
Il faut voir ce scheme comme une passerelle qui permet de raccorder facilement la créance et le paiement associé. C’est un scheme très ouvert car il n’est pas « réservé » aux seuls PSP, en fait n’importe quel Service Provider peut postuler car le schème RTP ne consiste qu’en un échange de messages – certes sécurisé – mais ne contenant pas d’instrument de paiement. Il doit être vu comme un « overlay » en amont du paiement comme décrit dans le schéma joint où la partie « échange de messages RTP » est strictement séparée de la partie paiement.
En fait la vraie valeur ajoutée de la RTP, c’est bien évidemment l’association de la demande de règlement avec son justificatif et l’ensemble des données relatives au paiement destiné au « payee » (le créancier) mais aussi, et encore plus peut-être, l’accord que le « payer » (le débiteur) peut donner sur cette créance. Cette créance acceptée peut en effet être assimilée à une sorte de « reconnaissance de dette » qui représente une vraie valeur pour le « payee ».
Il faut bien voir qu’une facture « acceptée », d’autant plus si on est en BtoB et que le « payer » est une grande entreprise, représente de la quasi-monnaie car cela assure au « payee » qu’il recevra son paiement, même si ce paiement est à 30 jours. D’ailleurs rien n’empêche que ce « paiement à 30 jours » se fasse par SCT Inst… De la même façon, un refus peut survenir, mais dans ce cadre, il vaut mieux le savoir le plus rapidement possible pour le « payee » afin de pouvoir réagir, et ne pas attendre les 30 jours pour s’apercevoir… qu’il n’y aura pas de paiement !
Au niveau retail également et en click&collect par exemple, la RTP permettra d’avoir un parcours fluide vis-à-vis du client « payer » mais une assurance côté commerçant « payee », notamment grâce à l’usage du virement instantané…
Concernant les changements apportés dans la deuxième version du Rule Book, c’est un peu trop tôt pour le dire car les travaux et la consultation de l’écosystème sont en cours. Néanmoins, plusieurs sujets reviennent régulièrement dans les premiers retours : l’articulation de la RTP avec une demande de garantie de paiement, l’usage de lien URL dans la RTP au lieu d’une pièce jointe, le paiement en plusieurs fois ou l’extension à d’autres devises européennes que l’Euro… Cette liste n’est bien évidemment pas exhaustive.
Quelles sont les principales règles fixées dans le rule book ?
Comme dans tout Rule Book au niveau de l’EPC, le « SRTP Rule Book » (pour SEPA Request-to-Pay) liste la description du scheme, principalement les droits et obligations des adhérents au scheme, les différents acteurs, le contenu des messages que ces différents acteurs s’échangent (les datasets) avec les données obligatoires, conditionnelles ou facultatives. Et ce pour les différents messages : la requête elle-même, sa réponse, les messages de statuts (query) et les messages d’annulation pour les cas d’usage retenus en premier lieu qui recouvrent les cas les plus standards de la RTP avec acceptation immédiate ou ultérieure selon la période d’acceptation accordée par le « payee » au « payer » et une fois l’acceptation obtenue, le caractère immédiat ou différé du virement concerné.
Qui pourrait être un « homologation body » ?
Tout organisme qui a l’habitude de gérer des tests et des dossiers techniques dans un environnement sécurisé. L’objectif est de s’assurer que les « candidats RTP SP » qui souhaitent rejoindre le scheme respectent bien toutes les règles de ce scheme et savent échanger en toute fiabilité ces messages en respectant bien les droits et obligations de ce scheme. C’est une fonction assez nouvelle au sein de l’environnement EPC car dans les schemes de paiement habituels ces éléments sont couverts à la fois par les « agréments » des PSP (ASPSP ou TPP) et les infrastructures CSM dévolus aux échanges de paiement. Or, là, comme vous l’avez vu, ce type d’organisation n’est pas prévue car nous ne sommes pas dans un scheme de paiement d’une part et d’autre part car c’est un scheme ouvert à d’autres acteurs que les PSP…
Quel rôle pour les banques dans ce schéma ? Qu’ont-elles à perdre ? Qu’ont-elles à gagner ?
Les banques ont tout leur rôle dans ce scheme, car il y a en fait trois grands rôles ou fonctions associés à ce scheme. Vous avez tout d’abord l’échange de message RTP proprement dit ; mais vous avez également – une fois l’acceptation obtenue – deux rôles qui vont prendre le relais, mais cette fois dans l’univers des schemes de paiement : l’initiation du paiement et l’exécution de ce paiement pour « boucler la boucle ».
Comme vous le voyez, il y a bien trois rôles différents et distincts, mais à y regarder de plus près, seules les banques en tant qu’ASPSP peuvent cumuler les trois rôles simultanément.
Après, chaque acteur a sa place et doit déterminer son propre business case pour offrir le service suivant les différents rôles qu’il peut endosser.
Je me garderais bien de définir ce que les uns ou les autres peuvent perdre ou gagner ; c’est à chacun de se positionner sur ce nouveau scheme très prometteur, c’est malgré tout une évidence de dire qu’il y a des places à prendre et que « la nature a horreur du vide »…
Le RTP existe-t-il déjà dans d’autres pays ? Peut-il être utilisé pour des paiements transfrontaliers (y compris dans un pays hors UE) ?
Oui, plusieurs pays européens – en dehors de la France - ont développé leur « RTP » domestique.
Le scheme européen est semblable à la solution normalisée en France, dans le cadre de SEPAmail. L’idée de base est d’avoir une véritable solution paneuropéenne (donc d’ores et déjà transfrontalière dans l’eurozone) utilisable entre un « payer » et un « payee » quel(s) que soi(en)t le(s) pays de la zone SEPA concerné(s) qui reste – je le rappelle – l’objectif recherché par les autorités européennes.
Pour l’instant, ce scheme est un scheme « européen » applicable aux pays de la zone UE. Nous songeons d’ores et déjà à l’étendre à d’autres devises que l’Euro. Ceci dit, difficile de se prononcer pour le moment au-delà de l’UE…
Ce qu’il faut retenir ici, c’est que nous sommes en train de bâtir une standardisation des échanges de RTP sur toute l’Europe qui assurera une « atteignabilité » de tous les acteurs « payee » et « payers » partout en Europe.
D’autres éléments pourraient-ils venir compléter ce dispositif ?
Pour ma part, et fort de l’expérience que l’on a d’un scheme similaire au niveau SEPAmail, il manque peut-être les aspects relatifs à une « autorité de certification » qui serait habilitée à délivrer des certificats (clés publiques/privées) pour sécuriser les échanges de messages entre les RTP SP et qui permettrait d’avoir un ensemble de règles de sécurité homogènes entre tous les acteurs.
De même, le fait d’avoir un véritable Scheme Manager opérationnel permettrait d’assurer le suivi au quotidien des échanges et la gestion des référentiels d’échanges tant pour les RTP SP que des « Payees » enrôlés par ces mêmes RTP SP.
D’ailleurs, le Scheme Manager pourrait être Homologation body lui-même ou déléguer cette tâche à une entité tierce qui agit pour son compte.
En synthèse, l’Europe se donne ainsi un moyen important d’intégration économique et de réduction des coûts et délais de paiement avec une solution électronique. C’est une brique importante de liaison entre l’activité économique et le paiement dans la panoplie d’outils et de systèmes dont se dote l’Europe, dans le cadre du grand mouvement en cours pour faire de l’Europe un espace de paiement souverain, digital et interopérable.
