Résumé

  • IBM ouvre en bêta une version sur site de Digital Asset Haven et un adaptateur ISO 20022 vers le registre partagé de Swift. La première garde logiciel, politiques et gestion des clés dans l’environnement IBM Z ou LinuxONE du client.
  • Swift exploite la couche d’orchestration, les banques conservent actifs et financement, tandis que le règlement final reste hors registre dans les systèmes existants. Une signature locale, une acceptation du registre et la finalité ne sont pas le même fait.
  • La valeur commerciale dépend d’une chaîne de reçus réconciliables : autorisation, transformation du message, ordre dans le registre, puis règlement irrévocable, y compris lorsque l’un des passages échoue.

Le retour « sur site » répond à une préoccupation sérieuse des banques : ne pas confier à un nuage public les clés qui commandent des actifs ni les règles qui décident de les signer. IBM annonce que Digital Asset Haven peut fonctionner intégralement dans le centre de données du client, sur IBM Z ou LinuxONE, avec HSM Crypto Express, cloisonnement des environnements et cérémonies de clés documentées.

Il faut toutefois prendre le statut au mot. Il s’agit d’un accès bêta, pas d’une disponibilité générale. Le dispositif rend locale une surface de décision précise : l’établissement peut exploiter l’application, administrer la politique, conserver le matériel cryptographique et produire son propre dossier d’approbation. Il ne rend pas locale l’infrastructure à laquelle le paiement est ensuite confié.

La seconde bêta est un adaptateur de messagerie ISO 20022. Digital Asset Haven fournit portefeuilles, signatures, gouvernance et connectivité Hyperledger Besu ; l’adaptateur transforme une instruction bancaire familière en transaction destinée au registre blockchain partagé de Swift. C’est un raccourci d’intégration utile. La banque peut réutiliser une partie de ses données, contrôles et procédures au lieu d’inventer un langage d’exploitation parallèle.

Mais Swift reste l’opérateur du registre. Les banques gardent la maîtrise des actifs et du financement ; le registre valide et synchronise leurs engagements. En juillet, Swift a présenté l’infrastructure comme prête pour une première utilisation et indiqué que dix-sept établissements de six continents se préparaient à piloter des transactions en dépôts tokenisés. Ce vocabulaire atteste une expérimentation structurée. Il ne démontre ni un volume de production, ni une couverture générale, ni un résultat économique.

Surtout, Swift et IBM précisent que le règlement reste extérieur au registre. Les mouvements peuvent être orchestrés vingt-quatre heures sur vingt-quatre avant un règlement final dans les infrastructures existantes, notamment des systèmes RTGS. Le moment où le registre accepte un engagement n’est donc pas nécessairement celui où l’obligation monétaire devient définitive.

Le reçu local ne clôt pas le paiement

Le premier reçu devrait lier l’intention métier, l’identité du demandeur, la version de la politique, les approbateurs, la clé HSM, la signature et tout contournement d’urgence. L’installation sur site aide la banque à garder cette preuve dans son périmètre. Elle ne transforme pas une règle vague en mandat légitime et n’explique pas, à elle seule, ce qui s’est passé après l’envoi.

Le deuxième reçu appartient au passage entre l’adaptateur et Swift. Il devrait conserver l’empreinte du message ISO 20022, l’identifiant d’idempotence, la transformation appliquée, les reprises, la décision du registre, l’ordre obtenu et la version de règle utilisée. Sans ce lien, une expiration réseau peut ressembler soit à un échec, soit à une seconde instruction économique.

Le troisième reçu vient du système de règlement. Il doit nommer l’infrastructure, la position obtenue, l’heure de finalité et le point après lequel la révocation n’est plus possible. Les principes CPMI-IOSCO demandent précisément que les règles d’une infrastructure financière définissent la finalité et l’irrévocabilité. La technologie tokenisée déplace certains risques ; elle ne les dissout pas.

Une interface unique ne doit donc pas réduire ces trois états à « terminé ». Une instruction peut être signée localement mais refusée par le registre. Elle peut être acceptée par Swift alors que le système de règlement est indisponible. Elle peut être rejouée après un délai et créer un doublon si les identifiants ne survivent pas au passage. Le véritable produit est la capacité de raconter ces écarts sans reconstruire l’histoire à la main.

Le standard ne porte pas la responsabilité

ISO 20022 fournit une structure sémantique et des identifiants familiers. Il n’accorde pas le crédit, ne vérifie pas à lui seul les sanctions, ne choisit pas la juridiction et ne détermine pas qui supporte la perte lorsqu’une couche avance et que la suivante s’arrête. Un message conforme est une meilleure enveloppe, pas une garantie de règlement.

Il en va de même pour les « huit neuf » d’IBM. Le chiffre de 99,999999 % repose, selon la note de bas de page, sur des mesures et projections internes et sur une configuration précise de LinuxONE, z/VM, OpenShift, Operations Manager, GDPS et DS8000. Il ne couvre pas l’adaptateur, le registre Swift, les banques correspondantes, le RTGS ni le crédit final du bénéficiaire. La disponibilité de bout en bout reste celle de la chaîne, non celle de son maillon le plus robuste.

IBM affirme enfin que ses trois modèles de déploiement conservent architecture, API et flux de travail. Cela peut limiter la réécriture applicative. La portabilité réelle exige davantage : déplacer clés, politiques, historique des exceptions et preuves de décision vers un autre modèle ou opérateur, puis démontrer que la même transaction reste explicable.

Limite des preuves

Le statut bêta, l’architecture locale, l’adaptateur et la projection de disponibilité viennent du communiqué IBM, de la note produit IBM et de la page Digital Asset Haven. Le partage des rôles et l’état du pilote sont décrits dans le communiqué de juillet de Swift et sa page consacrée au registre. Le cadre indépendant provient des principes PFMI et du rapport BIS/CPMI sur la tokenisation. Les tests de reçus sont une analyse éditoriale.