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

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

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

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

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

All goes ISO 20022

Ce titre fait référence à la migration à l'ISO 20022 pour tous les paiements ainsi que pour le reporting lié. Mon collègue René Keller a déjà écrit au sujet de la migration de TARGET2 et de SWIFT vers ISO 20022, standard déjà en vigueur pour les paiements SEPA, individuels et internationaux. Les modifications décrites, en particulier dans les paiements interbancaires ont des conséquences sur l'interface client-banque.

La pandémie liée au coronavirus affecte de nombreux domaines, et également dans les calendriers de migration. Les changements arrivent mais avec du retard. Il faut bien optimiser ce temps car il ne s'agit pas uniquement d'un sujet lié à l'informatique. La nouvelle norme entraîne des modifications importantes dans les processus de paiements et leurs domaines connexes et les impacts doivent être pris en compte dans l'architecture dans sa globalité. Cela concerne les institutions financières et les entreprises qui surmonteront de nombreux changements dans les versions à venir. Les informations contenues dans les communiqués sont maintenant disponibles dans l'annexe 3 de l'accord EDI (DFÜ) ; elles s'étendent sur quelques années, mais elles sont nécessaires.

Certains experts avancent l'argument selon lequel « les changements à venir ne sont pas si profonds, car nous connaissons déjà le format XML grâce à SEPA ». Si le format utilisé dans SEPA est déjà « bien connu », c'est un très bon point de départ pour se préparer aux changements. Mais l'enjeu est bien plus important. D'une part, SEPA est sur le point d'implémenter une nouvelle version, et d'autre part, il existe toute une série de particularités dans les paiements individuels et internationaux qui ne sont pas du tout présentes dans les paiements de masse. En outre, pour des raisons réglementaires, les coordonnées structurées seront utilisées à l’avenir. Le défi réside dans la multiplicité des changements.

camt.053 – Changement de version

Avec la mise en place de SEPA et du format harmonisé à l'échelle européenne basé sur l'ISO 20022, le relevé de compte camt.053 a également été introduit en plus de MT940 déjà connu. C’était le format idéal pour les paiements SEPA, car il était désormais possible de transférer les données d'un dictionnaire de données uniforme (data dictionary) via les formats pain (client-institution financière) et pacs (interbancaire) sous forme de relevés de compte. Toutefois, outre les écritures dans les paiements de masse, il y avait également des paiements individuels et internationaux. Pour cette raison (entre autres), de nombreuses entreprises ont conservé l'ancien format familier.

Cependant, l'introduction de l'ISO 20022 dans l'ensemble des paiements interbancaires se fait sur une version ISO actuelle, celle de 2019. SEPA utilise toujours la version ISO de 2009. Comme pour toute norme, il y a bien sûr différentes raisons pour l'ISO 20022 de poursuivre le développement du format, et il continuera d'y en avoir. De nouveaux champs seront introduits ou des mots de passe seront étendus. Le relevé de compte, qui doit transmettre toutes les nouvelles informations au client final sans perte de données, doit donc également respecter la nouvelle norme. La migration de camt.053.001.02 à la nouvelle version camt.053.001.08 est donc inévitable (de même pour camt.052 et camt.054). En informant les entreprises à un stade précoce, le délai est désormais suffisamment long pour les cycles de mises à jour ERP souvent plus longs. D’autant qu’il faut s'attendre à ce qu'un report de la migration TARGET2 à l'ISO 20022 retarde également cette migration.

Arrêt du MT940

SWIFT arrêtera les messages MT de catégories 1, 2 et 9 dans la communication interbancaire en novembre 2025. Au niveau de l'interface client-banque (notamment chez SCORE), cette restriction ne doit pas s'appliquer. À ce sujet, les banques du monde entier ne sont pas obligées de désactiver le MT101 ou même le MT940. Mais la DK (Deutsche Kreditwirtschaft) a décidé l'arrêt pour notre « standard multibancaire » - et c'est une bonne chose. Les institutions financières qui le souhaitent peuvent toujours proposer MT940, mais les avantages du nouveau standard sont évidents : des structures XML entières peuvent être transportées de pain via pacs à camt sans conversion. L'analogie avec les conteneurs dans le domaine de la logistique est manifeste. Toutes les entreprises devraient donc être « encouragées » vers ces avantages.

DTAZV devient pain.001

L'introduction de pain.001 comme ordre de client pour un virement SEPA a rapidement soulevé la question suivante : pourquoi ce format ne peut-il pas être utilisé également pour les paiements en devises ? L'initiative CGI-MP (Common Global Implementation – Market Practice) des entreprises, des institutions financières et des fabricants s'est rapidement créée pour harmoniser l'utilisation de ce standard global et définir une cartographie normalisée. Mais la version CGI de pain.001 est basée, comme la version SEPA, sur la version ISO 2009 - c'est-à-dire pain.001.001.03. Le CGI-MP travaille sur une nouvelle version (ISO release 2019) de la cartographie harmonisée. La nouvelle remise d’AZV dans l'annexe 3 sera également basée sur l'ISO 2019 - donc pain.001.001.09.

Enfin, comme souvent, la migration « all goes ISO 20022 » est aussi une grande opportunité, permettant des processus continus sur la même base de données qui peuvent être traités sans qu’une conversion soit nécessaire. La base de la numérisation dans le futur reste la normalisation. Avec « All goes ISO 20022 », les normes sont également valables pour les processus adjacents « Exception & Investigation » (questions), les avis, les messages de frais bancaires (Bank Service Billing camt.086) ainsi que dans le BAM (Bank Account Management) comme messages eBAM. Les transactions financières (y compris les relevés de compte) ne représentent donc qu'une petite partie de l'univers ISO.

Auteur : Mario Reichel

Inquiétude injustifiée concernant les logiciels standard dans les transactions financières

Ceux qui souhaitent se distinguer de la concurrence développent leurs propres logiciels. Cette règle s'impose de plus en plus dans les entreprises – et toujours plus « d'experts » recommandent aux institutions financières d'investir davantage dans leurs propres applications, ou mieux encore de devenir une entreprise technologique. Mais lorsqu’il s’agit de développer une plateforme pour paiement, ces principes se complexifient.

Les autorités exigent par exemple une continuité de service lorsque les institutions financières souhaitent mettre en place des paiements instantanés. Lors du développement de TRAVIC-Payment Hub, nous avons nous-mêmes expérimenté ce que ces exigences impliquent dans l'architecture d'un logiciel. Il s'y ajoute un grand nombre de systèmes périphériques, comme ceux pour la lutte contre le blanchiment d'argent ou les listes d'embargo ou de sanction, sans parler des systèmes de routage. Pour des raisons de coûts, de nombreuses institutions financières préfèrent par conséquent ne pas du tout traiter ces transactions financières en interne et les externalisent auprès d’une institution centrale au sein d'un grand groupe. En revanche, ce procédé se révèle insatisfaisant si le transfert de paiements représente à terme une activité stratégique.

Plaque tournante pour paiements

C’est pourquoi nous avons recherché la composante spéciale qui doit être intégrée dans les systèmes de paiement par les institutions financières pour se démarquer de la concurrence et pour offrir leur propre transfert de paiements. Cet aspect est notamment pertinent pour les institutions qui se présentent comme prestataire de services auprès de clients entreprises pour le traitement d’opérations financières dans certaines régions du monde. Le résultat : les processus de nombreuses banques ne diffèrent guère les uns des autres. Souvent seul l'ordre dans lequel ils sont exécutés les différencie. Suite à ce constat, nous avons conçu une plaque tournante de paiement qui fonctionne comme un manège. Les fonctionnalités spéciales sont accessibles à chaque étape, de la même manière que les enfants peuvent accéder à n’importe quel manège de leur choix dans une fête foraine (voir aussi figure 1).

TRAVIC-Payment Hub permet à une institution financière d'offrir toute configuration envisageable. Cela s'applique à l’administration du routage, pour lequel un ensemble complexe de règles peut être défini, et également aux systèmes périphériques connectés. Mais de quelle façon TRAVIC-Payment Hub sait-il ce qui est censé se produire, si par exemple le système de conformité nécessite une action ? En règle générale, ce sont les systèmes périphériques qui doivent s'adapter aux indications du système principal. Donc pourquoi les banques s’encombreraient-elles d'un nouveau défi de transfert de paiements, surtout après avoir probablement abandonné un monolithe dans leur système central ? La solution est de doter chaque moteur de workflow intégré de son propre script, ce qui permet une connexion aisée et efficace du fournisseur (par exemple PPI) aux autres systèmes.

Le mot « Hub » dans TRAVIC-Payment Hub est donc dans le même temps un nom de produit et un service.

Développement de logiciel à l'inverse

Techniquement, nous nous penchons particulièrement sur ce qui autrement deviendrait une « monnaie » à l'extérieur. Le langage de script implémenté permet à une institution financière d'intégrer ses propres fonctionnalités métier dans TRAVIC-Payment Hub, sans devoir modifier le code source du logiciel. En raison de la séparation de la technique et de la fonctionnalité métier, une partie essentielle du développement du logiciel est ainsi transférée du fournisseur à l'utilisateur. De cette façon, les mises à jour sont toujours supportées, même si TRAVIC-Payment Hub doit gérer un réseau complexe de systèmes périphériques. De plus, les départements informatiques ne seront pas tentés de modifier le code du système de traitement des paiements principal et ne risqueront donc pas créer des problèmes en cascade.

Dans la pratique, TRAVIC-Payment Hub reçoit les différents statuts des systèmes connectés. Le langage de script est utilisé en interne par les développeurs du département informatique ou le prestataire intégrateur, pour définir la manière de traiter les paiements selon leurs différents statuts. Dès que la définition du workflow est terminée, le système compile le code pour que TRAVIC-Payment Hub s’exécute. Des tâches créées par le moteur de workflow sont traitées par un moteur de tâches interne. Ci-dessous un exemple simple sur la manière dont le langage script utilisé dans TRAVIC-Payment Hub de PPI traite les OUR Charges, c'est-à-dire comment TRAVIC-Payment Hub vérifie si les frais d'un paiement sont intégrés dans le paiement et s'ils peuvent être retenus ou si une demande de paiement doit être créée pour encaisser les frais.
Status CHECKINBOUNDCHRGS {
    if payment is inbound and (payment is ourCharges) then {
        if payment is ourChargesReceived then {
            just set status VALIDATERECEIVCHGS and leave step
        }
        if payment is correspondentChargeExpected then {
            if payment is debitAuthorized then {
                just set status CREATEADVICEOFCHGS and leave step
            }
            just set status CREATECHARGEREQ and leave step
        }
    }
    just set status DONE and leave step
}



Introduire TRAVIC-Payment Hub

Avec la gamme de produits TRAVIC, PPI couvre le processus entier de paiement d'une institution financière, depuis la réception du paiement jusqu'à sa compensation en passant par les activités interbancaires. TRAVIC-Payment Hub représente le traitement noyau des transactions financières. Notre solution fonctionne en tant que banque de client et banque de compensation – même en fonctionnement parallèle – et elle offre également une fonctionnalité pour paiements instantanés. En plus, la solution permet autant l’exploitation locale que l’externalisation du produit de haute disponibilité logicielle, en partenariat avec nos partenaires infrastructurels.

Auteur : Thomas Riedel



Plus d'informations :

SEPA 2.0 : La mise à jour du standard ISO 20022 risque de causer une triple migration

SEPA et le standard ISO 20022 sur lequel il est fondé peuvent être considérés comme des moteurs parmi les initiatives globales ISO 20022. Très tôt, ils se sont présentés comme des règles de fonctionnement (rulebook) pour les différents formats de paiement dans la zone euro, les utilisant en tant que standard de format commun pour permettre l'interopérabilité transfrontalière et inter-systèmes. Malgré certaines spécificités locales, SEPA a permis un traitement continu de bout en bout sans discontinuités et conversions de supports au cours des dernières années, notamment en harmonisant les caractéristiques nationales avec une spécification EPC uniforme. Le traitement de bout en bout s'applique dans ce cas non seulement à la relation interbancaire mais également à la communication du donneur d'ordre au bénéficiaire. Cela est rendu possible par l'utilisation cohérente d'un dictionnaire de données uniforme (data dictionary) au format ISO 20022 qui fournit une base uniforme pour l'échange de données en transportant des éléments de données des messages client-banque (pain) jusqu’aux messages interbancaires (pacs) en passant par les messages des clients bancaires (camt) sans conversions.

Tandis que SEPA continue son évolution (notamment en raison de l'introduction des paiements instantanés), la norme ISO 20022 utilisée pour le SEPA doit encore rattraper son retard : plus particulièrement en ce qui concerne la base 2009 définie par l'EPC. Cette norme ISO étant également en constante évolution pour refléter les développements actuels, le groupe de travail EPC responsable de la poursuite du développement du schéma SEPA prévoit de migrer tous les schémas (SCT, SCT Inst, SDD Core, SDD B2B) vers la version 2019 de la norme ISO 20022. La transition doit être annoncée en 2020 et entrera définitivement en vigueur en novembre 2022 dans le cadre d'une migration big bang (des formats interbancaires). Ce changement, entre autres, fait actuellement l'objet d'une consultation publique en tant que demande de modification majeure (Change request). Au cours de cette phase, des remarques sont demandées au cercle des parties participant à la consultation.

L'une des raisons pour lesquelles cette demande de modification, « CR » est importante est la prise en charge future de Request to Pay (demande de paiement), qui ne peut pas être fournie avec la version ISO actuelle car les futurs éléments requis ne sont pas disponibles dans son format. Cependant, une version à jour de la norme ISO est également requise pour d'autres développements futurs, en particulier à la lumière des migrations TARGET2 et SWIFT MX, qui sont également basées sur la version 2019 de la norme ISO.

La bonne nouvelle est que la norme ISO 20022 est déjà bien implantée dans le monde du SEPA. Contrairement à l'introduction de SEPA, il n'est pas nécessaire d'introduire un nouveau format ni de remplacer les anciens formats à grande échelle. Les systèmes existants doivent « seulement » être ajustés et apprendre à traiter les changements tels que les nouveaux éléments de données. Néanmoins, le défi est de maîtriser une migration big bang avec des effets sur les paiements interbancaires et les formats à l'interface client-banque.

La mauvaise nouvelle: est qu’en raison des développements actuels, la date de transition SEPA coïncide désormais avec le début de la période de transition de SWIFT MT à MX. L'idée originale de réaliser la transition SEPA en 2022 avait pour objectif de ne pas exécuter les trois grandes migrations - TARGET2, SWIFT MX et SEPA ISO 20022 Version 2019 - presque en même temps et d'ainsi séparer l'effort nécessaire. Si TARGET2 aussi prévoit un décalage de la migration big bang prévu, comme il est déjà revendiqué par le marché, toutes les migrations auront lieu en même temps ce qui représente un défi majeur pour les prestataires de services financiers concernés annulant l'approche initiale de séparer les différentes migrations. A qui la faute ? La réponse est vite trouvée : la pandémie mondiale de Corona a mis à rude épreuve notre vie quotidienne et l'économie.

Dans cette situation, les institutions financières doivent garder un œil sur les développements futurs et s'adapter aux changements à venir. Nous surveillerons également de près les événements en cours et continuerons de rendre compte des modifications de l'ISO SEPA une fois la consultation du marché terminée.

Auteur : René Keller

DSP2: Sécuriser les paiements de masse via EBICS

La sécurité des paiements de masse a toujours été un problème. Les premières tentatives visant à établir une protection simple contre la manipulation frauduleuse se sont avérées peu efficaces et n'ont donc jamais conduit à une sécurité fiable. Par exemple, le total de tous les numéros de compte des bénéficiaires a été créé pour empêcher les criminels de modifier ultérieurement les paiements. Mais lorsque l'IBAN est arrivé, même cette méthode extrêmement simple n'était plus utile - les institutions financières l'ont finalement abandonnée en raison des défis mathématiques impliqués.

Il ne reste à ce jour que le nombre de paiements inclus et le montant total. Personne ne prétend que de telles valeurs offrent une protection efficace.

La DSP2 et du RTS ont été plus prometteurs pour fournir plus de sécurité pour les paiements. Cependant, ils n'ont pas conduit à une percée pour les paiements de masse qui sont particulièrement courants chez les entreprises clientes. Pour cause : afficher le bénéficiaire, le compte et le montant et demander au client de vérifier toutes les données contenues, par exemple via un lien dynamique, est difficilement réalisable pour le paiement des salaires dans une entreprise de plus de 10 000 employés. Cela est impossible d'un seul point de vue organisationnel et peut difficilement être réalisé en utilisant les canaux établis sur le plan technique.

Alors, comment s’assurez-vous que le fichier de paiement, une fois créé, est exécuté, sans altération, par l'institution financière ?

La réponse est EBICS !

EBICS est la norme en matière de paiements aux entreprises européennes depuis des années. Il est disponible dans tous les grands pays où le volume de transactions est élevé, tels que l'Allemagne, la France, l'Autriche et la Suisse. D'autres pays suivront.

Alors pourquoi la société EBICS ne définit-elle pas une norme d'audit générale et obligatoire basée sur des procédures internationales de valeur de hachage (par exemple SHA-256) et n'établit-elle pas l'ensemble de règles correspondant ? Le principe est le suivant : toutes les applications qui génèrent des fichiers de paiement de masse génèrent toujours la valeur de hachage correspondante et la transmettent à l'institution financière avec le fichier de paiement. Ainsi, cette valeur de contrôle peut être recalculée dès l'arrivée du fichier de paiement et présentée au client pour vérification avant validation. C'est aussi simple que cela !

Simple et très efficace, car la valeur de hachage identique garantit qu'aucune manipulation n'a eu lieu entre la création du fichier de masse et le traitement de masse par l'institution financière.

Si, pour la définition de la procédure de valeur de hachage par la société EBICS, nous considérons également le client final, au lieu de la comparaison à 32 valeurs doubles, un algorithme pourrait être trouvé qui transforme la valeur de hachage en un nombre composé de 8-10 chiffres - semblable à un TAN. Les clients et les utilisateurs utilisent déjà ce type de valeurs de nos jours. Une comparaison des valeurs de contrôle ne nécessite qu'un minimum de temps et est facile à faire.

Par ailleurs, laisser l’établissement de cette définition au marché seul n’est pas une bonne idée. Si tous les acteurs impliqués font leur propre définition, une multitude de procédures différentes vont être créées, ce qui déroutera les clients au lieu de fournir une sécurité supplémentaire.

C'est donc l'une des tâches de la société EBICS de fournir une solution contraignante à ce stade et de répondre ainsi aux exigences de la DSP2 pour les paiements de masse.

Auteur : Michael Schunk

eBAM – composante de la numérisation

Une crise peut aussi être un catalyseur de progrès. La crise du corona virus est inédite comparée aux crises précédentes en ce sens qu’elle nous plonge dans le monde numérique - de l'enseignement à domicile au home office, la pression est exercée sur la réévaluation de nombreuses activités sur de nombreux aspects. Ce gap qui n’était pas perçu comme tel devient flagrant dans un contexte de confinement et de restrictions en tout genre.

Et quand on parle de solutions de Cash Management ici, dans le blog, je pense que le sujet de la gestion des comptes bancaires (Bank Account Management) en fait également partie. Cela comprend non seulement l'échange de messages sur l'interface client-banque, mais également la gestion des données de base de la banque et du compte et de leurs autorisations de signature (pas uniquement les signatures numériques) ainsi que de tous les documents associés, les processus dans l'ensemble du cycle de vie du compte et la confirmation de l'équilibre fastidieux. C'est là que toutes les exigences en matière de KYC ainsi que les autorisations et les identités numériques entrent en ligne de compte.

Ces sujets auraient pu depuis longtemps être transférés dans le monde numérique dans le cadre d'eBAM - la gestion électronique des comptes bancaires. La normalisation est nécessaire ici et elle commence par l'orthographe correcte. EBAM ou eBAM ou e-BAM ?

Il est temps de réagir - de nombreux blocs de construction sont disponibles. Certains éditeurs de solutions de Cash Management ou de gestion de la trésorerie proposent des modules spécialement pour l'administration des données côté entreprise. Des réussites peuvent déjà être rapportées pour les premiers processus d'ouverture de compte purement numérique. Il y a également eu des développements encourageants concernant le KYC et les identités numériques. Même les messages à l'interface client-banque en XML selon la norme ISO 20022 sont en principe disponibles. La poursuite du développement de la norme est également examinée par un groupe de travail du CGI-MP (mise en œuvre mondiale commune - pratiques du marché) - une initiative mondiale des entreprises, des institutions financières et des fabricants pour l'harmonisation de l'utilisation de l'ISO 20022 à l’interface client-banque. Les normes sont à la base de la numérisation. Ils créent une sécurité pour les fabricants et les utilisateurs.

En Allemagne, avec l'annexe 3 de l'accord DFÜ, il existe une longue tradition multibancaire - c'est-à-dire une norme qui atteint de nombreuses institutions financières. Pour cela, il est désormais possible d'intégrer des rubriques optionnelles telles que la facturation des services bancaires (BSB). Tout le monde n'a pas besoin de soutenir le sujet - mais s'ils le font, ils doivent se conformer à la norme. Et je voudrais plaider pour une telle option au sujet de l'eBAM. Pour EBICS, il est facile de transporter les messages XML dans le groupe de messages camt (gestion des comptes) - les normes (harmonisées) doivent être convenues. Le cas d'utilisation simple d'une vue d'ensemble des autorisations de signature montre un premier pas dans cette direction avec EBICS en utilisant le type de commande HKD, mais - voir ci-dessus - ce n'est encore que le début.

Il est bien entendu que la partie communication client-banque d'eBAM ne doit pas être réalisée via EBICS, car un itinéraire de transport via SWIFT est également possible. Même les API ouvrent de nombreuses possibilités. Indépendamment du canal, la base devrait être une standardisation du contenu (XML en harmonie avec json) et des processus de base. Et pour le contenu au format XML selon ISO 20022, un chapitre supplémentaire devrait être ajouté à l'annexe 3 de l'accord DFÜ.

Sur cette base, les fournisseurs mentionnés ci-dessus peuvent ensuite étendre leurs produits pour le « multi-bancaire » et les institutions financières peuvent offrir de nouveaux services à de nombreux clients avec des systèmes similaires - leur permettant ainsi de s'intégrer très bien dans le monde numérique avec ces services.

Auteur : Dr. Mario Reichel

L’impact du M2M : Communication entre machines sur les transactions financières

L’économie du M2M « Machine to Machine », Internet des objets connaît une croissance rapide. Toujours plus de machines et appareils sont interconnectés. D’ici 2025, 75 milliards d’appareils devraient être interconnectés dans le monde entier. Selon les analyses de BizIntellia, un prestataire IdO américain, les solutions autour l’IdO contribueront à hauteur d’environ 14,2 milliards de dollars au PIB mondial d’ici 2030.

À l’avenir, l’IdO occupera une place significative dans nos vies et dans nos sociétés. La question est de savoir quel impact aura l’IdO sur les paiements ?
Quels sont les potentiels nous réservent les paiements Machine à Machine (M2M) ?

Comment l’IdO et les paiements sont-ils connectés ? Les machines sont autorisées à transférer non seulement des identités et des informations, mais également des valeurs. Ils envoient des paiements à d’autres machines de manière autonome, sans avoir besoin de validation humaine. Toutefois, si ces transactions commerciales ne peuvent pas s’exécuter sans interruptions (par exemple, les machines doivent attendre une action manuelle telle qu’une confirmation de paiement), des périodes de blocage ou même des terminaisons anormales peuvent en résulter - les deux scénarios doivent être évités, afin d’exploiter pleinement le potentiel des paiements M2M.

Mais les paiements M2M ne sont pas uniquement des visions futures. Des solutions concrètes sont déjà en cours de développement, par exemple, dans l’industrie automobile. Certaines entreprises mettent déjà en place les écosystèmes nécessaires. L’idée est que les automobiles aient leurs propres portefeuilles avec de l’argent électronique et puissent ainsi payer les frais de carburant ou de péage sans intervention humaine.

Afin d’analyser l’impact des paiements M2M, nous avons mené une étude sur le thème « Machines payantes » qui traite notamment des questions suivantes :

  1. Quelles conditions préalables doivent être remplies pour permettre la mise en œuvre des paiements M2M ?
  2. Quels sont les défis de la mise en œuvre des paiements M2M ?
  3. Dans quelle mesure le nombre de transactions de paiement augmentera-t-il en raison des paiements M2M ?
  4. Quels moyens de paiement conviennent le mieux aux paiements M2M ?
  5. Quel impact les paiements M2M ont-ils sur les prestataires de services de paiement ?
  6. Comment les prestataires de services de paiement devraient-ils réagir aux paiements M2M ?

Pour que les paiements M2M deviennent une réalité, les machines participantes doivent d’abord recevoir leur identité propre de machine comportant des attributs individuels les distinguant des autres machines. Une identité de machine sécurisée ne peut être ni manipulée, ni falsifiée ou ni utilisée à mauvais escient. La machine reçoit une identité unique et sécurisée qu’elle peut utiliser pour s’authentifier au sein du réseau productif auprès d’autres machines, instances et participants.

Il y a un vide juridique en matière d’objets connectés. En effet des progrès doivent être faits sur le plan réglementaire. Il faut établir des règles de responsabilités claires pour les actions des systèmes autonomes et pour l’allocation des risques liés à l’utilisation des systèmes autonomes. Enfin et surtout, de nouveaux systèmes de responsabilité sont nécessaires qui tiennent compte des particularités des machines autonomes.

En termes de mise en œuvre pratique, nous avons identifié les domaines d’action suivants, dont la solution sera particulièrement difficile:

  1. Cartographie de l’identification des paiements automatiques
  2. Contrôles de conformité par rapport à une machine (KYO au lieu de KYC)
  3. Traitement des informations retournées (y compris les perturbations des processus)
  4. Prise en compte d’un reporting plus complexe et plus complet
  5. Sécurité accrue des machines et des interfaces
  6. Mise en œuvre cohérente de l’intégration numérique et des processus numériques

De nombreuses analyses suggèrent que le nombre de transactions augmentera considérablement avec les paiements M2M. Nous sommes d’accord avec cette évaluation et prévoyons également une augmentation significative. Compte tenu des effets de compensation, nous estimons que d’ici 2027, il y aura environ 12 milliards de transactions de paiement « Machine à Machine » supplémentaires en Allemagne et environ 50 milliards dans l’UE.


Tous les modes de paiement électronique courants ne sont pas adaptés aux paiements M2M. Nous pensons que la monnaie digitale (stable coins : indexées sur un actif réel, unbacked coins : non indexées sur des actifs réels et devises électroniques) et la monnaie électronique sont les plus adaptées aux paiements M2M.

Les méthodes de paiement établies ont généralement des frais de transaction plus ou moins élevés. Les solutions de crypto-monnaie et de monnaie électronique, en revanche, permettent des transactions peu coûteuses même pour les plus petits montants et les rendent attrayantes pour une utilisation dans l’IdO. Après tout, ils offrent la possibilité de régler économiquement même les petits paiements de services, pour un montant inférieur à un centime ; comme, par exemple, l’utilisation d’une ampoule dans une maison intelligente. Les solutions de monnaie électronique et de crypto-monnaie peuvent également être intégrées indépendamment des prestataires de services financiers traditionnels.

Reste à savoir comment les prestataires de services de paiement devraient se positionner à l’avenir. L’Internet des objets renforcera encore la tendance à la différenciation des fournisseurs spécialisés avec un modèle commercial basé sur les données et des fournisseurs d’infrastructure.

Les fournisseurs spécialisés peuvent utiliser l’augmentation du volume de données due à l’IdO à leur avantage dans la concurrence du marché et développer des opportunités commerciales. Par exemple, des services supplémentaires personnalisés avec précision peuvent être proposés aux clients sur la base de données d’utilisation détaillées. Cela dépend de la capacité des prestataires de services de paiement à se placer « au-dessus » des machines ou au moins à agir comme des agrégateurs de données qui compilent les données d’utilisation pertinentes en chiffres et les transfèrent.

En ce qui concerne le positionnement en tant qu’agrégateur de données ou hub de données, les prestataires de services de paiement pourraient également assurer la confiance nécessaire entre les personnes, les entreprises et les machines participantes, et agir comme une sorte d’instance de compensation pour les identités numériques sécurisées et les données valides.

En résumé, cela signifie que les prestataires de services de paiement traditionnels doivent surmonter des défis considérables. Les exigences fonctionnelles et surtout techniques de l’infrastructure des prestataires de services de paiement entraîneront des changements massifs. Ils doivent répondre aux prérequis suivants : 

Disponibilité totalement ininterrompue, augmentant l’importance des modèles d’exploitation 24/7/365 et du traitement des transactions en temps réel
  • Les temps d’arrêt pour l’installation de nouvelles versions ne sont plus possibles.
  • Capacité à gérer des charges très élevées en raison de milliards de transactions supplémentaires
  • Possibilité de faire la distinction entre les paiements automatiques et non automatiques, car ils seront traités par des règles différentes
  • Possibilité de numérisation complète et d’intégration de la machine
  • Conformité future avec KYO pour les machines, qui n’est actuellement pas encore réglementé, en combinaison avec KYC, cartographie dans les systèmes correspondants et, en particulier, réglementation organisationnelle
  • Possibilité non seulement de déclencher des paiements, mais également de traiter les informations en retour du système et de traiter les perturbations en conséquence. Sur la base du retour d’expérience, les machines doivent pouvoir tirer les bonnes « conclusions » en temps réel et sélectionner des alternatives si nécessaire.
En outre, les prestataires de services de paiement doivent décider comment ils souhaitent se positionner et ajuster les structures de vente, car les écosystèmes de l’IdO deviendront de plus en plus importants.

Auteur: Michael Titsch

EBICS-Security – Quand est-il temps de mettre à jour votre système client ?

EBICS spécifie différentes fonctions et règlementations de sécurité qui doivent être respectées par les clients et les institutions financières. Ces dernières doivent toujours veiller à ce que les spécifications les plus à jour soient mises en œuvre et supportées par leurs serveurs bancaires EBICS. Cependant, les clients EBICS et chaque utilisateur ont aussi la responsabilité d’utiliser à tout instant des logiciels client répondant aux standards de sécurité EBICS en vigueur. Il est donc primordial, tant en raison des adaptations fonctionnelles que pour des raisons de sécurité, de mettre à jour fréquemment les logiciels client EBICS.

Toutefois, la mise à jour d’un logiciel client EBICS existant ne signifie pas que ce logiciel EBICS sera automatiquement capable de communiquer avec l’institution financière en utilisant la version EBICS et les procédures de sécurité les plus récentes. En fonction de la version EBICS et des fonctionnalités client utilisées précédemment, il est nécessaire de mettre à jour les différentes clés d’application pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006) ainsi que la version d’EBICS à utiliser, suivie d’un échange de ces données avec les serveurs bancaires EBICS. Il peut aussi être nécessaire de mettre à jour le cryptage Internet (TLS) vers une version plus récente et plus sécurisée en échangeant des certificats renouvelés. De telles mises à jour requièrent en règle générale une intervention proactive et des ajustements manuels de la part de l’utilisateur EBICS.

Pourquoi ces mises à jour sont-elles importantes ?

La communication EBICS via Internet possède ses propres spécifications en termes de procédures de sécurité. La société EBICS les met à jour et les adapte régulièrement aux exigences de sécurité en vigueur au moyen de nouvelles versions d’EBICS. Un exemple est la longueur des clés. Les anciennes versions d’EBICS permettent encore d’utiliser des clés de longueur 1 024 bits pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006). Mais cette longueur ne répond plus aux exigences de sécurité actuelles, car les clés trop courtes sont considérées comme peu sécurisées. Les versions plus récentes d’EBICS n’acceptent que des clés d’une longueur minimale de 2 048 bits. Un autre exemple est mis en évidence avec les procédures et les versions du cryptage TLS. Afin de répondre plus aisément aux recommandations de sécurité, par exemple à celles de BSI en Allemagne, la société EBICS a créé une annexe distincte des spécifications EBICS 3.0, appelée Transport Layer Security qui comporte les directives y afférentes. Comme les spécifications de la version 2.5 d’EBICS ne pouvaient pas être adaptée rétroactivement, la DK (Die Deutsche Kreditwirtschaft) a en outre publié en 2019 son propre document de recommandations intitulé Recommandations concernant les protocoles de sécurité EBICS et la longueur des clés (disponible en allemand et en anglais). Il contient des informations sur les procédures de sécurité à utiliser pour EBICS. Voir aussi www.ebics.de et www.ebics.org.

Afin de permettre aux utilisateurs d’EBICS une transition en douceur vers les nouvelles versions d’EBICS et les nouveaux standards de sécurité, la plupart des institutions financières proposent toujours à leurs clients les versions plus anciennes, en parallèle avec les nouvelles. Malheureusement, il est devenu évident que dans de nombreux cas cela conduit à ce que les clients ne saisissent pas l’occasion de mettre à jour leur communication EBICS. Nombreux sont ceux qui continuent à utiliser les anciens systèmes et procédures. Il est donc plus difficile pour les institutions financières de mettre fin à ces anciennes procédures.

En fin de compte, chaque acteur de la communication EBICS s’attend à ce qu’un échange de données sécurisé soit assuré. Personne ne veut subir de dommages. Ce qui signifie que chacun doit apporter sa contribution. Bien entendu la sécurité d’EBICS n’est pas la seule chose que les institutions financières et les entreprises doivent garder à l’esprit. Après tout, toutes les parties impliquées doivent prendre toutes les mesures de sécurité possibles dans leurs infrastructures et dans leurs solutions logicielles afin de prévenir les abus et les pertes.

Alors, pourquoi attendre ? Allons-y.

Auteur: Michael Lembcke