Paiements en 2021 : pas le temps de relâcher

Une année difficile s’achève pour les prestataires de services de paiement européens. Dans ce secteur aussi, la pandémie liée au coronavirus était le thème déterminant. Dans les paiements individuels, comprenant les paiements interbancaires et internationaux, le coronavirus est en partie responsable du report de la consolidation de TARGET2 et de la conversion de SWIFT ISO 20022. Pour les paiements par carte, la pandémie a eu des effets négatifs, mais aussi positifs : D'une part, le coronavirus a entraîné une augmentation considérable des transactions par carte et surtout sans contact. Une telle évolution aurait normalement duré plusieurs années et elle aurait entraîné des investissements importants dans le marketing des principaux systèmes de cartes. D'autre part, de nombreux acteurs du marché des cartes ont subi des baisses massives de ventes, en particulier ceux qui sont fortement impliqués dans le secteur de la gastronomie, des voyages et des événements. 

Ceux qui pensent que le secteur des paiements aura un répit en 2021 se trompent. Après tout, deux projets concrets seront mis en œuvre l'année prochaine. D'autres projets doivent déjà être préparés, même si la mise sur le marché n'est prévue qu'en 2022 ou encore plus tard. Considérant les énormes bouleversements structurels du marché, il semble que le secteur se trouve face à une ascension des Alpes dans des conditions difficiles.

Mais une chose à la fois : Parmi les thèmes concrets de l'année prochaine figurent la mise en place de la demande de paiement (Request to Pay ou RTP). Avec le lancement de cette norme en été 2021, les paiements seront complétés par un élément important (voir également notre livre blanc, parties 1 et 2). De nombreuses entreprises ont longtemps exigé du secteur des services financiers de faire progresser rapidement le développement et l’expansion de la demande de paiement (voir également l'enquête de l'EBA). En effet, RTP comble les lacunes en matière d'application dans les procédures existantes ou entre celles-ci. Cela inclut la connexion éventuelle des données de facturation et des données de paiement. Ce procédé facilite considérablement les processus de rapprochement dans les systèmes comptables de nombreuses entreprises. En plus, cela permet d’accepter des paiements par voie électronique au point de vente (POS) sans terminal - une possibilité qui n’existait pas jusqu’à présent. La configuration d'un point de vente devient plus facile et plus mobile grâce à RTP. 

Afin de pénétrer davantage le marché des virements en temps réel conformément au scheme SCT Inst, le Conseil de la BCE a décidé que tous les prestataires de services de paiement accessibles via TARGET2 participants à scheme SCT Inst doivent être accessibles via TIPS (TARGET instant Payment Settlement). Par conséquent, l'accessibilité via TIPS doit être assurée soit par une participation directe avec le compte de l’utilisateur, soit par la fonctionnalité « Reachable Party ». En outre, tous les ACH (Automated Clearing Houses) qui offrent des paiements instantanés doivent transférer leurs comptes techniques de TARGET2 à TIPS. La mise en œuvre des décisions est prévue pour la fin de l’année 2021. 

Enfin, tous les thèmes de 2021 ne demandent pas aux prestataires de services de paiement une si grande efficacité : Les exigences d'adaptation découlant des changements apportés par l’EPC en novembre sont plutôt gérables. En revanche, personne ne sait si cela s’applique également aux changements apportés à l’EDI et à SWIFT. Cependant, c’est très probable, du moins pour les transactions financières proprement dites. D’importantes échéances réglementaires ne sont pas non plus en vue.

Toutefois, il reste bien sûr tous les projets de paiements qui doivent être mis en œuvre en 2022 et les années à venir - et qui doivent donc être préparés en 2021. L'un des projets les plus importants est la transition des paiements au format ISO 20022 à l’échelle mondiale.

Dans les paiements individuels, par exemple, il faut préparer la transition à TARGET2 qui est prévue pour 2022 et le passage à SWIFT qui commence en 2022. Dans les deux domaines, outre le simple changement de format, des modifications importantes des processus doivent être exécutées, telles que la modification des mécanismes d'accès aux plateformes correspondantes. Selon des estimations unanimes, chacun de ces projets dépasse les dimensions du SEPA. 

En ce qui concerne les paiements de détail (SEPA), les prestataires de services de paiement doivent se préparer à la transition des schemes SEPA vers la (nouvelle) version ISO 2019, prévue pour 2023.
Compte tenu des coûts liés à ces conversions, les institutions financières – principalement les institutions de niveau 2 – externaliseront en 2021 de plus en plus le traitement des paiements ou, du moins, achèteront des logiciels de paiement en tant que service. La demande dans ce sens est déjà perceptible. En outre, il est probable que les voix qui réclament des offres centralisées pour les services interbancaires, tels que le filtrage des sanctions ou le KYC, deviennent plus fortes.

En fin de compte, les institutions financières et les prestataires de services financiers doivent trouver des réponses aux nouveaux bouleversements structurels du marché en 2021 :

• La poursuite du développement de European Payment Initiative (EPI) : Est-il possible de créer une solution de paiement paneuropéenne unique et innovante comme alternative aux solutions et aux systèmes de paiement internationaux existants ?
• La pression croissante exercée par la Commission européenne et par le Parlement européen sur les redevances d'interchange : Comment les émetteurs peuvent-ils réagir à une éventuelle réglementation « zéro interchange » ? Quels sont les futurs modèles commerciaux ?
• L'obligation imminente de toutes les institutions financières imposée par le législateur européen d'offrir des paiements instantanés et de prendre davantage en compte les intérêts des consommateurs en ce qui concerne l’annulation des paiements instantanés. Les systèmes de traitement existants sont-ils en mesure de traiter des volumes supplémentaires ?
• La consolidation significative des prestataires de services de traitement, notamment la formation de deux conglomérats par EquensWordline d'une part et de NEXI/SIA/nets d'autre part : Qu'est-ce que cela signifie pour l'avenir des petits et moyens fournisseurs de services, notamment en matière d’acquisition ? 
• L’effacement progressif des frontières entre les paiements par carte et les paiements classiques, tels que les activités de Mastercard (via Vocalink) dans le cadre de la compensation des paiements classiques : Y aura-t-il une autre infrastructure de compensation à long terme dans les paiements de masse ? 
• L'introduction imminente de la monnaie numérique, sous forme de monnaie numérique de la Banque centrale, mais aussi sous forme de libra : Quel est l'impact de ces mesures sur les paiements en espèces ou par carte ? Qu'est-ce que cela signifie pour le rôle et le modèle commercial des institutions financières ?
• Les conséquences de l’expansion croissante de l'Internet des objets (Internet of Things) sur les paiements : Les potentiels de l'Internet des objets ne peuvent être exploités qu'avec des flux de paiement totalement autonomes et sans interruption entre les appareils connectés [voir notre étude sur l’Internet of Payments]. Comment répondre aux exigences de conformité et aux aspects de sécurité informatique ? Comment les systèmes de traitement doivent-ils être adaptés à des milliards de transactions supplémentaires ?

Le jour du nouvel an chinois 2021 marque le début de l'année du buffle. L'astrologie chinoise lui attribue la patience et la diligence. Il est fort et surmonte toutes les difficultés. Le secteur des paiements peut en faire bon usage.

Auteur : Hubertus von Poser (Head of Consulting Payments)

En savoir plus

La demande de paiement (Request to Pay ou RTP): une valeur ajoutée pour l'expérience client dans le commerce électronique ?

Jour après jour, de nombreux clients consultent les boutiques en ligne et ajoutent une variété d’articles à leurs paniers pour les acheter et donc payer. La dernière étape du parcours client, le processus de paiement, est un point très sensible des achats en ligne. À ce stade, le client, qui souhaite acheter un produit, attend une option de paiement à la fois adaptée à son besoin, simple et intuitive. Par conséquent, l'une des tâches les plus importantes du commerçant en ligne est de toujours offrir au client une variété d’options de paiement.

Selon une étude de l'EHI, l’achat sur facture, Paypal et le prélèvement ont été les trois principaux types de paiement moteurs de chiffre d’affaires sur le marché allemand du commerce électronique en 2019. Ils représentaient près des trois quarts du chiffre d'affaires (achat sur facture 32,8 %, Paypal 20,2 %, prélèvement 18,3 %) (source : https://www.ehi.org/de/studien/online-payment-2020/). En ce qui concerne l’achat sur facture, le commerçant en ligne envoie les marchandises commandées accompagnées d’une facture au client. Le client peut rapidement vérifier son achat, il lui est simplement demandé de régler la facture dans un délai précisé. En outre, jusqu’à la date limite de paiement, il a la possibilité de conserver puis payer les marchandises ou les renvoyer. Le type de paiement Paypal se distingue quant à lui par son processus de paiement rapide. Le client n'a qu'à se connecter avec son adresse e-mail enregistrée et peut terminer son achat. Le troisième type de paiement, le prélèvement, est une procédure bien connue et populaire. Le client autorise le commerçant en ligne à débiter le montant de la facture de son compte bancaire. Aucune étape supplémentaire n'est nécessaire. 

Alors pourquoi ces types de paiements sont-ils si populaires ? Tous les trois ont des caractéristiques similaires : Ils convainquent par une manipulation intuitive, la possibilité d'un processus de paiement rapide, une vue d’ensemble des paiements et une large acceptation par les commerçants.
Cependant, le processus des types de paiement susmentionnés se termine actuellement avec le règlement. Des informations supplémentaires telles que la facturation, les bons de garantie et les informations d'expédition (numéro de suivi) sont mises à la disposition du client à un moment ultérieur via le portail des commerçants ou par courrier électronique.
En fin de compte, il manque souvent un aperçu consolidé des détails de paiement des marchandises commandées, de la facture, de la garantie et des informations d'expédition dans le processus de vente en ligne actuel.

La demande de paiement pourrait-elle être la pièce manquante du puzzle pour une expérience client réussie dans le commerce électronique?

En considérant le processus de demande à paiement conçu, on peut en déduire les possibilités d'un processus de commande complet dans l'écosystème bancaire. Le processus suivant peut être déclenché au moyen de la demande de paiement: 

Figure : Processus RTP (source : propre représentation)

Une fois que le client a confirmé sa commande dans la boutique en ligne du commerçant, une demande de paiement électronique est lancée sous forme d'un enregistrement RTP par le commerçant. Cet enregistrement est automatiquement envoyé à l’institution financière du client, puis au client (débiteur). Les informations de paiement initiales telles que les factures et les informations d'expédition peuvent être jointes à l'enregistrement RTP ou être mises à la disposition du client à un moment ultérieur via un lien figurant sur l'enregistrement.
RTP offre au client (après réception de la demande de paiement) des possibilités d'action flexibles pour effectuer son paiement :

• Accepter maintenant et payer maintenant 
• Par exemple, l’achat d'un film dans une vidéothèque en ligne à regarder directement
• Accepter maintenant et payer plus tard 
• Par exemple, l’achat de chaussures à essayer
• Accepter plus tard et payer plus tard 
• Par exemple, l’expédition des marchandises avant le paiement. Les premiers commerçants testent actuellement l'expédition de la marchandise (par exemple des vêtements) au client, sans que celui-ci ne soit tenu de fournir les informations de paiement. Ce n'est qu'après un certain temps que le commerçant demande des données du règlement via une demande de paiement.

Si le client accepte la demande de paiement après la réception et paie directement avec un ordre de paiement (instantané), l’institution financière du client envoie une confirmation de paiement directe à la banque du commerçant. Le commerçant (bénéficiaire) reçoit à son tour de son institution financière la confirmation de la transaction. Le processus de la demande de paiement au règlement est ainsi terminé.
Ce processus de paiement proposé en l’état n’apporte aux consommateurs aucune valeur ajoutée significative par rapport aux trois types de paiement mentionnés plus tôt. En revanche, si ce processus de paiement dans l’application bancaire est enrichi par les informations de paiement telles que les factures, les bons de garantie et les informations d'expédition, l'écosystème bancaire devient l'archive centrale des commandes en ligne et crée une nouvelle expérience client.

En outre, pour que le processus de demande de paiement devienne un processus de paiement efficace dans le commerce électronique, les facteurs suivants doivent être pris en compte :

1. Acceptation (du commerçant) universelle des demandes de paiement électronique et des paiements
2. Intégration du processus entier dans l'écosystème bancaire existant (application bancaire)
3. Création d'options de paiement échelonné et de paiement à une date ultérieure
4. Possibilité de processus inversé, par exemple, en cas d’annulation ou de perte d’un colis
5. Extension de la transaction de paiement permettant ainsi une vue d'ensemble des achats, par exemple, par l’historique des factures, les numéros d'expédition et les bons de garantie

Compte tenu de ces facteurs et dans le cadre des paiements instantanés, la demande de paiement peut être la pièce manquante du puzzle pour une expérience client positive dans le commerce électronique. En fin de compte, la règle suivante s’applique : Pour une mise en œuvre réussie, une approche complète et centrée sur le client est nécessaire.

Auteur : Philipp Schröder

En savoir plus

De nouveaux formats de données et la nécessité d'une mise à jour d’EBICS pour la Suisse – que faut-il prendre en compte ?

Avec le document « EBICS 3.0 Swiss Market Practice Guidelines EBICS, Recommendations for implementing the EBICS standard in the Swiss financial services sector » (recommandations pour la mise en œuvre de la norme EBICS pour la place financière Suisse, disponible en allemand et en anglais) publié en juin 2020 par SIX, la Suisse se conforme désormais au protocole européen harmonisé. Les principaux moteurs de l'harmonisation ont été les membres de la société EBICS, notamment les places financières en Allemagne, en France et en Suisse (le membre le plus récent est l'Autriche).

Par définition, deux versions d'EBICS sont prises en charge en Suisse, c'est-à-dire la version 2.5 et la version 3.0. À première vue, on pourrait donc penser qu’il n’y a pas d’urgence pour les clients et les éditeurs de logiciels car la version précédente est encore disponible. Cependant, en Suisse, il existe le paragraphe 2.2.1 dans « EBICS Timeline », un document de SIX contenant la remarque suivante : La prise en charge de la migration de schéma ISO 20022 vers la version 2019 requiert l'utilisation d'EBICS 3.0.

Comme les professionnels bien informés le savent, la version ISO 2019 sera également introduite dans l'interface client-institution financière à partir de 2022 et les versions actuelles ne seront plus prises en charge à partir de 2024. Cela correspond à la tendance de la migration mondiale vers cette nouvelle version, par exemple dans les projets de migration SEPA, SWIFT MX ou TARGET2. Cette migration est importante, notamment pour l'introduction prévue des paiements instantanés en Suisse à partir de 2023.

La place financière suisse a donc choisi de lier la mise à niveau de la version EBICS à la mise à niveau de la version ISO. Dans ce contexte, les clients et les éditeurs de logiciels se posent quelques questions et font face à des défis qui ne doivent pas être sous-estimés. Les principaux points sont abordés dans les paragraphes suivants et, chaque fois que cela est possible, des solutions sont présentées.

EBICS 3.0 en Suisse au plus tard à partir de novembre 2021

La communication EBICS, désormais pleinement établie en Suisse, est une composante incontournable du secteur financier. Jusqu'à présent, la version 2.5 d'EBICS était proposée par la majorité des institutions financières suisses.

Comme mentionné précédemment, les « recommandations pour la mise en œuvre de la norme EBICS pour la place financière Suisse » (version 1.0 du 01/06/2020 de six, www.six-group.com) ont officiellement introduit la nouvelle version 3.0 EBICS en Suisse pour les activités des banques d'entreprise avec les institutions financières à partir de novembre 2021.

Définition de la Suisse pour le traitement des nouveaux opérations métier dans EBICS

Liée au lancement de la nouvelle version EBICS, la version précédente EBCIS 2.5 devrait être officiellement soutenue par les institutions financières jusqu’à la fin de l’année 2024. En outre, la réception des nouveaux formats suisses ISO 20022 dans la version 2019 requiert EBICS dans la version 3.0. Cela signifie pour les entreprises qui ont mis à jour leurs formats ISO suisses, qu’elles ne peuvent pas utiliser EBICS 2.5 sans adaptations supplémentaires.

Il est temps de planifier

Ces mises à jour exigent que les solutions logicielles soient planifiées et mises à jour en temps voulu. C’est alors au tour des institutions financières, des entreprises et des éditeurs de logiciels d’agir.

La mise à jour des formats de données ISO 20022 vers la version 2019 n'est qu’un aspect. En effet, il ne faut pas sous-estimer les modifications apportées au protocole EBICS qui doivent être mises en œuvre avec la version 3.0. Les plus importantes sont les suivantes :

• Le nouveau Business Transaction Format (BTF) remplace les types d’ordre et les paramètres FileFormat précédents.
• Le transport des clés publiques se fait désormais de manière uniforme avec des certificats.
• Les procédures cryptographiques sont améliorées.
• La gestion des clés bancaires est améliorée.
• Il existe des paramètres de commande supplémentaires pour la signature électronique.
• Une vérification de la double remise au niveau du fichier est disponible.

Comment gérer ces nouvelles exigences ?

Les institutions financières, mais également les éditeurs de logiciels des clients EBICS, doivent étendre leurs solutions logicielles à EBICS 3.0, afin de permettre aux entreprises d'effectuer des mises à jour et d’utiliser la solution à un stade précoce.

Toutes les spécificités d'EBICS 3.0 doivent être prises en compte dans le client et un fonctionnement parallèle des différentes versions EBICS pourrait être nécessaire selon l'accès bancaire et les utilisateurs EBICS. En outre, des options de migration d'EBICS devraient être proposées à l'utilisateur, en évitant autant que possible une réinitialisation (mot-clé : augmenter la longueur minimale des clés).

L'API EBICS – découpler la fonctionnalité métier du fonctionnement technique

Par notre propre expérience, nous savons chez PPI que la migration vers la version 3.0 n'est pas simplement un mapping des types d’ordres aux combinaisons BTF. Il y a beaucoup plus de problèmes à résoudre, et de tâches à reprogrammer. Cela s’applique en particulier si l’institution financière, le fabricant de logiciels et le client souhaitent effectuer cette migration de manière aussi automatisée que possible. PPI offre depuis des années TRAVIC-EBICS-Kernel, une solution API permettant une intégration dans les clients EBICS existants. C’est l’élément central pour gérer la communication EBICS en Europe avec presque la moitié des logiciels client EBICS.

Les nouvelles spécifications autour d'EBICS 3.0 sont déjà implémentées dans la nouvelle version. Correctement liée, l'API gère l'eBanking avec EBICS de manière transparente dans toutes ses versions et dans toutes ses formes pour le client. TRAVIC-EBICS-Kernel décharge ainsi l'éditeur de logiciels d'applications pour l’eBanking et pour le paiement lors de la mise en œuvre du protocole standard et de sa syntaxe, ainsi que des procédures de sécurité. Le progiciel correspond à la spécification EBICS et offre une interface facile à intégrer, permettant aux éditeurs de logiciels de l'intégrer dans les produits logiciels existants en tant que module de communication confortable et rapide à utiliser.

Considérant le rapport entre les coûts et les revenus lors de l'intégration de TRAVIC-EBICS-Kernel, il n'est pas surprenant que ce produit soit un tel best-seller. Les éditeurs de logiciels qui n'utilisent pas TRAVIC-EBICS-Kernel peuvent nous contacter à tout moment et demander une licence de test. C’est le moment idéal avant la prochaine migration vers EBICS 3.0.

Auteurs : Carsten Miehling et Michael Lembcke

Pour plus d’informations: Parlez-vous EBICS 3.0?

En savoir plus

Configurer EBICS – de manière aisée et pas à pas

En tant que standard, EBICS permet une vraie fluidité des transferts de paiements en Europe, avec une sécurité maximale. Cependant, cela exige également l’implication de toutes les parties concernées. L'initialisation et la configuration des accès bancaires, des participants et des droits EBICS sont nécessaires et requièrent de la prudence lors du processus de configuration. L’optimisation du potentiel élevé du fonctionnement multibancaire exige la répétition d’étapes qui sont normalement opérées à différents endroits et exécutées de manière décentralisée. Remplacer les applications complexes et interconnectées par des séquences linéaires et simples pour les usagers est un véritable enjeu dans l’art de concevoir des logiciels orientés utilisateurs.
L'assistant de configuration compact que PPI a développé pour son portail client TRAVIC-Port prouve que cela peut être effectué de manière pratique, simple et rapide. Ce sont les administrateurs qui sont ciblés du côté client - car le libre-service est un atout majeur dans les relations modernes entre le client et l'institution financière. En permettant un accès direct aux processus d'administration essentiels, on crée des processus rapides sans passer par le fournisseur.

Il est vrai qu’il vous faudra un certain nombre de clics pour créer un nouvel utilisateur EBICS, mais vous serez guidé pas à pas. Cela est également le cas pour la gamme de produits PPI, à savoir TRAVIC-Port. Le système demande de chaque utilisateur un identifiant, les données de base, le mot de passe initial ainsi qu’un dispositif de sécurité utilisé pour les connexions futures. Chaque utilisateur assume par ailleurs plusieurs rôles, dispose d’autorisations différentes et possède souvent plus d’un compte bancaire. Du fait que TRAVIC-Port est un système multibanque, il est nécessaire de créer également les accès bancaires respectifs. Souvent, la banque principale prend en charge cette tâche pour ses clients entreprises EBICS – et cela signifie en règle générale de longs appels téléphoniques pendant lesquels l’employé de la banque demande toutes ces informations.

L'utilisateur du portail trouve une nouvelle entrée directement sur la page d’accueil (voir fig. 1). À l'aide de ce lien, il accède directement à l'assistant de configuration, ce qui facilite considérablement l'entrée dans le monde sécurisé d'EBICS. À l’aide de dialogues, un assistant demande toutes les données nécessaires pour créer un nouvel utilisateur EBICS.

L’assistant veille également à ce que les données soient toujours saisies aux bons endroits. C’est particulièrement pratique car le système configure l’agent de téléchargement, par exemple, via une autre rubrique que les accès bancaires et les utilisateurs. Bien que cela semble logique, il faut alterner entre de nombreux onglets et rubriques, ce qui demande plus de temps. Les fenêtres de dialogue dans l'assistant de configuration évitent les oublis de données importantes et permettent également de voir d’un coup d’œil les informations réellement nécessaires. Par exemple, la première action à faire est de configurer un nouvel accès bancaire – que ce soit fait par l’institution financière ou par l’administrateur du côté client n’a aucune importance. Le dialogue demande toutes les informations pertinentes et indique le travail qui reste à accomplir. Pour un accès bancaire, il s’agit de sept dialogues à traiter (voir fig. 2).

Une fois que tous les accès bancaires sont configurés, on passe aux utilisateurs. Un petit cabinet d’avocats, par exemple, souhaite configurer une autorisation de compte pour le propriétaire, deux avocats salariés et un assistant – avec des autorisations différentes pour chaque personne. La gérante souhaite bien sûr avoir tous les droits, pouvoir commander et valider les transactions sans limite et valider des transactions via une signature électronique disjointe pour ses collègues. En revanche, les deux avocats salariés sont autorisés à valider eux-mêmes des transactions jusqu’à un certain montant – et l’assistant peut saisir des paiements mais ne peut pas les valider. Tous les quatre doivent pouvoir consulter les relevés de compte qui sont téléchargés depuis le serveur bancaire EBICS. Tout cela est facilité par un dialogue qui permet de créer des nouveaux collègues pour un client entreprise déjà créé (voir fig. 3).

Le démarrage et l'utilisation d'EBICS dans les paiements peuvent donc très bien être simplifiés, sans sacrifier la sécurité et le respect des standards. L'assistant de configuration a été éprouvé en conditions réelles et utilisé par des grands clients importants. Si vous souhaitez en savoir plus sur cette fonctionnalité de TRAVIC-Port, veuillez nous contacter. Ensemble, nous faciliterons EBICS.


Auteur : Christian Veith

En savoir plus

SWIFT gpi - de l’obligation à l’opportunité

La version SWIFT prévue pour novembre 2020 ne requiert pour une fois aucun changement de format pour les transactions financières. Ceux-ci ont été reportés à l’année prochaine, en raison de la pandémie mondiale de la maladie à coronavirus. Cependant, la demande d’une « confirmation universelle » dans le cadre de SWIFT gpi n’a pas changé. En termes simples, cela signifie que tous les participants à FIN doivent annoncer le crédit sur le compte du bénéficiaire au traqueur de SWIFT au format MT103. Les rejets doivent également être annoncés, en revanche cela ne dispense pas le retour. Le secteur bancaire doit encore une fois faire face à un cadre réglementaire contraignant, ce qui signifie moins de ressources pour les projets des clients. Mais faut-il que ce soit ainsi ? Pour répondre à cette question, voyons d’abord ce que signifie SWIFT gpi.

Depuis 2016, le thème SWIFT gpi (global payment innovation) gagne en importance. L’aspect le plus important est une référence unique UETR (unique end-to-end-reference), qui est ajoutée au paiement en début de chaîne de traitement de la banque du correspondant et conservée dans toutes les stations. Cela permet le suivi des paiements requis depuis longtemps dans l’AZV (paiements internationaux). Les informations sont collectées dans le traqueur. Le traqueur est une base de données centrale dans le nuage FIN chez SWIFT, qui lit automatiquement les informations nécessaires pour chaque paiement dans FIN et qui est complétée par d’autres messages des banques gpi.

Au début, l’UETR n’existait qu’au sein du CUG (closed user group) des institutions financières participant à l’initiative gpi et ce uniquement pour les paiements de clients (MT103). Le service standard est également appelé gCCT (gpi for Corporate Credit Transfer), rapidement complété par gCOV (gpi for Cover Payments). Après avoir traité uniquement les paiements de clients (MT103), toutes les institutions financières FIN sont désormais obligées, depuis 2018, de s’appuyer sur l’UETR pour les paiements de banque à banque (MT202/205) – c’est-à-dire pour tous les paiements. Les premiers effets positifs peuvent être remontés. Grâce à l’UETR il est désormais possible d’affirmer que « 40 % des paiements gpi sont définitifs dans les 5 minutes » ou que « 75 % des paiements gpi sont réalisés dans les 6 heures ». Avant, il n’y avait que des exemples des paiements qui arrivaient très tard (ou pas du tout) ou sans motif de paiement, mais avec des frais élevés (y compris OUR), ce qui a entraîné de nombreuses plaintes avec des demandes d’enquêtes associées. Un effet inattendu de l’introduction gpi a été la réduction considérable des demandes d’enquête.

Une institution financière gpi s’engage à un traitement le jour même si possible, à renoncer à la déduction des frais pour OUR, à transmettre le motif de paiement dans son intégralité et sans modifications (comme pour SEPA) – ce qui paraît être évident – et bien sûr à échanger des informations (si possible en temps réel) avec le traqueur non seulement sur le statut mais également sur les frais et les cours. Ces informations sont ensuite mises à la disposition de la banque du payeur agissant comme institution financière gpi. De cette manière, un autre problème de l’AZV – le manque de transparence des frais – peut être résolu. Ces avantages – et surtout ces informations – peuvent ensuite être communiqués au payeur.

Il y a aussi le thème des annulations. Si nécessaire, il devrait également être possible d’arrêter un paiement à tout moment de la chaîne du traitement bancaire. Mais de la même façon que le paiement se réalise tout au long de la chaîne, le message de rappel est également traité étape par étape par chacune des institutions financières concernées. C’est ici qu’intervient le service supplémentaire gpi gSRP (gpi Stop and Recall Payments). L’annulation est signalée au traqueur et la tentative suivante d’envoi du paiement avec l’UETR correspondant à FIN est rejetée. La longue chaîne est ignorée.

Aujourd’hui, avec la confirmation universelle, le processus est complètement transparent. De cette façon, l’institution financière du payeur reçoit non seulement l’information « paiement arrivé à la dernière institution financière de la chaîne FIN » mais aussi le statut « paiement arrivé au bénéficiaire ». Une telle confirmation faisait partie intégrante de la définition des paiements instantanés SEPA, mais c’était près de 50 ans après les premiers messages SWIFT.

Les institutions financières FIN sont désormais obligées d’envoyer une confirmation universelle. Cela ne s’applique qu’aux paiements de clients (MT103) et non à toutes les réceptions de paiements (M202/205). Les messages doivent également être envoyés pour les entrées TARGET2, car ils sont transportés via FINCopy. En bonus, l’accès web (manuel) à ce traqueur, qui n’était auparavant disponible que pour les institutions financières gpi.

L’institution financière a jusqu’à 2 jours ouvrables (certains jours fériés sont alors exclus) pour envoyer la confirmation universelle. Ce SLA sera mesuré et la bonne gestion des autres institutions financières reportée, mais cela ne devrait pas commencer avant la mi-2021. L’accès web au traqueur dépend également des bons comportements.

Les institutions financières traitant les plus petits volumes pourraient envisager l’utilisation d’un message manuel dans le traqueur. Pour les solutions automatisées, la plateforme de paiement devrait, par exemple, prendre en charge l’un des chemins offerts par SWIFT (MT199 ou API). En outre, il existe une solution dite CSV dans laquelle un certain rapport CSV dans l’interface SWIFT est utilisé pour générer les messages correspondants au traqueur.

Une institution financière qui ne fait pas partie de gpi doit alors répondre à presque toutes les exigences des institutions financières gpi. L’étape manquante n’est plus aussi grande mais le bénéfice pour vos propres clients peut être énorme. Grâce aux possibilités de gpi pour les paiements de banques à banques (MT202/205 – appelé gFIT, Financial Institution Transfer service, une option pour les institutions financières gpi), les départements internes de la banque tels que la trésorerie ou le marché monétaire peuvent également profiter de la sécurité que le « paiement est arrivé ».

Toutefois, il n’est pas aussi important pour l’institution financière de recevoir les messages de statut du traqueur pour les paiements envoyés, que d’offrir au client un service à forte valeur ajoutée – dans le meilleur des cas, la confirmation « paiement arrivé » (y compris l’information sur les frais et les cours de change). Les niveaux de service qu’une institution financière peut offrir s’étendent de l’option minimale de l’accès manuel au traqueur dans la hotline (propre à l’entreprise) jusqu’aux offres de libre-service dans le portail bancaire en ligne, en passant par l’information active par le message de statut envoyé à l’entreprise. Et cela n’est possible qu’en optant pour la confirmation universelle au service standard gpi et le gpi. C’est la nouvelle référence pour les institutions financières.

Une coopération interservices est alors nécessaire. Les services ne peuvent pas être fournis seuls par le département de paiement ou par le service informatique même, comme c’est souvent prévu pour les projets « réglementaires » dans le cas d’une nouvelle version SWIFT. Cela peut être réalisé grâce à une consultation qui inclut le processus entier.

En résumé, on peut donc constater qu’il n’y a qu’un pas entre les exigences règlementaires et les immenses opportunités, et que les perspectives de services supplémentaires pour les entreprises et les services internes des institutions financières sont énormes.



Auteur : Mario Reichel

En savoir plus

ISO 20022 – plus actuel que jamais malgré le report

Les dés sont jetés : le 27 juillet 2020, la BCE a rejoint le vote de la communauté bancaire européenne et a accepté de reporter d'un an la date de mise en service de la consolidation de T2 et T2S à novembre 2022. De même, la date de la migration de Eurosystem Collateral Management System (ECMS) a été reportée de novembre 2022 à juin 2023, au plus tôt.

Dans le sondage réalisé en mai, les banques européennes avaient préconisé de reporter la migration. Outre les effets de la pandémie du Corona, la raison principale est le report de la migration ISO pour les paiements internationaux, déjà annoncé par SWIFT. Dans de nombreuses banques, les deux scénarios de migration convergent en un seul projet, car il n'est tout simplement pas possible de séparer les paiements via TARGET2 des paiements internationaux. Ce sont surtout les grandes banques ayant une activité de correspondance bancaire étendue qui ont vu de grands risques dans une divergence des dates de migration. Grâce à cette décision, les deux dates coïncident. EBA Clearing s'est également joint à la décision et a reporté sa migration en 2022.

Le soulagement du report était certes formidable - mais que signifie cette décision pour les institutions financières et pour leurs projets ? Que les institutions financières profitent de cette année supplémentaire pour se relâcher et ralentir la mise en œuvre de leurs projets serait la pire chose qui puisse arriver. De nombreuses institutions financières ont sous-estimé l'effort que le passage à TARGET2 exigera. Au contraire, le report offre l’opportunité de rattraper le temps perdu en œuvrant à plein régime. Faire marche arrière et reprendre le processus début 2021 n’est pas une option envisageable. Il faut également noter que la phase de démarrage des tests utilisateurs a été reportée de neuf mois seulement, de mars 2021 à décembre 2021. Déployer des ressources externes signifiera que les employés qui ont acquis les connaissances en travaillant précédemment sur les projets ne seront plus disponibles.

Il faut également prendre en compte que les spécifications qui ont déjà fait l'objet de deux adaptations cette année, continueront à l’être. La BCE doit toujours traiter les demandes de changement en attente non prévues pour la migration de novembre 2021. Cela va certainement changer avec le report. Il faut s'attendre à ce que les nouvelles UDFS publiées en novembre offrent des fonctionnalités supplémentaires qui devront être évaluées et implémentées.

L'image cible de SWIFT n'est pas non plus clairement définie. Jusqu'à présent, il est prévu qu'une plateforme pour la gestion des transactions soit développée pour servir de « hub » pour traiter les paiements internationaux. Il n'existe pas encore de spécifications publiées à ce sujet. En outre, de nouveaux types de messages ISO sont actuellement en cours de définition, par exemple pour les frais et les chèques, qui doivent également être pris en compte et mis en œuvre. La prochaine migration d'ISO est alors toujours changeante avec encore beaucoup d’incertitude à ce sujet. Ne devrait-on pas se demander si SWIFT décalera encore la migration à plus tard ? Quelle serait alors la réaction de la BCE ? Pourrait-on encore reporter TARGET2 ou serait-on alors obligé d’accepter une divergence des dates de migration ? Comment gérer les changements dans les formats de message déjà harmonisés, comme pacs.004 ?

Mais ce n'est pas tout, car la décision de la BCE concernant les paiements instantanés fait également sensation. Sur la base de discussions avec les participants du marché d'AMI-Pay, le Conseil de la BCE a décidé que tous les PSP qui ont souscrit à SCT Inst Scheme (c'est-à-dire paiements instantanés) et qui sont accessibles dans TARGET2, doivent être accessibles également dans TIPS. De plus, tous les ACH qui offrent des paiements instantanés doivent transférer les comptes techniques de TARGET2 à TIPS. La mise en œuvre est prévue pour la fin de l'année 2021. De cette manière, la BCE rend TIPS pratiquement obligatoire pour ceux qui participent déjà aujourd'hui aux paiements instantanés. C’est important car un grand nombre d'institutions financières utilisent désormais la procédure RT1 de l'EBA.

De plus, pour l’heure seule la décision a été prise et annoncée. D'autres données comme les détails techniques sont encore inconnues et seront publiées plus tard. Cela soulève la question du futur modèle tarifaire, en particulier si des frais sont facturés pour les transactions ACH cross. À quoi peuvent ressembler les frais de transaction et quel impact auront-ils sur la tarification des chambres de compensation ? Se pose également la question de l’existence d’un risque accru pour le règlement des positions telles que RT1, car avec TIPS un participant supplémentaire doit être intégré dans la chaîne.

Enfin, SEPA migre également vers la nouvelle version ISO 2019 en 2023 selon les plans actuellement annoncés de l'EPC. L'intervalle actuel d'un par rapport à la migration de TARGET2 et SWIFT peut sembler long, mais là aussi, il faut lire les spécifications, créer des concepts techniques et préparer les systèmes à l'avance. Malgré le report connu à 2023, cette migration ne doit pas non plus être sous-estimée, et nous recommandons d'aborder ce sujet le plus tôt possible.

Comme on peut le voir, les trois prochaines années apportera des différents sujets relatifs à ISO 20022 aux institutions financières et chacune devrait utiliser le temps gagné grâce au report pour redéfinir leurs priorités.

Cela nécessite un savoir-faire très spécifique et d’éviter les excès budgétaires à court terme des ressources qui seront à nouveau nécessaires de manière urgente en 2021.

Auteurs : Sabine Aigner, Thomas Ambühler

En savoir plus

Moins de stress grâce à un « libre-service EBICS » ?

Dans mon dernier article EBICS sur mon blog, j'ai parlé des problèmes auxquels les nouveaux clients EBICS sont confrontés lors de l'initialisation (et comment on pourrait les résoudre). Ce qui rend la situation encore plus difficile, c'est que les nouveaux clients n'ont pas ces problèmes une seule fois – la même procédure est répétée pour chaque participant à EBICS.

Est-ce nécessaire ? Que se passerait-il si le premier utilisateur EBICS connecté, pour ainsi dire l'utilisateur 0, avait le droit de créer d'autres participants – et de les authentifier immédiatement ? Comment cela fonctionnerait-il ?

Imaginons un nouveau type d'ordre EBICS administratif que l'on appellerait HUC (EBICS User Create) par exemple. HUC serait un type d’ordre upload, le message EBICS contenu contiendrait les données de base du nouvel utilisateur EBICS ainsi que ses trois certificats. Le message est signé par l'utilisateur 0. Grâce à ces données et à la signature, le serveur EBICS peut immédiatement configurer le participant, les ordres INI et HIA, les lettres et les délais d'attente sont supprimés. Sans aucun problème d'initialisation, un autre utilisateur est configuré et prêt à travailler. Il existe des indicateurs pour la nécessité d'un tel « libre-service EBICS » côté client : après tout, avec EBAM tout est mis en œuvre pour permettre un service très similaire pour les comptes.

Si cela était aussi simple, on l'aurait probablement déjà fait. Deux questions sont inévitables :

1. Comment contrôler un participant EBICS aussi puissant que l'utilisateur 0 ?

2. Quelles sont les données de base nécessaires ?

La première question est facile à répondre : si EBICS est vraiment expert dans un domaine, c'est le contrôle des autorisations. Afin d'éviter qu'un utilisateur 0 ne devienne trop puissant, on crée un utilisateur 1 dès le début et on spécifie qu'un ordre HUC requière plusieurs signatures. De cette façon on obtient un principe de double contrôle et on peut configurer de manière très détaillée qui est autorisé à créer d'autres employés, en utilisant les mécanismes connus des signatures E, A ou B.

La question beaucoup plus délicate est celle des données de base nécessaires. La plupart des personnes impliquées reconnaissent qu'un nom est probablement nécessaire, mais pour le reste, c’est plus difficile. Voulons-nous connaître l'adresse, le numéro de téléphone et l'adresse e-mail de l'utilisateur ? Ces informations peuvent-elles même être obligatoires ? Ou préférons-nous ne pas nous encombrer de données personnelles inutiles à cause du Règlement général sur la protection des données ? Jusqu'à présent, chaque institution financière pouvait prendre la décision elle-même, mais HUC définirait un standard pour toutes les banques. Après tout, il n'est pas utile qu'un standard se compose essentiellement d'un grand nombre de champs facultatifs. Dans ce cas, les institutions financières auront à se mettre d'accord sur un ensemble cohérent de données obligatoires.

La difficulté de ce processus est visible dans EBICS même dans les types d'ordre HKD et HDT. Concus pour permettre à un système client de collecter des informations sur les clients, ses utilisateurs EBICS et leurs autorisations, ces deux types d'ordre restent vagues, car il n'a pas été possible de concilier les modèles d'autorisation développés originaux des différentes banques. Au contraire, de nombreuses institutions financières considèrent leur degré de liberté dans la distribution des droits comme un argument clé de vente. Cela n'est pas compatible avec la normalisation.

C'est pourquoi il semble que les modèles de droits incohérents soient la fin prématurée et certaine d'un libre-service EBICS. Mais il se peut que ce ne soit pas le cas. En réalité la banque nécessite de nombreuses possibilités de distribution de droits pour satisfaire tous ses clients, le client individuel n'en a pas forcément besoin, ou du moins pas tous en même temps. Mais combien de rôles existe-t-il pour une entreprise typique ? Il y a ceux qui peuvent soumettre des ordres mais qui ne peuvent pas les autoriser, ceux qui ont un pouvoir de signature limité ou étendu pour tel ou tel compte, et puis il y a ceux qui sont autorisés à créer des nouveaux utilisateurs. Au total, il une poignée de rôles sont créés lors de la mise en place de l'accord EBICS, parmi lesquels un seul a accès à l’intégralité de la configuration d'autorisations de l'institution financière. Le rôle est ensuite doté d'un nom que le client peut utiliser (par exemple signataire) et qu'il peut ensuite indiquer dans sa requête HUC pour le nouveau représentant.

Un tel modèle de rôle présente encore plus d'avantages. Le rôle peut être adapté aux nouvelles conditions de l'entreprise (un compte a été ajouté) sans devoir consulter les autorisations de tous les participants. Les rôles peuvent également être redistribués. De plus, il est plus facile d'avoir une vue d'ensemble sur les utilisateurs et leurs rôles et donc l'autorisation associée.

Tandis que la définition des rôles restera inévitablement manuelle, l'affectation des rôles peut être faite dans le libre-service d'EBICS. Pour compléter le libre-service, il manque, outre la création, également la possibilité de lire, modifier et supprimer des utilisateurs, c'est-à-dire le R, U et D de CRUD. Les types d'ordre associés peuvent alors être appelés HUR, HUU et HUD. On aurait alors un premier lancement prometteur pour le libre-service EBICS.

Et les problèmes d'initialisation disparaitraient presque complètement.


Auteur: Curd Reinert

En savoir plus

EBICS et VEU : La limite des paiements de salaire contenant des informations confidentielles

Pendant de nombreuses années, la signature électronique distribuée (VEU) a été une fonctionnalité importante utilisée par diverses personnes pour télécharger et effectuer des paiements, même à partir de différents endroits.

Les types d'ordre et leur contenu commercial prévus à cet effet à partir du protocole EBICS permettent une validation basée sur le total des données disponibles - via la note d'accompagnement - ou sur la base des données de paiement du contenu. À cette fin, les serveurs EBICS fournissent les informations très importantes pour chacun des paiements uniques contenus déjà sous format préétabli. Un système client qui doit afficher ces données ne doit même pas connaître le format de paiement spécifique. C'est ce qui rend le logiciel si pratique. Exceptionnellement, même un dossier de paiement complet peut être transmis. Cependant, quand il est question des paiements de masse, la facilité décrite ci-dessus n’est plus d’actualité.

Dans la pratique des paiements, non seulement les paiements simples et les prélèvements sont inclus dans le dossier de signatures électroniques, mais les paiements spéciaux contenant des données très personnelles qui nécessitent une protection spéciale doivent également être inclus. Cela comprend les pensions et les salaires ainsi que les primes et gratifications qui ne sont pas destinées au grand public et certainement pas destinée à la libre consultation des salariés dans l’entreprise.

C'est surtout ici que la spécification EBICS montre ses limites : Il manque le GVC ou Code (Purpose), qui spécifie le type de paiement, si les paiements unitaires sont transférés. Les produits EBICS utilisés par le client ne sont pas aptes à protéger les données confidentielles dans un ordre de paiement, même si les entreprises le souhaitaient. Le logiciel n'a pas de critère pour décider si les détails du paiement doivent être affichés ou masqués.

Sans identifiant dans l'ordre de paiement spécifique, il n'est pas possible de distinguer les paiements confidentiels des paiements normaux. Cela signifie que la VEU n'est en principe pas apte à vérifier et à effectuer les paiements de salaire par VEU, car il ne peut être exclu que des employés non autorisés jettent un coup d'œil aux informations strictement confidentielles.

La société EBICS devrait donc envisager une extension du XML pour le HVT, qui transmettra également ces informations importantes concernant le type de paiement. Tant que cela ne se produit pas, la VEU ne peut être utilisée pour les paiements de salaire que dans une mesure limitée.

Auteur : Michael Schunk

En savoir plus

EBICS: Tous les débuts sont difficiles

Le premier contact que les nouveaux clients ont avec EBICS est généralement le processus d’initialisation. C’est d’une certaine façon dommage, car leur expérience EBICS commence par la partie probablement la plus compliquée et la moins intuitive. Et lorsque ces nouveaux clients auront enfin réussi à se débrouiller avec leur propre technologie réseau, les proxies, les pare-feux et le TLS, à transférer correctement les données du formulaire des paramètres bancaires dans l’application, qui, espérons-le, les a guidés de manière aussi simple et intuitive que possible à travers l’envoi des deux messages d’initialisation, ils seront alors surpris de découvrir qu’ils ne sont en aucun cas enfin prêts à utiliser EBICS. Au lieu de cela, ils doivent d’abord imprimer une lettre INI de plusieurs pages, la signer et l’envoyer à leur institution financière. Et attendre. Attendre que la lettre leur parvienne et qu’un employé de l’institution financière ait entré les 192 chiffres hexadécimaux des valeurs de hachage des trois clés EBICS dans l’ordinateur bancaire. Vraisemblablement toujours conformément au principe du double contrôle.

Si cela est fait - et il n’y a, en règle générale, aucune indication si ce procédé est terminé, ni quand il l’est - les nouveaux clients peuvent enfin commencer à utiliser l’EBICS. Ou presque. Avant cela, ils doivent d’abord avoir récupéré les clés bancaires et confirmé leurs valeurs de hachage qui, espérons-le, seront soigneusement comparées avec celles du formulaire des paramètres bancaires.

Après le traumatisme de l’initialisation première, le reste ressemble pratiquement à une promenade de santé. Dans de nombreuses applications, les clés propres au client peuvent être renouvelées par un simple clic. Les nouvelles clés bancaires peuvent désormais être signées avec les anciennes et acceptées automatiquement. Le véritable inconvénient consiste dans l’obligation - pour toute raison - de se réinitialiser complètement.

En France, la situation est (légèrement) meilleure

Les clients français d’EBICS qui lisent ce blog se demandent peut-être de quoi je parle. Le réseau et le TLS ne sont pas plus faciles à gérer en France qu’ailleurs et les informations du formulaire des paramètres bancaires doivent être saisies, mais au moins l’échange des clés EBICS est aussi simple que possible grâce aux certificats basés sur les AC : Le participant envoie ses clés sous forme de certificats que l’institution financière peut valider et libérer directement sur la base de la signature de l’Autorité de certification émettrice. Le client EBICS peut donc récupérer immédiatement les clés bancaires sous forme de certificats. Et si ces certificats ont également été émis par une AC et que le client fait confiance à cette AC, plus rien ne s’oppose au lancement d’une communication EBICS.

Cette apparente facilité est bien sûr quelque peu illusoire, car les certificats ne tombent pas du ciel. Le processus de certification n’est pas vraiment plus simple que l’initialisation EBICS car, là aussi, il faut que la personne et son identité numérique concordent en toute sécurité. L’avantage est que le processus n’est pas considéré comme faisant partie d’EBICS et il n’est donc pas imputé au protocole. Bien sûr, un certificat peut être utilisé à de nombreuses fins - l’initialisation EBICS, en revanche, n’est toujours valable que pour ce participant dans cette institution financière.

Je ne développerai pas non plus le fait que les certificats entraînent également d’autres problèmes tels que les coûts réguliers de renouvellement, le problème de s’accorder sur une liste d’AC fiables aussi globalement que possible et des scénarios d’échec s’il n’y a qu’un seul fournisseur généralement reconnu pour la vérification en ligne des certificats.

Cela reste donc difficile, mais nous pensons que la situation ne doit pas rester ainsi. Lors d’une séance de brainstorming, nous avons trouvé deux idées que nous aimerions présenter ici - au risque qu’elles se révèlent complètement déconnectées en pratique.

Option 1 : Face-à-face

Notre première idée est que le futur utilisateur d’EBICS prenne rendez-vous avec son conseiller bancaire afin que ce dernier active l’initialisation EBICS. Pendant que le conseiller saisit les données nécessaires telles que le nom et l’adresse, l’identifiant du client et du participant dans le système, au moment opportun, l’utilisateur saisit un mot de passe unique choisi librement – à saisir comme d’habitude deux fois afin d’exclure les fautes de frappe. L’utilisateur doit bien entendu se souvenir du mot de passe jusqu’à ce qu’il se connecte à son client EBICS, puis le saisir à nouveau lors de la configuration de l’accès bancaire. En utilisant le mot de passe, une clé symétrique est alors générée avec laquelle le message d’initialisation - qui contient les trois clés EBICS - est chiffré. Comme l’ordinateur de la banque connaît le mot de passe, il peut générer la même clé symétrique et la communication est protégée contre les écoutes, les manipulations et même les attaques de type « man-in-the-middle ». Par conséquent, le serveur peut renvoyer les clés bancaires directement dans la réponse. Le mot de passe d’initialisation n’est plus nécessaire (et ne doit pas être réutilisé pour des réinitialisations ultérieures).

Le résultat : un seul message EBICS après lequel l’utilisateur est complètement initialisé et prêt pour EBICS. Du côté de l’institution financière, les étapes manuelles après la configuration sont éliminées, le client ne doit pas envoyer de lettre et - surtout - ne doit pas attendre !

Deux problèmes potentiels viennent à l’esprit :

1. Un attaquant, qui connaît suffisamment bien l’institution financière et le participant, pourrait deviner l’identifiant du client et du participant ainsi que le mot de passe que le client a imaginé et se connecter lui-même avant le participant légitime. Un PIN, par exemple, qui est généré lors de la création du participant et qui lui est donné, ainsi qu’un verrou après n tentatives infructueuses peuvent protéger contre ce risque.
2. Les erreurs que le serveur signale lorsque quelqu’un devine de façon hasardeuse la clé pourraient permettre des attaques oracle. Là encore, il devrait être utile que le participant soit complètement bloqué après n tentatives infructueuses.

Ce problème pourrait alors être résolu.

Option 2 : Numérisation totale

L’option 1 reste encore trop proche de la situation actuelle : le client reçoit une feuille de papier sur laquelle les données sont indiquées, ensuite il saisit les données dans son application. Mais quel est l’intérêt ? Pourquoi ne pas donner au client ces données sous forme numérique ? Par exemple stockées dans une clé USB que le conseiller peut utiliser directement et remettre au client, qui peut la conserver par la suite, bien entendu avec l’empreinte publicitaire de l’institution financière. Sur la clé USB se trouverait alors un fichier contenant tout ce qui est nécessaire à la configuration :

• L’URL
• Les identifiants
• Une clé symétrique, avec laquelle on sécurise la communication initiale, comme dans l’option 1

Ici, bien sûr, il n’est pas nécessaire de tenir compte de ce dont une personne peut se souvenir ou doit taper, la clé peut être aussi longue que souhaité. Le risque d’une attaque consistant à deviner la clé est ainsi éliminé. Le plus grand danger reste que le client perde la clé USB en rentrant chez lui. Une protection du fichier par mot de passe peut aider dans ce cas.

En revanche, en arrivant chez lui avec la clé USB, il importe le fichier dans son application EBICS. Celui-ci reconnaît le format et peut ainsi établir immédiatement et de manière autonome l’accès bancaire complet - comme décrit dans l’option 1.

Que faire si mon système ne dispose pas d’un port USB ? Il s’agit par exemple d’un smartphone sur lequel je veux m’inscrire pour une application de signature. Dans ce cas, la solution de la clé USB n’est effectivement pas adaptée, mais il est possible d’utiliser les codes QR. Il suffit donc de lui fournir les données de cette manière. Ce peut être également la politique de l’entreprise qu’aucune clé USB ne soit utilisée, même si elle provient d’une source aussi fiable qu’une institution financière. On pourrait bien sûr penser à simplement envoyer le fichier par courriel. Et donc se demander immédiatement après l’intérêt de recourir à une clé USB. La réponse est probablement qu’il n’y en a pas, si (a) le fichier est sécurisé cryptographiquement avec un mot de passe suffisamment sûr et (b) le mot de passe n’est pas dans le même courrier, mais est transmis d’une autre manière sécurisée. Cela devrait être possible.

Atteindre l’objectif

L’initialisation peut être simplifiée. Mais pour que cette simplification soit utile, il ne suffit pas qu’une seule institution financière la mette en œuvre ou - plus absurde encore - un seul système client (fabricant). Ce n’est que si un tel changement est partie intégrante de la spécification EBICS qu’il pourra faciliter la vie des clients et des institutions financières. Dans ce cas la situation sera considérablement facilitée : pour le client, la configuration d’un accès bancaire n’est plus une difficulté et les institutions financières n’ont plus à taper des valeurs de hachage. Dans certains centres d’appel, des employés ne font que cela.

Si l’initialisation est aussi simplifiée, le fait qu’elle doive être effectuée individuellement pour chaque participant EBICS ne pose peut-être plus de problème. Mais là aussi, nous avons réfléchi à des moyens de simplification que j’aimerais présenter dans un prochain article de ce blog.


Auteur : Curd Reinert

En savoir plus