【速攻解説】「Project Pax」は何を目指しているのか?(国際送金の基本やSwiftの役割から、SCのチャレンジと乗り越え方まで、必要な情報全部まとめ)
こんにちは、プログラマブルな信頼を共創したい、Progmat(プログマ)の齊藤です。
2024年9月5日に、本年9件目のプレスリリースを発信しました。
タイトルは、「クロスボーダーステーブルコイン送金基盤構築プロジェクト「Project Pax」の始動 および 国内外金融機関との実証実験の開始について(Progmat and Datachain Launch Project Pax - Initiating Pilot Test for Cross-Border Stablecoin Transfer Platform with Financial Institutions Worldwide)」です。
昨日の日経電子版(イブニングスクープ)、本日の日経朝刊(一面アタマ)でも報道されていた取り組みです。(人生8度目の一面)
===2024/9/18追記===
国際決済銀行(BIS)が進める「Project Agora」の日経朝刊掲載と合わせて、改めて「Project Pax」も朝刊で紹介されています。
また、シリーズ的に継続開催中の「CoinDesk JAPAN Talk -RWA-」で1時間まるまる本件を解説していまして、通常回比較で多くの方に聴いていただいているようなので、よろしければこちらも!(アーカイブ収録聴けます)
===追記おわり===
プレスリリース等を実施したイベント週では、
情報解禁後いち早く正確に、背景と内容についてこちらのnoteで解説しています。
”銀行送金”、”国際送金”、”クロスボーダー×ブロックチェーン”…といった単語が出てくる際に必要な背景知識は、一式全て盛り込んだつもりです。
読めば読むほど味わい深い内容になっている一方、これまでで最大の分量となっているので、ぜひブックマークのうえ随時お手元でご参照いただけますと執筆者冥利につきます…!
ということで、通算28回目の本記事のテーマは、
「【速攻解説】「Project Pax」は何を目指しているのか?(国際送金の基本やSwiftの役割から、SCのチャレンジと乗り越え方まで、必要な情報全部まとめ)」です。
要旨
時間のない方向けに、端的にサマると以下のとおりです。(動画でコンセプトはザックリわかると思います)
前提、「現状の国際送金プロセス」を含む銀行送金とは、現金の物理的な直接輸送を伴うことなく、繋がりをもった銀行間のデータ連携(勘定データの異動の連鎖)により、デジタル上で価値を移転する仕組みです。
銀行間のデータ連携のための世界的な標準インフラを提供し、世界中の金融機関間のやりとりを可能にしているのが、「Swift」です。
G20/FSBがおおむね2027年までの解決目標としている「クロスボーダー送金の課題」は、「①送金コスト」「②着金スピード」「③アクセス」「④透明性」です。
ソリューションとして期待されているブロックチェーン技術を用いた送金アプリケーションとして、「Stable Coin(日本の”電子決済手段”)」、「Tokenized Deposit(トークン化された預金)」、「CBDC(中央銀行デジタル通貨)」があります。
SCは、物理的な現金や、間接当事者が多い既存の銀行送金と比較して、「デジタル完結かつ直接的な価値移転が可能な”デジタル上の現金”」という性質を有しています。
ただしファクトとして、海外で先行していた既存のSCは、「暗号資産取引」セグメントでの利用に留まっているという現状があります。
実体経済におけるSC活用のハードルの1つを「利用法人における、自己管理ウォレット導入や既存プロセスと複線化してしまうことのハードルの高さ」にあると捉え、「自己管理ウォレット利用によるP2P送金」の選択肢(利用者の状況によるため、このパターンも否定しません)に加えて、”もう1つの選択肢”を新たに提供することで利活用範囲を拡張するのが「Project Pax」です。
具体的には、「銀行UI」「Swift APIプラットフォーム」「SC」の仕組みを融合したハイブリットな「クロスボーダーSC送金基盤」の構築を目指しています。
3メガバンク以外の外国金融機関を含めた関係金融機関の座組みや、Datachain&TOKIとタッグを組んで取り組むプロダクトの詳細は、進展に応じて継続的に情報を公開していきます。(一緒に世界に挑むメンバー募集中!)
では、順番に解説していきます。
そもそも、現状の国際送金ってどんな感じ?
”トークン化”による新たなソリューションのポイントを理解するために、背景として「現状の国際送金」の”今さら聞けないキホンの部分”を俯瞰してみます。
さらに、「現状の国際送金」を理解するための”今さら聞けない大前提情報”として、単純な「現状の国内送金(内国為替)」を俯瞰したうえで、「現状の国際送金」へと話を進めたいと思います。
実際の実務はさまざまなパターンがあるところですが、シンプルな1例ということで、思い切って焦点を絞って図解していきます。
(金融機関の中でも決済領域のご担当の方等、この分野のプロの方にとっては、既知かつ突っ込みたくなるレベルで時系列等をシンプル化した内容になるので、適宜次の章へ飛んでいただければと思います)
まずは大前提の「現状の国内送金(内国為替)」のポイント
たとえば企業Xから企業Yへ送金したい場合、現金をトラックに積んで企業Yの財務部へ直接届けるようなことは、通常しないでしょう。
(物理的にできなくはないですが、様々なリスクやペインがありすぎる)
現金を届けなくてもいい方法として、銀行間ネットワーク(内国為替)を利用する方法があります。
ということで、内国為替における主要な取引参加者とバランスシートを俯瞰します。(図表1)
【X】
送金元企業
【Y】へ送金したい
【Bank A】
【X】の取引先銀行
【X】からの送金依頼を受けて【Y】の口座へ入金したい(=仕向け銀行)
中央銀行に当座預金残高を有する
【Bank D】
【Y】の取引先銀行
【Bank A】からの送金依頼を受けて【Y】の口座へ入金したい(=被仕向け銀行)
中央銀行に当座預金残高を有する
【Central Bank①】
Country①における中央銀行
【A】や【D】からの当座預金を受け入れ、貸出や国債買入等を実施している
ここで、金融機関の中の人にとっては当然の常識ながら、金融機関の中の人ではない大多数の方にとっては”肌感覚に反する”前提情報についても触れておきます。それは、銀行にとって、「預金は負債である」ということです。
【預金】
企業/個人にとっては「債権」(バランスシート左側の「資産」)
銀行にとっては「債務」(バランスシート右側の「負債」)
【中央銀行当座預金】※例:日銀当預
銀行にとっては「債権」(バランスシート左側の「資産」)
中央銀行にとっては「債務」(バランスシート右側の「負債」)
では、”お金”を動かしていきます。
(以後、図解趣旨に照らしたシンプル化のために、銀行送金手数料や外国為替手数料等はゼロとして見ていきます)
①:【X】が【Bank A】に、【Bank D】の【Y】名義の口座への送金依頼[20]を行う
②:【Bank A】には【Bank D】に対する支払債務が、【Bank D】には【Bank A】からの受取債権と同時に【Y】への支払債務が、それぞれ[20]ずつ発生する
③:【Bank A】と【Bank D】間の債権/債務を清算し、差額を【Central Bank①】内の当座預金振替(【A】残高→【D】残高)によって決済する
④:【Bank A】の【Central Bank①】への預け金残高が[80](100‐20)になる
④’:【Bank D】の【Central Bank①】への預け金残高が[120](100+20)になる
⑤:【Bank D】において【Y】への支払債務[20]を解消し、代わりに【Y】からの預金(債務)を[120](100+20)に増やす
⑥:【Bank D】から【Y】へ[20]の入金通知を行う
かくして、現金を直接輸送せずとも、銀行間ネットワークを利用することで無事に【Y】の口座へ入金することができました。
ここまで確認してきた銀行間ネットワークを利用した送金方法において、ポイントは以下の点です。
【ポイント①】銀行間で支払債務/受取債権が発生していることが前提
【ポイント②】銀行間で預金債務/預け金を持ち合っていることが前提
【ポイント③】銀行間で支払債務/受取債権の異動と、預金債務/預け金の異動とを連鎖させることで、物理的な現金の異動と伴うことなく、勘定の異動(=デジタル上の数値変動)だけで送金を実現
【ポイント④】仕向け銀行と被仕向け銀行との”中継”は、双方の口座を有する中央銀行が実施
上記のポイントを念頭に置きつつ、いよいよ「国際送金」の流れを確認していきます。
次に「現状の国際送金」のポイント
先ほどのポイント①~④のうち、内国為替と国際送金の最大の違いは、仕向け銀行の所属国と被仕向け銀行の所属国が異なるため、中央銀行がそれぞれの国毎に存在し、「双方の口座を有する中央銀行」が存在しない、という点です。
【ポイント④】が満たせず、そのままでは【ポイント①】【ポイント②】を満たせないことで、【ポイント③】も実現できない、ということになってしまいます。
すべての仕向け銀行と被仕向け銀行が、それぞれ直接口座(預け金/預金)を持ち合うことも理屈としては可能ですが、N:Nで口座を持ち合うのは非常に資金効率が悪いうえ、預金先銀行の信用不安時には預け元の銀行にも大きな被害が波及する虞があるため、あまり現実的ではありません。
そこで中央銀行や各個別行に代わって、大元の仕向け銀行と最終的な被仕向け銀行を繋ぐための、”中継銀行”が必要となります。
この”中継銀行”こそが、いわゆる「コルレス銀行(Correspondent Bank)」です。
ある銀行が「コルレス銀行(コルレス先)」と結ぶ「コルレス契約」とは、為替業務の代行に関する契約です。取り決め内容は個別行間で様々ですが、例えば「為替決済口座(コルレス口座)」を開設してその口座から相手先口座に送金をしてもらう、などの取扱いを規定しています。
ということで、国際送金における主要な取引参加者とバランスシートを俯瞰します。(図表7)
【X】
送金元企業
【Y】へ送金したい
【Bank A】
【X】の取引先銀行
【X】からの送金依頼を受けて【Y】の口座へ入金したい(=仕向け銀行)
Country①の中央銀行にのみ当座預金残高を有する
外国金融機関とコルレス契約を締結していない(できない)ため、国内の【Bank B】と契約を締結し、国際送金業務を委託している
※例:日本の地方銀行
【Bank B】
Country①の中央銀行にのみ当座預金残高を有する
外国金融機関【Bank C】とコルレス契約を締結し、コルレス口座を有している
【Bank A】等の国内銀行とも契約を締結し、外国為替業務を受託している
※例:三菱UFJ銀行
【Central Bank①】
Country①における中央銀行
【A】や【B】からの当座預金を受け入れ、貸出や国債買入等を実施している
【Bank C】
Country②の中央銀行にのみ当座預金残高を有する
外国金融機関【Bank B】とコルレス契約を締結し、【Bank B】のコルレス口座を開設している
【Bank D】等の国内銀行とも契約を締結し、外国為替業務を受託している
例:JP Morgan
【Bank D】
【Y】の取引先銀行
【Bank A】(及びその委託先)からの送金依頼を受けて【Y】の口座へ入金したい(=被仕向け銀行)
Country②の中央銀行にのみ当座預金残高を有する
外国金融機関とコルレス契約を締結していない(できない)ため、国内の【Bank C】と契約を締結し、外国為替業務を委託している
※例:外国の地方銀行
【Central Bank②】
Country②における中央銀行
【C】や【D】からの当座預金を受け入れ、貸出や国債買入等を実施している
図表の中で薄青色でハイライトしている【Bank B】がCountry①におけるコルレス銀行、【Bank C】がCountry②におけるコルレス銀行、です。
双方がお互いに有しているコルレス口座(図中ではB→Cのみ図解し、C→Bの口座は割愛)は、各当事者の勘定科目としては例えば以下のように処理されています。
コルレス口座の勘定科目(例)
口座開設元の銀行にとっては「外国他店預け」(バランスシート左側の「資産(債権)」)
口座開設先の銀行にとっては「外国他店預り」(バランスシート右側の「負債(債務)」)
【X】から外国の【Y】へ[20]送金した後の”ゴールイメージ”を先に図示すると、図表8のとおりです。
(【A】のB/Sが▲20、【D】のB/Sが+20で、コルレス銀行【B】【C】のB/Sは±0)
では、どういった経路で上記の”ゴールイメージ”まで到達するか、順を追って確認します。
(以後、図解趣旨に照らしたシンプル化のために、銀行送金手数料や外国為替手数料等はゼロとして見ていきます)
①:【X】が【Bank A】に、【Bank D】の【Y】名義の口座への送金依頼[20]を行う
内国為替との最大の違いは、【Bank D】がCentral Bankの当座預金を介して繋がっている先ではないという点
送金依頼時に利用する”あるコード”を指定することで、【Bank A】から【Bank D】に到達するための経路が事後的に決定される(ここが非常に重要なポイント=次の章で解説します)
②:【Bank A】には【Bank B】に対する支払債務が、【Bank B】には【Bank A】からの受取債権と同時に【Bank C】への支払債務が、【Bank C】には【Bank B】からの受取債権と同時に【Bank D】への支払債務が、【Bank D】には【Bank C】からの受取債権と同時に【Y】への支払債務が、それぞれ[20]ずつ発生する
③④:【Bank A】と【Bank B】間の清算/決済は内国為替と同様
⑤:【Bank B】内で、中銀預け金残高から【Bank C】への預け金残高へ[20]を振替
⑥:【Bank C】内で、【Bank B】からの預り金(負債)が[20]増加した分、バランスシートの資産の部である中銀預け金残高が[20]増加して、バランスする
⑦:上記やりとりで【Bank B】と【Bank C】間の清算/決済が完了する
⑧⑨:【Bank C】と【Bank D】間の清算/決済は内国為替と同様
⑩⑪:【Bank D】から【Y】への入金通知までは内国為替と同様
かくして、現金の海上輸送等で物理的に国境を越えずとも、銀行間ネットワークを利用することで無事に【Y】の口座へ入金することができました。
ここまで確認してきた銀行間ネットワークを利用した国際送金方法において、ポイントは以下の点です。
【ポイント①】銀行間で支払債務/受取債権が発生していることが前提(内国為替と同じ考え方)
【ポイント②】銀行間で預金債務/預け金を持ち合っていることが前提(内国為替と同じ考え方)
【ポイント③】銀行間で支払債務/受取債権の異動と、預金債務/預け金の異動とを連鎖させることで、物理的な現金の異動と伴うことなく、勘定の異動(=デジタル上の数値変動)だけで送金を実現(内国為替と同じ考え方)
【ポイント④】仕向け銀行と(外国)被仕向け銀行とが直接的に繋がっていない場合、各行と直接繋がりのある(複数の)銀行を”中継”する必要があり、”中継地点”を含めた「経路設定」が不可欠となる
ここで、先ほど後述するといった「経路設定」のために利用する”あるコード”の関係組織として登場するのが、皆さまお待ちかねの「スイフト(Swift)」です。
いまさら聞けない「Swift」って、なに?
「Swift」の役割/ポジション
ここまでの「前提情報」時点で既に6,000字近くあるのですが(!)、上記の「現状の国際送金の基本」が頭にあると、「Swift」の役割/ポジションが理解しやすいと思います。
※詳細に知りたい方は、リンク先のSwiftのHPをご覧下さい(*英語です)
「Swift」=Society for Worldwide Interbank Financial Telecommunication=”国際銀行間金融通信協会”、です。
「Swift」とは何か?について、関係組織による公式な説明内容をいったんそのまま転載します。
つまり、エッセンスを抜粋&まとめると以下のとおりです。
「Swift」は、金融機関等が加盟する協同組合
本拠はベルギーで、グローバルに拠点展開(日本の事務局は全銀協)
提供しているのは、金融メッセージングサービスとその標準
そのネットワークにより、200以上の国又は地域で11,000以上の銀行、証券会社、市場インフラ、事業法人顧客を結んでいる
「Swift」自身が資金を保持したり口座を管理するものではない
既に前章でつぶさに見てきたとおり、「現状の国際送金」において、自身のバランスシートを使って(=勘定の異動により)、デジタル上でバケツリレーのようにデータを動かしている当事者は銀行(仕向け銀行、コルレス銀行、被仕向け銀行)であり、「Swift」のバランスシートは登場しません。
国際送金の当事者である銀行間で勘定を異動するための情報をやりとりする際に、個別にバラバラのフォーマットでやりとりするのはあまりにも非効率なので、世界的に標準化されたサービス/プラットフォームを「Swift」が提供しているということです。
標準化内容の典型的な代表例は、送金先として指定する世界各国の金融機関の特定方法でしょう。
これが、国際送金プロセスの解説の中で、「経路設定」のために利用する”あるコード”と表現していた、「SWIFTコード」(またの名を「SWIFT BIC(Business Identifier Code)」ともいう)です。
メッセージフォーマットの”これまで”と”これから”
では、このようなコードを入力するメッセージフォーマットとは、具体的にどんなイメージなのでしょうか?具体例で解像度を高めていきます。
これまでの送金指図のフォーマットは「MTフォーマット」と呼ばれ、通信容量に制限があった1970年代から利用されている古いデータフォーマットです。
MTフォーマットは、メッセージ内容を人の目で識別することを想定して開発されたアナログな仕組みで、「フィールド」と呼ばれる入力欄に複数の送金情報を一括入力することを求めており、”固定長形式”で入力できる情報量も限られているうえ、国際送金取扱時の大前提である”アンチマネーロンダリング(AML)”のスクリーニングが困難である等の課題を内包しています。
また、送金元企業(先ほどの例でいえば【X】)から取引銀行(【Bank A】)への送金依頼、送金先企業(【Y】)への入金通知には、MTフォーマットとは別のフォーマットが使用され、国際送金プロセスが複雑化する一因にもなっています。(図表19)
こうした中で、「Swift」が提供する”銀行間伝達手段”のフォーマットを、MTフォーマットから「MXフォーマット(ISO20022規格)」に移行する、というのが現在の動きになっています。(既に並行稼働は開始されており、2025年11月までに完全移行することが目指されています)
ISO20022は、国際標準化機構(ISO)が定める「金融メッセージの世界共通規格」のことで、XML(Extensible Markup Language=”拡張可能なマークアップ言語”)というコンピュータ言語に準拠したフォーマットであり、多くのシステムやソフトウェアでの活用において高い柔軟性を持つ仕組みになっています。
ISO20022に準拠したMXフォーマットでは、従来のMTフォーマットと比較し、資金決済に必要な情報だけでなく、お客さまの取引に関わる豊富な情報を、システム処理に適した形で送受信することが可能です。
さらにいえば、「Swift」のみならず世界各国の内国為替における標準として続々と採用されていることから、データフォーマットの共通化・標準化が実現され、国際送金プロセス複雑化の一因でもあった”フォーマットバラバラ問題”の解消に繋がるものと期待されています。
「クロスボーダー送金」の課題と潮流とは
「現状の国際送金プロセス」と「Swift」について確認してきましたが、課題はないのでしょうか?
ここまでで既に9,000字超(!!)あるのですが、ここからステーブルコインのPros/Consや、「Project Pax」の内容に踏み込んでいきます。
クロスボーダー送金を巡る国際的な動きを、時系列でハイライトすると以下のとおりです。
2017年:「G20」が”クロスボーダー送金の改善”を優先事項に設定
2020年:「FSB(Financial Stability Board=”金融安定理事会”)」が「行動計画」を策定
2021年:「FSB」が「ロードマップ」を作成
この「ロードマップ」の中で達成目標として掲げられている4つの項目は、裏返すと”改善余地のある現状の課題”といえます。
【ターゲット①】送金コスト
クロスボーダー送金の平均コストを1%未満とする(~2027年)
全ての送金ルートのコストが3%を上回らない(~2030年)
【ターゲット②】着金スピード
クロスボーダー送金の75%が1時間以内に着金する(~2027年)
残り25%が1営業日以内に着金する(~2027年)
【ターゲット③】アクセス
全てのエンドユーザーが送金/着金手段として少なくとも1つは選択可能なオプションを持つ(~2027年)
【ターゲット④】透明性
トータルコスト、着金までに予想される時間、送金ステイタスのトラッキング、サービス条件等が透明である(~2027年)
※詳細に知りたい方は、リンク先の「FSB」のレポート原文をご覧下さい(*英語です)
このような世界的な目標(≒課題感)の下、クロスボーダー送金の新たな規格に関する様々なプロジェクトが動いています。
「送金コスト」「着金スピード」「アクセス」「透明性」…ブロックチェーン文脈でよく語られる、既視感がありすぎる単語たちですね。笑
こうした潮流の中で、課題解決に向けたソリューションの1つとして期待されているのがブロックチェーン技術です。
ブロックチェーン×クロスボーダー送金のアプリケーションとして、「Stable Coin(日本でいえば”電子決済手段”)」のほか、「Tokenized Deposit(トークン化された預金)」「CBDC(中央銀行デジタル通貨)」等がある、という位置づけです。
クロスボーダー送金とSC
「現状の国際送金プロセス」では、銀行間で勘定データをバケツリレーで異動させることでデジタルに価値を移転でき、”現金の直接移動(物理的な輸送)”に伴うリスク/ペインを回避することが可能でした。
他方で、銀行間のバケツリレーを介する場合、各プロセスにおいて図解の中では捨象した多くの手続(AML対応等)も都度不可避となり、それが前述の課題に繋がっている一面もあります。
現金は、物理的な移動/輸送を伴う一方、支払者(エンドユーザー)において特段の手続を要さず、相手方に直接支払可能(=渡せば終わる)という性質を有しています。
※少なくとも、日本円紙幣等の偽造の疑いの僅少なものについては
こうした比較感で考えると、SCを以下のように捉えることもできそうです。
SCとは、現金のような物理的輸送を伴うことなく、固定的な価値を直接移転する手段である
SCとは、銀行間の勘定データの異動を伴うことなく、デジタル完結で固定的な価値を移転する手段である
つまりSCとは、物理制約なく直接移転が可能な”デジタル上の現金”のようなものである
さらにいえば、SC(日本の”電子決済手段”)は、BitcoinやEthereumのような(発行体不在の)暗号資産とも異なり、パーミッションドチェーン利用やパーミッションレスチェーン×移転先統制(いわゆるホワイトリスト型運用)実装も可能なため、高い水準のAML対応が求められるユースケースであっても対応することが可能です。
では、実際の「既存のSC」(USDTやUSDC)の状況を見てみます。(数値は24/8月)
既に何度か同じ図表で解説してきましたが、(そもそも根拠法がなく正面から利用できなかったこれまでの日本市場は置いておくとして)グローバル市場でSCが利用されているシーンは、ほぼほぼ「暗号資産取引」に留まっている、というのが現状かと思います。
(USDCは「暗号資産取引以外」のセグメントへの展開を試行中も途上)
ということで「SC×クロスボーダー決済」のポテンシャルを真剣に追及するうえでは、「暗号資産取引」と「法人間決済(/リテール)決済」とのセグメントの違いで利用状況に大きく差が出る構造的な理由について、考察する必要がありそうです。
構造的な理由に関する私たちの仮説は、
「滞在する生活圏の違い」に起因する「既存プロセスの引力(慣性)」にある、というものです。
【暗号資産取引ユーザー】
主にはキャピタルゲイン狙いでトレードを行う個人ユーザー(又は当該ユーザーが利用するプログラム=いわゆる”bot”)
「滞在する主たる生活圏」はオンチェーン世界
オンチェーン世界における「既存プロセス」とは、自己管理ウォレット(アンホステッドウォレット)を介した暗号資産関連の操作
【法人間決済ユーザー】
その名のとおり、一般法人(通常は暗号資産トレードを行っていない法人の方が多い)
「滞在する主たる生活圏」はオフチェーン世界
オフチェーン世界における「既存プロセス(決済文脈)」とは、現状は多くの場合において、取引先銀行が提供するUI(EBシステム等)を用いた送金/決済関連の操作
つまり、
SC利用にあたって「自己管理ウォレット前提」とすると、そのプロセスに慣れ親しんだ一部のユーザーを除き、少なくとも「ウォレットを用いた新規プロセスと既存プロセスが一定期間併存」することは不可避となります。
特に一般法人の利用を想定した場合、
「業務プロセスが複線化する面倒さ」が発生してしまうのをバックオフィスの方々が強く反対するであろうことは、大きな組織の中で働いた経験をお持ちの方であれば容易に想像がつくのではないかと思います。
※なお、「自己管理ウォレット」ではなく「業者管理ウォレット(カストディアルウォレット)」の場合は、価値移転の当事者として中間業者(カストディアン)を必要とする「間接的移転モデル」となり、銀行が介在する方法(銀行送金)とほぼ同じ(又はそれ以上の)手間/手続が発生することになります。
(暗号資産をCEXからなかなか出庫できなかったり、他のCEXへ自由に移転できないのは、そういうことです)
では、どうしたらいいのでしょうか?
この課題の解決を目指すのが、私たちが本日公表した「Project Pax」です。
「Project Pax」は何を解決するのか?
ここまでで既に12,000字超となっています(!!!)が、本記事の本題はここからなので、あと少しだけお付き合いください。
「Project Pax」とは?
まず、なぜ「Pax」なのでしょうか?
本プロジェクトの背景にある思想/ビジョンを引用させてください。
エッセンスを抽出すると、ポイントは以下のとおりです。
①:目的は、世界の経済格差/経済課題の解消(=特に新興国取引)
②:既存システムとの対立ではなく融合(=ハイブリット)
③:スコープは最初からグローバル(=ガラパゴスな仕組みにしない)
①の新興国取引に関する課題(貿易取引における新興国/取引相手の”不”)とSCによる解決の全容については、過去に記事をまとめているので適宜ご覧ください。
ただし、上記記事執筆時点と現在との大きな違いは、②③を実効的に実施するための方法論の部分です。
つまり、「貿易取引用の法人向けウォレット」(自己管理ウォレット)を新たに提供することで企業自らSCを管理/送金する、といったオプションだけでなく、「銀行が提供する既存UI」×「SwiftのAPIプラットフォーム」×「SC」が連携する「クロスボーダーSC送金基盤」を利用できるようにする、という新たなオプションを提示した、ということです。
前提として、SCによる送金オプションが登場したとしても、「現状の国際送金プロセス」として解説したルート(上の図表における下のルート)が即座に無くなるわけではない、との現実的なビューがあります。
そうである以上、前の章で解説したとおり”既存プロセス併存”は多くの企業にとって所与の条件として、送金元/送金先企業と各取引銀行とのインタフェース/プロセスや、各銀行内の国際送金システムを活かしながら、物理制約なく直接移転が可能な”デジタル上の現金”としてのSCの強みを融合させることが重要です。
「自己管理ウォレット利用によるSC管理/P2P送金」が可能な企業だけでなく、”もう1つの選択肢”を新たに提供することで、SCの利活用範囲を従来よりも拡張することが可能となります。
「Swift」との連携により、世界200以上の国および地域、11,000以上の金融機関等を結ぶネットワークを活用することはもちろん、前述のとおりメッセージフォーマットがISO20022規格へ移行する等のモダナイゼーションの動きにより、”既存プロセス自体の利便性向上”のメリットを享受することも可能といえます。
「SC×銀行間連携のハイブリットモデル」とは?
「国際送金プロセスの俯瞰図」に則り、今回発表した内容が具体的にどのようなプロセスのイメージになるかについて、公表時点での想定ベースで簡単に確認します。(実証実験等のプロセスを経て、商用版リリースまで可変である点はご留意いただければと思います)
①:【X】が【Bank A】に、【Bank D】の【Y】名義の口座への送金依頼[20]を行う
②:【Bank A】には【Bank D】に対する支払債務が、【Bank D】には【Bank A】からの受取債権と同時に【Y】への支払債務が、それぞれ[20]ずつ発生する
③:【Bank A】が【Bank D】にSC[20]を送り、【Bank A】と【Bank D】間の清算/決済が完了する
④⑤:【Bank D】から【Y】への入金通知までは内国為替と同様
非常にシンプルです。
最大の違いは③の部分であり、従来のプロセスではコルレス銀行との債権/債務清算や中央銀行当座預金振替等、「銀行間の勘定データのバケツリレー」が発生していたところ、”直送可能なデジタル上の現金”としてのSCの強みを生かし、【A】から【D】へのSC直接移転により大幅にプロセスを短縮しています。
そして、①②④⑤については、従来のプロセスと同じです。(あえて言えば、①の時に送金手段として「法定通貨 or SC」を選択することになりそう、といった程度)
言い換えると、【X】や【Y】は「自己管理用ウォレット」でのSC管理や移転操作といった”新規業務”を導入する必要がありません。
これらを、各当事者における期待効果として改めてまとめると、以下のとおりです。
【for 送金元/送金先企業】
SCやブロックチェーンの存在を強く意識することなく、従来どおりの国際送金と連続的な体験で、より高速で安価な国際送金が可能
【for 金融機関】
既存の仕組みを活用することで、新たなシステムをゼロから構築する必要がないため、投資を抑えながら顧客企業への新たな送金オプションの提供が可能
【for Swift】
既存の法定通貨送金に加え、SC送金においてもコミュニケーションハブとなることで、様々なデータを集約・管理するオーケストレーターとしての役割を強化し、会員行に対するよりよいサービス提供が可能
「オンチェーン部分」のポイントは?
プレスリリースからそのまま引用すると、以下のとおりです。
まさに、5月31日に「伏線です」と宣言して公開した内容が、そのまま「クロスボーダー SC送金基盤」の基礎になっています。
現在のステータスとして、「Progmat Coin」基盤(as a Service)と並行して、「クロスボーダーSC送金基盤」(別システム)もプロトタイプ版を実装し、国内外の金融機関が関与する形で実証実験をスタートする段階まできています。
今回合わせて公表した3メガバンク以外の関係金融機関名一式(第2陣、第N陣、…)や、プロダクトに関する技術的な詳細を含む実証実験結果等、まだ詳らかにできない内容も多いのですが、諸々整い次第、グローバルベースで段階的に情報公開していきます。
さいごに
いま、何文字目だと思いますか…?笑
…正解は、約16,300字です!
寄稿論文として出せるレベルの分量を書いている理由は、それだけ私がこのプロジェクトの持つポテンシャルの大きさに興奮しているからです。
そしてここまで読んでいただいた”あなた”も、相応に高いアンテナとパッション(そして願わくば期待感/高揚感)を持っているのでは…と推察します。
さすがに、現在の「Progmat」に繋がる取り組みを社内新規事業として始めた2018年当時、まさか自分がここまでのプロジェクトの旗手になるとは夢にも思っていませんでした。
このような世界的にも最先端かつ非常にインパクトの大きな取り組みを、ただの研究開発ではなく具体的なユースケースと合わせて社会実装できる環境が、Progmatにはあります。
一緒に世界に挑む仲間、待ってます!(定期)
特にこれらを一緒に爆速で社会実装し、認知を高めてモメンタムを上げていく「HR/PRメンバー」&「Techメンバー」、絶賛採用継続中です!
(毎月新メンバーJoinな状態)
カジュアル面談のご相談は、Web(☟)からお気軽にできます。皆さまにとって「今かも」というタイミングがきましたら、いつでもどうぞ!
(いや、今でしょ!!)
この記事が気に入ったらサポートをしてみませんか?