Dans la série «Comment améliorer EBICS», 1re partie – référence d’ordre client

Avec cette nouvelle série, je souhaite lancer une nouvelle rubrique invitant à réfléchir aux extensions d’EBICS envisageables et judicieuses. Ces propositions sont issues d’un cadre spécifique ou technique concret, dont découle la solution proposée. La première édition de cette série est consacrée à la référence d’ordre client.

Certains clients se sont souvent enquis de la possibilité d’associer une référence à un ordre, par exemple sous forme d’un nom de fichier ou d’un identifiant quelconque. Cette référence doit être sans équivoque. Le client serait ainsi en mesure d’obtenir l’état du traitement de l’ordre uniquement en indiquant la référence, que le traitement ait été terminé plusieurs jours auparavant ou qu’il soit encore en cours. Cette même référence permettrait en outre d’effectuer un contrôle pour éviter les doublons.

Il semble évident que l’ID d’ordre existant, formé de 4 caractères, n’est pas en mesure de répondre aux exigences précitées. Cet ID d’ordre est attribué par le serveur EBICS depuis la version 2.5, mais il se révèle équivoque.

Or, les exigences pourraient être satisfaites par l’introduction d’une référence d’ordre client (Customer Order Reference), qui viendrait compléter le standard EBICS. Concrètement, la mise en œuvre pourrait s’effectuer de la manière suivante:
  • Introduction d’une référence individuelle d’ordre client, par exemple de 512 caractères. Cette référence peut être librement attribuée par le client. Elle peut par exemple être constituée du nom du fichier, d’un identifiant quelconque ou d’une combinaison des deux. La référence d’ordre client doit être indiquée dans le compte-rendu (PTK/HAC).
  • Pour chaque client, l’unicité de la référence est vérifiée par le serveur EBICS de la banque, par exemple dans un délai de 90 jours. Lorsqu’un ordre est soumis avec une référence pour laquelle un envoi a déjà été effectué avec succès, l’ordre est refusé. En revanche, si un deuxième envoi portant la même référence d’ordre client intervient alors que le premier envoi est encore en cours, ce dernier est terminé avec erreur. Il est ainsi possible d’utiliser la référence d’ordre client même lorsqu’un transfert reste bloqué. Le refus est dans tous les cas indiqué dans le PTK/HAC.
  • Lorsque les comptes-rendus PTK/HAC du serveur EBICS de la banque sont par exemple complétés par le Clearing, ils devraient également comporter la référence d’ordre client correspondante, dans la mesure où cette dernière se réfère à une remise.
Les ordres suivants seraient envisageables au regard des requêtes :
  • Le client peut demander un PTK/HAC de manière ciblée pour une ou plusieurs références d’ordre client. Le PTK/HAC tel qu’il se présente à ce moment est alors transmis au client. L’état de restitution du PTK/HAC reste ici inchangé.
  • Toutes les références d’ordre client déjà remis peuvent être recherchées. La période peut alors être limitée de la même manière que pour l’historique de restitution. Il s’agirait d’une fonction de service pour les références d’ordre client.
L’introduction d’une référence d’ordre client, permettant la recherche ciblée de telles références ainsi qu’un contrôle des doublons, serait sans nul doute un outil puissant. Le client pourrait rechercher des ordres individuels et serait en mesure d’instituer un système de contrôle des doublons efficace. La banque quant à elle pourrait étendre les possibilités de recherche mises à la disposition de ses clients, et ainsi réduire le nombre de sollicitations auprès de ses services. Le contrôle de doublons pourrait même être délégué au client. L’introduction d’une telle référence serait donc une situation gagnant-gagnant pour les banques et les clients. Que demander de plus?

Michael Lembcke

Problèmes de démarrage pour les clients suisses d’EBICS

Dans nos précédents articles, nous nous étions déjà fait l’écho du lancement d’EBICS en Suisse. Certaines institutions bancaires proposent d’ores et déjà ce standard multibanque, alors que d’autres en sont encore à la phase de planification. L’accent ne se porte donc que lentement sur les entreprises qui souhaitent exploiter ces nouvelles interfaces – et donc sur les logiciels clients EBICS à mettre en œuvre.

Les résultats de la première enquête réalisée début 2014 auprès des développeurs de logiciels suisses sur le support d’EBICS dans leurs produits clients respectifs ont été très positifs. La plupart d’entre eux ont déjà implémenté le protocole EBICS et peuvent mettre en production des échanges avec les deux grandes banques. Pour simplifier l’activation de nouvelles interfaces, certaines solutions logicielles prévoient l’installation des profils EBICS spécifiques à chaque institution bancaire. Avant de commencer l’installation, le client choisit la banque avec laquelle il souhaite établir une liaison et le programme définit automatiquement les principaux paramètres de connexion et de configuration en fonction de ce choix (version,  nom de l’hôte, émetteur du certificat, types d’ordres supportés, URL, etc.).

Lorsque le client souhaite se connecter à une banque supplémentaire (qui vient d’ajouter EBICS à son offre par exemple), il a souvent besoin d’une nouvelle version logicielle contenant la configuration spécifique à celle-ci. Dès lors le paramétrage initialement si convivial se complexifie, car qui souhaite mettre à jour l’ensemble du logiciel uniquement dans le but d’ajouter une nouvelle liaison bancaire ? Une configuration qui permettrait aux clients d’introduire eux-mêmes les seuls paramètres EBICS nécessaires pour la nouvelle liaison semble à ce stade bien plus judicieuse.

Si  les développeurs facturent en plus des frais de mise à jour, l’on ne peut s’empêcher de penser qu’un problème trivial en soi devient un prétexte pour faire du profit sur le dos des clients. De fait, il appartient aux banques de recenser les solutions existantes et d’en informer les clients lorsqu’ils s’interrogent sur le meilleur logiciel EBICS à mettre en œuvre pour les échanges avec leurs banques.
Pour terminer, un dernier conseil aux développeurs suisses n’ayant pas encore implémenté le protocole EBICS: la configuration d’une nouvelle liaison EBICS ne doit pas devenir un acte de sorcellerie. Pour cela, il suffit de permettre au client de la paramétrer lui-même, par exemple via une boîte de dialogue. Et à ce sujet, je profite de l’occasion pour rappeler l’existence du module EBICS-Kernel développé par PPI (cf. modules logiciels sur le site de PPI), qui met à disposition l’ensemble des fonctionnalités d’EBICS sous forme de bibliothèque logicielle.

Carsten Miehling

SEPA Card Clearing – quel rapport avec EBICS ?

Outre les les virements (Credit Transfer) et prélèvements (Direct Debit), l’harmonisation des échanges de paiements au sein de la zone SEPA (Single Euro Payment Area) touche également, dans une certaine mesure, les paiements par carte. L'article qui suit explique ce que cela a à voir avec EBICS.

Jusqu’à présent, les paiements par carte étaient échangés dans leurs formats nationaux respectifs. Dans les points de vente, on distingue généralement deux grands types:

1. les prélèvements ELV* autorisés par une signature manuelle du client
2. les prélèvements autorisés par saisie du code PIN sur le lecteur de cartes

Les prélèvements ELV sont traités en tant que Direct Debits SEPA classiques. Les prélèvements autorisés par saisie du code PIN ne sont en revanche pas controlés automatiquement par SEPA. Dans ce cas, il semble donc judicieux de remplacer les formats nationaux par des formats ISO20022. Ces formats ISO sont spécifiés dans le SEPA Card Clearing ou SCC. Le SCC se subdivise de la manière suivante:
  • transactions entre les entreprises et les banques
  • échanges de paiements interbancaires
Des exigences particulières s’appliquent aux processus afférents à ces deux domaines, aux mécanismes de compensation et de règlement, ainsi qu’aux formats des données à échanger. L’EPC (European Payment Council) a édicté des règles concernant le SEPA Card Clearing. Le Berlin Group (www.berlin-group.org), groupement européen initié par les principaux systèmes nationaux de paiement par carte, a quant à lui spécifié en détail des directives uniformisées basées sur la norme ISO20022. Ces spécifications, existant actuellement dans leur version 2.0, répondent aux exigences énoncées au SEPA Card Clearing par l’EPC.

Le Berlin Group compte des représentants issus de différents états: Allemagne, Belgique, Bulgarie, Croatie, Danemark, Espagne, Estonie, Finlande, France, Grande-Bretagne, Grèce, Hongrie, Irlande, Islande, Italie, Lettonie, Lituanie, Luxembourg, Norvège, Pays-Bas, Portugal, Serbie, Suède et Turquie. Les spécifications SCC du Berlin Group sont donc une initiative paneuropéenne. Pour l’heure, l’implémentation du SCC est toujours en cours. En Allemagne, la DK (Deutsche Kreditwirtschaft) a décidé de remplacer les anciens formats par les formats et processus du SCC du Berlin Group pour la compensation des transactions par cartes qui ne reposent pas sur ELV. Ce passage des anciens formats à SCC concerne les entreprises, les émetteurs de cartes de crédit et tous ceux qui les acceptent, les prestataires techniques (par exemple les exploitants de réseaux), ainsi que les institutions bancaires et les intermédiaires dans les échanges de paiements. Avant la modification, il conviendrait de contrôler la capacité des systèmes informatiques et, le cas échéant, de la revoir à la hausse, le SCC – tout comme SEPA – impliquant sans doute des volumes de données plus importants.

Alors, quel rapport avec EBICS? La DK a également décidé d’utiliser SCC avec EBICS. Le 23 avril 2014, l’annexe 2 des spécifications EBICS s’est vue étendue aux opérations relatives au SCC. Cette extension EBICS concerne les échanges interbancaires ainsi que les opérations entre les entreprises et les banques. De nouvelles opérations pour l’échange de données ont fait leur entrée dans les spécifications EBICS sous la forme de nouveaux types d’ordres et formats. Ainsi des types d’ordre et des formats interbancaires ont par exemple été rajoutés pour les échanges via EBICS avec la Deutsche Bank pour ce qui affère au nouveau service SEPA-Clearer SCC. La Deutsche Bundesbank prévoit également d’abandonner l’ancien format DTA. De la même manière, des extensions EBICS pour le SCC Européen ont été intégrées aux échanges de paiements interbancaires. Avec ces opérations le clearing EBA propose le STEP2 Card Clearing via EBICS dans toute l’Europe pour les échanges de paiements entre institutions financières. Les tests relatifs au SCC sont en cours et les tests de réception avec les organes de clearing EBA et la Deutsche Bundesbank doivent être terminés au printemps 2015. Le passage complet de DTA à SEPA, et donc au SCC, doit être achevé en 2016. L’intérêt des banques des autres pays européens pour ces changements reste à déterminer, cependant la constitution du Berlin Group semble être de bon augure.

* «Elektronisches Lastschriftverfahren» (système de prélèvement électronique)

Michael Lembcke

La Banque cantonale de Zurich mise sur EBICS

Dans le domaine des paiements électroniques, la Banque cantonale de Zurich a opté pour une solution multibanque particulièrement sûre. À l’avenir, la plus grande banque cantonale du pays proposera à ses clients le standard de communication bancaire basé sur Internet EBICS, adopté par les établissements bancaires suisses en tant que standard multibanque. Dans le cadre d’un appel d’offres, le système bancaire électronique TRAVIC-Corporate de la société PPI AG est parvenu à s’imposer face à de nombreux concurrents.

Après la décision des établissements de crédit helvétiques d’adopter un standard particulièrement sûr sous la forme de l’«Electronic Banking Internet Communication Standard (EBICS)», la Suisse adhère à la société européenne EBICS afin de contribuer à son essor en collaboration avec la France et l’Allemagne. EBICS est en passe de s’imposer sur d’autres places financières européennes en tant que standard pour l’échange de paiements électroniques avec les entreprises.

Ces dernières utilisent le protocole EBICS pour traiter les paiements électroniques en tant que partie intégrante de leurs propres systèmes de paiements. Les transactions typiques sont ici l’émission d’ordres de paiement ainsi que la génération d’extraits de compte, de rapports d’état et d’avis de paiement. La validation s’effectue à l’aide de signatures électroniques. Alliant grande disponibilité et faibles coûts, le standard EBICS permet de traiter, rapidement et en toute sécurité, de très gros volumes de données.

Avantage pour les entreprises: un nombre croissant de banques à travers l’Europe propose le standard EBICS, qui avec le format de paiement européen SEPA s’impose de plus en plus en tant que protocole de communication.

La Banque cantonale de Lucerne avait opté pour TRAVIC-Corporate de PPI dès le début d’année 2014 et d’autres grandes banques helvétiques s’intéressent vivement au système proposé par le leader des solutions EBICS. La Banque cantonale de Zurich met en œuvre le nouveau protocole de communication de PPI AG, qui repose sur TRAVIC-Corporate. «Nous travaillons en étroite collaboration avec la banque et garantissons ainsi une intégration sur mesure dans les systèmes bancaires existants», explique Michael Lembcke, responsable produit chez PPI et chargé du projet d’intégration de la Banque cantonale de Zurich et de RECON.

«La Banque cantonale de Zurich entend intégrer le système directement au niveau de l’administration centrale des utilisateurs, ce qui réduit les tâches administratives et accroît la sécurité de l’ensemble du système», ajoute Carsten Miehling, directeur de RECON, partenaire de distribution de PPI AG en Suisse.

Michael Lembcke

Types d’ordres et paramètres de format – les différentes variantes d’EBICS

En dépit de l’existence d’une seule et unique spécification, EBICS est mis en œuvre de manières différentes en Europe pour la présentation d’ordres de paiement et leur authentification par les banques. En Allemagne, l’on utilise par exemple exclusivement les types d’ordres, alors qu’en France l’on emploie les paramètres de format de fichier. Mais le client doit-il vraiment connaître ces différences? Comme je l’annonçais dans mon dernier article, voici quelques informations supplémentaires.


Par le biais du type d’ordre EBICS, le client indique la nature de la transaction qu’il souhaite transmettre au serveur bancaire. Si le type d’ordre est connu du serveur et que la personne à l’origine de la demande dispose des autorisations requises, le traitement est exécuté en appliquant le format spécifique à ce type d’ordre.

S’agissant des trigrammes des types d’ordres, EBICS fait systématiquement la différence entre l’initialisation d’un envoi de fichier et celle d’une récupération de fichier. Le standard établit en outre une distinction entre types d’ordres de production et d’administration. Les types d’ordres d’administration sont ceux permettant de piloter le protocole EBICS en soi, comme HIA et INI pour l’échange de clés ou encore HVU pour l’obtention de la signature électronique distribuée (ou VEU). Les types d’ordres de production quant à eux décrivent le contenu d’un transfert de fichier, comme CCT pour les paiements au format SEPA Credit Transfer. Les types d’ordres de production déterminent donc le format de traitement spécifique à appliquer.

EBICS établit une liste des types d’ordres de production à utiliser, ainsi que des transactions et des formats concernés. Ces types d’ordres de production sont pour l’heure principalement mis en œuvre en Allemagne.

En France et indépendamment du contenu du fichier, l’on utilise pour chaque ordre de production un type d’ordre déterminé pour les envois (FUL) et les récupérations (FDL). Pour fournir au serveur bancaire les données requises concernant le format, le type d’ordre reçoit côté client un paramètre de format de fichier (FileFormat) pouvant comprendre jusqu’à 40 caractères. La structure de ce paramètre est également spécifiée par EBICS.

Qu’en est-il de la compréhension mutuelle entre serveur bancaire et logiciel client?

Tant la variante allemande que celle utilisée en France en matière de types d’ordres permettent d’instaurer des contrôles d’authentification spécifiques à chaque format côté banque. Les paramètres de format de fichier rendent ici possible une convention plus détaillée entre le client et la banque sur le type de contenus à échanger (par exemple la version SEPA, les spécificités propres au pays). Ceci dit, les types d’ordres peuvent se révéler plus faciles à mettre en œuvre pour le client, car il n’a alors pas besoin de se poser de question sur les détails de format dans EBICS. Seul impératif : les serveurs bancaires EBICS et les logiciels client doivent se comprendre. Pour ce faire, le client doit absolument connaître le langage parlé par le serveur bancaire en face de lui.

Les deux modes d’échange de données de production entre logiciel client EBICS et serveur bancaire EBICS ont leurs avantages et leurs inconvénients. En définitive, la décision revient à l’entreprise cliente qui détient peut-être des comptes auprès de différentes institutions bancaires dans divers pays. Ce client exigera alors sans doute un standard unique. Le succès d’EBICS dépendra par conséquent également de l’homogénéité de son utilisation, ou de l’interopérabilité de ses différentes variantes. Une tâche pour les spécificateurs. Comme indiqué dans l’article de Carsten Miehling du 9.9.2014, le processus est déjà en marche.

Michael Lembcke

Renouvellement des certificats EBICS serveurs

Écrit par Christophe Garnier – Directeur technique PPI FRANCE

La très grande majorité des serveurs EBICS, pour la version française de ce protocole, ont été mis en production fin 2009 et courant 2010. Bon nombre d’entre eux utilisent des certificats X.509 auto-signés d’une durée de vie de 5 ans, un certain nombre d’établissements ont donc déjà procédé à leur renouvellement et d’autres s’y préparent.


Si pour le renouvellement des certificats côté clients le protocole prévoit des messages dédiés (messages PUB, HCA et HCS) et une cinématique supprimant les interventions manuelles (messages signés ne nécessitant pas de validation complémentaire), il n’en est pas de même en ce qui concerne le renouvellement côté serveur. Le seul message HPB est disponible et la validation des certificats reçus inclut une étape manuelle : le rapprochement avec leur empreinte numérique. Une autre différence notable est la portée de l’opération qui peut concerner plusieurs milliers d’accès clients simultanément.

Il apparait donc évident qu’un minimum d’organisation et de précautions sont nécessaires pour faciliter cette intervention.

Fort de notre savoir-faire dans le développement et la mise en œuvre de logiciels EBICS tant du côté client que du côté serveur, nous avons pu tirer des enseignements des premières expériences de renouvellements de ces certificats, et nous nous permettons donc de faire les recommandations suivantes aux personnes en charge de l’administration des serveurs EBICS:

- S’enquérir auprès de son fournisseur du mode opératoire de génération et de mise à jour des certificats.

- Bien choisir la date et l’heure en évitant les périodes habituelles de stress (fin de mois, cut-off, …) ou de faible disponibilité des intervenants côté clients (fin de soirée, nuit, week-end, congés scolaires, …).  Eu égard aux dates de fin de validité des certificats, il est bien sûr possible d’anticiper leur renouvellement, ce qui offre un peu plus de latitude.

- Informer les clients, avec un délai significatif, de la date et de l’heure retenues pour la mise en place des nouveaux certificats. Il nous semble judicieux de prévoir l’envoi d’un courrier de rappel quelques jours auparavant. Voici quelques éléments que nous pensons utiles d’intégrer dans cette communication:
  • Inciter le client à prendre contact avec son fournisseur pour s’assurer que son logiciel supporte le renouvellement des certificats EBICS du serveur et en obtenir le mode opératoire s’il n’est pas déjà en sa possession. A noter que nous avons identifié deux logiciels clients distincts ne permettant pas de réaliser cette opération. Dans les deux cas, les clients ont été dans l’obligation de recréer complètement leurs accès.
  • Inviter le client à transmettre le courrier à d’éventuels prestataires auxquels il aurait délégué un accès de télétransmission. Le point précédent s’appliquant aussi à eux.
  • L’empreinte numérique (pour une meilleure compréhension nous conseillons d’ailleurs de mentionner également les autres dénominations couramment employées: condensat et hash) de chaque nouveau certificat doit bien sûr être indiquée dans le courrier pour en permettre la validation par rapprochement. La présentation habituelle sous forme d’une matrice de 4 lignes de 8 octets peut être complétée par une présentation linéaire (les 32 octets sur une même ligne sans caractère séparateur) afin d’en faciliter le copier-coller dans le logiciel du client.
  • Indiquer au client que s’il omet de mettre à jour à temps son paramétrage, le premier transfert échouera avec un code d’erreur réservé de valeur 091008 et de libellé EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Il devra alors récupérer les nouveaux certificats avant de relancer le ou les transferts en échec.
  • Un dernier point peut aussi mentionner les empreintes numériques des certificats en cours pour permettre aux clients qui le souhaiteraient de se familiariser avec les actions à réaliser dans leur logiciel en faisant une simulation sur la base de ces certificats. Cela permettrait au client de détecter à l’avance un éventuel dysfonctionnement de la procédure de renouvellement dans son logiciel, et dans ce cas de solliciter son fournisseur sur le champ, dans un contexte moins stressant.
La gestion du renouvellement des certificats EBICS serveurs est l’un des derniers éléments du protocole manquant de fluidité. Gageons que comme pour l’OrderID, la société EBICS saura y remédier d’ici les 5 prochaines années en faisant évoluer le standard.

Marc Dutech

Sécurité renforcée, coûts réduits : Clearing STEP2 avec EBICS

Depuis la fin de l’année dernière, ABE Clearing propose EBICS en plus de SWIFT comme canal d’accès pour STEP2. C’est le SEPA Clearer de la Deutsche Bundesbank, accessible depuis 2008 par le biais de SWIFT et EBICS, qui a ici servi de modèle. Quels sont les motifs ayant incité ABE Clearing à ajouter un accès EBICS à celui existant via SWIFT? L’impulsion émane de certaines banques et caisses d’épargne allemandes, dont les motivations sont à chercher sur le front des coûts : le transport via EBICS n’occasionne en effet aucun frais de transaction.


Le clearing bilatéral entre les banques – également désigné «garage clearing» en Allemagne, où il a été très utilisé – ne génère donc aucuns frais pour le transport et le clearing, car ce sont les banques concernées qui les prennent à leur charge. Or, la mise en œuvre d’un clearing centralisé implique bien entendu des coûts. Afin d’éviter leur envolée, il semble par conséquent judicieux de limiter au maximum les frais de transport dont doivent s’acquitter les établissements bancaires. EBICS a donc été un choix tout naturel, puisque ce standard ne génère pas de frais de transaction pour le transport, mis à part les coûts d’exploitation.

Un second aspect revêt en outre une importance croissante : la sécurité. Les volumes monétaires échangés quotidiennement lors des paiements interbancaires se chiffrent en milliards. Une perturbation de quelques heures de ces flux peut entraîner des dommages aux répercussions considérables pour l’économie. C’est pourquoi les voix en faveur d’un système de secours pour le clearing interbancaire se multiplient. Ici encore, EBICS est parfaitement en mesure de relever le défi, par exemple en tant que solution de secours pour SWIFT. D’ailleurs, certaines banques utilisent d’ores et déjà EBICS et SWIFT en parallèle pour le clearing. À long terme, il semble en outre peu probable que les autorités de régulation continuent à se contenter d’un seul procédé de transport. Les exigences en matière de sécurité ont été considérablement renforcées dans presque tous les domaines bancaires, par exemple avec l’entrée en vigueur de la directive sur les services de paiement (DSP2). Un durcissement des standards de sécurité en matière de paiements interbancaires n’est donc pas à exclure à l’avenir.

Michael Lembcke

Réunion du groupe de travail EBICS: La Suisse donne un nouvel élan à EBICS

Le groupe de travail EBICS suisse entend présenter ses idées – concernant notamment les types d’ordres – au mois de septembre. Tel est le principal résultat de la réunion du groupe de travail EBICS s’étant tenue le 28 août dernier. En vue de la candidature de notre pays à l’adhésion à la société EBICS, la réunion s’est tenue en Suisse pour la première fois depuis le lancement de la coopération franco-allemande autour d’EBICS. À deux pas des locaux du porte-drapeau helvétique pour cette adhésion, SIX Interbank Clearing, les experts des trois pays se sont réunis à l’hôtel Renaissance de Zurich pour débattre de la situation actuelle en Suisse et des évolutions prévues du nouveau standard électronique d’échanges des paiements.


Les discussions ont été animées dès les premières minutes. La Suisse doit encore en effet choisir laquelle des deux solutions, entre le modèle de types d’ordres allemand et la variante française basée sur des fichiers de paramètres (FUL/FDL), elle souhaite mettre en œuvre à l’échelle nationale. Albert Apolloner, responsable du groupe de travail EBICS helvétique, a présenté les avantages et les inconvénients des deux alternatives du point de vue de la Suisse. En conclusion, il a privilégié la variante des fichiers de paramètres, qui couvre d’ores et déjà les exigences fondamentales du marché financier suisse tout en se révélant plus flexible. Les représentants allemands ont indiqué que leur variante permet d’attribuer chaque type de transaction à un «issuer» déterminé, par exemple à la Suisse ou à une grande banque.

L’idée de transposer tous les types de transactions allemands en appliquant la logique des fichiers de paramètres a finalement émergé des débats. Les fournisseurs de logiciels clients n’auraient alors qu’à implémenter cette logique dans leurs modules clients, ce qui, en prévision de l’extension à de nouveaux marchés comme la Suisse, l’Espagne, le Portugal et à d’autres candidats, serait un avantage certain. Afin de minimiser les coûts pour les institutions allemandes, où les trigrammes des types d’ordres sont actuellement transmis jusqu’à des étapes avancées des traitements, la possibilité a été évoquée d’un mapping au niveau des serveurs bancaires. Par exemple, le type de transaction AZV deviendrait ainsi pain.xxx.azv. En combinaison avec le code pays et la «Name-/Value-Pair», il serait alors possible de répondre aux exigences de chaque pays et même d’ajouter les caractéristiques de grands acteurs du marché (comme la mention «Il s’agit d’un fichier conforme aux modalités du Crédit Suisse»).

La réaction de la délégation allemande n’a certes pas été des plus enthousiastes, cependant ses représentants ont déclaré que ce genre de migration ne serait pas totalement inconcevable dans le cadre d’une future harmonisation du standard EBICS. Les deux procédés pourraient d’ailleurs continuer à exister en parallèle pendant une phase de transition. Les nouveaux marchés opteraient alors directement et de manière avantageuse pour la variante plus universelle FUL/FDL.

La deuxième partie de la réunion était consacrée à la sécurité, domaine dans lequel la France et l’Allemagne empruntent également des voies différentes. Alain Hiltgen (UBS) a proposé de faire figurer une mention dans le Guide d’implémentation EBICS, qui recommanderait d’utiliser des tokens matériels pour le stockage des clés et des certificats.

Après le déjeuner, Sabine Wenzel (SIZ) a présenté la société EBICS aux participants suisses, ainsi que son organisation et les processus décisionnels qui président aux futures extensions. Selon le planning actuel, il serait encore possible d’introduire des demandes de modifications pour la version 2.6 (entrée en vigueur prévue en 2016) jusqu’en novembre 2014. Le groupe de travail Suisse souhaite se réunir à nouveau en septembre afin de formuler ses idées, notamment sur les types d’ordres. Dans l’idéal, celles-ci pourraient ensuite être discutées à l’occasion de la prochaine réunion du groupe de travail international EBICS qui se tiendra à Paris au mois de novembre.

Bilan : un forum très intéressant pour tous les passionnés d’EBICS. L’impression qui s’en dégage est que l’arrivée d’un nouvel acteur dans l’équipe pourrait très bien insuffler une nouvelle dynamique à l’évolution d’EBICS. À suivre donc.

Carsten Miehling

Le bircher muesli des clés

Ainsi que nous l’évoquions déjà dans notre article du 25.07.2014 intitulé «EBICS enfin en Suisse», la place financière suisse rejoint lentement mais sûrement la communauté EBICS formée par nos deux grands voisins que sont l’Allemagne et la France. Comme nous le savons, les Français ont une approche un peu différente des Allemands en la matière et les acteurs suisses s’interrogent sur la variante à adopter. Concernant les types d’ordres (Order Type), la préférence va actuellement au modèle français, c’est-à-dire FUL/FDL et Fileformat, au lieu de  la panoplie d’Order Type utilisés  en Allemagne. Les choses se compliquent lorsqu’il est question de la mise en œuvre des signatures électroniques : comment l’implémenter concrètement pour les clients?

La variante allemande s’articulant autour de paires de clés auto-générées pour le cryptage (E002), l’authentification (X002) et la signature (A005/A006) est celle actuellement en vigueur en Suisse, tandis que le concept de signature électronique distribuée (ou VEU pour «Verteilte Elektronische Unterschrift») appliqué en Allemagne n’en est qu’à sa phase de planification. La VEU permet l’utilisation de plusieurs signatures personnelles pouvant être générées et présentées lors de la transmission de l’ordre, mais aussi après celle-ci. Pour l’heure, les grandes banques suisses n’utilisent toutefois que les simples signatures et de transport. La simple signature est habituellement un «corporate seal», donc un «sceau» identifiant une entreprise, et non la personne ayant effectivement validé l’ordre. L’administration et l’utilisation de ces «sceaux» sont gérées par le logiciel du client. Pour la signature de transport, la validation est effectuée sur un canal séparé par le biais d’un accès via la banque en ligne – et non manuellement à l’aide d’un document de confirmation, comme c’est encore souvent le cas en France.

Or, la première méthode est de plus en plus critiquée par les services juridiques et de sécurité des institutions financières suisses, qui exigent une authentification sans équivoque de la personne qui a signé l’ordre. La VEU pourrait sans nul doute répondre à cette exigence, même si les banques appréhendent encore les processus supplémentaires qu’il leur faudrait mettre en place pour l’administration des règles de signature.

L’EBICS TS («Transport and Signature») en vigueur en France, employant des certificats délivrés par une autorité de certification (AC) reconnue par les banques pour la signature personnelle, est considéré comme une alternative intéressante, le problème de la validité des clés et la gestion de la révocation des certificats  via les AC semblant réduire les risques de sécurité. Ceci étant  complété par un token matériel utilisable uniquement par la personne émettant l’ordre. «Tant qu’à le faire, autant le faire bien», serions-nous alors tentés de dire. Pourquoi ne pas appliquer un standard offrant de telles fonctionnalités? En outre, le régulateur semble envisager des dispositions qui interdiraient aux institutions financières de ne pas assumer les risques liés à l’utilisation des «corporate seals» grâce à l’ajout dans les contrats d’une clause de non-responsabilité (à ce sujet, voir également le document publié par la BCE «Assessment Guide for the Security of Internet Payments»).

Une recette unique serait souhaitable

La difficulté réside dans la diversité des variantes d’EBICS existantes, et dans le choix de celle à mettre en œuvre sur le marché pour répondre aux besoins des premiers concernés, à savoir les clients, les développeurs de logiciels et les banques. Faut-il instaurer des certificats délivrés par des AC,  et si oui, pour quels types de clés? Quelles sont les AC reconnues par l’ensemble des banques? Quelles caractéristiques un tel certificat doit-il présenter? L’emploi de tokens matériels se limiterait-il à la signature (A005/A006) ou  également à l’authentification et au cryptage? Les tokens matériels pourraient-ils être mis en œuvre sans AC, seule la clé étant conservée en externe auprès du donneur d’ordre signataire?

Tout cela fait un peu penser à notre bircher muesli et à ses multiples variantes et recettes. L’objectif de la société EBICS est d’établir le standard dans toute l’Europe. Dans ce cadre, une recette unique pour la préparation de ce «bircher muesli des clés» serait de toute évidence un atout – y compris pour les utilisateurs. À défaut, instaurer un standard transnational se révèlera sans doute difficile. Selon moi, cette problématique devrait occuper une place de choix dans l’agenda du groupe de travail EBICS.

Carsten Miehling

Le Portugal à l’heure d’EBICS

Comme l’ont fait les banques françaises à partir de 2009 et les banques allemandes en 2008, de nombreuses banques portugaises ont décidé d’utiliser le protocole EBICS dans le cadre de leurs échanges de flux financiers avec les entreprises.

Deux raisons principales ont motivé ce changement:

1. L’arrêt du réseau X25 planifié par Portugal Telecom pour le 30 juin 2014,
2. L’incapacité de certains protocoles utilisés jusqu’à présent de transférer des fichiers constitués d’enregistrements de taille variable, comme c’est le cas pour les formats SEPA.

Les banques portugaises  devaient donc proposer à leurs entreprises clientes un canal d’échange de substitution accessible, sécurisé, peu coûteux et transfrontalier.


Informées des retours d’expérience positifs sur la migration et l’utilisation au quotidien du protocole EBICS en Allemagne et en France, ces banques portugaises ont décidé d’ajouter le canal EBICS à leur offre de services. Certaines d’entre-elles ont d’ailleurs retenu pour cela le logiciel TRAVIC-Corporate, serveur bancaire édité par PPI.

La version retenue est la version 2.4, identique à celle en vigueur en France à l’heure actuelle. A ce jour seul le profil T est opérationnel.

Les types de flux échangés via le canal EBICS sont divers et variés: paiements domestiques au format PS2, ordres de virement Swift MT101, virements et prélèvements SEPA SCT et SDD, relevés de compte, confirming, taux et cotation des devises, formats propriétaires pour les lettres chèques et le factoring…

De plus, voilà quelques mois déjà que quelques éditeurs implantés au Portugal proposaient des logiciels entreprise supportant le protocole EBICS. C’est notamment le cas de METACASE, le partenaire Portugais de PPI, qui a implémenté la gestion du protocole EBICS dans Target One, la plateforme de gestion dont METACASE est l’éditeur. Cette implémentation du protocole EBICS avant même que des banques portugaises n’ouvrent leur canal se justifiait par la demande de certaines entreprises portugaises de pouvoir échanger des flux financiers avec des banques allemandes et/ou françaises.

Le choix opéré par une majorité de banques portugaises démontre donc que le protocole EBICS a vocation à devenir un protocole largement déployé en Europe, contribuant ainsi à des échanges entreprise-banque sécurisés, facilités et peu coûteux au sein de la zone SEPA.

Marc Dutech

L’harmonisation du trafic des paiements par SEPA n’est toujours pas pour aujourd’hui

SEPA a été introduit en Europe pour harmoniser le trafic des paiements. Pourtant, il n’est toujours pas possible d’effectuer simplement des paiements électroniques SEPA vers toutes les banques européennes. En Allemagne, les entreprises utilisent le type d’ordre CCT pour la présentation d’un virement SEPA («SEPA Credit Transfer») auprès des instituts bancaires. Pourquoi est-il impossible de traiter simplement les virements SEPA en provenance des autres pays de la zone euro avec ce même type d’ordre ?

Les formats de données SEPA basés sur XML ont désormais été introduits dans tous les pays européens participants. L’objectif était et est toujours – après l’introduction de la monnaie unique – d’uniformiser les formats de données et les dispositions réglementaires pour les échanges des paiements et ainsi de simplifier ces mêmes échanges électroniques à l’échelle européenne.
Sur la base des formats XML ISO20022 et des recommandations de l’European Payments Council (EPC), la transposition dans les différents pays européens a cependant été définie en tenant compte des spécificités nationales en matière d’échanges des paiements. Résultat : il existe aujourd’hui dans les différents pays des formats SEPA spécifiques pour un même type d’opération.

Les divergences commencent d’ailleurs dès l’identification des formats. Si l’Allemagne a par exemple introduit sa propre variante de format de données pour les virements SEPA sous la dénomination pain.001.002.03, d’autres pays utilisent le format pain.001.001.03 préconisé par l’EPC. Les différences nationales se reflètent également au niveau des espaces de nom XML. En outre, des règles de référencement distinctes s’appliquent d’un pays à l’autre.

En Allemagne, les paiements SEPA via EBICS sont identifiés et transmis à l’aide de types d’ordre comportant trois caractères (par exemple «CCT» pour un virement SEPA). Selon les spécifications, le format associé à un type d’ordre donné est alors celui prévu par la «Deutsche Kreditwirtschaft» (DK). Mais que se passe-t-il lorsqu’un client étranger transmet un virement SEPA dans son format national à une banque allemande ? En pareil cas, ni le type d’ordre, ni l’espace de nom XML ne fournissent des informations fiables quant aux spécificités du format utilisé. Or, la banque doit être en mesure d’appréhender ces spécificités si elle souhaite traiter le trafic des paiements transfrontalier. Alors, comment faire en sorte que les banques puissent identifier les variantes de format et les traiter de manière adéquate ?

Solution possible : identifiant de l’émetteur pour EBICS (IssuerID)

Tant qu’une harmonisation complète des formats SEPA échangés entre les entreprises et les instituts bancaires n’intervient pas au niveau européen, il est indispensable de trouver une autre solution. Différentes approches sont ici envisageables. La première mettrait à contribution les développeurs de logiciels, en créant des parsers intelligents ou des extensions spécifiques des données de base pour les systèmes informatiques des banques. Une autre approche, sans doute plus pertinente à long terme, serait d’exploiter les avantages offerts par le standard EBICS.

En France, le problème a d’ores et déjà été résolu, en utilisant les paramètres de format et le code pays transmis via EBICS. Grâce à ce code pays, le serveur EBICS de la banque est en mesure d’identifier la variante de format spécifique utilisée dans un pays donné et donc d’initier le mode de traitement adéquat. Cela dit, l’utilisation de paramètres de format n’est pas usuelle en Allemagne, raison pour laquelle l’on envisage d’y introduire un identifiant de l’émetteur pour EBICS. Celui-ci fournirait des informations quant à l’origine du format utilisé pour une transaction donnée et donc ses spécificités. Le serveur bancaire pourrait alors déterminer s’il existe des conventions et des règles de vérification spécifiques pour la variante de format concernée. Si le modèle français avec paramètres de format et code pays ne peut être introduit en Allemagne, l’adjonction d’un identifiant émetteur au type d’ordre EBICS devrait pouvoir être effectuée rapidement. Une telle solution serait judicieuse. Reste à espérer qu’elle soit prochainement disponible avec EBICS. D’ici là, les banques et leurs clients n’auront d’autre choix que de recourir à des solutions au cas par cas.

Les spécificités de l’utilisation des types d’ordre EBICS à trois caractères en Allemagne et des paramètres de format en France seront abordées dans un prochain article.

Michael Lembcke

EBICS enfin en Suisse

Jetons tout d’abord un bref regard en arrière sur la septième édition de l’Electronic Banking Forum de Petersberg, qui s’est tenue le 10 novembre 2011: Christian Schwinghammer, de SIX Interbank Clearing Suisse, y avait présenté un exposé intitulé «EBICS goes Europe – Où en est la Suisse?». Grand connaisseur de la place financière helvétique, il s’était à l’époque dit assez confiant de voir le nouveau standard s’imposer également dans les instituts financiers suisses – d’autant plus qu’avec UBS et Credit Suisse, deux poids lourds de la branche proposaient alors d’ores et déjà le canal de communication EBICS.

Mais comme souvent, les bonnes choses prennent du temps. Le rapprochement si souvent annoncé entre la société EBICS et la délégation suisse a été plusieurs fois reporté et a connu des débuts assez cahoteux. Du côté des managers des banques, le sujet EBICS a été quelque peu oblitéré par les débats fiscaux menés avec l’Europe (impôt libératoire à la source) et les États-Unis (FATCA). Cela n’a toutefois pas empêché le groupe de travail EBICS, réunissant les représentants des grandes banques suisses, de présenter une première version du «Guide d’implémentation EBICS» pour révision au début de l’année 2012.

La Suisse fait cavalière seule en matière de directives d’implémentation

À l’époque, les directives d’implémentation suisses ont été établies sans consultation du groupe de travail EBICS, ce qui a donné lieu à de nombreuses discussions et continuera à en susciter. Le groupe de travail pour la définition des types d’ordres EBICS en Suisse a ainsi suivi le modèle allemand basé sur une suite de trois caractères pour les types d’ordres disponibles. Concrètement, le type d’ordre «XKD» a par exemple été attribué au processus d’échange de données suisse. Parce qu’UBS et le Credit Suisse se sont fondés sur le système employé en Allemagne et que les types d’ordres identifiés par des trigrammes sont déjà utilisés auprès des clients, ce modèle est «de facto» devenu le standard dans notre pays.

Pourtant, de nombreux Suisses jugent la variante française «FUL/FDL» plus flexible et plus élégante dans son architecture. Celle-ci ne repose pas sur la coutume allemande consistant à utiliser des types d’ordres définis par des trigrammes, comme c’était déjà le cas dans le protocole précédent (FTAM). Au vu de l’extension prévue d’EBICS à d’autres pays d’Europe et du reste du monde, le stock de trigrammes encore disponibles pourrait en outre s’épuiser. Cela dit, le passage au modèle français impliquerait des efforts et des coûts considérables.

En dépit de la discorde qui règne encore sur ce point, EBICS semble définitivement établi en Suisse. Son introduction par la Banque cantonale de Lucerne à l’automne et par celle de Zurich au début de l’année prochaine va sans doute accélérer la diffusion du protocole dans notre pays. D’autres banques cantonales ne seraient d’ailleurs pas en reste et procéderaient à l’évaluation des solutions EBICS qu’elles pourraient proposer à leurs clients. L’adhésion de la Suisse à la société EBICS semble également en bonne voie: des offres concrètes en ce sens ont déjà été formulées et une première réunion tripartite du groupe de travail EBICS est prévue en août à Zurich.

Il sera intéressant de voir comment ce « ménage à trois » va se comporter dans la pratique. Les Suisses devraient ici jouer un rôle important, leur réputation d’habileté diplomatique et de plurilinguisme les ayant précédés. Selon la rumeur, les relations entre les acteurs allemands et français ne se sont, par le passé, pas toujours révélées harmonieuses. L’utilisation des types d’ordres disponibles en Suisse – évoquée précédemment – a entre autres été le déclencheur à l’origine d’une demande de modification concrète auprès de la société EBICS («EB-14-DK-int04 OrderType with issuer»). L’adjonction d’un «issuer code» pour le type d’ordre concerné doit permettre de simplifier l’utilisation de types d’ordres identiques dans d’autres communautés. Un type d’ordre helvétique au format pain.001 (CCT) pourrait ainsi être différencié sans équivoque d’un type d’ordre français ou allemand, tout simplement en ajoutant un «issuer code» spécifique pour la Suisse.

Carsten Miehling

La Banque cantonale de Lucerne mise sur EBICS

Pour la première fois, EBICS est désormais intégralement pris en charge par une banque cantonale suisse. La Banque cantonale de Lucerne (BCL) émet ainsi un signal fort en Suisse, prévoyant de mettre EBICS en production dès 2014. Je me réjouis de constater que la diffusion d’EBICS se poursuit et que le standard s’impose également de plus en plus en Suisse. Précurseur dans ce domaine, la BCL y a sans aucun doute contribué.

À mes yeux, les raisons à l’origine du rapide succès d’EBICS en Suisse sont les suivantes:

1. EBICS utilise l’Internet  auquel ont en principe accès toutes les entreprises. Les coûts de communication restent donc faibles. De plus, le marché des produits EBICS dédiés aux entreprises est relativement bien fourni, ce qui assure un bon rapport qualité-prix.


2. En Suisse, il n’existait auparavant aucun standard unique pour les échanges électroniques entre les entreprises et les banques. S’il avait été décidé de mettre au point un standard, il aurait de toute évidence très fortement ressemblé à EBICS. Il semble donc judicieux d’utiliser l’original.

3. EBICS est un standard créé pour les banques, par les banques,ses process sont donc fondamentalement adaptés aux institutions bancaires helvétiques. Une adhésion à la société EBICS leur permettrait en outre de suggérer les évolutions qu’elles jugent opportunes.

4. L’aspect innovant d’EBICS réside surtout dans sa multi-bancarité. Même si le pour et le contre ont fait l’objet de longues discussions, c’est l’amélioration du niveau de  services offert à la clientèle qui s’est ici révélé déterminant – lequel constitue une priorité  pour les banques suisses.

5. Les discussions autour de la signature électronique distribuée (VEU pour «Verteilte Elektronische Unterschrift») ont été tout aussi âpres. Contrairement à l’Allemagne, chaque banque helvétique peut décider individuellement si elle souhaite ou non proposer ce service à ses clients. Le fait que les institutions bancaires disposent ici du libre-choix facilite l’introduction d’EBICS.

6. Le fait que l’Allemagne et la France aient déjà mis en œuvre EBICS et que de plus en plus d’entreprises paneuropéennes s’y intéressent de très près fûrent bien sûr des facteurs déterminants pour la Suisse. De plus, il est ainsi également possible de capter de nouveaux clients internationaux, sans avoir à changer les solutions existantes.

Je pense qu’il s’agit là des raisons essentielles pour lesquelles la BCL a décidé d’avoir recours à EBICS. Une attention particulière doit désormais être accordée à la VEU: il sera intéressant d’observer comment celle-ci va évoluer lorsque les premières banques, et donc leurs clients, commenceront à l’utiliser.

Michael Lembcke