ISO 20022 dans les paiements internationaux : c'est l'heure du changement !

Presque tous les grands systèmes de paiement sont en train d'introduire des formats de données standardisés basés sur XML. Ils rendent les paiements internationaux et propriétaires plus rapides et produisent moins d'erreurs. Par contre, la transition ne va pas de soi et il ne reste pas beaucoup de temps. Que faut-il prendre en considération ?

Les paiements par carte pendant les vacances et les virements internationaux sont désormais considérés comme acquis dans la vie quotidienne. Toutes les transactions électroniques nécessitent cependant des processus très complexes, car pour assurer des transactions financières rapides et fluides, tous les systèmes informatiques concernés doivent être en mesure de traiter les données générées de la même manière. Un standard tel que l'ISO 20022 est requis à cet effet, étant donné qu’il sera la référence pour les paiements internationaux et individuels dans les années à venir.

Un standard éprouvé pour l'avenir

Toujours plus d'espaces de paiement migrent leurs systèmes vers le standard ISO car ses avantages sont considérables : il est évolutif, il permet un traitement des données de paiement beaucoup plus rapide et il permet une efficacité considérablement accrue. Les conversions d'un format de données vers un autre ne seront plus nécessaires. De plus en plus de données pourront être directement traitées sans interactions ou ruptures de supports  (STP).

Ne sous-estimez pas l'effort

Mais ce n'est pas sans coûts. Le passage à l'ISO 20022 exige des ressources humaines et financières. En ce moment de nombreuses institutions financières sous-estiment l’effort nécessaire. Elles doivent non seulement automatiser des processus manuels éventuellement existants, mais aussi adapter leur propre logiciel à l'ISO. S'il s'agit comme souvent des systèmes Legacy établis, la préparation des processus pour le traitement des paquets de données XML est exigeante. Et le temps presse : la mise en service de la conversion de TARGET2 au standard XML est prévue pour le 21 novembre 2021. À cette date débutera une période de coexistence avec SWIFT.

Un sentiment de préparation trompeur

Les institutions financières européennes appliquent déjà les standards basés sur ISO, car ils servent de base au SEPA. Mais cela ne signifie pas qu’elles peuvent rester les bras croisés. En fonction du type de mise en œuvre, des adaptations s’imposeront dans tous les secteurs importants de l'informatique des transactions financières : des données de base aux systèmes back end en passant par l'e-banking. Sans parler de l’impact sur l'architecture future du Core banking.

Diverses implémentations du standard ISO

Nous ne devons pas oublier qu'il s'agit d'un standard générique, qui définit uniquement les principes de base pour les messages de paiements. Lors de chaque implémentation spécifique le standard est adapté de manière appropriée, ce qui signifie qu'elle peut être différente pour TARGET2, SWIFT et SEPA. De la limitation des codes ISO et types de données autorisés à l'élimination des éléments facultatifs du message de base non utilisés, différentes variantes sont imaginables. Voilà pourquoi une seule solution pour tous les scénarios est irréaliste pour la migration.

De nombreux projets spécifiques

Il n'est donc pas correct de parler d'une seule transition ISO 20022 alors qu’en réalité existent bon nombre de projets distincts. Il est donc d'autant plus important d’impliquer très tôt le service IT afin d’aider les équipes métier à identifier à temps les pièges et les problèmes et, non des moindres, à estimer les coûts. Car la conversion des paiements internationaux et individuels de TARGET2 au standard XML est susceptible de générer un coût global de l’ordre de sept à huit chiffres. Ce montant inclue l'étude préliminaire, l’implémentation et les adaptations IT. Il faut en plus budgéter les formations des employés impliqués et le développement en temps voulu du savoir-faire nécessaire, ou alternativement l'intégration d'un partenaire externe.

Quelle est la suite ?

Si elle n'existe pas encore, les institutions financières ont besoin d'une feuille de route dans les meilleurs délais – contenant tous les tâches et jalons nécessaires pour la conversion au standard ISO. Un inventaire objectif de la situation actuelle sert de base, il n’est contournable par personne. À cette occasion il peut aussi être opportun de se demander si la fourniture de paiements transfrontaliers par sa propre institution sera toujours économiquement viable ou si une coopération renforcée avec des prestataires de services externes représente une meilleure solution.

Faire du changement une opportunité

La transition à l'ISO 20022 met sans aucun doute les prestataires de services financiers sous pression, surtout si nous considérons la consolidation quasi simultanée de TARGET2 et de TARGET2 securities. Par contre, les changements réglementaires sont également une possibilité pour vérifier critiquement ses propres systèmes et pour déterminer leurs capacités à être modélisés de manière agile et flexible. En fin de compte, cela aide à faire progresser la transformation numérique dans son ensemble – car l’immobilisme n'est pas une option dans le monde numérique d'aujourd’hui.

Auteurs invités : Sabine Aigner, Raija Wehrli

EBICS 3.0 – un ensemble de paramètres au lieu du type d'ordre Que faut-il prendre en compte lors de l'identification des opérations métier ?

Avec EBICS 3.0 les différentes opérations métier ne sont plus effectuées via les types d’ordres, mais via les nouveaux paramètres BTF.

Afin de permettre l'utilisation de contrats client avec des clients EBICS de différentes versions d'EBICS combinées avec EBICS 3.0, des règles de mapping ont été spécifiquement développées par les organismes nationaux de spécification. Ces règles suivent généralement les cinq paramètres BTF Service Name, Service Scope, Service Option, Service Message Name et Service Container. Il est important que la combinaison de ces paramètres BTF dans le serveur bancaire EBICS soit unique. Cela permet de s'assurer qu'un type d'ordre peut être attribué à l'opération métier via BTF et vice versa.

Dans la pratique, des ordres identiques d'un format donné peuvent être créés dans différentes versions de format et soumis au serveur bancaire. Bien que des ajustements de format soient effectués régulièrement par les organismes de spécification, la version de format utilisée par le système client dépend également de la version du logiciel client. Comme la version de format doit être transparente dans les logiciels clients, leurs utilisateurs n'ont aucune influence sur les envois dans une version de format spécifique lors de la compilation de leurs remises. En outre, les institutions financières acceptent en règle générale différentes versions de format d'une opération métier. En fin de compte, pour le traitement côté banque, la version de format correspondante peut également être lue à partir du namespace du fichier XML, au moins pour les formats XML. Jusqu’à présent, les serveurs bancaires sont conçus de manière flexible pour différentes versions de format.

Les autres paramètres BTF applicables pour EBICS 3.0 sont Service Message Name Format, Service Message Name Variant et Service Message Name Version. Si une institution financière inclut également ces autres paramètres dans les mappings des types d’ordre et les détails des contrats client, il convient de prendre en considération certains aspects. S’ils n’ont pas déjà été utilisés plus intensivement via le paramètre FileFormat ou s’ils ne sont pas nécessaires pour des raisons inhérentes au traitement, ces paramètres supplémentaires devraient être pris en compte de manière plus mesurée du côté des banques pour les tests EBICS.

Finalement, ces informations supplémentaires sur les paramètres font déjà partie du fichier d’ordre lui-même et, de toute façon, elles peuvent être lues à partir de ce dernier. Que faut-il faire en cas d’indications contradictoires ? Un surplus de gestion dans le serveur bancaire implique plus de temps et davantage d'efforts pour la gestion des référentiels. Il devrait y avoir un accord client propre à chaque version de format d'une opération métier. En plus, ces détails de format sont visibles par le client dans le logiciel client et certains d’entre eux ne peuvent pas être contrôlés.

Que se passerait-il si, par exemple, le serveur bancaire prenait en charge les versions 03 et 04 d'un format XML lors de la remise, mais que le client remettait la version 04 dans le BTF au lieu d’utiliser la version 03 du format ? L’ordre serait rejeté lors de la prise en compte de la version, bien que le système bancaire puisse traiter la version de format. La version réelle est reconnaissable au moyen du namespace.

La mise à disposition de fichiers pour download est encore plus compliquée. Celle-ci devrait être générée de manière synchrone dans la version demandée à la date/heure de téléchargement et être publiée en tant que fichier. Il en va de même pour les téléchargements historiques.

Conclusion : les institutions financières ne devraient pas être trop restrictives dans leurs définitions des accords BTF avec leurs clients. Cela leur permettrait ainsi d’être plus flexibles et d’économiser du temps et des efforts supplémentaires dans la gestion des contrats et des référentiels.


Auteur: Michael Lembcke

Paiements avant Noël – achats de Noël avec la demande de paiement ?

Les fêtes de Noël approchent. Pas aussi manichéennes, pas aussi simples et paisibles que les histoires le racontent – mais à leur manière tout à fait charmantes. Cependant, cette période de fin d’année peut être un peu déroutante, en particulier quand je regarde les relevés de compte de mes expériences d’achats effectués avant Noël.

La plupart des gens le savent : les bonnes intentions du type « ...mais cette année nous n’offrirons rien ! » sont encore moins valables que les résolutions du Nouvel An qui ne manqueront pas de suivre. Et même si on a l’impression que Noël commence en automne avec le premier pain d’épices sur les étagères, le temps des achats de cadeaux est toujours reporté à la dernière minute. Cette année encore je me retrouve encore une fois prise dans la folie du shopping. Parents, sœurs, grands-parents, famille du conjoint avec cinq frères et sœurs – et la génération suivante est déjà à la porte. Concilier les différentes listes de souhaits, listes d’achats et attentes avec mes relevés bancaires semble être un travail de Sisyphe.

Mes boutiques en ligne préférées possèdent mon mandat de prélèvement automatique alors que dans d’autres magasins digitaux, seuls les paiements par carte de crédit sont possibles. Je paie les billets de concert avec PayPal et les commerçants via Girocard pour les produits achetés dans les réseaux physiques ou « hors ligne ».

Retrouver toutes ces positions sur mon relevé de compte qui est beaucoup trop long me rappelle que je dois encore commander un puzzle trois mille pièces pour ma tante. Le service à thé pour ma grand-mère a-t-il déjà été payé ou sera-t-il débité plus tard ? Quand ma facture de téléphone sera-t-elle encaissée ce mois-ci ? C’est d’habitude cette semaine, n’est-ce pas ? Et qu’est-ce que ce « shop XY », et pour quoi a-t-il reçu 90 € de ma part ?

Comme chaque année, j’ai l’impression que la folie du shopping me submerge et je perds la vue d’ensemble. Le décalage entre la commande et le paiement ainsi que les différents délais me laissent un sentiment désagréable– surtout qu’en cette période de débits inhabituels de mon compte, quelque chose peut m’échapper facilement. À quoi me sert-il de pouvoir faire une réclamation sur un débit effectué par prélèvement si je ne peux plus ensuite l’identifier ? Quel paiement par carte de crédit ai-je vraiment autorisé ?

Cela devrait être plus facile. Cela devrait être plus ordonné. Cela devrait être plus immédiat. L’année prochaine à la même époque ?

Je m’imagine commander la nouvelle radio pour ma mère et que mon application bancaire me demande de débloquer le montant, au moment de la commande. Les pull-overs de Noël kitsch avec le nez de renne sont commandés en deux tailles différentes et essayés. Et qu’au moment de retourner le pull beaucoup trop grand, ma banque en ligne me demande si je débloque le paiement pour le bon pull.

Trois paquets sont à ma disposition dans l’entrepôt de livraison. Afin d’ouvrir le paquet, j’autorise le paiement après en avoir reçu la demande. Le magasin XY réclame encore 90 € de ma part ? Rejeté ! Je n’ai rien commandé chez eux. Et en décembre ma facture de téléphone était apparemment plus élevée que d’habitude et pour cette raison la demande de paiement n’a pas été confirmée automatiquement. Je vérifie le relevé des appels et j’autorise la facture manuellement – c’est exact, j’ai appelé ma famille en Angleterre.

Voilà ce qu’est la demande de paiement. Qui sait si cela rendra la prochaine période des fêtes de fin d’année plus calme et plus paisible. Mais avoir plus de contrôle sur mes paiements avant leurs exécutions et ainsi éviter des regards inquiets sur mon compte, cela sonne presque aussi bien que d’avoir un Noël blanc.

Auteur : Anuschka Clasen

XS2A sans prestataires de services tiers ? Pourquoi pas !

Dans le cadre de la DSP2, une interface pour les prestataires de services tiers (API XS2A) a été introduite dans toute l’Europe. En tant qu’initiateur, l’UE souhaite permettre à des tiers d’accéder aux comptes bancaires des clients et ainsi promouvoir la concurrence sur le marché. Le 14/09/2019, l’API XS2A a été mise en production par les banques en Europe dans les délais prévus. Depuis lors, les participants du marché adaptent l’API XS2A aux besoins des parties prenantes et font évoluer intensivement les services proposés aux consommateurs et entreprises.

En tant que « service obligatoire » conformément à la règlementation, l’API XS2A constitue un facteur de coûts initial pour les institutions financières. Cependant dès le début ont été pris en compte des services à valeur ajoutée et ils ont été spécifiés par le Berlin Group, par exemple, offrant ainsi aux institutions financières de nouvelles sources de revenus. Mais dans le battage médiatique actuel autour de l'API, il n'y a pas de limites aux fantasmes concernant les sources de revenus.

Pour l’instant nous surfons donc sur la vague médiatique et imaginons l'API XS2A comme un canal d'accès alternatif pour les entreprises. Pourquoi pas ? D’un point de vue technique, les obstacles devraient être peu importants. Une entreprise pourrait s’identifier comme prestataire de services tiers au moyen d’un certificat eIDAS. Le certificat ne différerait que dans les champs spécifiques pour les prestataires de services tiers. Comme c’est le cas pour EBICS, les ordres émis ou les demandes pourraient être accompagnés d’une signature, permettant au destinataire du message d’en vérifier l’intégrité. La sécurité du transport est garantie par l’utilisation de TLS.

Du point de vue métier, le cas d’application « Initier un paiement » permet tant l’exécution d’un paie-ment unique que l’exécution d’un paiement de masse. Les procédures d’autorisation habituelles de la banque en ligne pour la validation sont à la disposition des consommateurs (par exemple photoTAN et pushTAN). Cela ne conviendrait probablement pas aux entreprises, de sorte que les sceaux des entreprises seraient utilisés, ce qui reste à spécifier. L’API XS2A permet également de consulter les informations sur les comptes (soldes, transactions détails). Dans ce cas particulier où existe une relation de confiance entre l’entreprise et l’institution financière, le consentement (consent) requis à cette fin pourrait être donné par le biais d’un consentement valable en permanence.

L’API XS2A serait alors une vraie alternative qui est déjà discutée dans divers forums. L’idée est vue comme « moins cher, plus pratique, exécution en temps réel, plus flexible dans les ajustements ». Cependant le status quo nous ramène rapidement sur terre. La spécification du Berlin Group donne aux institutions financières une grande liberté d’implémentation de l’API. Dans le but d’atteindre toutes les institutions financières en Europe via XS2A, cette liberté d’implémentation représente actuellement un défi pour tous les participants sur le marché. C’est une situation qui n’est pas ou pas encore favorable pour les entreprises. Mais la première pierre en direction d’une alternative est posée.


Auteur: Christian Wenz

Notification en cas de réception de paiements instantanés SEPA – un composant élémentaire dans la chaîne des paiements

Outre les délais courts inhérents au virement en temps réel, la notification immédiate du bénéficiaire du paiement quant à la réception du paiement est un élément clé des paiements instantanés SCT et des autres étapes associées de ce processus.

Ce qui est désormais bien réalisé dans le traitement des transactions en ligne ou dans la relation entre le commerçant et le client – comme décrit par Michael Lembcke dans l’article « Notifications en temps réel et EBICS - finies les demandes de téléchargement «vaines»  » – représente toujours un défi pour les différents acteurs dans l’environnement EBICS. Les notifications sur le chiffre d'affaires ont fait leur entrée dans l’annexe 3 de l'accord DFÜ (en vigueur depuis novembre 2019) et y sont spécifiées en tant que messages camt.054, qui peuvent être téléchargés via le type d'ordre EBICS C5N. Par contre, ces derniers doivent être récupérés activement par le bénéficiaire du paiement depuis l’institution financière. Une notification push active du bénéficiaire du paiement n’a pas été prévue jusqu’à présent. Il est désormais possible de combler cette lacune en étendant la spécification EBICS à une notification basée sur le protocole WebSocket du serveur bancaire envoyée au client. Les informations sur le chiffre d’affaires peuvent ainsi être téléchargées rapidement, dès que la réception de paiement sous-jacente a eu lieu. Les demandes de téléchargement «vaines» sont alors éliminées.

Étant donné qu’une notification directe de la réception du paiement entraîne également un déroulement des processus plus rapide et plus efficace, il est temps d’examiner de plus près cette fonction importante.

Le point de départ de notre voyage dans le monde des notifications instantanées est l’interconnexion globale de la société. Les services numériques sont disponibles à tout moment et tout lieu dans le monde et ce de plus en plus en temps réel – « toujours disponible, toujours instantané ». Alors que les délais liés aux procédures de paiement classiques duraient parfois plusieurs jours en fonction du pays destinataire, et que les processus logistiques restaient lents lors de l’envoi d’une marchandise, la numérisation croissante permet des chaînes de processus toujours plus courtes, stables, sans ruptures de supports et sans délai d’attente et assure aussi une forte croissance dans le domaine de nouvelles offres numériques.

Certaines étapes de la chaîne trop imbriquées les unes avec les autres ne peuvent être transférées facilement dans le monde instantané, car il existe des dépendances vis-à-vis du monde non numérique. D’autres étapes sont déjà disponibles 24h/24, 7j/7, 365 jours par an – certaines avec une durée de quelques secondes. Le processus de commande et le processus de paiement associé en font partie.

Le mot clé est « paiements instantanés », permettant un crédit immédiat du montant payé chez le bénéficiaire et garantissant ainsi un service immédiat après le paiement. Ce qui fonctionne pour les produits numériques est bien plus difficile pour la vente par correspondance. Une accélération de l’intégralité du processus grâce à une réception du paiement plus rapide chez le commerçant est envisageable, mais une disponibilité directe de la marchandise commandée est presque impossible, ce qui signifie que le client paye en avance même si la durée du processus est raccourcie.
L’achat sur facture représente pour le client l’option la moins risquée. Pour le commerçant/fournisseur elle comporte des risques élevés, car ce dernier fournit la marchandise en avance et ne peut pas compter sur un règlement rapide de la créance. Le paiement anticipé par les méthodes de paiement classiques, y compris les cartes, entraîne uniquement un renversement de la position de risque, mais pas un risque équilibré entre le commerçant et l’acheteur. Seul un intermédiaire peut actuellement remédier cette situation, qui exécute en tant qu’instance fiable pour le commerçant et l’acheteur la remise de la marchandise et la procédure de paiement au même moment. Pas de paiement – pas de marchandise et vice versa. C’est alors le processus de paiement à la livraison classique.

Quel est le rôle de la notification du bénéficiaire du paiement ? Sans notification immédiate du bénéficiaire sur la réception du paiement, les processus accélérés ainsi que les produits innovants, basés sur un paiement direct, sont impensables. L’opération ne peut être conclue ou du moins, la prochaine étape de la chaîne du processus ne peut être déclenchée que par une information, qui est intégrée dans le processus de paiement et qui est envoyée immédiatement après le paiement – soit par un processus en ligne via une API qui est restituée à cet effet par l’institution financière, soit via l’utilisation du canal EBICS en combinaison avec un service push.

Jusqu’à présent les notifications sur le chiffre d’affaires ont été faites par information sur les comptes intra-journaliers (MT942) ou relevé de compte (MT940), qui était restitué avec un délai d’un jour. En raison de la nécessité d’une réponse immédiate, prévue pour SCT Inst en cas d’une réception de paiements instantanés, ce n’est que la finalisation de la procédure de paiements qui est possible. Ceci est notamment indispensable pour l’application des paiements instantanés sur le POS. Les longs délais d’attente jusqu’à ce que la transaction soit complétée empêcheraient l’acceptation du client. La référence est la durée d’un paiement par carte.

Ce n’est seulement pour le POS qu’une notification immédiate est importante : Les procédures de paiements existantes, par exemple le paiement de facture par paiements instantanés dans l’online banking ainsi que le paiement classique à la livraison, pourraient en profiter. Dans le premier cas, l’avantage consiste en un déroulement accéléré du processus pour toutes les parties concernées. Le deuxième cas se réfère surtout à la substitution des instruments de paiement classiques, comme l’argent ou les cartes.

En ce qui concerne le développement des futures méthodes de paiement, par exemple Request to pay (demande de paiement), la notification jouera un rôle significatif. Dans ce contexte je voudrais vous renvoyer vers un autre article du blog EBICS de mon collègue Eric Waller qui a traité de ce sujet : « La demande de paiement modifie les transactions financières - premiers cas d’utilisation ».

Auteur : René Keller

Erreurs de format des ordres EBICS – services de test pourraient aider

EBICS a été spécialement conçu pour des échanges de données sécurisés et performants avec des fichiers de toute taille entre banques et entreprises. Pour les ordres de paiement le contenu d'un fichier à envoyer vers le serveur EBICS doit toujours correspondre à l'opération métier définie (type d'ordre, paramètre FileFormat ou BTF) et aux spécifications de formats y afférentes. Lors des remises de paiements, des fichiers de remise contenant des transactions unitaires regroupées par compte du donneur d'ordre sont couramment utilisés. La création de comptes-rendus (HAC et PTK) des procédures EBICS côté serveur est en partie spécifique au format des ordres de paiement. Les vérifications d'autorisation et la création des comptes-rendus requièrent donc que le serveur bancaire EBICS connaisse et puisse lire au moins les informations importantes du format de remise (par exemple compte du donneur d'ordre et montant). Afin de lire ces informations le serveur bancaire EBICS effectue un contrôle de format. Généralement il interrompt le contrôle dès que la première erreur de format est détectée. L'ordre est refusé en raison d’une erreur de format laquelle est documentée dans le compte-rendu client.

Pourquoi le fichier n'est-il pas entièrement vérifié et pourquoi les erreurs détaillées ne sont-elles pas consignées dans le compte-rendu client ?

Il y a plusieurs raisons à cela. En premier lieu les contrats de services habituels pour l'e-banking via EBICS visent à la remise et au traitement rapide des fichiers corrects. Une vérification intégrale du format avec compte-rendu d'erreurs n'est pas incluse et ne fait pas partie des tâches fondamentales d’un serveur bancaire EBICS. En plus, les capacités des serveurs bancaires doivent être utilisées pour le traitement immédiat des ordres conformes au format et non pour l'analyse de fichiers incorrects.
Mais comment une institution financière peut-elle offrir à ses clients entreprise un service qui améliore la qualité des ordres de paiement quant au format et au contenu, sans charger inutilement le serveur bancaire EBICS ?

Les clients pourraient pour cela utiliser des services de test tels que la plateforme de test ISO-20022. Dans le cadre de l'harmonisation des paiements suisses, les banques suisses offrent déjà une telle plateforme à leurs clients afin de tester les formats d'entrée et de sortie.

La plateforme de test simule les conditions en production spécifiques à la banque. À l'aide de cette plateforme, les messages banque-entreprise XML peuvent être validés et l'interface banque-client peut être simulée.

Un élargissement de la plateforme test ISO-20022 à la vérification des ordres de paiement pour des conventions de format et des contenus propriétaires peut encore améliorer considérablement la qualité du fichier. En faisant préalablement une vérification complète de format des ordres de paiement, des erreurs pourraient être identifiées rapidement et facilement, grâce à un compte-rendu d'erreur détaillé.

Il est ainsi possible, lors d’une vérification préalable, de détecter et de corriger les fichiers dont le format et le contenu ne sont pas corrects, avant de les envoyer vers le serveur EBICS.


Auteur: Aline Wendler et Michael Lembcke

La demande de paiement modifie les transactions financières - premiers cas d’utilisation

La demande de paiement, également appelée Request to Pay (R2P), est un nouvel instrument de paiement qui modifiera durablement les paiements. Dans le papier blanc « Request to Pay completes the electronic payment process » (disponible en anglais et en allemand), j’ai déjà expliqué le rapport entre la facturation électronique, les paiements instantanés et l’instrument de paiement « Request to Pay » qui n’existait pas jusqu’à présent.
Je profite de cet article pour présenter les quelques premiers cas d’utilisation qui peuvent facilement être envoyés vers un compte bancaire existant, via la demande de paiement.

  • Demande de paiement dans le cas d’une facture déjà émise : un cas d’utilisation simple consiste par exemple en l’envoi classique de la facture, puis de la demande de paiement. Ce cas vise d’abord à accélérer le paiement de la facture dûe en facilitant le traitement des données qu’elle comporte par le débiteur. La demande de paiement relative à la facture déjà reçue par le débiteur est affichée dans son application bancaire en ligne ou sur son mobile avec les données du bénéficiaire, le montant du paiement ainsi que le motif de paiement déjà renseignés. Le débiteur n’a plus qu’à confirmer les données et signer son exécution avec ses identifiants.

  • Demande de paiement combinée avec une facture commerciale : le cas d’utilisation décrit ci-dessus s’applique également dans le cas où la facture électronique et la demande de paiement correspondante sont simultanément présentées au débiteur dans son application bancaire en ligne ou sur son mobile. L’envoi habituel par la poste n’est plus nécessaire, le débiteur peut consulter électroniquement sa facture et payer de manière aisée. Cette méthode offre aussi la possibilité de stocker numériquement la facture dans un système d’archive bancaire et de la rapprocher numériquement et à tout moment avec un paiement.

  • Demande de paiement par étapes : il va sans dire que la demande de paiement peut être utilisée en cas d’une séparation spatiale. Il est ainsi également concevable de numériser l’ancienne méthode de paiement à la livraison. Le fournisseur adresse un message de demande de paiement au destinataire qui vérifie la livraison de la marchandise et lance un ordre de paiements instantanés en réponse à la demande. Le distributeur reçoit de son côté une notification indiquant la réception du paiement et débloque la marchandise.

  • Demande de paiement dans le commerce traditionnel : comme expliqué dans le cas précédent, il serait possible d’utiliser la demande de paiement en combinaison avec les paiements instantanés et les notifications. Dans ce cas, ce n’est pas la facture qui est transférée mais le ticket de caisse qui est transporté conjointement avec le message de demande de paiement et qui peut être enregistré dans une archive numérique du compte, avec la comptabilisation. Le personnel de caisse ne débloque l’achat qu’une fois la notification reçue.

Les demandes de paiement peuvent être utilisées dans différents secteurs d'activité et je pense donc que le nouvel instrument de paiement « Request to Pay » modifiera durablement les paiements tels que nous les connaissons. Je continuerai à publier des mises à jour fréquentes sur les développements en cours et sur d’autres cas d’utilisation.

Auteur : Eric Waller