Les Éditeurs de logiciels et l’Institution financière font la promotion d’EBICS en Suisse

Depuis 2013, les grandes banques suisses proposent le standard de communication EBICS à leurs entreprises clientes. Depuis mai 2015, la Suisse est membre officiel de la société EBICS ; celle-ci s’est fixé comme objectif de propager et entretenir ce standard dans l’ensemble de l’Europe et au-delà. Afin de sceller définitivement le succès d’EBICS, le plus grand fabricant d’EBICS et la banque majeure Credit Suisse ont formé un groupe de travail visant à promouvoir EBICS en Suisse (AFES). Les éditeurs de logiciels suisses profitent d’une campagne qui leur facilite l’introduction d’EBICS.


Les transmissions d’ordres de paiement ou les demandes de relevés de compte électroniques sont typiquement des transactions EBICS. Surtout dans les cas de multibancarisation, EBICS est très utilisé, une seule identification permettant aux sociétés d’accéder à différentes banques. Au cours des dernières années, de plus en plus de petites et moyennes banques suisses ont adopté le protocole EBICS et les interfaces propriétaires disparaissent du marché, lentement mais sûrement. Cette tendance est encore renforcée par les cas de fraudes sur Internet dont certaines firmes ont été victimes ces derniers temps : en effet, le mécanisme EBICS de la signature électronique distribuée (SED) réduit nettement le risque d’attaque.

L’initiative AFES fournit aux fabricants intéressés un pack de démarrage contenant le module EBICS-Kernel éprouvé de PPI, sous forme de bibliothèque logicielle (code Java ou code C) et à des conditions très intéressantes. Dès que le modèle de maintenance et un pack onboarding (au choix, avec accès à un serveur test EBICS) sont convenus, le module peut être activé. Credit Suisse joue le rôle d’intermédiaire et met son infrastructure à disposition pour à des fins de formation. Il en résulte une situation gagnante pour tous les acteurs et la place financière suisse profite de l’uniformisation attendue des interfaces de corporate banking.

Les initiateurs espèrent une propagation plus rapide du standard en Suisse. Tous en bénéficient, même les institutions financières étrangères situées en Europe qui proposent déjà EBICS comme interface. L’expérience a montré que la standardisation est la base pour davantage de concurrence et que ce sont les clients bancaires qui en profitent le plus. C’est ce que montrent les discussions actuellement menées en Europe selon lesquelles les banques seraient à l’avenir obligées de fournir des interfaces ouvertes. Dans ce contexte, EBICS est assurément une composante importante et il est certain que d’autres banques et éditeurs de logiciels lanceront aussi des initiatives communes.
Pour en savoir plus sur l’initiative: www.ebics-initiative.ch.

Carsten Miehling

En savoir plus

Les paiements instantanés au cœur du SIBOS

Cette année, le SIBOS a été organisé à Genève, à deux pas de l’aéroport et de ses avions s’élançant à pleine vitesse vers le ciel. Les paiements instantanés – qui connaissent un décollage tout aussi vigoureux – figuraient parmi les thèmes centraux de l’édition 2016 du salon. Les préparatifs en vue de leur introduction vont bon train.


Les paiements instantanés sont sans doute une technologie disruptive, qui va détourner quantité d’opérations d’autres méthodes de paiements, comme de paiements de masse, qui se déroulent aujourd’hui via EBICS, ou encore les paiements par carte (cartes de débit et paiements par carte au point de vente). En outre, l’on s’attend à une augmentation du volume de paiements instantanés effectués par le biais de l’Internet – une attaque en règle contre PayPal et consorts?

Ce qui à première vue semble anodin peut bouleverser le monde des opérations de paiement. Les paiements instantanés ont été qualifiés de «nouvelle normalité» à l’occasion du SIBOS, alors que cette technologie n’a pas encore vraiment pris son essor en Europe. Cela démontre tout le potentiel qui lui est prêté et les «nouveaux» acteurs d’hier (tels que PayPal et autres), pourraient bien devenir les perdants de demain.

Pour l’heure, les solutions de paiement instantané sont purement nationales. Et c’est compréhensible, puisque la majeure partie des volumes de paiements ainsi traités reste très limitée géographiquement. Mais les choses changent et un système de paiement instantané fonctionnant à l’échelle européenne pourrait donner naissance à une pléthore de nouveaux services. Les banques joueraient ici un rôle plus important que lors de paiements via carte de crédit ou PayPal. Cela leur permettrait d’affirmer leur ambition d’être leader dans le domaine des opérations de paiement, et peut-être même de rattraper un certain retard.

La limite de 15 000 € par transaction instantanée va rapidement être augmentée et l’on évoque déjà des montants proches du demi-million. Les groupes bancaires européens sont d’ores et déjà prêts à travailler avec de tels montants, ce qui pourrait également intéresser les entreprises. Biens industriels, prestations de services et autres marchandises sont aujourd’hui réglés «à l’ancienne», ce qui implique un coût élevé et des délais assez longs. Les paiements instantanés pourraient changer la donne. Bien sûr, un paiement instantané pourra nécessiter quelques secondes, voire quelques minutes de plus si le montant dépasse par exemple le million ou si des vérifications d’embargo, de lutte contre le blanchiment d’argent ou de règlement sont exécutées en parallèle. Ici encore, cela pourrait se traduire par des changements fondamentaux et même disruptifs.

À propos, la DSP II ne couvre pas les paiements instantanés. Quelle opportunité manquée! La BCE n’a semble-t-il pas osé faire le pas vers un système européen de paiement instantané.

L’interopérabilité avec les solutions nationales reste donc à clarifier. La DPS III, déjà annoncée dans la deuxième mouture du texte, permettra peut-être d’établir le cadre légal nécessaire. En attendant, l’approche reste purement facultative et les répercussions – également sur les opérations de paiements de masse via EBICS – demeurent floues. Mais une chose est sûre: l’européanisation des paiements instantanés recèle des opportunités. Et il s’agit de les saisir.

Michael Lembcke

En savoir plus

EBICS et DSP2: comment vont-ils ensemble?

La Directive sur les services de paiement DSP (ou PSD pour Payment Services Directive) adoptée par le Parlement européen fournit le cadre juridique nécessaire à la mise en place d’un marché unique des paiements dans l’ensemble de l’Union européenne. La version actuelle, la DSP2, a été publiée le 23 décembre 2015 au Journal Officiel de l’Union européenne et devra être transposée dans les droits nationaux d’ici le 13 janvier 2018. Quels sont les effets concrets de la DSP2 sur l’EBICS?

La DSP2 a plusieurs objectifs:

• amélioration de la sécurité des paiements électroniques
• protection des informations financières des consommateurs
• ouverture du marché aux prestataires de services de paiement, notamment en matière de services pour les consommateurs et les entreprises
• renforcement des droits des consommateurs, par exemple en termes de responsabilité en cas d’opérations de paiements non autorisés et de remboursement de prélèvements en euros
• interdiction de facturation de frais supplémentaires, quel que soit l’instrument de paiement

Pour accroître la sécurité des paiements électroniques, il est nécessaire que l’accès aux comptes des clients soit totalement sécurisé. L’identification d’un utilisateur de services de paiement ou d’une transaction exige une authentification forte. EBICS remplit ces critères grâce aux procédés de clés asymétriques liés à l’utilisateur. Rien ne s’oppose donc à la mise en pratique d’une authentification forte.

Les trois piliers d’une authentification forte sont possession, inhérence et savoir. Au moins deux de ces critères doivent être fournis aux utilisateurs pour l’authentification EBICS. Une carte à puce (possession) peut par exemple servir de clé EBICS pour permettre une authentification par saisie de code PIN (savoir) via un lecteur de carte à puce. Dans l’interface avec l’utilisateur, cela doit donc être réalisé par le Client.

Outre les procédés EBICS d’identification et d’authentification unique de la personne, la banque peut également prévoir des vérifications supplémentaires (inhérence) et vérifier par exemple si les adresses IP convenues sont bien utilisées pour la communication. Une adresse IP inadéquate empêche alors l’accès, même si l’authentification est correcte.

EBICS assure la dynamique d’authentification exigée grâce à la procédure de signature électronique car la signature est toujours créée au moyen de la valeur de hachage du fichier original et d’un horodatage.

Par ailleurs, la fonctionnalité EBICS de signature électronique distribuée (SED aussi appelée VEU en Allemagne) permet, du côté des utilisateurs des services de paiement, de séparer les infrastructures pour les remises de paiements et les autorisations. Par exemple, la remise de paiement peut avoir lieu par EBICS sans autorisation sur un guichet automatique et les autorisations requises, elles, postérieurement par application mobile, sur portail EBICS ou avec quelque autre logiciel Client EBICS (séparation dans le temps et dans l’espace). En outre, les conditions d’autorisation peuvent exiger l’implication de plusieurs personnes. Cette fonction est déjà utilisée par les solutions EBICS que sont les portails EBICS, les solutions de navigateur EBICS, les Clients mobiles EBICS ainsi que les autres logiciels Clients EBICS. Il convient de proposer et d’utiliser systématiquement ces techniques pour la DSP2.

Ouvrir le marché des paiements aux prestataires de services de paiement implique que les banques doivent accorder aux applications de fournisseurs tiers l’accès aux données client, si ce dernier donne son accord. Pour mettre en œuvre cette exigence, des interfaces sont nécessaires. Le standard EBICS fournit sa propre interface. Si le fournisseur tiers ne peut pas obtenir les informations directement via l’accès EBICS standard, des API rapides et flexibles capables d’échanger les données requises en fonction des besoins deviennent nécessaires. Dans ce cadre, homogénéité et multi-usage sont souhaitables.

Dans la pratique, les activités des utilisateurs et en particulier les autorisations pour applications de e-banking et de paiements sont d’ores et déjà enregistrées. Cependant, le renforcement des droits des consommateurs visé par la DSP2 demande aux prestataires de services et aux banques de consigner et conserver les processus de paiement et les autorisations, dans le contexte des utilisateurs, de façon aussi intégrale que possible ainsi que de manière traçable et justifiable. Dans le contexte d’EBICS, cela s’applique aux banques, mais également aux fournisseurs de services qui exploitent par exemple des applications Client EBICS.

En résumé, la DSP2 n’a pas, pour l’instant, d’impact direct sur les spécifications d’EBICS. Néanmoins, les utilisateurs d’EBICS doivent tenir compte de la DSP2 dans leur contexte d’utilisation. Les exigences de la DSP2 doivent donc être définies et mises en œuvre précocement pour l’exploitation et l’utilisation de solutions EBICS. Le temps est compté.

Michael Lembcke

En savoir plus

«Les logiciels de paiement hors ligne ciblés par des pirates: des entreprises suisses sont touchées»

Le titre ci-dessus est tiré d’un communiqué publié en juillet de cette année par la Centrale d’enregistrement et d’analyse pour la sûreté de l'information MELANI. Il décrit un nouveau type de piratage dont des entreprises suisses sont victimes.

Aujourd’hui, les entreprises utilisent généralement un logiciel hors ligne pour transmettre, valider et exécuter un grand nombre d’ordres de paiement électroniques, surtout quand elles sont multibancarisées. Les virements sont automatiquement déclenchés à partir de l’ ERP et transmis à la banque par des protocoles sécurisés. Ce type d’émission de paiements est aujourd’hui utilisé pour la majorité des ordres de paiements électroniques effectués en Suisse.
 

Le maliciel «Dridex» que MELANI décrit dans son communiqué se propage à travers des documents Microsoft Office malicieux contenus dans des e-mails provenant d’expéditeurs en apparence légitimes et il s’attaque depuis peu à ces logiciels de paiement hors ligne. Les fabricants pris pour cible sont, avant tout, ceux qui sont assez répandus sur le marché suisse. Beaucoup d’entreprises sont actuellement inquiètes et se demandent si leur solution est suffisamment protégée et comment se prémunir contre de telles attaques.

Tout d’abord, il est important de suivre les consignes de sécurité publiées depuis longtemps par MELANI: utiliser des ordinateurs dédiés, ignorer les mails contenant des pièces jointes suspectes, mettre régulièrement à jour les systèmes d’exploitation et les antivirus, etc. afin de garantir la sécurité de sa propre infrastructure. Une consigne attire particulièrement l’attention, à savoir celle recommandant l’utilisation d’une signature collective à la place de signatures individuelles. Comment cela fonctionne-t-il dans la pratique alors que les fondés de pouvoir de la société ne signent plus d’ordres physiques sur papier pour les envoyer à la banque?

Les banques proposent deux solutions différentes (parfois combinées). D’une part, la validation peut avoir lieu à travers un autre canal. Cela signifie que le fichier est directement  transmis à la banque à partir du logiciel hors ligne au moyen du protocole EBICS (Electronic Banking Internet Communication Standard), par exemple, mais que l’exécution de l’ordre n’est pas encore autorisée. Par validation au travers de l’e-banking en ligne de la banque, les ordres peuvent être ensuite définitivement validés par une deuxième personne.

Un autre type de signature collective sûre et flexible est l’utilisation de la «Signature Electronique Distribuée» (VEU) gérée par le protocole EBICS. Celui-ci prévoit les modèles de signatures «transport» (pas d’autorisation), «individuelle», «collective A» et «collective B». De plus, la banque peut fixer un plafond journalier (par client, par compte ou par type d’ordre). La Signature Electronique Distribuée permet au client une couverture complète de la gestion des signatures de son entreprise et assure un niveau de sécurité très élevé avec l’utilisation de plusieurs canaux (ex.: délivrance de la deuxième signature au moyen d’un dispositif mobile).

De plus en plus de banques suisses proposent la VEU EBICS dans leurs solutions d’e-banking. Renseignez-vous à ce sujet auprès de votre banque ou posez vos questions à info@ppi.ch si vous désirez davantage d’informations sur la VEU EBICS.

Communiqué original de MELANI : https://www.melani.admin.ch/melani/fr/home/documentation/lettre-d-information/offline-payment-software.html

Carsten Miehling

En savoir plus

EBICS mobile – partout et à tout moment

Michael Schunk, Product Manager, PPI AG

Le protocole EBICS est conçu pour transférer d’importantes quantités de données, accéder aux informations des comptes et autoriser des ordres. Il s’agit là des besoins élémentaires de tout trésorier gérés sans difficulté par EBICS, ce qui garantit son succès.

À l’ère de la digitalisation, un volume toujours plus important d’informations est mis à disposition toujours plus rapidement. EBICS ne peut se soustraire à ces exigences. La solution : des applis mobiles EBICS fournissant aux clients des informations en un temps record.


L’atout des applis EBICS en termes de vitesse découle de deux aspects:

• Les messages push
  Ces notifications ciblées se substituent aux requêtes envoyées par le client. Elles l’informent de manière proactive de la survenue d’un événement (p. ex. une activation ou la réception d’un paiement).
• L’indépendance géographique
  Les smartphones permettent un accès presque sans limites aux informations. Il est ainsi p. ex. possible de produite une signature EBICS au cours d’une réunion.

Les premières applis EBICS étaient entachées de graves défauts, qui n’incitaient guère à les utiliser:

• Le téléchargement
  Pour signer un fichier, il est nécessaire de le télécharger en totalité, ce qui peut représenter un nombre important de méga-octets. La signature devient alors rapidement une corvée et le volume mensuel de téléchargement disponible est vite épuisé.
• La performance
  Pour accéder aux informations du compte, il est dans un premier temps nécessaire d’analyser (ou de « parser ») un message XML CAMT. Le modeste processeur du smartphone consomme alors une telle quantité d’énergie que la batterie commence à chauffer et se décharge rapidement. Pendant le délai d’attente, il n’est en outre pas possible d’accéder p. ex. à ses e-mails, car toutes les ressources de l’appareil sont utilisées.
• La sécurité
  Les trois clés EBICS sont conservées sur le smartphone ou sur un serveur. Le vol du smartphone ouvre donc la voie à toutes sortes d’attaques. Simultanément, stocker les clés sur le serveur est contraire aux exigences de sécurité.

Tenez compte de ces imperfections initiales lorsque vous achetez une appli EBICS, nombreuses sur le marché sont celles qui en sont encore affectées.

Mais revenons à notre trésorier. De quoi a-t-il besoin ?

• d’informations actuelles sur les entrées et les sorties de paiements
• d’un outil pour autoriser les paiements
• de notifications proactives, p. ex. lors d’activations ou en cas de réception d’avis de paiements

Un trésorier souhaite et doit toujours être parfaitement informé. Ce qui semble encore impossible avec les systèmes clients EBICS conventionnels devient réalité grâce aux applis EBICS. Les services push informent proactivement le client. Et si ce dernier est en déplacement ou s’il ne souhaite pas recevoir de messages push, il peut opter pour des notifications par e-mail.

L’image ci-dessus montre la nouvelle appli EBICS mise à disposition par HSH Nordbank auprès de ses clients entreprises. Le nombre d’institutions bancaires exploitant les possibilités du numérique ne cesse de croître – tout comme l’attractivité d’EBICS.

Michael Schunk

En savoir plus

Attaques de hackers contre des opérations de paiement SWIFT

Des criminels ont dérobé la somme incroyable de 81 millions de dollars américains à la banque centrale du Bangladesh – non pas au cours d’un cambriolage digne d’un film, mais par le biais d’une attaque de hackers. Les malfaiteurs ont effectué plus de 30 virements du compte de la banque du Bangladesh à la Federal Reserve Bank (Fed) de New York vers des comptes aux Philippines. Cet exemple, ainsi que d’autres, montre que les opérations de paiement interbancaires constituent une cible de choix pour les criminels et que la sécurité du réseau financier international SWIFT est vulnérable. Certes, s’introduire dans ce réseau requiert des efforts considérables, mais les butins envisageables le sont encore bien davantage. Au vu de ce type d’attaques professionnelles, la sécurité des opérations de paiement est une fois de plus à l’ordre du jour.


La banque du Bangladesh a été victime d’une attaque à deux niveaux en février 2016. De toute évidence, les dispositifs de sécurité informatique se sont révélés insuffisants: la rumeur parle ainsi d’absence de pare-feu et d’une infrastructure réseau obsolète. C’est cette faille que les malfaiteurs auraient exploitée pour s’introduire dans le réseau de la banque et accéder aux données d'accès pour les virements. Dans SWIFT Client Alliance Access, ils furent en mesure de faire usage de ces données pour s’autoriser eux-mêmes en tant que donneur d’ordre des transactions. Pour la Fed, la Banque du Bangladesh agissait en tant qu’émetteur.

Selon BAE Systems, cette faille de sécurité aurait également permis aux criminels d’installer un logiciel malveillant spécialement conçu à cet effet dans le serveur SWIFT Alliance. Ce malware avait pour objectif de manipuler les messages de confirmation du réseau SWIFT et de désactiver la protection contre les accès à la base de données. Les transactions effectuées n’ont par conséquent pas été consignées correctement, et ce, afin d’effacer toute trace du méfait.

L’attaque des hackers a complètement neutralisé les mécanismes de sécurité de SWIFT, ouvrant aux malfaiteurs des possibilités presque illimitées. Le montant total des transactions demandées était en fait de 951 millions de dollars américains. Ce n’est qu’une erreur de saisie assez inhabituelle, incitant une banque du Bangladesh impliquée dans le processus à s’enquérir de la validité d’un virement, qui a permis de révéler l’escroquerie. Toutefois 81 millions de dollars avaient déjà été virés et avaient déjà disparu dans des casinos et chez des particuliers philippins. En mars 2016, Atjur Rahman, directeur de la banque centrale du Bangladesh ainsi que ses adjoints n’ont eu d’autre choix que de démissionner de leurs fonctions.

SWIFT a pour sa part reconnu que des messages frauduleux avaient été envoyés à plusieurs reprises par le biais du réseau au cours des derniers mois. En mai 2016, une banque commerciale avait ainsi été victime d’une escroquerie similaire : des criminels s’étaient introduits dans les systèmes informatiques pour y accéder à des données utilisateurs et manipuler des messages. Des mises à jour doivent maintenant combler les lacunes de sécurité constatées dans le logiciel SWIFT.

Bien que SWIFT souligne le fait que l’attaque ne remet pas en cause la sécurité du réseau, mais plutôt celle des systèmes utilisés pour y accéder, cette mésaventure illustre tout le dilemme des réseaux fermés internationaux. Même en déployant des moyens techniques importants, il est impossible de les cloisonner complètement. Outre le logiciel de l’exploitant du réseau, les systèmes bancaires environnants peuvent également présenter des failles, sans parler de collaborateurs mal intentionnés qui peuvent se rendre complices d’escroqueries. Une fois l’accès obtenu, tout un monde de possibilités s’ouvre aux malfaiteurs – d’où leur motivation. EBICS est un procédé qui utilise l’Internet – ouvert par définition – et qui met en œuvre un concept de sécurité misant sur des clés tant pour la cryptographie que pour l’authentification. Cette approche constitue une alternative face aux réseaux fermés.

Au vu des dommages potentiels énormes, il est impératif de mettre en place une protection exhaustive des transactions tant interbancaires qu’entre banques et entreprises. Et il faut s’attendre à une recrudescence des cyberattaques telles que celles décrites ci-avant. Pour y faire face, les mesures de sécurité des procédures et des systèmes informatiques des banques et celles applicables au personnel doivent être parfaitement imbriquées.

Michael Lembcke

En savoir plus

Comment améliorer EBICS, 8e partie – éviter les doubles remises grâce aux fonctionnalités d’EBICS: Ce genre d’incident peut se produire rapidement, comment procéder?

Un moment d’inattention et les ordres de paiement ont été transférés à la banque deux fois via EBICS. Et personne ne l’a remarqué. Plusieurs scénarios sont possibles:

1. Un paiement est saisi et transmis deux fois.
2. Le fichier comportant les ordres de paiement est envoyé une nouvelle fois et donc en double.
3. Le fichier est envoyé deux fois pour des raisons techniques, parce que le statut de transfert du premier envoi était équivoque.

Une double remise se caractérise par le fait qu’un client transmette deux fois un paiement ou un fichier identique à sa banque pendant un laps de temps déterminé. Mais deux remises identiques peuvent-elles toujours être considérées comme une double remise devant être refusée? La réponse est non, car certains paiements sont émis et transmis plusieurs fois par le remettant en toute connaissance de cause.


Dès lors, comment identifier à coup sûr les doubles remises côté banque et éviter ainsi tout préjudice pour le client?

Dans un premier temps, il est possible d’identifier et de refuser les doubles remises évidentes dès leur réception par le serveur bancaire EBICS.

S’agissant des doubles remises pour raisons techniques (scénario 3), le protocole EBICS jusqu’à la version 2.4 est en mesure de détecter si un client réutilise un ID d’ordre attribuée par le client EBICS dans un laps de temps déterminé. À partir de la version 2.5, le serveur bancaire EBICS attribue un ID d’ordre unique dès le début de la communication. Par conséquent un doublon avec même ID d’ordre ne peut pas se produire via EBICS V2.4.

En revanche, un serveur bancaire implémentant les fonctionnalités existantes d’EBICS n’est pour l’heure pas en mesure d’exclure le scénario 2, au cours duquel un fichier ou un ordre est transmis une nouvelle fois par erreur par le biais d’un nouveau transfert et donc muni d’un ID d’ordre différent. Pour permettre une identification efficace des doubles remises au niveau des fichiers, la prochaine version d’EBICS doit être enrichie de la proposition d’amélioration EBICS-CR EB-14-08 DoubleUploadControl.

Celle-ci impose la transmission, par le logiciel client au serveur bancaire EBICS, d’une valeur de hachage afférente au fichier. Cette valeur de hachage est de toute façon produite par le logiciel client pour générer la signature. Le serveur bancaire EBICS doit ensuite vérifier si la valeur de hachage a déjà été reçue au cours d’un laps de temps déterminé et refuser l’ordre si tel est le cas.
Une identification plus étendue des doubles remises p. ex. au niveau des transactions unitaires (scénario 1) se révèle plus compliquée et la solution passe ici toujours par des mécanismes extérieurs à EBICS. Le cas échéant, un collaborateur de la banque doit déterminer en concertation avec le client si une double remise est voulue ou non.

Grâce à l’implémentation de la proposition EBICS-CR EB-14-08 DoubleUploadControl, EBICS se voit complété et amélioré d’une nouvelle fonctionnalité aussi utile que nécessaire, qui permettra d’éviter suffisamment tôt les doubles remises erronées. Cela dit, il ne s’agit pas d’un remède universel et les applications bancaires devront continuer à effectuer des recherches de doublons plus étendues.

Michael Lembcke

En savoir plus

UBS goes EBICS

Patrik Giger, Head Payment Connectivity Services, UBS Switzerland AG

Dans le cadre de l’enquête Cash Management 2015 organisée par Euromoney, UBS s’est vue décerner le prix de « Best Domestic Cash Manager Switzerland » pour la cinquième fois consécutive. Ce succès résulte d’une prise en considération depuis plusieurs années des besoins des clients et de la recherche  d’une qualité optimale des produits et des services proposés.

L’infrastructure pour la connexion directe avec les systèmes clients fait partie intégrante de cette offre de services. Depuis de nombreuses années, c’est une interface basée sur un échange propriétaire des données qui a fait ses preuves dans notre pays – une connexion directe largement plébiscitée par les clients. À l’international, ces derniers utilisent principalement une connexion via SWIFT for Corporates ou des solutions multibanques pour échanger des données de paiement et de reporting avec leurs institutions financières.

Les clients d’UBS sont d’ores et déjà en mesure d’exécuter leurs opérations financières mondiales en toute sécurité, y compris avec  les succursales internationales. L’objectif majeur des nouvelles infrastructures est de rendre les échanges avec les institutions financières encore plus sûrs, plus aisés et plus standardisés.


Harmonisation des opérations de paiement : une opportunité autant qu’un défi

Dans le cadre d’un projet commun dénommé «Harmonisation du trafic des paiements», les banques suisses ont entériné un accord prévoyant, d’ici 2020, la migration des opérations de paiement vers  la norme internationale ISO 20022 (pour plus de détails, voir http://www.paymentstandards.ch/fr/home.html).

Dans les quatre années à venir, les formats et traitements existants seront modifiés afin d’exploiter durablement les synergies entre prestataires de services de paiement, institutions financières et consommateurs tout au long de la chaîne de valeur. Ces synergies doivent donc devenir des atouts pour tous les acteurs impliqués. Or, le défi est non seulement de taille, mais le calendrier établi pour atteindre cet objectif se révèle très ambitieux. Ce sont les répercussions que ces changements auront sur les clients qui sont dès lors bien souvent sous-estimées. La modification des formats va ainsi sans doute également se traduire par une évolution des procédures au sein des entreprises clientes.

Les développeurs de logiciels en tant que pivots de l’harmonisation

Les départements informatiques des clients, ainsi que les consultants IT et les développeurs de logiciels, jouent un rôle fondamental dans la migration des opérations de paiement en Suisse. Plus de 90 % des clients d’UBS utilisent p. ex. un logiciel standard proposé par un prestataire bien implanté sur le marché pour permettre les échanges avec leurs banques. Et ces clients s’attendent bien entendu à ce que les ERP (Enterprise Ressource Planning) et autres TMS (Treasury Management Software) correspondants soient en mesure de gérer rapidement et avec fiabilité les nouveaux formats ISO. Pour simplifier le passage aux formats ISO 20022, UBS met à la disposition des développeurs une plateforme de test dédiée, qui permet de télétransmettre des fichiers tests, tant manuellement que par le biais d’un canal EBICS, en vue de leur validation. Outre des codes d’erreur standardisés, les rapports de test contiennent également des informations très détaillées sur les éventuelles anomalies et imperfections des messages. La plateforme propose par ailleurs aux développeurs un « readiness test », qui confirme leur aptitude (et celle de leurs clients) à gérer l’ISO 20022.

Remplacement d’une solution propriétaire éprouvée

UBS propose à ses clients le canal de communication EBICS depuis déjà 2013. Ce canal est utilisé par quelques clients dotés de logiciels financiers très spécifiques, mais la grande majorité favorise toujours la solution propriétaire. Cela s’explique notamment par la grande stabilité des opérations de paiement dans notre pays, où les changements sont demeurés très rares au cours des dernières décennies. Tant les clients que les développeurs locaux de logiciels n’avaient donc aucune raison de modifier leurs solutions existantes éprouvées. Et ceci s’appliquait également aux banques.

EBICS – un canal idéal pour ISO 20022

Alors pourquoi – en plus des formats – vouloir aussi changer les canaux de communication? Les analyses ont montré que l’intégration des nouveaux formats dans les anciens canaux (propriétaires) allait demander à peu près autant d’efforts de la part des clients, des développeurs de logiciels et des banques que d’instaurer le nouveau canal standardisé EBICS.

Les principaux prestataires financiers helvétiques proposent d’ores et déjà une connexion via EBICS, ou ils sont en passe de le faire.

L’avantage du standard EBICS est évident: les clients pourront profiter du fait que les «banques parlent la même langue». En Suisse, nous disposons en outre déjà de solutions éprouvées, puisqu’EBICS s’est imposé comme un standard de communication stable et fiable depuis son introduction en Allemagne il y a 10 ans. L’adhésion de la Suisse en tant que troisième pays membre de la société EBICS (avec l’Allemagne et la France) témoigne sans équivoque de la volonté des prestataires financiers helvétiques de faire de ce canal de communication non pas un produit secondaire, mais bien une solution d’importance stratégique.

Lutte autour des types d’ordres standardisés

S’agissant des types d’ordres, c’est l’approche allemande qui s’est imposée en Suisse (indication du contenu à l’aide du type d'ordre), par opposition au modèle français qui ne connaît que les types d'ordres «upload» et «download». La «recommandation suisse» prévoit une standardisation la plus étendue possible des types d’ordres, et la migration des opérations de paiement offre la possibilité d’aller encore plus loin. Le type d’ordre suisse «XE2» s’applique actuellement aux transferts nationaux ainsi qu’aux virements SEPA et internationaux. Or, UBS s’engage pour que les types d’ordres soient à l’avenir étendus pour maximiser l’effet de synergie d’ISO 20022 et d’EBICS. Dans les faits, on envisage donc d’utiliser des types d’ordres EBICS spécifiques pour les paiements en Suisse, à l’étranger et via SEPA. Cette proposition fait l’objet de discussions animées au sein des instances compétentes et UBS espère ainsi atteindre un degré de standardisation à synergie ajoutée.

UBS implémente EBICS – mondialement!

UBS a décidé de remplacer l’infrastructure de communication existante pour les opérations de paiements de masse en Suisse par une solution EBICS standardisée. À terme, la banque prévoit même d’utiliser EBICS en tant que protocole de communication pour ses clients dans les centres de comptabilité internationaux, en Asie et aux États-Unis. Point essentiel lors de cette migration, l’infrastructure doit être stable et standardisée. Grâce à l’étroite collaboration avec la société PPI, nous serons à l’avenir en mesure de recommander aux clients ne disposant pas de logiciels capables de gérer EBICS un plug-in, qui se chargera de la communication. En outre, nous offrirons la possibilité de se connecter au portail EBICS «UBS KeyPort Web» en tant qu’alternative lorsque les clients souhaitent télétransmettre manuellement leurs transactions sous forme de fichiers ou de télécharger leurs reportings par le biais d’un portail Internet.

L’offre EBICS d’UBS s’adresse en premier lieu aux clients qui ont besoin d’une connexion directe pour leurs systèmes ERP et TMS, puis à ceux qui recherchent un portail disposant de capacités «multi-booking-center» pour leurs paiements de masse. Pour traiter les transactions spécifiques et obtenir des informations supplémentaires, nos clients pourront continuer à utiliser notre e-banking UBS, une solution aussi moderne que polyvalente.

EBICS doit continuer à évoluer

UBS supportera tant la variante allemande (DK) du standard que la variante française. Il est cependant urgent d’harmoniser encore d’avantage le standard, car bien que seuls trois membres siègent au sein de la société EBICS, le nombre d’implémentations distinctes se révèle déjà très élevé. La société EBICS a d’ailleurs d’ores et déjà lancé un projet d’harmonisation supplémentaire sous le nom BTF (voir l’article de Sabine Wenzel, EBICS SCRL, dans ce blog http://www.ebicsblog.com/fr/harmonieusement-international-avec-ebics-btf/). Selon nous, cette harmonisation constitue une priorité majeure et nous sommes convaincus qu’EBICS va continuer à s’imposer en tant que standard de communication à l’échelle mondiale. UBS est en première ligne sur ce sujet et mise sur EBICS en Suisse, en Allemagne, en Europe, en Asie et aux États-Unis.

Patrik Giger

En savoir plus

EBICS et TLS 1.2 – un regain de sécurité sans complexité accrue

Curd Reinert, Project Manager EBICS-Kernel, PPI AG

Quiconque jette un coup d'œil sur les spécifications actuelles d’EBICS pourra s’étonner de constater que la version prescrite pour le protocole de sécurisation des échanges sur Internet, Transport Layer Security (TLS), est toujours la version 1.0. A un certain moment, ce fut un choix judicieux: lorsque les spécifications EBICS ont été publiées, le protocole TLS 1.0 était la technologie la pus avancée. À l'époque, en effet, il avait surtout été jugé important de ne pas utiliser le protocole SSL. Ce choix avait d'ailleurs garanti une excellente protection par exemple contre la vulnérabilité logicielle POODLE, et ce, aussi bien pour les éditeurs que pour les exploitants: EBICS excluait l’utilisation du protocole SSL et les applications EBICS étaient protégées contre POODLE. Ceci étant dit, POODLE n'aurait eu de toute façon pratiquement aucune chance avec un client EBICS: Lors d'une telle attaque, l'agresseur contraint en effet le client à envoyer des milliers de requêtes au serveur HTTPS, pour, par exemple, obtenir le cookie de la session. Or, EBICS n'utilise aucun cookie de session et les logiciels clients ne sont pas des applications web avec lesquelles JavaScript peut être utilisé pour envoyer des milliers de requêtes. Mais essayez d’expliquer cela aux auditeurs!


Et il ne s'agissait là que de l'une des attaques malveillantes portant des noms amusants: HEARTBLEED, par exemple, mettait à profit une erreur dans l'implémentation TLS d'OpenSSL. Et sans oublier non plus la menace BEAST. Pourtant, comme dans le cas de la menace POODLE, EBICS est également protégé contre une attaque BEAST. Malgré tout la réputation du protocole TLS 1.0 est durablement compromise et tous les sites recommandent de passer au successeur, plus sûr, le protocole TLS 1.2.

Cela fut admis dans le cadre d’EBICS et des demandes de modification ont été planifiées afin de prendre charge TLS 1.2. Malheureusement, la sortie de cette nouvelle version prend du retard et les auditeurs nous demandent souvent : Pourquoi EBICS utilise-t-il encore le protocole TLS 1.0 ? Un argument du genre «parce ce que c'est ce qui est prescrit dans les spécifications » n'est certainement plus une raison valable si l'on tient compte du fait que le BSI (federal office for information security) conseille officiellement d'éviter cette version. C'est d'ailleurs la raison pour laquelle vous trouverez désormais sur le site officiel EBICS des recommandations en matière de sécurité qui conseillent d'utiliser la version TLS 1.2 – sans expliquer comment concilier cette recommandation et la spécification.

Nous avons testé 82 serveurs EBICS en Allemagne et en France : Seulement 52 serveurs ont pu communiquer avec nous en utilisant le protocole TLS 1.2. Si vous décidez donc aujourd'hui en tant que fabricant de produits clients de ne plus supporter TLS 1.0, vous ne pourrez plus vous connecter à environ un tiers des serveurs EBICS. Et la situation risque d'être encore pire pour les exploitants de serveurs qui communiquent avec des produits clients utilisant les différentes versions.

Quelles sont alors les possibilités? Proposer la version TLS 1.2 sans toutefois interdire la version TLS 1.0. Cette solution est possible aussi bien pour les clients que pour les serveurs; lors de la prise de contact - ou handshake - TLS, les deux parties se mettent d'accord sur la variante commune la plus sûre – du moins en théorie. Ceci a d'ailleurs effectivement fonctionné sur 28 des serveurs testés. Mais nous avons aussi trouvé deux serveurs qui interrompent systématiquement la communication dès lors que le client propose la version TLS 1.2. Ceci est particulièrement désagréable pour les fabricants de produits clients étant donné que les clients ne peuvent alors tout simplement pas proposer la version TLS 1.2 «au cas où». Et s'ils le font tout de même, ils prennent le risque de ne pas pouvoir communiquer avec quelques serveurs.

Nous avons naturellement informé les opérateurs de ces deux serveurs EBICS. Comme notre test ne couvrant pas tous les serveurs EBICS, nous recommandons aux exploitants de contrôler eux-mêmes le comportement de leur serveur EBICS.

Une question subsiste cependant: Quel serait le risque lié à un décryptage du protocole TLS dans EBICS ; quelles seraient les données visibles? Les données de l'ordre elles-mêmes sont cryptées une seconde fois et restent invisibles pour l'agresseur. Il reste donc uniquement le cadre XML dans lequel sont intégrées les données de l'ordre ou, comme on les nomme également depuis l'affaire Snowden : les métadonnées. Il s'agit là principalement du type d'ordre ou du format de fichier, de l'ID client et de l'ID participant. En d'autres termes, pas vraiment grand-chose. Cela suffira-t-il à calmer les esprits : c’est une autre histoire.

Curd Reinert

En savoir plus

EBICS dans la péninsule Ibérique

En 2014, la plupart des banques portugaises ont ouvert un canal EBICS basé sur la version 2.4.2 du protocole. Seul le profil T est réellement utilisé à ce jour toutefois plusieurs entreprises souhaitent utiliser les signatures personnelles laissant présager une mise en œuvre du profil TS à court terme.
A ce jour, très peu de banques espagnoles proposent à leur clientèle entreprise la possibilité de gérer leurs échanges de flux financiers au moyen du protocole EBICS. Pourtant, la demande se fait de plus en plus prégnante, ce qu’a démontré la présence de nombreux participants à un évènement organisé à Madrid par l’Association Espagnole des Financiers d’Entreprise (ASSET) le 20 Janvier.

Lire l'article en espagnol (PDF)

Ceci s’explique entre autres par le fait que les entreprises espagnoles, tout comme les autres entreprises européennes, ont un besoin accru d’effectuer des transactions avec des banques situées hors de la péninsule.

Dans le cadre de cet évènement présidé par Gerardo de la Mata, Director ASSET et responsable de la commission Paiements, diverses présentations ont permis d’apporter un éclairage sur EBICS et d’en faire connaître l’intérêt aux entreprises, banques et éditeurs présents. Pour ce faire, les intervenants ont abordé des thèmes divers et complémentaires tels que:

• Axel Weiß, EBICS Chairman, a fait la genèse d’EBICS, il en a présenté les caractéristiques principales et les avantages avant de décrire le fonctionnement de la compagnie EBICS SCRL,
• Thomas Stosberg, Deutsche Bank, a notamment présenté les raisons pour lesquelles EBICS a été mis en œuvre et les retours sur expérience ainsi que les évolutions futures dans le cadre de BTF[1],
• Ma présentation a eu pour but de décrire plus en détail certains sujets tels que la sécurité, les cas d’usage en France et en Allemagne tant dans le domaine des échanges entreprise-banque qu’en interbancaire. J’ai également exposé les modalités d’implémentation d’EBICS ainsi que le déroulement de la migration en France.

Les questions posées par l’auditoire ont essentiellement porté sur un éventuel choix à opérer entre divers protocoles d’échanges utilisés à ce jour en Espagne (Editran, Swift) et EBICS. Les critères de choix paraissent rationnels.

Editran est certes un protocole largement utilisé en Espagne. Toutefois, il n’est que rarement, voire pas du tout supporté par des banques et entreprises situées au-delà des frontières espagnoles, il ne répond donc pas aux besoins d’entreprises et banques devant gérer des échanges transfrontaliers.
La réponse à ces besoins réside donc dans l’utilisation d’un ou plusieurs protocoles qui permettront de supporter des échanges transfrontaliers. En fonction du contexte, comme c’est déjà le cas en France par exemple, l’utilisation d’EBICS et de SWIFT est parfaitement concevable; EBICS pouvant être utilisé pour les communications avec un nombre croissant de banques situées dans plusieurs états européens, SWIFT pouvant l’être avec les autres.

Les coûts d’utilisation constituent également un facteur de décision important qui pourrait (devrait) inciter les entreprises à optimiser les coûts en utilisant le protocole le plus économique.

Un thème qui semble également avoir attiré l’attention des participants est la signature électronique distribuée avec EBICS, plus particulièrement sur mobile, telle qu’elle est couramment pratiquée en Allemagne (VEU). Rien d’étonnant à cela, ce qui me paraît l’être d’avantage est qu’elle ne soit pas véritablement mise en œuvre en France.

Un évènement similaire se tiendra à Barcelone le 24 février et nombre de participants ont d’ores et déjà confirmé leur venue. Encore une preuve pour autant qu’elle soit nécessaire que l’industrie financière est demandeuse d’un moyen d’échange normalisé, universel et efficient, comme c’est le cas d’EBICS.

[1] Business Transactions & Formats

Marc Dutech

En savoir plus

Harmonieusement international avec EBICS BTF

Sabine Wenzel, EBICS Secretary, EBICS SCRL


Le CFONB et la Deutsche Kreditwirtschaft (DK) ont fondé la société EBICS en 2010, dont l’un des objectifs est l’harmonisation du standard éponyme. Les procédés utilisés auparavant dans les deux pays ont influé sur les spécifications d’EBICS, ce qui a eu pour effet de complexifier son implémentation. L’Allemagne et la France suivent des approches différentes en matière d’identification (abrégée) des échanges et des formats à mettre en œuvre. La situation a évolué depuis l’adhésion de la Suisse à EBICS SCRL: un projet d’harmonisation a été lancé, dont le but est de garantir une démarche homogène dans l’utilisation d’EBICS. Ce projet de consolidation s’intitule EBICS BTF.


En tant que protocole de communication sécurisé, EBICS garantit en premier lieu l’authentification, le chiffrement et l’autorisation des données à transférer.

Les banques et les entreprises clientes doivent être en mesure d’identifier les services devant être exécutés en relation avec un ordre. Par conséquent, le serveur EBICS doit p. ex. vérifier

• que le client utilise bien le format de fichier adéquat, le cas échéant dans la version (variante) correspondante du protocole et/ou conformément à des directives d’implémentation spécifiques
• que les prescriptions en matière de mise à disposition des fichiers sont respectées et que les indicateurs de traitement sont bien spécifiés
  • indicateur du nombre de signatures électroniques apposées sur l’ordre et indicateur précisant si le client peut fournir une signature supplémentaire par VEU (Signature électronique distribuée) en cas de besoin
  • indicateur signalant que l’ordre a été intégré à un conteneur
• si des options de service complémentaires ont été spécifiées, p. ex. la mention du protocess SRZ (Service Data Processing Centre) de la DK ou le mode test couramment utilisé en France

Ces vérifications requièrent une indication concise des échanges concernée et de l’adéquation du format sous lequel l’ordre a été transmis. À l’heure actuelle, ces «étiquettes» apposées sur un ordre EBICS varient encore d’un pays à l’autre.

En Allemagne, on utilise des trigrammes, tandis que seuls deux types d’ordre standards (pour la télétransmission et le téléchargement) complétés d’un paramètre de format de fichier ont été définis en France. Or, ces deux approches se révèlent insuffisantes pour une utilisation internationale – p. ex. en Suisse. Ce manque d’homogénéité constitue sans nul doute un frein à la diffusion d’EBICS.
Le Board of Directors (BoD) EBICS a de ce fait mandaté l’EBICS Working Group (constitué d’experts allemands, français et suisses) afin d’élaborer une solution uniformisée et structurée pour l’identification des «Business Transactions Formats» (BTF). EBICS BTF doit faire partie intégrante de la prochaine version d’EBICS.

Pour l’heure, le concept BTF s’articule autour de trois groupes d’éléments:

• Contenu – format/standard de format utilisé (le cas échéant version utilisée)
• Traitement – codes EU et VEU, conteneurs utilisés
• Service – informations relatives au système cible (le cas échéant avec 1..n options)

L’avantage de ce développement commun : toutes les instances impliquées ont la même perception de l’utilisation des éléments et attributs XML. La «balise» des échanges standards (p. ex. du transfert SEPA) sera donc le même dans tous les pays. S’agissant des caractéristiques spécifiques aux pays, les éléments BTF prendront cependant des formes différentes. Les divergences sont ainsi transparentes et facilement identifiables.

Cette approche commune a été le fruit de débats animés, y compris à propos des informations vraiment nécessaires pour identifier et transmettre correctement les ordres concernés. Ces informations doivent être complètes et exemptes de toute redondance et incohérence. Les participants sont notamment convenus de recourir autant que faire se peut à des listes de codes externes (les codes et éléments de données correspondants feront l’objet d’une concertation commune avant d’être administrés par EBICS SCRL).

Au sein de l’EBICS Working Group, cette solution est considérée comme particulièrement stable et bénéficie d’un large consensus. Ce sera finalement aux communautés EBICS de décider sous quelle forme et dans quels délais elles mettront en œuvre EBICS BTF dans les années à venir. Des consultations nationales à ce sujet – avec la participation de l’EBICS Working Group – sont prévues en début d’année 2016.

Sabine Wenzel

En savoir plus