20220929_【DCC】資金決済WG_中間報告書_本紙

CONFIDENTIAL Discussion Purpose Only デジタルアセット共創コンソーシアム(DCC) 資金決済WG | 中間報告書 2022年9月デジタルアセット共創コンソーシアム

CONFIDENTIAL / Discussion Purpose Only © 2022 Mitsubishi UFJ Financial
Group, Inc. 目次 #1 エグゼクティブサマリ #01 デジタルアセット共創コンソーシアムと本WGの概要 #02 Progmat内RTGS分科会中間報告 #03 クロスチェーンRTGS分科会中間報告 #04 今後の計画

Group, Inc. エグゼクティブサマリ #2 ネクストアクション中間成果 Progmat 内 RTGS ・ステーブルコイン(SC)は「ホールセール(WS)型」と「リテール型」に大別されるが、まずはSTセカンダリ取引の決済効率化が必須目標であり、当該ユースケースでは金商業者間決済のSC利用のみで要件充足するため、「WS型」を実装する。クロスチェーン RTGS ・複数金商業者を委託者兼受益者とする受益証券発行信託を銘柄別に組成(目的別に複数のSC銘柄発行が可能)し、・WS型SCの業務プロセス/システム構成として、「①PTSや金商業者がNode保有未済」と「②直接保有済」の2つの業務態様の断面が想定され、まずは①の断面における「Progmat Coin1.0」の要件整理を実施した。・PTSの個人情報取扱回避のために想定している、金商業者Node間の情報共有の実現方法については、金商業者間においても個人情報の第三者提供に該当し得るため、本WGの残期間において継続検討を行う。業務プロセス /システム構成・②の断面における、より高度化された全自動化プロセスも整理を実施し、SC決済のフェイル発生防止策(事前チェックプログラム実装)やPTSにおける個人情報取扱回避策(権利者ID情報のPTS宛連携不要)を織込済み。スキーム /契約構成 /法的論点・必要な技術検証内容の策定に向けて、机上検証によりクロスチェーン実装方式の主案を定めた。技術検証・チェーン(BC)間の接続/認証方式として、「API方式」「相互認証方式(TTP方式,HTLC方式,Relay方式)」で比較し、トラストポイント発生による拡張性制約や、一定のケースにおける取りはぐれを回避すべく「Relay方式」を主案とした。・①疑似環境でのQuorum-Corda間クロスチェーン検証、②各ST基盤-Progmat Coin間の機能検証、③実際の ST取引を想定した実証検証、の3Stepで検証を進めることとし、①は2022年10月~2023年2月で実施する。資金決済法上の電子決済手段(SC)として特定信託受益権を発行する。・「Progmat Coin1.0」実装、及び「②PTSや金商業者がNode直接保有済の断面」の全自動化プロセス確定を行う。・実機検証Step1の検証開始と技術課題の抽出、及び検証結果を踏まえた実機検証Step2の計画策定を行う。・「Relay方式」のアーキテクチャとして、「IBC」プロトコル活用が望ましい前提で、実装方式である「直接検証型」「プロキシ型(BC上)」「プロキシ型(TEE上)」で比較し、拡張性とセキュリティ・性能面から「プロキシ型(TEE上)」を主案とした。・Cordaにおける実装方法として、トランザクション(Tx)の正当性を担保するためのValidatorsを導入すると共に、 Corda側のロック/アンロックを行いアトミックな処理を実現すべく、Encumbrance機構(消費条件任意追加)を活用する。

Group, Inc. #01 #3 デジタルアセット共創コンソーシアムとWGの概要

Group, Inc. #4 #01 デジタルアセット共創コンソーシアムとWG概要 #01-1 デジタルアセット共創コンソ―シアム(DCC)概要  デジタルアセット全般を対象とした新たなエコシステム共創を目的に、「デジタルアセット共創コンソーシアム」(DCC)という枠組みを設けている。  2022年9月時点で会員企業数は134社が参画（参加費用は無償、入会申込書のファイル送付のみで入会手続き完了）。  事務局からの最新動向に関する情報発信のほか、目的別のワーキング・グループ(WG)を組成し検討を実施中。  DCC内でST市場の将来像を具体化した「セカンダリ・DLT拡張WG」の後続として、資金決済の在り方を具体化する取り組みが「資金決済WG」。最新ナレッジ共有プロダクト共創デジタルアセット共創コンソーシアム共同検討・提言 (DCC) 【目的】デジタルアセット全般を対象とした、業界横断での新たなエコシステムの共創【参加会員】各種を保有する資金調達者や運用者、顧客接点を担う仲介者、原簿管理者やカストディアン、開発を担う技術者、各種士業等の専門家が、【運営概要】 ①事務局より最新ナレッジを月次でWeb配信 ②業界横断的/新規性の高いテーマを対象に、ワーキング・グループ(WG)を組成し、任意参加 ③包括的な秘密保持契約として機能し、会員同士で柔軟に個別プロジェクトを実施 ④プロダクトに係る分権的運営(予定) 企業グループ横断的に参加する中立組織

Group, Inc. #5 #01 デジタルアセット共創コンソーシアムとWG概要 #01-2① 前提｜ステーブルコイン導入意義 ST × 法定通貨 ST × SC PTS 金商業者①【売】金商業者②【買】銀行【金商①】銀行【金商②】 ST基盤約定結果受領結果受領金額確認送金指図他行振込残高増加着金確認 ST移転Tx 金商②署名検証 ST移転決済リスク (T+2) 他行送金手数料決済関連事務コスト PTS 金商業者①【売】金商業者②【買】 ST基盤 +Progmat Coin 約定金商②署名検証 ST/SC同時移転決済リスク極小化 (T+0) 決済関連事務全自動化【凡例】 :事務処理(人員介在要) :自動処理(DLT外) :自動処理(DLT) 出来通知金商①署名送金コスト極小化  ST取引において、資金決済手段が法定通貨(銀行送金)しか存在しない場合、取引から決済完了まで(T+2営業日)の決済リスクがあるうえ、金商業者間での相対ネッティングのための金額確認や銀行関連オペ等の事務コストが掛かり、更に他行送金手数料も発生する。  「Progmat Coin」で発行したステーブルコイン(SC)を利用し、PTSから出来通知をDLT上で連携することで、ポストトレードプロセスが一線完結化。  決済リスクは極小化(T+0)され、全ての処理を全自動化可能で、且つ送金手数料も低減される。

Group, Inc. #6 #01 デジタルアセット共創コンソーシアムとWG概要 #01-2② 前提｜「Progmat内RTGS」俯瞰図（2022年3月時点） Coin ST デジタル証券PTS EN マッチングシステム(競売買) 取引システムバックシステム CN API 提供基盤 AN SN CN 取引システムバックシステム ST原簿管理者 SC原簿管理者 tCN NN 出来Tx生成出来Tx 移転Tx 出来Tx 生成移転Tx 署名出来情報売注文情報(専用線) 買注文情報(専用線) 売注文買注文 (SC 残高有 ) 指図 ( 出来次第 ) 移転Tx承認 (SC分) 移転Tx承認 (ST分) 金商業者 (カストディ委託) 金商業者 (直接管理) カストディアン【凡例】 AN :Asset Node(ST) SN :SC Node(SC) EN :Exchange Node(ST&SC) CN :Custodian Node(ST&SC) :対面/画面入力 :API/専用線連携 :DLT連携(Progmat ST/SC) NN :Nortry Node  証券決済は「Progmat ST」で、資金決済は「Progmat Coin」で発行したSCで対応する場合、デジタル証券PTSによるマッチング完了後、各市場参加者はProgmat用Nodeを介した1本のフローでポストトレードプロセスが完結する。  デジタル証券PTS(EN)からの出来Txをインプットに、CN(売)がST及びSCの移転Txを生成し、ST/SCの取引関係者全員の署名の下、NNによる二重消費検証を経て移転が確定する。

Group, Inc. #7 #01 デジタルアセット共創コンソーシアムとWG概要デジタル証券PTS マッチングシステム(競売買) 取引システムバックシステム API 提供基盤取引システムバックシステム SC原簿管理者売注文情報(専用線) 買注文情報(専用線) 売注文買注文 (SC 残高有 ) 指図 ( 出来次第 ) 移転Tx承認 (ST分) 金商業者 (カストディ委託) 金商業者 (直接管理) カストディアン【凡例】 AN :Asset Node(ST) SN :SC Node(SC) EN :Exchange Node(ST&SC) CN :Custodian Node(ST&SC) :対面/画面入力 :API/専用線連携 :DLT連携(Progmat SC) NN :Nortry Node ST原簿管理者 SN 移転Tx承認 (SC分) 出来Tx生成出来情報 ST基盤(3rd Party) 出来Tx 移転Tx 出来Tx 署名移転Tx 生成 (ST分) (ST分) :DLT連携(3rd Party ST基盤) R :Relayer Server :3rd ST基盤用 Node Coin CN CN tCN NN 移転Tx 生成移転Tx 署名 R (SC分) (SC分) 連携連携  証券決済は「ST基盤(3rd Party)」で、資金決済は「Progmat Coin」で対応する場合、デジタル証券PTSによるマッチング完了後、各市場参加者は Progmat用Nodeを介したSC移転のフローに加え、当該ST基盤用NodeとST移転用フローが別途必要になる。  Progmat Coin側で、信頼できる第三者機関に依存しないクロスチェーンソリューション(＝Relayer)を提供することで、「Progmat ST」以外のST基盤もアトミックなDVP決済が可能となり、各市場参加者はデジタル証券市場における資金決済手段を統一/効率化できる。 #01-2③ 前提｜「クロスチェーンRTGS」俯瞰図（2022年3月時点）

Group, Inc. #8 #01-3① 資金決済WG｜分科会構成・目的  国内法準拠のステーブルコイン発行基盤である「Progmat Coin」を用いた資金決済の在り方を具体化するべく、「資金決済WG」を組成した。  「Progmat Coin」を決済手段とするST基盤はProgmatに限定しないため、「Progmat内RTGS」に加え「クロスチェーンRTGS」も含めて検討を行う。  「Progmat内RTGS」分科会は、共通ToDoをスコープとして、「Progmat Coin1.0」開発へ要件等をインプットすることを目的としている。  「クロスチェーンRTGS」分科会は、他ST基盤連携を目的とした「クロスチェーン決済機能」開発までに、各種合意形成の完了を目的としている。 #01 デジタルアセット共創コンソーシアムとWG概要 1 2 3 4 5 Coin 対象レイヤー ST基盤デジタル証券PTS SC原簿管理者金商業者「Progmat内RTGS」分科会「クロスチェーンRTGS」分科会【共通ToDo】 ①改正資金決済法規制を踏まえた(金銭預託原則禁止) SC発行/SC償還/ST分配金フローの具体化【共通ToDo】 ①デジタル証券PTSにおける取扱情報と管理方法具体化 (投資家ID,資金決済関連情報) 「共通ToDo」は「Progmat内RTGS」分科会で整理「共通ToDo」は「Progmat内RTGS」分科会で整理【固有ToDo】 ①各種ST基盤と「Progmat Coin」間のクロスチェーン技術の技術検証（可否,パフォーマンス,課題有無）「セカンダリ・DLT拡張WG」にて検討済 (1～3行目のレイヤーの議論を受けて適宜更新) ②各種改正法を踏まえた発行者/金商業者(仲介業者) における法令遵守方法具体化(法定調書等) ②デジタル証券PTSの責任分界点とコストシェア方法具体化 (”ゴールデンソース”としての責任,PTS接続料金転嫁是非) ②クロスチェーン技術検証により認識した課題に対する対応方法具体化（可否.トレードオフ,是非） ③クロスチェーン技術の商用化にあたり必要なコストの明確化とシェア方法の具体化 ④クロスチェーン技術商用化方式とスケジュールの合意形成「Progmat Coin1.0」開発へインプット「クロスチェーン決済機能」開発へインプット

Group, Inc. #9 #01-3② 資金決済WG｜中間成果 #01 デジタルアセット共創コンソーシアムとWG概要  「Progmat Coin1.0」(初回スコープ)における各種具体化は完了し、実装プロセスに移行する。  更なる将来形における在り方、及びクロスチェーンRTGSの技術検証を踏まえた各種合意形成は、後半継続して検討を進める。 1 ToDo 分科会改正資金決済法規制を踏まえた(金銭預託原則禁止) SC発行/SC償還/ST分配金フローの具体化デジタル証券PTSにおける取扱情報と管理方法具体化 (投資家ID,資金決済関連情報) Progmat 内 RTGS 分科会各種ST基盤と「Progmat Coin」間のクロスチェーン技術の技術検証（可否,パフォーマンス,課題有無）各種改正法を踏まえた発行者/金商業者(仲介業者) における法令遵守方法具体化(法定調書等) デジタル証券PTSの責任分界点とコストシェア方法具体化 (”ゴールデンソース”としての責任,PTS接続料金転嫁是非) クロスチェーン技術検証により認識した課題に対する対応方法具体化（可否.トレードオフ,是非）クロスチェーン技術の商用化にあたり必要なコストの明確化とシェア方法の具体化クロスチェーン技術商用化方式とスケジュールの合意形成クロスチェーン RTGS 分科会中間時点での主な取組・初回リリースのスコープをホールセール型(後述)に決定・ホールセール型の契約構成,業務フローを策定・初回スコープのデータフロー、情報管理方式案を整理・初回スコープのシステム具体化、将来形に係る整理は継続検討・机上検証を経て、実現方式は「プロキシ型(TEE上)IBC」を主案とし、10月から3STEPで検証予定・初回スコープの電子決済手段等取引業の考え方を確認も、最終的な法定帳票の範囲は内閣府令案等を以て確定・デジタル証券PTSのNode直接参画/STP化の実現は「Progmat Coin1.0」リリース後となるため、優先順位劣後・技術検証結果を踏まえた検討となるため、中間時点では未着手・同上・同上ステータスー完了継続検討継続検討継続検討継続検討継続検討継続検討継続検討 *1 「Progmat Coin1.0」(初回スコープ)の要件整理は予定どおり完了。更なる将来形については下期継続して検討。 *1 2 3 4 5 6 7 8

Group, Inc. #10 #01 デジタルアセット共創コンソーシアムとWG概要 #01-3③ 資金決済WG｜参加者・運営概要 DCC事務局デジタル証券PTS 1 証券会社 (ST専業証券設立予定者含) ３ DLT基盤/証券システムを担うソフトウェア会社４法律事務所５オブザーバー６「Progmat内RTGS」分科会各検討会アジェンダ設計各検討会資料最終化各検討会ファシリテーション議事録作成、配信関係者間折衝、取り纏め 1 ２３「クロスチェーンRTGS」分科会月次参加論点検討 / 技術協力月次参加論点検討 2 社 17 社 4 社 1 社 3 団体デジタル証券PTS ST基盤提供者 DLT基盤/証券システムを担うソフトウェア会社 2 社 2 社 3 社 1年｜2022年4月~2023年03月開催期間月次開催(全12回)｜各回原則1時間（最大2時間）開催頻度定期的に、参加者全員が参加する「検討会」を実施開催方法「デジタルアセット共創コンソーシアム規程」に基づく”参加者内に閉じた”取扱いとする（情報公開は参加者全員の合意の下で実施）秘密保持事務局の主催するオンライン会議形式開催形式 ※第11条(秘密情報の定義)、第12条(秘密保持)、第13条(目的外使用の禁止)、第20条(権利の帰属)、第21条(協議事項) 原簿管理者２ 4 社

Group, Inc. #02 #11 Progmat内RTGS分科会中間報告

Group, Inc. #12  「Progmat Coin」を用いて発行されるステーブルコイン(電子決済手段,SC)は、金商業者が自己口で保有し業者間移転取引に用いる「ホールセール (WS)型SC」と、個人・企業等のエンドユーザーがそれぞれ直接保有する「リテール型SC」の、2つの類型に大別される。  「Progmat Coin1.0」(初回スコープ)段階では、デジタル証券PTSを介した金商業者間のST移転取引における資金決済の効率化が目的のため、必ずしもエンドユーザーが直接SC残高を保有する必然性がない(むしろ法定通貨との交換の手間が生じる)ことから、「WS型」を対象とする。 #02-1 「Progmat Coin1.0」の開発スコープ #02 Progmat内RTGS分科会中間報告利用用途ホールセール(WS)型リテール型 1 ・金商業者が自己口で保有し業者間移転取引に用いる・現行の日銀当預を利用したインターバンク決済に相当・エンドユーザーが直接保有する・証券取引以外にも、NFT・DeFi・一般決済取引も想定受益者(SC保有者) 3 ・委託者と同一の金商業者自己口（のみ）・同左+他委託者+エンドユーザー(個人・企業) 委託者５・SC銘柄別の複数金商業者・同左+SCを必要とする事業者等 SC発行スキーム 2 ・受益証券発行信託(電子決済手段＝特定信託受益権) ・同左受託者４・SC銘柄別の信託銀行（MUTBに限定されない）・同左 DLT基盤 7 ・パーミッション型のみで要件充足可能・パーミッション型+パーミッションレス型まで必要になる Progmat Coin1.0(初回スコープ)は、STセカンダリ取引の決済効率化目的であり、「WS型」で充足するスキーム関係者６・取引方式の構成次第・顧客口を取り扱う各種業者仲介者

Group, Inc. #13  「Progmat Coin(WS型)」の拡張ロードマップは下図のとおり、システム断面及びその業務態様が、①PTS・金商間連携オフチェーン(既存回線)/ホールセール型SC有/カストディ委託型、②PTS・金商間連携オンチェーン/ホールセール型SC有/直接管理型の2断面に大きく分かれる。  ①の断面では、MUTB以外の各参加者はNodeを直接持たず、ST/SCの移転をAPI又はCSV送付にて行うカストディ委託型となる。  ②の断面では、災対サイト強化のうえで、PTSを含む各参加者がNodeを直接保有し、自身で直接ST/SCの移転が可能な直接管理型へ移行する。 #02-2 「Progmat Coin(WS型)」の拡張ロードマップ #02 Progmat内RTGS分科会中間報告 1 4 災対サイト強化 7 2 DLTオープン化｜AN 3 DLTオープン化｜CN+EN 6 5 2023.03 2023.06 2023.09 2023.12 2024.03 2024.06 2024.09 基盤拡張業務態様 ProgmatCoin 1.0 ｜ホールセール型SC ST移転資金決済 ST発行 ▪MUTBのみ ▪各種原簿管理者による発行 ▪MUTBのみ ▪各種原簿管理者による発行 ▪法定通貨のみ ▪法定通貨orホールセール型SC ▪カストディ委託(API or CSV) ▪法定通貨orホールセール型SC ▪カストディ委託(API or CSV) ▪法定通貨orホールセール型SC ▪直接管理(CN) ▪PTS無し ▪金商内移転 ▪カストディ委託 (API or CSV) ▪PTS有り ▪出来通知:既存回線(PTS→金商) ▪カストディ委託(API or CSV) ▪PTS有り ▪出来通知:既存回線(PTS→金商) ▪カストディ委託(API or CSV) ▪PTS有り ▪出来通知:自動(EN→CN) ▪直接管理(CN) EN無,ST/SCカストディ委託 1 EN有,ST/SC直接管理 2

Group, Inc. #14  フローを検討する際の論点の1つである「PTSで個人情報(権利者ID)を取り扱う必要性の有無」について、断面別に整理を実施。  断面①では、そもそもEN⇒CN間の自動連携がないため、PTSで権利者ID(移転先/移転元ID)を取り扱う可能性は無く、パターンは単一。(A)  断面②では、PTSでの個人情報取扱有無によりTx処理フローが変わり得るが、現状のエクスチェンジでは個人情報取扱はなく、ST/SC取引に際して新規で取り扱うことは課題感が強いことから、パターン(C)ではなくパターン(D)を採用する。 #02-3 「Progmat Coin(WS型)」の断面別パターン #02 Progmat内RTGS分科会中間報告 A B D C EN無, PTSでの個人情報取扱断面有無 1 2 ST/SCカストディ 2023.06～ 2024.06～業務の様態業務の態様委託 EN有, ST/SC直接管理金商業者様からの移転指図のため、 ✓ Node無いため、全自動化不可 × PTS様における個人情報取扱問題は発生しない ▪ホールセール型SC ▪出来通知:自動(EN→CN) ▪PTS有(EN) ▪直接管理(CN) EN⇒CNでST/SCの移転全自動化 ✓ PTSでの個人情報管理保有の課題あり × 業務の様態 ▪ホールセール型SC ▪出来通知:自動(EN→CN) ▪PTS有(EN) ▪直接管理(CN) EN⇒CNでST/SCの移転全自動化 ✓ CN間で移転に必要な移転先/移転元IDを ✓ 連携することで、PTS様の個人情報取扱回避 ▪ホールセール型SC ▪出来通知:既存回線(PTS→金商業者) ▪PTS有(EN無し) ▪カストディ委託(API or CSV)

CONFIDENTIAL / Discussion Purpose Only B EN無, PTSでの個人情報取扱断面
有無 1 2 ST/SCカストディ 2023.06～ 2024.06～業務の様態業務の態様委託 EN有, ST/SC直接管理金商業者様からの移転指図のため、 ✓ Node無いため、全自動化不可 × PTS様における個人情報取扱問題は発生しない ▪ホールセール型SC ▪出来通知:自動(EN→CN) ▪PTS有(EN) ▪直接管理(CN) EN⇒CNでST/SCの移転全自動化 ✓ PTSでの個人情報管理保有の課題あり × 業務の様態 ▪ホールセール型SC ▪出来通知:自動(EN→CN) ▪PTS有(EN) ▪直接管理(CN) EN⇒CNでST/SCの移転全自動化 ✓ CN間で移転に必要な移転先/移転元IDを ✓ 連携することで、PTS様の個人情報取扱回避 ▪ホールセール型SC ▪出来通知:既存回線(PTS→金商業者) ▪PTS有(EN無し) ▪カストディ委託(API or CSV) 中間報告書にて詳細明示実現に向けて後半継続検討 A 各社がNode保有する将来形では、権利者ID等の共有方式等の残論点があるため、後半継続検討 (現時点案は中間報告書に参考掲載) D PTSで個人情報取扱不可のため、詳細化対象外 C © 2022 Mitsubishi UFJ Financial Group, Inc. #15  前頁のとおり、パターン(C)は採用可能性がないため詳細検討の対象外とする。  パターン(A)は、Progomat Coin1.0(初回スコープ)の前提となるため、優先的に詳細検討を行った。  パターン(D)は、各社がNode保有し、PTSを除く金商業者間で投資家ID等の情報を共有する将来形だが、残論点もあるため、後半に継続検討する。  パターン(A)における業務フロー/データフロー案、パターン(D)における各種現時点(案)は、参考までにAppendixに掲載する。 #02-4 「Progmat Coin(WS型)」の詳細検討対象 #02 Progmat内RTGS分科会中間報告

Group, Inc. #16 #02-5 契約構成｜パターン(A) #02 Progmat内RTGS分科会中間報告  複数金商業者を委託者兼受益者とする受益証券発行信託を銘柄別に締結し、資金決済法上の電子決済手段として特定信託受益権を発行する。  WS型SCでは投資家は直接SCを保有しないため、金商業者とは既存契約に基づく金銭預託とST/SC交換取引の取次の委託に留まる。  パターン(A)の断面①時点ではカストディ委託必須のため、STと同様、カストディアンを含めた各当事者間で事務取扱要領により詳細を定める。  金商業者がAPIを利用する場合は受託者/カストディアンとAPI利用契約を締結し、受託者/カストディアンはPF提供者とPF利用契約を締結する。秘密鍵管理等委託先カストディアン(B) 金商業者(B) 総合取引約款等に基づくST購入用金銭の預託,ST/SC交換取引の取次の委託 01 受託者委託者兼受益者金商業者(A) 02 03 02 03 03 07 金銭(A) 金銭(B) SC(A) 受益証券発行信託 SC(B) 委託者兼受益者秘密鍵管理等委託先カストディアン(A) 03 05 投資家投資家(a1) 投資家投資家(a2) 投資家投資家(b1) 投資家投資家(b2) (SC銘柄別) 金銭(A) SC(A) 預り金 (a1,a2) 金銭(B) SC(B) 預り金 (b1,b2) 01 01 04 04 電子決済手段等発行者 06 08 プラットフォーム(PF)提供者 Core Developer 09 受益証券発行信託契約(SC銘柄別,複数委託者) 02 受益権原簿管理等事務取扱要領 03 API利用契約(金商業者-受託者間,任意) 04 業務委託契約(金商業者-カストディ(A)間) 05 API利用契約(金商業者-カストディ(A)間,任意) 06 業務委託契約(金商業者-カストディ(B)間) 07 API利用契約(金商業者-カストディ(B)間,任意) 08 PF利用契約(※MUTB内で完結する時点では不要) 09

Group, Inc. #17 #02 Progmat内RTGS分科会中間報告 #02-6① 業務システム俯瞰｜SC移転(ST決済)｜(A)  各投資家は、口座を有する各金商業者に対して、取引決済用の資金を預託したうえで(現状どおり)、ST/SC交換取引の取次を依頼する。  PTSの媒介により金商業者間でST/SC交換取引が法的に成立し、その経済効果が取次の委託元の各投資家に帰属する。  「Progmat Coin 1.0」時点では、PTSはEN導入未済のため、金商業者はDLT外で出来通知を受領後、APIにてカストディアンに移転を指図。  各金商業者はST決済用SC枠を用意しておき、顧客口の買付資金を自己口に移しつつ、自己のSC枠内で他金商業者とDLT上で自動決済を行う。 ST取扱者/SC委託者兼受益者(B) バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) 証券口座 (顧客口) 投資家(b) ST取扱者/SC委託者兼受益者(A) バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) 証券口座 (顧客口) デジタル証券PTS ①ST売注文 ②ST売注文 ⑥ST買注文 ⑦出来通知 ⑦出来通知投資家(a) ⑧ST/SC移転指図(API) ⑧ST/SC移転指図(API) SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) Progmat ST/Coin (ST/SC移転管理) ST/SCカストディアン Progmat ST/Coin (ST/SC移転管理) ST/SCカストディアン ⑨ST移転/SC移転(DLT) ④ST買注文 ③ST購入資金預託 ⑤振替【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat ST/Coin(ST/SC移転管理システム) (取次委託) (取次委託)

Group, Inc. #18 #02-6② 業務システム俯瞰｜SC発行(枠確保)｜(A) #02 Progmat内RTGS分科会中間報告 SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) ST原簿管理者ファンド管理システム (信託会計等) 勘定系システム Progmat Coin (SC移転管理) ST取扱者/SC委託者兼受益者バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) Progmat Coin (SC移転管理) 証券口座 (顧客口) ST/SCカストディアン投資家 ST投資対象【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat Coin(SC移転管理システム) ①SC発行指図 ②入金 ③SC発行(DLT) 〔→SC委託者兼受益者〕 ④SC残高照会(API) 入金&振替記帳・処理銀行預金口座  WS型SCにおけるSC発行は、STセカンダリ取引における流動性(枠)確保のための事前発行、及び枠超過時の追加発行の2パターンを想定。  金商業者は現行の日銀当座預金と同様に事前に一定金額のSCを発行の上で、前述のとおり即時決済(T+0)を実現する形を想定。  枠の考え方については、ST取扱残高やセカンダリ取引実績に応じて、各金商業者(SC委託者兼受益者)が動的にコントロールすることを想定する。

Group, Inc. #19 #02-6③ 業務システム俯瞰｜SC発行(追加)｜(A) #02 Progmat内RTGS分科会中間報告 SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) ST原簿管理者ファンド管理システム (信託会計等) 勘定系システム Progmat Coin (SC移転管理) ST取扱者/SC委託者兼受益者バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) Progmat Coin (SC移転管理) 証券口座 (顧客口) ST/SCカストディアン投資家 ST投資対象【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat Coin(SC移転管理システム) ②SC発行指図 ④入金 ⑤SC発行(DLT) 〔→SC委託者兼受益者〕入金&振替記帳・処理 ①ST購入資金預託 ③振替銀行預金口座  STセカンダリ取引が想定よりも増加した場合、ST決済用SC枠が不足するため、SCの追加発行が必要となる。  ST買注文前/移転前の必要SC残高確認により不足を検知した場合に発生するが、その前提としてST買発注者(投資家)は必要な決済用資金を予め顧客口に預託しているため、追加発行に要する法定通貨を顧客口から自己口に移したうえで、自己口の当該資金を用いてSCの追加発行を行う。

Group, Inc. #20 #02-6④ 業務システム俯瞰｜SC一部償還｜(A) #02 Progmat内RTGS分科会中間報告  STセカンダリ取引におけるST売却側の金商業者様及び投資家は、売側金商業者宛てのWS型SCで対価を受領するため、その後投資家の顧客口へ法定通貨として資金移動する必要がある。  よって、SCを一部償還して証券会社自己口へ必要な法定通貨を準備した上、自己口から顧客口へ当該資金を振り替えることを想定。 SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) ST原簿管理者ファンド管理システム (信託会計等) 勘定系システム Progmat Coin (SC移転管理) ST取扱者/SC委託者兼受益者バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) Progmat Coin (SC移転管理) 証券口座 (顧客口) ST/SCカストディアン投資家 ST投資対象【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat Coin(SC移転管理システム) ①SC一部償還指図 ③出金 ②SC償還(DLT) 出金記帳・処理 ④振替銀行預金口座

Group, Inc. #21 #02-7 主要論点と中間時点の整理状況 #02 Progmat内RTGS分科会中間報告  「Progmat Coin1.0」(初回スコープ)時点で影響を受ける論点については、SC流動性確保の論点以外、中間時点で以下のとおり整理済み。  「Progmat Coin」拡張後の“EN・CNオープン化”断面(前述のパターンD)における業務プロセスは残論点があるため、継続検討を行う。カテゴリ論点検討結果法的論点 1 2 4 業務ホールセール型SCにおいて、金商業者が改正資金決済法の電子決済手段等取引業者に該当するか金商業者がPTSにST売買注文を発注 SCの流動性確保について円滑にST移転処理を実行するために、フェイル発生時に備えてSCの準備金改正法による業規制該当有無デジタル証券PTSでの個人情報取扱ステータス継続検討完了継続検討金商業者及びカストディアンの電子決済手段等取引業該当性について確認も、最終的な結論は内閣府令等の公表を以て確定させる。枠をどの程度確保すべきか SCの流動性確保を目的として確保しておく準備金の額は、現時点では存在しないセカンダリ取引量に依存するため、足許で明確なロジックは決定できないとの結論。する際、PTSを起点とするSTP化のために個人情報(投資家ID)を連携可能か PTSのNode保有後、ST売買注文マッチングからST移転完了までを自動完結化 (STP化)するため、金商業者からPTSへの注文発注時に、投資家IDを付加して連携する方式を想定。その後、投資家IDは個人情報に該当しPTS・金商業者共に連携が困難であるとの見解を得たため、「注文ID・約定IDをKeyに、PTSを介さず a b c d 3 Node間のデータ共有範囲 PTSに個人情報(投資家ID)を連携させずにSTP化を実現するための、継続検討金商業者(CN)間の情報共有を PTSでの個人情報取扱が不可であることから、ST移転に必要な投資家IDは Progmatを介して金商業者(CN)間で連携する方式とした。但し、金商業者間においても個人情報の第三者提供に該当し得るため、断面② (CN/ENオープン化後)以降の投資家IDの共有方針について継続検討する。金商業者(CN)間で連携する方式」に変更し、PTSは個人情報取扱い不要とした。流動性確保の目的は「SC残高不足によるフェイルを発生させない」ことにあるため、「そもそもフェイルが発生し得ないフロー案」を策定した。実装に向けた詳細化はプロセスどのように実現するか継続検討する。

Group, Inc. #03 #22 クロスチェーンRTGS分科会中間報告

CONFIDENTIAL / Discussion Purpose Only #03 クロスチェーンRTGS分科会中間報告 © 2022 Mitsubishi
UFJ Financial Group, Inc. #23 #03-1 論点と検討経緯  必要な技術検証内容の策定に向けて、まずは机上検証によりクロスチェーン実装方式の主案を定め、合意形成を行った。  机上検証に際しては、商用利用を前提としたセキュリティ面・性能面に加え、将来的な拡張性を最大限考慮して比較検討を行い、「プロキシ型(TEE 上)IBC」が望ましいとの見解を得た。(詳細は後述)  当該主案を前提に、「Progmat Coin」(on Corda)のユースケースにおける実装方法を具体化し、3ステップアプローチによる検証計画を定めた。論点と進め方検討結果 1 2 3 4 チェーン間の接続/認証方式【方式】API方式、相互認証方式(TTP方式、HTLC方式、Relay方式) クロスチェーンのアーキテクチャ Cordaにおける実装・Cordaを用いたユースケースの具体的なクロスチェーンのフローを検討する。検証計画・上記を踏まえ、クロスチェーン検証の実現可能な進め方・方針を整理する。・実機検証の初回スコープ・検証項目を策定し、スケジュールを明定する。・新たなトラストポイントが生じ、拡張性を制約し得る「API方式」や「TTP方式」は採用しない。・一定のユースケースにおいて「HTLC方式」は取りはぐれのリスク・前提として、本ユースケースでは「IBC」プロトコルと「Cross ・CordaにおいてもTxの正当性を担保するためのValidatorsを・①疑似環境でのQuorum-Corda間クロスチェーン検証、があるため、最も優位な「Relay方式」を主案とする。・異なるチェーン間でのトランザクションの処理状況を把握し相互の処理を連動させるための仕組みとして、どのような方式が望ましいか確定する。・①で確定した方式を実現する際のアーキテクチャとして、どのような方式が望ましいか確定する。・「Progmat Coin」のようにCorda上に構築した基盤において、上述の検討で主案としたアーキテクチャをどのように実装するかを確定する。 Framework」活用が望ましい。(「Polkadot」との対比) 導入し、Proofの条件とする。 ②各ST基盤-Progmat Coin間の機能検証、③実際のST セカンダリ取引を想定した実証検証、の3ステップで行う。・ステップ1の検証は、2022年10月～2023年2月で実施し、 6つの検証シナリオにより技術課題を抽出する。【方式】直接検証型、プロキシ型(BC上)、プロキシ型(TEE上) ・「IBC」のネットワーク構成として、将来の拡張性とセキュリティ・性能面を考慮し、「プロキシ型(TEE上)IBC」を主案とする。・Corda側のロック/アンロックを行いアトミックな処理を実現すべく、 Encumbrance機構(消費条件の任意追加)を活用する。

UFJ Financial Group, Inc. #24 #03-2① チェーン間の接続/認証方式(1/3) | 「API方式」vs「相互認証方式」  異なるブロックチェーンを跨いだDvPを実現するにあたって、大きく①APIによる処理状況を連携する方式、②ブロックチェーン間で直接処理状況を連携して整合性を担保する相互認証方式、の2パターンに分けられる。  API方式は、ブロックチェーン間の整合性担保に工夫を要し、かつAPI管理者に対する規制/要件が国により異なり得る点で、拡張性に制約が生じる。  相互認証方式は、ブロックチェーン間の直接接続により整合性担保が比較的容易で、様々なユースケースを想定した場合に拡張性の観点で比較優位。・

UFJ Financial Group, Inc. #25 #03-2② チェーン間の接続/認証方式(2/3) | 「相互認証方式」の3パターン  相互認証方式は、「TTP方式」(Trusted Third Party)、「HTLC方式」(Hashed Time Locked Contract)、「Relay方式」、の3パターンがある。  「TTP方式」は“信頼可能な第三者エンティティ”により整合性を担保するが、「HTLC方式」と「Relay方式」はそのようなエンティティの存在は必要としない。  “信頼可能な第三者エンティティ”は新たなトラストポイントを生むことになり、前述のAPI管理者に対する規制/要件が国により異なり得る問題と同様の課題を孕んでいるため、「HTLC方式」又は「Relay方式」が望ましい。・

UFJ Financial Group, Inc. #26 #03-2③ チェーン間の接続/認証方式(3/3) | 「HTLC方式」vs「Relay方式」  「HTLC方式」は、ST⇔SCの交換取引において、ST受け側(SC渡し側)が鍵を用いてSTをアンロックすると、ST渡し側(SC受け側)は当該鍵を用いて SCをアンロック可能になる仕組み。  例えばST側に譲渡数制限がある等の一定のユースケースにおいては、SC側のみ移転が成立し、ST側は移転が不成立となる「取りはぐれ」が生じ得る。  したがい、相互認証方式の中でも新たなトラストポイントを必要としない「HTLC方式」と「Relay方式」のうち、「Relay方式」を採用する。・

UFJ Financial Group, Inc. #27 #03-3① クロスチェーンのアーキテクチャ(1/7)｜「IBC」アーキテクチャ  Relay方式の選択肢として、「IBC」(Inter Blockchain Communication)と呼ばれるプロトコル(通信規格)を用いる方法か、「Polkadot」を利用する方法が考えられるが、「実績」「プライバシー」「その他制約(不透明)」の観点で、「IBC」を採用する。(比較概要はAppendix参照)  「IBC」は、「ICS」(Interchain Standards)として仕様を公開しており、異なるBC間でデータのやり取り(転送,認証,順序付け)が可能。  BC(A)の情報をクエリしてBC(B)にTxを送る通信仲介役の「Relayer」と、各BC上で受領データの正当性を検証する「ライトクライアント」に特徴がある。・

UFJ Financial Group, Inc. #28 #03-3② クロスチェーンのアーキテクチャ(2/7)｜「ライトクライアント」による検証  「IBC」のトラストレスな性質を可能にしているのが、改ざん検知が可能で信頼不要な「Relayer」と、リレーされてきた相手方BCデータの正当性を検証する「ライトクライアント」(簡易ノード,以下LC)であり、両方のBCが相手方BCのLCを立ち上げることで相互検証を行う。  LCは、主にブロックヘッダー(ブロックのハッシュ値)のみを用いて検証するため、全てのデータを保存するために大きなリソースが必要なフルノードよりも軽量。 ※Cordaはブロック(＝ブロックヘッダー)の概念がない等、台帳毎の特性を考慮したProofを用意する

UFJ Financial Group, Inc. #29 #03-3③ クロスチェーンのアーキテクチャ(3/7)｜「Cross Framework」活用  各BC上でスマートコントラクトとして組み込む「IBC-module」に加え、App-moduleとして組込可能な「実行制御機能」「ロック機構」を「Cross Framework」としてDatachainが提供しており、「Progmat Coin」によるDvP/PvPで活用を想定する。・

UFJ Financial Group, Inc. #30 #03-3④ クロスチェーンのアーキテクチャ(4/7)｜「直接検証型」vs「プロキシ型」  前述の「IBC」では、各BC上にそれぞれ相手方のBCのLCを持ち合うこと(直接検証型)となるが、「Progmat Coin」のように接続先BCが増加していく将来像を踏まえると、ネットワーク構成全体として複雑化/非効率化していくことが想定される。  より効率的なネットワーク構成案として、各BCのLCを持つ「ハブシステム」(プロキシ)と各BC上のLCとで相互検証を行う“ハブ&スポーク型ネットワーク構成”(プロキシ型)が考えられる。・

UFJ Financial Group, Inc. #31 #03-3⑤ クロスチェーンのアーキテクチャ(5/7)｜「プロキシ型」の採用  「IBC」のネットワーク構成として「プロキシ型」を採用することにより、以下記載のメリットにより拡張性が担保し易くなるものと考えられる。 ①新規に参画するBCは、ハブシステム(プロキシ)のみに繋げば、ハブシステム(プロキシ)の先の各接続済BCと容易に接続が可能になる ②接続先BCが新規増加する際、ハブシステム(プロキシ)に当該新規BCのLCを追加すればよく、各接続済BC側で新たなLCの追加は不要 ③「直接検証型」の場合、異なるBCの組み合わせによっては相手方BCのLCを実装することが困難なケースもあり得るが、「プロキシ型」では実装が可能・

UFJ Financial Group, Inc. #32 #03-3⑥ クロスチェーンのアーキテクチャ(6/7)｜「プロキシ型IBC」アーキテクチャ  前述の「(直接検証型)IBC」アークテクチャを、「プロキシ型IBC」アーキテクチャに昇華させた概念図は下図のとおり。  改ざん検知可能で信頼不要なBC間通信仲介役の「Relayer」の存在は不変だが、BC(A)の情報をクエリしてTxを送る先はBC(B)ではなくハブシステム (プロキシ)となり、ハブシステム(プロキシ)において検証した結果をBC(B)に提出し、BC(B)はハブシステム(プロキシ)の検証結果を検証する。  上記プロセスにより、各BC(A/B)はハブシステム(プロキシ)のLCを実装することで足り、その先の各BC(B/A)のLCをそれぞれ実装する必要がなくなる。・

UFJ Financial Group, Inc. #33 #03-3⑦ クロスチェーンのアーキテクチャ(7/7)｜「プロキシ型IBC」実装方式  「プロキシ型IBC」におけるハブシステムの実装方式として、①ブロックチェーン(Tendermint等)上実装、②TEE(Trusted Execution Environment) 上実装、の2パターンが考えられる。（TEE＝OSとは独立したCPU上の隔離実行環境。SGX＝インテルの「Software Gard Extension」の略）  ①は、Tendermintでの開発実績はあるものの、新たに導入するブロックチェーンにおけるセキュリティ対策コストや性能面での懸念が想定される。  ②は、①と比較して技術的に黎明期ながら、①におけるセキュリティや性能面の懸念を軽減でき、単一障害点とならない設計も可能なため、主案とする。・

UFJ Financial Group, Inc. #34 #03-4① Cordaにおける実装(1/5)｜Corda特有の考慮点  「Progmat Coin」を含む「Progmat」基盤は、金融ユースケースにおけるプライバシーと性能面の観点から、まずはCorda上で実装している。  Cordaは、Ethereum等と異なる仕組みを有しているため、EthereumやQuorum、HyperLdger等の基盤との接続には工夫が必要となる。  一般論として、NVN(Non-Validating Nortary)による二重消費検証を行っているCordaのビジネスネットワークの場合、Txの中身を検証する Validatorが必ずしも存在しないため、Txの正当性を異なるBC間で担保するための仕組みが必要となる。・

UFJ Financial Group, Inc. #35 #03-4② Cordaにおける実装(2/5)｜Corda特有の実装方法  Cordaにおいて、SCの移転Tx(＝Cash Contractと呼ぶ)のOwnerが各取引参加者のままの場合、前述の「IBC-module」「Cross Framework」によるフローにおいて、相手先BCからのデータを受けてアンロックする際、再度Ownerの署名が必要となり、アトミック性が損なわれる。  したがい、Contractの消費条件を任意に追加できるEncumbrance機構を活用し、EncumbranceによるCashのロックを行う際にOwnerを公知の秘密鍵に変更したうえで、相手先BCからのデータを受けてEncumbranceのアンロックと公知の公開鍵署名とを1つのフローで実行可能とする。・

UFJ Financial Group, Inc. #36 #03-4③ Cordaにおける実装(3/5)｜Cordaを含む「プロキシ型IBC」構成  前述の「プロキシ型IBC」におけるハブシステム(プロキシ)を「LCP Node」(Light Client Proxy Node)と定義し、当該Node上の「LCP Enclave」内に (Relayer,App経由で得た)Cordaを含む各BCからのデータを検証する「ELC」(Enclave Light Client)と、(Relayer,App経由で)各BCに返すデータに署名する際に用いるEnclave Keyを生成・管理する「EM」(Enclave Manager)を保持する。  「Attestation Service」により、「LCP Enclave」の完全性を各BC上の「LCP Client」が検証可能になる。・

UFJ Financial Group, Inc. #37 #03-4④ Cordaにおける実装(4/5)｜Cordaを含む「プロキシ型IBC」フロー①

UFJ Financial Group, Inc. #38 #03-4⑤ Cordaにおける実装(5/5)｜Cordaを含む「プロキシ型IBC」フロー②

UFJ Financial Group, Inc. #39 #03-5① 検証計画(1/6)｜検証フェーズ・ステップの大枠  FY2022下期時点では、「Progmat Coin」のSC移転プログラム群は開発前であること等から、実施可能なスコープから段階的に検証する方針とする。  Step1では、Quorum-Corda間の「IBC」を用いたクロスチェーン検証を疑似環境下で実行し、技術課題の抽出を行う。  Step2では、ST基盤側は「ibet」「Securitize」(Quorum)、SC基盤側は「Progmat Coin」(Corda)の検証環境下で実行し、各システム固有の課題の抽出を行ったうえで、STEP3において実際のSTセカンダリ取引におけるプロセス(PTSからの出来TxをインプットとしたSTP化)を踏まえた検証を行う。・

UFJ Financial Group, Inc. #40 #03-5② 検証計画(2/6)｜Step1｜検証の目的  Step1では、前述の机上検証により主案とした“Cordaを含む「プロキシ型IBC」構成“を前提に、構成要素である「IBC」「LCP」「Cross Framework」の活用によって、「拡張性の高いトラストレスなブロックチェーン間相互接続」と「異なる基盤上のSTとSCの同時移転(クロスチェーンアトミックスワップ)」を実装し、技術課題を抽出する。・

UFJ Financial Group, Inc. #41 #03-5③ 検証計画(3/6)｜Step1｜検証シナリオ  Step1では、ST基盤側をQuorum、SC基盤側をCordaと想定し、Quorum-Corda間のIBCを用いたクロスチェーン検証をスコープとする。  主要な正常系/異常系ケースにおける技術課題を抽出するため、下表のとおり6つの検証シナリオを実行する。・

UFJ Financial Group, Inc. #42 #03-5④ 検証計画(4/6)｜Step1｜検証項目  Step1の各検証シナリオにおける検証項目は下表のとおり。・

UFJ Financial Group, Inc. #43 #03-5⑤ 検証計画(5/6)｜Step1｜検証環境  前述のとおり、“Cordaを含む「プロキシ型IBC」構成”を前提に、検証環境を用意する。  Step1では、「Progmat Coin」のSC移転プログラム群は開発前であることに加え、ST基盤側も「ibet」「Securitize」と個別に検証を実施する場合は重複部分を含めてスコープが拡大することから、「Corda-Quorumの疑似環境」を本検証用に別途構築することとする。・

UFJ Financial Group, Inc. #44 #03-5⑥ 検証計画(6/6)｜Step1｜検証スケジュール  2023年2月末時点で検証結果を分科会として取りまとめることを念頭にスケジュールを策定。  2023年1月末までに前述の検証環境構築を完了し、2023年2月前半で各検証シナリオをPoCとして実行する想定。・

Group, Inc. #04 今後の計画 #45

CONFIDENTIAL / Discussion Purpose Only #04 今後の計画 © 2022 Mitsubishi
UFJ Financial Group, Inc. #46 #04-1 全体スケジュール  FY2021の「セカンダリ・DLT拡張WG」を踏まえ、4月より「資金決済WG」(=Progmat Coin)・「Progmat 5.0」に着手した。  「資金決済WG」中間報告を踏まえ、「Progmat Coin1.0」は実装フェーズに移行する。（改正資金決済法施行を踏まえた業務開始を目標とする）  3月までの残り6ヵ月で「CN/EN拡張後フローの確定」と「クロスチェーン技術検証」を進め、「Progmat 6.0」及び「Progmat Coin2.0」の実装に向けた前提整理/合意形成を行う。・ 1 マイルストーン 4 資金決済WG (Progmat内RTGS) 7 「Progmat 5.0」 (ANオープン化) 2 セカンダリWG 3 DLT拡張WG 8 「Progamt 6.0」 (EN/CNオープン化) 6 「Progmat Coin1.0」 (WS型/Progmat内) 5 9 「Progmat Coin2.0」 (クロスチェーン) DCC ・ WG Progmat 資金決済WG (クロスチェーンRTGS) FY2021 1Q-2Q 3Q-4Q FY2022 1Q-2Q 3Q-4Q FY2023 1Q-2Q 3Q-4Q FY2024 第1期 - 第2期 (全体設計) 第1期前半 (Coin1.0開発要件) 第1期前半 (実現方式机上検証) 予備検討・企画要件定義・開発予備検討企画・要件定義・開発第1期後半 (CN/EN拡張フロー) 第3期 (AN/CN/EN横断協議) 企画・要件定義・開発 (AN個別協議並走) (CN/EN個別協議並走) 予備検討第2期 (技術検証Step2-Step3) 企画・要件定義・開発予備検討第1期 - 第2期 (全体設計) 第1期後半 (技術検証Step1) Progmat Coin1.0リリース▼ ANオープン化▼ CN/ENオープン化▼ Progmat Coin2.0リリース▼ 中間報告書公開▼

Group, Inc. #05 Appendix #47

Group, Inc. #48 #05-1① Progmat内RTGS｜想定業務フロー｜(A)(1/6) #05 Appendix 業務 PTS 【売側】金商業者A (Coin/間接/CSV or API) 【買側】金商業者B 原簿管理者 SC発行者システム | Progmat 1 2 3 4 5 6 7 8 CN CN (金商A) (金商B) (Coin/間接/CSV or API) AN SC発行者 Node 9 10 カストディアン 11 CN (カストディアン) ST売注文約定日(取引都度～) 保有ST 残高確認 ST売注文発注注文ID 採番・連携受領 ST買注文自己口保有 SC残高確認自己口で保有しているSC残高がST買注文の金額を充足しているか金商業者にて事前確認充足している場合は、PTSへST買注文発注実施未充足の場合は、SC追加発行実施してから、PTSへST買注文発注実施顧客口預り金ロック売側注文ID

Group, Inc. #49 #05-1② Progmat内RTGS｜想定業務フロー｜(A)(2/6) #05 Appendix 業務 PTS 【売側】金商業者A (Coin/間接/CSV or API) 【買側】金商業者B 原簿管理者 SC発行者システム | Progmat 1 2 3 4 5 6 7 8 CN CN (金商A) (金商B) (Coin/間接/CSV or API) AN SC発行者 Node 9 10 カストディアン 11 CN (カストディアン) 約定日(取引都度～) 不足金額入金入金確認 SC追加信託指図 SC追加信託指図受領 SC追加信託情報登録 SC追加信託手続き SC追加信託 SC残高増加 SC残高増加連絡 SC残高増加確認自己口保有 SC不足確認 ST買注文発注買側注文ID 注文ID 採番・連携自己口SC保有残高不足時の対応：手オペ処理：自動処理受領

Group, Inc. #50 #05-1③ Progmat内RTGS｜想定業務フロー｜(A)(3/6) #05 Appendix 業務 PTS 【売側】金商業者A (Coin/間接/CSV or API) 【買側】金商業者B 原簿管理者 SC発行者システム | Progmat 1 2 3 4 5 6 7 8 CN CN (金商A) (金商B) (Coin/間接/CSV or API) AN SC発行者 Node 9 10 カストディアン 11 CN (カストディアン) マッチング出来通知受領出来通知受領 PTSから連携される出来通知は、既存の専用線ないしは、それに準じた専用線の利用想定 ST・SC移転指図 ST・SC移転情報登録 PTSより受領した出来情報を基に、金商業者は CSVでカストディアンへ指図を出すか、APIを通じて ST・SC移転情報を登録 PTSがEN未保有時点では、金商業者にて移転情報登録時に権利者IDを夫々登録できるため、個人情報の問題は発生しない買側SC残高事前確認 ST・SC移転指図約定日(取引都度～) ホールセール型SCの場合は、買側権利者IDに紐づく金商業者の自己口IDに置換して確認想定 ST・SC移転指図受領 ST・SC移転情報入力

Group, Inc. #51 #05-1④ Progmat内RTGS｜想定業務フロー｜(A)(4/6) #05 Appendix 業務 PTS 【売側】金商業者A (Coin/間接/CSV or API) 【買側】金商業者B 原簿管理者 SC発行者システム | Progmat 1 2 3 4 5 6 7 8 CN CN (金商A) (金商B) (Coin/間接/CSV or API) AN SC発行者 Node 9 10 カストディアン 11 CN (カストディアン) 買側SC残高不足確認買側SC残高不足通知 SC残高不足通知受領 SC残高不足連携 SC残高不足連携受領不足金額入金 SC追加信託指図 SC追加信託指図受領入金確認 SC追加発行手続き SC追加信託指図登録 SC追加発行 SC残高増加 SC残高増加連絡 SC残高増加確認自己口SC保有残高不足時の対応：手オペ処理約定日(取引都度～) ：自動処理

Group, Inc. #52 #05-1⑤ Progmat内RTGS｜想定業務フロー｜(A)(5/6) #05 Appendix 業務 PTS 【売側】金商業者A (Coin/間接/CSV or API) 【買側】金商業者B 原簿管理者 SC発行者システム | Progmat 1 2 3 4 5 6 7 8 CN CN (金商A) (金商B) (Coin/間接/CSV or API) AN SC発行者 Node 9 10 カストディアン 11 CN (カストディアン) ST・SC移転 Tx受領 ST・SC移転 Tx署名・回付 ST・SC移転 Tx受領 ST・SC移転 Tx署名・回付 ST・SC移転 Tx受領 ST・SC移転 Tx生成・回付買側SC残高再確認随時リトライ処理実行約定日(取引都度～)

Group, Inc. #53 #05-1⑥ Progmat内RTGS｜想定業務フロー｜(A)(6/6) #05 Appendix 業務 PTS 【売側】金商業者A (Coin/間接/CSV or API) 【買側】金商業者B 原簿管理者 SC発行者システム | Progmat 1 2 3 4 5 6 7 8 CN CN (金商A) (金商B) (Coin/間接/CSV or API) AN SC発行者 Node 9 10 カストディアン 11 CN (カストディアン) ST・SC移転 Tx確定・配布 ST・SC移転 Tx取込 ST・SC移転 Tx取込 ST・SC移転結果確認 ST・SC移転結果確認 NNへ二重消費検証依頼 NNから署名済 Tx受領 ST・SC移転結果連携約定日(取引都度～)

Group, Inc. #54 #05-2① Progmat内RTGS｜想定データフロー｜(A)(1/5) #05 Appendix 3 SC発行者システム SN 1 2 金商内システム金商内システム社内システム CN 社内システム AN f # 取引事由 PTS 【売】金商業者【買】金商業者カストディアン原簿管理者 SC発行者 PTSシステム a b c d e 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携売却注文情報・銘柄名 or コード・注文数量・注文単価・ST決済基盤コード買付注文情報・銘柄名 or コード・注文数量・注文単価・ST決済基盤コード ST 売買注文発注 PTS へ注文発注 SC追加信託情報・買側SC権利者ID ・追加信託金額 SC追加信託情報 SC追加信託情報 SC発行金額情報・SC発行金額 SC発行金額情報 SC追加信託情報・買側SC権利者ID ・SC発行金額 (SC 不足時） SC 追加発行 ST 売買注文受注注文受注時残高事前確認 ST売却注文受注 ST残高確認 ST買付注文受注 SC残高確認買付金商業者が自己口で保有するSC残高がST 買付注文の金額を充足していない場合は、PTSに発注する前にSC追加発行を実施買側SC残高情報買側SC残高情報

Group, Inc. #55 #05-2② Progmat内RTGS｜想定データフロー｜(A)(2/5) #05 Appendix 4 5 SC発行者システム SN 金商内システム金商内システム社内システム CN 社内システム AN f # 取引事由 PTS 【売】金商業者【買】金商業者カストディアン原簿管理者 SC発行者 PTSシステム a b c d e 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携売却注文情報売却注文ID情報・売側注文ID 売却注文ID情報買付注文情報買付注文ID情報・買側注文ID 買付注文ID情報注文 ID 採番・登録出来情報・約定ID ・銘柄名 or コード・ST約定数量・ST約定金額・売側注文ID ・買側注文ID ・ST決済基盤コード・売側参加者コード・買側参加者コード出来情報出来情報 PTS にてマッチング・出来通知マッチング・出来通知 PTS へ注文発注

Group, Inc. #56 #05-2③ Progmat内RTGS｜想定データフロー｜(A)(3/5) #05 Appendix 6 7 SC発行者システム SN 金商内システム金商内システム社内システム CN 社内システム AN f # 取引事由 PTS 【売】金商業者【買】金商業者カストディアン原簿管理者 SC発行者 PTSシステム a b c d e 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携 ST・SC移転情報・約定ID ・ST売買区分・SC決済手段・ST権利者ID ・ST受益権ID ・売側注文ID ・ST/SC約定数量・ST/SC約定金額・買側注文ID (利用SCの別) ・移転パターン (取次・媒介等) ST・SC移転情報 ST・SC移転情報 ST・SC移転情報買側SC残高確認カストディアンへ ST ・ SC 移転指図 ST ・ SC 移転指図買側 SC 残高確認 PTSより受領した出来情報を基に、金商業者は CSVによるカストディアンへの指図、もしくはAPIを通じて、ST・SC移転情報を登録なお、PTSがEN未保有時点では、金商業者にて移転情報登録時に権利者IDを夫々登録できるため、個人情報の問題は発生しない事前登録された資金決済情報を基に、買側 SC残高を確認ホールセール型SCの場合は、SC保有者である金商業者の自己口のIDも確認買側 SC 残高確認 ST・SC移転情報・約定ID ・ST売買区分・SC決済手段・ST権利者ID ・ST受益権ID ・売側注文ID ・ST/SC約定数量・ST/SC約定金額・買側注文ID (利用SCの別) ・移転パターン (取次・媒介等)

Group, Inc. #57 #05-2④ Progmat内RTGS｜想定データフロー | (A)(4/5) #05 Appendix 8 9 10 SC発行者システム SN 金商内システム金商内システム社内システム CN 社内システム AN f # 取引事由 PTS 【売】金商業者【買】金商業者カストディアン原簿管理者 SC発行者 PTSシステム a b c d e 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携買側SC残高・約定ID ・買側SC不足金額不足金額情報買側SC残高不足金額情報買側SC残高不足金額情報 SC追加信託情報・買側SC権利者ID ・追加信託金額 SC追加信託情報 SC追加信託情報 SC発行金額情報・SC発行金額 SC発行金額情報買側SC残高再確認 SC追加信託情報・買側SC権利者ID ・SC発行金額買側 SC 残高不足通知 SC 追加発行買側 SC 残高再連携 SC 残高不足

Group, Inc. #58 #05-2⑤ Progmat内RTGS｜想定データフロー｜(A)(5/5) #05 Appendix 11 12 SC発行者システム SN 金商内システム金商内システム社内システム CN 社内システム AN f # 取引事由 PTS 【売】金商業者【買】金商業者カストディアン原簿管理者 SC発行者 PTSシステム a b c d e 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携 ST・SC移転情報・取引ID ・トークンのTxID ・約定ID ・ST/SC約定数量・売側権利者ID ・買側権利者ID ・ST/SC約定金額・ST/SC受益権ID CN署名 ST・SC移転情報 CN署名 AN署名 ST・SC移転情報 CN署名 AN署名 ST・SC移転情報 CN署名 AN署名 SN署名 SN署名 NN署名(NNにて付与) ST・SC移転情報 ST・SC移転情報 ST ・ SC 移転 Tx 生成・回付 ST ・ SC 移転 Tx 確定・取込 ST ・ SC 移転実行処理

Group, Inc. #59  複数金商業者を委託者兼受益者とする受益証券発行信託を銘柄別に締結し、資金決済法上の電子決済手段として特定信託受益権を発行する。  WS型SCでは投資家は直接SCを保有しないため、金商業者とは既存契約に基づく金銭預託とST/SC交換取引の取次の委託に留まる。  パターン(D)の断面②以降はCNオープン化によりカストディ委託は任意となるため、金商業者-受託者間で事務取扱要領により詳細を定める。  金商業者がAPIを利用する場合は受託者とAPI利用契約を締結し、受託者/金商業者はPF提供者とPF利用契約を締結する。 #05 Appendix #05-3 Progmat内RTGS｜契約構成｜(D) 金商業者(B) 総合取引約款等に基づくST購入用金銭の預託,ST/SC交換取引の取次の委託 01 受託者委託者兼受益者金商業者(A) 02 03 02 03 金銭(A) 金銭(B) SC(A) 受益証券発行信託 SC(B) 委託者兼受益者投資家投資家(a1) 投資家投資家(a2) 投資家投資家(b1) 投資家投資家(b2) (SC銘柄別) 金銭(A) SC(A) 預り金 (a1,a2) 金銭(B) SC(B) 預り金 (b1,b2) 01 01 04 04 プラットフォーム提供者 Core Developer 05 受益証券発行信託契約(SC銘柄別,複数委託者) 02 受益権原簿管理等事務取扱要領 03 API利用契約(金商業者-受託者間,任意) 04 PF利用契約 05 電子決済手段等発行者

Group, Inc. #60 #05-4① Progmat内RTGS｜業務システム俯瞰｜SC移転(ST決済)｜(D)  各投資家は、口座を有する各金商業者に対して、取引決済用の資金を預託したうえで(現状どおり)、ST/SC交換取引の取次を依頼する。  PTSの媒介により金商業者間でST/SC交換取引が法的に成立し、その経済効果が取次の委託元の各投資家に帰属する。  パターン(D)の断面②以降は、PTSはENを、金商業者はCNを直接管理し、出来通知からST/SC移転までDLT上で自動完結(STP化)する。  各金商業者はST決済用SC枠を用意しておき、顧客口の買付資金を自己口に移しつつ、自己のSC枠内で他金商業者とDLT上で自動決済を行う。 ST取扱者/SC委託者兼受益者(B) バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) 証券口座 (顧客口) 投資家(b) ST取扱者/SC委託者兼受益者(A) バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) 証券口座 (顧客口) デジタル証券PTS ①ST売注文 ②ST売注文 ⑥ST買注文 ⑦出来通知 ⑦出来通知投資家(a) SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) Progmat ST/Coin (ST/SC移転管理) Progmat ST/Coin (ST/SC移転管理) ⑧ST移転/SC移転(DLT) ④ST買注文 ③ST購入資金預託 ⑤振替【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat ST/Coin(ST/SC移転管理システム) (取次委託) (取次委託) (DLT) (DLT) #05 Appendix

Group, Inc. #61 #05-4② Progmat内RTGS｜業務システム俯瞰｜SC発行(枠確保)｜(D)  WS型SCにおけるSC発行は、STセカンダリ取引における流動性(枠)確保のための事前発行、及び枠超過時の追加発行の2パターンを想定。  金商業者は現行の日銀当座預金と同様に事前に一定金額のSCを発行の上で、前述のとおり即時決済(T+0)を実現する形を想定。  枠の考え方については、ST取扱残高やセカンダリ取引実績に応じて、各金商業者(SC委託者兼受益者)が動的にコントロールすることを想定する。  パターン(A)との違いは、CNオープン化により金商業者がCNを直接管理することが可能となり、カストディアンとの残高確認等が不要となる。 SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) ST原簿管理者ファンド管理システム (信託会計等) 勘定系システム Progmat Coin (SC移転管理) ST取扱者/SC委託者兼受益者バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) Progmat Coin (SC移転管理) 証券口座 (顧客口) 投資家 ST投資対象【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat Coin(SC移転管理システム) ①SC発行指図 ②入金 ③SC発行(DLT) 〔→SC委託者兼受益者〕入金&振替記帳・処理銀行預金口座 #05 Appendix

Group, Inc. #62 #05-4③ Progmat内RTGS｜業務システム俯瞰｜SC発行(追加)｜(D)  STセカンダリ取引が想定よりも増加した場合、ST決済用SC枠が不足するため、SCの追加発行が必要となる。  ST買注文前/移転前の必要SC残高確認により不足を検知した場合に発生するが、その前提としてST買発注者(投資家)は必要な決済用資金を予め顧客口に預託しているため、追加発行に要する法定通貨を顧客口から自己口に移したうえで、自己口の当該資金を用いてSCの追加発行を行う。  パターン(A)との違いは、CNオープン化により金商業者がCNを直接管理することが可能となり、発行完了等の確認が自社内で完結する点。 #05 Appendix SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) ST原簿管理者ファンド管理システム (信託会計等) 勘定系システム Progmat Coin (SC移転管理) ST取扱者/SC委託者兼受益者バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) Progmat Coin (SC移転管理) 証券口座 (顧客口) 投資家 ST投資対象【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat Coin(SC移転管理システム) ②SC発行指図 ④入金 ⑤SC発行(DLT) 〔→SC委託者兼受益者〕入金&振替記帳・処理 ①ST購入資金預託 ③振替銀行預金口座

Group, Inc. #63 #05-4④ Progmat内RTGS｜業務システム俯瞰｜SC一部償還｜(D)  STセカンダリ取引におけるST売却側の金商業者様及び投資家は、売側金商業者宛てのWS型SCで対価を受領するため、その後投資家の顧客口へ法定通貨として資金移動する必要がある。  よって、SCを一部償還して証券会社自己口へ必要な法定通貨を準備した上、自己口から顧客口へ当該資金を振り替えることを想定。  パターン(A)との違いは、CNオープン化により金商業者がCNを直接管理することが可能となり、償還完了等の確認が自社内で完結する点。 SC原簿管理者ファンド管理システム (信託会計等) 勘定系システム銀行預金口座 Progmat Coin (SC移転管理) ST原簿管理者ファンド管理システム (信託会計等) 勘定系システム Progmat Coin (SC移転管理) ST取扱者/SC委託者兼受益者バックシステム (約定管理等) 銀行預金口座 (証券会社自己口) Progmat Coin (SC移転管理) 証券口座 (顧客口) 投資家 ST投資対象【凡例】 :対面/画面入力 :既存システム連携 :Progmat DLT :Progmat API :法定通貨送金 :既存の資金決済システム :Progmat Coin(SC移転管理システム) ①SC一部償還指図 ③出金 ②SC償還(DLT) 出金記帳・処理 ④振替銀行預金口座 #05 Appendix

Group, Inc. #64 #05-5① Progmat内RTGS｜想定業務フロー｜(D)(1/6) #05 Appendix 1 2 3 4 5 6 7 8 9 10 11 業務 PTS 【売側】金商業者A (Coin/直接/DLT) 【買側】金商業者B (Coin/直接/DLT) カストディアン原簿管理者 SC発行者システム / Progmat EN (PTS) CN (金商業者A) CN (金商業者B) AN (原簿管理者) SN (SC発行者) 約定日(取引都度) ST売注文保有ST 残高確認 ST売注文発注注文ID 採番・連携受領 ST買注文自己口保有 SC残高確認売側注文IDと移転情報紐付 PTSへの発注時に採番された注文IDにSTSC移転に必要となる情報を紐付し、各社の社内システム上で管理し、CNへ注文情報を連携(マスタ情報(RDB)) 顧客口預り金ロック自己口で保有しているSC残高がST買注文の金額を充足しているか金商業者にて事前確認充足している場合は、PTSへST買注文発注実施未充足の場合は、SC追加発行実施してから、PTSへST買注文発注実施売側注文ID

Group, Inc. #65 #05-5② Progmat内RTGS｜想定業務フロー｜(D)(2/6) #05 Appendix 1 2 3 4 5 6 7 8 9 10 11 業務 PTS 【売側】金商業者A (Coin/直接/DLT) 【買側】金商業者B (Coin/直接/DLT) カストディアン原簿管理者 SC発行者システム / Progmat EN (PTS) CN (金商業者A) CN (金商業者B) AN (原簿管理者) SN (SC発行者) 約定日(取引都度) 不足金額入金入金確認 SC追加信託指図 SC追加発行処理 SC追加発行 SC残高増加 SC残高増加確認自己口保有 SC不足確認 ST買注文発注買側注文ID 自己口SC保有残高不足時の対応：手オペ処理：自動処理注文ID 採番・連携注文IDと移転必要情報紐付 PTSへの発注時に採番された注文IDにSTSC移転に必要となる情報を紐付し、各社の社内システム上で管理し、CNへ注文情報を連携(マスタ情報(RDB)) 受領

Group, Inc. #66 #05-5③ Progmat内RTGS｜想定業務フロー｜(D)(3/6) #05 Appendix 1 2 3 4 5 6 7 8 9 10 11 業務 PTS 【売側】金商業者A (Coin/直接/DLT) 【買側】金商業者B (Coin/直接/DLT) カストディアン原簿管理者 SC発行者システム / Progmat EN (PTS) CN (金商業者A) CN (金商業者B) AN (原簿管理者) SN (SC発行者) 出来情報自動作成出来通知Tx 生成・回付出来通知Tx 取込出来通知Tx 取込買側移転情報連携依頼買側移転情報連携依頼受領買側移転情報連携買側移転情報受領 SC移転金額確認依頼 SC移転金額確認依頼受領 SC移転金額確認結果連携約定日(取引都度) PTSにてENへデータを連携するシステム構築が必要プログラムバグによる誤情報連携時のリスク・責任範囲に係る整理が必要 ST売側CNより、PTSから売側注文ID、買側注文ID、約定IDをST買側CNに連携 ST買側CNは、連携された注文IDをキーにマスタ情報(RDB)に格納されている買側移転情報を連携することを想定売側CNは、ST決済に必要なSC金額の充足確認を買側CNに依頼し、買側CNは充足・未充足の結果を売側CNに返す想定ホールセール型SCの場合は、買側権利者IDに紐づく金商業者の自己口IDに置換して確認想定具体的な処理方法については、下期分科会にて継続検討マッチング

Group, Inc. #67 #05-5④ Progmat内RTGS｜想定業務フロー｜(D)(4/6) #05 Appendix 1 2 3 4 5 6 7 8 9 10 11 業務 PTS 【売側】金商業者A (Coin/直接/DLT) 【買側】金商業者B (Coin/直接/DLT) カストディアン原簿管理者 SC発行者システム / Progmat EN (PTS) CN (金商業者A) CN (金商業者B) AN (原簿管理者) SN (SC発行者) SC残高不足通知買側SC残高不足通知受領買側SC残高不足金額入金入金確認 SC追加発行指図 SC追加発行処理 SC追加発行 SC残高増加 SC残高増加確認自己口SC保有残高不足時の対応：手オペ処理：自動処理約定日(取引都度) SC移転金額確認依頼 SC移転金額確認依頼受領 SC移転金額確認結果連携 SC移転金額確認結果受領随時リトライ処理実行買側SC残高不足通知

Group, Inc. #68 #05-5⑤ Progmat内RTGS｜想定業務フロー｜(D)(5/6) #05 Appendix 1 2 3 4 5 6 7 8 9 10 11 業務 PTS 【売側】金商業者A (Coin/直接/DLT) 【買側】金商業者B (Coin/直接/DLT) カストディアン原簿管理者 SC発行者システム / Progmat EN (PTS) CN (金商業者A) CN (金商業者B) AN (原簿管理者) SN (SC発行者) 売側ST残高確認 ST・SC移転 Tx生成・回付 ST・SC移転 Tx受領 ST・SC移転 Tx署名・回付 ST・SC移転 Tx受領 ST・SC移転 Tx署名・回付 ST・SC移転 Tx受領 ST・SC移転 Tx署名・回付 ST・SC移転 Tx受領約定日(取引都度)

Group, Inc. #69 #05-5⑥ Progmat内RTGS｜想定業務フロー｜(D)(6/6) #05 Appendix 1 2 3 4 5 6 7 8 9 10 11 業務 PTS 【売側】金商業者A (Coin/直接/DLT) 【買側】金商業者B (Coin/直接/DLT) カストディアン原簿管理者 SC発行者システム / Progmat EN (PTS) CN (金商業者A) CN (金商業者B) AN (原簿管理者) SN (SC発行者) NNへ二重消費検証依頼 NNから署名付 Tx受領 ST・SC移転Tx 確定・配布 ST・SC移転Tx 取込 ST・SC移転Tx 取込 ST・SC移転Tx 取込 ST・SC移転結果確認 ST・SC移転結果確認約定日(取引都度)

Group, Inc. #70 #05-6① Progmat内RTGS｜想定データフロー｜(D)(1/5) #05 Appendix # 取引事由 1 2 原簿管理者 SC発行者 PTSシステム EN 金商内システム CN 金商内システム CN 社内システム AN PTS(Node保有) 【売】金商業者(Coin/直接) 【買】金商業者(Coin/直接) SC発行者システム SN g h i j k f a b c d e 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携 SC追加発行情報・買側SC権利者ID ・SC追加発行金額 SC追加発行情報 CN署名 SC追加発行情報買側SC残高情報・買側権利者ID ・買側SC残高買側SC残高情報買側SC残高情報 SC 追加発行注文受注 ST 売買時残高事前確認 ST売却注文受注 ST残高確認 ST買付注文受注 SC残高確認買付金商業者が自己口で保有するSC残高がST 買付注文の金額を充足していない場合は、PTSに発注する前にSC追加発行を実施

Group, Inc. #71 #05-6② Progmat内RTGS｜想定データフロー｜(D)(2/5) #05 Appendix 3 4 SC発行者システム SN 原簿管理者 SC発行者 PTSシステム EN 金商内システム CN 金商内システム CN 社内システム AN g h i j k # 取引事由 PTS(Node保有) 【売】金商業者(Coin/直接) 【買】金商業者(Coin/直接) f a b c d e 売却注文情報・銘柄名 or コード・注文数量・注文単価・ST決済基盤コード買付注文情報・銘柄名 or コード・注文数量・注文単価・ST決済基盤コード注文受注売却注文情報売却注文ID情報・売側注文ID 売却注文ID情報【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携注文 ID 採番・登録売却注文情報・売却注文ID ・ST権利者ID ・ST売買区分・ST受益権ID ・SC決済手段・移転パターン・注文数量・金額 (利用SCの別) (取次・媒介等) 買付注文情報買付注文ID情報・買側注文ID 買付注文ID情報 PTS へ注文発注売却注文情報買付注文情報 PTSにて採番された注文IDと移転必要情報を紐付し、各社はCN(マスタ情報(RDB))へ登録。注文IDと移転必要情報の紐付登録方法については、下期分科会にて継続検討事項買側注文情報・買側注文ID ・ST権利者ID ・ST売買区分・ST受益権ID ・SC決済手段・移転パターン・注文数量・金額 (利用SCの別) (取次・媒介等)

Group, Inc. #72 #05-6③ Progmat内RTGS｜想定データフロー｜(D)(3/5) #05 Appendix 7 5 6 SC発行者システム SN 原簿管理者 SC発行者 PTSシステム EN 金商内システム CN 金商内システム CN 社内システム AN g h i j k # 取引事由 PTS(Node保有) 【売】金商業者(Coin/直接) 【買】金商業者(Coin/直接) f a b c d e 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携出来情報・約定ID ・銘柄名 or コード・ST約定数量・ST約定金額・売側注文ID ・買側注文ID ・ST決済基盤コード・売側参加者コード・買側参加者コード出来情報・約定ID ・銘柄名 or コード・ST約定数量・ST約定金額・売側注文ID ・買側注文ID ・取引ID ・トークンTxID ・売側参加者コード・買側参加者コード EN署名出来情報出来情報 PTS にてマッチング出来通知 Tx 生成・回付マッチング買側移転情報・買側注文ID ・約定ID 連携依頼・売側注文ID 買側移転情報・買側注文ID ・約定ID ・売側注文ID ・買側ST権利者ID ・買側SC権利者ID ・買側SC決済手段・買側移転パターン買側移転情報買側移転情報確認買側移転必要情報確認売側CNから連携された約定IDと注文IDを基に、買側CNは該当する買側移転情報を事前登録した CN(マスタ情報(RDB))から抽出し連携金商業者間の個人情報授受方法については、下期分科会にて継続検討事項

Group, Inc. #73 #05-6④ Progmat内RTGS｜想定データフロー｜(D)(4/5) #05 Appendix f a b c d e # 取引事由 PTS(Node保有) 【売】金商業者(Coin/直接) 【買】金商業者(Coin/直接) g h i j k SC発行者システム SN 原簿管理者 SC発行者 PTSシステム EN 金商内システム CN 金商内システム CN 社内システム AN 8 9 10 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携買側SC残高連携依頼・買側SC権利者ID ・約定ID 買側SC残高情報・買側SC権利者ID ・約定ID ・SC充足確認結果買側SC残高情報買側 SC 充足確認 SC移転金額不足通知 SC追加発行情報・買側SC権利者ID ・SC追加発行金額 SC追加発行情報 CN署名 SC追加発行情報買側SC残高情報・買側SC権利者ID ・買側SC残高買側SC残高情報買側SC残高情報買側 SC 残高不足通知 SC 追加発行 SC 残高不足売側CNはSC移転金額の充足確認を買側CNへ依頼買側CNは保有するSC残高が移転金額を充足しているか確認し、確認結果を売側CNに返す想定具体的な処理方式は下期分科会にて継続検討買側移転必要情報確認 SC移転金額不足通知

Group, Inc. #74 #05-6⑤ Progmat内RTGS｜想定データフロー｜(D)(5/5) #05 Appendix f a b c d e # 取引事由 PTS(Node保有) 【売】金商業者(Coin/直接) 【買】金商業者(Coin/直接) g h i j k SC発行者システム SN 原簿管理者 SC発行者 PTSシステム EN 金商内システム CN 金商内システム CN 社内システム AN 11 12 13 【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報：署名：連携：DLT間連携 SC移転金額受足確認結果 ST・SC移転情報・約定ID ・ST・SC移転数量・ST・SC移転金額・売側注文ID ・買側注文ID ・取引ID ・トークンTxID ・売側権利者ID ・買側権利者ID ・ST/SC受益権ID 買側 SC 充足確認売側CN署名 ST・SC移転情報売側CN署名買側CN署名 ST・SC移転情報売側CN署名買側CN署名 AN署名 ST・SC移転情報売側CN署名買側CN署名 AN署名 SN署名 ST・SC移転情報売側CN署名買側CN署名 AN署名 SN署名 NN署名(NNにて付与) ST・SC移転情報 ST・SC移転情報 ST・SC移転情報 ST ・ SC 移転 Tx 生成・回付 ST ・ SC 移転 Tx 確定・取込 ST ・ SC 移転実行処理 SC移転金額充足確認結果 SC移転金額充足確認依頼

CONFIDENTIAL / Discussion Purpose Only #05 Appendix © 2022 Mitsubishi
UFJ Financial Group, Inc. #75 #05-7① クロスチェーンRTGS｜検証計画｜Step1｜検証シナリオ1  検証シナリオ1「正常系｜SC/STの同時移転の実行」の想定フローは以下のとおり。  検証項目は、「①売側Aliceの送金Tx生成&送付」、「②各Signerの承認を受け、Corda上でのSC仮送金とELCでの仮送金確認」、「③Quorum上でのLCPでのロック確認」、「④Quorum上でのST移転実施と同時にCorda上でのSC移転実施」・

UFJ Financial Group, Inc. #76 #05-7② クロスチェーンRTGS｜検証計画｜Step1｜検証シナリオ2  検証シナリオ2「異常系｜Relayerがダウン後、再開時の同時移転が成功する」の想定フローは以下のとおり。  検証項目は、「①検証シナリオ1と同様のシナリオ上で、Relayerをダウンさせる」、「②Relayerはステートレスなため、再開後に処理は成功する」・

UFJ Financial Group, Inc. #77 #05-7③ クロスチェーンRTGS｜検証計画｜Step1｜検証シナリオ3  検証シナリオ3「異常系｜LCP Nodeがダウン後、再開時の同時移転が成功する」の想定フローは以下のとおり。  検証項目は、「①検証シナリオ1と同様のシナリオ上で、LCP Nodeをダウンさせる」、「②RelayerはLCP Node再開後にPacketを再送するため、処理は成功する」・

UFJ Financial Group, Inc. #78 #05-7④ クロスチェーンRTGS｜検証計画｜Step1｜検証シナリオ4  検証シナリオ4「異常系｜Sellerが移転対象ST不所持による同時移転失敗」の想定フローは以下のとおり。  検証項目は、「①検証シナリオ1と同様のシナリオ上で、売側AliceのST不所持でST移転(on Quorum)が失敗する」、「②処理が異常終了(Abort) し、買側BobのSCは移転しない」・

UFJ Financial Group, Inc. #79 #05-7⑤ クロスチェーンRTGS｜検証計画｜Step1｜検証シナリオ5  検証シナリオ5「異常系｜Buyerの残高不足による同時移転失敗」の想定フローは以下のとおり。  検証項目は、「①検証シナリオ1と同様のシナリオ上で、買側Bobの資金不足で送金(on Corda)が失敗する」、「②処理が異常終了(Abort)し、売側 AliceのSTは移転しない」・

UFJ Financial Group, Inc. #80 #05-7⑥ クロスチェーンRTGS｜検証計画｜Step1｜検証シナリオ6  検証シナリオ6「異常系｜Relayerの不正な振る舞いによる同時移転失敗」の想定フローは以下のとおり。  検証項目は、「①検証シナリオ1と同様のシナリオ上で、PacketやAckを不正なものに入れ替えて実施」、「②Cross Frameworkは検証の結果、この Txを無視するため、後続処理が発生しない（状態継続）」・

UFJ Financial Group, Inc. #81 #05-8① クロスチェーンRTGS｜IBCとは｜「IBC」概要①  IBCは、複数の異なるブロックチェーン間で情報をやり取りを行うために開発されたデータの転送、認証、信頼性を処理する通信プロトコルで、「Inter Blockchain Communication」の略称である。  TCP/IPプロトコルをモデルとして、ブロックチェーン間の相互運用を目指したブロックチェーン・プラットフォームである「Cosmos」によって開発された。・

UFJ Financial Group, Inc. #82 #05-8② クロスチェーンRTGS｜IBCとは｜「IBC」概要②  「Cosmos」は、主にブロックチェーンの相互運用性に係る問題を解決するため、「Internet of Blockchain」というコンセプトを掲げたプロジェクト。  ブロックチェーンの仕様に依存せずにアプリケーションを開発可能にするため、Tendermint BFTと呼ばれるパッケージ化して提供し、その上で様々な言語でアプリケーション開発を可能とする構成を採用しており、その効率的な開発のために「Cosmos SDK」や「IBC」といった仕組みを提供。  また、IBCによってハブ型でブロックチェーンが接続されたネットワーク全体を「Cosmons Network」と呼ぶ。・

UFJ Financial Group, Inc. #83 #05-8③ クロスチェーンRTGS｜IBCとは｜「Cosmos」「Polkadot」概要  ブロックチェーンの市場拡大に伴い、ブロックチェーンの相互運用性に係る課題が注目されると、それを解消するための様々な仕組みが考えられるとともに、相互運用性を目的として新たなブロックチェーン基盤を開発するプロジェクトが立ち上げられた。  「Cosmos」「Polkadot」は、共に相互運用性を主眼としたプロジェクトとして知られ、共に大きなエコシステムを形成している。・

UFJ Financial Group, Inc. #84 #05-8④ クロスチェーンRTGS｜IBCとは｜「Polkadot」との比較  「Cosmos」「Polkadot」は共にブロックチェーンの相互運用性を主眼として発足したプロジェクトであるが、「Cosmos」は既に複数のDappsがメインネットローンチしており、IBCによって40以上のチェーンが本番環境で相互接続している。  また、「Polkadot」は全体としてのセキュリティやガバナンスの統一を意識しているのに対し、「Cosmos」は各ブロックチェーンの独立性、開発の柔軟性を重視しており、ブロックチェーンの構築に制約がないことが特徴であり、金融機関特有のセキュリティをネットワーク夫々で設定可能と考えられる。・

CONFIDENTIAL / Discussion Purpose Only 免責事項 © 2022 Mitsubishi UFJ
Financial Group, Inc. #85  本資料は、ディスカッション用に作成されたものであり、三菱UFJ信託銀行の個別の商品、サービスを勧誘することを目的としたものではありません。本ディスカッション或いは資料だけで契約が成立するものではありません。従って、当社はいかなる種類の法的義務、或いは責任を負うものではありません。  本資料は信頼できると思われる各種データ等に基づいて作成されていますが、当社はその正確性、完全性を保証するものではありません。ここに示したすべての内容は、当社の現時点での判断を示しているに過ぎません。また、本資料に関連して生じた一切の損害については、当社は責任を負いません。その他専門的知識に係る問題については、必ず貴社の弁護士、税理士、公認会計士等の専門家にご相談の上ご確認ください。  本資料は当社の著作物であり、著作権法により保護されております。当社の事前の承認なく、本資料の全部もしくは一部を引用または複製、転送等により使用することを禁じます。  商号等：三菱ＵＦＪ信託銀行株式会社登録金融機関関東財務局長（登金）第33号  加入している協会の名称：日本証券業協会一般社団法人日本STO協会一般社団法人金融先物取引業協会一般社団法人日本投資顧問業協会

CONFIDENTIAL / Discussion Purpose Only

20220929_【DCC】資金決済WG_中間報告書_本紙

20220929_【DCC】資金決済WG_中間報告書_本紙

More Decks by progmat

Other Decks in Business

Featured

Transcript