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

En savoir plus

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

En savoir plus