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