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

En savoir plus

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

En savoir plus

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

En savoir plus

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

En savoir plus

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

En savoir plus