Des échanges EBICS en mode test sur un serveur bancaire en production?

Depuis la version 2.4 d’EBICS utilisée en France, il est possible d’échanger des opérations métier non pas par le biais de types d’ordre composés de 3 caractères comme il est d’usage en Allemagne et dans d’autres pays, mais via le paramètre FileFormat pouvant contenir jusqu’à 40 caractères.

Ce paramètre doit être précédé du type d’ordre FUL ou FDL. Ce faisant, l’ajout d’un indicateur de test est possible. Ce dernier permet au client EBICS en production de signaler à l’institution financière une remise de test, lors de l’envoi d’un fichier par exemple. À condition qu’il existe un accord bilatéral concernant l’utilisation de l’indicateur de test, la banque peut accepter l’ordre, l’identifier en tant que cas de test et l’isoler des chaînes de traitement. L’utilisation d’un indicateur de test en production fait l’objet de controverses dans les banques. Une telle option est actuellement refusée par la plupart des banques allemandes.

Avec la version 3.0 d’EBICS et grâce à l’utilisation harmonisée du BTF - au lieu des types d’ordre et des paramètres FileFormat - l’indicateur de test est omise dans la spécification de cette version la plus récente d’EBICS. En outre, le CR EBICS EB-17-01 Element Group Parameter a introduit une vérification plus stricte de l’utilisation des indicateurs non convenus bilatéralement, dans les paramètres génériques du BTF. Les indicateurs non autorisés sont dorénavant rejetés par le code retour EBICS 09-0-0-06: EBICS_UNSUPPORTED_REQUEST_FOR_ORDER_INSTANCE.

Le CFONB a rédigé un guide d’aide à la migration pour la mise en œuvre d’EBICS 3.0 en France (EBICS 3.0 Aide à la migration BTF & Table de correspondance File Format/BTF). Vu que les banques en France ont utilisés l’indicateur de test dans le passé et que son utilisation perdurera à l’avenir, le CFONB a défini l’utilisation du mode de test pour la migration vers le BTF et l’a également intégré dans le guide en tant que fonctionnalité optionnelle. De cette façon, le paramètre TEST peut toujours être utilisé pour les cas de test, même pour BTF, à condition qu’il existe un accord bilatéral entre la banque et le client. Si l’indication du paramètre est différente, un rejet se produit avec le code retour indiqué ci-dessus. Les serveurs bancaires EBICS et les logiciels client EBICS peuvent proposer cette fonction en option.

Indépendamment de ce qui précède, EBICS permet en outre l’utilisation des BTF ayant fait l’objet d’un accord bilatéral dans le cadre de remises de test.

En fin de compte, il faut cependant noter qu’il existe toujours un risque que l’utilisation de l’option de test dans un environnement de production puisse avoir des conséquences négatives sur les données de production, ou pire encore, que des données de test soient inopinément introduites dans les données de production.

L’option la plus sûre reste de disposer d’un serveur dédié aux tests avec la clientèle. Et pourquoi pas ?

Auteur: Michael Lembcke

Grâce à EBICS : normalisation et automatisation de la relation avec les gérants de fortune indépendants

Les gérants de fortune indépendants (GFI) ou External Asset Manager (EAM) offrent aux clients privés fortunés et aux clients institutionnels, parmi les caisses de retraite et les compagnies d'assurance, différents services (par exemple le conseil fiscal et immobilier, les actes de commerce et d'investissement). Les comptes client sont souvent détenus par une ou plusieurs banques de dépôt. L'interaction avec les institutions financières n'est souvent ni standardisée, ni automatisée. La communication par courrier, téléphone, courriel et parfois même par télécopieur domine le travail quotidien.

Il n'existe que peu de gérants de fortune qui disposent d'une connexion SWIFT et qui utilisent cette dernière pour le traitement des activités de trésorerie et de devises étrangères (type de message 3), des activités de titres (type de message 5), des activités de métaux précieux (type de message 6) ou des activités de Cash Management (type de message 9). Certains ont mis en œuvre des connexions propriétaires de système à système, par exemple via FTP, afin d'échanger des messages financiers. En Suisse, nous constatons qu'EBICS pourrait s'établir en tant que connexion alternative pour ces transferts.

Dans le cadre du Petit Déjeuner de PPI en avril 2019 à Lausanne, un représentant de Credit Suisse a présenté le service « Private swift Network (PsN) ». Il s'agit d'un supplément au protocole EBICS qui offre environ 20 nouveaux types d'ordre EBICS (rapport pour le téléchargement) provenant des cas d'utilisation GFI indiqués ci-dessus. Grâce à la coopération avec les éditeurs de logiciel qui sont leader sur le marché des producteurs de systèmes de gestion de portefeuille (comme par exemple Allocare ou Expersoft), Credit Suisse atteint une augmentation significative du niveau de normalisation et d'automatisation dans la communication avec leurs partenaires. Les messages SWIFT des types de message indiqués ci-dessus peuvent désormais être transférés via EBICS.

Du fait que le protocole EBICS est flexible quant au contenu transféré, Credit Suisse offre en plus d'autres formats, comme par exemple CSV ou XML pour l'établissement de rapports sur les transactions et fortunes, y compris les données de base des dépôts de client correspondants. Tous les acteurs du marché profitent de cette nouvelle offre : les gérants de fortune connectent de plus en plus les institutions financières à faible coût via EBICS et automatisent leurs processus, les éditeurs de logiciels peuvent élargir l'étendue de leurs fonctions et les institutions financières profitent d'une augmentation de l'attractivité pour les GFI. Si on considère tous les postes et processus, le taux d'erreur baisse et la vitesse de mise en œuvre augmente, vu qu'une action manuelle n'est plus nécessaire.

Les institutions financières en Suisse, réalisant actuellement des projets dans ce contexte, prévoient déjà les prochaines étapes du développement de l'offre EBICS. À l'avenir, l'offre contiendra non seulement les fonctions de rapport (téléchargement EBICS), mais également les fonctions d'ordre (émission EBICS). Notamment les ordres dans le commerce (type de message 5 SWIFT) sont particulièrement adaptés à la remise via EBICS. Concrètement, cela signifie que les ordres de bourse (par exemple SWIFT MT502) doivent être transférés, par le biais d'un propre type d'ordre, du gérant de fortune à l'institution financière. Par analogie avec les interfaces d'ordre de paiement répandues, les interfaces d'ordre de bourse sont connectées côté banque. Dans ce contexte, l'application de la VEU est envisageable.

Conclusion:

Des premières institutions financières en Suisse élargissent leur offre EBICS, au-delà des cas d'utilisation du trafic de paiements. L'offre de Credit Suisse pour les moyens et grands gérants de fortune envoie un signal fort au marché des clients GFI et entraînera, sans doute, des imitateurs. Les éditeurs de logiciels des systèmes de gestion de portefeuille font lentement et sûrement connaissance du protocole EBICS et élargissent leurs possibilités de connectivité, en ajoutant ce type de connexion. L'imagination n'a pas de limite quant aux formats et standards transférés via EBICS. On peut présumer qu'EBICS représentera une vraie alternative à la communication via le réseau SWIFT, par exemple dans les domaines en dehors du trafic de paiements, pour une clientèle particulière.

Carsten Miehling

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

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

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

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

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

Michael Lembcke

Migration vers EBICS 3.0 en France

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

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


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


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

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

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

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

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

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


Marc Dutech


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

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

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

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

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

Michael Lembcke

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


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

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

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

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

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

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

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

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

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

Carsten Miehling

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

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

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

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

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

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

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

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


Michael Lembcke