トークン化預金には受取先の地図が必要だ

分析 | 2026年10月17日

Jack Henryは10月16日、Google Cloud Universal Ledgerでのトークン化預金対応計画を発表した。

販売・導入経路が広がると、次の問いが生まれる。どの支払いが可能になるのか。Open Market Notesは、実際に対応できる支払人と受取人の関係を基準に導入を評価する方法を提案する。以下の計算は架空の計画例であり、顧客の取引、普及状況、いずれかの提供会社のネットワーク範囲を推計したものではない。

Googleはプレビュー版と記載。

当方は発表された連携を検証していない。Googleの技術文書は同社のサービスを説明するもので、特定の銀行が何を導入したかを示すものではない。

利用できる関係を数える

Googleの送金仕様では、送信側に支払人のロール、受信側に受取人のロールが必要だ。

本稿の評価案では、経路とは、指定された支払人が想定条件の下で、合意した資産を指定された受取人に送れる関係を指す。連携先一覧に銀行名があるだけでは、この地図は埋まらない。用途ごとに実際の口座、資産、金額、利用時間帯を確認する。これは確認項目の提案であり、発表された商品に特定の制限があると主張するものではない。

送金方向も分けて記録する。一方から他方へ支払えたことだけでは、逆方向も使えるとは示せない。直接対応する支払いと、別のサービスを使う代替策も区別する。代替策に価値があっても、追加の手順は見えるようにしておく。

6行だけでは全体像は分からない

6行の銀行を3行ずつの二つのグループに分ける。この意図的に単純化したモデルでは、異なる銀行の順序付きの組み合わせを、直接送金の候補経路とする。6掛ける5で30経路となる。各グループ内の6本の有向経路はすべて使える。グループ間は使えず、仲介者による転送も認めない。したがって利用可能なのは30本中12本、40%だ。

ここで、一つ目のグループのある銀行から、二つ目のグループのある銀行への一方向の経路を追加する。参加銀行は6行のままだ。使える経路は30本中13本、約43.3%になる。この変更でグループ間の全組み合わせが自動的に使えるわけではない。それには別の前提が必要になる。

これは権限と利用可能な関係のモデルであり、GCULの構成図ではない。実際の仕組みでは転送や別のサービスが可能で、計算が変わるかもしれない。要点は、その能力を明示してから効果を数えることだ。

対応できる業務で地図を測る

固定した標本に、実行したい支払いが1,000件あるとする。700件は当初の12経路を使い、200件は新しい経路を使い、100件はその他の未対応経路を使う。すべての支払いが他の条件を満たし、開通した経路は試験中ずっと使えると仮定する。

当初のネットワークは標本の70%に対応でき、拡張後は90%になる。経路を一つ増やすと、可能な組み合わせに対する利用可能な割合は約3.3ポイントしか上がらないが、支払い件数で測る対応率は20ポイント上がる。どちらの数字も正しい。答えている問いが異なる。

この区別は導入計画の改善に役立つ。追加候補によって対応可能になる既存の支払いを基準に順位を付け、導入の手間と継続費用を比べる。よく使う関係を一つ開く方が、めったに使わない関係を複数開くより価値があるかもしれない。これは優先順位を決める方法であり、特定市場の支払いが集中しているという主張ではない。

件数と金額は別々に報告する。多数の少額支払いを扱う経路と、少数の高額支払いを扱う経路では、優先順位が異なり得る。どの経路が使えるか分かってから標本を選び直さず、未対応の指示も分母に残す。

最も重要な経路を試す

標本を変えずに新しい経路を停止すると、対応率は90%から70%に戻る。機関数は依然として6行だ。参加数の見出しだけでは、顧客にとっての有用性の大きな変化を見落とすことがある。

試験では同じ標本を維持し、受取先が利用できない場合、利用時間外、設計に関わるその他の条件も調べる。各指示について、提案されたサービスを使ったのか、代替経路が必要だったのか、未完了なのかを記録する。代替経路での成功は顧客にとって重要な結果だが、それを提案経路の可用性の証拠に置き換えてはならない。

次に有用なのは、代表的な支払い活動と結び付け、前提と失敗条件を示した受取先の地図である。幅広い導入経路は機会を生む。どの関係が実際に利用可能になるのかを示すことで、その機会がサービスになる。