EBICS: Tous les débuts sont difficiles

Le premier contact que les nouveaux clients ont avec EBICS est généralement le processus d’initialisation. C’est d’une certaine façon dommage, car leur expérience EBICS commence par la partie probablement la plus compliquée et la moins intuitive. Et lorsque ces nouveaux clients auront enfin réussi à se débrouiller avec leur propre technologie réseau, les proxies, les pare-feux et le TLS, à transférer correctement les données du formulaire des paramètres bancaires dans l’application, qui, espérons-le, les a guidés de manière aussi simple et intuitive que possible à travers l’envoi des deux messages d’initialisation, ils seront alors surpris de découvrir qu’ils ne sont en aucun cas enfin prêts à utiliser EBICS. Au lieu de cela, ils doivent d’abord imprimer une lettre INI de plusieurs pages, la signer et l’envoyer à leur institution financière. Et attendre. Attendre que la lettre leur parvienne et qu’un employé de l’institution financière ait entré les 192 chiffres hexadécimaux des valeurs de hachage des trois clés EBICS dans l’ordinateur bancaire. Vraisemblablement toujours conformément au principe du double contrôle.

Si cela est fait - et il n’y a, en règle générale, aucune indication si ce procédé est terminé, ni quand il l’est - les nouveaux clients peuvent enfin commencer à utiliser l’EBICS. Ou presque. Avant cela, ils doivent d’abord avoir récupéré les clés bancaires et confirmé leurs valeurs de hachage qui, espérons-le, seront soigneusement comparées avec celles du formulaire des paramètres bancaires.

Après le traumatisme de l’initialisation première, le reste ressemble pratiquement à une promenade de santé. Dans de nombreuses applications, les clés propres au client peuvent être renouvelées par un simple clic. Les nouvelles clés bancaires peuvent désormais être signées avec les anciennes et acceptées automatiquement. Le véritable inconvénient consiste dans l’obligation - pour toute raison - de se réinitialiser complètement.

En France, la situation est (légèrement) meilleure

Les clients français d’EBICS qui lisent ce blog se demandent peut-être de quoi je parle. Le réseau et le TLS ne sont pas plus faciles à gérer en France qu’ailleurs et les informations du formulaire des paramètres bancaires doivent être saisies, mais au moins l’échange des clés EBICS est aussi simple que possible grâce aux certificats basés sur les AC : Le participant envoie ses clés sous forme de certificats que l’institution financière peut valider et libérer directement sur la base de la signature de l’Autorité de certification émettrice. Le client EBICS peut donc récupérer immédiatement les clés bancaires sous forme de certificats. Et si ces certificats ont également été émis par une AC et que le client fait confiance à cette AC, plus rien ne s’oppose au lancement d’une communication EBICS.

Cette apparente facilité est bien sûr quelque peu illusoire, car les certificats ne tombent pas du ciel. Le processus de certification n’est pas vraiment plus simple que l’initialisation EBICS car, là aussi, il faut que la personne et son identité numérique concordent en toute sécurité. L’avantage est que le processus n’est pas considéré comme faisant partie d’EBICS et il n’est donc pas imputé au protocole. Bien sûr, un certificat peut être utilisé à de nombreuses fins - l’initialisation EBICS, en revanche, n’est toujours valable que pour ce participant dans cette institution financière.

Je ne développerai pas non plus le fait que les certificats entraînent également d’autres problèmes tels que les coûts réguliers de renouvellement, le problème de s’accorder sur une liste d’AC fiables aussi globalement que possible et des scénarios d’échec s’il n’y a qu’un seul fournisseur généralement reconnu pour la vérification en ligne des certificats.

Cela reste donc difficile, mais nous pensons que la situation ne doit pas rester ainsi. Lors d’une séance de brainstorming, nous avons trouvé deux idées que nous aimerions présenter ici - au risque qu’elles se révèlent complètement déconnectées en pratique.

Option 1 : Face-à-face

Notre première idée est que le futur utilisateur d’EBICS prenne rendez-vous avec son conseiller bancaire afin que ce dernier active l’initialisation EBICS. Pendant que le conseiller saisit les données nécessaires telles que le nom et l’adresse, l’identifiant du client et du participant dans le système, au moment opportun, l’utilisateur saisit un mot de passe unique choisi librement – à saisir comme d’habitude deux fois afin d’exclure les fautes de frappe. L’utilisateur doit bien entendu se souvenir du mot de passe jusqu’à ce qu’il se connecte à son client EBICS, puis le saisir à nouveau lors de la configuration de l’accès bancaire. En utilisant le mot de passe, une clé symétrique est alors générée avec laquelle le message d’initialisation - qui contient les trois clés EBICS - est chiffré. Comme l’ordinateur de la banque connaît le mot de passe, il peut générer la même clé symétrique et la communication est protégée contre les écoutes, les manipulations et même les attaques de type « man-in-the-middle ». Par conséquent, le serveur peut renvoyer les clés bancaires directement dans la réponse. Le mot de passe d’initialisation n’est plus nécessaire (et ne doit pas être réutilisé pour des réinitialisations ultérieures).

Le résultat : un seul message EBICS après lequel l’utilisateur est complètement initialisé et prêt pour EBICS. Du côté de l’institution financière, les étapes manuelles après la configuration sont éliminées, le client ne doit pas envoyer de lettre et - surtout - ne doit pas attendre !

Deux problèmes potentiels viennent à l’esprit :

  1. Un attaquant, qui connaît suffisamment bien l’institution financière et le participant, pourrait deviner l’identifiant du client et du participant ainsi que le mot de passe que le client a imaginé et se connecter lui-même avant le participant légitime. Un PIN, par exemple, qui est généré lors de la création du participant et qui lui est donné, ainsi qu’un verrou après n tentatives infructueuses peuvent protéger contre ce risque.
  2. Les erreurs que le serveur signale lorsque quelqu’un devine de façon hasardeuse la clé pourraient permettre des attaques oracle. Là encore, il devrait être utile que le participant soit complètement bloqué après n tentatives infructueuses.

Ce problème pourrait alors être résolu.

Option 2 : Numérisation totale

L’option 1 reste encore trop proche de la situation actuelle : le client reçoit une feuille de papier sur laquelle les données sont indiquées, ensuite il saisit les données dans son application. Mais quel est l’intérêt ? Pourquoi ne pas donner au client ces données sous forme numérique ? Par exemple stockées dans une clé USB que le conseiller peut utiliser directement et remettre au client, qui peut la conserver par la suite, bien entendu avec l’empreinte publicitaire de l’institution financière. Sur la clé USB se trouverait alors un fichier contenant tout ce qui est nécessaire à la configuration :

  • L’URL
  • Les identifiants
  • Une clé symétrique, avec laquelle on sécurise la communication initiale, comme dans l’option 1
Ici, bien sûr, il n’est pas nécessaire de tenir compte de ce dont une personne peut se souvenir ou doit taper, la clé peut être aussi longue que souhaité. Le risque d’une attaque consistant à deviner la clé est ainsi éliminé. Le plus grand danger reste que le client perde la clé USB en rentrant chez lui. Une protection du fichier par mot de passe peut aider dans ce cas.

En revanche, en arrivant chez lui avec la clé USB, il importe le fichier dans son application EBICS. Celui-ci reconnaît le format et peut ainsi établir immédiatement et de manière autonome l’accès bancaire complet - comme décrit dans l’option 1.

Que faire si mon système ne dispose pas d’un port USB ? Il s’agit par exemple d’un smartphone sur lequel je veux m’inscrire pour une application de signature. Dans ce cas, la solution de la clé USB n’est effectivement pas adaptée, mais il est possible d’utiliser les codes QR. Il suffit donc de lui fournir les données de cette manière. Ce peut être également la politique de l’entreprise qu’aucune clé USB ne soit utilisée, même si elle provient d’une source aussi fiable qu’une institution financière. On pourrait bien sûr penser à simplement envoyer le fichier par courriel. Et donc se demander immédiatement après l’intérêt de recourir à une clé USB. La réponse est probablement qu’il n’y en a pas, si (a) le fichier est sécurisé cryptographiquement avec un mot de passe suffisamment sûr et (b) le mot de passe n’est pas dans le même courrier, mais est transmis d’une autre manière sécurisée. Cela devrait être possible.

Atteindre l’objectif

L’initialisation peut être simplifiée. Mais pour que cette simplification soit utile, il ne suffit pas qu’une seule institution financière la mette en œuvre ou - plus absurde encore - un seul système client (fabricant). Ce n’est que si un tel changement est partie intégrante de la spécification EBICS qu’il pourra faciliter la vie des clients et des institutions financières. Dans ce cas la situation sera considérablement facilitée : pour le client, la configuration d’un accès bancaire n’est plus une difficulté et les institutions financières n’ont plus à taper des valeurs de hachage. Dans certains centres d’appel, des employés ne font que cela.

Si l’initialisation est aussi simplifiée, le fait qu’elle doive être effectuée individuellement pour chaque participant EBICS ne pose peut-être plus de problème. Mais là aussi, nous avons réfléchi à des moyens de simplification que j’aimerais présenter dans un prochain article de ce blog.


Auteur : Curd Reinert

All goes ISO 20022

Ce titre fait référence à la migration à l'ISO 20022 pour tous les paiements ainsi que pour le reporting lié. Mon collègue René Keller a déjà écrit au sujet de la migration de TARGET2 et de SWIFT vers ISO 20022, standard déjà en vigueur pour les paiements SEPA, individuels et internationaux. Les modifications décrites, en particulier dans les paiements interbancaires ont des conséquences sur l'interface client-banque.

La pandémie liée au coronavirus affecte de nombreux domaines, et également dans les calendriers de migration. Les changements arrivent mais avec du retard. Il faut bien optimiser ce temps car il ne s'agit pas uniquement d'un sujet lié à l'informatique. La nouvelle norme entraîne des modifications importantes dans les processus de paiements et leurs domaines connexes et les impacts doivent être pris en compte dans l'architecture dans sa globalité. Cela concerne les institutions financières et les entreprises qui surmonteront de nombreux changements dans les versions à venir. Les informations contenues dans les communiqués sont maintenant disponibles dans l'annexe 3 de l'accord EDI (DFÜ) ; elles s'étendent sur quelques années, mais elles sont nécessaires.

Certains experts avancent l'argument selon lequel « les changements à venir ne sont pas si profonds, car nous connaissons déjà le format XML grâce à SEPA ». Si le format utilisé dans SEPA est déjà « bien connu », c'est un très bon point de départ pour se préparer aux changements. Mais l'enjeu est bien plus important. D'une part, SEPA est sur le point d'implémenter une nouvelle version, et d'autre part, il existe toute une série de particularités dans les paiements individuels et internationaux qui ne sont pas du tout présentes dans les paiements de masse. En outre, pour des raisons réglementaires, les coordonnées structurées seront utilisées à l’avenir. Le défi réside dans la multiplicité des changements.

camt.053 – Changement de version

Avec la mise en place de SEPA et du format harmonisé à l'échelle européenne basé sur l'ISO 20022, le relevé de compte camt.053 a également été introduit en plus de MT940 déjà connu. C’était le format idéal pour les paiements SEPA, car il était désormais possible de transférer les données d'un dictionnaire de données uniforme (data dictionary) via les formats pain (client-institution financière) et pacs (interbancaire) sous forme de relevés de compte. Toutefois, outre les écritures dans les paiements de masse, il y avait également des paiements individuels et internationaux. Pour cette raison (entre autres), de nombreuses entreprises ont conservé l'ancien format familier.

Cependant, l'introduction de l'ISO 20022 dans l'ensemble des paiements interbancaires se fait sur une version ISO actuelle, celle de 2019. SEPA utilise toujours la version ISO de 2009. Comme pour toute norme, il y a bien sûr différentes raisons pour l'ISO 20022 de poursuivre le développement du format, et il continuera d'y en avoir. De nouveaux champs seront introduits ou des mots de passe seront étendus. Le relevé de compte, qui doit transmettre toutes les nouvelles informations au client final sans perte de données, doit donc également respecter la nouvelle norme. La migration de camt.053.001.02 à la nouvelle version camt.053.001.08 est donc inévitable (de même pour camt.052 et camt.054). En informant les entreprises à un stade précoce, le délai est désormais suffisamment long pour les cycles de mises à jour ERP souvent plus longs. D’autant qu’il faut s'attendre à ce qu'un report de la migration TARGET2 à l'ISO 20022 retarde également cette migration.

Arrêt du MT940

SWIFT arrêtera les messages MT de catégories 1, 2 et 9 dans la communication interbancaire en novembre 2025. Au niveau de l'interface client-banque (notamment chez SCORE), cette restriction ne doit pas s'appliquer. À ce sujet, les banques du monde entier ne sont pas obligées de désactiver le MT101 ou même le MT940. Mais la DK (Deutsche Kreditwirtschaft) a décidé l'arrêt pour notre « standard multibancaire » - et c'est une bonne chose. Les institutions financières qui le souhaitent peuvent toujours proposer MT940, mais les avantages du nouveau standard sont évidents : des structures XML entières peuvent être transportées de pain via pacs à camt sans conversion. L'analogie avec les conteneurs dans le domaine de la logistique est manifeste. Toutes les entreprises devraient donc être « encouragées » vers ces avantages.

DTAZV devient pain.001

L'introduction de pain.001 comme ordre de client pour un virement SEPA a rapidement soulevé la question suivante : pourquoi ce format ne peut-il pas être utilisé également pour les paiements en devises ? L'initiative CGI-MP (Common Global Implementation – Market Practice) des entreprises, des institutions financières et des fabricants s'est rapidement créée pour harmoniser l'utilisation de ce standard global et définir une cartographie normalisée. Mais la version CGI de pain.001 est basée, comme la version SEPA, sur la version ISO 2009 - c'est-à-dire pain.001.001.03. Le CGI-MP travaille sur une nouvelle version (ISO release 2019) de la cartographie harmonisée. La nouvelle remise d’AZV dans l'annexe 3 sera également basée sur l'ISO 2019 - donc pain.001.001.09.

Enfin, comme souvent, la migration « all goes ISO 20022 » est aussi une grande opportunité, permettant des processus continus sur la même base de données qui peuvent être traités sans qu’une conversion soit nécessaire. La base de la numérisation dans le futur reste la normalisation. Avec « All goes ISO 20022 », les normes sont également valables pour les processus adjacents « Exception & Investigation » (questions), les avis, les messages de frais bancaires (Bank Service Billing camt.086) ainsi que dans le BAM (Bank Account Management) comme messages eBAM. Les transactions financières (y compris les relevés de compte) ne représentent donc qu'une petite partie de l'univers ISO.

Auteur : Mario Reichel

Inquiétude injustifiée concernant les logiciels standard dans les transactions financières

Ceux qui souhaitent se distinguer de la concurrence développent leurs propres logiciels. Cette règle s'impose de plus en plus dans les entreprises – et toujours plus « d'experts » recommandent aux institutions financières d'investir davantage dans leurs propres applications, ou mieux encore de devenir une entreprise technologique. Mais lorsqu’il s’agit de développer une plateforme pour paiement, ces principes se complexifient.

Les autorités exigent par exemple une continuité de service lorsque les institutions financières souhaitent mettre en place des paiements instantanés. Lors du développement de TRAVIC-Payment Hub, nous avons nous-mêmes expérimenté ce que ces exigences impliquent dans l'architecture d'un logiciel. Il s'y ajoute un grand nombre de systèmes périphériques, comme ceux pour la lutte contre le blanchiment d'argent ou les listes d'embargo ou de sanction, sans parler des systèmes de routage. Pour des raisons de coûts, de nombreuses institutions financières préfèrent par conséquent ne pas du tout traiter ces transactions financières en interne et les externalisent auprès d’une institution centrale au sein d'un grand groupe. En revanche, ce procédé se révèle insatisfaisant si le transfert de paiements représente à terme une activité stratégique.

Plaque tournante pour paiements

C’est pourquoi nous avons recherché la composante spéciale qui doit être intégrée dans les systèmes de paiement par les institutions financières pour se démarquer de la concurrence et pour offrir leur propre transfert de paiements. Cet aspect est notamment pertinent pour les institutions qui se présentent comme prestataire de services auprès de clients entreprises pour le traitement d’opérations financières dans certaines régions du monde. Le résultat : les processus de nombreuses banques ne diffèrent guère les uns des autres. Souvent seul l'ordre dans lequel ils sont exécutés les différencie. Suite à ce constat, nous avons conçu une plaque tournante de paiement qui fonctionne comme un manège. Les fonctionnalités spéciales sont accessibles à chaque étape, de la même manière que les enfants peuvent accéder à n’importe quel manège de leur choix dans une fête foraine (voir aussi figure 1).

TRAVIC-Payment Hub permet à une institution financière d'offrir toute configuration envisageable. Cela s'applique à l’administration du routage, pour lequel un ensemble complexe de règles peut être défini, et également aux systèmes périphériques connectés. Mais de quelle façon TRAVIC-Payment Hub sait-il ce qui est censé se produire, si par exemple le système de conformité nécessite une action ? En règle générale, ce sont les systèmes périphériques qui doivent s'adapter aux indications du système principal. Donc pourquoi les banques s’encombreraient-elles d'un nouveau défi de transfert de paiements, surtout après avoir probablement abandonné un monolithe dans leur système central ? La solution est de doter chaque moteur de workflow intégré de son propre script, ce qui permet une connexion aisée et efficace du fournisseur (par exemple PPI) aux autres systèmes.

Le mot « Hub » dans TRAVIC-Payment Hub est donc dans le même temps un nom de produit et un service.

Développement de logiciel à l'inverse

Techniquement, nous nous penchons particulièrement sur ce qui autrement deviendrait une « monnaie » à l'extérieur. Le langage de script implémenté permet à une institution financière d'intégrer ses propres fonctionnalités métier dans TRAVIC-Payment Hub, sans devoir modifier le code source du logiciel. En raison de la séparation de la technique et de la fonctionnalité métier, une partie essentielle du développement du logiciel est ainsi transférée du fournisseur à l'utilisateur. De cette façon, les mises à jour sont toujours supportées, même si TRAVIC-Payment Hub doit gérer un réseau complexe de systèmes périphériques. De plus, les départements informatiques ne seront pas tentés de modifier le code du système de traitement des paiements principal et ne risqueront donc pas créer des problèmes en cascade.

Dans la pratique, TRAVIC-Payment Hub reçoit les différents statuts des systèmes connectés. Le langage de script est utilisé en interne par les développeurs du département informatique ou le prestataire intégrateur, pour définir la manière de traiter les paiements selon leurs différents statuts. Dès que la définition du workflow est terminée, le système compile le code pour que TRAVIC-Payment Hub s’exécute. Des tâches créées par le moteur de workflow sont traitées par un moteur de tâches interne. Ci-dessous un exemple simple sur la manière dont le langage script utilisé dans TRAVIC-Payment Hub de PPI traite les OUR Charges, c'est-à-dire comment TRAVIC-Payment Hub vérifie si les frais d'un paiement sont intégrés dans le paiement et s'ils peuvent être retenus ou si une demande de paiement doit être créée pour encaisser les frais.
Status CHECKINBOUNDCHRGS {
    if payment is inbound and (payment is ourCharges) then {
        if payment is ourChargesReceived then {
            just set status VALIDATERECEIVCHGS and leave step
        }
        if payment is correspondentChargeExpected then {
            if payment is debitAuthorized then {
                just set status CREATEADVICEOFCHGS and leave step
            }
            just set status CREATECHARGEREQ and leave step
        }
    }
    just set status DONE and leave step
}



Introduire TRAVIC-Payment Hub

Avec la gamme de produits TRAVIC, PPI couvre le processus entier de paiement d'une institution financière, depuis la réception du paiement jusqu'à sa compensation en passant par les activités interbancaires. TRAVIC-Payment Hub représente le traitement noyau des transactions financières. Notre solution fonctionne en tant que banque de client et banque de compensation – même en fonctionnement parallèle – et elle offre également une fonctionnalité pour paiements instantanés. En plus, la solution permet autant l’exploitation locale que l’externalisation du produit de haute disponibilité logicielle, en partenariat avec nos partenaires infrastructurels.

Auteur : Thomas Riedel



Plus d'informations :

SEPA 2.0 : La mise à jour du standard ISO 20022 risque de causer une triple migration

SEPA et le standard ISO 20022 sur lequel il est fondé peuvent être considérés comme des moteurs parmi les initiatives globales ISO 20022. Très tôt, ils se sont présentés comme des règles de fonctionnement (rulebook) pour les différents formats de paiement dans la zone euro, les utilisant en tant que standard de format commun pour permettre l'interopérabilité transfrontalière et inter-systèmes. Malgré certaines spécificités locales, SEPA a permis un traitement continu de bout en bout sans discontinuités et conversions de supports au cours des dernières années, notamment en harmonisant les caractéristiques nationales avec une spécification EPC uniforme. Le traitement de bout en bout s'applique dans ce cas non seulement à la relation interbancaire mais également à la communication du donneur d'ordre au bénéficiaire. Cela est rendu possible par l'utilisation cohérente d'un dictionnaire de données uniforme (data dictionary) au format ISO 20022 qui fournit une base uniforme pour l'échange de données en transportant des éléments de données des messages client-banque (pain) jusqu’aux messages interbancaires (pacs) en passant par les messages des clients bancaires (camt) sans conversions.

Tandis que SEPA continue son évolution (notamment en raison de l'introduction des paiements instantanés), la norme ISO 20022 utilisée pour le SEPA doit encore rattraper son retard : plus particulièrement en ce qui concerne la base 2009 définie par l'EPC. Cette norme ISO étant également en constante évolution pour refléter les développements actuels, le groupe de travail EPC responsable de la poursuite du développement du schéma SEPA prévoit de migrer tous les schémas (SCT, SCT Inst, SDD Core, SDD B2B) vers la version 2019 de la norme ISO 20022. La transition doit être annoncée en 2020 et entrera définitivement en vigueur en novembre 2022 dans le cadre d'une migration big bang (des formats interbancaires). Ce changement, entre autres, fait actuellement l'objet d'une consultation publique en tant que demande de modification majeure (Change request). Au cours de cette phase, des remarques sont demandées au cercle des parties participant à la consultation.

L'une des raisons pour lesquelles cette demande de modification, « CR » est importante est la prise en charge future de Request to Pay (demande de paiement), qui ne peut pas être fournie avec la version ISO actuelle car les futurs éléments requis ne sont pas disponibles dans son format. Cependant, une version à jour de la norme ISO est également requise pour d'autres développements futurs, en particulier à la lumière des migrations TARGET2 et SWIFT MX, qui sont également basées sur la version 2019 de la norme ISO.

La bonne nouvelle est que la norme ISO 20022 est déjà bien implantée dans le monde du SEPA. Contrairement à l'introduction de SEPA, il n'est pas nécessaire d'introduire un nouveau format ni de remplacer les anciens formats à grande échelle. Les systèmes existants doivent « seulement » être ajustés et apprendre à traiter les changements tels que les nouveaux éléments de données. Néanmoins, le défi est de maîtriser une migration big bang avec des effets sur les paiements interbancaires et les formats à l'interface client-banque.

La mauvaise nouvelle: est qu’en raison des développements actuels, la date de transition SEPA coïncide désormais avec le début de la période de transition de SWIFT MT à MX. L'idée originale de réaliser la transition SEPA en 2022 avait pour objectif de ne pas exécuter les trois grandes migrations - TARGET2, SWIFT MX et SEPA ISO 20022 Version 2019 - presque en même temps et d'ainsi séparer l'effort nécessaire. Si TARGET2 aussi prévoit un décalage de la migration big bang prévu, comme il est déjà revendiqué par le marché, toutes les migrations auront lieu en même temps ce qui représente un défi majeur pour les prestataires de services financiers concernés annulant l'approche initiale de séparer les différentes migrations. A qui la faute ? La réponse est vite trouvée : la pandémie mondiale de Corona a mis à rude épreuve notre vie quotidienne et l'économie.

Dans cette situation, les institutions financières doivent garder un œil sur les développements futurs et s'adapter aux changements à venir. Nous surveillerons également de près les événements en cours et continuerons de rendre compte des modifications de l'ISO SEPA une fois la consultation du marché terminée.

Auteur : René Keller

DSP2: Sécuriser les paiements de masse via EBICS

La sécurité des paiements de masse a toujours été un problème. Les premières tentatives visant à établir une protection simple contre la manipulation frauduleuse se sont avérées peu efficaces et n'ont donc jamais conduit à une sécurité fiable. Par exemple, le total de tous les numéros de compte des bénéficiaires a été créé pour empêcher les criminels de modifier ultérieurement les paiements. Mais lorsque l'IBAN est arrivé, même cette méthode extrêmement simple n'était plus utile - les institutions financières l'ont finalement abandonnée en raison des défis mathématiques impliqués.

Il ne reste à ce jour que le nombre de paiements inclus et le montant total. Personne ne prétend que de telles valeurs offrent une protection efficace.

La DSP2 et du RTS ont été plus prometteurs pour fournir plus de sécurité pour les paiements. Cependant, ils n'ont pas conduit à une percée pour les paiements de masse qui sont particulièrement courants chez les entreprises clientes. Pour cause : afficher le bénéficiaire, le compte et le montant et demander au client de vérifier toutes les données contenues, par exemple via un lien dynamique, est difficilement réalisable pour le paiement des salaires dans une entreprise de plus de 10 000 employés. Cela est impossible d'un seul point de vue organisationnel et peut difficilement être réalisé en utilisant les canaux établis sur le plan technique.

Alors, comment s’assurez-vous que le fichier de paiement, une fois créé, est exécuté, sans altération, par l'institution financière ?

La réponse est EBICS !

EBICS est la norme en matière de paiements aux entreprises européennes depuis des années. Il est disponible dans tous les grands pays où le volume de transactions est élevé, tels que l'Allemagne, la France, l'Autriche et la Suisse. D'autres pays suivront.

Alors pourquoi la société EBICS ne définit-elle pas une norme d'audit générale et obligatoire basée sur des procédures internationales de valeur de hachage (par exemple SHA-256) et n'établit-elle pas l'ensemble de règles correspondant ? Le principe est le suivant : toutes les applications qui génèrent des fichiers de paiement de masse génèrent toujours la valeur de hachage correspondante et la transmettent à l'institution financière avec le fichier de paiement. Ainsi, cette valeur de contrôle peut être recalculée dès l'arrivée du fichier de paiement et présentée au client pour vérification avant validation. C'est aussi simple que cela !

Simple et très efficace, car la valeur de hachage identique garantit qu'aucune manipulation n'a eu lieu entre la création du fichier de masse et le traitement de masse par l'institution financière.

Si, pour la définition de la procédure de valeur de hachage par la société EBICS, nous considérons également le client final, au lieu de la comparaison à 32 valeurs doubles, un algorithme pourrait être trouvé qui transforme la valeur de hachage en un nombre composé de 8-10 chiffres - semblable à un TAN. Les clients et les utilisateurs utilisent déjà ce type de valeurs de nos jours. Une comparaison des valeurs de contrôle ne nécessite qu'un minimum de temps et est facile à faire.

Par ailleurs, laisser l’établissement de cette définition au marché seul n’est pas une bonne idée. Si tous les acteurs impliqués font leur propre définition, une multitude de procédures différentes vont être créées, ce qui déroutera les clients au lieu de fournir une sécurité supplémentaire.

C'est donc l'une des tâches de la société EBICS de fournir une solution contraignante à ce stade et de répondre ainsi aux exigences de la DSP2 pour les paiements de masse.

Auteur : Michael Schunk

eBAM – composante de la numérisation

Une crise peut aussi être un catalyseur de progrès. La crise du corona virus est inédite comparée aux crises précédentes en ce sens qu’elle nous plonge dans le monde numérique - de l'enseignement à domicile au home office, la pression est exercée sur la réévaluation de nombreuses activités sur de nombreux aspects. Ce gap qui n’était pas perçu comme tel devient flagrant dans un contexte de confinement et de restrictions en tout genre.

Et quand on parle de solutions de Cash Management ici, dans le blog, je pense que le sujet de la gestion des comptes bancaires (Bank Account Management) en fait également partie. Cela comprend non seulement l'échange de messages sur l'interface client-banque, mais également la gestion des données de base de la banque et du compte et de leurs autorisations de signature (pas uniquement les signatures numériques) ainsi que de tous les documents associés, les processus dans l'ensemble du cycle de vie du compte et la confirmation de l'équilibre fastidieux. C'est là que toutes les exigences en matière de KYC ainsi que les autorisations et les identités numériques entrent en ligne de compte.

Ces sujets auraient pu depuis longtemps être transférés dans le monde numérique dans le cadre d'eBAM - la gestion électronique des comptes bancaires. La normalisation est nécessaire ici et elle commence par l'orthographe correcte. EBAM ou eBAM ou e-BAM ?

Il est temps de réagir - de nombreux blocs de construction sont disponibles. Certains éditeurs de solutions de Cash Management ou de gestion de la trésorerie proposent des modules spécialement pour l'administration des données côté entreprise. Des réussites peuvent déjà être rapportées pour les premiers processus d'ouverture de compte purement numérique. Il y a également eu des développements encourageants concernant le KYC et les identités numériques. Même les messages à l'interface client-banque en XML selon la norme ISO 20022 sont en principe disponibles. La poursuite du développement de la norme est également examinée par un groupe de travail du CGI-MP (mise en œuvre mondiale commune - pratiques du marché) - une initiative mondiale des entreprises, des institutions financières et des fabricants pour l'harmonisation de l'utilisation de l'ISO 20022 à l’interface client-banque. Les normes sont à la base de la numérisation. Ils créent une sécurité pour les fabricants et les utilisateurs.

En Allemagne, avec l'annexe 3 de l'accord DFÜ, il existe une longue tradition multibancaire - c'est-à-dire une norme qui atteint de nombreuses institutions financières. Pour cela, il est désormais possible d'intégrer des rubriques optionnelles telles que la facturation des services bancaires (BSB). Tout le monde n'a pas besoin de soutenir le sujet - mais s'ils le font, ils doivent se conformer à la norme. Et je voudrais plaider pour une telle option au sujet de l'eBAM. Pour EBICS, il est facile de transporter les messages XML dans le groupe de messages camt (gestion des comptes) - les normes (harmonisées) doivent être convenues. Le cas d'utilisation simple d'une vue d'ensemble des autorisations de signature montre un premier pas dans cette direction avec EBICS en utilisant le type de commande HKD, mais - voir ci-dessus - ce n'est encore que le début.

Il est bien entendu que la partie communication client-banque d'eBAM ne doit pas être réalisée via EBICS, car un itinéraire de transport via SWIFT est également possible. Même les API ouvrent de nombreuses possibilités. Indépendamment du canal, la base devrait être une standardisation du contenu (XML en harmonie avec json) et des processus de base. Et pour le contenu au format XML selon ISO 20022, un chapitre supplémentaire devrait être ajouté à l'annexe 3 de l'accord DFÜ.

Sur cette base, les fournisseurs mentionnés ci-dessus peuvent ensuite étendre leurs produits pour le « multi-bancaire » et les institutions financières peuvent offrir de nouveaux services à de nombreux clients avec des systèmes similaires - leur permettant ainsi de s'intégrer très bien dans le monde numérique avec ces services.

Auteur : Dr. Mario Reichel

L’impact du M2M : Communication entre machines sur les transactions financières

L’économie du M2M « Machine to Machine », Internet des objets connaît une croissance rapide. Toujours plus de machines et appareils sont interconnectés. D’ici 2025, 75 milliards d’appareils devraient être interconnectés dans le monde entier. Selon les analyses de BizIntellia, un prestataire IdO américain, les solutions autour l’IdO contribueront à hauteur d’environ 14,2 milliards de dollars au PIB mondial d’ici 2030.

À l’avenir, l’IdO occupera une place significative dans nos vies et dans nos sociétés. La question est de savoir quel impact aura l’IdO sur les paiements ?
Quels sont les potentiels nous réservent les paiements Machine à Machine (M2M) ?

Comment l’IdO et les paiements sont-ils connectés ? Les machines sont autorisées à transférer non seulement des identités et des informations, mais également des valeurs. Ils envoient des paiements à d’autres machines de manière autonome, sans avoir besoin de validation humaine. Toutefois, si ces transactions commerciales ne peuvent pas s’exécuter sans interruptions (par exemple, les machines doivent attendre une action manuelle telle qu’une confirmation de paiement), des périodes de blocage ou même des terminaisons anormales peuvent en résulter - les deux scénarios doivent être évités, afin d’exploiter pleinement le potentiel des paiements M2M.

Mais les paiements M2M ne sont pas uniquement des visions futures. Des solutions concrètes sont déjà en cours de développement, par exemple, dans l’industrie automobile. Certaines entreprises mettent déjà en place les écosystèmes nécessaires. L’idée est que les automobiles aient leurs propres portefeuilles avec de l’argent électronique et puissent ainsi payer les frais de carburant ou de péage sans intervention humaine.

Afin d’analyser l’impact des paiements M2M, nous avons mené une étude sur le thème « Machines payantes » qui traite notamment des questions suivantes :

  1. Quelles conditions préalables doivent être remplies pour permettre la mise en œuvre des paiements M2M ?
  2. Quels sont les défis de la mise en œuvre des paiements M2M ?
  3. Dans quelle mesure le nombre de transactions de paiement augmentera-t-il en raison des paiements M2M ?
  4. Quels moyens de paiement conviennent le mieux aux paiements M2M ?
  5. Quel impact les paiements M2M ont-ils sur les prestataires de services de paiement ?
  6. Comment les prestataires de services de paiement devraient-ils réagir aux paiements M2M ?

Pour que les paiements M2M deviennent une réalité, les machines participantes doivent d’abord recevoir leur identité propre de machine comportant des attributs individuels les distinguant des autres machines. Une identité de machine sécurisée ne peut être ni manipulée, ni falsifiée ou ni utilisée à mauvais escient. La machine reçoit une identité unique et sécurisée qu’elle peut utiliser pour s’authentifier au sein du réseau productif auprès d’autres machines, instances et participants.

Il y a un vide juridique en matière d’objets connectés. En effet des progrès doivent être faits sur le plan réglementaire. Il faut établir des règles de responsabilités claires pour les actions des systèmes autonomes et pour l’allocation des risques liés à l’utilisation des systèmes autonomes. Enfin et surtout, de nouveaux systèmes de responsabilité sont nécessaires qui tiennent compte des particularités des machines autonomes.

En termes de mise en œuvre pratique, nous avons identifié les domaines d’action suivants, dont la solution sera particulièrement difficile:

  1. Cartographie de l’identification des paiements automatiques
  2. Contrôles de conformité par rapport à une machine (KYO au lieu de KYC)
  3. Traitement des informations retournées (y compris les perturbations des processus)
  4. Prise en compte d’un reporting plus complexe et plus complet
  5. Sécurité accrue des machines et des interfaces
  6. Mise en œuvre cohérente de l’intégration numérique et des processus numériques

De nombreuses analyses suggèrent que le nombre de transactions augmentera considérablement avec les paiements M2M. Nous sommes d’accord avec cette évaluation et prévoyons également une augmentation significative. Compte tenu des effets de compensation, nous estimons que d’ici 2027, il y aura environ 12 milliards de transactions de paiement « Machine à Machine » supplémentaires en Allemagne et environ 50 milliards dans l’UE.


Tous les modes de paiement électronique courants ne sont pas adaptés aux paiements M2M. Nous pensons que la monnaie digitale (stable coins : indexées sur un actif réel, unbacked coins : non indexées sur des actifs réels et devises électroniques) et la monnaie électronique sont les plus adaptées aux paiements M2M.

Les méthodes de paiement établies ont généralement des frais de transaction plus ou moins élevés. Les solutions de crypto-monnaie et de monnaie électronique, en revanche, permettent des transactions peu coûteuses même pour les plus petits montants et les rendent attrayantes pour une utilisation dans l’IdO. Après tout, ils offrent la possibilité de régler économiquement même les petits paiements de services, pour un montant inférieur à un centime ; comme, par exemple, l’utilisation d’une ampoule dans une maison intelligente. Les solutions de monnaie électronique et de crypto-monnaie peuvent également être intégrées indépendamment des prestataires de services financiers traditionnels.

Reste à savoir comment les prestataires de services de paiement devraient se positionner à l’avenir. L’Internet des objets renforcera encore la tendance à la différenciation des fournisseurs spécialisés avec un modèle commercial basé sur les données et des fournisseurs d’infrastructure.

Les fournisseurs spécialisés peuvent utiliser l’augmentation du volume de données due à l’IdO à leur avantage dans la concurrence du marché et développer des opportunités commerciales. Par exemple, des services supplémentaires personnalisés avec précision peuvent être proposés aux clients sur la base de données d’utilisation détaillées. Cela dépend de la capacité des prestataires de services de paiement à se placer « au-dessus » des machines ou au moins à agir comme des agrégateurs de données qui compilent les données d’utilisation pertinentes en chiffres et les transfèrent.

En ce qui concerne le positionnement en tant qu’agrégateur de données ou hub de données, les prestataires de services de paiement pourraient également assurer la confiance nécessaire entre les personnes, les entreprises et les machines participantes, et agir comme une sorte d’instance de compensation pour les identités numériques sécurisées et les données valides.

En résumé, cela signifie que les prestataires de services de paiement traditionnels doivent surmonter des défis considérables. Les exigences fonctionnelles et surtout techniques de l’infrastructure des prestataires de services de paiement entraîneront des changements massifs. Ils doivent répondre aux prérequis suivants : 

Disponibilité totalement ininterrompue, augmentant l’importance des modèles d’exploitation 24/7/365 et du traitement des transactions en temps réel
  • Les temps d’arrêt pour l’installation de nouvelles versions ne sont plus possibles.
  • Capacité à gérer des charges très élevées en raison de milliards de transactions supplémentaires
  • Possibilité de faire la distinction entre les paiements automatiques et non automatiques, car ils seront traités par des règles différentes
  • Possibilité de numérisation complète et d’intégration de la machine
  • Conformité future avec KYO pour les machines, qui n’est actuellement pas encore réglementé, en combinaison avec KYC, cartographie dans les systèmes correspondants et, en particulier, réglementation organisationnelle
  • Possibilité non seulement de déclencher des paiements, mais également de traiter les informations en retour du système et de traiter les perturbations en conséquence. Sur la base du retour d’expérience, les machines doivent pouvoir tirer les bonnes « conclusions » en temps réel et sélectionner des alternatives si nécessaire.
En outre, les prestataires de services de paiement doivent décider comment ils souhaitent se positionner et ajuster les structures de vente, car les écosystèmes de l’IdO deviendront de plus en plus importants.

Auteur: Michael Titsch