ISO 20022 dans les paiements internationaux : c'est l'heure du changement !

Presque tous les grands systèmes de paiement sont en train d'introduire des formats de données standardisés basés sur XML. Ils rendent les paiements internationaux et propriétaires plus rapides et produisent moins d'erreurs. Par contre, la transition ne va pas de soi et il ne reste pas beaucoup de temps. Que faut-il prendre en considération ?

Les paiements par carte pendant les vacances et les virements internationaux sont désormais considérés comme acquis dans la vie quotidienne. Toutes les transactions électroniques nécessitent cependant des processus très complexes, car pour assurer des transactions financières rapides et fluides, tous les systèmes informatiques concernés doivent être en mesure de traiter les données générées de la même manière. Un standard tel que l'ISO 20022 est requis à cet effet, étant donné qu’il sera la référence pour les paiements internationaux et individuels dans les années à venir.

Un standard éprouvé pour l'avenir

Toujours plus d'espaces de paiement migrent leurs systèmes vers le standard ISO car ses avantages sont considérables : il est évolutif, il permet un traitement des données de paiement beaucoup plus rapide et il permet une efficacité considérablement accrue. Les conversions d'un format de données vers un autre ne seront plus nécessaires. De plus en plus de données pourront être directement traitées sans interactions ou ruptures de supports  (STP).

Ne sous-estimez pas l'effort

Mais ce n'est pas sans coûts. Le passage à l'ISO 20022 exige des ressources humaines et financières. En ce moment de nombreuses institutions financières sous-estiment l’effort nécessaire. Elles doivent non seulement automatiser des processus manuels éventuellement existants, mais aussi adapter leur propre logiciel à l'ISO. S'il s'agit comme souvent des systèmes Legacy établis, la préparation des processus pour le traitement des paquets de données XML est exigeante. Et le temps presse : la mise en service de la conversion de TARGET2 au standard XML est prévue pour le 21 novembre 2021. À cette date débutera une période de coexistence avec SWIFT.

Un sentiment de préparation trompeur

Les institutions financières européennes appliquent déjà les standards basés sur ISO, car ils servent de base au SEPA. Mais cela ne signifie pas qu’elles peuvent rester les bras croisés. En fonction du type de mise en œuvre, des adaptations s’imposeront dans tous les secteurs importants de l'informatique des transactions financières : des données de base aux systèmes back end en passant par l'e-banking. Sans parler de l’impact sur l'architecture future du Core banking.

Diverses implémentations du standard ISO

Nous ne devons pas oublier qu'il s'agit d'un standard générique, qui définit uniquement les principes de base pour les messages de paiements. Lors de chaque implémentation spécifique le standard est adapté de manière appropriée, ce qui signifie qu'elle peut être différente pour TARGET2, SWIFT et SEPA. De la limitation des codes ISO et types de données autorisés à l'élimination des éléments facultatifs du message de base non utilisés, différentes variantes sont imaginables. Voilà pourquoi une seule solution pour tous les scénarios est irréaliste pour la migration.

De nombreux projets spécifiques

Il n'est donc pas correct de parler d'une seule transition ISO 20022 alors qu’en réalité existent bon nombre de projets distincts. Il est donc d'autant plus important d’impliquer très tôt le service IT afin d’aider les équipes métier à identifier à temps les pièges et les problèmes et, non des moindres, à estimer les coûts. Car la conversion des paiements internationaux et individuels de TARGET2 au standard XML est susceptible de générer un coût global de l’ordre de sept à huit chiffres. Ce montant inclue l'étude préliminaire, l’implémentation et les adaptations IT. Il faut en plus budgéter les formations des employés impliqués et le développement en temps voulu du savoir-faire nécessaire, ou alternativement l'intégration d'un partenaire externe.

Quelle est la suite ?

Si elle n'existe pas encore, les institutions financières ont besoin d'une feuille de route dans les meilleurs délais – contenant tous les tâches et jalons nécessaires pour la conversion au standard ISO. Un inventaire objectif de la situation actuelle sert de base, il n’est contournable par personne. À cette occasion il peut aussi être opportun de se demander si la fourniture de paiements transfrontaliers par sa propre institution sera toujours économiquement viable ou si une coopération renforcée avec des prestataires de services externes représente une meilleure solution.

Faire du changement une opportunité

La transition à l'ISO 20022 met sans aucun doute les prestataires de services financiers sous pression, surtout si nous considérons la consolidation quasi simultanée de TARGET2 et de TARGET2 securities. Par contre, les changements réglementaires sont également une possibilité pour vérifier critiquement ses propres systèmes et pour déterminer leurs capacités à être modélisés de manière agile et flexible. En fin de compte, cela aide à faire progresser la transformation numérique dans son ensemble – car l’immobilisme n'est pas une option dans le monde numérique d'aujourd’hui.

Auteurs invités : Sabine Aigner, Raija Wehrli

EBICS 3.0 – un ensemble de paramètres au lieu du type d'ordre Que faut-il prendre en compte lors de l'identification des opérations métier ?

Avec EBICS 3.0 les différentes opérations métier ne sont plus effectuées via les types d’ordres, mais via les nouveaux paramètres BTF.

Afin de permettre l'utilisation de contrats client avec des clients EBICS de différentes versions d'EBICS combinées avec EBICS 3.0, des règles de mapping ont été spécifiquement développées par les organismes nationaux de spécification. Ces règles suivent généralement les cinq paramètres BTF Service Name, Service Scope, Service Option, Service Message Name et Service Container. Il est important que la combinaison de ces paramètres BTF dans le serveur bancaire EBICS soit unique. Cela permet de s'assurer qu'un type d'ordre peut être attribué à l'opération métier via BTF et vice versa.

Dans la pratique, des ordres identiques d'un format donné peuvent être créés dans différentes versions de format et soumis au serveur bancaire. Bien que des ajustements de format soient effectués régulièrement par les organismes de spécification, la version de format utilisée par le système client dépend également de la version du logiciel client. Comme la version de format doit être transparente dans les logiciels clients, leurs utilisateurs n'ont aucune influence sur les envois dans une version de format spécifique lors de la compilation de leurs remises. En outre, les institutions financières acceptent en règle générale différentes versions de format d'une opération métier. En fin de compte, pour le traitement côté banque, la version de format correspondante peut également être lue à partir du namespace du fichier XML, au moins pour les formats XML. Jusqu’à présent, les serveurs bancaires sont conçus de manière flexible pour différentes versions de format.

Les autres paramètres BTF applicables pour EBICS 3.0 sont Service Message Name Format, Service Message Name Variant et Service Message Name Version. Si une institution financière inclut également ces autres paramètres dans les mappings des types d’ordre et les détails des contrats client, il convient de prendre en considération certains aspects. S’ils n’ont pas déjà été utilisés plus intensivement via le paramètre FileFormat ou s’ils ne sont pas nécessaires pour des raisons inhérentes au traitement, ces paramètres supplémentaires devraient être pris en compte de manière plus mesurée du côté des banques pour les tests EBICS.

Finalement, ces informations supplémentaires sur les paramètres font déjà partie du fichier d’ordre lui-même et, de toute façon, elles peuvent être lues à partir de ce dernier. Que faut-il faire en cas d’indications contradictoires ? Un surplus de gestion dans le serveur bancaire implique plus de temps et davantage d'efforts pour la gestion des référentiels. Il devrait y avoir un accord client propre à chaque version de format d'une opération métier. En plus, ces détails de format sont visibles par le client dans le logiciel client et certains d’entre eux ne peuvent pas être contrôlés.

Que se passerait-il si, par exemple, le serveur bancaire prenait en charge les versions 03 et 04 d'un format XML lors de la remise, mais que le client remettait la version 04 dans le BTF au lieu d’utiliser la version 03 du format ? L’ordre serait rejeté lors de la prise en compte de la version, bien que le système bancaire puisse traiter la version de format. La version réelle est reconnaissable au moyen du namespace.

La mise à disposition de fichiers pour download est encore plus compliquée. Celle-ci devrait être générée de manière synchrone dans la version demandée à la date/heure de téléchargement et être publiée en tant que fichier. Il en va de même pour les téléchargements historiques.

Conclusion : les institutions financières ne devraient pas être trop restrictives dans leurs définitions des accords BTF avec leurs clients. Cela leur permettrait ainsi d’être plus flexibles et d’économiser du temps et des efforts supplémentaires dans la gestion des contrats et des référentiels.


Auteur: Michael Lembcke