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

EBICS-Security – Quand est-il temps de mettre à jour votre système client ?

EBICS spécifie différentes fonctions et règlementations de sécurité qui doivent être respectées par les clients et les institutions financières. Ces dernières doivent toujours veiller à ce que les spécifications les plus à jour soient mises en œuvre et supportées par leurs serveurs bancaires EBICS. Cependant, les clients EBICS et chaque utilisateur ont aussi la responsabilité d’utiliser à tout instant des logiciels client répondant aux standards de sécurité EBICS en vigueur. Il est donc primordial, tant en raison des adaptations fonctionnelles que pour des raisons de sécurité, de mettre à jour fréquemment les logiciels client EBICS.

Toutefois, la mise à jour d’un logiciel client EBICS existant ne signifie pas que ce logiciel EBICS sera automatiquement capable de communiquer avec l’institution financière en utilisant la version EBICS et les procédures de sécurité les plus récentes. En fonction de la version EBICS et des fonctionnalités client utilisées précédemment, il est nécessaire de mettre à jour les différentes clés d’application pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006) ainsi que la version d’EBICS à utiliser, suivie d’un échange de ces données avec les serveurs bancaires EBICS. Il peut aussi être nécessaire de mettre à jour le cryptage Internet (TLS) vers une version plus récente et plus sécurisée en échangeant des certificats renouvelés. De telles mises à jour requièrent en règle générale une intervention proactive et des ajustements manuels de la part de l’utilisateur EBICS.

Pourquoi ces mises à jour sont-elles importantes ?

La communication EBICS via Internet possède ses propres spécifications en termes de procédures de sécurité. La société EBICS les met à jour et les adapte régulièrement aux exigences de sécurité en vigueur au moyen de nouvelles versions d’EBICS. Un exemple est la longueur des clés. Les anciennes versions d’EBICS permettent encore d’utiliser des clés de longueur 1 024 bits pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006). Mais cette longueur ne répond plus aux exigences de sécurité actuelles, car les clés trop courtes sont considérées comme peu sécurisées. Les versions plus récentes d’EBICS n’acceptent que des clés d’une longueur minimale de 2 048 bits. Un autre exemple est mis en évidence avec les procédures et les versions du cryptage TLS. Afin de répondre plus aisément aux recommandations de sécurité, par exemple à celles de BSI en Allemagne, la société EBICS a créé une annexe distincte des spécifications EBICS 3.0, appelée Transport Layer Security qui comporte les directives y afférentes. Comme les spécifications de la version 2.5 d’EBICS ne pouvaient pas être adaptée rétroactivement, la DK (Die Deutsche Kreditwirtschaft) a en outre publié en 2019 son propre document de recommandations intitulé Recommandations concernant les protocoles de sécurité EBICS et la longueur des clés (disponible en allemand et en anglais). Il contient des informations sur les procédures de sécurité à utiliser pour EBICS. Voir aussi www.ebics.de et www.ebics.org.

Afin de permettre aux utilisateurs d’EBICS une transition en douceur vers les nouvelles versions d’EBICS et les nouveaux standards de sécurité, la plupart des institutions financières proposent toujours à leurs clients les versions plus anciennes, en parallèle avec les nouvelles. Malheureusement, il est devenu évident que dans de nombreux cas cela conduit à ce que les clients ne saisissent pas l’occasion de mettre à jour leur communication EBICS. Nombreux sont ceux qui continuent à utiliser les anciens systèmes et procédures. Il est donc plus difficile pour les institutions financières de mettre fin à ces anciennes procédures.

En fin de compte, chaque acteur de la communication EBICS s’attend à ce qu’un échange de données sécurisé soit assuré. Personne ne veut subir de dommages. Ce qui signifie que chacun doit apporter sa contribution. Bien entendu la sécurité d’EBICS n’est pas la seule chose que les institutions financières et les entreprises doivent garder à l’esprit. Après tout, toutes les parties impliquées doivent prendre toutes les mesures de sécurité possibles dans leurs infrastructures et dans leurs solutions logicielles afin de prévenir les abus et les pertes.

Alors, pourquoi attendre ? Allons-y.

Auteur: Michael Lembcke

Open banking : EBICS versus API

L'Open banking est l'une des tendances de fond que de nombreuses institutions financières risquent de manquer. Puisque presqu’aucune interface DSP2 ne semble être prête pour le marché, les autorités de surveillance bancaire ont accordé une période de transition allant jusqu'à décembre 2020. Mais le problème est autre : de nombreuses institutions ne ressentent que peu d'envie d'investir beaucoup d'argent pour faciliter la vie des fournisseurs d’interfaces d'Open banking – d'autant plus que les protocoles établis comme FinTS et EBICS offrent beaucoup plus de possibilités que « l'APIsation » du secteur bancaire.

Les deux protocoles, FinTS et EBICS, couvrent déjà presque tous les domaines des opérations bancaires : des paiements aux opérations de crédit en passant par les transactions de titres. Au total, plus de 200 processus sont disponibles qui décrivent de façon contraignante tant les interfaces métier que la communication technique entre les partenaires participants. Dès les années 90 HBCI et FinTS ont été les pionniers en matière de standards ouverts dans la communication avec les institutions financières. Il y a plus de dix ans qu'EBICS a été introduit par la Deutsche Kreditwirtschaft (DK) ou par son prédécesseur comme standard contraignant pour les échanges avec les entreprises. L'Open banking est donc une réalité en Allemagne depuis de nombreuses années.

Aucune interface DSP2 uniforme en vue


Aussi bonne que soit l'idée de l'Open banking, les évolutions auxquelles pousse la DSP 2 laisse perplexes beaucoup d'institutions financières, même celles qui veulent avancer. D'un côté, la DSP2 est supposée servir de base à une norme européenne d'Open banking. De l’autre, le législateur a délibérément laissé ouverte la question de savoir comment la communication doit avoir lieu et comment elle peut être sécurisée. En conséquence, les fournisseurs d'API pour l'Open banking exhortent les banques à implémenter leurs solutions et à adopter leurs propres interprétations de l'Open banking, juste pour ne pas être marginalisées. En plus, différentes initiatives dans divers pays développent des protocoles pour les aspects technique/métier des applications, ce qui conduit à un nombre incontrôlé des types d’API. Les concepts transnationaux par contre sont encore loin d'être en vue.

Tout cela pourrait devenir un puits sans fonds pour les institutions, s'il n'y a pas bientôt une spécification uniforme de la DSP2 que chaque banque puisse suivre. Tant que cela n'arrivera pas, de nombreuses visions de l'Open banking resteront des vœux pieux. Après tout, selon la loi, l'ouverture doit être gratuite et exempte de discrimination. Gagner de l’argent avec elle est réservé à d’autres acteurs. Alors, quelle devrait être la motivation d’une banque à continuer d’ajouter des nouvelles API gratuitement, juste pour que les prestataires tiers puissent plus facilement augmenter leurs parts de marché ? Cela rétrograderait les institutions elles-mêmes au rang de simples fournisseurs de services. Il est beaucoup plus raisonnable de s’en remettre à des standards établis de longue date.
EBICS : Open banking pour entreprise

L'un de ces standards est EBICS. Il est largement répandu : outre l'Allemagne, EBICS est aussi populaire en France. Il existe un accord de coopération entre la Deutsche Kreditwirtschaft et son équivalent français, le CFONB. Ces deux plus grands marchés des paiements de la zone euro utilisent EBICS pour les entreprises et les opérations interbancaires. La Suisse (SIX) est également fan d’EBICS, et l’Autriche (STUZZA) envisage d’y participer. Au lieu de se perdre dans le maquis des API, il vaut mieux se demander comment EBICS peut évoluer pour être conforme à la DSP2. Et la réponse est : avec une signature à distance (voir figure 1). Un portail EBICS moderne peut générer la signature et l'envoyer au serveur bancaire EBICS en utilisant des données entrantes comme le code d'un PhotoTAN ou d'un QR TAN au moyen de dispositifs matériels.
Figure 1 : Comment les signatures à distance EBICS étoffent EBICS pour en faire une solution d'Open banking conforme à la DSP2
EBICS offre de nombreux avantages aux entreprises. Celles qui disposent d'un client EBICS peuvent effectuer des opérations bancaires multiples et également utiliser la signature électronique distribuée (VEU). De cette façon, les modèles de rôles et de droits peuvent être réalisés (signatures T, A, B et E), pour déterminer par exemple, si les ordres de paiement sont remis par des personnes autorisées ou si la personne concernée dispose des autorisations appropriées pour valider ces ordres de paiement. Tout comme pour FinTS, ce qui suit s'applique également à EBICS : l'infrastructure nécessaire pour mettre en œuvre l'Open banking existe déjà. Rien que pour cette raison il est compréhensible que de nombreuses institutions aient du mal à investir pour le moment. Rien ne garantit qu'elles choisiront le bon fournisseur d'API ou que les législateurs n'adopteront pas de nouvelles règlementations rendant obsolètes les investissements déjà réalisés.

Auteur : Michael Schunk

Big Bang de T2/T2S : les institutions financières risquent d'être exclues des transactions financières

Pour le grand public, les transactions financières fonctionnent de manière invisible et fiable. Mais cela ne doit pas rester ainsi. Inconnu du public, le sujet d’actualité le plus important est la consolidation TARGET2/TARGET2-Securities, et avec elle la migration ISO 20022 ainsi que le nouveau modèle de comptes. Les institutions financières qui ne relèvent pas ces défis à temps risquent d’être exclues des transactions de paiements – et les clients en ressentiront les conséquences.

La migration concerne tous les participants au système TARGET2 actuel et elle a lieu dans l'infrastructure des institutions financières, des banques centrales et de la Banque centrale européenne (BCE). Du fait que la transition s’effectuera en mode Big Bang, c'est à dire simultanément pour toutes les institutions financières en Europe le 21 novembre 2021, les retards de chaque institution peuvent avoir des conséquences négatives sur l'économie. Des complications dans les systèmes informatiques souvent obsolètes ou des retards dans la réalisation des projets peuvent, au pire, conduire à l'exclusion des paiements individuels, si la bascule ne peut pas se dérouler à la date limite.
Les conséquences pour les institutions financières en cas d'un échec de la consolidation T2/T2S :

  • Exclusion des paiements individuels en monnaie banque centrale
  • Exclusion du traitement des opérations monétaires, ce qui signifie en particulier :
  • Impossible d’utiliser les opérations d'open market.
  • Impossible d'utiliser les facilités permanentes.
  • Impossible de respecter les réserves obligatoires.

Si un système secondaire connecté à TARGET2 comme SEPA-Clearer est utilisé pour les paiements de masse, l'institution financière sera également exclue des canaux de compensation concernés et elle ne pourra plus traiter les paiements.

Les conséquences sont alors dramatiques et menacent la viabilité de la banque elle-même. La seule alternative possible est d’établir une connexion directe via une autre institution. Mais ce procédé devrait être décidé et planifié à un stade précoce et ne pourra pas être mis en place juste avant novembre 2021. Si ceci échoue également, l'avenir de la banque est en péril. Spéculer ou compter sur un éventuel report de la migration serait négligeant.

Toutefois, le défi majeur de la consolidation de TARGET2 est non seulement la refonte de la structure des comptes mais également l'harmonisation technique de l'accès des systèmes existants TIPS et T2S à TARGET2, ainsi que la migration imminente des formats de message.

Accès futur à TARGET2

La connexion à TARGET2 va changer. Jusqu'à présent le service FIN Copy de SWIFT (appelé mode Y Copy) est utilisé. À l'avenir, il y aura une propre architecture de communication dédiée et distincte, fournie par la BCE, qui fonctionnera avec l'Eurosystem Single Market Infrastructure Gateway (ESMIG) comme point d’accès central à tous les services TARGET2. Pour cet accès, un Network Service Provider (NSP) échangeant avec l’ESMIG sera requis en tant que nouveau participant.

Formats de message

L'avenir parle ISO 20022 et aussi TARGET2. Jusqu'à ce jour, TARGET2 utilise toujours les messages MT pour les échanges. Ces messages MT seront remplacés par des messages ISO 20022 en XML (MX), qui seront beaucoup plus complets et qui permettront de compiler beaucoup plus d'informations. Les messages MX ne sont pas introduits dans une approche similaire qui permettrait de transformer  facilement les messages MT en messages MX. Au lieu de cela, le potentiel des nouveaux formats sera exploité d’emblée.

De ce fait et en raison du réaménagement complet de l'infrastructure, une utilisation parallèle ou une solution transitoire avec les deux formats ne sera pas possible.

Trop ambitieux ?

De nouveaux formats de message, de nouveaux canaux de connexion, de nouveaux acteurs et de nouveaux processus – tout cela à une date butoir dans toute l'Europe. Cela peut-il bien se passer ?
En raison de l’actualité de ce sujet, un reporting détaillé avec un calendrier strict est établi via les banques centrales. Les jalons du projet sont définis de manière centralisée par la BCE et l'atteinte des objectifs est régulièrement surveillée. Chaque banque est elle-même responsable de sa propre mise en œuvre. En ce moment, sept marchés participants (y compris l'Allemagne) ont indiqué un statut  jaune, 18 un état vert. À première vue, tout semble encore aller pour le mieux – mais les institutions financières qui sous-estiment les conséquences et les efforts nécessaires pour se mettre en conformité à temps pourraient passer du jaune au rouge plus rapidement que souhaité.

Pour que les choses conservent leur intérêt, la bascule des formats MT vers les formats MX se déroulera en plus de la consolidation de TARGET2. Pour les formats, par contre, une période de transition de quatre ans est prévue pendant laquelle les institutions financières pourront encore utiliser les deux formats. En raison de la proximité de ce thème, il est sensé de le traiter en même temps que TARGET2.

La liste des tâches est plutôt longue et va mobiliser les capacités des institutions pendant les prochaines années. Cela doit également entrer dans les esprits des membres du conseil d'administration. Il ne s'agit pas seulement d'un « exercice obligatoire », mais de la viabilité de chaque institution.

Auteurs : Swaantje Anneke Völkel, Thomas Ambühler

EBICS pour la compensation et le règlement des transactions de paiements instantanés SEPA – le nouveau document Delta comme jalon

Depuis l'introduction de SEPA en Janvier 2018, le protocole de transfert EBICS est également utilisé dans les opérations interbancaires pour la compensation bilatérale et le règlement ainsi que pour l'échange des paiements SEPA avec la Deutsche Bundesbank. Au fil des années, le nombre d'institutions Européennes qui utilisent EBICS n'a cessé de croître. Il n'est alors pas surprenant qu’à partir de novembre 2013 EBA Clearing ait aussi offert EBICS comme accès alternatif à ce que l’on désigne par « garage clearing » (compensation bilatérale) et à STEP2.

Après la transition à SEPA, l'introduction des paiements instantanés SEPA fut l’étape suivante vers la standardisation dans le secteur européen des paiements. Toutefois, en raison de l’approche temps réel, ce nouveau type de paiement constitue un défi particulier pour l’utilisation d’EBICS. Alors que l'échange de données basé sur des fichiers était la base de l'utilisation conventionnelle d'EBICS, pour les paiements interbancaires les procédures de paiements instantanés SEPA demandent une approche basée sur des messages relatifs aux transactions. Ainsi en novembre 2017 EBA Clearing a mis en œuvre avec succès le RT1 basé sur des paiements instantanés SEPA.

Afin de promouvoir EBICS dans l'échange et la compensation des transactions de paiements instantanés SEPA, la société EBICS a officiellement publié en octobre 2019 un document Delta relatif à la spécification EBICS (cf. Use of EBICS for the Clearing & Settlement of Instant Payment Transactions, www.ebics.org, disponible en anglais). Ce document décrit les modifications à prendre en considération pour le traitement des paiements instantanés avec la version 3.0 d’EBICS. Pour répondre aux nouvelles exigences nées du fonctionnement en temps réel, le nouveau schéma ebics_inst_request_H005.xsd a été ajouté. Toutefois pour les opérations métiers administratives des paiements instantanés, le fonctionnement d’EBICS basé sur des fichiers et par conséquent le schéma standard demeurent nécessaires. Le nouveau schéma doit être ajouté au schéma global pour l'utilisation des paiements instantanés SEPA avec EBICS.

Rien ne change lorsque EBICS est utilisé dans le cadre des échanges entreprise-banque ou pour les transactions interbancaires qui ne portent pas sur les paiements instantanés.

Le document Delta Use of EBICS for the Clearing & Settlement of Instant Payment Transactions est bienvenu. Dans la pratique, EBICS est largement utilisé et de nombreux autres scénarios sont envisageables. Afin de garantir l'utilisation intégrale et harmonisée d'EBICS les standards ainsi que leur respect sont indispensables. Il faut, par contre, pouvoir réagir de manière flexible aux défis du marché. Ce document répond tout aussi bien à ces deux objectifs. Un autre jalon a été posé sur la voie vers une normalisation des transactions financières en Europe.

Auteur: Michael Lembcke

La demande de paiement modifie les transactions financières - les défis techniques

Notre dernier article du blog concernant la demande de paiement (R2P) nous a montré jusqu’à quel point la demande de paiement pouvait rendre les fêtes de fin d'année plus simple en permettant de réaliser les achats associés de manière parfaitement organisée. Les prochaines fêtes de fin d'années étant encore lointaines, il est encore temps de s’intéresser aux défis découlant de l'intégration des systèmes de paiement basés sur la demande de paiement.

Dans ce contexte il convient en premier lieu de parler de la composante technique. En décembre dernier, EBA CLEARING a publié des spécifications de formats, décrivant tant la demande de paiement (pain.013) que la réponse à la demande de paiement (pain.014). Ainsi, la partie compensation est précisée techniquement et le « seul » défi qui reste à relever est de préparer les interfaces d'entrée et de sortie des systèmes de paiements à ces cinématiques et formats. Cela peut sembler trivial de prime abord, mais c’est en fait un véritable challenge pour les systèmes de paiement : tant le chemin aller (demande de paiement) que le chemin retour (réponse à la demande) doivent être routés par le système de paiement en très peu de temps depuis un système client répondant vers les systèmes de compensation concernés et le système client récepteur et/ou répondant.

Reste bien sûr à déterminer comment les clients pourraient transférer la demande de paiement à leur institution financière. D’un point de vue technique, le Conseil européen des paiements et la Deutsche Kreditwirtschaft (DK) mènent un débat à ce sujet, qui se matérialisera par une spécification technique de l'interface entre le client et la banque.

C'est là que la composante métier entre en jeu. Elle devrait impliquer de repenser conceptuellement les systèmes existants quant au système qui reçoit les demandes de paiement et celui qui doit y répondre. Les questions de suivi qui en résultent traitent par exemple de la manière dont le client peut choisir de payer via SEPA ou SCTINST (à condition que la conception de la demande de paiement permette ce choix). La question de savoir comment le client peut autoriser la demande de paiement n'est pas moins importante. Les méthodes d'autorisation adaptées sont par exemple un dispositif mobile muni d’un système TAN ou une signature électronique disjointe EBICS.

Par ailleurs, les informations sur un avis de paiement suivant une demande de paiement réglée instantément peuvent désormais être restituées plutôt facilement, grâce à la « notification de crédit pour virements SEPA en temps réel ».

Moyennant une bonne combinaison des possibilités techniques, la R2P favorisera certainement le développement des paiements instantanés. Relever ces défis exigera un effort considérable, qui – selon les choix de conception – ne portera ses fruits qu’en cas de mise en œuvre efficace. Nous avons déjà discuté des cas d'application résultant des possibilités techniques dans le livre blanc « Demande de paiement – des possibilités d'application multiples ». N'hésitez pas non plus à nous contacter à tout moment pour des discussions sur le contenu et des discussions techniques.

Auteur : Eric Waller

Multi banques – tout en un seul portail

Les normes comme base de l’automatisation des processus en réseau

Les données sont le pétrole du 21ème siècle. Cela a été prêché lors de toutes les conférences numériques depuis des années. Plus un prestataire dispose de données d'un client, mieux ce dernier peut être regroupé et segmenté en groupes cibles. Ce savoir sur les besoins du client permet de lui composer des offres supplémentaires intéressantes.

Dès lors que dans le cadre de la normalisation les canaux d'accès s’appuient de plus en plus sur   l'Internet, le point de contact décisif entre les institutions financières et leur clientèle entreprise sera assuré par l’agence digitale en ligne telle que le portail web TRAVIC-Port. Si l'opérateur parvient à agréger tous les comptes bancaires du client, y compris ceux que celui-ci détient également auprès d'autres institutions financières, et à les regrouper dans son propre portail, il réunit alors les meilleures conditions pour proposer une vue d'ensemble des opérations de paiement à son client. Plus de comptes sont regroupés, meilleures seront les offres de services que l’opérateur peut proposer à ses clients.

Le mot clé « multi banques » fait référence aux fonctionnalités qui permettent de regrouper de manière optimale les transactions financières d'un client. Les deux parties - clients et institutions financières - tirent bénéfice de ce regroupement sous un même toit. Les clients disposent d’un aperçu global des transactions. L'agrégation concerne tant la remise de tous les types de paiement que le téléchargement des informations sur tous les comptes connectés. Le portail multi banque offre aux utilisateurs une interface utilisateur unifiée et facile à utiliser pour les différents prestataires de services de paiements via un accès sécurisé - et permet ainsi la mise en place de processus internes efficients. Mais le bénéfice de cette automatisation sans heurts de multiples transactions de paiement dépend de la rapidité du traitement et de l'implémentation correcte des serveurs bancaires de différents prestataires. Un niveau élevé de transactions interconnectées dans les deux sens requiert des interfaces uniformisées et la conformité aux spécifications en vigueur. Dans ce contexte la communication basée sur EBICS de TRAVIC-Port met à disposition le protocole technique basé sur Internet pour l’espace SEPA le plus sécurisé. Des adaptations trop larges et des écarts trop importants par rapport aux spécifications empêchent des processus limpides côté prestataire et font obstacle à une consolidation globale et sans faille des paiements. Dans ce cas, tant les clients de fournisseurs de portails que les éditeurs de logiciels devraient agir ensemble. En revanche, les API avec des interfaces propriétaires permettent des adaptations spécifiques aux environnements techniques de chaque institution financière. Cependant tout écart par rapport aux normes retarde l'intégration aisée d’un trafic de données complexe. Une interprétation imprécise des spécifications réduit le degré d'automatisation et le débit de chaque connexion. Plus il y a de lacunes dans un réseau complexe de connexions multi bancaires, moins le client en tire profit et de moindre qualité sont les analyses.

Auteur invité : Christian Veith

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