Vous êtes client d'une banque et vous utilisez EBICS : la surveillance des communications en EBICS continuera-t-elle à fonctionner avec EBICS 3.0 ?

Depuis EBICS 2.5, les clients EBICS peuvent non seulement utiliser le compte-rendu en mode texte pour surveiller les processus et résultats EBICS mais aussi un compte-rendu basé sur XML. Ce dernier convient surtout pour des analyses automatisées. Pour télécharger le compte-rendu à partir du serveur EBICS, le client EBICS peut utiliser le type d'ordre PTK pour le compte-rendu en mode texte et le type d'ordre HAC pour le compte-rendu basé sur XML. Avec la version 3.0 d'EBICS, le compte-rendu en mode texte ne fait plus partie de la spécification. De plus, des modifications du compte-rendu HAC doivent être prises en compte pour l'analyse automatisée des résultats. Les versions devant être interopérables, ces modifications peuvent également avoir un impact sur les logiciels clients utilisant une version antérieure d’EBICS, quand le serveur bancaire supporte la version 3.0 d'EBICS.

Les concepteurs de logiciels et les utilisateurs doivent dès lors se préparer aux modifications des logiciels clients EBICS déjà aptes à analyser les comptes-rendus client automatiquement. D'abord, les logiciels clients EBICS devraient migrer du PTK au HAC afin de permettre des analyses automatisées. Ceux qui utilisent déjà le compte-rendu HAC doivent tenir compte du fait qu'avec EBICS 3.0, le résultat final est fourni de manière différente.

Jusqu'à présent, le flag de fin du HAC avec les identificateurs HAC ORDER_HAC_FINAL_POS et ORDER_HAC_FINAL_NEG indiquait le résultat positif ou négatif d’une remise. Avec EBICS 3.0, seul le flag de fin HAC ORDER_HAC_FINAL demeure dont le code raison précise le résultat de la remise. Le code final DS04 indique par exemple que l'ordre a été rejeté alors que le code DS05 informe que l'ordre a été remis avec succès et transmis aux systèmes bancaires. D'autres codes raison doivent être pris en compte.

Pour être sûr que votre surveillance EBICS continue à fournir des résultats exacts, je vous recommande donc d'utiliser le compte-rendu client HAC et d’analyser les codes raison. Ainsi, vous gardez le contrôle sur la communication EBICS avec votre banque.

Michael Lembcke

Migration vers EBICS 3.0 en France

La version 3.0 d’EBICS est entrée en vigueur en France le 27 novembre dernier. Deux mois plus tard il semble opportun de faire un état d’avancement de la migration vers cette nouvelle version.

Rappelons que les évolutions les plus importantes de cette version dite «d’harmonisation» sont: 


  • Une version EBICS uniforme dans tous les pays dans lesquels EBICS est déployé
  • Une identification uniforme des processus métier et des formats (aussi appelé BTF: Business Transaction Format)
  • Un format X.509 uniforme pour le dépôt de clé.


La date d’entrée en vigueur ne concerne que les banques et institutions financières françaises, sans qu’elle n’ait aucun caractère obligatoire pour les entreprises qui quant à elles sont libres de migrer à la date de leur choix.

Les grandes banques françaises ont lancé les chantiers de migration depuis plusieurs mois et la plupart d’entre elles sont désormais en position de proposer le canal EBICS 3.0 à leur clientèle. Pour celles qui ne le sont pas, les tests sont en cours de finalisation et par conséquent l’ouverture du canal EBICS 3.0 est imminente.

Il n’en va pas de même pour les banques de taille plus modestes car rares sont celles qui ont lancé leur projet de migration. Il est fort probable par conséquent que l’ouverture du canal EBICS 3.0 par ces établissements ne soit pas effectif avant quelques mois, voire même pas avant 2020.

Cette disparité ne devrait pas constituer un frein pour les entreprises désireuses de migrer prochainement vers EBICS 3.0 car en phase transitoire (plus ou moins longue) les banques ayant migré vers EBICS 3.0 continueront à supporter la version 2.4.2 en vigueur depuis l’introduction d’EBICS en France. Ceci afin de laisser le temps aux entreprises de procéder elles aussi à la mise à jour de leurs logiciels client.

Plus que cette disparité c’est, pour les entreprises, un manque d’appétence pour cette nouvelle version qui risque de faire durer la phase transitoire. Pour remédier à cela les banques vont pouvoir proposer à leur clientèle des services à valeur ajoutée mettant à profit les évolutions apportées par cette nouvelle version. Outre la simplification du paramétrage des transferts, l’une d’entre elles est la signature électronique disjointe. Elle permettra aux entreprises de signer les ordres de manière désynchronisée (alors que dans la version 2.4.2 la signature est systématiquement jointe à l’ordre à signer), contribuant ainsi à une plus grande mobilité.

Cela sera d’autant plus appréciable lorsque la dématérialisation des certificats X.509 sera devenue une réalité, rendant ainsi la signature sur mobile parfaitement opérante. Des experts travaillent sur ce sujet et des solutions efficientes devraient voir le jour d’ici quelques mois…


Marc Dutech


Comment améliorer EBICS, 10e partie – téléchargements EBICS avec date et heure configurables

Dans le domaine des paiements et en particulier depuis la mise en œuvre des paiements instantanés, il est de plus en plus important pour les clients des banques d'être tenus au courant des opérations intraday. Pour les logiciels clients entreprise cela pose également un nouveau défi relatif au protocole EBICS. En règle générale, les informations sur les écritures de paiements doivent être téléchargées du serveur bancaire par le client EBICS. Le téléchargement dit historique avec indication de la date est la méthode la plus adéquate lorsque les clients entrepris utilisent plusieurs clients EBICS. Cependant, du fait que le téléchargement historique par EBICS ne soit spécifié qu’'au jour près, il en résulte en pratique que des volumes importants de données sont souvent téléchargées plusieurs fois pendant la journée. En plus, les horodatages métier pour EBICS dépendent souvent du format de restitution ; ils sont au mieux précis au jour près, au pire ils n'existent même pas sur le serveur bancaire. La tâche des postes client est alors de filtrer automatiquement les données qui ont été téléchargées plusieurs fois. Cela signifie actuellement une charge additionnelle pour tous les systèmes concernés, tant du côté des clients que du côté des banques.

Il serait possible de remédier à cela en faisant évoluer les spécifications d’EBICS permettant de définir des téléchargements programmés

Le serveur EBICS supportera alors une variante supplémentaire du téléchargement historique. Contrairement au téléchargement historique EBICS standard actuellement en vigueur, seraient également pris en considération les heures de début et de fin. En outre, les dates et heures indiquées doivent toujours faire référence à celles de mise à disposition. Le serveur EBICS pourrait ainsi fournir toutes les écritures qui ont été fournies pendant la période de temps indiquée. Pour un traitement plus souple, il devrait être permis de n'indiquer que la date ou l’heure pour les demandes de téléchargement. Sans cette indication le téléchargement se déroulerait comme un téléchargement standard.

À mon avis, spécifier une telle solution uniforme dans le protocole EBICS pour tous ses utilisateurs affinerait les processus de téléchargement, réduirait la charge des systèmes. Elle allègerait et améliorerait considérablement les processus, surtout au vu du besoin croissant de disposer d’informations à jour. Les solutions propriétaires utilisées jusqu'ici dans les produits EBICS deviendraient alors superflues.

Michael Lembcke

EBICS et les discussions sur l'API – Un point de situation en Suisse


Depuis que SIX Interbank Clearing (SIC) est devenue membre officiel d'EBICS SCRL au printemps 2015 en tant que représentant de la place financière suisse, de nombreuses modifications ont eu lieu dans le domaine des interfaces de communication entre entreprises et banques (« Corporate Communication Interfaces »). Les interfaces électroniques font l’objet de discussion accrues, c’est la raison pour laquelle il semble que le temps soit venu de jeter un coup d'œil sur la situation actuelle.

Il va de soi qu’une telle exploration nécessite aussi d’aborder le sujet des API (interfaces de programmation applicative), car dans certaines instances de direction des banques, cet acronyme est proclamé comme étant la solution clé à la stratégie de numérisation. Les API sont-elles le potentiel pour rendre obsolètes les protocoles de transfert de fichiers de longue date comme EBICS, en particulier celles qui permettent le téléchargement les informations sur le compte ou les paiements ? Cette question se pose d'autant plus que les startups et les fintechs privilégient ces API allégées à EBICS, dont l'implémentation est plus complexe.

Afin de pouvoir répondre à cette question pour la Suisse, les lecteurs moins familiers avec la place financière suisse ont besoin d'informations de fonds actualisées. Il convient d'abord de noter que la Suisse, qui n'est pas membre de l'UE, n'est liée en aucun cas à la DSP2 (deuxième directive sur les services de paiements). Par conséquent, les institutions financières ne sont pas obligées d'offrir une API, ceci éliminant un élément moteur majeur. En outre, il n'existe aucune interface standardisée en Suisse pour la banque en ligne, comme c’est le cas pour l'Allemagne avec FinTS. Néanmoins le message positif de l'Union européenne a également été entendu en Suisse.

Avant d'entrer dans les détails du sujet brulant des initiatives des API très discutées en ce moment, reconnaissons une fois encore à quel point l’utilisation d'EBICS s’est largement répandue. Au cours des cinq dernières années à l’instar du modèle d'implémentation allemand, le protocole EBICS s'est imposé dans toutes les grandes institutions financières en tant que standard pour l'échange électronique des données avec les entreprises. La capacité du protocole à pouvoir transférer des volumes importants, ainsi que l'utilisation plus récente de la VEU (signature électronique disjointe), sont des fonctions très appréciées par les moyennes et grandes entreprises. Tous les fournisseurs de logiciels suisses renommés qui offrent des solutions de la banque en ligne proposent également EBICS.

Jusque-là tout va bien pourrait-on penser. Comme mentionné précédemment, la discussion sur les API bat son plein en Suisse et nous constatons en ce moment deux initiatives remarquables qui sont présentées ci-après. Pour que ce soit clair d’emblée, du point de vue de l'auteur ces initiatives ne remplacent pas EBICS, mais permettent plutôt aux institutions financières de compléter l'offre des interfaces qu’elles mettent à disposition d’un segment de clientèle spécifique (en règle générale les petites entreprises qui échangent les informations en bilatéral avec leur institution financière via le cloud).

« Corporate API », l'initiative de SIX et des institutions financières suisses semble actuellement très prometteuse. Sous ce nom, SIX conjointement avec les représentants des institutions financières et les éditeurs de logiciels développent non seulement un standard librement disponible pour tous, mais également la plateforme appropriée. Cette plateforme permet une participation facile à un écosystème émergent qui offrira des services dépassant largement le cadre de la DSP2 (AIS, PIS).

Les formats proposés par la « Corporate API » sont JSON et ISO 20022 XML. La variante JSON sera implémentée très facilement et rapidement et s'adresse aux fournisseurs de logiciels qui ne nécessitent pas la complexité des messages ISO 20022. La variante ISO 20022 XML prend en charge toute la panoplie des possibilités connues par la migration du transfert des paiements suisse. Les premiers tests avec les banques et fournisseurs pilotes seront effectués dès fin 2018.

Un autre projet d’actualité porte le nom de « Common API ». La « Common API » de SFTI (Swiss Fintech Innovations) s'appuie plus fortement sur la DSP2 et l'implémentation du Berlin Group. En comparaison avec la « Corporate API », les spécifications de la SFTI décrivent l'API en termes plus généraux et laissent le choix du groupe cible aux prestataires de services. Selon les informations de la SFTI, les fournisseurs d'applications bancaires sont également impliqués pour le développement de ce standard. SIX a accompagné le processus de développement des spécifications SFTI dès le début et poursuivra à l’avenir les résultats du groupe de travail de la SFTI. Il est donc bien possible, que les deux standards soient au moins partiellement compatibles.

La situation des éditeurs de logiciels en Suisse n'est pas très simple, car d'un côté EBICS est un protocole efficient et bien établi et de l'autre côté les nouvelles initiatives sont dans les starting-blocks. En fonction de la clientèle et du modèle commercial, les fournisseurs de solutions sont confrontés à la question de savoir quelle implémentation ils doivent proposer – voire même plusieurs. En outre, certaines institutions financières ont déjà publié leurs interfaces propriétaires (par exemple la Hypothekarbank Lenzburg, qui se présente comme une banque fintech très innovatrice). Si on élargit le champ d'application sur toute l'Europe, il s'ajoute également d'autres initiatives déjà connues comme par exemple « Berlin Group », « STET » ou « Open Banking ». Comme on pouvait s’y attendre, la place financière suisse n'a adopté aucun des standards existant, car le « Swiss Finish » est toujours d'actualité.

Carsten Miehling

Égalité pour EBICS – le cas d'utilisation des paiements instantanés de masse

Même si cela peut paraître étrange à première vue, en Allemagne les cas d’usage des paiements instantanés via le protocole de transfert de fichiers EBICS sont également spécifiés et font l’objet de discussions dans le cadre des échanges banque entreprise.
 
Dans ce cas, les utilisations se concentrent sur les échanges avec les clients entreprise. Ce sont en particulier les grandes entreprises qui souhaitent faire des virements de masse vers les institutions financières. C'est la raison pour laquelle, pour la remise de virements SEPA Credit Transfer par exemple, les membres de la DK ont convenu de l’envoi de paiements instantanés de masse basés sur le format XML ISO pain.001. Des opérations métier et des formats (par exemple le statut des paiements au format pain.002) sont également définis pour les informations de paiement retournées dans la chaîne des paiements du bénéficiaire ou des institutions financières. Les opérations métier et les modèles de format ainsi spécifiés seront valides en Allemagne à partir de novembre 2019 et pourront être offerts par les institutions financières de manière facultative.

Quelle est la particularité des paiements instantanés de masse?

La différence par rapport aux paiements instantanés via EBICS exécutés de manière synchrone, par exemple au « point de vente », réside dans le fait que l’envoi de ces paiements instantanés de masse n'est pas réellement considéré comme « instantané », mais comme une remise pour exécution immédiate (SCTINST).

L'institution financière exécutante du remettant scinde le fichier de masse en transactions unitaires et exécute les paiements en tant que SCTINST, à condition que le bénéficiaire du paiement soit joignable de cette façon. Ce n'est qu'à ce moment que les conditions pour SCTINST s'appliquent.
Dans le sens inverse, les données sont retournées au remettant par l'institution financière du remettant sur le canal EBICS. Dans ce cas cela signifie par défaut que les données sont mises à disposition par l’institution financière sur le serveur EBICS pour téléchargement (download). Pour les entreprises, l'institution financière joue uniquement le rôle passif habituel dans la relation entreprise – banque via EBICS. Pour cette raison, une notification active à l'envoyeur via EBICS n'est actuellement pas prévue pour les clients entreprise. 

Paiements instantanés de masse du fait de l’urgence? 

Les entreprises souhaitent utiliser ces nouvelles opérations métier afin de pouvoir remettre les paiements en masse et de manière simultanée, juste avant l’échéance. De cette façon, les fonds demeurent disponibles plus longtemps, jusqu'à l’échéance. Et lorsque le virement de masse est effectué, les paiements sont immédiatement garantis et exécutés.
Comme pour le bénéficiaire, une notification immédiate est également souhaitée en retour. Puisque le modèle de rôles EBICS ne prévoit pas de notification active du client par l'institution financière, différentes interfaces (API) et procédés (comme par e-mail push) sont actuellement discutés en Allemagne. 

Au final c’est pourtant relativement simple : pourquoi ne pas utiliser l'EBICS bilatéral tel qu'il l’est déjà dans les échanges de paiements interbancaires. Les deux parties, le client et l'institution financière, disposent des rôles initiateur – répondeur équivalents. Seul l’ajout, dans les applications clientes EBICS, de fonctionnalités de répondeur est nécessaire. Les entreprises remettant des paiements instantanés de masse pourraient ainsi recevoir automatiquement les données générées par ces processus. De telles applications sont déjà disponibles sur le marché. Les nouvelles opérations métier peuvent être intégralement gérées avec le standard existant dans des solutions existantes. Cela permettrait de mettre fin aux discussions chronophages et coûteuse sur des interfaces, des protocoles et des agréments supplémentaires.


Michael Lembcke

10e anniversaire d’EBICS – Histoire d’un succès annoncé

L’année 2008 a été marquée par une évolution de taille : chaque entreprise en Allemagne avait enfin la certitude de pouvoir entrer en contact avec toutes les banques et caisses d’épargne via Internet à l’aide d’un protocole homogène et sécurisé de la banque électronique pour envoyer des virements, instaurer des prélèvements et d’autres ordres ou encore télécharger des informations de comptes.

Particulièrement importante pour les entreprises, la multibancarité a été garantie par l’accord relatif aux transferts de données (DFÜ agreement) institué par le comité allemand pour le secteur bancaire (DK), qui imposait à l’ensemble des institutions financières du pays de supporter un nouveau protocole harmonisé dénommé EBICS (Electronic Banking Internet Communication Standard) pour l’échange des données avec les entreprises à partir du 1er janvier 2008. Bien que la réussite d’EBICS fût prévisible dès cette époque, la véritable success-story qui a suivi ne manque pas de surprendre.

Aujourd’hui, EBICS s’est imposé en tant que standard européen pour la transmission sécurisée de données, non seulement dans la banque électronique avec les entreprises, mais aussi pour les paiements interbancaires. Et il semble en bonne voie de réaliser le même exploit s’agissant de certaines évolutions actuelles, comme l’Instant Payments. Mais nous y reviendrons plus tard.

La genèse d’EBICS

Dans les faits, EBICS a plus de 10 ans, puisque sa naissance remonte au 18 juillet 2003. En ce jour, la société SIZ GmbH a présenté au ZKA («Zentraler Kredit Ausschuss» = ancienne dénomination de la DK), réuni en session extraordinaire, un protocole de banque électronique basé sur l’Internet dénommé WOP, avec pour objectif de faire de ce protocole (ou tout du moins de son concept), la base d’un nouveau standard Internet multibanques pour l’ensemble de l’industrie bancaire allemande. Le DFÜ agreement mis en place par le ZKA garantissait un protocole multibanques dans les affaires avec les entreprises depuis 1995 (BCS-FTAM). Or, ce protocole de transfert de fichiers reposait sur le standard OSI FTAM pour liaisons X.25 et ISDN, et se révélait dépassé à l’ère de l’Internet. Malgré quelques tentatives, il n’avait jusqu’alors pas été possible d’établir un standard IP commun. Il existait certes des solutions propres à certaines entreprises (comme MultiWeb et MCFT) ou même à des fédérations (BCS-FTP), mais il leur manquait l’essentiel : la multibancarité. En ce 18 juillet 2003, le temps d’un nouveau standard semblait venu. Au cours de cette fameuse session extraordinaire, la DK a spontanément décidé la création d’un groupe de travail, chargé de développer un standard de communication et de sécurité commun multibanques basé sur IP. Les principes fondamentaux de WOP ont ainsi donné naissance à EBICS. Le concept initial élaboré par le groupe de travail a servi de base à la spécification EBICS 1.0, qui a pu être présentée dès la mi-2005.

EBICS n’a donc pas été une révolution, mais le fruit d’un processus évolutif. Les composants de BCS-FTAM ayant fait leurs preuves pendant plus de 10 ans ont été conservés et seuls les éléments qui ne correspondaient plus aux nouvelles technologies ont été remodelés. Le concept des types d’ordres et donc le principe de neutralité aux applications ont ainsi été maintenus, tout comme l’autorisation de données de paiement par le biais d’une signature électronique (SE). La principale nouveauté d’EBICS résidait dans le passage d’un protocole X.25 ou ISDN (utilisés par BCS-FTAM) a un protocole de communication moderne basé sur XML et les standards Internet. La SE a par ailleurs été étendue à un concept de signature électronique disjointe (VEU), qui permettait aux entreprises d’autoriser des ordres – par exemple ceux transmis de manière automatisée de leur comptabilité à la banque – en tout lieu et à tout moment par le biais d’une SE, y compris à partir d’appareils mobiles.

Initiatrice du développement d’EBICS en 2003, la société SIZ GmbH n’a depuis cessé d’accompagner son évolution. En 2005, elle est ainsi devenue le centre de commande du comité allemand pour le secteur bancaire pour EBICS (annexe 1 du DFÜ agreement) ainsi que pour les formats de fichiers dans la banque électronique et les transactions financières (annexe 3 de l’accord).
Le groupe Sparkasse a été le premier regroupement d’instituts financiers en Allemagne à supporter EBICS, et ce, dès 2006. En 2007, il a été suivi par des institutions coopératives et publiques, ainsi que par certaines grandes banques et instituts privés.

EBICS: tunnel sécurisé pour réseaux exposés

Le développement d’EBICS repose en grande partie sur un concept de sécurité exhaustif. Les données de la banque électronique et des transactions financières nécessitant une protection particulière, les menaces envisageables ont été analysées pour établir les exigences et mesures de sécurité d’EBICS, celles-ci visant à garantir la confidentialité, l’intégrité et l’authenticité des données au sein de réseaux potentiellement non sécurisés (comme l’Internet) à l’aide de mécanismes cryptographiques. La confidentialité et l’intégrité des données sont ici garanties par un processus de chiffrement spécifique à EBICS, qui en plus du cryptage TLS à l’échelon du transport, offre un chiffrement de bout en bout des données sensibles dans la banque électronique. L’authenticité de la communication est vérifiée à l’aide d’une signature d’authentification accompagnant chaque paquet de données. L’autorisation des paiements s’effectue exclusivement par le biais de signatures électroniques, les modèles d’autorisation appliqués dépendant alors des conventions contractuelles établies entre la banque et ses clients (signatures individuelles ou multiples, classes de SE, plafonds, etc.). Le concept de sécurité fait depuis l’objet de vérifications régulières et EBICS est modifié en cas de besoin, par exemple pour adapter le protocole aux nouvelles menaces et/ou normes techniques. Pendant toutes ces années, EBICS s’est révélé un standard particulièrement sûr, et il n’a à ce jour subit aucune attaque qui aurait été couronnée de succès.

Les caractéristiques innovantes d’EBICS pour la transmission sécurisée de données sensibles:



2008: introduction en Allemagne

Le grand jour est arrivé le 1er janvier 2008, date à partir de laquelle toutes les banques et caisses d’épargne allemandes s’engageaient à supporter EBICS côté banque, conformément aux stipulations du DFÜ agreement de la DK. Et les entreprises ont adopté le protocole bien plus rapidement qu’anticipé: une grande partie d’entre elles a en effet opéré la migration de BCS-FTAM vers EBICS dès la première année de son introduction. Apparemment, les avantages étaient tout simplement trop évidents. Le fulgurant succès d’EBICS s’explique par plusieurs facteurs : une vitesse de transmission bien plus élevée par rapport à FTAM, une intégration simplifiée au sein des réseaux des entreprises et des banques grâce à l’utilisation de standards Internet et la mise en œuvre de nouvelles caractéristiques comme la signature électronique disjointe. Mais ce qui a vraiment été déterminant pour les entreprises, c’est la multibancarité du protocole, garantie dès le début par le DFÜ agreement de la DK. La transition a en outre été facilitée par des scénarios de migration directement implémentés dans le protocole, qui permettaient de convertir les clés pour la signature électronique de BCS-FTAM à EBICS pour ainsi dire en quelques clics.

EBICS s’établit en tant que protocole interbancaire

La conception sécurisée d’EBICS, permettant la transmission rapide et sure de grandes quantités de données, est rapidement devenue notoire. Il n’est donc guère surprenant que le protocole se soit également établi en tant que standard de communication pour les paiements interbancaires. C’est ici la Bundesbank allemande qui a fait office de précurseur, puisqu’elle a introduit EBICS dès 2008 en tant que protocole de communication pour son SEPA-Clearer (dans le cadre du système EMZ – le paiement de masse électronique). Aujourd’hui, EBICS est tout simplement devenu indispensable pour assurer les échanges sécurisés entre les banques et les organismes de clearing. Outre la Bundesbank, ABE Clearing mise également sur EBICS dans son système de paiement STEP2. Et le protocole fait depuis des années référence pour le clearing bilatéral entre les banques – également désigné «garage clearing».

Par ailleurs, EBICS a rapidement été utilisé pour la livraison de données par les centres informatiques prestataires et une directive ad hoc concernant le support d’EBICS dans ce domaine a été émise par la DK en 2009.

EBICS devient un standard international

En quête d’un nouveau protocole de communication sécurisé basé sur IP, l’industrie bancaire française (CFONB) a découvert l’existence d’EBICS dès la fin 2006. Un peu comme en Allemagne, il s’agissait de remplacer un standard vieillissant (ETEBAC) par un protocole capable de relever les défis futurs. Après examen minutieux des différentes alternatives, c’est EBICS qui s’est révélé le protocole le mieux adapté et un accord de coopération entre les industries bancaires françaises et allemandes a été conclu en 2008. EBICS SCRL, la société européenne EBICS, a été fondée sous droit belge à Bruxelles à l’été 2010. De nos jours, EBICS est largement utilisé en France et y connaît tout autant de succès qu’en Allemagne. Après la création de la société EBICS, SIZ est devenu le bureau technique officiel (centre de commande EBICS européen) et coordonne depuis l’EBICS Working Group – la commission chargée du développement d’EBICS.

L’introduction d’EBICS en France a cependant été synonyme d’apparition de deux « dialectes » différents dans les deux pays. Adoptant une approche particulièrement pragmatique, il a en effet été constaté que des exigences différentes dans les deux pays allaient nécessairement mener à la naissance de différentes variantes du standard EBICS. Ces divergences concernent notamment la représentation des opérations métier, identifiés en Allemagne par des classes de type d’ordre à trois chiffres et en France par des paramètres de format. Mais il existe aussi d’autres distinctions, comme l’utilisation en France de clés cryptographiques au standard X.509, alors qu’en Allemagne, l’on favorise toujours un format propriétaire repris de BCS-FTAM. Si l’on «parle» EBICS dans les deux pays, la compatibilité transfrontalière s’est révélée compliquée – l’on parlait et l’on parle toujours deux dialectes différents.

Cette lacune est devenue encore plus évidente avec l’adhésion d’un autre pays à la société EBICS en 2015 – la Suisse. Pour cette dernière, le dilemme consistait à choisir lequel des deux dialectes elle devait adopter, ou s’il était préférable d’opter pour une troisième variante helvétique.

Il était évident que l’existence de différents dialectes d’EBICS ne favorisait guère la diffusion souhaitée du standard en Europe. La solution ne pouvait être autre qu’une harmonisation, qui a fini par être lancée avec la nouvelle version EBICS V3.0. Celle-ci a notamment mené à l’introduction des BTF («Business Transaction and Formats») une nomenclature porteuse d’avenir, flexible et surtout homogène des opérations métier dans EBICS. D’autres harmonisations importantes ont par la suite été apportées à EBICS, faisant du protocole un standard unique à l’échelle internationale. Pour les paiements électroniques, il est en effet crucial que les différents partenaires puissent communiquer, se comprendre et se faire confiance. La compréhension est notamment garantie par des formats de données SEPA harmonisés et la nomenclature unique des BTF dans EBICS. La confiance quant à elle repose sur EBICS en tant que standard de communication et de sécurité commun. EBICS V3.0 est d’ores et déjà validé et son introduction pourra commencer à l’automne 2018. En Allemagne, le DFÜ agreement prévoit que la version sera obligatoire pour tous les instituts de la DK à partir de 2021.

10 ans d’EBICS: rétrospective et perspectives

Aujourd’hui, nous pouvons revenir sur 10 ans d’EBICS en Allemagne. Ce qui a commencé comme tentative de fédérer différentes évolutions incompatibles de banque électronique en Allemagne et de garantir la multibancarité pour les entreprises à l’ère de l’Internet s’est finalement mué en véritable success-story, s’affranchissant même des frontières nationales. En tant que standard sécurisé pour l’échange de données, EBICS est réputé dans le monde entier, et il est également utilisé dans des pays qui n’ont pas (encore) adhéré à la société EBICS. Désormais, EBICS est non seulement un protocole assurant la communication entre les banques et leurs clients, mais aussi un standard établi pour les paiements interbancaires. Et il semble certain qu’il jouera un rôle important aussi bien pour la remise d’Instant Payments que pour leur clearing.

Mais quelles sont les raisons de ce succès ? Personnellement, je pense que les points suivants sont déterminants:
  • La neutralité aux applications
    EBICS est un standard générique, capable de transmettre les données les plus diverses, puisque sa modélisation n’intègre ni formats ni spécifications bancaires spécifiques. Il peut ainsi être utilisé dans différents pays et scénarios d'application, en toute simplicité.
  • La sécurité
    EBICS combine plusieurs procédés cryptographiques indépendants pour garantir la confidentialité des données, authentifier les partenaires et la communication ainsi que pour autoriser les ordres, faisant de lui un tunnel sécurisé pour réseaux exposés.
  • La multibancarité
    EBICS est un protocole multibanques, en Allemagne comme en France. En Allemagne, la multibancarité est garantie par le DFÜ agreement institué par la DK.
  • L’adaptabilité
    En tant que standard ouvert, l’architecture d’EBICS peut être adaptée aux exigences les plus diverses. Et la société EBICS veille à la pérennité de son développement.
EBICS peut déjà s’enorgueillir d’une longue histoire, qui remonte au-delà des 10 ans écoulés depuis son introduction obligatoire en Allemagne. Et cette histoire est loin d’être terminée! En tant que standard de communication ouvert et sécurisé, EBICS est taillé pour le futur. La certitude que les décisions fondamentales qui ont présidé au développement d’EBICS restent d’actualité et que la flexibilité du protocole lui permet de s’adapter à de nouvelles exigences a en effet de quoi susciter l’optimisme – EBICS restera un élément essentiel pour les paiements électroniques en Europe.

Dieter Schweisfurth

Responsable Electronic Banking
SIZ GmbH

EBICS et «Private Banking» – des cas d’utilisation au-delà des transactions financières



EBICS est généralement considéré comme un protocole de transfert sécurisé pour l'échange des fichiers de paiement (ordres et relevés). Pour les clients entreprises en particulier il s’agit certainement du protocole le plus utilisé. J'aimerais profiter de l'occasion pour vous présenter un cas d'utilisation très actuel en Suisse: EBICS dans le secteur du Private Banking.


Les banques privées situées en Suisse font face à une situation toujours plus difficile et se voient confrontées à des exigences pressantes venant de tous côtés. La réglementation, la pression sur les marges, des clients mieux informés, l’éclatement de la chaîne de valeur et la numérisation ne sont que quelques sujets parmi ceux qui sont inscrits dans les agendas des directions des banques privées. Dans le domaine de l'automation, nous observons en ce moment une initiative remarquable qui prévoit l'utilisation d'EBICS en tant qu'interface pour les opérations boursières.

À l'initiative de grands investisseurs institutionnels et de gérants de fortune professionnels qui, de leur côté ont également un intérêt à augmenter le niveau d'automatisation, il y a une recrudescence des types de transaction EBICS, pour les opérations boursières. Il s'agit typiquement des types d'ordre pour la réception et le traitement d’ordres boursiers (upload) ainsi que des confirmations d'ordre, des factures et des relevés de dépôt (download). Les formats utilisés sont SWIFT (MT5xx) et PDF. Leur mise en œuvre est effectuée avec des types  d'ordre spécifiques à l'institution financière (XYZ).

Lorsqu'on examine l’intégralité de la chaîne de valeur d'une transaction boursière, il est possible de l'effectuer de manière complètement automatisée. Le système de gestion du portefeuille du gérant de fonds détecte un déséquilibre entre la stratégie d'investissement et le portefeuille du client et génère l'ordre boursier pour la réaffectation. Grâce aux standards EBICS et SWIFT (par exemple MT502), l'ordre est déclenché automatiquement auprès de l'institution financière et la confirmation sera, elle aussi, envoyée via EBICS (par exemple MT509). Cette automatisation réduit de manière significative et de toute part les travaux de traitement de l'ordre. En outre, le taux d'erreur est significativement minimisé comparé aux processus exécutés manuellement à ce jour.

En résumé, on constate que des banques privées innovatrices offrent dès à présent EBICS à leurs clients ou ont prévu de lancer prochainement des offres sur le marché. En raison du fait que traditionnellement les transactions financières jouent en règle générale un rôle moins décisif dans le secteur des banques privées que dans celui des banques universelles, l'utilisation d'EBICS vise plus les transactions boursières et le reporting sur le relevé d’actifs. De cela découle une situation win-win car les gérants de fonds et les investisseurs institutionnels, eux aussi, aspirent à une plus grande automatisation. L’idéal serait que les instances de standardisation définissent dès que possible des types d'ordre et des formats à la fois universels et uniformes (ou à partir d’EBICS 3.0 de nouvelles spécifications BTF).

Carsten Miehling