EBICS – Opportunités d’internationalisation

Thomas Stosberg, GTB Product Management, Deutsche Bank AG

La Suisse a rejoint l’Allemagne et la France au sein de la société EBICS, marquant ainsi une nouvelle étape dans l’internationalisation d’EBICS. Ce dernier peut-il se hisser au rang de standard international, et est-ce dans l’intérêt des banques et de leurs clients?


Les différents organismes d’un pays chargés de traiter les opérations de paiement (nationales) aspirent à proposer une solution stable et standardisée pour le plus grand bénéfice des clients et des banques. L’adoption d’un nouveau standard requiert toujours une bonne dose de motivation, et ce, afin de surmonter les difficultés inhérentes à la sécurité technique et/ou aux coûts d’exploitation de la solution existante; ou pour le formuler différemment : les pays disposant déjà d’une solution opérationnelle avec tous les acteurs du marché local seront sans doute peu enclins à envisager le passage à un nouveau standard. Pour toutes les nations à la recherche d’un nouveau standard, EBICS pourrait cependant se révéler la meilleure option.

Du point de vue des clients

Les clients cibles d’EBICS – les entreprises de toutes tailles, de la TPE aux groupes internationaux – ont besoin d’une solution respectant deux exigences : d’une part un faible coût et d’autre part une connexion multi-bancaire simple, sécurisée, conforme aux règlementations et standardisée (en termes de communication bancaire et de formats). Cette dernière condition permet une intégration homogène de toutes les banques partenaires et offre la possibilité de répartir les opérations de paiement sur différentes institutions financières ainsi que de réagir aux éventuels problèmes techniques en toute urgence.

EBICS est tout à fait en mesure de répondre à l’intégralité des besoins côté clients. S’agissant de la variante allemande, il est même possible d’atteindre l’automatisation intégrale du processus grâce à la mise en œuvre de signatures numériques sans recours à des certificats et d’une autorisation «Corporate Seal».

L’évolution du standard – sur le marché allemand par l’introduction du format CGI-MP-XML pour le traitement des opérations de paiement à l’échelle mondiale – a par ailleurs créé les bases pour établir EBICS en tant qu’alternative à SWIFT ou à une liaison host-to-host pour la communication entre les clients et les banques.

Du point de vue des banques

À l’avenir, les banques auront beaucoup de mal à s’imposer sur le marché en s’appuyant uniquement sur des solutions propriétaires. Une solution technique propre à la banque (communication bancaire et format des opérations de paiement) n’est perçue ni comme un avantage concurrentiel, pas plus que comme un argument de vente. À l’échelon de la banque, l’exploitation et la maintenance d’une telle solution ne sont tout simplement pas rentables.

La concurrence entre les institutions financières se déroulera donc exclusivement au niveau des prestations bancaires proposées et de leurs prix. Les clients quant à eux souhaitent que les solutions techniques utilisées dans les opérations de paiement atteignent un degré de standardisation proche par exemple de celui de la fourniture d’électricité.

L’introduction d’EBICS en France a montré que les répercussions d’un standard commun sur la clientèle existante et sur les revenus générés sont relativement faibles. Cela s’explique par la différence existant entre les interfaces clients des deux pays, et par le fait que le choix d’une relation bancaire ne dépend pas des canaux d’accès qu’elle propose.

En termes d’interfaces client, EBICS offre aux banques la possibilité de proposer un service standardisé pour plusieurs pays. Le standard peut par ailleurs être utilisé en tant que moyen d’accès à la compensation des paiements SEPA.


EBICS une opportunité d’internationalisation

Pour les clients, EBICS constitue une solution de communication bancaire très attractive. Au sein des banques, le standard offre la possibilité de proposer un accès standardisé pour plusieurs pays sur la base d’une infrastructure unique. Et c’est également vrai lorsque la banque n’opère majoritairement que dans un seul pays, car elle reste en mesure – sans investissement important – de proposer des prestations à ses clients ayant des filiales au sein de l’espace SEPA. L’implémentation d’EBICS dans les deux plus grands pays d’Europe et en Suisse s’est d’ores et déjà traduite par une augmentation considérable du nombre d’utilisateurs du standard au-delà de ces nations. Ce chiffre en constante augmentation contribuera sans nul doute à imposer EBICS dans d’autres pays et d’autres institutions bancaires. Une diffusion plus large d’EBICS serait un avantage certain pour tous les acteurs du marché. En outre, le standard reste de loin la meilleure solution pour moderniser le système de traitement des opérations de paiement dans les pays qui doivent se résoudre à une telle démarche.

Thomas Stosberg

Comment améliorer EBICS, 7e partie – mise à jour automatique des clés bancaires : est-ce envisageable ?

Conformément aux spécifications d’EBICS, les données sont toujours signées et chiffrées avant d’être transmises. Et cela s’applique aux deux sens de communication : client > banque et banque > client. En Allemagne, les clés utilisées à cet effet disposent en théorie d’une validité illimitée. En revanche en France la durée de validité des certificats est limitée. Pour des raisons de sécurité, il est indispensable que les clés soient renouvelées régulièrement. Côté client, EBICS propose d’ores et déjà des fonctions permettant un changement automatisé de la clé d’un participant EBICS initialisé auparavant. Le renouvellement automatique des clés bancaires se révèle quant à lui plus difficile à mettre en œuvre dans la pratique. Un «changement en douceur» peut être une solution.


Pourquoi les banques n’aiment-elles pas changer leurs clés EBICS

Au moyen de la commande HPB, le système client EBICS peut télécharger les clés publiques du serveur pour l’authentification (identification de la banque) et le chiffrement de la remise des fichiers. Si le système client utilise des clés bancaires invalides ou périmées, il reçoit (conformément aux spécifications d’EBICS) le code retour négatif EBICS_BANK_PUBKEY_UPDATE_REQUIRED.
Cela entraîne les problèmes suivants:
  • Dès réception du code retour EBICS_BANK_PUBKEY_UPDATE_REQUIRED, le client EBICS devrait télécharger la clé bancaire valide via HPB. Or, ce processus n’est pas toujours suffisamment supporté par les clients EBICS.
  • Après le téléchargement des nouvelles clés bancaires, une clé qui n’est pas basée sur les CA et certificats doit être validée manuellement dans le client EBICS par l’enregistrement de sa valeur de hachage.
  • Or les clients EBICS fonctionnent bien souvent de manière automatisée. La nécessité d’une intervention manuelle en cas de renouvellement de la clé bancaire, par exemple sous la forme du téléchargement de la nouvelle clé ou de sa validation, n’est par conséquent généralement détectée que trop tard ou pas du tout. Les défaillances semblent donc inévitables.
De ce fait, les exploitants des serveurs bancaires EBICS rechignent à modifier les clés bancaires. Les dispositions suivantes pourraient changer la donne.

Pour un changement de clé bancaire en toute quiétude

Pour renouveler sans problème les clés bancaires et certificats, il devrait dans un premier temps être possible de les modifier «en douceur». Cela signifie que tous les clients ne devraient pas avoir à actualiser leurs clés bancaires du jour au lendemain.

Un changement de clé en douceur est possible si le serveur bancaire EBICS est doté de la capacité de travailler en parallèle avec les anciennes et les nouvelles paires de clés. Les clients EBICS qui détectent un changement et procèdent à l’actualisation (y compris de manière automatisée) utilisent alors la nouvelle clé, tandis que les autres continuent à utiliser l’ancienne. Dans ce dernier cas, la banque peut choisir de contacter les clients concernés pour leur indiquer le changement.

Une autre mesure essentielle serait d’implémenter la proposition de modification EBICS EB-14-12 tant du côté client que du côté serveur. Cette proposition doit être intégrée aux prochaines spécifications EBICS et prévoit entre autres qu’en cas de téléchargement des clés bancaires, les nouvelles oient signées à l’aide de l’ancienne clé d’authentification de la banque (voir www.ebics.org). Une validation manuelle dans le client EBICS est alors nécessaire uniquement lors du premier téléchargement de clé. Pour chaque ordre HPB suivant, la signature est vérifiée et les clés bancaires sont ensuite automatiquement validées dans le client EBICS si la vérification est positive.
Grâce à ces fonctionnalités, il est possible de renouveler les clés bancaires de manière totalement automatisée.

Michael Lembcke

SIBOS 2015: mouvements sur le front des opérations de paiement

Le salon SIBOS de Singapour fait traditionnellement la part belle à SWIFT, tandis qu’EBICS ne joue qu’un rôle secondaire. Cela dit, l’utilisation et les futures évolutions d’EBICS y ont néanmoins suscité un vif intérêt. Plus de 8000 visiteurs ont pris le chemin du Sands Expo and Convention Centre, faisant du SIBOS de Singapour la plus grande manifestation de son genre en Asie et la deuxième plus grande à l’échelle mondiale. Et les thèmes dominants semblent indiquer que des mutations majeures sont sur le point de concerner les opérations de paiement.

EBICS BTF

Avec l’adhésion de la Suisse à la société EBICS, la diffusion du standard s’est encore accélérée. À ce jour, deux variantes distinctes d’EBICS sont utilisées en Allemagne et en France. Or, les Suisses s’apprêtent à ajouter la leur. Pour permettre l’utilisation d’EBICS dans d’autres pays, une harmonisation du standard est imminente: EBICS BTF.

Volonté affichée des trois pays: développer un standard EBICS unique – et les préparatifs battent leur plein. Nous ne manquerons pas de vous communiquer plus d’informations sur EBICS BTF très prochainement.

Numérisation

Dans certains pays, les opérations de paiement sont hautement automatisées. Les processus sont presque intégralement numérisés, intègrent un ou plusieurs partenaires et dépassent largement les limites des systèmes mis en œuvre par les différents acteurs. Citons ici SWIFT et EBICS, qui permettent tous deux l’échange d’informations structurées entre partenaires.

Mais d’autres domaines bancaires sont également susceptibles de profiter des avancées faites dans les opérations de paiement. Il est ainsi tout à fait possible d’étendre le degré important de numérisation aux crédits, aux garanties et aux transactions documentairespar exemple. La tendance pour les prochaines années semble s’orienter en ce sens.

Solution de secours pour les flux d’opérations de paiement

Les sommes concernées par les opérations de paiement sont astronomiques. TARGET 2 gère ainsi près d’un billion d’euros par an – un 1 suivi de quinze zéros ! Toute interruption du traitement doit donc être évitée.

Les voix exigeant une solution de secours pour garantir le bon déroulement des flux de paiement se multiplient par conséquent. EBICS s’impose ici presque naturellement en tant que complément à SWIFT. Certaines rumeurs font état de premières recommandations – car ce ne seront que de simples recommandations – visant à sécuriser les opérations de paiement numériques au moyen d’un deuxième protocole

Evolutions réglementaires

Par le passé, ces sont les exigences réglementaires qui dominaient en matière d’opérations de paiement, comme le démontrent les exemples de SEPA et ISO 20022. Selon nos estimations, quelque 30 nouvelles tendances et projets vont faire leur apparition dans ce domaine au cours des deux prochaines années – la plupart sous l’égide des instances réglementaires. Les répercussions sur l’informatique s’étendront des systèmes de réception aux systèmes bancaires centraux, en passant par le clearing. L’intégralité des infrastructures mises en œuvre dans les opérations de paiement semble donc concernée. L’avenir promet d’être passionnant!

Michael Lembcke

Migration des opérations de paiement en Suisse: des tests end-to-end grandeur réelle avec EBICS

Les banques de la place financière suisse travaillent d’arrache-pied à l’harmonisation des opérations de paiement selon la norme ISO 20022. Les éditeurs de logiciels et les entreprises ont besoin d’outils pour tester les nouveaux formats de paiement. Leur requête: un scénario de test end-to-end reproduisant le plus fidèlement possible le traitement au sein de la banque. En Suisse, seule une poignée de banques sont en mesure de proposer de tels tests. EBICS peut les y aider.


SIX Interbank Clearing, responsable de la publication de l’implémentation suisse, propose une plateforme de validation, sur laquelle la syntaxe et la conformité aux règles métiers simples des messages concernés (pain et camt) peuvent être validées. Généralement, cette plate-forme constitue la première étape de test dans le nouvel univers ISO. Pour les éditeurs et les clients, cette vérification se révèle cependant insuffisante pour migrer leurs processus de paiements auprès de leur banque.

Des tests end-to-end appropriés doivent également inclure les écritures relatives aux ordres dans les relevés de compte électroniques (p. ex. MT940 ou camt.053) et les avis (p. ex. MT942 ou camt.052), y compris les soldes, ou encore simuler des erreurs telles que celles qui peuvent survenir en production (avec génération de rapports de statut et d’écritures d’annulation). «Les avis constituent souvent un problème dans les tests, car ils sont établis en fonction des données mises à disposition», relate Christoph Schenker de PostFinance. «La plateforme de test http://isotest.postfinance.ch offre tout ce dont les éditeurs de logiciels ont besoin pour adapter la présentation et la mise à disposition des ordres de paiement dans leurs produits à la norme ISO.»

Les clients souhaitent ardemment simuler des erreurs, et ce, afin de tester leurs processus internes de traitement des exceptions avant le passage en production. En règle générale, il s’agit d’anomalies telles que «insuffisance de provision», «compte bénéficiaire incorrect» et d’autres similaires qui peuvent survenir au quotidien.

Si l’on élargit quelque peu le cadre du «end-to-end» il serait idéal ,pour une entreprise, de pouvoir transmettre directement un ordre de paiement à une infrastructure de test à partir de son propre logiciel ERP via EBICS, et ainsi de réaliser les téléchargements correspondants également par l’intermédiaire d’EBICS. Ce n’est qu’ainsi qu’un test en grandeur réelle est possible. Dans ce cadre, ce sont surtout les messages d’erreur et le traitement de fichiers de taille réalistes qui doivent être simulés – donc des processus créditeurs opérationnels avec quelques centaines de paiements ou plus, et non des paiements de tests isolés. Il est ainsi possible de garantir un passage en production sans anicroche. La liaison directe à une plateforme de test par le biais d’EBICS permet d’automatiser les cycles de test et de transmettre des fichiers de grande taille via le protocole EBICS – ce qui n’est que difficilement possible avec une plateforme de test ne disposant que d’une interface de téléchargement manuelle via le web.

Les banques innovantes helvétiques voient dans la combinaison d’ISO 20022 et d’EBICS un outil idéal pour aider leurs clients dans l’harmonisation des ordres de paiement. Les institutions qui sont en mesure de proposer une véritable solution de test end-to-end offrent à leurs clients une véritable valeur ajoutée. «SAP gère les virements sous ISO 20022 depuis déjà plusieurs années. Des plateformes de tests efficaces et des interlocuteurs directs auprès des institutions financières soutiennent par ailleurs le déploiement des messages ISO 20022 en Suisse», explique Rainer Hofmeister de l’éditeur SAP.

Carsten Miehling

Comment améliorer EBICS, 6 partie – identification sans équivoque de la personne agissante

Un ordre de paiement, qui dans EBICS doit normalement être autorisé par deux personnes différentes, peut-il être validé par une seule personne ? Oui, c’est possible dans certaines circonstances. Dans certaines configurations contractuelles entre l’institution financière et l’entreprise cliente, la personne agissante ne peut pas être identifiée clairement.


Le responsable: le modèle de données d’EBICS

Le modèle d’autorisation du client entreprise dans la communication via EBICS se fonde sur le modèle de données d’EBICS. Ce dernier fait la distinction entre le client et son collaborateur en tant que participant EBICS.

Les entreprises communiquent avec leur banque via EBICS par le biais d’un ID client valide pour toute l’entreprise et d’un ID participant propre au collaborateur agissant. Ces ID sont attribués par la banque lors de la création du client et de ses collaborateurs; le client en a besoin pour se connecter au serveur bancaire par l’intermédiaire des accès clients EBICS. Problème: cet ID utilisateur n’est pas toujours unique. Comment est-ce possible?

Les entreprises utilisent différents clients EBICS

Les grandes entreprises utilisent parfois plusieurs logiciels clients EBICS de fournisseurs différents. Selon sa fonction, un même collaborateur peut alors utiliser plusieurs solutions clientes en parallèle. Exemple type: un collaborateur qui autorise et transmet des paiements à l’aide d’un produit EBICS pour PC – et qui simultanément autorise via une solution EBICS pour mobile des paiements qui ont été transmis directement à la banque par sa solution ERP pour la signature électronique distribuée communément utilisée en Allemagne.

Clés et certificats ne sont bien souvent pas partageables

Les clés et certificats relatifs au participant étant stockés différemment en fonction du système client et du pays EBICS, un collaborateur ne peut en règle générale pas les utiliser pour tous les contrats clients EBICS. De fait, le produit EBICS pour PC et la solution EBICS pour mobile requièrent des clés distinctes pour un même participant. C’est la raison pour laquelle le collaborateur, dans le cadre de son accès EBICS à la banque, dispose d’un ID participant différent pour chaque contrat client EBICS, qui lui permet ensuite d’accéder à ses clés et certificats.

Le modèle de données d’EBICS définissant chaque participant comme personne unique, une personne disposant de plusieurs ID participant peut théoriquement valider elle-même des paiements qui devraient être autorisés par plusieurs personnes. Dans le modèle de données d’EBICS, l’attribution d’une même personne à plusieurs ID participant n’est pas prévue.

Pour éviter toute utilisation abusive, les serveurs bancaires EBICS sont désormais dotés de fonctions de correction individuelles supplémentaires. Une solution harmonisée dans le standard EBICS semble néanmoins souhaitable.

Format d’échange harmonisé pour les clés et certificats

Une approche possible serait d’imposer un format d’échange harmonisé dans le standard EBICS pour le stockage des clés et des certificats, par exemple sous la forme d’un token logiciel avec stockage au format PKCS12. Dans ce cas, il serait possible d’utiliser l’ID participant unique pour identifier la personne agissante. Ainsi les clés et certificats pourraient être utilisés en liaison avec le même ID participant sur plusieurs clients.

Michael Lembcke

Quid d’EBICS au Maroc ?

L’essor d’EBICS en Europe n’est plus à démontrer. Mais quid de son développement au-delà des frontières de l’Union Européenne. Il est un continent qui me semble parfaitement propice à l’adoption d’un protocole d’échange de flux financiers moderne, performant et universel tel qu’EBICS: l’Afrique. Et pour être plus précis, c’est au Maroc que je pense en premier lieu, pour les raisons exposées ci-après.

De longue date, les banques et les institutions financières marocaines se sont inspirées des pratiques bancaires européennes, et plus particulièrement de celles des banques françaises. Ainsi, dans les années 90, les banques marocaines ont emboité le pas aux banques françaises en choisissant le protocole ETEBAC pour les échanges télématiques Entreprise-Banque, offrant ainsi la possibilité aux entreprises marocaines de mettre en œuvre des solutions efficientes de Cash Management.

De même, les formats d’échange utilisés par l’industrie bancaire marocaine se sont fortement inspirés des formats CFONB, que ce soit pour les relevés de comptes ou pour les virements et prélèvements.
A l’heure actuelle, le protocole ETEBAC est toujours utilisé au Maroc. Cependant, il fonctionne en X28 via des PAD privés et les entreprises doivent utiliser des modems analogiques asynchrones qui deviennent introuvables. Il devient donc quasiment impossible de faire croître le nombre d’entreprises utilisatrices du canal ETEBAC. Les solutions de substitution proposées sont:
  • l’internet-banking qui ne convient pas aux entreprises multi-bancarisés ou ayant des volumes de transactions significatives,
  • SWIFT qui engendre des frais récurrents supplémentaires non négligeables,
  • d’autres protocoles moins usités tels que PeSIT qui ne répondent pas aux exigences futures.
Le cadre juridique marocain relatif aux échanges de données numériques et à leurs protections milite en faveur de l’adoption de protocoles d’échanges de données sécurisés avec signature(s) électronique(s). Ce qui dotera les transactions bancaires des fonctions de sécurité requises à savoir authentification, inaltérabilité et intégrité, confidentialité, non rejeu de la signature et non répudiation. Lesquelles sont proposées en standard par le protocole EBICS.

Les banques marocaines, pionnières en Afrique et présentes dans 22 pays du continent, ont besoin de systèmes fiables et éprouvés de transfert de données financières interbancaires transfrontalières pour faire en sorte entre autres que le Maroc devienne un Hub de transferts bancaires permettant ainsi de capter un maximum de transactions d’une manière sûre et moderne. Pour ce faire, EBICS est le protocole approprié.

Par ailleurs, EBICS ne permettra pas seulement d’étoffer l’offre de services existante pour les entreprises, il sera également une réelle opportunité d’innovation pour les banques marocaines qui pourront l’utiliser pour ouvrir de nouveaux services (par ex. e-Invoicing).

Et n’oublions pas deux autres domaines d’utilisation dans lesquels EBICS serait parfaitement opérant:
  1. Il est déjà utilisé en Europe avec la plus grande satisfaction pour les échanges interbancaires domestiques. Les institutions financières marocaines pourraient en faire de même, elles auraient ainsi la faculté d’améliorer la résilience et le haut niveau de disponibilité de ces échanges interbancaires et accessoirement d’en optimiser les coûts.
  2. Il est tout à fait adapté aux transferts de données pour les projets de dématérialisation gouvernementaux, afférents en particuliers aux données sociales, médicales et interservices.
Fort de ce qui précède, le protocole EBICS qui - comme tout lecteur du blog a pu le constater – se déploie rapidement en Europe grâce à son universalité, sa facilité de mise en œuvre, son haut niveau de sécurité et son absence de coûts récurrents, me paraît être une alternative de choix pour les échanges Business to Bank et Bank to Bank. Si, en outre, l’adoption de la norme ISO 20022 venait à être considérée par les banques marocaines, un grand pas serait alors franchi vers une harmonisation et une standardisation des échanges de flux financiers qui apporterait une simplification et une optimisation des transactions avec l’Europe. Ce point me semble d’autant plus important que la proximité du Maroc avec le continent européen a bénéficié à l'économie marocaine dans la mesure où cette dernière a profité des nombreuses délocalisations effectuées par les entreprises européennes.

Se pose alors la question de la migration vers EBICS. Est-ce un chantier si complexe qu’il puisse constituer un obstacle à l’adoption de ce protocole? Si l’on se réfère à la façon dont la migration s’est déroulée en France, je ne le pense pas. L’expérience acquise à cette occasion, non seulement par les éditeurs de logiciels pour banques et entreprises mais aussi par des banques françaises implantées au Maroc, serait un gage de migration en douceur, sans risque de devoir «essuyer les plâtres».

Marc Dutech

La Luzerner Kantonalbank AG offre aux entreprises des solutions élargies basées sur EBICS et ISO 20022

Raphael Häfliger, Cash Management Services, Luzerner Kantonalbank AG

La Luzerner Kantonalbank AG (LUKB) propose le standard de communication EBICS depuis 2014 en Suisse, offrant ainsi une gamme complète de prestations pour les opérations de paiement professionnelles. Après l’introduction réussie d’EBICS, la banque s’apprête maintenant à franchir une nouvelle étape: la LUKB sera en effet la première institution de la place financière suisse à initier une phase pilote pour l’introduction de la «signature électronique distribuée» (VEU) à l’automne 2015.
 
La VEU répond ici à un besoin de plus en plus répandu des entreprises helvétiques. Grâce à elle, les clients de la LUKB peuvent transmettre des ordres de paiement à la banque et les faire valider par les personnes responsables au sein de l’entreprise – en fonction des pouvoirs attribués à cette dernière. Cette étape de traitement se distingue de la variante d’EBICS habituellement mise en œuvre en Suisse, dans laquelle une signature unique est utilisée, les autorisations étant régies par le système ERP du client. Si la VEU est devenue la norme en Allemagne, elle reste une innovation en Suisse.

L’introduction de la VEU est perçue par la LUKB comme une chance de se positionner en tant qu’institution financière à la fois flexible et orienté clientèle. La banque procédera à la création de la VEU EBICS en concertation avec le client, ceci afin de déterminer le modèle de signature le mieux adapté. Les spécifications suivantes sont entre autres prévues :
  • collective à deux
  • collective à trois
  • groupes dotés de signatures A et B
  • rôles individuels supplémentaires pour la comptabilité des débiteurs et/ou des créditeurs
  • attribution/exclusion flexible de types d’ordres unitaires
L’intérêt de la VEU ne se limite cependant pas à ces possibilités. Au vu des risques opérationnels, il peut se révéler judicieux d’identifier les personnes responsables de l’émission d’ordres au sein d’EBICS. Largement répandus, les «corporate seals» – qui authentifient uniquement l’entreprise – ne le permettent pas. En outre, la pression exercée par les autorités réglementaires ainsi que par les cabinets d’audit pourrait augmenter dans ce domaine.

Pendant la phase de lancement, ce sont surtout les clients utilisant des solutions logicielles européennes qui devraient profiter de l’offre. À moyen terme, la LUKB s’attend à ce que les fournisseurs de logiciels locaux intègrent également la VEU dans leurs produits.

Dans sa communication à l’intention des entreprises, la banque va même plus loin et annonce vouloir acheminer le format ISO 20022 via EBICS à partir de décembre 2015. Dans les faits, les messages pain.001, pain.002, camt.052 et camt.053 seront ainsi implémentés. Complétant l’offre ISO, camt.054 devrait suivre au printemps 2016. Avec ce programme, la LUKB fera partie des premiers fournisseurs d’une solution opérationnelle dans le cadre du projet «Harmonisation du trafic des paiements en Suisse». Outre les recommandations helvétiques, la LUKB supportera également les schémas ISO et DK (Allemagne) pour l’émission d’ordres via ISO 20022. L’implémentation de schémas supplémentaires (comme les formats français et autrichien) fera l’objet d’évaluations au cas par cas en fonction des exigences des clients.

Grâce à son offre exhaustive autour de la VEU EBICS et d’ISO 20022, la LUKB semble parfaitement positionnée pour relever les défis à venir sur le marché des clients entreprises.
www.lukb.ch/harmonisierung-zv
www.lukb.ch/direkt-ebics

Raphael Häfliger

Dans la série: Comment améliorer EBICS, 5e partie – administration des comptes et des participants par les clients

À la base, EBICS est doté de toute une série de types d’ordres utiles pour obtenir des informations relatives aux clients et participants (à noter qu’ils ne sont pas systématiquement proposés par tous les fournisseurs). Il est ici par ex. question de types d’ordres comme HKD (interrogation des données client) et HTD (interrogation des données participant). Les grandes banques helvétiques aimeraient non seulement accéder à ces données, mais également pouvoir les administrer et les modifier elles-mêmes.


Une particularité de l’implémentation suisse réside dans sa limitation actuelle aux types de signatures «T» et «E». Dans le cas de la première, l’ordre d’exécution est transmis sur un canal de communication distinct (par ex. banque en ligne). Pour la deuxième, l’ordre est traité immédiatement, le donneur d’ordre étant lui-même responsable des mesures de sécurité à appliquer. En règle générale, la personne qui a apposé sa signature n’est pas connue dans le cas du type «E», mais seulement l’entreprise ou le client donneur d’ordre.

La raison principale invoquée pour ne pas mettre en œuvre la signature électronique distribuée («VEU») en Suisse reste la complexité de l’administration des droits VEU par participants et par comptes. Etant donnée la fréquente absence de lien direct entre les données de base client de la banque et le produit EBICS, des doubles saisies sont engendrées qui peuvent avoir des répercussions sur un certain nombre de clients et de modifications des autorisations. Il faudrait donc mettre en œuvre un mécanisme proche de l’«Electronic Bank Account Management» (eBAM).

Quinze messages ont d’ores et déjà été modélisés à cet effet dans le standard ISO 20022 (voir catégorie de messages acmt). Cette base pourrait être utilisée pour étendre le protocole EBICS afin de permettre de déléguer au moins en partie l’administration des comptes et des participants au client. Un système de confirmations multiples, par le biais de signatures côté client et un principe de double vérification côté banque, pourrait être ajouté en fonction des différentes exigences en matière de sécurité. À titre d’exemple, le client aurait à contrôler deux fois une transaction sensible, tandis que la banque aurait à valider manuellement son exécution (sans toutefois devoir la saisir intégralement).

Avec un type d’ordre propre à la banque (XYZ) relatif à la transmission de données XML de compte et de participant, il serait possible d’introduire un tel procédé dès aujourd’hui. La banque pourrait alors vérifier les autorisations et les appliquer de manière automatisée par le biais de l’interface avec le produit EBICS (par ex. Webservices). La position suisse en la matière est pour l’heure marquée d’une certaine réserve, puisque de nombreux types d’ordres helvétiques ont déjà été introduits en suivant le même principe – types d’ordres que l’on souhaite remplacer dans un proche avenir par un concept global basé sur la variante française FUL/FDL. Pour notre part, nous souhaiterions que cette exigence soit intégrée dans une future description d’ordre dans EBICS. Tant le client que la banque ont tout à gagner d’une automatisation accrue.

Carsten Miehling

Dans la série: Comment améliorer EBICS, 4e partie – à chacun ses extraits de compte

Une grande partie des données qu'une entreprise télécharge d’un serveur bancaire via EBICS sont afférentes à un compte. Comment déterminer dès le téléchargement quel extrait de compte doit être accessible à quel collaborateur? La solution: instaurer un pilotage correspondant côté serveur bancaire.


EBICS régit l’acquisition et la restitution des données au moeyen de types d’ordre et de paramètres de format. Le format de données associé au type d’ordre détermine les possibilités de traitement offertes au niveau du serveur bancaire EBICS. Les contenus des données ne sont cependant pas régis par EBICS et peuvent donc différer d’un serveur bancaire à l’autre et d’une banque à une autre.

Quelles informations de compte pour quels participants EBICS?

Les données auxquelles ont accès les collaborateurs en leur qualité de participants EBICS sont généralement mises à disposition sur le serveur bancaire pour un client déterminé. Chaque participant EBICS du client qui dispose du type d’ordre correspondant peut donc télécharger l’ensemble des données mises à disposition pour ce même client. Cela s’applique aux données liées au compte telles que les extraits de compte et aux transactions prévisionnelles. Lors de l’accès aux données, l’autorisation du participant pour un compte déterminé n’est pas vérifiée, contrairement à ce qui se passe lors de la présentation d’ordres de paiement dans les échanges entre le client et la banque. En outre, le message EBICS ne comporte aucun détail relatif au compte. Les vérifications et les traitements liés au compte dépendent de l’implémentation du serveur bancaire – et dans l’essentiel également de la complétude des informations du compte associé aux données devant être mises à disposition, ainsi que de l’existence effective de ce compte.

Autorisation de compte pour les données mises à disposition

Dans des cas particuliers, un participant EBICS ne devrait pouvoir accéder aux informations que de certains comptes. Une solution évidente serait dès lors de mettre à disposition les données non plus par client, mais par participant. Cependant, les données étant relatives à un client entreprise, cela se traduit dans le cas de plusieurs participants pour un même client par des redondances et donc par un accroissement du volume de données. Il est par conséquent préférable de continuer à mettre à disposition les données par client et de piloter les accès par le biais de l’autorisation que détiennent les différents participants (s’il s’agit de données effectivement liées au compte). Chaque participant accède ainsi exactement aux données des comptes pour lesquelles il est habilité.

Une extension permettant d’indiquer un ou même plusieurs compte(s) dans une demande EBICS – similaire à l’indication d’une période en cas de demande d’historique – serait donc judicieuse. Cette fonctionnalité EBICS permettrait aux participants d’accéder aux données de comptes déterminés. Pour le participant, il n’est pas toujours important que les informations soient à jour pour tous les comptes. Une extension EBICS en la matière permettrait un accès plus ciblé aux données et apporterait aux clients une plus grande flexibilité dans l’interrogation des comptes.

Michael Lembcke

EBICS – en passe de devenir un standard européen

Axel Weiß, Chairman of Board of Directors EBICS

Depuis 1995, les entreprises allemandes sont en mesure d’effectuer leurs opérations de paiement en toute sécurité à l’aide d’un produit standard assorti d’une signature électronique, et ce, auprès de l’ensemble des instituts financiers.

L’ajout d’une variante internet à l’accord relatif aux transferts de données a été initié dès 2003. Cette variante da la procédure de transfert de données devait être baptisée «Electronic Banking Internet Communication Standard» ou EBICS. Grâce à elle, le secteur bancaire allemand fut à même de répondre tant aux exigences des clients que des institutions financières en matière de solutions de banque électronique basées sur l’Internet.


L’objectif était d’étendre le standard commun multibanque «DFÜ mit Kunden» aux canaux de transfert via l’Internet et ainsi d’élargir les possibilités de mise en œuvre inhérentes. Pour ce faire et conformément aux exigences actuelles en matière de sécurité, l’on utilise des mécanismes de sécurisation tels que HTTPS ainsi qu’un dispositif supplémentaire d’authentification forte.
Les caractéristiques spécifiques d’EBICS sont les suivantes:
  • il s’agit d’un standard s’adressant à toutes les banques et entreprises, c.-à-d. que ces dernières sont en mesure d’effectuer des transferts avec toutes les institutions financières proposant EBICS à l’aide d’un seul et même logiciel
  • il s’agit d’un standard ouvert, c.-à-d. que les entreprises peuvent utiliser des produits standards ou leurs propres logiciels pour le mettre en œuvre
  • il utilise une technologie moderne et des standards internationaux libres de droits comme XML, HTTPS, TLS, ZIP
  • il garantit les standards de sécurité les plus élevés, p. ex. par le biais d’un cryptage de bout en bout à l’échelon du transport
  • il s’agit d’un procédé de transport applicable à l’ensemble des processus commerciaux (prélèvements, virements, extraits de compte, gestion de trésorerie, ordres sur titre, etc.)
  • il permet l’intégration de prestataires de services par le biais d’un concept de signatures à plusieurs niveaux
  • il permet la validation d’ordres indépendamment de la localisation
  • il s’agit d’un standard où le rapport prix/performance, et non l’aspect technique, prévaut (absence d’ajustements en cas de changement de la relation bancaire)
Outre pour la communication entre le client et la banque, EBICS est de plus en plus utilisé – en Allemagne comme dans un nombre croissant de pays de l’UE – pour l’échange sécurisé et très bon marché de transactions de paiement entre les banques. La mise à disposition d’un canal dédié aux transactions via EBICS par EBA Clearing a ainsi entraîné une augmentation significative du nombre d’opérations interbancaires effectuées à l’aide de ce standard, de sorte que quelque 5% des transactions SEPA traitées aujourd’hui par EBA Clearing concernent des transmissions via EBICS.

En plus d’être mis en œuvre dans le clearing bilatéral de paiements, EBICS est également de plus en plus utilisé en tant que solution de secours aux canaux de communication existants (comme SWIFT).
La désignation anglaise «EBICS» choisie en 2003 avait pour vocation de souligner l’ambition du standard de dépasser le cadre national et de s’imposer à l’échelon européen en proposant une alternative intéressante aux procédés existants, tant pour les banques que pour leurs clients.
En Allemagne, les banques ont obligation de supporter EBICS depuis le 1er janvier 2008. L’ancien standard FTAM a depuis lors été intégralement remplacé par EBICS.

L’année 2008 a également vu la signature d’un accord de coopération entre l’Allemagne et la France en matière d’EBICS. Suite à une étude exhaustive placée sous le signe du «make or buy», l’industrie bancaire française avait déterminé qu’EBICS apportait la meilleure réponse aux exigences des banques du pays et de leurs clients, et présentait donc le meilleur potentiel pour succéder au standard de communication ETEBAC. Pour les banques et et les associations impliquées, il est vite devenu évident qu’une utilisation juridiquement sûre d’EBICS par l’ensemble de ses utilisateurs passait par la création d’une société EBICS commune. Le but de cette société devait notamment être de développer et de maintenir le standard EBICS ainsi que de détenir les droits de marque relatifs.

À l’issue d’intenses négociations entre les industries bancaires française et allemande, la société EBICS a été fondée en juin 2010. Lors de la constitution d’EBICS SCRL, société de droit belge, les fondateurs ont scrupuleusement veillé à ce que l’entité conserve un but non lucratif et une structure la plus épurée possible, permettant de limiter les frais courants au strict minimum. Un soin particulier a en outre été apporté au fait que la société soit ouverte à l’adhésion d’autres acteurs bancaires intéressés.

La fondation de la société EBICS a créé les bases pour une mise en œuvre à l’échelle européenne et donc pour l’évolution d’EBICS vers un standard de marché européen. En avril de cette année, un pas important supplémentaire sur la voie d’un déploiement européen d’EBICS a été fait, avec la déclaration d’adhésion de SIX Interbank Clearing en tant que représentant de l’industrie bancaire helvétique.

L’objectif affiché est désormais de convaincre d’autres secteurs bancaires en Europe des avantages que recèlent une utilisation d’EBICS et une participation à la société éponyme – dont les portes sont grandes ouvertes.

Axel Weiß

EBICS et les paiements sur mobile en France

Dans la série «EBICS-standard européen pour les paiements mobiles», examinons le cas de la France.

Une solution sur mobile permettant à tout utilisateur de signer les transactions à distance -conformément au protocole EBICS TS - répondrait aux besoins des signataires «nomades» toujours plus nombreux à espérer que le mobile-banking avec EBICS devienne enfin une réalité.


A condition toutefois que cette solution soit suffisamment souple, autrement dit qu’elle fonctionne sur la plus grande variété de téléphones mobiles et tablettes, quels que soient leur système d’exploitation (à minima iOS, Android, Windows Mobile) et avec le même niveau de sécurité que celui fourni par les logiciels de signature EBICS TS sur PC utilisés quotidiennement par plusieurs milliers de signataires.

Des applications sur mobile ont certes vu le jour à l’initiative de tel ou tel éditeur, mais elles demeurent insatisfaisantes et donc peu utilisées car elles ne présentent pas la souplesse et la facilité d’utilisation requise. Rappelons en effet que pour être conforme aux spécifications décrites par le CFONB dans le guide d’implémentation, chaque signature doit disposer d’un certificat de signature personnelle sur support physique, délivré par une AC reconnue par la banque. Et c’est là que le bât blesse car autant il est possible de connecter un token USB sur certaines tablettes, autant il est impossible à ce jour de le faire sur tous les appareils mobiles, quelle que soit leur marque. Ou alors à grand frais d’adaptateurs et de connectique divers et variés, fonctionnant plus ou moins bien et surtout obligeant leurs utilisateurs à transformer leur appareil en de véritables usines à gaz, aptes à dissuader les meilleures volontés d’en faire un usage systématique.

Et il ne paraît ni raisonnable ni opportun d’obliger les signataires à s’équiper d’un smartphone ou d’une tablette supplémentaires auxquels la connexion d’un token est suffisamment commode pour être exploitée dès que c’est nécessaire.

Une solution serait de remplacer l’utilisation d’un support physique pour le stockage du certificat par un certificat à la volée, à usage unique. Mais, outre le fait que cela exigerait l’assentiment indispensable du CFONB, il faudrait refaire systématiquement l’enregistrement du certificat auprès d’une AC à chaque usage, ce qui enlèverait toute souplesse et ce faisant, tout intérêt.

Reste la problématique de l’absence de standardisation du processus de signature distribuée dont bénéficient nos voisins outre-Rhin au moyen de la Signature Electronique Distribuée (VEU). Bien que regrettable, la non concrétisation à ce jour d’EBICS DS n’empêche pas de proposer un service de couverture fonctionnelle équivalente : permettre aux signataires itinérants de confirmer des ordres avant exécution. Cette gestion des collèges de signataires et parapheurs est faite en amont sur une plateforme exploitée par l’entreprise ou par les prestataires et opérateurs de confiance. Une fois que le nombre nécessaires de signatures est atteint, impérativement au format EBICS (A005 ou A006), l’ordre et les signatures retenues sont acheminés vers l’établissement serveur via un envoi EBICS profil TS. A noter que cette solution permet de gérer des droits à signer plus riches que ceux proposés par le standard EBICS (1+1 ou 2) et donc potentiellement plus proches des attentes de l’utilisateur.

Marc Dutech

Des paiements haute disponibilité avec EBICS et SWIFT

Les transactions de paiements interbancaires européennes portent sur plusieurs milliards d’euros chaque jour. Ce volume gigantesque est traité de manière bilatérale et par l'intermédiaire d’organismes de clearing nationaux et européens, comme TARGET2, STEP2 et SEPA-Clearer. Pour l’économie comme pour nous tous en tant qu’individus, la circulation sans entrave de ces flux financiers est primordiale, raison pour laquelle la sécurité des systèmes informatiques concernés revêt une importance critique. Seule l’utilisation redondante des deux protocoles de transport EBICS et SWIFT garantit la haute disponibilité requise.


Point surprenant : les redondances requises dans le processus global ne sont pas systématiquement mises en œuvre. La haute disponibilité est ainsi généralement assurée par des systèmes redondants internes. Un point faible de taille – le «Single Point of Failure» – subsiste toutefois en cas de défaillance système, à savoir le processus d’échange électronique, qui doit lui aussi être redondant pour s’affranchir de toute panne.

Les deux protocoles de transport les plus courants dans les transactions internationales sont SWIFT et EBICS. Ils garantissent une sécurité de transmission et un rendement élevés – deux prérequis indispensables à une stratégie de transport duale. En outre, il est nécessaire que les systèmes soient indépendants l’un de l’autre. Or, cette indépendance ne peut être garantie que par une stratégie faisant appel à deux fournisseurs. La haute disponibilité requiert donc une stratégie faisant appel à deux fournisseurs alliant une approche de transport duale.

Afin d’améliorer la fiabilité, la première est d’ores et déjà employée dans des scénarios d’importance critique en matière de sécurité. Ces règles permettent d’éviter que le système d’un fournisseur donné puisse devenir le fameux «Single Point of Failure».

Examinons la stratégie de transport duale associant SWIFT et EBICS. Les topologies réseau des deux protocoles sont complémentaires:

SWIFTEBICS
Topologieen étoilemaillée
Administrationadministréeauto-administrée
Défaillancecentraleréparation automatique
Mode de transmissioncâblecâble et satellite

Dans le cas d’EBICS, les pannes sont réparées automatiquement, c.-à-d. en redirigeant automatiquement les données. Dans le cas de SWIFT en revanche, le réseau en étoile est administré de manière centralisée. Cette complémentarité est un atout en cas de défaillance car elle exclut par définition tout «Single Point of Failure». SWIFT et EBICS sont indépendants (grâce à la stratégie faisant appel à deux fournisseurs), ce qui les prédestine à un système de transport dual.

Si une panne survient au niveau d’EBICS, la banque ou la société de clearing peut agir sur les modalités techniques de transmission. Si les lignes terrestres sont hors service, il est ainsi possible de basculer sur des systèmes radio ou non terrestres, comme les satellites. Le satellite permet de couvrir l’ensemble des zones peuplées de la planète. Il s’agit d’un avantage certain d’EBICS par rapport aux réseaux administrés tels que SWIFT.

Mais qu’en est-il dans la pratique? Au vu des risques inhérents aux transactions interbancaires, la combinaison d’une stratégie de transport duale associant EBICS et SWIFT et d’une approche s’appuyant sur deux fournisseurs semble rien moins que raisonnable. Il n’est donc guère surprenant que des services comme STEP2 d’EBA Clearing et SEPA-Clearer de la Deutsche Bundesbank proposent tant EBICS que SWIFT et appliquent une stratégie s’appuyant sur deux fournisseurs. Il est possible de basculer en très peu de temps, voire plusieurs fois par jour, entre les deux protocoles de transport. Les banques allemandes et un établissement français utilisent déjà EBICS et SWIFT afin de minimiser les dommages résultant d’éventuelles défaillances. D’autres banques européennes et américaines leur emboîteront certainement le pas.

Il reste surprenant que le régulateur ne soit toujours pas intervenu dans ce domaine. Les répercussions d’une défaillance seraient en effet incalculables.

Michael Lembcke

EBICS – standard européen pour les paiements mobiles?

Les évolutions actuelles en matière de paiements mobiles ont de quoi déconcerter. Chaque jour voit l’apparition de nouveaux fournisseurs de solutions et les standards techniques foisonnent. Les banques sont confrontées au risque de se laisser distancer dans un secteur d’activité en pleine croissance. Le salut pourrait-il venir d’un standard européen comme EBICS?


Les mêmes règles s’appliquent aux paiements mobiles et aux transactions électroniques basées sur EBICS: il s’agit de garantir la sécurité de la communication, une authentification sans équivoque et la confidentialité des données de base et relatives à l’ordre. Pour les paiements mobiles, cela prend la forme de «Secure Elements» (cartes SD, SIM, HCE, etc.), auxquels viennent s’ajouter les différentes technologies de transmission (code QR, code-barre, NFC, BLE, etc.). Pour l’heure, rien ne semble vraiment réglementé, les acteurs les plus divers faisant leur entrée sur le marché: des grands fournisseurs de cartes de crédit aux prestataires spécialisés, en passant par les fabricants de matériel (Apple, Samsung) – tous tentent aujourd’hui de concurrencer les banques dans le domaine du trafic des paiements. Pour les banques, le défi se révèle de taille, car une bonne partie d’entre elles ne pourra pas proposer simultanément toutes les solutions.

Pour des transactions uniformisées et sécurisées, les développeurs d’applications et les clients auraient besoin d’un protocole standard comme EBICS ou FinTS. De tels standards sont déjà bien établis dans les autres environnements de transactions, les formats ISO 20022 et SEPA permettant de joindre immédiatement quelque 400 millions de détenteurs de compte en Europe. Parmi les premières adaptations des standards aux paiements mobiles figure la solution Jiffy de SIA Italie, entièrement basée sur SEPA.

Pour les consommateurs et les banques, cette approche présente l’avantage qu’aucun tiers ne vient augmenter les coûts de transaction, comme c’est le cas avec les paiements par carte de crédit – et encore davantage avec ApplePay. Elle permettrait aux institutions financières de reconquérir le marché. Des organisations comme l’European Payments Council (EPC) pourraient se charger de l’introduction et du développement d’un tel standard en Europe.

Il peut sembler présomptueux de qualifier EBICS de standard envisageable dans le domaine des paiements mobiles, son protocole ayant avant tout été développé pour des traitements asynchrones. Cependant, mes collègues blogueurs ont déjà eu l’occasion d’évoquer le potentiel d’extension que recèle EBICS en la matière: les interactions devraient en effet avoir lieu en temps réel et chaque transaction individuelle nécessiterait un retour synchrone. Cette approche paraîtra peut-être plus raisonnable dans un avenir proche, lorsque le «realtime clearing» se sera propagé dans toute l’Europe. Je me réjouis d’ores et déjà de vos réactions.

Pourquoi les banques devraient désactiver les anciennes versions d’EBICS

Gardez-vous une vue d’ensemble des versions d’EBICS disponibles? Quelle version utilise votre client EBICS? Quelles sont celles acceptées par le serveur de la banque? Le présent article entend établir un tour d’horizon et expliquer ce que la prolifération des différentes versions peut impliquer pour les utilisateurs.


En Allemagne, EBICS est officiellement exploité depuis le 1er janvier 2008 dans sa version 2.3, après que certaines fonctionnalités de la version 2.0 aient été proposées par quelques banques. La première mouture développée en commun avec la France est la version 2.4, qui est utilisée sous sa mise à jour la plus récente 2.4.2 depuis le 16 février 2010. Dernière version en date, l’édition 2.5 du 16 mai 2011 est principalement proposée par les instituts de crédit en Allemagne et en Suisse. Actuellement en préparation, la version 2.6 est prévue pour 2016. À ce jour, 6 versions successives ont été publiées (sans compter la future version 2.6), avec un nombre équivalent d’implémentations pour les serveurs bancaires et les systèmes clients.

Clients et banques ont besoin d’une version commune

Le protocole EBICS repose sur des structures XML. Outre les nouvelles fonctionnalités et les évolutions, une nouvelle version d’EBICS se distingue dans les faits par de nouveaux schémas XML. À l’aide du type d’ordre HEV basé sur le schéma neutre H000, le système client EBICS peut interroger le serveur bancaire quant aux versions supportées par celui-ci, puis poursuivre la communication en utilisant la version la plus récente en cas de réponse positive. Le serveur bancaire et le système client ne sont donc en mesure de communiquer correctement que si tous deux utilisent la même version d’EBICS. Si le nombre de versions existantes venait à s’accroître outre mesure, le risque que les deux partenaires de communication exploitent une version différente augmenterait d’autant. L’échange de données deviendrait alors une gageure.

Un serveur bancaire supportant l’ensemble des versions d’EBICS nécessiterait – au minimum – des efforts de maintenance considérables. Par ailleurs, l’utilisation de versions plus anciennes saperait toutes les améliorations apportées par les dernières moutures, notamment dans le domaine capital de la sécurité. Lors de l’élaboration des spécifications d’EBICS, l’on s’était d’ailleurs mis d’accord pour toujours utiliser la dernière version en date en supportant systématiquement la version précédente.

Des mises à jour sont ignorées – ce qui recèle des risques certains

Dans la pratique, les choses peuvent se révéler fort différentes. Parfois par méconnaissance, certains clients omettent d’implémenter la dernière version d’EBICS sur leur système. Certaines banques négligent d’informer leurs clients des changements et continuent de supporter les versions plus anciennes d’EBICS. La transparence s’estompe et le risque décrit précédemment augmente.

Par conséquent, nous recommandons aux institutons financières non seulement d’utiliser la dernière version d’EBICS, mais aussi de veiller à ce que leurs clients en fassent de même, le cas échéant en les informant à temps des mises à jour. Les institutions financières ne devraient plus supporter les anciennes versions, voire même opter pour une désactivation pure et simple. Les entreprises quant à elles devraient s’assurer de toujours utiliser la dernière version du logiciel EBICS et planifier régulièrement les mises à jour.

Il est donc important de conserver une vue d’ensemble des versions d’EBICS en service et de réduire les risques en ayant recours à des mises à jour régulières – en attendant 2016 et EBICS 2.6.

Michael Lembcke

«EBICS as a Service» – un modèle d’exploitation pour les petits et moyennes institutions financières

Le fait qu’EBICS finira par s’imposer en Suisse en tant que protocole de transactions bancaires ne fait plus guère de doute. Les plus grandes institutions financières et les principales banques cantonales proposent déjà une interface EBICS aux entreprises, ou elles sont en passe de le faire. La prochaine étape serait la mise en place d’une plateforme commune «EBICS as a Service», pour laquelle il reste cependant à trouver un exploitant.


Les avantages d’une communication point à point sécurisée, standardisée et bon marché sont évidents, raison pour laquelle les petites et moyennes institutions financières s’y intéressent de plus en plus. Au vu du nombre de clients susceptibles de demander une connexion EBICS à leur banque, certains décideurs estiment que le coût initial pour l’acquisition, l’installation et l’exploitation d’un produit EBICS est très élevé.

Et de telles réserves sont assurément fondées, la mise en œuvre d’un produit EBICS pouvant atteindre un montant de cinq à six chiffres – un poste considérable dans le budget de nombreuses banques de petite et moyenne taille. En Suisse, où l’on compte près d’une centaine d’institutions dans ce segment – comme les petites banques communales ou privées –, la question suivante est donc particulièrement pertinente : pourquoi n’existe-t-il encore aucun prestataire proposant «EBICS as a Service» sur le marché national? Les avantages d’une plateforme EBICS mutualisée semblent pourtant incontestables, et certains prestataires paraissent prédisposés à mettre en place une telle offre.

À l’instar des services d’externalisation proposés pour l’exploitation de plateformes bancaires, il serait alors possible d’implémenter un modèle EBICS multi-clients. Ce business case devient rentable dès lors qu’un petit nombre de banques y participe et se traduit par une situation gagnant-gagnant pour l’ensemble des acteurs. Le fournisseur d’une telle solution pourrait proposer une offre de services étendue et, grâce à la diffusion et à l’utilisation croissante du standard, amortir rapidement son investissement. Les clients, dans le cas présent les banques, pourraient proposer aux entreprises un accès à cette plateforme moyennant des coûts d’investissement et d’exploitation réduits, et ainsi faire jeu égal avec les grandes institutions financières.

Alors que manque-t-il? Un produit adéquat bien sûr, alliant capacité multi-clients et fonctionnalités opérationnelles optimisées pour une exploitation dans des centres de traitement de données, ainsi qu’un fournisseur innovant proposant des solutions informatiques dans le secteur bancaire et qui serait disposé à jouer un rôle de précurseur. Comme déjà évoqué, le marché suisse recèle quelques candidats potentiels, des exploitants de solutions Avaloq ou Finnova aux plateformes d’insourcing des grands instituts, en passant par les centres de traitement de données classiques.

L’avenir nous dira qui sera en mesure de s’adjuger ce rôle.

Carsten Miehling

Franc succès pour l’événement EBICS à Luxembourg

Le standard EBICS poursuit sa progression en Europe. C’est donc avec beaucoup d’intérêt que les experts dans le domaine des échanges de paiements et en informatique des banques luxembourgeoises se sont rencontrés le 28 janvier 2015 pour en savoir plus sur EBICS. Intitulé «EBICS – A New Communication Protocol for Payment Activities», l’événement était organisé par l’Association des Banques et Banquiers, Luxembourg (ABBL).


Axée sur l’intérêt potentiel d’EBICS pour le Luxembourg, la conférence a vu se succéder les intervenants et thèmes suivants.
  • Allocution de bienvenue, Serge Wagener, Banque et Caisse d’Epargne de l’Etat
  • EBICS at a Glance – Security, Use and Implementations, Hermann Fürstenau, PPI AG
  • EBICS – a chance to harmonise customer-to-bank communication standards for electronic banking in Europe, Axel Weiß, EBICS Chairman
  • EBICS Strategy of Deutsche Bank, Thomas Stosberg, Deutsche Bank
  • STEP2 and EBICS, Katja Heyder, EBA Clearing
Les intervenants ont entrepris de décrire EBICS du point de vue de la communication client-banque et des échanges interbancaires, en mettant notamment l’accent sur la sécurité des échanges de données via Internet. La signature électronique distribuée ainsi que les différences existant entre les versions française et allemande d’EBICS figuraient également au nombre des thèmes pertinents pour les experts luxembourgeois.

L’accès STEP2 à la plateforme pour les échanges de paiements via EBICS constituait un autre point particulièrement intéressant pour la communauté des banques du Grand-Duché, car celui-ci permet de réduire les coûts et de renforcer la fiabilité en fournissant un système de « secours ». Les différents scénarios de mise en œuvre de STEP2 et EBICS doivent être établis spécifiquement pour chaque banque. Cela dit, si un système de secours devait être exigé dans le cadre de mesures réglementaires – ce qui semble tout à fait possible à l’heure actuelle –, EBICS constitue la meilleure solution.

Certaines banques opèrent d’ores et déjà avec deux infrastructures différentes pour des raisons de sécurité, à savoir SWIFT et EBICS. De par la complémentarité topologique de leurs réseaux, EBICS et SWIFT se substituent idéalement l’un à l’autre en cas de défaillance. Bien souvent, les coûts sont également un facteur décisif pour l’utilisation d’EBICS.

Autre argument de taille pour les banques luxembourgeoises: le standard EBICS est une création commune de l’Allemagne et de la France. En outre, son développement et sa diffusion sont assurés par la société EBICS, entité particulièrement flexible basée à Bruxelles. La Suisse est en passe de rejoindre la société EBICS et le Luxembourg pourrait suivre, devenant ainsi le quatrième membre de cette organisation.

L’idée d’un «Global EBICS» revêt une importance stratégique pour certaines banques, comme l’ont montré sans ambiguïté les débats à Luxembourg. «Global EBICS» – ou GBICS – s’appuie sur un format ISO 20022 conforme à CGI (Common Global Implementation). CGI fait ici office de standard de format unique et GBICS de format de transport uniforme partout dans le monde. Autre question qui a suscité l’intérêt des participants à l’événement: existe-t-il un standard comparable à EBICS à l’échelle internationale, par exemple en Asie ou en Amérique? La réponse à cette question est clairement non. Lorsqu’ils existent, les standards concurrents ont une portée purement nationale et sont généralement très anciens. L’outil technique et bancaire que constitue EBICS est sans nul doute excellent. À ce titre, EBICS – ou plutôt GBICS – possède un réel potentiel pour s’imposer en tant que standard mondial.

Michael Lembcke

EBICS et les échanges banque-entreprise dans le cadre de SEPAmail™

A l’initiative de grandes banques françaises (BPCE, CM-CIC, Société Générale, BNP Paribas, Crédit Agricole), SEPAmail™ a été conçu afin de faciliter les échanges dématérialisés entre entités économiques de documents non comptables autour des paiements comme des factures, des mandats ou des avis, au moyen de flux. Cette messagerie sécurisée interbancaire permet ainsi de compléter les opérations de paiement traditionnelles (virement, prélèvement…) par de nouveaux services de paiements orientés sur les usages des clients.

Cela inclut:
  • Règlement de facture dématérialisée
  • Fiabilisation des IBAN et lutte contre la fraude sur IBAN
Pour toute information supplémentaire sur SEPAmail™ nous vous invitons à consulter le site www.sepamail.eu.
Conformément au modèle 4 coins sur lequel se fonde la norme SEPAmail™, les échanges se subdivisent en deux typologies:
  • les échanges interbancaires exclusivement fait en mode message (dénommés missives dans la terminologie SEPAmail™) : web service ou S/MIME
  • les échanges banque/entreprise pour lesquels les échanges de fichiers sont particulièrement adaptés.
C’est dans le cadre du canal échange de fichiers que PPI France s’est très tôt intéressée à SEPAmail™, en participant activement, dès Décembre 2012, à une expérimentation visant à valider l’adéquation d’EBICS pour le transport bidirectionnel de flux SEPAmail™.
L’expérimentation a notamment consisté à:
  • Transmettre une missive et un lot de missives de remises d’ordre au moyen du type d’ordre FUL,
  • Récupérer une missive et un lot de missives d’accusés de traitement de la remise d’un fichier de type pain.002, via le type d’ordre PSR,
  • Et télécharger un lot de missive de relevés d’opération au moyen du type d’ordre FDL.
Les paramétrages habituels ayant été effectués côté installation client et côté serveur banque (logiciels TRAVIC), les échanges ont pu être effectués, validant ainsi la possibilité et pour les banques et pour les clients d’utiliser leurs installations EBICS pour procéder aux échanges SEPAmail™.

Cette expérimentation nous a permis de faire quelques suggestions et notamment:
  • la rédaction d’un document de simplification du nommage des fichiers,
  • la rédaction d’un guide de mise en œuvre de SEPAmail™ avec EBICS à usage des banques, des entreprises et des prestataires.
Certains prestataires et Opérateurs de confiance ont d’ailleurs très rapidement compris l’intérêt à proposer une offre SEPAmail™ supportant le canal EBICS. C’est le cas notamment de GFI qui propose la première solution complète conforme à la norme pour ses clients banques ou entreprises.

«La stratégie de notre offre s’articule autour de trois principes fondamentaux:
  • simplicité: minimum d’impact sur le système d’information de nos clients
  • efficacité: optimisation du time to market
  • maitrise des coûts: minimiser les investissements initiaux des clients afin de faciliter la mise en place de l’écosystème
Dans ce cadre, l’utilisation du canal EBICS s’est imposée à nous comme une évidence. Ce canal garantit en effet les niveaux de sécurisation et de traçabilité nécessaires dans des échanges SEPAmail™ tout en s’appuyant sur des mécanismes connus et maitrisés par nos clients dans le cadre des échanges entre banque et entreprise.» nous précise Lionel Chemla, directeur de l’offre SEPAmail™ de Gfi.

Et tout comme EBICS qui est désormais largement utilisé non seulement en Allemagne et en France, mais aussi au Portugal, en Suisse, en Autriche et bientôt dans d’autres états européens, SEPAmail™, en s’adossant sur l’ISO20022, intéressera sans nul doute dans le futur des entités économiques européennes situés hors du territoire français…

Marc Dutech

Dans la série: «Comment améliorer EBICS», 3e partie – EBICS désormais aussi en ligne

Les exigences posées à l’e-banking par les entreprises concernent-elles vraiment exclusivement l’échange de données par l’intermédiaire de fichiers? Des opérations administratives en ligne ne sont-elles pas également souhaitées ? Sans quoi, comment expliquer pourquoi les petites sociétés utilisent souvent des solutions d’e-banking issues du domaine d’application des clients privés?


D’un point de vue historique, le protocole EBICS a été développé à partir du transfert de fichiers et se révèle particulièrement adapté pour l’échange rapide et sécurisé de fichiers volumineux entre les entreprises et les banques ainsi que dans le trafic interbancaire. Les fichiers à échanger sont, selon les opérations administratives, identifiés par des types d’ordre ou des paramètres de format, lesquels pilotent ensuite le processus correspondant.

Lors de la transmission de données via EBICS et une fois l’authentification de l’utilisateur effectuée avec succès, la liaison est maintenue ouverte uniquement le temps de la transmission des données. Le traitement en tant que tel est généralement réalisé hors ligne. Les résultats de ce traitement doivent ensuite être téléchargés par le biais d’une opération administrative séparée (PTK/HAC). De la même manière, les données à télécharger sur le serveur de la banque (p. ex. les informations relatives aux montants) sont régulièrement mises à disposition hors ligne. Ces données peuvent ensuite être téléchargées sous forme de fichier via EBICS.

Pour l’heure, le protocole EBICS ne permet pas encore l’enregistrement et l’authentification en ligne d’ordres de paiement ou la consultation en ligne d’informations sur les comptes. Ces fonctionnalités sont supportées par les portails web propriétaires dédiés aux opérations avec les clients privés et par les standards nationaux, par exemple HBCI/FinTS en Allemagne. Si une entreprise souhaite aujourd’hui exploiter à la fois les avantages des opérations administratives en ligne et d’EBICS en se conformant aux standards en vigueur, elle doit parfois mettre en œuvre plusieurs solutions nécessitant des identifications distinctes.

Il serait donc judicieux d’implémenter les processus en ligne adéquats dans le protocole EBICS, par exemple:
  • Information sur les soldes des comptes: le protocole EBICS pourrait permettre de fournir des informations en ligne sur les soldes actuels de comptes. Pour ce faire, la liaison serait maintenue ouverte dans EBICS le temps de l’interrogation. Les entreprises pourraient ainsi toujours consulter le solde actuel de leur compte.
  • Informations sur l’état et les résultats du traitement d’ordres transmis: Le client a besoin de connaître l’état de traitement de chaque ordre transmis. En combinaison avec la référence d’ordre client qui reste à introduire (cf. article du 18.12.2014), la mise en œuvre d’une requête en ligne permettant d’obtenir l’état d’un ordre unitaire simplifierait grandement le processus d’analyse pour l’entreprise. Cela permettrait en outre d’économiser bon nombre d’appels téléphoniques pour s’enquérir de l’état d’un ordre auprès de la banque.
Il existe bien sûr d’autres applications envisageables. Précisons cependant qu’il ne s’agit ici pas d’une concurrence avec d’autres standards et procédés existant sur le segment des clients privés. L’objectif est plutôt d’ajuster le protocole EBICS aux besoins des banques et des entreprises en matière d’e-banking, et ainsi de le conformer aux exigences futures.

Michael Lembcke

Dans la série «Comment améliorer EBICS», 2ième partie – de la délégation des autorisations avec EBICS et la Signature Electronique Distribuée (VEU)

Le présent article constitue la suite de la série consacrée aux améliorations envisageables d’EBICS initiée au mois de décembre. Il est dédié au problème suivant : lorsqu’un remettant émet un ordre de paiement via EBICS, les fonctions standard existant à l’heure actuelle ne lui permettent pas d’influer sur les autorisations ultérieures. Dans certains cas, il n’est possible de définir ces autorisations qu’au moment même de la présentation de l’ordre de paiement, et il serait alors utile de pouvoir déléguer lesdites autorisations au cas par cas.

Parmi les fonctionnalités actuelles d’EBICS, différents modèles de gestion des pouvoirs pour la présentation et l’exécution de fichiers d’ordre par les entreprises sont mis en œuvre par les serveurs bancaires. Dans les faits, ces modèles reposent toujours sur les classes de signature E, A, B et T, le nombre de signatures requises et les autorisations personnelles nécessaires pour les fichiers physiques. Par ailleurs, les établissements bancaires et les développeurs de logiciels ont au fil du temps étendu leurs modèles de gestion des pouvoirs, de sorte qu’ils peuvent aujourd’hui être appliqués à différents scénarios. Parmi ces extensions figurent entre autres:
  • Les autorisations relatives à une personne et à un ordre en combinaison avec les classes de signature, les types d’ordre (donc des cas commerciaux déterminés) et les comptes.
  • Différentes notions de limites, par exemple relatives aux montants, au nombre de transactions, à des périodes, et applicables par paliers aux personnes, comptes et/ou clients, et classes de signature.
  • Des notions de groupes en relation avec les classes de signature, par exemple pour définir les pouvoirs de personnes appartenant exclusivement à des groupes différents ou exclusivement au même groupe.
  • Des classes de signature propriétaires, tenant compte de critères propres pour l’autorisation.
  • Des procédures dédiées aux centres de calcul, dans lesquels les processus de présentation et d’autorisation des ordres de paiement sont traités séparément au niveau du client.
Tous ces modèles se révèlent relativement statiques. Quand un client EBICS soumet un ordre, ses possibilités d’influer sur la façon dont la banque traite la transaction sont limitées. Seules les données de base instaurées par la banque constituent la base de contrôle des droits, de la vérification du format et de l’autorisation. Lorsque dans le cadre d’EBICS la détermination desdroits est réalisable par la banque sans aucune équivoque, cette approche est généralement judicieuse et souhaitable. Cependant, EBICS ne permet pas d’appliquer un traitement spécifique aux ordres qui le nécessiteraient. Pour les ordres SEPA identiques de type CCT au crédit d’un compte déterminé, toutes les personnes autorisées à mettre en œuvre la VEU (Signature Electronique Distribuée) pour un compte et une type d’ordre donné sont également autorisées à donner l’ordre de l’exécuter.

Or, ne serait-il pas judicieux pour le client de pouvoir définir les personnes auxquelles il souhaite déléguer l’autorisation dès la présentation d’un ordre de paiement dans EBICS ? Bien entendu, ces personnes devraient alors déjà disposer auprès de la banque d’un niveau d’autorisation de base correspondant. L’avantage serait que les personnes non désignées, mais qui disposent du même niveau d’autorisation, ne reçoivent pas l’ordre pour la VEU et ne peuvent par conséquent pas le consulter. Ce modèle peut par exemple s’appliquer aux cas où un compte déterminé est utilisé tant pour les paiements de toutes sortes que pour le versement de salaires ou de rémunérations, et que les paiements ne disposent pas d’un identifiant de transaction (transaction ID) particuliere. Ce type d’identification diffère de toute manière d’un format et d’un pays à un autre. L’extension correspondante du standard EBICS permettrait donc de mettre en place une solution indépendante et viable du format.

Michael Lembcke