De nouveaux formats de données et la nécessité d'une mise à jour d’EBICS pour la Suisse – que faut-il prendre en compte ?

Avec le document « EBICS 3.0 Swiss Market Practice Guidelines EBICS, Recommendations for implementing the EBICS standard in the Swiss financial services sector » (recommandations pour la mise en œuvre de la norme EBICS pour la place financière Suisse, disponible en allemand et en anglais) publié en juin 2020 par SIX, la Suisse se conforme désormais au protocole européen harmonisé. Les principaux moteurs de l'harmonisation ont été les membres de la société EBICS, notamment les places financières en Allemagne, en France et en Suisse (le membre le plus récent est l'Autriche).

Par définition, deux versions d'EBICS sont prises en charge en Suisse, c'est-à-dire la version 2.5 et la version 3.0. À première vue, on pourrait donc penser qu’il n’y a pas d’urgence pour les clients et les éditeurs de logiciels car la version précédente est encore disponible. Cependant, en Suisse, il existe le paragraphe 2.2.1 dans « EBICS Timeline », un document de SIX contenant la remarque suivante : La prise en charge de la migration de schéma ISO 20022 vers la version 2019 requiert l'utilisation d'EBICS 3.0.

Comme les professionnels bien informés le savent, la version ISO 2019 sera également introduite dans l'interface client-institution financière à partir de 2022 et les versions actuelles ne seront plus prises en charge à partir de 2024. Cela correspond à la tendance de la migration mondiale vers cette nouvelle version, par exemple dans les projets de migration SEPA, SWIFT MX ou TARGET2. Cette migration est importante, notamment pour l'introduction prévue des paiements instantanés en Suisse à partir de 2023.

La place financière suisse a donc choisi de lier la mise à niveau de la version EBICS à la mise à niveau de la version ISO. Dans ce contexte, les clients et les éditeurs de logiciels se posent quelques questions et font face à des défis qui ne doivent pas être sous-estimés. Les principaux points sont abordés dans les paragraphes suivants et, chaque fois que cela est possible, des solutions sont présentées.

EBICS 3.0 en Suisse au plus tard à partir de novembre 2021

La communication EBICS, désormais pleinement établie en Suisse, est une composante incontournable du secteur financier. Jusqu'à présent, la version 2.5 d'EBICS était proposée par la majorité des institutions financières suisses.

Comme mentionné précédemment, les « recommandations pour la mise en œuvre de la norme EBICS pour la place financière Suisse » (version 1.0 du 01/06/2020 de six, www.six-group.com) ont officiellement introduit la nouvelle version 3.0 EBICS en Suisse pour les activités des banques d'entreprise avec les institutions financières à partir de novembre 2021.

Définition de la Suisse pour le traitement des nouveaux opérations métier dans EBICS

Liée au lancement de la nouvelle version EBICS, la version précédente EBCIS 2.5 devrait être officiellement soutenue par les institutions financières jusqu’à la fin de l’année 2024. En outre, la réception des nouveaux formats suisses ISO 20022 dans la version 2019 requiert EBICS dans la version 3.0. Cela signifie pour les entreprises qui ont mis à jour leurs formats ISO suisses, qu’elles ne peuvent pas utiliser EBICS 2.5 sans adaptations supplémentaires.

Il est temps de planifier

Ces mises à jour exigent que les solutions logicielles soient planifiées et mises à jour en temps voulu. C’est alors au tour des institutions financières, des entreprises et des éditeurs de logiciels d’agir.

La mise à jour des formats de données ISO 20022 vers la version 2019 n'est qu’un aspect. En effet, il ne faut pas sous-estimer les modifications apportées au protocole EBICS qui doivent être mises en œuvre avec la version 3.0. Les plus importantes sont les suivantes :
  • Le nouveau Business Transaction Format (BTF) remplace les types d’ordre et les paramètres FileFormat précédents.
  • Le transport des clés publiques se fait désormais de manière uniforme avec des certificats.
  • Les procédures cryptographiques sont améliorées.
  • La gestion des clés bancaires est améliorée.
  • Il existe des paramètres de commande supplémentaires pour la signature électronique.
  • Une vérification de la double remise au niveau du fichier est disponible.
Comment gérer ces nouvelles exigences ?

Les institutions financières, mais également les éditeurs de logiciels des clients EBICS, doivent étendre leurs solutions logicielles à EBICS 3.0, afin de permettre aux entreprises d'effectuer des mises à jour et d’utiliser la solution à un stade précoce.

Toutes les spécificités d'EBICS 3.0 doivent être prises en compte dans le client et un fonctionnement parallèle des différentes versions EBICS pourrait être nécessaire selon l'accès bancaire et les utilisateurs EBICS. En outre, des options de migration d'EBICS devraient être proposées à l'utilisateur, en évitant autant que possible une réinitialisation (mot-clé : augmenter la longueur minimale des clés).

L'API EBICS – découpler la fonctionnalité métier du fonctionnement technique

Par notre propre expérience, nous savons chez PPI que la migration vers la version 3.0 n'est pas simplement un mapping des types d’ordres aux combinaisons BTF. Il y a beaucoup plus de problèmes à résoudre, et de tâches à reprogrammer. Cela s’applique en particulier si l’institution financière, le fabricant de logiciels et le client souhaitent effectuer cette migration de manière aussi automatisée que possible. PPI offre depuis des années TRAVIC-EBICS-Kernel, une solution API permettant une intégration dans les clients EBICS existants. C’est l’élément central pour gérer la communication EBICS en Europe avec presque la moitié des logiciels client EBICS.

Les nouvelles spécifications autour d'EBICS 3.0 sont déjà implémentées dans la nouvelle version. Correctement liée, l'API gère l'eBanking avec EBICS de manière transparente dans toutes ses versions et dans toutes ses formes pour le client. TRAVIC-EBICS-Kernel décharge ainsi l'éditeur de logiciels d'applications pour l’eBanking et pour le paiement lors de la mise en œuvre du protocole standard et de sa syntaxe, ainsi que des procédures de sécurité. Le progiciel correspond à la spécification EBICS et offre une interface facile à intégrer, permettant aux éditeurs de logiciels de l'intégrer dans les produits logiciels existants en tant que module de communication confortable et rapide à utiliser.

Considérant le rapport entre les coûts et les revenus lors de l'intégration de TRAVIC-EBICS-Kernel, il n'est pas surprenant que ce produit soit un tel best-seller. Les éditeurs de logiciels qui n'utilisent pas TRAVIC-EBICS-Kernel peuvent nous contacter à tout moment et demander une licence de test. C’est le moment idéal avant la prochaine migration vers EBICS 3.0.

Auteurs : Carsten Miehling et Michael Lembcke

Pour plus d’informations: Parlez-vous EBICS 3.0?

Configurer EBICS en un rien de temps

Celui qui veut utiliser EBICS doit s’assurer de ne pas faire d'erreur, et de ne rien oublier. Depuis les utilisateurs aux droits en passant par les comptes : les utilisateurs d’EBICS doivent considérer beaucoup d’aspects et configurer de nombreux paramètres. Pour son client EBICS (TRAVIC-Port), PPI a développé un assistant afin d’enregistrer les données requises plus rapidement et de manière centralisée.

Il est vrai qu’il faut cliquer à de nombreuses reprises si on veut créer un nouvel utilisateur EBICS. Cela est également le cas pour la gamme de produits PPI, à savoir TRAVIC-Port. En plus d’un identifiant, le système demande de chaque utilisateur les données de base, le mot de passe initial ainsi qu’un dispositif de sécurité utilisé pour les connexions futures. Chaque utilisateur assume par ailleurs plusieurs rôles, dispose d’autorisations différentes et possède souvent plus d’un compte bancaire. Du fait que TRAVIC-Port est un système multibanque, il est nécessaire de créer également les accès bancaires respectifs. Souvent, la banque principale prend en charge cette tâche pour ses clients entreprises EBICS – et cela signifie en règle générale de longs appels téléphoniques pendant lesquels l’employé de la banque demande toutes ces informations.

Les institutions financières qui commandent l’assistant de configuration trouvent une nouvelle entrée directement sur la page d’accueil (voir fig. 1), ce qui facilite grandement les choses. À l’aide de dialogues, un assistant demande toutes les données nécessaires pour créer un nouvel utilisateur EBICS.


L’assistant veille également à ce que les données soient toujours saisies aux bons endroits. C’est particulièrement pratique car le système configure l’agent de téléchargement, par exemple, via une autre rubrique que les accès bancaires et les utilisateurs. Si cela est logique, cela complique cependant la saisie rapide, cause des erreurs lors d’une nouvelle configuration et est donc fastidieuse. Les dialogues évitent les oublis de données importantes et permettent également de voir d’un coup d’œil les informations réellement nécessaires. Par exemple, la première action à faire est de configurer un nouvel accès bancaire – que ce soit fait par l’institution financière ou par l’administrateur du côté client n’a aucune importance. Le dialogue demande toutes les informations pertinentes et indique le travail qui reste à accomplir. Pour un accès bancaire, il s’agit de sept dialogues à traiter (voir fig. 2).


Une fois que tous les accès bancaires sont configurés, on passe aux utilisateurs. Un petit cabinet d’avocats, par exemple, souhaite configurer une autorisation de compte pour le propriétaire, deux avocats salariés et un assistant – avec des autorisations différentes pour chaque personne. La gérante souhaite bien sûr avoir tous les droits, pouvoir commander et valider les transactions sans limite et valider des transactions via une signature électronique disjointe pour ses collègues. En revanche, les deux avocats salariés sont autorisés à valider eux-mêmes des transactions jusqu’à un certain montant – et l’assistant peut saisir des paiements mais ne peut pas les valider. Tous les quatre doivent pouvoir consulter les relevés de compte qui sont téléchargés depuis le serveur bancaire EBICS. Tout cela est facilité par un dialogue qui permet de créer des nouveaux collègues pour un client entreprise déjà créé (voir fig. 3).


Vous voulez gagner du temps pour vous et pour vos clients lors de la mise en place d’EBICS ? N’hésitez pas à nous contacter. L’assistant de configuration peut être facilement commandé via un CR et est ensuite disponible dans TRAVIC-Port.


Auteur : Christian Veith









SWIFT gpi - de l’obligation à l’opportunité

La version SWIFT prévue pour novembre 2020 ne requiert pour une fois aucun changement de format pour les transactions financières. Ceux-ci ont été reportés à l’année prochaine, en raison de la pandémie mondiale de la maladie à coronavirus. Cependant, la demande d’une « confirmation universelle » dans le cadre de SWIFT gpi n’a pas changé. En termes simples, cela signifie que tous les participants à FIN doivent annoncer le crédit sur le compte du bénéficiaire au traqueur de SWIFT au format MT103. Les rejets doivent également être annoncés, en revanche cela ne dispense pas le retour. Le secteur bancaire doit encore une fois faire face à un cadre réglementaire contraignant, ce qui signifie moins de ressources pour les projets des clients. Mais faut-il que ce soit ainsi ? Pour répondre à cette question, voyons d’abord ce que signifie SWIFT gpi.

Depuis 2016, le thème SWIFT gpi (global payment innovation) gagne en importance. L’aspect le plus important est une référence unique UETR (unique end-to-end-reference), qui est ajoutée au paiement en début de chaîne de traitement de la banque du correspondant et conservée dans toutes les stations. Cela permet le suivi des paiements requis depuis longtemps dans l’AZV (paiements internationaux). Les informations sont collectées dans le traqueur. Le traqueur est une base de données centrale dans le nuage FIN chez SWIFT, qui lit automatiquement les informations nécessaires pour chaque paiement dans FIN et qui est complétée par d’autres messages des banques gpi.

Au début, l’UETR n’existait qu’au sein du CUG (closed user group) des institutions financières participant à l’initiative gpi et ce uniquement pour les paiements de clients (MT103). Le service standard est également appelé gCCT (gpi for Corporate Credit Transfer), rapidement complété par gCOV (gpi for Cover Payments). Après avoir traité uniquement les paiements de clients (MT103), toutes les institutions financières FIN sont désormais obligées, depuis 2018, de s’appuyer sur l’UETR pour les paiements de banque à banque (MT202/205) – c’est-à-dire pour tous les paiements. Les premiers effets positifs peuvent être remontés. Grâce à l’UETR il est désormais possible d’affirmer que « 40 % des paiements gpi sont définitifs dans les 5 minutes » ou que « 75 % des paiements gpi sont réalisés dans les 6 heures ». Avant, il n’y avait que des exemples des paiements qui arrivaient très tard (ou pas du tout) ou sans motif de paiement, mais avec des frais élevés (y compris OUR), ce qui a entraîné de nombreuses plaintes avec des demandes d’enquêtes associées. Un effet inattendu de l’introduction gpi a été la réduction considérable des demandes d’enquête.

Une institution financière gpi s’engage à un traitement le jour même si possible, à renoncer à la déduction des frais pour OUR, à transmettre le motif de paiement dans son intégralité et sans modifications (comme pour SEPA) – ce qui paraît être évident – et bien sûr à échanger des informations (si possible en temps réel) avec le traqueur non seulement sur le statut mais également sur les frais et les cours. Ces informations sont ensuite mises à la disposition de la banque du payeur agissant comme institution financière gpi. De cette manière, un autre problème de l’AZV – le manque de transparence des frais – peut être résolu. Ces avantages – et surtout ces informations – peuvent ensuite être communiqués au payeur.

Il y a aussi le thème des annulations. Si nécessaire, il devrait également être possible d’arrêter un paiement à tout moment de la chaîne du traitement bancaire. Mais de la même façon que le paiement se réalise tout au long de la chaîne, le message de rappel est également traité étape par étape par chacune des institutions financières concernées. C’est ici qu’intervient le service supplémentaire gpi gSRP (gpi Stop and Recall Payments). L’annulation est signalée au traqueur et la tentative suivante d’envoi du paiement avec l’UETR correspondant à FIN est rejetée. La longue chaîne est ignorée.

Aujourd’hui, avec la confirmation universelle, le processus est complètement transparent. De cette façon, l’institution financière du payeur reçoit non seulement l’information « paiement arrivé à la dernière institution financière de la chaîne FIN » mais aussi le statut « paiement arrivé au bénéficiaire ». Une telle confirmation faisait partie intégrante de la définition des paiements instantanés SEPA, mais c’était près de 50 ans après les premiers messages SWIFT.

Les institutions financières FIN sont désormais obligées d’envoyer une confirmation universelle. Cela ne s’applique qu’aux paiements de clients (MT103) et non à toutes les réceptions de paiements (M202/205). Les messages doivent également être envoyés pour les entrées TARGET2, car ils sont transportés via FINCopy. En bonus, l’accès web (manuel) à ce traqueur, qui n’était auparavant disponible que pour les institutions financières gpi.

L’institution financière a jusqu’à 2 jours ouvrables (certains jours fériés sont alors exclus) pour envoyer la confirmation universelle. Ce SLA sera mesuré et la bonne gestion des autres institutions financières reportée, mais cela ne devrait pas commencer avant la mi-2021. L’accès web au traqueur dépend également des bons comportements.

Les institutions financières traitant les plus petits volumes pourraient envisager l’utilisation d’un message manuel dans le traqueur. Pour les solutions automatisées, la plateforme de paiement devrait, par exemple, prendre en charge l’un des chemins offerts par SWIFT (MT199 ou API). En outre, il existe une solution dite CSV dans laquelle un certain rapport CSV dans l’interface SWIFT est utilisé pour générer les messages correspondants au traqueur.

Une institution financière qui ne fait pas partie de gpi doit alors répondre à presque toutes les exigences des institutions financières gpi. L’étape manquante n’est plus aussi grande mais le bénéfice pour vos propres clients peut être énorme. Grâce aux possibilités de gpi pour les paiements de banques à banques (MT202/205 – appelé gFIT, Financial Institution Transfer service, une option pour les institutions financières gpi), les départements internes de la banque tels que la trésorerie ou le marché monétaire peuvent également profiter de la sécurité que le « paiement est arrivé ».

Toutefois, il n’est pas aussi important pour l’institution financière de recevoir les messages de statut du traqueur pour les paiements envoyés, que d’offrir au client un service à forte valeur ajoutée – dans le meilleur des cas, la confirmation « paiement arrivé » (y compris l’information sur les frais et les cours de change). Les niveaux de service qu’une institution financière peut offrir s’étendent de l’option minimale de l’accès manuel au traqueur dans la hotline (propre à l’entreprise) jusqu’aux offres de libre-service dans le portail bancaire en ligne, en passant par l’information active par le message de statut envoyé à l’entreprise. Et cela n’est possible qu’en optant pour la confirmation universelle au service standard gpi et le gpi. C’est la nouvelle référence pour les institutions financières.

Une coopération interservices est alors nécessaire. Les services ne peuvent pas être fournis seuls par le département de paiement ou par le service informatique même, comme c’est souvent prévu pour les projets « réglementaires » dans le cas d’une nouvelle version SWIFT. Cela peut être réalisé grâce à une consultation qui inclut le processus entier.

En résumé, on peut donc constater qu’il n’y a qu’un pas entre les exigences règlementaires et les immenses opportunités, et que les perspectives de services supplémentaires pour les entreprises et les services internes des institutions financières sont énormes.



Auteur : Mario Reichel

ISO 20022 – plus actuel que jamais malgré le report


Les dés sont jetés : le 27 juillet 2020, la BCE a rejoint le vote de la communauté bancaire européenne et a accepté de reporter d'un an la date de mise en service de la consolidation de T2 et T2S à novembre 2022. De même, la date de la migration de Eurosystem Collateral Management System (ECMS) a été reportée de novembre 2022 à juin 2023, au plus tôt.

Dans le sondage réalisé en mai, les banques européennes avaient préconisé de reporter la migration. Outre les effets de la pandémie du Corona, la raison principale est le report de la migration ISO pour les paiements internationaux, déjà annoncé par SWIFT. Dans de nombreuses banques, les deux scénarios de migration convergent en un seul projet, car il n'est tout simplement pas possible de séparer les paiements via TARGET2 des paiements internationaux. Ce sont surtout les grandes banques ayant une activité de correspondance bancaire étendue qui ont vu de grands risques dans une divergence des dates de migration. Grâce à cette décision, les deux dates coïncident. EBA Clearing s'est également joint à la décision et a reporté sa migration en 2022.

Le soulagement du report était certes formidable - mais que signifie cette décision pour les institutions financières et pour leurs projets ? Que les institutions financières profitent de cette année supplémentaire pour se relâcher et ralentir la mise en œuvre de leurs projets serait la pire chose qui puisse arriver. De nombreuses institutions financières ont sous-estimé l'effort que le passage à TARGET2 exigera. Au contraire, le report offre l’opportunité de rattraper le temps perdu en œuvrant à plein régime. Faire marche arrière et reprendre le processus début 2021 n’est pas une option envisageable. Il faut également noter que la phase de démarrage des tests utilisateurs a été reportée de neuf mois seulement, de mars 2021 à décembre 2021. Déployer des ressources externes signifiera que les employés qui ont acquis les connaissances en travaillant précédemment sur les projets ne seront plus disponibles.

Il faut également prendre en compte que les spécifications qui ont déjà fait l'objet de deux adaptations cette année, continueront à l’être. La BCE doit toujours traiter les demandes de changement en attente non prévues pour la migration de novembre 2021. Cela va certainement changer avec le report. Il faut s'attendre à ce que les nouvelles UDFS publiées en novembre offrent des fonctionnalités supplémentaires qui devront être évaluées et implémentées.

L'image cible de SWIFT n'est pas non plus clairement définie. Jusqu'à présent, il est prévu qu'une plateforme pour la gestion des transactions soit développée pour servir de « hub » pour traiter les paiements internationaux. Il n'existe pas encore de spécifications publiées à ce sujet. En outre, de nouveaux types de messages ISO sont actuellement en cours de définition, par exemple pour les frais et les chèques, qui doivent également être pris en compte et mis en œuvre. La prochaine migration d'ISO est alors toujours changeante avec encore beaucoup d’incertitude à ce sujet. Ne devrait-on pas se demander si SWIFT décalera encore la migration à plus tard ? Quelle serait alors la réaction de la BCE ? Pourrait-on encore reporter TARGET2 ou serait-on alors obligé d’accepter une divergence des dates de migration ? Comment gérer les changements dans les formats de message déjà harmonisés, comme pacs.004 ?

Mais ce n'est pas tout, car la décision de la BCE concernant les paiements instantanés fait également sensation. Sur la base de discussions avec les participants du marché d'AMI-Pay, le Conseil de la BCE a décidé que tous les PSP qui ont souscrit à SCT Inst Scheme (c'est-à-dire paiements instantanés) et qui sont accessibles dans TARGET2, doivent être accessibles également dans TIPS. De plus, tous les ACH qui offrent des paiements instantanés doivent transférer les comptes techniques de TARGET2 à TIPS. La mise en œuvre est prévue pour la fin de l'année 2021. De cette manière, la BCE rend TIPS pratiquement obligatoire pour ceux qui participent déjà aujourd'hui aux paiements instantanés. C’est important car un grand nombre d'institutions financières utilisent désormais la procédure RT1 de l'EBA.

De plus, pour l’heure seule la décision a été prise et annoncée. D'autres données comme les détails techniques sont encore inconnues et seront publiées plus tard. Cela soulève la question du futur modèle tarifaire, en particulier si des frais sont facturés pour les transactions ACH cross. À quoi peuvent ressembler les frais de transaction et quel impact auront-ils sur la tarification des chambres de compensation ? Se pose également la question de l’existence d’un risque accru pour le règlement des positions telles que RT1, car avec TIPS un participant supplémentaire doit être intégré dans la chaîne.

Enfin, SEPA migre également vers la nouvelle version ISO 2019 en 2023 selon les plans actuellement annoncés de l'EPC. L'intervalle actuel d'un par rapport à la migration de TARGET2 et SWIFT peut sembler long, mais là aussi, il faut lire les spécifications, créer des concepts techniques et préparer les systèmes à l'avance. Malgré le report connu à 2023, cette migration ne doit pas non plus être sous-estimée, et nous recommandons d'aborder ce sujet le plus tôt possible.

Comme on peut le voir, les trois prochaines années apportera des différents sujets relatifs à ISO 20022 aux institutions financières et chacune devrait utiliser le temps gagné grâce au report pour redéfinir leurs priorités.

Cela nécessite un savoir-faire très spécifique et d’éviter les excès budgétaires à court terme des ressources qui seront à nouveau nécessaires de manière urgente en 2021.

Auteurs : Sabine Aigner, Thomas Ambühler

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