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

Annonce: Extension du blog EBICS de PPI – tout sur les paiements!

Chers lecteurs,

Nous avons le plaisir de vous informer aujourd'hui sur l'extension du blog EBICS.

Dans notre blog EBICS « Tout sur les paiements », nous souhaitons à l'avenir vous informer encore plus sur les tendances et thèmes actuels autour des transactions financières dans les domaines EBICS, SEPA, SWIFT ainsi que régularisation et numérisation.

Dès maintenant, le blog EBICS est maintenu toutes les deux semaines par deux équipes d'auteurs. Notre objectif est de vous présenter de première main les perspectives et expériences de nos experts en produits et en conseil issues des projets client, des études et des papiers blancs, au vu des exigences actuelles et futures sur le marché des paiements.

Nous nous réjouissons de votre feedback et nous vous souhaitons une bonne lecture !

Votre équipe d'auteurs PPI

Notifications en temps réel et EBICS - finies les demandes de téléchargement «vaines»

Ainsi que je l’écrivais dans mon article de décembre 2018, le sujet des virements en temps réel (paiements instantanés) pour la clientèle entreprise est devenu d’actualité dans le monde EBICS grâce au nouveau format de paiements instantanés de masse. Lors de l’upload de virements en temps réel, les règles strictes afférentes aux délais de synchronisation des paiements instantanés ne s'appliquent pas à la phase de transfert EBICS. Le temps n’est décompté qu’une fois que le traitement par le serveur bancaire EBICS est achevé.

Et qu'en est-il du sens inverse pour les échanges d’opérations métier des paiements instantanés via EBICS ? Après tout, même si une notification en temps réel (Credit Notification) n'est pas possible en temps réel, il n’en demeure pas moins que le bénéficiaire du paiement doive être informé de préférence assez rapidement. Dans la relation standard entre le client et la banque, le client EBICS est toujours l’initiateur du téléchargement des informations disponibles sur le serveur bancaire. Un envoi via EBICS de telles informations, à l’initiative de l'institution financière, n'est pas prévu. Le milieu économique en particulier a forcé les institutions financières et la Deutsche Kreditwirtschaft (Comité allemand pour le secteur bancaire) à trouver une solution pragmatique pour l’envoi de notifications en mode push. L'objectif final consistant en une solution ne nécessitant pas de modifier le protocole EBICS ni de faire évoluer la notion de rôles (initiateur/répondeur).

Il en résulta l'idée d'une nouvelle interface standard basée sur WebSocket, informant les clients EBICS de la mise à disposition de nouvelles informations pouvant être téléchargées. La disponibilité d'une Credit Notification en fait partie. Ce nouveau canal push ne transfère pas de données sensibles, le téléchargement de telles données se faisant toujours via le canal sécurisé EBICS.

La Deutsche Kreditwirtschaft (Comité allemand pour le secteur bancaire) a désormais spécifié cette nouvelle interface dans la spécification sur les notifications en temps réel, puis publié le document dans sa version 1.0 le 18/07/2019 sur la partie allemande du site web d'EBICS (www.ebics.de).

Il s'agit maintenant de mettre en œuvre cette interface dans les logiciels clients EBICS et dans les serveurs bancaires EBICS, d'une manière rapide et conforme au standard, car elle permet d'optimiser l’activité des clients entreprise, même indépendamment des paiements instantanés. Pour les divers processus de téléchargement, il est ainsi possible d'éviter les demandes de téléchargement « vaines » répétées par les logiciels clients EBICS de façon automatique, qui sont effectuées par exemple lors du téléchargement des relevés de compte. Par conséquent, tant les utilisateurs des clients EBICS que les opérateurs de serveurs bancaires profiteront d'une réduction de la charge. Voilà une bonne nouvelle, n'est-ce pas ?

Auteur : Michael Lembcke

Le protocole EBICS est-il exempt d’authentification forte au sens de la DSP2?

La question nous a été posée maintes fois, que ce soit par des Institutions financières Françaises ou Européennes, et il ne fut pas toujours évident de fournir une réponse suffisamment formelle.

Et bien la Banque de France a récemment répondu de manière officielle en incluant le protocole EBICS dans la liste des procédures et protocoles exemptés d’authentification forte en application de l’article 17 du règlement délégué (UE) 2018/389. Celle-ci précise que « les prestataires de services de paiement sont autorisés à ne pas appliquer l'authentification forte du client à l'égard de personnes morales qui initient des opérations de paiement électronique au moyen de procédures ou de protocoles de paiement dédiés qui sont uniquement mis à la disposition de payeurs qui ne sont pas des consommateurs lorsque les autorités compétentes ont acquis la certitude que lesdits procédures et protocoles garantissent des niveaux de sécurité au moins équivalents à ceux prévus par la directive (UE) 2015/2366 ».

Le texte intégral peut être consulté à l’adresse suivante: https://www.banque-france.fr/stabilite-financiere/securite-des-moyens-de-paiement-scripturaux/2eme-directive-sur-les-services-de-paiement https://www.banque-france.fr/stabilite-financiere/securite-des-moyens-de-paiement-scripturaux/2eme-directive-sur-les-services-de-paiement
 
Attention cela ne signifie pas pour autant qu’EBICS ne supporte pas l’authentification forte, loin de là ! La certitude que le protocole EBICS garantit des niveaux de sécurité au moins équivalents à ceux prévus par la directive est acquise de longue date. D’ailleurs je vous invite à ce sujet à lire ou à relire l’article EBICS et DSP2 : comment vont-ils ensemble? publié dans ce blog il y a quelques mois.

Auteur: Marc Dutech

Vérifier les valeurs de hachage des clés bancaires lors d'une requête d'initialisation EBICS

Les transactions EBICS sont divisées en différentes étapes : initialisation, transfert de données et acquittement (cette dernière ne s'appliquant qu'aux transactions de téléchargement).

Les aspects suivants sont notamment vérifiés lors de l'initialisation:


  • Type d'ordre
  •  Signature d'authentification
  • Valeurs de hachage des clés bancaires
  •  Autorisations relatives au participant


La phase de transfert durant laquelle les données de l’ordre sont envoyées ne peut se dérouler qu’une fois l’initialisation réalisée avec succès. Les valeurs de hachage des clés bancaires sont vérifiées lors de l'initialisation, afin d'assurer que le client utilise les clés bancaires à jour. Si la vérification échoue, le serveur envoie le code retour EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Cela permet d’indiquer au client qu’il doit télécharger les clés bancaires les plus récentes à l'aide du type d'ordre HPB.

Avant l'harmonisation apportée par EBICS 3.0 il était possible d'utiliser les clés bancaires directement ou incorporées dans les certificats. Conformément aux spécifications d’EBICS jusqu'à la version 3.0, les valeurs de hachage des clés bancaires publiques devaient être fournies pendant l'initialisation des transactions – indépendamment du fait qu'il s'agissait d'un échange de certificats ou de clés avec l'institution financière.

À partir d'EBICS 3.0, les certificats sont obligatoires pour la gestion des clés. Il est en plus spécifié qu'il est nécessaire d'indiquer les valeurs de hachage des certificats dans la requête d’initialisation EBICS, tant pour les émissions que pour les téléchargements.

En règle générale, les fournisseurs de serveurs bancaires EBICS offrent à leurs clients la possibilité d’une transition progressive, en permettant de spécifier aussi bien les clés bancaires que les certificats au format DER. Cela signifie que les clients ne sont plus tenus d’effectuer de téléchargement via le type d'ordre HPB une fois la migration vers EBICS 3.0 accomplie. Les clés comme les certificats peuvent être indiqués soit sous forme HEX, conformément à la spécification, soit de manière alternative en codage Base64. Le mélange des deux schémas dans une seule et même requête n'est pas prévu.

À propos : EBICS 3.0 a uniformisé la gestion des clés non seulement pour les clés bancaires, mais également pour les clés du participant. Cela signifie qu'il est d'ores et déjà obligatoire dans tous les pays d'initialiser les participants avec des certificats, chose qui existait jusqu'ici uniquement en France (CFONB). Dans ce cas aussi les serveurs bancaires EBICS permettent généralement une transition aisée : les clés du participant d’une longueur minimale de 2 048 octets peuvent également être utilisées pour EBICS 3.0 et, pour l’activation des clés (types d'ordre HCA, HCS et PUB) les nouveaux certificats peuvent généralement être signés avec les clés des versions antérieures d’EBICS.
Les certificats validés par une AC continuent d'être utilisés uniquement en France. Cependant du point de vue des serveurs bancaires, rien ne devrait s’opposer à ce que ce soit le cas également dans d’autres pays.

Auteur: Hendrik Chlosta

Quel est le rapport entre GPI et EBICS ?

GPI est-il intimement lié à SWIFT ? De prime abord, on pourrait le penser. L’acronyme provient de SWIFT et signifie « Global Payments Innovation ». Lancée à la fin de l'année 2015, l'initiative GPI a immédiatement reçu le soutien de nombreuses institutions financières mondiales.

Le principe de GPI repose sur la référence unique de bout en bout, en abrégée UETR (Unique End-to-End Transaction Reference), qui accompagne un paiement tout au long de la chaîne des banques correspondantes et qui peut dans certains cas se révéler plutôt longue. Elle est composée de pas moins de 36 caractères sous la forme xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx générés au moyen d’un algorithme universel, et elle garantit l'unicité de la transaction sans « organisme d'attribution » central. Alors qu’UETR n'était à l'origine utilisé que dans un seul CUG (Closed User Group) pour les paiements entreprise dans les messages MT103, tous les paiements effectués dans le réseau FIN sont désormais munis d'une telle référence, qui reste identique du début à la fin de la chaîne de paiement.

Le deuxième composant essentiel de GPI est le « tracker », base de données centralisée hébergée chez SWIFT. Il fournit aux institutions financières participantes des informations complètes sur le statut d'un paiement dans la chaîne des banques correspondantes, sur les frais et sur les cours de change des devises. Alors que le transport FIN lit directement ces informations dans les messages échangés, les institutions financières non-FIN peuvent elles aussi fournir activement des informations au tracker. La « Confirmation » qui consiste en la notification du crédit sur le compte du bénéficiaire à la fin de la chaîne de paiement, est actuellement en discussion et devrait devenir obligatoire dès 2020 pour toutes les institutions financières FIN.

Mais pourquoi tous ces efforts ? GPI permet de relever les deux principaux défis du secteur des banques correspondantes, à savoir la transparence et la rapidité. L'utilisation intensive d'UETR a permis d'obtenir des statistiques : en moyenne, 40 % des virements GPI sont comptabilisés dans le compte du bénéficiaire final dans un délai inférieur à cinq minutes, 50 % en moins de 30 minutes, 75 % en moins de six heures et la quasi-totalité en 24 heures. Une telle affirmation aurait été tout simplement impossible avant l'arrivée de GPI. Au contraire, tous les trésoriers ont connu des situations au cours desquelles les paiements arrivaient en retard ou n'arrivaient pas du tout, avec des frais élevés et inexplicables ainsi que des informations peu claires ou manquantes.

En plus des détails techniques tels qu'UETR et le Tracker, GPI fournit également un ensemble de règles stipulant qu'un paiement doit être transmis dans la mesure du possible le même jour et doit être accompagné d'un motif de paiement complet spécifiant les frais déduits ainsi que les détails de la conversion des devises. Puisqu'il n'existe pas de directive globale sur la transparence, celle-ci doit être appliquée sur la base d'accords multilatéraux. C'est une bonne chose - nous attendions une telle mesure depuis longtemps.

Le client (entreprise) devrait bénéficier d'un meilleur service en matière de transactions financières transfrontalières. Nous avons déjà abordé le sujet de la rapidité et la transparence, mais l'accusé de réception joue également un rôle important. À y regarder de plus près, ce principe n'existe que pour les paiements en espèces : dans le domaine des transactions financières électroniques, le slogan « shoot and forget » était jusqu'à présent de rigueur, à savoir que si personne ne se manifeste, nous partons du principe que l'argent est bien arrivé. Les paiements SEPA se sont considérablement développés au cours des dernières années et les paiements instantanés réalisés selon le schéma SCTinst sont maintenant eux aussi accompagnés d'un accusé de réception. L'arrivée de SWIFT GPI permet également de générer un tel accusé de réception, même si cette opération requiert (encore) une chaîne FIN dans le processus de règlement. Il reste toutefois du chemin à parcourir : de nombreux changements sont requis au niveau des institutions financières, dans un premier temps uniquement en interne. La connexion des systèmes clients permettant l'accès aux informations ou même le transfert du statut et des informations relatives aux frais vers les systèmes clients n'en est qu'à ses débuts. En cas de doute, la possibilité de vérifier le statut des paiements dans une base de données centralisée représente déjà une avancée considérable dans le vaste réseau des banques correspondantes.

Ce système peut-il être mis en place en dehors du réseau FIN ? Bien sûr que oui. Les développements actuels, tels que la migration des systèmes de règlement brut en temps réel (RTGS) TARGET2, EURO1 ou encore CHAPS de MT vers des messages en XML conformément à la norme ISO-20022, permettent de faire un pas supplémentaire dans cette direction. Les (nouveaux) formats de message ISO contiennent des champs dédiés à l’UETR, permettant ainsi de transporter la référence également en dehors du réseau FIN. SWIFT a par ailleurs récemment annoncé le « SWIFT trials instant cross-border gpi payments through TIPS »[1].

Les messages sous forme de PSR (Payment Status Report, c'est-à-dire pain.002) sont plus efficaces que les processus manuels pour l’envoi des réponses GPI aux systèmes clients tels que TMS ou ERP. Ces fonctions en libre-service sont déjà un pas important vers plus de transparence. Les normes de ces réponses, c'est-à-dire les champs (tags) et les codes, sont par ailleurs définis par l'initiative d'harmonisation CGI-MP comme solutions compatibles multi-banques. PPI contribue dès maintenant activement à cette initiative.

À l'avenir, les clients devraient également être en mesure d'initier leurs références en tant qu'UETR dans les paiements - comme champ spécial de pain.001.001.03 conformément à l'initiative CGI-MP ou dans des champs prévus à cet effet (déjà disponibles dans les versions ISO les plus récentes).

C'est précisément ici, au niveau de l'interface institution financière/banque ou banque/institution financière, que les paiements des clients et les réponses PSR sont souvent transportés avec EBICS. Plutôt que de s'opposer, les systèmes GPI et EBICS se complètent donc de manière raisonnable, comme c'est souvent le cas pour les transactions financières.

Auteur : Dr Mario Reichel

[1] Source : https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips