É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

EBICS 3.0 avec BTF ouvre la voie

Le trafic des paiements européens s’harmonise grâce à SEPA et EBICS, il en va de même pour les différentes variantes d’EBICS grâce à EBICS 3.0. Le concept de ce processus s’appelle BTF (Business Transaction Format). BTF uniformise la description des formats en Allemagne, en France en Suisse. Cette harmonisation ouvre la voie à une communauté EBICS en plein essor.

La nouvelle spécification d’EBICS 3.0 entrera en vigueur dès le 27 novembre 2018. Les dates de lancement pourront quant à elles différer pour chaque pays. EBICS 3.0 apportera les évolutions suivantes:
  • Une version EBICS uniforme dans les trois pays EBICS
  • Une identification uniforme des processus métier et des formats (BTF)
  • Un format X.509 uniforme pour le dépôt de clé.
Avec cela, la compatibilité des variantes EBICS est garantie.

Fonctionnalités facultatives

Jusqu’à présent, toutes les fonctionnalités d’EBICS n’étaient pas supportées dans tous les pays, désormais grâce à EBICS 3.0, les banques peuvent offrir à leurs clients toutes ces fonctionnalités individuellement.

Celles-ci comprennent:
  • Certificats
    Des certificats signés par une Autorité de Certification
    Des certificats auto-signés
  • Le modèle d’autorisation
    Des classes de signature T, A, B et E allemandes
    Des classes de signature T, TS françaises
    La suppression de l’autorisation par fax
  • Signature électronique distribuée (VEU en Allemand)
    L’utilisation de la VEU est obligatoire en Allemagne, optionnelle ailleurs.
Innovations

EBICS 3.0 comprend des innovations qui devraient être prises en considération lors de la mise en service:
  • Mapping
    L’adaptation des paramètres de format et des types d’ordre aux standards BTF est facilitée par une description générale des correspondances (Mappings). Ces correspondances pour les types d’ordre et des paramètres de format sont définies à l’échelle du pays, elles devront être appliquées par les utilisateurs d’EBICS. Pendant la période transitoire il pourrait subsister des variances : la banque A supporte déjà BTF alors que la banque B ne supporte que EBICS 2.x
  • Contrôle étendu
    Grâce à BTF, le client EBICS peut d’ores et déjà contrôler le serveur bancaire. Jusqu’à maintenant seul le serveur bancaire contrôlait les processus mais avec le contrôle par le client un nouveau chapitre voit le jour dans le déroulement des processus. L’utilisateur EBICS peut décider par exemple si son ordre va directement à la VEU ou si l’autorisation doit être vérifiée. La spécification EBICS définit l’action à effectuer en cas de divergences entre la spécification BTF et les droits sur le serveur bancaire.
  • Protocole uniforme
    Le compte-rendu client si stratégique dans la spécification EBICS 3.0 est le HAC qui se substitue à l’ancien PTK basé en mode texte. Le compte-rendu HAC étant en XML il contribue à une plus grande interopérabilité inter-applications. Pendant la période transitoire PTK et HAC coexisteront, s’il y a l’utilisation de plusieurs versions d’EBICS. Conformément à la spécification EBICS 3.0 les ordres BTF ne seront plus délivrés avec l’ancien PTK. Cependant pour ceux qui le souhaitent des extensions d’utilisation du format PTK pourront être effectuées au cas par cas.
EBICS 3.0 prépare le terrain pour une communauté EBICS en plein essor

EBICS 3.0 européanise l’utilisation d’EBICS. C’est une bonne chose car les banques peuvent ainsi gagner de nouveaux marchés et clients. Le client bénéficie de nouvelles possibilités grâce à une plus grande flexibilité. Désormais, EBICS utilise exclusivement des standards établis.

Les interfaces existantes et les contrats peuvent rester quasiment inchangés. Le BTF peut être configuré en arrière-plan. Concernant les serveurs bancaires et clients EBICS les standards métier demeurent toujours une priorité grâce aux spécifications d’EBICS 3.0 et aux mappings par défaut.
La promotion d’EBICS dans de nouveaux marchés et pays a été énormément facilitée grâce à EBICS 3.0. Ses avantages sont évidents, raison pour laquelle sa mise en service à court terme dans les pays dans lesquels EBICS est déjà en vigueur ne peut qu’être recommandée.

Michael Lembcke

La version 3.0 d’EBICS est née

Le 19 mai dernier s’est déroulé à l’auditorium de la Fédération Bancaire Française un atelier thématique du CFONB ayant pour objet la présentation de la version 3.0 du protocole EBICS.
Plus de 120 personnes provenant d’horizons divers - banques, éditeurs, entreprises, …- ont assisté à cet évènement au cours duquel plusieurs intervenants ont exposé les grandes lignes de cette nouvelle version.


Après un rappel de la gouvernance et des missions de la société EBICS Scrl (www.ebics.org), quelques date clés dans la vie d’EBICS ont été énoncées. Elles nous ont rappelé que ce standard a largement dépassé l’âge de raison puisque voilà 12 ans que son implémentation a débuté en Allemagne et plus de 7 ans qu’il a été adopté en France, avant que les institutions financières Suisses ne suivent la voie en 2015.  Une diapositive a par ailleurs montré la propagation actuelle d’EBICS qui s’étend de la péninsule Ibérique à la mer Baltique et de l’Irlande à l’Italie, avec toutefois des taux d’utilisation contrastés si l’on exclut l’Allemagne, la France, la Suisse et le Portugal.

Les raisons du succès d’EBICS dans ces quatre pays ont été abordées (de nombreux articles à ce sujet peuvent d’ailleurs être consultés dans ce blog) ainsi que les freins à un déploiement paneuropéen rapide qui sont essentiellement:
  • des divergences dans l’identification des flux entre les variantes Allemandes, Suisses et Françaises
  • l’utilisation de certificats X 509 en France et de bi-clés en Allemagne
  • la mise en œuvre de la Signature électronique distribuée en Allemagne et en Suisse mais pas en France
S’en est suivie une description des changements majeurs apportés par la version 3.0 en termes d’harmonisation par l’intégration du concept BTF (Business Transaction Format), le support commun des certificats X 509 et la généralisation possible de la Signature Electronique Distribuée. Des informations plus amplement détaillées figurent sur le site de la société EBICS Scrl.

Le deuxième acte de cet atelier a consisté en la tenue d’une table ronde ayant pour thème: Pourquoi une version EBICS harmonisée?

Ce fut l’occasion pour des acteurs dans le domaine d’EBICS d’évoquer et de débattre avec l’assistance des sujets suivants:
  • avantages d’EBICS mais également contraintes des versions 2.x dues au manque d’harmonisation
  • attentes par rapport à la nouvelle version et bénéfices apportés par l’harmonisation ,
  • opportunités d’extension géographique, y compris vers d’autres continents. L’Afrique a notamment été citée car d’ores et déjà certaines banques ont ouvert des services EBICS dans un certain nombre de pays francophones
  • possibilités d’utilisation d’EBICS au-delà de la relation Entreprise-Banque : l’utilisation d’EBICS pour STEP2 et RT1 (Instant Payment) avec EBA Clearing a notamment été mentionné
  • modalités de migration
  • évolutions futures du protocole en cours de réflexion ou pouvant être mises à l’ordre du jour, telles que la généralisation des certificats d’AC et la possibilité d’utiliser des certificats non stockés sur des dispositifs physiques afin de simplifier l’industrialisation de solutions de signature EBICS sur mobile
  • utilisation actuelle de la Signature Electronique Distribuée en Allemagne et en Suisse et bénéfices qui pourraient découler de son utilisation en France
Cet évènement a donc officialisé la naissance de la version 3.0. Son démarrage sera effectif en Novembre 2018, date à laquelle toutes les banques devront la proposer en complément des versions 2.x en vigueur dans les différentes communautés.

Les entreprises n’ont en ce qui les concerne aucune obligation de migrer à cette date, il n’est pas prévu de migration des version 2.x vers la versions 3.0 en mode «big-bang». Quant aux nouvelles communautés elles pourront d’emblée utiliser cette version.

Voilà donc du travail en perspective pour les Editeurs et les Banques, pour les y aider un guide d’Implémentation sera mis à disposition sur le site d’EBICS Scrl et du CFONB en Juillet 2017.
Etant souvent amené à présenter d’EBICS dans divers pays d’Europe et même au-delà, je considère que cette harmonisation va grandement faciliter le travail de promotion et je suis convaincu qu’elle est la clé du succès pour qu’enfin la première lettre d’EBICS signifie «European».

Et si, grâce aux évolutions en cours d’étude, la prochaine étape était le Worldwide EBICS ?...

Marc Dutech

EBA CLEARING présente EBICS en tant qu’option de connexion additionnelle pour son système d’Instant Payment

Les futurs participants au service EBA Clearing peuvent utiliser SIANet ou EBICS à partir de novembre 2017, pour se connecter à la nouvelle infrastructure de paiement en temps réel, s'étendant à l'échelle européenne – d'autres options pourront suivre ultérieurement.

EBA CLEARING a annoncé ce jour que les futurs participants au service de l'infrastructure des Instant Payments à l'échelle européenne seront prochainement en mesure d'utiliser, en plus de SIANet, l'Electronic Banking Internet Communication Standard (EBICS), pour échanger des messages de transaction avec la plate-forme. L'entreprise présentera EBICS comme option de connectivité additionnelle à partir du lancement de ce service en novembre 2017. Cette option sera désormais disponible dans son environnement test à partir de juin 2017.


Cliquez ici pour lire le communiqué de presse entier du 09 mars 2017: Communiqué de presse EBA CLEARING

Michael Lembcke

Comment améliorer EBICS, 9e partie – EBICS convient aux transferts de données de fichiers de toutes tailles – Oui, mais …

SEPA modifie lui aussi le comportement des dates au sein des opérations de paiement. En raison de nouveaux processus, les fichiers échangés entre les clients et les banques ainsi que les fichiers d’échanges bilatéraux deviennent de plus en plus volumineux. Lors des échanges banque vers client en particulier, la fonction de téléchargement destinée à la réception de données via EBICS (ex.: relevés de compte) joue un rôle important. Et tout au moins sur ce plan, une optimisation semble s’imposer. Pour différentes raisons, le téléchargement s’avère difficile dans le cas de fichiers particulièrement volumineux.


Afin de pouvoir décrire le problème de manière plus précise, il convient, tout d’abord, d’examiner le protocole EBICS plus en détail. Lors d’un téléchargement de données (downloads) via EBICS en réponse à une requête client, celles-ci sont toujours segmentées. Lorsqu’il reçoit une requête, le Client EBICS dépose dans un seul fichier physique toutes les données à télécharger.

Lors du processus de téléchargement d’EBICS, le serveur EBICS, après réception d’un ordre de téléchargement, détermine d’abord le nombre de segments qui permettront de transmettre le fichier à transférer. Cette information est délivrée au Client avec le premier segment. Elle est obligatoire dans EBICS. Ensuite, le Client récupère successivement chaque segment de manière séquentielle et enregistre le fichier.

L’opération de concaténation du premier segment et avec tous les suivants sur le serveur EBICS peut, à elle seule, prendre un certain temps selon la taille et le type du fichier (ex. : archive ZIP). Le fichier complet doit d’abord être compressé et chiffré pour que la quantité exacte de segments puisse être indiquée au Client EBICS dans la première réponse EBICS. En cas de grandes quantités de données, un timeout et donc une coupure de la connexion EBICS peut se produire avant que le Client ne reçoive, dans la phase d’initialisation, une réponse indiquant le nombre de segments.

Là est le problème. À l’avenir, il faudra donc pouvoir accélérer la réponse à la requête d’initialisation EBICS.

À l’heure actuelle, la nombre de segments indiqué au Client dans le premier segment doit être exact pour permettre le démarrage du transfert. Pourtant, selon la spécification EBICS 2.5 (voir chapitre 7.2 Mise en œuvre dans les messages EBICS, page 159), le Client EBICS devrait se montrer tolérant si le nombre de segments indiqué est faux. Dans un tel cas, le Client EBICS devrait acquitter la transaction en cours, même si le serveur EBICS délivre un nombre de segments inférieur à celui indiqué dans la réponse initiale. Pour que le serveur EBICS, en cas de fichiers de grande taille, envoie plus rapidement une réponse au Client et de façon à empêcher un timeout, il devrait être possible d’estimer la quantité de segments et de délivrer cette estimation.

Fondamentalement, une extension de la spécification EBICS avec les deux solutions partielles suivantes serait souhaitable.

Le Client EBICS déclenche un téléchargement de taille indéterminée pour éviter un timeout en cas de grande quantité de données

Dans sa réponse, le serveur bancaire indique, en même temps que le premier segment, une quantité de segments des données attendues. S’il s’agit de données permettant une concaténation rapide, le serveur bancaire peut indiquer le nombre exact de segments comme c’est le cas jusqu’à maintenant. Mais s’il s’agit d’une grande quantité de données demandant éventuellement un temps de préparation plus long (ex: ZIP), il serait possible d’indiquer un nombre approximatif de segments.
Dans tous les cas, le Client EBICS devrait récupérer des segments jusqu’à ce qu’il ait reçu le message de fin.

Afin d’éviter les timeouts pendant la phase de collecte et de préparation du serveur bancaire EBICS, ce dernier devrait également, lors de la récupération d’un segment suivant, pouvoir transmettre une valeur indiquant qu’il n’a pas encore terminé la concaténation des données. Le Client EBICS pourrait redemander le segment souhaité jusqu’à ce qu’il l’ait reçu.

Limitation facultative de la quantité de données téléchargeables par le Client EBICS pour éviter les fichiers trop volumineux

Cependant, les problèmes de téléchargement de grandes quantités de données peuvent également résulter de facteurs indépendants du serveur EBICS ou de son opérateur. Les difficultés peuvent reposer dans la conception du système du Client ou dans l’infrastructure. Dans ce cas, il peut s’avérer utile de pouvoir limiter, côté client, la quantité de données téléchargeables au-delà des possibilités actuelles (téléchargement historique).

Il serait par exemple souhaitable que le client EBICS puisse déclencher un téléchargement en indiquant une taille maximale. On pourrait envisager un nouveau paramètre optionnel portant sur la taille des fichiers téléchargés. Lors du téléchargement, le serveur bancaire EBICS livrerait toujours des blocs de données complets (ex.: relevé de compte) et à minima un dans son intégralité. La limite de taille devrait toujours être considérée comme une valeur indicative que le serveur bancaire a le droit de dépasser. Il y aurait ainsi, outre le téléchargement historique, une autre possibilité de choisir soi-même la taille des fichiers de relevés.

Grâce à ces deux extensions, EBICS serait bien armé pour l’avenir et pour des volumes de données en augmentation.

Michael Lembcke