L’heure du changement

Ce qui est différé n’est pas perdu : la transition vers des formats de données conformes à la norme ISO 20022 dans les paiements aura lieu – mais un an plus tard. Elle engendre d’autres changements, notamment pour SWIFT. La plateforme pour la gestion des transactions (Transaction Management Platform ou TMP) prévue dans ce contexte a pour objectif de rendre les flux de paiements internationaux plus transparents et plus rapides. Mais ces systèmes centraux sont-ils suffisamment sécurisés ? Y a-t-il des alternatives ? 

Une plateforme de données centralisée comme objectif de développement

Les systèmes de paiement sont au cœur de l’infrastructure financière. Une défaillance, comme celle de TARGET2 l’année dernière, est grave et, à juste titre, a causé des remous. Le report de la transition vers des formats de données XML conformes à l’ISO 20022 des paiements européens n’est pas lié à cela, mais il offre bien sûr aux institutions financières le temps d’agir. Ces dernières peuvent en avoir besoin, car avec le changement de format, d’autres choses sont également en train de changer. Avec la TMP, SWIFT a annoncé la mise en place d’une plateforme de données centrale pour les paiements internationaux, basée sur XML. 

L’enregistrement centralisé de toutes les données de transaction permet à toutes les parties impliquées dans le processus d’y accéder à tout moment. Pour SWIFT, il s’agit d’un changement de paradigme, qui l’éloigne du simple agent d’informations pour devenir un fournisseur de services logistiques de paiement à part entière. La solution de plateforme présente un certain nombre d’avantages :

• La réduction des interfaces
• Aucune perte de données entre les différentes stations
• Une grande transparence pour toutes les parties concernées
• Plus grande sécurité de manipulation
• Plus d’offres de services

Pas d’introduction sans risques

Toutefois, l’introduction de la TMP comporte également quelques risques. Tout d’abord, il y a une possible défaillance du réseau SWIFT. Dans le pire des cas, tous les ordres d’une période donnée ont été perdus avec la TMP centrale. Les inquiétudes des institutions financières concernant le risque de défaillance en un point unique ne peuvent pas être écartées. Quant à la confidentialité des données, il convient de tenir compte du fait que les États-Unis ont déjà exigé des droits d’accès directs aux données du centre de données américain SWIFT. En réponse, SWIFT a construit un site en Suisse, entre autres.

Existe-t-il des alternatives à SWIFT ?

En principe, oui – mais le choix est limité : les candidats potentiels sont des réseaux de paiement sur Internet tels que Ripple. Les premières grandes institutions financières utilisent déjà le système en mode test. Les monnaies numériques des Banques centrales (Central Bank Digital Currencies) ne sont pas encore prêtes pour le marché, mais elles constituent certainement une alternative possible à l'avenir. L’e-Renminbi en Chine est déjà testé dans certaines provinces, et la couronne suédoise électronique a récemment commencé ses opérations de test. La BCE devrait suivre ce mouvement avec l’euro numérique.

Les systèmes transfrontaliers de règlement brut en temps réel (Real Time Gross Settlement, RTGS) méritent également d’être pris en considération. Cependant, ces systèmes n’existent pas si souvent ou, comme le SEPA, sont fixés sur une seule monnaie. Enfin, il existe des schémas de collaborations spécifiques créés comme des alternatives à SWIFT, tels que le Support of Trade Exchange (INSTEX). Ce système européen a été conçu expressément pour le commerce avec l’Iran. La Chine a pris un chemin similaire avec le CIPS. Le Visa B2B Connect fonctionne d’une manière totalement différente, mais en principe il repose également sur la coopération des institutions financières concernées. En Europe, le service est actuellement disponible dans certains pays.

Mais même une solution de SWIFT utilisant l’une des rares alternatives ne dispense pas les institutions financières de l’obligation de passer aux formats de données XML conformes à la norme ISO 20022. Dans le même temps, il est recommandé aux institutions financières d’examiner attentivement et de vérifier les changements provoqués par la TMP dans les paiements internationaux. Un peu de temps a été gagné dans la feuille de route vers la norme ISO 20022 en raison du report de la mise en service, il faut en profiter maintenant !

Auteurs : Sabine Aigner, Thomas Ambühler

En savoir plus

Les transactions financières sans interruption – qui ne souhaite pas cela ?

Certains systèmes logiciels sont tellement essentiels qu’ils requièrent les niveaux de disponibilité les plus élevés. Certes, dans le secteur financier, il ne s’agit pas d’une question de vie ou de mort. Mais dans le cas des procédures de paiement en temps réel ou des processus d’autorisation en temps réel, des exigences toujours plus importantes sont définies et surtout les périodes de maintenance ne sont plus acceptées. Et cela à juste titre : si, à cause d’une fenêtre de maintenance, vous recevez votre relevé de compte une heure plus tard, ou si le portail est inaccessible pendant une heure, cela peut être fâcheux, mais sans trop de conséquences. En revanche, si le client d’une banque ne peut plus payer sur le point de vente ou ne peut autoriser un paiement en temps réel, l’indisponibilité est d’une importance sérieuse.

Par conséquent, après le processus d’autorisation des paiements par carte, le transfert en temps réel est également devenu un domaine d’application des systèmes sans interruption avec l’introduction des paiements instantanés en Europe.

Commençons par le concept de continuité de service. Un fonctionnement sans interruption est défini par deux propriétés différentes :

1. Éviter l’indisponibilité prévue
   En fonctionnement normal, le système est prêt à fonctionner en permanence. Il n’existe donc pas de période de fonctionnement limité, par exemple en fin de journée ou lors d’une réorganisation.
   Le système est conçu pour que les changements de version puissent également être effectués en cours d’exploitation et ne provoquent aucun temps d’arrêt. 
2. Réduire l’indisponibilité non prévue
   Le système est hautement disponible même en cas d’erreur. La garantie de fonctionnement est donc importante malgré la défaillance de certains composants. Cette probabilité est calculée ou mesurée comme le rapport entre le temps de production et la durée d’exécution, c’est-à-dire le temps incluant le temps d’interruption, par exemple 99,99 %.
   La robustesse des scénarios de surcharge est particulièrement importante dans ce contexte. Bien que chaque système ait ses limites, il y a une différence entre l’effondrement total du système en raison d’un dépassement de la limite de charge et le fait que seule la charge supplémentaire ne peut être traitée conformément aux spécifications.

En règle générale, l’enthousiasme pour le sujet diminue considérablement lorsque l’on considère les coûts. Il convient alors de trouver des solutions architecturales et non seulement déplacer tout sur l’infrastructure. Néanmoins, même le meilleur logiciel ne pourra fonctionner que si l’environnement système est disponible. Je ne vais pas rentrer dans les détails de l’infrastructure hautement disponible, des systèmes d’exploitation, des systèmes de base de données et des agents de messages – tous ces éléments sont les conditions de base pour un système global sans interruption. Je voudrais plutôt me concentrer sur l’architecture logicielle. Cela permettrait de mettre en œuvre les exigences de disponibilité de manière ciblée tout en surveillant les coûts.

La haute disponibilité étant coûteuse, il faut avant tout identifier les processus critiques. Par conséquent, il faut savoir quels sont les processus devant toujours fonctionner et ceux qui peuvent être exécutés ultérieurement. Dans le cas des paiements en temps réel par exemple, les traitements en masse sont moins cruciaux que les paiements individuels.

Au cas où les grands composants relèvent des processus critiques, il convient d’analyser si ceux-ci peuvent être contournés. Un composant alternatif peut-il remplacer les tâches critiques d’un grand composant qui n’est pas hautement disponible pendant la période de défaillance ? Dans les transferts de paiements, le système de réservation peut être un très grand système qui n’est pas hautement disponible et la vérification de solde en ligne peut être le processus critique qui doit être contourné.

Bien entendu, dans l’ensemble, les transactions financières ne sont traitées sans statut: l’argent ne peut malheureusement être dépensé qu’une seule fois, le solde du compte étant alors un statut pertinent et un logiciel bancaire doit bien sûr pouvoir le refléter avec précision. Dans notre cas, cela se traduit toujours par l’utilisation de bases de données et par la nécessité de faire preuve de persistance avant et après chaque changement de statut. C’est surtout la conception du modèle de base de données qui détermine si nous atteignons ou non notre objectif. Les processus hautement disponibles sont conçus pour fonctionner avec des structures de données stables et sans migration. C’est la seule possibilité pour éviter l’arrêt de processus critiques pour changer le schéma de la base de données.

Il reste la question de la robustesse. La science parle également de résilience lorsque l’on décrit que les défaillances ou les défaillances partielles des systèmes techniques ne conduisent pas à une panne totale. Dans les transferts de paiement, ces pannes peuvent être des pics de charge supérieurs aux limites convenues ou des systèmes périphériques qui ne répondent pas aussi rapidement que convenu. Les défaillances chez les partenaires commerciaux et les accusés de réception manquants en grandes quantités peuvent également entraîner des défaillances. Nous avons trouvé un paradigme dans la programmation réactive permettant la robustesse souhaitée à travers l’orientation des flux de données. Une surcharge peut ainsi être encapsulée dans les zones touchées et rien ne s’oppose au traitement sans panne des données restantes – dans notre cas, les paiements.

Auteur : Thomas Riedel

En savoir plus