要約

  • IBMは、Digital Asset Havenのオンプレミス展開と、Swiftのブロックチェーン型共有台帳につなぐISO 20022アダプターをベータとして発表した。オンプレミス版では、ソリューション層と鍵管理層を顧客のIBM ZまたはLinuxONE環境に置く。
  • 共有台帳を運用するのはSwiftであり、資産と資金は各銀行が管理する。最終決済は既存インフラを通じて台帳外で行われるため、行内署名、台帳受理、決済の確定は同じ出来事ではない。
  • 調達時に見るべきは、単一装置の主権や可用性ではなく、業務意思、方針、HSM署名、メッセージ変換、再試行、台帳上の順序、取消不能時点を一つの取引として照合できるかである。

金融機関が暗号鍵を自らの施設に置きたい理由は明快だ。取引を許可する最終的な手段を、公開クラウドの運用境界に預けたくない。IBMによると、Digital Asset Havenのオンプレミス版は、顧客のデータセンターにあるIBM ZまたはLinuxONE上で完結し、Crypto Express HSM、環境分離、文書化された鍵生成手順、コールドストレージ連携を備える。

この設計で行内に戻るのは、限定された意思決定面である。誰がシステムを管理し、どの方針で、誰の承認を受け、どの鍵で署名したかを銀行自身が記録できる。一方、発表はベータであり、一般提供日、価格、契約額、実運用件数、処理量や障害実績は示されていない。

もう一つのベータはISO 20022 Messaging Adapterだ。Digital Asset Havenのウォレット、署名、方針管理、Hyperledger Besu接続を使い、銀行の既存メッセージをSwiftの共有台帳上の取引へ結び付ける。既存の業務用語とデータ構造を捨てずに新しい調整層へ入れる点は、移行コストを下げ得る。

ただし、共有台帳の運用主体はSwiftである。銀行は資産と資金を保持し、Swiftの層が銀行間の支払コミットメントを検証・同期する。Swiftは7月、台帳が初期利用可能になり、六大陸の17行がトークン化預金による実取引の試行を準備していると発表した。現在のページには銀行名もある。これは組織されたパイロットの根拠であって、全面的な本番採用の根拠ではない。

さらに、確定処理は台帳外に残る。IBMは、トークン化預金の移動を24時間扱いながら、最終決済はRTGSなど既存の仕組みで行うと説明する。Swift自身も、資産・資金は銀行が管理し、決済は既存インフラで台帳外に実行されるとしている。台帳への記録は、銀行間の意思を同期した時点を示しても、その債務が法的・経済的に確定した時点と常に一致するわけではない。

「完了」を三つに分ける

行内の受領記録には、依頼者、目的、方針バージョン、承認者、HSM鍵、署名、緊急例外を含めたい。オンプレミス化は、この記録を銀行の監査境界に置く助けになる。しかし、設備の所在地だけで委任の正当性は生まれず、その後の受理も証明できない。

アダプターの記録は、元のISO 20022メッセージのハッシュを台帳取引へ結び、変換内容、冪等キー、送信回数、拒否・保留・受理、適用ルールを残すべきだ。応答が途絶えたとき、同じ取引の照会なのか、新しい経済的義務の作成なのかを判別できなければならない。

決済側の記録は、利用したインフラ、動いたポジション、取消不能時刻、最終性を示す。CPMI-IOSCOのPFMIが最終決済点と取消不能点の明確化を求めるのは、取引が自らの帳簿で処理されても外部主体の帳簿で処理されても、決済リスクが残るからだ。

三つを一つの「完了」表示に畳むと、障害時に責任が消える。行内では署名済みでもSwiftに届かない場合がある。台帳が受理しても、決済インフラが停止している場合がある。タイムアウト後の再送が重複価値を作る場合もある。必要なのは、状態を行内承認済み、送信済み、台帳受理済み、決済待ち、確定、拒否、取消、紛争中と分けることだ。

共通形式は最終性を配らない

ISO 20022は意味と識別子をそろえ、接続作業を減らす。だが、残高、制裁判断、準拠法、損失分担を自動的に決めるものではない。正しい形式は証拠を運べるが、その証拠に法的効果を与える制度までは提供しない。

IBMの99.999999%という可用性も範囲を限定して読む必要がある。注記では、IBM内部の測定と予測に基づき、LinuxONE、z/VM、OpenShift、Operations Manager、GDPS、DS8000の特定構成を条件としている。アダプター、Swift、相手行、RTGS、受取人への入金を含む端から端までの実績ではない。最も強い構成要素の数字を、鎖全体の数字として使うべきではない。

SaaS、ハイブリッド、オンプレミスでアーキテクチャ、API、ワークフローが共通だというIBMの説明は、アプリの書き直しを減らし得る。退出可能性は別だ。鍵、方針、例外履歴、判断記録を別方式へ移し、同じ取引を説明できて初めて移植性が証明される。

証拠の範囲

ベータの位置付け、行内構成、アダプター、条件付き可用性はIBMの発表資料、製品解説、Digital Asset Havenページに基づく。Swiftの役割と試行状況は7月の発表と共有台帳ページで確認した。独立した評価軸にはPFMIとBIS/CPMIのトークン化報告書を用いた。三層の受領記録は編集上の検収案である。