Paiements avant Noël – achats de Noël avec la demande de paiement ?

Les fêtes de Noël approchent. Pas aussi manichéennes, pas aussi simples et paisibles que les histoires le racontent – mais à leur manière tout à fait charmantes. Cependant, cette période de fin d’année peut être un peu déroutante, en particulier quand je regarde les relevés de compte de mes expériences d’achats effectués avant Noël.

La plupart des gens le savent : les bonnes intentions du type « ...mais cette année nous n’offrirons rien ! » sont encore moins valables que les résolutions du Nouvel An qui ne manqueront pas de suivre. Et même si on a l’impression que Noël commence en automne avec le premier pain d’épices sur les étagères, le temps des achats de cadeaux est toujours reporté à la dernière minute. Cette année encore je me retrouve encore une fois prise dans la folie du shopping. Parents, sœurs, grands-parents, famille du conjoint avec cinq frères et sœurs – et la génération suivante est déjà à la porte. Concilier les différentes listes de souhaits, listes d’achats et attentes avec mes relevés bancaires semble être un travail de Sisyphe.

Mes boutiques en ligne préférées possèdent mon mandat de prélèvement automatique alors que dans d’autres magasins digitaux, seuls les paiements par carte de crédit sont possibles. Je paie les billets de concert avec PayPal et les commerçants via Girocard pour les produits achetés dans les réseaux physiques ou « hors ligne ».

Retrouver toutes ces positions sur mon relevé de compte qui est beaucoup trop long me rappelle que je dois encore commander un puzzle trois mille pièces pour ma tante. Le service à thé pour ma grand-mère a-t-il déjà été payé ou sera-t-il débité plus tard ? Quand ma facture de téléphone sera-t-elle encaissée ce mois-ci ? C’est d’habitude cette semaine, n’est-ce pas ? Et qu’est-ce que ce « shop XY », et pour quoi a-t-il reçu 90 € de ma part ?

Comme chaque année, j’ai l’impression que la folie du shopping me submerge et je perds la vue d’ensemble. Le décalage entre la commande et le paiement ainsi que les différents délais me laissent un sentiment désagréable– surtout qu’en cette période de débits inhabituels de mon compte, quelque chose peut m’échapper facilement. À quoi me sert-il de pouvoir faire une réclamation sur un débit effectué par prélèvement si je ne peux plus ensuite l’identifier ? Quel paiement par carte de crédit ai-je vraiment autorisé ?

Cela devrait être plus facile. Cela devrait être plus ordonné. Cela devrait être plus immédiat. L’année prochaine à la même époque ?

Je m’imagine commander la nouvelle radio pour ma mère et que mon application bancaire me demande de débloquer le montant, au moment de la commande. Les pull-overs de Noël kitsch avec le nez de renne sont commandés en deux tailles différentes et essayés. Et qu’au moment de retourner le pull beaucoup trop grand, ma banque en ligne me demande si je débloque le paiement pour le bon pull.

Trois paquets sont à ma disposition dans l’entrepôt de livraison. Afin d’ouvrir le paquet, j’autorise le paiement après en avoir reçu la demande. Le magasin XY réclame encore 90 € de ma part ? Rejeté ! Je n’ai rien commandé chez eux. Et en décembre ma facture de téléphone était apparemment plus élevée que d’habitude et pour cette raison la demande de paiement n’a pas été confirmée automatiquement. Je vérifie le relevé des appels et j’autorise la facture manuellement – c’est exact, j’ai appelé ma famille en Angleterre.

Voilà ce qu’est la demande de paiement. Qui sait si cela rendra la prochaine période des fêtes de fin d’année plus calme et plus paisible. Mais avoir plus de contrôle sur mes paiements avant leurs exécutions et ainsi éviter des regards inquiets sur mon compte, cela sonne presque aussi bien que d’avoir un Noël blanc.

Auteur : Anuschka Clasen

En savoir plus

XS2A sans prestataires de services tiers ? Pourquoi pas !

Dans le cadre de la DSP2, une interface pour les prestataires de services tiers (API XS2A) a été introduite dans toute l’Europe. En tant qu’initiateur, l’UE souhaite permettre à des tiers d’accéder aux comptes bancaires des clients et ainsi promouvoir la concurrence sur le marché. Le 14/09/2019, l’API XS2A a été mise en production par les banques en Europe dans les délais prévus. Depuis lors, les participants du marché adaptent l’API XS2A aux besoins des parties prenantes et font évoluer intensivement les services proposés aux consommateurs et entreprises.

En tant que « service obligatoire » conformément à la règlementation, l’API XS2A constitue un facteur de coûts initial pour les institutions financières. Cependant dès le début ont été pris en compte des services à valeur ajoutée et ils ont été spécifiés par le Berlin Group, par exemple, offrant ainsi aux institutions financières de nouvelles sources de revenus. Mais dans le battage médiatique actuel autour de l'API, il n'y a pas de limites aux fantasmes concernant les sources de revenus.

Pour l’instant nous surfons donc sur la vague médiatique et imaginons l'API XS2A comme un canal d'accès alternatif pour les entreprises. Pourquoi pas ? D’un point de vue technique, les obstacles devraient être peu importants. Une entreprise pourrait s’identifier comme prestataire de services tiers au moyen d’un certificat eIDAS. Le certificat ne différerait que dans les champs spécifiques pour les prestataires de services tiers. Comme c’est le cas pour EBICS, les ordres émis ou les demandes pourraient être accompagnés d’une signature, permettant au destinataire du message d’en vérifier l’intégrité. La sécurité du transport est garantie par l’utilisation de TLS.

Du point de vue métier, le cas d’application « Initier un paiement » permet tant l’exécution d’un paie-ment unique que l’exécution d’un paiement de masse. Les procédures d’autorisation habituelles de la banque en ligne pour la validation sont à la disposition des consommateurs (par exemple photoTAN et pushTAN). Cela ne conviendrait probablement pas aux entreprises, de sorte que les sceaux des entreprises seraient utilisés, ce qui reste à spécifier. L’API XS2A permet également de consulter les informations sur les comptes (soldes, transactions détails). Dans ce cas particulier où existe une relation de confiance entre l’entreprise et l’institution financière, le consentement (consent) requis à cette fin pourrait être donné par le biais d’un consentement valable en permanence.

L’API XS2A serait alors une vraie alternative qui est déjà discutée dans divers forums. L’idée est vue comme « moins cher, plus pratique, exécution en temps réel, plus flexible dans les ajustements ». Cependant le status quo nous ramène rapidement sur terre. La spécification du Berlin Group donne aux institutions financières une grande liberté d’implémentation de l’API. Dans le but d’atteindre toutes les institutions financières en Europe via XS2A, cette liberté d’implémentation représente actuellement un défi pour tous les participants sur le marché. C’est une situation qui n’est pas ou pas encore favorable pour les entreprises. Mais la première pierre en direction d’une alternative est posée.


Auteur: Christian Wenz

En savoir plus

Notification en cas de réception de paiements instantanés SEPA – un composant élémentaire dans la chaîne des paiements

Outre les délais courts inhérents au virement en temps réel, la notification immédiate du bénéficiaire du paiement quant à la réception du paiement est un élément clé des paiements instantanés SCT et des autres étapes associées de ce processus.

Ce qui est désormais bien réalisé dans le traitement des transactions en ligne ou dans la relation entre le commerçant et le client – comme décrit par Michael Lembcke dans l’article « Notifications en temps réel et EBICS - finies les demandes de téléchargement «vaines»  » – représente toujours un défi pour les différents acteurs dans l’environnement EBICS. Les notifications sur le chiffre d'affaires ont fait leur entrée dans l’annexe 3 de l'accord DFÜ (en vigueur depuis novembre 2019) et y sont spécifiées en tant que messages camt.054, qui peuvent être téléchargés via le type d'ordre EBICS C5N. Par contre, ces derniers doivent être récupérés activement par le bénéficiaire du paiement depuis l’institution financière. Une notification push active du bénéficiaire du paiement n’a pas été prévue jusqu’à présent. Il est désormais possible de combler cette lacune en étendant la spécification EBICS à une notification basée sur le protocole WebSocket du serveur bancaire envoyée au client. Les informations sur le chiffre d’affaires peuvent ainsi être téléchargées rapidement, dès que la réception de paiement sous-jacente a eu lieu. Les demandes de téléchargement «vaines» sont alors éliminées.

Étant donné qu’une notification directe de la réception du paiement entraîne également un déroulement des processus plus rapide et plus efficace, il est temps d’examiner de plus près cette fonction importante.

Le point de départ de notre voyage dans le monde des notifications instantanées est l’interconnexion globale de la société. Les services numériques sont disponibles à tout moment et tout lieu dans le monde et ce de plus en plus en temps réel – « toujours disponible, toujours instantané ». Alors que les délais liés aux procédures de paiement classiques duraient parfois plusieurs jours en fonction du pays destinataire, et que les processus logistiques restaient lents lors de l’envoi d’une marchandise, la numérisation croissante permet des chaînes de processus toujours plus courtes, stables, sans ruptures de supports et sans délai d’attente et assure aussi une forte croissance dans le domaine de nouvelles offres numériques.

Certaines étapes de la chaîne trop imbriquées les unes avec les autres ne peuvent être transférées facilement dans le monde instantané, car il existe des dépendances vis-à-vis du monde non numérique. D’autres étapes sont déjà disponibles 24h/24, 7j/7, 365 jours par an – certaines avec une durée de quelques secondes. Le processus de commande et le processus de paiement associé en font partie.

Le mot clé est « paiements instantanés », permettant un crédit immédiat du montant payé chez le bénéficiaire et garantissant ainsi un service immédiat après le paiement. Ce qui fonctionne pour les produits numériques est bien plus difficile pour la vente par correspondance. Une accélération de l’intégralité du processus grâce à une réception du paiement plus rapide chez le commerçant est envisageable, mais une disponibilité directe de la marchandise commandée est presque impossible, ce qui signifie que le client paye en avance même si la durée du processus est raccourcie.
L’achat sur facture représente pour le client l’option la moins risquée. Pour le commerçant/fournisseur elle comporte des risques élevés, car ce dernier fournit la marchandise en avance et ne peut pas compter sur un règlement rapide de la créance. Le paiement anticipé par les méthodes de paiement classiques, y compris les cartes, entraîne uniquement un renversement de la position de risque, mais pas un risque équilibré entre le commerçant et l’acheteur. Seul un intermédiaire peut actuellement remédier cette situation, qui exécute en tant qu’instance fiable pour le commerçant et l’acheteur la remise de la marchandise et la procédure de paiement au même moment. Pas de paiement – pas de marchandise et vice versa. C’est alors le processus de paiement à la livraison classique.

Quel est le rôle de la notification du bénéficiaire du paiement ? Sans notification immédiate du bénéficiaire sur la réception du paiement, les processus accélérés ainsi que les produits innovants, basés sur un paiement direct, sont impensables. L’opération ne peut être conclue ou du moins, la prochaine étape de la chaîne du processus ne peut être déclenchée que par une information, qui est intégrée dans le processus de paiement et qui est envoyée immédiatement après le paiement – soit par un processus en ligne via une API qui est restituée à cet effet par l’institution financière, soit via l’utilisation du canal EBICS en combinaison avec un service push.

Jusqu’à présent les notifications sur le chiffre d’affaires ont été faites par information sur les comptes intra-journaliers (MT942) ou relevé de compte (MT940), qui était restitué avec un délai d’un jour. En raison de la nécessité d’une réponse immédiate, prévue pour SCT Inst en cas d’une réception de paiements instantanés, ce n’est que la finalisation de la procédure de paiements qui est possible. Ceci est notamment indispensable pour l’application des paiements instantanés sur le POS. Les longs délais d’attente jusqu’à ce que la transaction soit complétée empêcheraient l’acceptation du client. La référence est la durée d’un paiement par carte.

Ce n’est seulement pour le POS qu’une notification immédiate est importante : Les procédures de paiements existantes, par exemple le paiement de facture par paiements instantanés dans l’online banking ainsi que le paiement classique à la livraison, pourraient en profiter. Dans le premier cas, l’avantage consiste en un déroulement accéléré du processus pour toutes les parties concernées. Le deuxième cas se réfère surtout à la substitution des instruments de paiement classiques, comme l’argent ou les cartes.

En ce qui concerne le développement des futures méthodes de paiement, par exemple Request to pay (demande de paiement), la notification jouera un rôle significatif. Dans ce contexte je voudrais vous renvoyer vers un autre article du blog EBICS de mon collègue Eric Waller qui a traité de ce sujet : « La demande de paiement modifie les transactions financières - premiers cas d’utilisation ».

Auteur : René Keller

En savoir plus

Erreurs de format des ordres EBICS – services de test pourraient aider

EBICS a été spécialement conçu pour des échanges de données sécurisés et performants avec des fichiers de toute taille entre banques et entreprises. Pour les ordres de paiement le contenu d'un fichier à envoyer vers le serveur EBICS doit toujours correspondre à l'opération métier définie (type d'ordre, paramètre FileFormat ou BTF) et aux spécifications de formats y afférentes. Lors des remises de paiements, des fichiers de remise contenant des transactions unitaires regroupées par compte du donneur d'ordre sont couramment utilisés. La création de comptes-rendus (HAC et PTK) des procédures EBICS côté serveur est en partie spécifique au format des ordres de paiement. Les vérifications d'autorisation et la création des comptes-rendus requièrent donc que le serveur bancaire EBICS connaisse et puisse lire au moins les informations importantes du format de remise (par exemple compte du donneur d'ordre et montant). Afin de lire ces informations le serveur bancaire EBICS effectue un contrôle de format. Généralement il interrompt le contrôle dès que la première erreur de format est détectée. L'ordre est refusé en raison d’une erreur de format laquelle est documentée dans le compte-rendu client.

Pourquoi le fichier n'est-il pas entièrement vérifié et pourquoi les erreurs détaillées ne sont-elles pas consignées dans le compte-rendu client ?

Il y a plusieurs raisons à cela. En premier lieu les contrats de services habituels pour l'e-banking via EBICS visent à la remise et au traitement rapide des fichiers corrects. Une vérification intégrale du format avec compte-rendu d'erreurs n'est pas incluse et ne fait pas partie des tâches fondamentales d’un serveur bancaire EBICS. En plus, les capacités des serveurs bancaires doivent être utilisées pour le traitement immédiat des ordres conformes au format et non pour l'analyse de fichiers incorrects.
Mais comment une institution financière peut-elle offrir à ses clients entreprise un service qui améliore la qualité des ordres de paiement quant au format et au contenu, sans charger inutilement le serveur bancaire EBICS ?

Les clients pourraient pour cela utiliser des services de test tels que la plateforme de test ISO-20022. Dans le cadre de l'harmonisation des paiements suisses, les banques suisses offrent déjà une telle plateforme à leurs clients afin de tester les formats d'entrée et de sortie.

La plateforme de test simule les conditions en production spécifiques à la banque. À l'aide de cette plateforme, les messages banque-entreprise XML peuvent être validés et l'interface banque-client peut être simulée.

Un élargissement de la plateforme test ISO-20022 à la vérification des ordres de paiement pour des conventions de format et des contenus propriétaires peut encore améliorer considérablement la qualité du fichier. En faisant préalablement une vérification complète de format des ordres de paiement, des erreurs pourraient être identifiées rapidement et facilement, grâce à un compte-rendu d'erreur détaillé.

Il est ainsi possible, lors d’une vérification préalable, de détecter et de corriger les fichiers dont le format et le contenu ne sont pas corrects, avant de les envoyer vers le serveur EBICS.


Auteur: Aline Wendler et Michael Lembcke

En savoir plus

La demande de paiement modifie les transactions financières - premiers cas d’utilisation

La demande de paiement, également appelée Request to Pay (R2P), est un nouvel instrument de paiement qui modifiera durablement les paiements. Dans le papier blanc « Request to Pay completes the electronic payment process » (disponible en anglais et en allemand), j’ai déjà expliqué le rapport entre la facturation électronique, les paiements instantanés et l’instrument de paiement « Request to Pay » qui n’existait pas jusqu’à présent.
Je profite de cet article pour présenter les quelques premiers cas d’utilisation qui peuvent facilement être envoyés vers un compte bancaire existant, via la demande de paiement.

• Demande de paiement dans le cas d’une facture déjà émise : un cas d’utilisation simple consiste par exemple en l’envoi classique de la facture, puis de la demande de paiement. Ce cas vise d’abord à accélérer le paiement de la facture dûe en facilitant le traitement des données qu’elle comporte par le débiteur. La demande de paiement relative à la facture déjà reçue par le débiteur est affichée dans son application bancaire en ligne ou sur son mobile avec les données du bénéficiaire, le montant du paiement ainsi que le motif de paiement déjà renseignés. Le débiteur n’a plus qu’à confirmer les données et signer son exécution avec ses identifiants.


• Demande de paiement combinée avec une facture commerciale : le cas d’utilisation décrit ci-dessus s’applique également dans le cas où la facture électronique et la demande de paiement correspondante sont simultanément présentées au débiteur dans son application bancaire en ligne ou sur son mobile. L’envoi habituel par la poste n’est plus nécessaire, le débiteur peut consulter électroniquement sa facture et payer de manière aisée. Cette méthode offre aussi la possibilité de stocker numériquement la facture dans un système d’archive bancaire et de la rapprocher numériquement et à tout moment avec un paiement.


• Demande de paiement par étapes : il va sans dire que la demande de paiement peut être utilisée en cas d’une séparation spatiale. Il est ainsi également concevable de numériser l’ancienne méthode de paiement à la livraison. Le fournisseur adresse un message de demande de paiement au destinataire qui vérifie la livraison de la marchandise et lance un ordre de paiements instantanés en réponse à la demande. Le distributeur reçoit de son côté une notification indiquant la réception du paiement et débloque la marchandise.


• Demande de paiement dans le commerce traditionnel : comme expliqué dans le cas précédent, il serait possible d’utiliser la demande de paiement en combinaison avec les paiements instantanés et les notifications. Dans ce cas, ce n’est pas la facture qui est transférée mais le ticket de caisse qui est transporté conjointement avec le message de demande de paiement et qui peut être enregistré dans une archive numérique du compte, avec la comptabilisation. Le personnel de caisse ne débloque l’achat qu’une fois la notification reçue.

Les demandes de paiement peuvent être utilisées dans différents secteurs d'activité et je pense donc que le nouvel instrument de paiement « Request to Pay » modifiera durablement les paiements tels que nous les connaissons. Je continuerai à publier des mises à jour fréquentes sur les développements en cours et sur d’autres cas d’utilisation.

Auteur : Eric Waller

En savoir plus

Annonce: Extension du blog EBICS de PPI – tout sur les paiements!

Chers lecteurs,

Nous avons le plaisir de vous informer aujourd'hui sur l'extension du blog EBICS.

Dans notre blog EBICS « Tout sur les paiements », nous souhaitons à l'avenir vous informer encore plus sur les tendances et thèmes actuels autour des transactions financières dans les domaines EBICS, SEPA, SWIFT ainsi que régularisation et numérisation.

Dès maintenant, le blog EBICS est maintenu toutes les deux semaines par deux équipes d'auteurs. Notre objectif est de vous présenter de première main les perspectives et expériences de nos experts en produits et en conseil issues des projets client, des études et des papiers blancs, au vu des exigences actuelles et futures sur le marché des paiements.

Nous nous réjouissons de votre feedback et nous vous souhaitons une bonne lecture !

Votre équipe d'auteurs PPI

En savoir plus

Notifications en temps réel et EBICS - finies les demandes de téléchargement «vaines»

Ainsi que je l’écrivais dans mon article de décembre 2018, le sujet des virements en temps réel (paiements instantanés) pour la clientèle entreprise est devenu d’actualité dans le monde EBICS grâce au nouveau format de paiements instantanés de masse. Lors de l’upload de virements en temps réel, les règles strictes afférentes aux délais de synchronisation des paiements instantanés ne s'appliquent pas à la phase de transfert EBICS. Le temps n’est décompté qu’une fois que le traitement par le serveur bancaire EBICS est achevé.

Et qu'en est-il du sens inverse pour les échanges d’opérations métier des paiements instantanés via EBICS ? Après tout, même si une notification en temps réel (Credit Notification) n'est pas possible en temps réel, il n’en demeure pas moins que le bénéficiaire du paiement doive être informé de préférence assez rapidement. Dans la relation standard entre le client et la banque, le client EBICS est toujours l’initiateur du téléchargement des informations disponibles sur le serveur bancaire. Un envoi via EBICS de telles informations, à l’initiative de l'institution financière, n'est pas prévu. Le milieu économique en particulier a forcé les institutions financières et la Deutsche Kreditwirtschaft (Comité allemand pour le secteur bancaire) à trouver une solution pragmatique pour l’envoi de notifications en mode push. L'objectif final consistant en une solution ne nécessitant pas de modifier le protocole EBICS ni de faire évoluer la notion de rôles (initiateur/répondeur).

Il en résulta l'idée d'une nouvelle interface standard basée sur WebSocket, informant les clients EBICS de la mise à disposition de nouvelles informations pouvant être téléchargées. La disponibilité d'une Credit Notification en fait partie. Ce nouveau canal push ne transfère pas de données sensibles, le téléchargement de telles données se faisant toujours via le canal sécurisé EBICS.

La Deutsche Kreditwirtschaft (Comité allemand pour le secteur bancaire) a désormais spécifié cette nouvelle interface dans la spécification sur les notifications en temps réel, puis publié le document dans sa version 1.0 le 18/07/2019 sur la partie allemande du site web d'EBICS (www.ebics.de).

Il s'agit maintenant de mettre en œuvre cette interface dans les logiciels clients EBICS et dans les serveurs bancaires EBICS, d'une manière rapide et conforme au standard, car elle permet d'optimiser l’activité des clients entreprise, même indépendamment des paiements instantanés. Pour les divers processus de téléchargement, il est ainsi possible d'éviter les demandes de téléchargement « vaines » répétées par les logiciels clients EBICS de façon automatique, qui sont effectuées par exemple lors du téléchargement des relevés de compte. Par conséquent, tant les utilisateurs des clients EBICS que les opérateurs de serveurs bancaires profiteront d'une réduction de la charge. Voilà une bonne nouvelle, n'est-ce pas ?

Auteur : Michael Lembcke

En savoir plus

Le protocole EBICS est-il exempt d’authentification forte au sens de la DSP2?

La question nous a été posée maintes fois, que ce soit par des Institutions financières Françaises ou Européennes, et il ne fut pas toujours évident de fournir une réponse suffisamment formelle.

Et bien la Banque de France a récemment répondu de manière officielle en incluant le protocole EBICS dans la liste des procédures et protocoles exemptés d’authentification forte en application de l’article 17 du règlement délégué (UE) 2018/389. Celle-ci précise que « les prestataires de services de paiement sont autorisés à ne pas appliquer l'authentification forte du client à l'égard de personnes morales qui initient des opérations de paiement électronique au moyen de procédures ou de protocoles de paiement dédiés qui sont uniquement mis à la disposition de payeurs qui ne sont pas des consommateurs lorsque les autorités compétentes ont acquis la certitude que lesdits procédures et protocoles garantissent des niveaux de sécurité au moins équivalents à ceux prévus par la directive (UE) 2015/2366 ».

Le texte intégral peut être consulté à l’adresse suivante: https://www.banque-france.fr/stabilite-financiere/securite-des-moyens-de-paiement-scripturaux/2eme-directive-sur-les-services-de-paiement https://www.banque-france.fr/stabilite-financiere/securite-des-moyens-de-paiement-scripturaux/2eme-directive-sur-les-services-de-paiement
 
Attention cela ne signifie pas pour autant qu’EBICS ne supporte pas l’authentification forte, loin de là ! La certitude que le protocole EBICS garantit des niveaux de sécurité au moins équivalents à ceux prévus par la directive est acquise de longue date. D’ailleurs je vous invite à ce sujet à lire ou à relire l’article EBICS et DSP2 : comment vont-ils ensemble? publié dans ce blog il y a quelques mois.

Auteur: Marc Dutech

En savoir plus

Vérifier les valeurs de hachage des clés bancaires lors d'une requête d'initialisation EBICS

Les transactions EBICS sont divisées en différentes étapes : initialisation, transfert de données et acquittement (cette dernière ne s'appliquant qu'aux transactions de téléchargement).

Les aspects suivants sont notamment vérifiés lors de l'initialisation:

• Type d'ordre
•  Signature d'authentification
• Valeurs de hachage des clés bancaires
•  Autorisations relatives au participant

La phase de transfert durant laquelle les données de l’ordre sont envoyées ne peut se dérouler qu’une fois l’initialisation réalisée avec succès. Les valeurs de hachage des clés bancaires sont vérifiées lors de l'initialisation, afin d'assurer que le client utilise les clés bancaires à jour. Si la vérification échoue, le serveur envoie le code retour EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Cela permet d’indiquer au client qu’il doit télécharger les clés bancaires les plus récentes à l'aide du type d'ordre HPB.

Avant l'harmonisation apportée par EBICS 3.0 il était possible d'utiliser les clés bancaires directement ou incorporées dans les certificats. Conformément aux spécifications d’EBICS jusqu'à la version 3.0, les valeurs de hachage des clés bancaires publiques devaient être fournies pendant l'initialisation des transactions – indépendamment du fait qu'il s'agissait d'un échange de certificats ou de clés avec l'institution financière.

À partir d'EBICS 3.0, les certificats sont obligatoires pour la gestion des clés. Il est en plus spécifié qu'il est nécessaire d'indiquer les valeurs de hachage des certificats dans la requête d’initialisation EBICS, tant pour les émissions que pour les téléchargements.

En règle générale, les fournisseurs de serveurs bancaires EBICS offrent à leurs clients la possibilité d’une transition progressive, en permettant de spécifier aussi bien les clés bancaires que les certificats au format DER. Cela signifie que les clients ne sont plus tenus d’effectuer de téléchargement via le type d'ordre HPB une fois la migration vers EBICS 3.0 accomplie. Les clés comme les certificats peuvent être indiqués soit sous forme HEX, conformément à la spécification, soit de manière alternative en codage Base64. Le mélange des deux schémas dans une seule et même requête n'est pas prévu.

À propos : EBICS 3.0 a uniformisé la gestion des clés non seulement pour les clés bancaires, mais également pour les clés du participant. Cela signifie qu'il est d'ores et déjà obligatoire dans tous les pays d'initialiser les participants avec des certificats, chose qui existait jusqu'ici uniquement en France (CFONB). Dans ce cas aussi les serveurs bancaires EBICS permettent généralement une transition aisée : les clés du participant d’une longueur minimale de 2 048 octets peuvent également être utilisées pour EBICS 3.0 et, pour l’activation des clés (types d'ordre HCA, HCS et PUB) les nouveaux certificats peuvent généralement être signés avec les clés des versions antérieures d’EBICS.
Les certificats validés par une AC continuent d'être utilisés uniquement en France. Cependant du point de vue des serveurs bancaires, rien ne devrait s’opposer à ce que ce soit le cas également dans d’autres pays.

Auteur: Hendrik Chlosta

En savoir plus

Quel est le rapport entre GPI et EBICS ?

GPI est-il intimement lié à SWIFT ? De prime abord, on pourrait le penser. L’acronyme provient de SWIFT et signifie « Global Payments Innovation ». Lancée à la fin de l'année 2015, l'initiative GPI a immédiatement reçu le soutien de nombreuses institutions financières mondiales.

Le principe de GPI repose sur la référence unique de bout en bout, en abrégée UETR (Unique End-to-End Transaction Reference), qui accompagne un paiement tout au long de la chaîne des banques correspondantes et qui peut dans certains cas se révéler plutôt longue. Elle est composée de pas moins de 36 caractères sous la forme xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx générés au moyen d’un algorithme universel, et elle garantit l'unicité de la transaction sans « organisme d'attribution » central. Alors qu’UETR n'était à l'origine utilisé que dans un seul CUG (Closed User Group) pour les paiements entreprise dans les messages MT103, tous les paiements effectués dans le réseau FIN sont désormais munis d'une telle référence, qui reste identique du début à la fin de la chaîne de paiement.

Le deuxième composant essentiel de GPI est le « tracker », base de données centralisée hébergée chez SWIFT. Il fournit aux institutions financières participantes des informations complètes sur le statut d'un paiement dans la chaîne des banques correspondantes, sur les frais et sur les cours de change des devises. Alors que le transport FIN lit directement ces informations dans les messages échangés, les institutions financières non-FIN peuvent elles aussi fournir activement des informations au tracker. La « Confirmation » qui consiste en la notification du crédit sur le compte du bénéficiaire à la fin de la chaîne de paiement, est actuellement en discussion et devrait devenir obligatoire dès 2020 pour toutes les institutions financières FIN.

Mais pourquoi tous ces efforts ? GPI permet de relever les deux principaux défis du secteur des banques correspondantes, à savoir la transparence et la rapidité. L'utilisation intensive d'UETR a permis d'obtenir des statistiques : en moyenne, 40 % des virements GPI sont comptabilisés dans le compte du bénéficiaire final dans un délai inférieur à cinq minutes, 50 % en moins de 30 minutes, 75 % en moins de six heures et la quasi-totalité en 24 heures. Une telle affirmation aurait été tout simplement impossible avant l'arrivée de GPI. Au contraire, tous les trésoriers ont connu des situations au cours desquelles les paiements arrivaient en retard ou n'arrivaient pas du tout, avec des frais élevés et inexplicables ainsi que des informations peu claires ou manquantes.

En plus des détails techniques tels qu'UETR et le Tracker, GPI fournit également un ensemble de règles stipulant qu'un paiement doit être transmis dans la mesure du possible le même jour et doit être accompagné d'un motif de paiement complet spécifiant les frais déduits ainsi que les détails de la conversion des devises. Puisqu'il n'existe pas de directive globale sur la transparence, celle-ci doit être appliquée sur la base d'accords multilatéraux. C'est une bonne chose - nous attendions une telle mesure depuis longtemps.

Le client (entreprise) devrait bénéficier d'un meilleur service en matière de transactions financières transfrontalières. Nous avons déjà abordé le sujet de la rapidité et la transparence, mais l'accusé de réception joue également un rôle important. À y regarder de plus près, ce principe n'existe que pour les paiements en espèces : dans le domaine des transactions financières électroniques, le slogan « shoot and forget » était jusqu'à présent de rigueur, à savoir que si personne ne se manifeste, nous partons du principe que l'argent est bien arrivé. Les paiements SEPA se sont considérablement développés au cours des dernières années et les paiements instantanés réalisés selon le schéma SCTinst sont maintenant eux aussi accompagnés d'un accusé de réception. L'arrivée de SWIFT GPI permet également de générer un tel accusé de réception, même si cette opération requiert (encore) une chaîne FIN dans le processus de règlement. Il reste toutefois du chemin à parcourir : de nombreux changements sont requis au niveau des institutions financières, dans un premier temps uniquement en interne. La connexion des systèmes clients permettant l'accès aux informations ou même le transfert du statut et des informations relatives aux frais vers les systèmes clients n'en est qu'à ses débuts. En cas de doute, la possibilité de vérifier le statut des paiements dans une base de données centralisée représente déjà une avancée considérable dans le vaste réseau des banques correspondantes.

Ce système peut-il être mis en place en dehors du réseau FIN ? Bien sûr que oui. Les développements actuels, tels que la migration des systèmes de règlement brut en temps réel (RTGS) TARGET2, EURO1 ou encore CHAPS de MT vers des messages en XML conformément à la norme ISO-20022, permettent de faire un pas supplémentaire dans cette direction. Les (nouveaux) formats de message ISO contiennent des champs dédiés à l’UETR, permettant ainsi de transporter la référence également en dehors du réseau FIN. SWIFT a par ailleurs récemment annoncé le « SWIFT trials instant cross-border gpi payments through TIPS »[1].

Les messages sous forme de PSR (Payment Status Report, c'est-à-dire pain.002) sont plus efficaces que les processus manuels pour l’envoi des réponses GPI aux systèmes clients tels que TMS ou ERP. Ces fonctions en libre-service sont déjà un pas important vers plus de transparence. Les normes de ces réponses, c'est-à-dire les champs (tags) et les codes, sont par ailleurs définis par l'initiative d'harmonisation CGI-MP comme solutions compatibles multi-banques. PPI contribue dès maintenant activement à cette initiative.

À l'avenir, les clients devraient également être en mesure d'initier leurs références en tant qu'UETR dans les paiements - comme champ spécial de pain.001.001.03 conformément à l'initiative CGI-MP ou dans des champs prévus à cet effet (déjà disponibles dans les versions ISO les plus récentes).

C'est précisément ici, au niveau de l'interface institution financière/banque ou banque/institution financière, que les paiements des clients et les réponses PSR sont souvent transportés avec EBICS. Plutôt que de s'opposer, les systèmes GPI et EBICS se complètent donc de manière raisonnable, comme c'est souvent le cas pour les transactions financières.

Auteur : Dr Mario Reichel

[1] Source : https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips

En savoir plus

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

En savoir plus

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

En savoir plus

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

En savoir plus

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

En savoir plus

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

En savoir plus

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

En savoir plus