Moins de stress grâce à un « libre-service EBICS » ?

Dans mon dernier article EBICS sur mon blog, j'ai parlé des problèmes auxquels les nouveaux clients EBICS sont confrontés lors de l'initialisation (et comment on pourrait les résoudre). Ce qui rend la situation encore plus difficile, c'est que les nouveaux clients n'ont pas ces problèmes une seule fois – la même procédure est répétée pour chaque participant à EBICS.

Est-ce nécessaire ? Que se passerait-il si le premier utilisateur EBICS connecté, pour ainsi dire l'utilisateur 0, avait le droit de créer d'autres participants – et de les authentifier immédiatement ? Comment cela fonctionnerait-il ?

Imaginons un nouveau type d'ordre EBICS administratif que l'on appellerait HUC (EBICS User Create) par exemple. HUC serait un type d’ordre upload, le message EBICS contenu contiendrait les données de base du nouvel utilisateur EBICS ainsi que ses trois certificats. Le message est signé par l'utilisateur 0. Grâce à ces données et à la signature, le serveur EBICS peut immédiatement configurer le participant, les ordres INI et HIA, les lettres et les délais d'attente sont supprimés. Sans aucun problème d'initialisation, un autre utilisateur est configuré et prêt à travailler. Il existe des indicateurs pour la nécessité d'un tel « libre-service EBICS » côté client : après tout, avec EBAM tout est mis en œuvre pour permettre un service très similaire pour les comptes.

Si cela était aussi simple, on l'aurait probablement déjà fait. Deux questions sont inévitables :

1. Comment contrôler un participant EBICS aussi puissant que l'utilisateur 0 ?

2. Quelles sont les données de base nécessaires ?

La première question est facile à répondre : si EBICS est vraiment expert dans un domaine, c'est le contrôle des autorisations. Afin d'éviter qu'un utilisateur 0 ne devienne trop puissant, on crée un utilisateur 1 dès le début et on spécifie qu'un ordre HUC requière plusieurs signatures. De cette façon on obtient un principe de double contrôle et on peut configurer de manière très détaillée qui est autorisé à créer d'autres employés, en utilisant les mécanismes connus des signatures E, A ou B.

La question beaucoup plus délicate est celle des données de base nécessaires. La plupart des personnes impliquées reconnaissent qu'un nom est probablement nécessaire, mais pour le reste, c’est plus difficile. Voulons-nous connaître l'adresse, le numéro de téléphone et l'adresse e-mail de l'utilisateur ? Ces informations peuvent-elles même être obligatoires ? Ou préférons-nous ne pas nous encombrer de données personnelles inutiles à cause du Règlement général sur la protection des données ? Jusqu'à présent, chaque institution financière pouvait prendre la décision elle-même, mais HUC définirait un standard pour toutes les banques. Après tout, il n'est pas utile qu'un standard se compose essentiellement d'un grand nombre de champs facultatifs. Dans ce cas, les institutions financières auront à se mettre d'accord sur un ensemble cohérent de données obligatoires.

La difficulté de ce processus est visible dans EBICS même dans les types d'ordre HKD et HDT. Concus pour permettre à un système client de collecter des informations sur les clients, ses utilisateurs EBICS et leurs autorisations, ces deux types d'ordre restent vagues, car il n'a pas été possible de concilier les modèles d'autorisation développés originaux des différentes banques. Au contraire, de nombreuses institutions financières considèrent leur degré de liberté dans la distribution des droits comme un argument clé de vente. Cela n'est pas compatible avec la normalisation.

C'est pourquoi il semble que les modèles de droits incohérents soient la fin prématurée et certaine d'un libre-service EBICS. Mais il se peut que ce ne soit pas le cas. En réalité la banque nécessite de nombreuses possibilités de distribution de droits pour satisfaire tous ses clients, le client individuel n'en a pas forcément besoin, ou du moins pas tous en même temps. Mais combien de rôles existe-t-il pour une entreprise typique ? Il y a ceux qui peuvent soumettre des ordres mais qui ne peuvent pas les autoriser, ceux qui ont un pouvoir de signature limité ou étendu pour tel ou tel compte, et puis il y a ceux qui sont autorisés à créer des nouveaux utilisateurs. Au total, il une poignée de rôles sont créés lors de la mise en place de l'accord EBICS, parmi lesquels un seul a accès à l’intégralité de la configuration d'autorisations de l'institution financière. Le rôle est ensuite doté d'un nom que le client peut utiliser (par exemple signataire) et qu'il peut ensuite indiquer dans sa requête HUC pour le nouveau représentant.

Un tel modèle de rôle présente encore plus d'avantages. Le rôle peut être adapté aux nouvelles conditions de l'entreprise (un compte a été ajouté) sans devoir consulter les autorisations de tous les participants. Les rôles peuvent également être redistribués. De plus, il est plus facile d'avoir une vue d'ensemble sur les utilisateurs et leurs rôles et donc l'autorisation associée.

Tandis que la définition des rôles restera inévitablement manuelle, l'affectation des rôles peut être faite dans le libre-service d'EBICS. Pour compléter le libre-service, il manque, outre la création, également la possibilité de lire, modifier et supprimer des utilisateurs, c'est-à-dire le R, U et D de CRUD. Les types d'ordre associés peuvent alors être appelés HUR, HUU et HUD. On aurait alors un premier lancement prometteur pour le libre-service EBICS.

Et les problèmes d'initialisation disparaitraient presque complètement.


Auteur: Curd Reinert

EBICS et VEU : La limite des paiements de salaire contenant des informations confidentielles

Pendant de nombreuses années, la signature électronique distribuée (VEU) a été une fonctionnalité importante utilisée par diverses personnes pour télécharger et effectuer des paiements, même à partir de différents endroits.
Les types d'ordre et leur contenu commercial prévus à cet effet à partir du protocole EBICS permettent une validation basée sur le total des données disponibles - via la note d'accompagnement - ou sur la base des données de paiement du contenu. À cette fin, les serveurs EBICS fournissent les informations très importantes pour chacun des paiements uniques contenus déjà sous format préétabli. Un système client qui doit afficher ces données ne doit même pas connaître le format de paiement spécifique. C'est ce qui rend le logiciel si pratique. Exceptionnellement, même un dossier de paiement complet peut être transmis. Cependant, quand il est question des paiements de masse, la facilité décrite ci-dessus n’est plus d’actualité.
Dans la pratique des paiements, non seulement les paiements simples et les prélèvements sont inclus dans le dossier de signatures électroniques, mais les paiements spéciaux contenant des données très personnelles qui nécessitent une protection spéciale doivent également être inclus. Cela comprend les pensions et les salaires ainsi que les primes et gratifications qui ne sont pas destinées au grand public et certainement pas destinée à la libre consultation des salariés dans l’entreprise.
C'est surtout ici que la spécification EBICS montre ses limites : Il manque le GVC ou Code (Purpose), qui spécifie le type de paiement, si les paiements unitaires sont transférés. Les produits EBICS utilisés par le client ne sont pas aptes à protéger les données confidentielles dans un ordre de paiement, même si les entreprises le souhaitaient. Le logiciel n'a pas de critère pour décider si les détails du paiement doivent être affichés ou masqués.
Sans identifiant dans l'ordre de paiement spécifique, il n'est pas possible de distinguer les paiements confidentiels des paiements normaux. Cela signifie que la VEU n'est en principe pas apte à vérifier et à effectuer les paiements de salaire par VEU, car il ne peut être exclu que des employés non autorisés jettent un coup d'œil aux informations strictement confidentielles.
La société EBICS devrait donc envisager une extension du XML pour le HVT, qui transmettra également ces informations importantes concernant le type de paiement. Tant que cela ne se produit pas, la VEU ne peut être utilisée pour les paiements de salaire que dans une mesure limitée.

Auteur : Michael Schunk

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