SWIFTが進める国際送金のオンチェーン化、預金トークン実証の到達点と課題
こんにちは。Decentier（ディセンティア）リサーチャーの聖・マーくんです。
世界の銀行をつなぎ、国際送金を支えてきたSWIFTが、ブロックチェーンを使った新たな基盤の構築を進めています。目指すのは、異なる国や銀行の間でも、夜間や休日に資金を動かしやすくすることです。実取引による検証は、銀行間の接続から企業の資金移動へと広がっています。
預金のオンチェーン化によって、国際送金の何が変わるのでしょうか。現在の仕組みと実証の内容をたどりながら、銀行間の処理がどう変わり、その先にどのような決済の姿が見えてくるのかを考えます。
国際送金を支える、情報とお金の二つの流れ
SWIFTは、世界の銀行などの金融機関をつなぎ、送金に必要な情報を安全にやり取りする通信ネットワークです。国際送金では、「誰から誰へ、どの通貨で、いくら支払うか」という支払指図を銀行間に届けます。この情報のやり取りに合わせて、各銀行は顧客の預金残高を更新し、決済用口座や決済システムを通じて銀行間の資金を受け渡します。
例えば、日本のA銀行から米国のB銀行へ、米ドルを送る場合を考えます。A銀行がB銀行に決済用の米ドル口座を持っていれば、A銀行は送金人の米ドル預金を減らして支払いを指図します。B銀行はA銀行の決済用口座から資金を引き落とし、受取人の預金口座へ入金します。顧客同士の送金を成立させるために、その裏側では銀行同士の支払いも行われるわけです。
他行のために決済用口座を管理し、支払いを取り次ぐ銀行を「コルレス銀行」と呼びます。この例ではB銀行がその役割も担います。直接の口座関係がなければ、別のコルレス銀行や現地の決済システムを利用し、異なる通貨で受け取る場合には為替交換も行います。
ここで重要なのは、こうした取引の記録をA銀行とB銀行がそれぞれ別々に管理していることです。
送金側のA銀行は、B銀行に持つ決済用口座について、自行の帳簿で残高や入出金、支払予定を管理し、必要な資金を用意します。一方、B銀行も、自行に開設されたA銀行の決済用口座について、自らの帳簿で残高や入出金を記録しています。
そのためA銀行は、自行で記録している入出金とB銀行から届く口座明細を照合し、両者が一致しているかを確認します。食い違いがあれば原因を調べ、必要に応じてB銀行へ問い合わせます。
受取側のB銀行でも、SWIFTで届いた送金指図と受取口座の情報を確認し、自行の記録と対応させながら処理を進めます。制裁審査などを経て入金しますが、情報の不足や不一致があれば、A銀行への照会や入金の保留、場合によっては返金も必要になります。
つまり、一つの送金でも、A銀行とB銀行が共通の帳簿を見て処理しているわけではありません。それぞれが自らの記録を持ち、銀行間でやり取りする情報や口座明細を照合しながら、「同じ取引を正しく処理しているか」を確認しています。
こうした確認を支えるため、SWIFTは複数のツールを提供しています。送金状況を追跡する「SWIFT GPI」や、関係する銀行が共通の取引データを参照し、情報の欠落や不整合を防ぐ「Transaction Manager」がその例です。ただし、これらは銀行間で必要な情報を共有しやすくする仕組みであり、各銀行の帳簿そのものが一つになるわけではありません。
また、日々の資金管理や記録の照合に加え、情報の不一致が生じた場合の照会や入金保留といった例外対応も、銀行の事務負担になります。
共有台帳で、銀行間の確認と調整を進める
SWIFTが構築を進める共有台帳では、このうち銀行間の支払関係を共通の記録で扱います。「どの銀行が、どの銀行に、いくら支払うのか」といった支払義務と、その処理状況を参加行が同じ記録で確認できるようにします。
今回の実証では、この共有台帳を各銀行の「預金トークン」の基盤と接続しています。預金トークンとは、銀行預金をブロックチェーンなどの台帳上で記録し、移転をプログラムで処理できるようにしたものです。
預金を払い戻す責任は銀行に残り、預金トークンを管理する基盤も銀行ごとに異なります。そのため、A銀行の預金トークン基盤に「B銀行へ支払う」と記録するだけでは、銀行間の送金は完結しません。SWIFTの共有台帳は、各行の基盤の間に入り、銀行間で生じる支払義務とその処理状況を共通の記録で管理します。
ここで扱われるのは、A銀行の預金トークンをそのままB銀行の顧客へ移す取引ではありません。送金人の預金はA銀行が減額し、受取人にはB銀行が自らの預金を入金します。その裏側で生じるA銀行からB銀行への支払義務を、共有台帳上でそろえる仕組みです。
ただし、共有台帳上で支払義務が確定しても、銀行間の決済まで完了するわけではありません。初期方式では、その義務を最終的に解消する資金の受け渡し、つまり「最終決済」には既存の決済手段を使います。
実際にSWIFTは2026年7月9日、共有台帳の初期利用準備が整い、17行が実取引の試行を準備していると発表しました。その後、8月19日には、HSBCとStandard CharteredがSWIFTの共有台帳を活用した初の実取引を完了したと公表しています。
両行は支払メッセージを交換し、そこから生じた支払義務を、それぞれの預金トークン基盤に記録しました。そのうえで、共有台帳を介して支払義務を照合・相殺し、既存のシステムで最終決済しました。
照合や相殺そのものは従来から行われています。今回の違いは、その前提となる銀行間の支払義務と処理状況を、共有台帳上の共通の記録をもとに確認・調整した点にあります。
金額や処理状況について銀行間の認識をそろえやすくなれば、食い違いの原因を調べる負担を減らせる可能性があります。また、「どの相手行に、いくら支払う必要があるか」を把握しやすくなれば、決済口座への資金補充も計画しやすくなります。
為替交換を伴う企業送金と、週末の資金移動へ
共有台帳を使った銀行間の接続は、企業向けの国際送金にも広がっています。
9月4日、BNP ParibasとHSBCは、Siemensの企業送金にSWIFTの共有台帳を利用したと発表しました。フランスのBNP ParibasにあるSiemensのユーロ口座から、英国のHSBCにある同社のポンド口座へ資金を移す取引です。
両行は為替交換と必要な資金を手配し、共有台帳を通じて銀行間の支払義務を確認したうえで、SiemensがHSBCの口座でポンドを利用できるようにしました。銀行間の最終決済は、その後、既存の手順で行われています。
この事例では、為替交換を伴う企業の国際送金にも、共有台帳を使った銀行間処理を組み込めることが確認されました。企業側は新しいウォレットや専用口座を用意する必要はなく、Siemensも従来の銀行口座をそのまま利用しています。ただし、従来方式との所要時間の比較は公表されておらず、共有台帳によって送金時間がどの程度短縮されたかは判断できません。
こうした企業送金への組み込みに加えて、利用できる時間帯を広げる実証も進んでいます。9月5日の土曜日には、DBSとCitiが共有台帳を使い、シンガポールから米国へのドル送金を実行しました。DBSによると、送金は数分で完了しています。
一方で、今回の実証では、銀行間の最終決済そのものは従来の仕組みに残っています。共有台帳によって銀行間の支払義務を確認・調整する部分は変わり始めていますが、その後の資金決済まで一体化されたわけではありません。
また、休日に顧客へ資金を使えるようにする場合、銀行間の最終決済が後になれば、受取銀行は最終決済までの信用・資金リスクを管理する必要があります。共有台帳で確認した支払義務に加え、決済資金の確保状況や相手銀行への与信枠などを踏まえて、顧客への入金を判断しなければなりません。
では、銀行間の最終決済までオンチェーンで行えるようになれば、国際送金はさらにどう変わるのでしょうか。
支払いの確認から、お金の受け渡しまで
SWIFTは共有台帳の機能拡張に向け、銀行間の決済に使うデジタル通貨の接続も検討しています。預金トークンに加え、規制に準拠したステーブルコインや中央銀行デジタル通貨などが選択肢として挙げられています。
具体的な通貨や方式はまだ決まっていませんが、こうしたデジタル通貨を共有台帳と連動できれば、銀行間の支払義務を確認するだけでなく、実際に資金を移してその義務を解消するところまでを、一連の処理としてつなげられる可能性があります。
例えば、A銀行の顧客がB銀行の顧客へ100万ドルを送る場合、両行が銀行間決済に利用できるドル建てのデジタル通貨を用意し、支払内容と必要な資金が確認できたら、A銀行からB銀行へ決済資金を移します。その結果をB銀行の顧客口座への入金までつなげる仕組みです。
異なる通貨を交換する場合には、二つの通貨の受け渡しを連動させることも考えられます。一方の通貨が支払われる場合に限って、もう一方も支払う「PvP（Payment versus Payment）」の仕組みを使えば、例えばユーロだけを渡してドルを受け取れないといった決済リスクを抑えられます。これは既存の為替決済インフラであるCLSでも使われている考え方です。
現在は、共有台帳で銀行間の支払義務を確認した後、別の決済システムを使って最終決済を行っています。将来、決済に使う資金そのものもオンチェーンで移転できるようになれば、銀行間の確認から最終決済までを既存の決済システムの営業時間に左右されず処理できるようになります。ここまで実現して初めて、国際送金の24時間365日対応が本格化します。
こうした仕組みを支えるうえで、ブロックチェーンの特徴が生きてきます。情報の共有や照合だけであれば、必ずしもブロックチェーンである必要はありません。一方、ブロックチェーンでは、お金を表すトークンの移転と、その移転を認める条件をスマートコントラクトで結び付けることができます。
SWIFTがブロックチェーンを使う意味は、各銀行で進む預金のオンチェーン化をつなぎ、銀行間の支払関係の確認から資金の移転までを共通の基盤で扱えるようにする点にあります。
今回の実証は、銀行間の支払義務を共通の記録で扱う段階から始まっています。最終決済までオンチェーンで行う方式はまだ決まっておらず、既存の仕組みと比較しながら実用性を検証していく必要があります。
国境も営業時間も越えるために、残る課題
銀行間の最終決済までオンチェーンで行えるようになれば、既存の決済システムの営業時間に左右されにくくなります。ただし、技術的に24時間動かせることと、銀行が実際に24時間サービスを提供できることは同じではありません。
まず必要になるのが、決済資金の確保です。銀行間決済を完了してから顧客へ入金できるようになれば、最終決済までの時間差を埋めるための与信は減らせます。一方で、銀行は決済に使うデジタル通貨を必要なタイミングで用意できなければなりません。
また、異なる銀行が発行する預金トークンは、それぞれ異なる銀行に対する請求権です。技術的につながったとしても、それだけで互いの預金を常に額面どおり受け渡せるとは限りません。銀行間決済に何を使うのか、そのデジタル通貨を誰が発行し、どのように額面で払い戻せるのかといった設計も必要です。
為替交換では、流動性とヘッジも課題になります。例えば週末は市場参加者が少なく、希望する金額やレートで取引できなかったり、銀行が為替変動リスクを十分にヘッジできなかったりする可能性があります。その場合、顧客への提示額を制限したり、レートにリスク分の費用を上乗せしたりすることになります。週末にドルを送れることと、幅広い通貨をいつでも交換できることは分けて考える必要があります。
技術面では、共有台帳と各銀行のシステム、さらに他の台帳との処理を確実につなぐことが求められます。例えば、銀行間決済は完了したのに顧客への入金だけが止まった場合、処理状況を把握し、二重入金を起こさずに再開できなければなりません。複数の台帳をまたぐ取引では、一方の処理だけが完了する事態を防ぐ仕組みも必要です。大量の取引への対応や、取引情報を閲覧できる参加者の範囲も検証課題になります。
制度面では、台帳上のどの時点で支払いが法的に確定するのかを明確にする必要があります。相殺の法的な有効性や、取引銀行・デジタル通貨の発行者が破綻した場合の請求関係を整理するとともに、顧客確認や制裁審査も実際の業務に組み込まなければなりません。
コストも重要です。銀行が十分な決済資金を常時確保すれば即時決済には対応しやすくなりますが、その分だけ資金を維持するコストは増えます。企業側の待機資金や銀行の事務負担を減らせても、別のコストが増えれば、国際送金全体が安くなるとは限りません。
送金時間だけでなく、資金調達や為替、システム運用、事務処理まで含めて、既存の仕組みに対してどこまで実用上のメリットを生み出せるかが問われます。
SWIFTの接続力と、企業の資金管理への広がり
SWIFTの強みは、多くの金融機関との接点と、銀行間の情報や業務手順を標準化してきた経験にあります。共有台帳でも、各銀行がそれぞれ構築する預金トークン基盤や既存システムをつなぐ役割に、この強みを生かそうとしています。
銀行が既存のシステムを活用しながら共有台帳へ接続するための仕組みも登場しています。9月24日にはIBMが、金融メッセージの国際標準「ISO 20022」を使って共有台帳へ預金トークン取引を指図する機能をベータ版として発表しました。9月28日にはOracleも、銀行の預金トークン基盤と既存の送金システムをSWIFTの共有台帳につなぐ連携を発表しています。
既存のシステムや業務手順を大きく変えずに接続できれば、銀行にとって共有台帳を導入するハードルも下げられます。
SWIFTはこれまでも、新しいブロックチェーン基盤との接続を検証してきました。2023年にはChainlinkと協業し、既存のSWIFT接続から複数のチェーンにまたがる模擬的な資産移転を実施しています。今回の共有台帳でChainlinkの技術が採用されていることは確認されていませんが、銀行が接続先ごとに個別の仕組みを構築する負担を減らすという考え方は共通しています。
今後の焦点は、共有台帳を使った国際送金が単発の実証を越えて、日常的な利用に広がるかです。銀行側で照合や例外対応、資金管理の負担を実際に減らせるかに加え、最終決済まで24時間365日利用できる仕組みへ発展するかが重要になります。
それが実現すれば、企業の資金管理にも影響が及びます。海外拠点への送金を銀行の営業時間や締め時間に合わせて前倒ししたり、着金までの時間を見込んで各拠点に余分な資金を置いたりする必要を減らせる可能性があります。必要なタイミングで資金を移せるようになれば、グループ内の余剰資金を集約し、必要な拠点へより機動的に配分しやすくなります。
SWIFTの共有台帳が目指しているのは、既存の国際送金網を一から置き換えることではありません。各銀行が持つ預金や既存システムを活かしながら、その間を共通の基盤でつなぎ、銀行間の確認から資金移転までをより一体的に処理できる仕組みへ発展させようとしています。
実証はまだその途上にありますが、世界の銀行をつないできたSWIFTが、情報を届けるネットワークから、デジタル化されたお金の移転まで支える基盤へ役割を広げられるか。今後の国際送金の姿を考えるうえで、その進展は重要な試金石になりそうです。
▼ ブロックチェーン、AIに関するコンサルティングやプロダクト開発のご相談は当社ホームページのお問い合わせよりご連絡ください。
▼ Decentierでは一緒に働く仲間を募集しています。
