ECB、3つのモデルを提示：焦点は決定ポイント

ECBは中央銀行マネーをオンチェーン化する3つのモデルを提示したが、トレーダーや機関投資家にとっての実質的な市場シグナルは、トークン化決済の規制経路がより明確になったことだ。アプローチを完全なDLT統合、ハイブリッド発行、または第三者によるトークン化に分類することで、ECBはユーロシステムの監督に適合する可能性が高いインフラ投資を示している。重要な不確実性は、これらのモデルが既存のステーブルコインの仕組みに対応するのか、それとも別個の決済レイヤーを強制するのかという点だ。

ECBの3つのモデルがトレーダーにとっての決済最終性をどう変えるか

デジタル決済を検討している機関にとっての実務的な疑問は、新しいインフラが実際に資金の移動方法を変えるかどうかだ。ECBの3つのモデル（内部ではPontesおよびAppiaプロジェクトとして知られる）は、中央銀行台帳と商業銀行台帳の関係を定義することで、この疑問に答えている。各モデルは、誰が負債を保有し、どのように決済最終性が達成されるかを変え、これが資金管理部門や決済チームが管理しなければならない流動性と運用リスクに直接影響する。

最初のモデルでは、中央銀行がエンドユーザーに直接トークン化された請求権を発行し、中央銀行が唯一の決済エージェントとなる。これにより、負債が中央銀行のバランスシート上にあるため、最も高い最終性が得られるが、中央銀行がリテール向けインフラを管理する必要があり、これは歴史的に避けてきた役割だ。2番目のモデルでは、トークン化された請求権は商業銀行レベルに置かれ、中央銀行はホールセール決済レイヤーのみを提供する。

ここでは、商業銀行が自社のトークン化負債の信用リスクを吸収し、中央銀行の台帳は純額の銀行間ポジションのみを清算する。3番目のモデルはハイブリッドだ。中央銀行マネーと商業銀行マネーの両方が同じDLT環境に共存する共通プラットフォームで、スマートコントラクトが2つの負債タイプ間の決済ロジックを管理する。

注目すべき重要な限界は、各モデルにおける法的最終性だ。分散型台帳上のトークン化決済は、従来の中央銀行送金と同じ法的地位を自動的に継承するわけではない。ユーロシステムが、トークン化された中央銀行請求権のDLTベースの移転が決済最終性指令に基づく最終決済を構成するかどうかを明確にするまで、運用リスクを完全に価格設定することはできない。

これらのモデルを評価する読者にとって、すぐに確認すべきことは、自社の資金管理業務がTARGET2と同じ法的確実性を必要とするかどうか、それともパイロット段階では契約上の決済枠組みで許容できるかどうかだ。

直接トークン化モデルのワークフローチェック

ECBが最も強く支持するモデル（直接トークン化中央銀行マネー）は、商業銀行に中央銀行のバランスシートに対するトークン請求権を提供し、共有DLTプラットフォーム上で決済される。実際には、中央銀行が直接負債を表すデジタルトークンを発行し、商業銀行が証券や他のトークン化資産が存在する同じ台帳上でそのトークンを保有・移転する。

運用上の利点はアトミック決済だ。資産と支払いレッグが同時に決済され、従来のDVP（引渡し対支払い）システムで信用リスクを生み出すタイミングのミスマッチが排除される。ECBのPontesプロジェクトは、中央銀行の既存の決済システムをトークン化資産台帳に接続する専用のDLTインフラを使用して、まさにこのワークフローをテストしている。

このメカニズムは、中央銀行が共有台帳上でトークンの発行・償還ルールを管理する場合にのみ機能する。商業銀行は中央銀行のノードにリクエストを送信し、中央銀行はレガシーTARGETシステムに保持されている銀行の準備金口座に対してトークンを発行または焼却する。トレーディングデスクや資金管理部門にとっての結果は、中央銀行と商業銀行の両方が参照でき、別々のデータベース間の照合を必要としない、単一で検証可能な決済イベントの記録だ。

The Blockの報道によると、ECBはこのインフラをAppiaプロジェクトを通じて構築しており、このプロジェクトは決済インターフェースに焦点を当てたPontesプロジェクトとは別に、DLTレイヤー自体に焦点を当てている。

重要な限界は採用規模だ。ECBはこのモデルがクロスボーダーまたは多通貨決済をサポートするかどうかをまだ明らかにしておらず、現在のテストには限られた数の参加機関のみが含まれている。このインフラを評価するトレーディングデスクは、カウンターパーティ銀行がECBのパイロットグループに含まれているかどうか、また決済する特定の資産クラス（国債やマネー・マーケット・ファンドのシェアなど）がPontesテストの範囲に含まれているかどうかを確認する必要がある。

その確認がなければ、ワークフローはプロトタイプのままであり、本番オプションではない。

決定ポイント：流動性、カウンターパーティリスク、モデル選択

3つのモデルフレームワークは、機関がパスを選択する前に評価しなければならない管理上のトレードオフを導入する。直接トークン化モデルでは、中央銀行が負債と決済最終性を完全に管理するが、商業銀行は別々の台帳にわたって流動性を管理する能力を失う。2番目のモデル（合成中央銀行マネー）では、商業銀行が中央銀行に保有する準備金を裏付けとして自社のトークン化負債を発行でき、流動性管理の柔軟性が高まる。

3番目のモデルは負債移転メカニズムで、既存の中央銀行預金をDLTブリッジを介して移転し、新しいトークン形式を作成せず、現在の法的構造を維持しながら決済レイテンシーの制約を追加する。

重要な決定境界は技術的実現可能性ではなく、運用リスクの配分だ。直接トークンモデルを好む商業銀行は、単一の台帳でのアトミック決済を得るが、流動性バッファーを完全にそのトークンで維持する必要があり、ストレス期間中にオフチェーンの準備金口座と代替可能でない可能性がある。

合成モデルは、銀行がシステム間で日中ポジションをネッティングできるようにすることでこの問題を解決するが、カウンターパーティリスクを導入する。トークンは発行銀行の準備金の裏付けと同じだけの価値しかなく、中央銀行は直接負債と同じ方法でトークンを保証しない。負債移転モデルはトークン設計とカウンターパーティの両方の問題を回避するが、ブリッジのスループットに依存し、ピーク取引時間中のホールセール決済に必要な取引量をサポートできない可能性がある。

トレーダーまたは決済運用リーダーにとって、実務的なチェックは、自社のカストディアンまたはプライムブローカーがどのモデルを示唆しているかだ。ECBは単一のモデルを義務付けておらず、PontesおよびAppiaプロジェクトは3つすべてを並行してテストしている。自社の決済フローが複数の資産クラスにわたってリアルタイムの最終性を必要とする場合、直接トークンモデルは最も強力な保証を提供するが、流動性プールは最も狭い。

既存の準備金口座とネッティングワークフローを維持する必要がある場合、合成モデルがより実用的な適合性を持つが、それはカウンターパーティの準備金の裏付けがオンチェーンで検証可能な場合に限られる。未解決の条件は相互運用性だ。ある中央銀行のDLTインフラからのトークンが、別の管轄区域のシステムからのトークンとどのように決済されるかを解決するモデルはまだない。このギャップが、モデル選択後の次の決定ポイントを定義する。

トレーダーと決済オペレーターにとって、重要な決定チェックは、直接トークン化モデルの決済最終性がマルチ台帳流動性管理の喪失を正当化するかどうか、または合成モデルの柔軟性が発行仲介業者からの追加信用リスクを上回るかどうかだ。ECBは単一のパスにコミットしておらず、PontesおよびAppiaプロジェクトは実験段階のままなので、実際的な次のステップは、担保やカストディワークフローを再配分する前に、ライブのホールセールトライアルでどのモデルが採用されるかを監視することだ。

参考

• https://www.theblock.co/news/regulation/2026-10-02-ecb-outlines-three-models-for-putting-central-bank-money-onchain-417552