20220316_【SRC】セカンダリ・DLT拡張WG_第2期報告書_本紙

ST研究コンソーシアム(SRC)
セカンダリ・DLT拡張WG｜第2期｜報告書
2022年3月
ST研究コンソーシアム

View Slide

© Mitsubishi UFJ Financial Group, Inc.
目次
エグゼクティブサマリ
#1
#02 デジタル証券市場参加者間の連携方法
#03 DLTオープン化後のガバナンス・セキュリティ・秘匿化
#01 Progmatと本WGの概要
#04 証券バリューチェーン変革の定量効果算定
#05 ネクストアクション
#06 Appendix

View Slide

エグゼクティブサマリ
#2
ネクストアクション
・デジタル証券市場に必要な証券決済基盤「Progmat ST」、及び資金決済基盤「Progmat Coin」を提供し、
ワンストップでポストトレードプロセスが完結する仕組みを構築する。
今
期
成
果
・金商業者、ST原簿管理者、SC原簿管理者、カストディアンに加えて、デジタル証券PTSもDLTネットワークに直接参加する
ことで、PTS発信のSTに係る出来通知をトリガーに証券決済・資金決済までが1本のフローで完結する仕組みを構築可能
デジタル証券市場
参加者間の
連携方法
DLTオープン化後の
ガバナンス・
セキュリティ・秘匿化
証券バリューチェーン
変革の定量効果
算定
・「Progmat Coin」は、デジタルアセットの資金決済に最適化したステーブルコインで、DLT上でアトミックなDvP決済が
可能となることで、決済リスク・業務負担・コストの極小化が可能となる。
であることを確認できた。(PTS側の責任分界、PTS側コストの市場参加者シェア方法は継続論点)
・Progmatの運営は、「デジタルアセット共創コンソーシアム(以下、DCC)」の会員企業による分権的運営に移行し、
意思決定や開発プロセスをオープン化することを目標とする。（三菱UFJ信託銀行の集中管理体制から高度化）
・Progmatコンポーネントのうち、Corda NWとNotary Nodeは非営利団体「Corda Network Foundation」が、
Progmatの共通仕様部分(Core Dapps)をCore Developerが、Node別の固有機能(Service Dapps)や
UI等のアプリ層をService Developerがそれぞれ責任・役割を分担することで、全体のガバナンスを担保する。
・流出リスクへの対応としての秘密鍵管理方式について、Progmatの仕様を踏まえ、実態的に不正移転により投資家の
被害に繋がる蓋然性が極めて低いことから、HSM(Hardware Security Module)利用は必須としない。
・トランザクションデータの秘匿性は、現行仕様で必要十分なプライバシー水準は担保されており、追加対応は要しない。
・DLTをオープン化し、ポストトレードがワンストップで完結する仕組みになる場合、オープン化前/既存決済の方式に比して
毎年約1,500百万円(84%)のネット効率化効果(Progmat利用コスト加味後)が想定される。
(効果試算のため、将来的なST取扱残高を1社あたり500億円、業者数を15社として、諸条件含めて数値仮置きの上、試算)
・DLT連携や「Progmat Coin」とのDvPによってフローが簡便化され、業務委託コストや各種手数料、業務執行に伴う人件費が
不要となり、Progmatを利用する上で必要なライセンスフィやAPI利用料のみで運用が可能となる見込み。
・Progmat基盤拡張に係るロードマップ(目標時期)について、APIオープン化を2022/12、DLTオープン化をFY2023中として、
本WGによる方針に則り、DLTオープン化に対応する「Progmat 5.0」PJの検討を開始する。(継続論点引き取り)
・SRCを2022/4より「DCC」へ改組したうえで、「資金決済WG」として「Progmat内完結の資金決済フロー具体化」
及び「クロスチェーン決済具体化」の2つの分科会を設置し、議論を開始する。

View Slide

#01
Progmatと本WGの概要
#3

View Slide

CONFIDENTIAL / Discussion Purpose Only
#01-1 拡張するエコシステム
 「Progmat」は、Node保有又はAPIを介して、様々な発行体・原簿管理者・金商業者・仲介業者・カストディアン等が参加可能なオープンな仕組み。
 「ST」「SC」「UT」を発行・管理するための独立したネットワーク(NW)で構成され、クロスチェーンにより他のデジタルアセットとの連携も想定している。
 デジタルアセットに関する様々なユースケースを企業横断で具現化する枠組み(※)に、80社を超える企業が参画しており、複数のWGやPJが並走中。
※ST研究コンソーシアム(SRC)…22年4月より「デジタルアセット共創コンソーシアム」(DCC)に改組する旨を公表済み
© Mitsubishi UFJ Financial Group, Inc. #4
Progmat ST
Progmat Coin
Progmat UT
3rd Party
ST
CA
(暗号資産)
NFT
(コンテンツ等)
3rd Party
SC
CBDC
(デジタル通貨)
クロスチェーン
発行体
発行体
発行体
発行体
発行体
原簿
管理者
原簿
管理者
金商業者
カストディ
アン
金商業者
金商業者
PTS
スーパー
アプリ等
(仲介業者)
(各参加者のCloud環境)
APIs
【凡例】 :Node(全NW参加) :Node(2つのNWに参加) :Node(1つのNWのみ参加)

View Slide

#01-2 Progmatのロードマップと本WGのスコープ
 DLTを中核とした金融インフラである「Progmat」は、金融取引のバリューチェーンのDXと新市場創出を志向し、大きく3つの方向性で拡張中。
：①投資対象STの多様化 ②プラットフォームの拡張 ③市場・決済機能の拡張
 「セカンダリ・DLT拡張WG」(以下、本WG)は、「②プラットフォームの拡張」及び「③市場・決済機能の拡張」について、市場関係者の広範な意見の集
約と共創プロセスを経て、ルールメイキングや個別開発PJ移行等の具体化に向けて設置したもの。（2020年1月より「第1期」開始）
投資対象STの多様化
プラットフォームの拡張市場・決済機能の拡張
不動産
航空機・船舶
インフラ・設備
電車・自動車
ロケット・人工衛星コンテンツ
嗜好品
社債
未上場株式
デジタル完結の
権利移転基盤
(特許登録)
Utility Token
API&DLT
証券会社を介した
随時売買・換金
デジタル証券PTS
連携
Stable Coin/
デジタル通貨連携
DEX/P2P(直接取引)
「利用」との融合
照合不要化決済リスク減
流動性向上
可能性拡大
(障壁減,投資家層拡大)
構築支援,スマコン共創
金銭債権
オープン化
UT
ST
連携(ファンマーケ)
執行自動化
新たな取引機会
…実現済み
…「セカンダリ・DLT拡張WG」
(本WG)のスコープ

View Slide

#01-3 第2期WG概要・開催目的
第2期WGの目的・スコープ位置づけ・時間軸
セカンダリ・DLT拡張WG（第2期）
【目的】2023年度からの「ODX連携」「DLTネットワークオープン化」
開始に向けた、詳細定義とステークホルダー間合意形成
【1】デジタル証券市場参加者間の連携方法
約定・権利移転処理や法定通貨による資金決済方法の詳細定義
【2】DLTオープン化後のガバナンス・セキュリティ・秘匿化
DLTネットワーク直接参加者間の役割分担と責任範囲の明定
DLTネットワーク直接参加者によるスマートコントラクトのデプロイ
及び品質管理方法の明定
Progmatシステム全体としてのセキュリティ要件及び秘匿化要件等
の参加者間合意
【3】証券バリューチェーン変革の定量効果算定
【1】【2】詳細定義を踏まえ、既存の証券バリューチェーン(約定・照合
・清算・決済)と比較した定量的な改善効果を算出
【4】デジタル証券PTSに求められる行為規制
必要に応じて、自主規制団体及びODXによる行為規制に係る
詳細検討について、本WGにおいて側面支援を実施
（基本的には、自主規制団体及びODXによる検討に移行する想定）
3Q
4Q
1Q
2Q
3Q
4Q
セカンダリ市場の確立企業間連携効率化
4Q
1Q
2Q
FY
2020
FY
2021
FY
2022
FY
2023
セカンダリWG
(第1期)
■目指す最終形可視化
■ステップ/ハードル可視化
■各計画へ織り込み
DLT拡張WG
(第1期)
■目指す最終形可視化
■ステップ/ハードル可視化
■各計画へ織り込み
PTS提言報告書報告書
Progmat
セカンダリ・DLT拡張WG
(第2期) 4.0 PJ
(API開放)
PJ企画
ルール
メイキング
(法規制)
(自主規制)
(ODX規則)
Progmat
5.0 PJ
(DLT開放)
「ODX連携」「DLTネットワークオープン化」開始

View Slide

#01-4 第2期WGの参加者・運営概要
ST研究コンソーシアム事務局
1
デジタル証券を取り扱う
証券会社
２
デジタル証券専業の
証券会社設立予定者
３
DLT基盤/証券システム
を担うソフトウェア会社
4
法律事務所
５
WG参加者
各検討会アジェンダ設計
各検討会資料最終化
各検討会ファシリテーション
議事録作成、配信
関係者間折衝、取り纏め
座長
経済産業省
1
金融庁
２
日本銀行
３
日本証券業協会
4
一般社団法人日本STO協会
５
関係当局・ステークホルダー
随
時
報
告
適
宜
参
加
月
次
参
加
論
点
持
ち
帰
り
検
討
6ヶ月｜2021年10月~2022年03月
開催期間月次開催(全6回)｜各回原則1時間（最大2時間）
開催頻度
定期的に、参加者全員が参加する「検討会」を実施
開催方法
「ST研究コンソーシアム規程」に基づく”参加者内に閉じた”取扱いとする（情報公開は参加者全員の合意の下で実施）
秘密保持
事務局の主催するオンライン会議形式
開催形式
※第11条(秘密情報の定義)、第12条(秘密保持)、第13条(目的外使用の禁止)、第20条(権利の帰属)、第21条(協議事項)
01
社
15
社
02
社
04
社
01
社

View Slide

#02
デジタル証券市場参加者間の連携方法
#8

View Slide

#02-1① 結論｜デジタル証券市場のグランドデザイン｜Progmat完結
 証券決済は「Progmat ST」で、資金決済は「Progmat Coin」で対応する場合、デジタル証券PTSによるマッチング完了後、各市場参加者は
Progmat用Nodeを介した1本のフローでポストトレードプロセスが完結する。
 デジタル証券PTS(EN)からのST出来Txをインプットに、CN(売)がST及びSCの移転Txを生成し、ST/SCの取引関係者全員の署名の下、NNによる二
重消費検証を経て移転が確定する。(詳細な業務フロー/データフローはAppendixをご参照)
Coin
ST
EN
マッチングシステム(競売買)
取
引
シ
ス
テ
ム
バ
ッ
ク
シ
ス
テ
ム
CN
API
提
供
基
盤
AN SN
CN
取
引
シ
ス
テ
ム
バ
ッ
ク
シ
ス
テ
ム
ST原簿管理者 SC原簿管理者
tCN
NN
ST出来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

View Slide

#02-1② 結論｜デジタル証券市場のグランドデザイン｜クロスチェーン
 証券決済は「ST基盤(3rd Party)」で、資金決済は「Progmat Coin」で対応する場合、デジタル証券PTSによるマッチング完了後、各市場参加者は
Progmat用Nodeを介したSC移転のフローに加え、当該ST基盤用NodeとST移転用フローが別途必要になる。
 Progmat Coin側で、信頼できる第三者機関に依存しないクロスチェーンソリューション(＝Relayer)を提供することで、「Progmat ST」以外のST基盤
もアトミックなDVP決済が可能となり、各市場参加者はデジタル証券市場における資金決済手段を統一/効率化できる。
マッチングシステム(競売買)
取
引
シ
ス
テ
ム
バ
ッ
ク
シ
ス
テ
ム
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分)
ST出来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分)
連
携
連
携

View Slide

 第1期WG報告書で公表しているグランドデザイン「STEP2-3」では、CBDC等の外部デジタル通貨連携を前提として、DVP実現・流動性補完機能の
具備を想定していた。
 「STEP1」期間は、デジタル通貨が不在なまま、PTSマッチング開始に伴う“金商業者を跨いだ約定/決済”が発生する見込みのため、既存の法定通貨イ
ンフラを所与とした暫定的な処理方式が必要と認識し、議論を開始した。
#02-2 検討過程(10月)｜議論の出発点
4
5
6
1
2
3
FY2023 FY2024～
デジタル証券市場
拡張ステップ
STEP2-3
FY2022
DVP実現・流動性補完
STEP1
PTS連携
AsIs
デジタル通貨
(日本銀行主導 or 民間主導)
証券決済・資金決済に係る
要整備事項
セ
カ
ン
ダ
リ
決
済
セカンダリ方式
資金決済方式
金商業者内マッチング
デジタル通貨とのDVP決済
暫定期間対応案
①金商間での相対決済確認(グロス=グロス決済)
②金商間での相対決済確認(グロス=ネット決済)
③清算機関(新設)による決済照合
④原簿管理者による決済照合
PTSを利用した金商業者間マッチング
法定通貨による資金決済確認後の証券決済
実証実験・パイロット実験・開発実装・業務開始準備
大阪デジタルエクスチェンジ
(PTS)
設立・業務開始・
ST取扱開始準備(目標時期)
資金決済手段としてのデジタル通貨が不在なまま、
PTSマッチングによる金商業者を跨いだ約定/決済が
発生する見込みのため、暫定的な処理方式が必要

View Slide

#02-3 検討過程(10月)｜法定通貨決済前提の対応方針比較(当初)
 「STEP1」期間の各暫定案について、コスト・事務負荷・システム開発負荷の観点から下表のとおり相対評価をしていた。
：パターン①②はいずれも金商業者側での事務・システム面の負荷が過大であり、PTS含む金商業者間を跨いだST取引の実現性が著しく不確実
：パターン③は”車輪の再発明“感が強いうえ、暫定期間のみではST用清算機関関連コストを回収する蓋然性が低く、最も比較劣位
：パターン④では、原簿管理者兼資金決済銀行に負荷が集中するが、当座MUTBが対応することで不確実性は排除できるため、相対的に優位
案① 案② 案③
1 基
本
情
報
決済方式グロス=グロス決済グロス=ネット決済グロス=ネット決済
約定 PTS PTS PTS
照合金商業者(売) 金商業者(売) 清算機関
ネッティング(資金決済) 該当なし金商業者(売) 清算機関
2
3
4
5
6 清算機関設立・維持コスト不要不要暫定的なコストを各社負担
移転時資金決済コスト資金決済総額・手数料負担大現行水準比同等～抑制
金商業者業務(事務作業) 決済照合が追加決済照合,ネッティングが追加 Progmat2.0踏襲
7
8
5
9
評
価
観
点
Progmat追加開発金商業者間Tx回付機能のみ金商業者間Tx回付機能のみ左記①②+清算機関連携
10
12
不要
13
金商業者追加開発
11
案④
グロス=ネット決済
PTS
原簿管理者
資金決済銀行
現行水準比同等～抑制
Progmat2.0踏襲
左記①②+決済照合
不要
PTS連携のみ
コ
ス
ト
事
務
資金決済銀行側追加開発
役
割
分
担
資金決済金商業者指定の金融機関金商業者指定の金融機関金商業者指定の金融機関
(#3と同一エンティティ)
不要
現行水準比同等～抑制
シ
ス
テ
ム
金商業者業務(外部連携) PTS+各金商業者相対 PTSのみ
PTS+清算機関
PTSのみ
DVP 金商業者側責任大同一金融機関内のため容易
清算機関との連携が煩雑
金商業者側責任大
PTS連携+決済照合対応 PTS連携+決済照合,ネッティング PTS連携+清算機関連携
清算機関連携 Progmat連携対応
:比較優位
(凡例) :比較劣位/優劣無し

View Slide

#02-4 検討過程(12月)｜ステーブルコイン法制化動向と「Progmat Coin」
受益証券発行信託(合同管理の金銭信託)
「原簿管理者」(受託者)
「委託者」兼「当初受益者」兼「仲介者」(A) 「委託者」兼「当初受益者」兼「仲介者」(B)
a1
受益者
a2
b1
受益者
b2
円貨(A分)
円貨(B分)
銀行預金
受益権＝SC(a2)
”発行不所持”の受益権
受益権＝SC(a1)
受益権＝SC(b2)
受益権＝SC(b1)
1受益権＝1円のSC(配当無)
SC(a2)
SC(a1) 預り金
(a1)
(a2) SC(b2)
SC(b1) 預り金
(b1)
(b2)
③¥(SC購入)
⑤SC移転
③'¥(SC購入)
⑤'SC移転
①¥(信託) ①'¥(信託)
②SC発行
④移転
Tx
②'SC発行
④'移転
Tx
権利保全＝倒産隔離機能
((A)破綻時も償還請求可能)
Ⅱ
権利保全＝倒産隔離機能
((B)破綻時も償還請求可能)
Ⅱ
Ⅲ Ⅲ 高効率＝対抗要件デジタル完結
(対抗要件＝原簿記録＝DLT記録)
Ⅰ Ⅰ
Ⅰ
Ⅰ SC新法制準拠
(「発行者規制」「仲介者規制」)
※特許登録済
 当局を中心とした法制化動向を前広に踏襲し、ST決済に最適化した資金決済用のステーブルコイン「Progmat Coin」の検討を開始した。
 各証券会社を委託者兼当初受益者とした円貨を裏付とする受益証券発行信託を設定し、1受益権＝1円のSCとして発行後、投資家が保有する。
 証券会社毎に異なるSCとすると、証券会社を跨いだ換金対応等が煩雑化するため、複数委託者で1種類の器を想定する。
 本信託は公募となることが想定されるが、ステーブルコイン新法制適用後は金商法上の開示規制の適用外となり、業務コストを抑制できる見通し。

View Slide

#02-5 検討過程(12月)｜決済方式の比較と「Progmat Coin」主案化
 外部デジタル通貨連携開始までの暫定期間におけるメインシナリオとしてきた法定通貨決済(下図A)と比較し、「アトミック性」「決済処理速度」「実現
性」「参加手数料」の観点で、「Progmat Coin」での決済(下図B)が、比較優位であった。
 従来“最終的なToBeシナリオ”としてきたCBDC決済も、「Progmat Coin」が実装される場合は明確な優位性がなくなることから、「Progmat Coin」で
の決済をメインシナリオとして、連携方法を再考するに至った。
1 特
徴
アトミック性アトミック性担保可能な見込み
決済処理速度最遅（勘定系仕様による時点処理）最速（Tx受付次第随時）不明確（【B】よりは劣位）
2
3
6
7
8
9
10
11
実装コントロール勘定系システム側の影響有り Progmat内で完結しコントロール容易コントロール不可（外部依存）
スケジュール勘定系システム側の影響有り改正法施行し次第（23年か）
実
現
性
参
加
者
負
担
送金手数料
Node構築費用
SCカストディ費用 N/A 直接Node管理しない場合必要不明確
ST-資金決済方式グロス=ネット決済グロス=グロス決済（RTGS）不明確（おそらくRTGS）
現状の銀行送金手数料から不変 Tx移転コストは【A】よりは安い不明確
不要 Progmat Nodeのみ（差分無し）
早くとも26年以降か
2Node分必要（Progmat+CBDC）
:比較優位
(凡例)
【A】法定通貨(Fiat)決済【B】Progmat Coin決済【C】CBDC決済
(Progmat内でST/SC同時移転)
アトミック性に課題が生じる可能性有り
(CBDC側がCordaか否かの影響)
現状、グロスでのシステムリクエストや
アトミック性担保の機能無し
5 システム接続容易性基本的にProgmat内で完結するため
最も接続が容易
不明確
(CBDC側がCordaか否かの影響)
勘定系システム側の改修を伴う
可能性有り、【B】よりは劣位
(勘定系とのやりとりも【A】よりは少ない)
Node維持費用不要 Progmat Nodeのみ（差分無し） 2Node分必要（Progmat+CBDC）
流動性補完機能既存の仕組み(O/D等)有り機能拡張により検討可能不明確
4
:次善 :比較劣位/優劣無し

View Slide

 資金決済方式が法定通貨か「Progmat Coin」か、Progmat参加方式が間接(カストティアン委託)か直接か、カストディアンへの請求方式がCSVファ
イル送付かAPIかにより、実装パターンは6種類あり得ることを確認した。
 下図A列が当初整理のまま法定通貨集中決済を実施する状態で、F列(Progmat5.0で直接参加/SC利用)が最も高度化された状態を意味する。
#02-6 検討過程(12月)｜「Progmat Coin」を踏まえた連携パターン整理
Coin/直接/DLT
Coin/間接/API
Coin/間接/CSV
Fiat/直接/DLT
Fiat/間接/API
Fiat/間接/CSV
5
6
決
済
処
理
の
態
様
資金決済方式 Progmat Coin
法定通貨決済法定通貨決済
決済
(MUTB集中処理) 決済
(MUTB集中処理)
Progmat Coin
1
CSVを基にカストディ PTSからの情報を基に
CSVを基にカストディ PTSからの情報を基に
アンがTx生成オペ
アンがTx生成オペ金商完結で自動処理
金商完結で自動処理
7
8
移転請求方式カストディアンへ
カストディアンへカストディアンへ
CSV送付し依頼
CSV送付し依頼
(証券) APIで指図
APIで指図
カストディアンへ
Progmatへの間接参加間接参加
(カストディアン委託)
参加方式 (カストディアン委託)
法定通貨決済
(MUTB集中処理) 決済
Progmat Coin
間接参加
間接参加
直接参加
(Custody Node)
間接参加間接参加
(カストディアン委託) (カストディアン委託)
間接参加
間接参加
直接参加
(Custody Node)
Custody Nodeから
移転請求Tx生成
Custody Nodeから
金商-カストディアン間
APIでTx自動生成
移転請求Txを基に
自動処理
自動処理
自動処理
自動処理
自動処理
自動処理
ST側処理をトリガー
に自動処理
自動処理
自動処理
CSVを基にカストディ
アンがTx生成オペ
自動処理
CSV送付 ST側処理をトリガー
(移転請求Tx無し) に自動処理
API連携
(移転請求Tx無し)
請求内容ネッティング
後、勘定系で処理
移転請求方式カストディアン(SC)へ
資金決済銀行へ
CSV送付し依頼
CSV送付し依頼
(資金) APIで指図
カストディアン(SC)へ Custody Nodeから
資金決済銀行へ
APIで指図
Custody Nodeから
2
3
4
前
提
情
報
:最も高度化
(凡例) :次善 :比較劣位/優劣無し
F
E
D
C
B
A
証券
決済
資金
決済
移転
請求
移転
移転
請求
移転

View Slide

 Progmat Coin導入に際してNode参加(直接管理)必須となると利用ハードルが高くなってしまうことから、現状のSTと同様、SC管理についてもカスト
ディアンへ委託する方式(前頁の列D・E)を想定しており、Node参加の準備が整った先から直接管理型へ移行する想定であることを明示した。
 Progmat Coin非導入先は「法定通貨(非集中処理)」しか手段がないため、金商業者跨ぎ取引が発生した場合、相対決済完了後にSTを移転する。
1
2
【C】
【B】
【A】
前
提
Progmatへの間接参加
(カストディアン委託(CSV))
間接参加
(カストディアン委託(API))
直接参加
(Custodian Node(ST/SC))
態
様
証券決済
カストディアンへのCSV送付、及び指図カストディアン(ST)へのAPIでの指図 Custodian Node(ST)からTx生成
参加方式
ST-資金決済方式グロス=ネット決済グロス=グロス決済(RTGS)
STマッチング方式金商業者内マッチング PTSによる金商業者間マッチング PTSによる金商業者間マッチング
証券会社への売買注文証券会社への売買注文証券会社への売買注文
投資家
金商業者
CSV受領後、カストディアンによるTx生成 APIによるTx自動生成金商完結で自動処理
Progmat
資金決済
資金決済銀行への振込指図カストディアン(SC)へのAPIでの指図 Custodian Node(SC)からTx生成
証券会社への法定通貨支払証券会社への法定通貨支払証券会社(仲介機関)経由でSC取得
投資家
金商業者
N/A APIによるTx自動生成金商完結で自動処理
Progmat
資金決済銀行による決済処理 Progmat Coin決済処理 Progmat Coin決済処理
決済機関
3
4
5
6
7
8
9
10
グロス=グロス決済(RTGS)
Progmat Coin(直接管理)決済
Progmat Coin(カストディ)決済
法定通貨決済(非集中/相対)
#02-7 検討過程(1月)｜連携方式の段階的なアプローチ

View Slide

#02-8 検討過程(2月)｜PTS-金商業者間の連携方式
 Progmat Coinの利用を前提に、PTSと金商業者間の出来通知に係る連携方式を2パターン想定し、下表【C】「Node保有/DLT連携」を主案とした。
 既存の上場株式において構築された専用線を転用する方式はPTS側の対応負荷が少ないものの、CSV形式で受領した出来情報から移転Txを生成す
る機能や照合機能を金商業者毎に開発することとなり、ネットワーク全体のリスクポイントや対応コストが膨らむことになる。
 PTSも「Exchange Node(EN)」を保持しProgmatに直接参加する方式では、マッチングシステムとENの連携さえ担保すれば、上記対応は不要となる。
出来通知連携先
1
連携内容
4
証券決済
5
照合処理
6
連携方式
2
連携フォーマット
3
前
提
【C】Node保有/DLT連携
同左
出来Txを基にCN(売)が移転Tx生成
不要
DLT連携(EN→CN×2)
DLT上のTx
【B】Node非保有/専用線転用
【A】専用線連携
既存の上場株式PTS
金商業者(売買双方)
JSCC、金商業者(売買双方)
専用線を用いたファイル送付による連携
専用線を用いたファイル送付による連携
CSV CSV
株式の出来情報 STの出来情報同左
出来CSVを基にJSCCにて処理出来CSVを基にCN(売)が移転Tx生成
不要 CN(買)で照合が必要
資金決済
7
エラー発生のリスクポイント
8 比較対象外
システム実装負荷（金商業者）
9 比較対象外
システム実装負荷（PTS）
10 比較対象外
処
理
の
態
様
評
価
JSCC,金商各社からの指図を基に
日銀での資金決済処理
出来CSVを基にCN(売)が移転Tx生成
し、Progmat CoinとDVP決済処理
CN(売)が出来CSVを基に移転Txを
生成する際のプログラムバグ(×金商数)
①出来CSVからの移転Tx生成機能
②出来CSVと移転Txの照合機能
既存のPTS-金商業者間の専用線を
転用することで、追加対応範囲は軽微
ENがPTSマッチング結果を基に出来Tx
を生成する際のプログラムバグ
出来Txを基にProgmat内で自動処理
されるため、金商毎の追加実装不要
①EN運用コスト負担方法【残論点1】
②マッチングシステムとENの連携機能
:比較優位
(凡例) :比較劣位/優劣無し
*1
*1 Exchange Node｜マッチングシステムからのデータ連携をinputに出来TxをCN(売)・CN(買)宛てに回付する機能のみ有するNode
出来Txを基にCN(売)が移転Tx生成
し、Progmat CoinとDVP決済処理
*2
*2 PTS接続料へ転嫁も検討

View Slide

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

View Slide

#03
DLTオープン化後のガバナンス・セキュリティ・秘匿化
#19

View Slide

#03-1 システム構成
 前提として、Progmatは「the Corda Network(tCN)」を基にBusiness Network(同一ビジネスを行う企業群ネットワーク)として形成する。
 Nodeの保持、自社システム組込や周辺機能開発等を行うネットワーク参加者を「Service Developer(以下、Service Dev)」、「Service Dev」の
提供するAPIを利用する間接的なネットワーク参加者を「API User」と定義し、「Service Dev」の役割別のProgmat用パッケージを用意する。
 「Service Dev」がネットワークに参加するためのProgmatのパッケージは、「Core Developer(以下、Core Dev)」が提供する。
金商業者(直接管理)
【Service Developer】
金商業者(カストディ委託)
【API User】
各種原簿管理者 / カストディアン
社内外向けUI 社内外向けUI 社内外向けUI
社内外向けUI
各社内システム各社内システム各社内システム
マッチングシステム
WebAP
Custodian Node
Corda Firewall
WebAP
Exchange Node
Corda Firewall
WebAP
Asset Node
Corda Firewall
API提供
インフラ
SC Node
Custodian Node
(専用線) (専用線)
(API)
NW管理サーバ接続エンドポイント Nortary接続エンドポイント tCN
【凡例】
:API/専用線連携 :DLT連携(Progmat ST/SC)
:原簿管理者/カストディアン
向けパッケージ提供範囲
:金商業者(直接管理)
:デジタル証券PTS
*1 *1 *1
*1 サーバ/OS/DB/コンテナエンジン等は
パッケージ化せず、各社で構築

View Slide

#03-2① ガバナンス方式｜分権的運営（デジタルアセット共創コンソーシアム）
 22年4月に改組する「デジタルアセット共創コンソーシアム」(以下、DCC)を、Progmat5.0対応(DLTオープン化)をトリガーに分権的運営に移行し、
Progmat揺籃期のMUTB集中管理体制からガバナンスの在り方を高度化する。
 Node運営を担う「Partner Members」は「Core Dev」と「Service Dev」に分かれ、責任範囲を明確にしたうえで開発を推進する。(分担は次頁)
 守秘義務を要しない開発提案はオープンに受付可能とし、開発提案の採択等重要な決定はDCC全会員による投票プロセスを経ることを想定する。
DCC関係エンティティ各エンティティの特徴
DCC
Partner Members｜Node運営
Core Developer
1
Service Developer
2
General Members｜Node非保有
API User
3
Discussant
4
5
DCC
事
務
局
一般開発者
6 一般利用者
7
2
3
1
4
5
6
7
一般開発者
Core
一般利用者
Service
Developer
API User
DCC事務局
Discussant
BNO 非保有非接続権利有無制限
Spon 保有接続権利有無制限
sees
ネットワーク Node API 投票権提案・WG
運営役割保有接続・資料閲覧
非関与非保有接続権利有無制限
非関与非保有非接続権利有無制限
非関与非保有非接続取り纏め取り纏め
(権利無)
非関与非保有非接続権利無制限有
(提案可)
非関与非保有非接続権利無制限有
(提案可)
*1
*2
*1
*2
Bussiness Network Operator｜Business Networkを構築・運用し、障害時の1次窓口の役割を担う
各自保有するNodeの管理責任を負い、Node障害時はBNOに問い合わせを実施する
Developer

View Slide

#03-2② ガバナンス方式｜責任分界/役割分担のアウトライン
 前提として、Progmatは「the Corda Network(tCN)」を利用することから、ネットワーク構成管理やNortary Node運用は非営利団体である
「Corda Network Foundation(the Foundation)」が行うため、「Core Dev」への集権が不要となる。
 「Core Dev」はProgmatの共通仕様/機能やパッケージアプリの開発を推進するが、Node別の固有機能や顧客向けサービス開発は原則関与しない。
 「Service Dev」は、各保有Nodeに関連する固有機能の開発や他の参加者向け提供、社内外向けインターフェイスの開発を主体的に推進する。
1
2
3
4
5
Web/Mobile
Apps
Progmat Networkに参加
する各エンティティが提供する
社内外向けインターフェイス
ST･SC･UT
the Corda
Network
(tCN)
Nortary Node
Progmat
Service Dapps
Progmat Networkに参加
するNode別に有する機能
(マッチング結果取込,出来照合等)
Progmat
Core Dapps
Progmat Network内での
共通仕様/機能/パッケージ
(ID体系,データ構造等)
Nortary Node
(Non-validating
トランザクションの二重消費
検証を行うNode
the Corda
Network
Progmat Networkを含む、
各Nodeが接続するCorda
Network全体
Progmatの関連コンポーネント
A
コンポーネントの概要
B
既存UI組込,顧客
向けサービス開発
(適宜パッケージ利用)
Service Developer
C
自社向け開発,
適宜他の参加者向け
にライセンス提供
非関与
(ライセンスフィ支払の
うえ利用するのみ)
非保有/非関与
各自保有するNode
の管理責任
(UI、Service)
(Cordapps)
(Cordapps)
Nortary)
(tCN)
パッケージアプリ提供
(Token Manager,
Token Wallet）
Core Developer
D
原則、非関与
(適宜Service Dev
の開発を支援)
開発推進のうえ
Service Dev向けに
ライセンス提供
非保有/非関与
Progmat NW内の
全Nodeの動作責任、
障害時1次窓口
非保有/非関与
the Foundation
E
非保有/非関与
非保有/非関与
Node運用
全Networkの構成
管理、障害時の原因
究明とCorda復旧
*1
*1 Corda Network Foundation｜Corda Networkに参加するNodeの投票により選任された9名、R3社により任命された2名の計11名のBoard Memberが運営を行う非営利団体（Corda設定等はR3に委託）

View Slide

#03-2③ ガバナンス方式｜論点別の責任分界/役割分担定義
秘密鍵の管理責任 Service Devへ秘密鍵
生成・管理手順を連携
3
自社/発行体の
秘密鍵生成・流出防止
自社/委託元/投資家の
自社/投資家の
トランザクションデータのデータフローの設計と
パッケージ提供(非保持)
4
自社発行トークンのTx,
障害復旧用バックアップ
顧客預りトークンのTx,
顧客預りトークンのTx,
Service DevとのAPI
利用契約の範囲で参照
データ参照機能の設計と
パッケージ提供(非参照)
5
パッケージ利用,パッケージ
外連携機能設計・運用
同左同左 Service DevとのAPI
利用契約の範囲で参照
データ保護措置の設計と
パッケージ提供(非保持)
6
自社内データに対する
保護措置の運用
同左同左 API取得データに対する
保護措置の運用
パッケージ(Core Dapps)
配布(Node非保持)
7
ｅｒｖｉ
配布PGMの取込・運用,
Service Dapps配布
同左同左対象外
(Node非保持)
パッケージ(Core Dapps)
ライセンス保有
8
自社開発分のService
Dappsライセンス保有
(Node非保持)
全Service Devに対し
KYC/SC
9
Core Dev+金商業者
のKYC/SC
Core DevのKYC/SC Core Dev+原簿管理
者のKYC/SC
API提供者のKYC/SC
対象外
(知り得ない)
10
委託者のKYC/SC、
他関係者と投資家のSC
金商業者(カストディ委託
)のKYC/SC
委託者+投資家の
KYC/SC
委託者+投資家の
KYC/SC
Core Developer Service Developer
原簿管理者カストディアン金商業者(直接管理)
API User
金商業者(カストディ委託)
アクセス範囲と管理
オフチェーンデータ参照
処理の管理
個人情報等の高秘匿
性データの取扱
スマートコントラクトの
配布・変更等の管理
対象外
(Node非保持)
Service Devのサーバ
スペック,NW構成等指定
1
サーバ/NWの設計･構築
・運用(含セキュリティ更新等)
(Node非保持)
障害時の対応責任障害時1次窓口,
パッケージ起因箇所修正
2
自社構築箇所の障害
検知,原因切り分け,復旧
同左同左同左
DLT上のPGMに係る
知的財産権帰属
AML/CFT対応
(対NW運営者)
AML/CFT対応
(対NW運営者以外)
システム構築・運用
(パッケージ部分)
*2
*1 Service Devのうち、デジタル証券PTSに係る分担は別途定義
*1
*2 KYC=Know your Customer、SC＝Screening

View Slide

#03-2④ ガバナンス方式｜プログラム開発プロセス
 パーミッションレス型DLTにおけるオープン/フラットな開発プロセスに準じ、Progmatの関連コンポーネント(具体構成は前頁)に対する開発提案は誰でも
可能とし、提案内容一式は常にWeb上で公開される運営を想定。
 実装プロセスに移行する前に、DCC全体の会員投票により提案採択可否を評価し、採択されたもののみ具体検討に移行する。
 影響を受ける関係者間で合意に至った場合、各コンポーネントに責任を有する「Core Dev」「Service Dev」で開発を行い、開発後PGMを公開する。
2
3
1
4
5
6 一般開発者
Core
一般利用者
Service
Developer
API User
DCC事務局
Discussant
開発提案作成
A
提案採択投票
B
検討・承認
C
開発・テスト
D
展開・実装
E
開発
提案書
・開発提案書は
・誰でも提案可能
・開発提案書一式は
・Web上で公開
・開発提案書採択は
・DCC全体で評価
・賛成票が一定の
・割合を超える場合、
・実装対象として
・具体検討に移行
開発
提案書
・影響を受ける関係者
・で、スコープ/期間/
・コスト負担を協議
・合意完了後、開発に
・移行(もしくは却下)
✔ ・Core Dapps/
・パッケージの開発
・Service Dapps/
・UIの開発
・アプリケーションへの
・接続テスト
・開発後PGMを
・GitHub等を介して
・公開・配布
・各Node保有者が
・実装オペ
・リリース内容確認
・(途中で却下/中断
・した場合はその旨)
*1
*1 Cordaの場合、Ethereum等と異なり、PGM群の各Nodeへの配布/実装ではなく、各Nodeにて実装オペレーションを行う方式
Developer

View Slide

#03-3 秘密鍵管理
秘密鍵管理に係る論点検討経緯/結論
前
提
①ProgmatはPermission型DLTのプラットフォーム
DLTへの書き込みはDCCに参加しNode保有が許可された企業のみ。
Permissionless型と異なり、万が一流出が発生したとしても移転先は
③不正移転時の「強制移転」機能有り
Progmatでは、トークン毎の各原簿管理者Nodeが「強制移転」機能
を有するため、万が一不正移転が発生したとしても取り戻しが可能。
論
点
・各Service DevによるHSM実装要否
Progmat上でTxに署名するための秘密鍵について、その管理方法
としてHSM等の実装要否を含めて検討するもの。
結論
・左記前提により、万が一不正移転が発生したとしても投資家が実際に
被害を被る蓋然性は極めて低い一方、HSMの実装負担は投資家の
秘密鍵管理責任を持つService Dev毎に必要となることから、
・Progmat全体の方針として、HSM利用は必須としないことで合意。
限定的で、誰が書き込んだかを具体的にトレースすることが可能。
②秘密鍵のみの流出では不正移転不可
秘密鍵が万一流出したとしても、それだけでは不正移転することは
出来ず、移転処理が可能なService DevのNW/Nodeへ侵入のうえ
移転に必要な複数の要素を盗み取る必要がある。
Progmatの現行バージョンでは、HSMは利用せず、複数の要素を
用いて秘密鍵を暗号化しており、更なる流出対策が妥当かを判断する。リスク量(導入効果)に比して過剰感が強い(コスト割高)との結論。
AN
ST原簿管理者
攻撃者
CN
金商業者C
CN
金商業者B
CN
金商業者A
特定可能なNW参加Node
以外のNodeへ移転不可
内部流出でも秘密鍵が
利用可能なNodeへの
侵入なしに利用不可
不正移転元/先を検知し、
強制移転機能で取り戻し可
AN :Asset Node
CN :Custodian Node
:秘密鍵
攻撃者
【内部流出防止】
【外部流出防止】
【凡例】
*1
*1 HSM=Hardware Security Module｜秘密鍵を安全に保管・演算をするためのハードウェア

View Slide

#03-4 秘匿化
DLTにおける秘匿化論点検討経緯/結論
前
提
②直接繋がりのない取引情報は共有されない
A C
Txデータは、取引に関係するNode間でのみ共有される仕様。
B D
共有範囲
①投資家はネットワークに直接参加しない
各STを取り扱う金商業者名等は公募に際して公開済のため、関係Node
保有者情報は公知情報。（Nodeの単位は金商業者単位、Not投資家）
論
点
・移転先Nodeから、移転元Nodeの過去取引の一部が参照可
Cordaのトランザクションモデルの仕様上、トークンの移転に際して過去の
トランザクションの繋がりを検証する必要があることから、移転元の直近の
過去取引情報が移転先から確認可能である点の是非を検討するもの。
A 100 A 40
B 60 B 10
C 50
Bに60移転
Cに50移転
CはBから移転された60に係る取引履歴参照が可能
・追加的な秘匿化機能(「ReissuingState」)は、移転の都度Txの
発行・償還を行うことで過去Txの取得が不要となるものだが、その分多く
の署名を必要とし、性能低下/コスト増加が懸念されるため、不採用
結論
・左記前提により、取引情報は関係当事者のみに共有範囲が限定され、
投資家の詳細情報は共有されないため、必要十分な秘匿性を担保
できていることから、追加的な秘匿化機能の実装までは不要との結論。
との方針で各社と合意。
③共有されうるデータ
自社関連取引と、その直近の過去取引に関する以下の情報(のみ)。
A)移転元/先情報(Progmat固有ID、Cordaのアドレス等)
B)取引時点の移転元の保有残高(総額か否かは分かり得ない)
C)移転額
D)取引日時
④共有されないデータ
以下はオフチェーン管理、IDと属性の紐づけは関係当事者のみ可能。
A)投資家名称はTxによって共有されない
B)住所/連絡先等の属性情報はTxによって共有されない
⇒直近取引に繋がる直近の過去取引のみが対象で、
それがBCの保有総額か否かは分かり得ない
⇒関係当事者以外は、Bが誰であるかは不明

View Slide

#04
証券バリューチェーン変革の定量効果算定
#27

View Slide

#04-1 定量効果試算の方向性
3 事務コスト(ST残高照合)
単位コスト
×661円
(人件費×単位時間/プロセス)
7
5
8
1
2
6
4
9
(カストディレポート照合オペ)
事務コスト(投資家登録・更新)
(登録ファイル作成/送付オペ)
事務コスト(移転情報指図)
(移転ファイル作成/送付オペ)
事務コスト(決済確認・振込)
(跨ぎ取引時の金額確認/送金オペ)
カストディフィ(ST預り)
(セキュリティ確保/リスク相当分)
カストディフィ(残高報告)
(カストディレポート作成/送付)
カストディフィ(投資家登録)
(登録ファイル確認/登録)
カストディティ(移転登録)
(移転ファイル確認/登録)
振込手数料
事務/外部委託コスト
AsIs ToBe(効果)
営業日
営業日
営業日
営業日
ST残高
営業日
営業日
移転件数
決済件数
×20bp
×5bp
×660円
変数
×1,984円
×1,323円
×19,625円
0円
(オペ不要)
0円
(オペ不要)
0円
(オペ不要)
0円
(オペ不要)
0円
(委託不要)
0円
(委託不要)
0円
(都度振込不要)
単位コスト(仮置き)
ToBe(対応する必要コスト)
決済件数
年
営業日
移転件数
変数
×15百万円
(CNライセンスフィ(固定))
(カストディフィ(ST預り)に内包) 0円
(委託不要)
0円
(委託不要)
(カストディフィ(ST預り)に内包)
×100円
(CNライセンスフィ(ST移転課金))
×500円
(API利用料(投資家登録))
×100円
(SCライセンスフィ(SC移転課金))
想定トータルコスト【X】
B C
A E
D
効率化効果【Y=X】必要コスト【Z】
▲ +
ネット効率化効果＝
残
高
管
理
ST
移
転
投
資
家
管
理
資
金
決
済
×100円
(API利用料(投資家ID参照))
×0百万円
(SCライセンスフィ(固定)
(CNライセンスフィ(固定)に内包))
*1
*1 単位コストは、定量効果を算定するにあたってST取扱残高等の諸条件と共に設定した仮置きの数値(以降、同様)

View Slide

#04-2① 結論｜金商業者1社あたり単年効率化効果
119.8 19.6 ▲100.2
▲4.8
4.8 0.0
7.1 2.3 ▲4.8
2.3 2.3 ▲0.0
▲1.0
1.0 0.1 ▲0.9
0.0 0.1 +0.1
1.0 0.0
▲0.3
11.6 2.3 ▲9.3
11.3 2.3 ▲9.0
0.3 0.0
0.2 0.0 ▲0.2
100.0 15.0 ▲85.0
100.2 15.0 ▲85.2
A B C
AsIs
1
13
効率化効果
外部委託/利用コスト
事務コスト
事務コスト
事務コスト
事務コスト
残高管理
総計
2
3
4
5
6
7
8
9
10
11
12
0.0
50.0
100.0
119.8
19.6
ネット効率化効果
AsIs ToBe(想定)
▲100
▲84
( )
%
百万円
前提
条件
・金商業者1社あたりのST取扱残高500億円
・ST移転件数22,500件(Primary/Secondary合算)
・新規ST保有投資家数12,500人(1人1口1百万円)
・資金決済件数22,500件(グロス=グロス想定)
(単位：百万円)
年間
ST移転
投資家管理
資金決済
【コスト:百万円】
(想定)
ToBe

View Slide

#04-2② 結論｜業界全体の単年効率化効果
106.1
34.0
14.6 0.0 ▲14.6
0.0 1.8 +1.8
4.9 0.0 ▲4.9
14.6 1.8 ▲12.8
173.7 33.8 ▲139.9
168.8 33.8 ▲135.0
1,500.0 225.0 ▲1,275.0
2.4 0.0 ▲2.4
1,502.4 225.0 ▲1,277.4
1,796.8 294.4 ▲1,502.4
A B C
72.1 0.0 ▲72.1
33.8 ▲72.3
33.8 ▲0.2
AsIs
1
効率化効果
事務コスト
事務コスト
事務コスト
事務コスト
残高管理
2
3
4
5
6
7
8
9
10
11
12
0.0
500.0
1,000.0
1,500.0
2,000.0
1,796.8
294.3
▲1,502
▲84
( )
%
百万円
前提
条件 (単位：百万円)
年間
ST移転
投資家管理
資金決済
・1社あたりのネット効率化効果を本WG参加金商業者
15社分乗算し、業界のネット効率化効果として試算
・業界全体のST取扱残高7,500億円
・ST移転件数337,500件(Primary/Secondary合算)
・新規ST保有投資家数187,500人(1人1口1百万円)
・資金決済件数337,500件(グロス=グロス想定)
13 総計
AsIs ToBe(想定)
(想定)
ToBe

View Slide

#04-3① プロセス別試算詳細｜残高管理｜業務プロセス比較
AsIs ToBe
Ⅰ
ⅰ
金商業者
Progmat
金商業者
Progmat
カストディレポート
作成
移転情報
CN(カストディアン)
ⅱ
残高情報
CN(金商業者)
Ⅱ
業務概要
ⅰ カストディアンがProgmatより、
ST残高情報をダウンロード
カストディレポートを作成の上、
ⅱ
金商業者は、カストディアンより
Ⅰ
カストディレポート
交付
金商業者に交付
交付されたカストディアンレポート
と、各社で認識しているSTの
残高を照合し確認
Ⅱ 金商業者にて、Progmat上の
残高情報を直接参照
金商業者がNodeを保有し、
自身でカストディ業務実施する
【金商側削減対象】
1プロセス
ST残高照合
ため、当該業務削減
【凡例】：手作業：システム処理
：業務削減対象
：業務改善対象
残高情報
・残高更新
残高照合・
自動処理残高更新

View Slide

#04-3② プロセス別試算詳細｜残高管理｜試算結果
カストディフィ
AsIs ToBe(想定)
ST取扱残高
500
億円
手数料率
20
bp
100.0
百万円
営業日数
245
日
人件費(/処理)
661
円
0.2
百万円
100.2
百万円
期間
年
ライセンスフィ
15
百万円
1 15.0
百万円
15.0
百万円
▲85.2
百万円
+15.0
百万円
必要コスト
▲0.2
百万円
削減
▲100.0
百万円
削減
(ST預り)
事務コスト
(ST残高照合)
CN
総計
1
2
3
4
(固定)
*1
*1 金商業者1社あたりのST取扱残高を最大500億として試算
*2
*3
*2
A B C
0.0
百万円
0.0
百万円
【作業者人件費：1処理あたり処理時間(15分)×単価＠h(2.24千円)】+【検印者人件費：1処理あたり処理時間(1.5分)単価＠h(4.08千円)】
Cordaに係るネットワーク維持管理等のため、15百万円/年を収受
*3
削減効果
年間
上記単価はMUTBの管理会計上の年給与[作業者単価]4.3M/年、[検印者単価]7.8M/年)を時間単価に換算(以降、同様)

View Slide

#04-3③ プロセス別試算詳細｜残高管理｜シミュレーション
15.0 15.0
85.2
400.0 500.0
100.2
80.2
▲15.0 5.2 25.2 45.2 65.2
0.0
15.0
100.0 200.0 300.0
15.0 15.0 15.0
0.0 20.2 40.2 60.2
0.0
50.0
100.0
0 100 200 300 400 500
[AsIs]
[ToBe]
【ST残高:億円】
【損益分岐点】
約74.4
億円
最大▲85.2
百万円
年間
AsIsコスト
ToBeコスト(想定)
2
3
4
百万
百万
百万
ST取扱残高
1 億円

View Slide

AsIs ToBe
直接登録
Ⅰ
金商業者
Progmat
金商業者
Progmat
移転情報ファイル
移転情報更新
CN(カストディアン)
移転情報
(自動連携)
移転情報登録
CN(金商業者)
業務概要
ⅰ
金商業者にて移転情報ファイルを
作成し、カストディアンへ送付
ST移転処理完了後、ANにて、
Ⅰ
Ⅱ 金商業者からCNにST移転情報
が自動連携され、移転処理実行
移転情報登録
移転情報
Ⅱ
ⅰ
移転情報に基づき、カストディアン
が移転情報を登録
原簿情報更新
AN(原簿管理者)
移転情報記録
AN(原簿管理者)
移転情報を記録
ファイル作成・送付
受領・確認
1プロセス
ⅱ
ⅱ
金商業者がNodeを保有し、
自身でカストディ業務実施する
ため、当該業務削減
自動処理
取引の都度、自動で
作成され、CNに連携
#04-4① プロセス別試算詳細｜ST移転｜業務プロセス比較

View Slide

#04-4② プロセス別試算詳細｜ST移転｜試算結果
カストディフィ
AsIs ToBe(想定)
移転金額
225
億円
手数料率
5
bp
11.3
百万円
営業日数
245
日
人件費(/処理)
1,323
円
0.3
百万円
11.6
百万円
移転件数
件
100
円
22,500 2.3
百万円
2.3
百万円
▲9.3
百万円
+2.3
百万円
必要コスト
▲0.3
百万円
削減
▲11.3
百万円
削減
(移転登録)
事務コスト
(移転指図)
CN
総計
1
2
3
4
(ST移転課金)
*1
*1 ST取扱残高500億円時、Primary移転金額125億、Secondary移転金額100億(回転率20%)と仮定
*2
*3
*4
*2
A B C
0.0
百万円
0.0
百万円
1日1回纏めての処理
から取引の都度処理へ
【作業者人件費：1処理あたり処理時間(30分)×単価＠h(2.24千円)】+【検印者人件費：1処理あたり処理時間(3分)単価＠h(4.08千円)】
*3
1口あたり100万円とし、1口単位で流通すると仮定して試算
*4
CN利用において、Tx署名処理の都度R3社からの課金が発生するため、ライセンスフィを収受
削減効果
年間

View Slide

#04-4③ プロセス別試算詳細｜ST移転｜シミュレーション
2.3
9.3
22,500.0
11.6
18,000.0
0.0 2.6 4.8 7.1 9.3
1.8
0.0
0.0 2.1 3.9 5.7 7.5
0.5 0.9 1.4
0.0 4,500.0 9,000.0 13,500.0
0.0
5.0
10.0
0 4,500 9,000 13,500 18,000 22,500
[AsIs]
[ToBe]
【ST移転件数:件】
最大 ▲9.3
百万円
AsIsコスト
2
3
4
百万
百万
百万
ST移転件数
1 件
年間

View Slide

AsIs ToBe
自動連携
Ⅰ
金商業者
Progmat
マスタ情報登録
CN(金商業者)
業務概要
ⅰ 金商業者からカストディアンに、
登録する投資家情報を送付
Ⅱ
金商業者はAPIを用いて、ANに
格納されている投資家IDを参照
Ⅰ 金商業者からCNに投資家情報
を直接登録し、ANにてマスタ情報
原簿管理者
投資家情報
ファイル作成
投資家情報
ファイル受領
投資家情報
確認
投資家情報
連携
マスタ情報
登録
マスタ情報登録
AN(原簿管理者)
カストディアンから原簿管理者に、
投資家情報を連携
原簿管理者が投資家情報を
金商業者
Progmat
原簿管理者
Progmatへ登録
ⅰ
マスタ情報更新
AN(原簿管理者)
マスタ情報
完了連絡
投資家ID
連携
投資家ID
確認・登録
API連携
2プロセス
・送付
ⅱ
APIにて参照
ⅱ
カストディアンから金商業者に、
投資家IDを送付
金商業者は自社システムに
受領した投資家IDを登録
を自動更新
投資家情報
投資家情報
投資家ID
投資家ID
更新の都度
投資家ID
参照・連携
Ⅱ
自動処理
#04-5① プロセス別試算詳細｜投資家管理｜業務プロセス比較

View Slide

#04-5② プロセス別試算詳細｜投資家管理｜試算結果
AsIs ToBe(想定)
営業日数
245
日
人件費(/処理)
3,306
円
0.8
百万円
営業日数
245
日
人件費(/処理)
661
円
0.2
百万円
1.0
百万円
営業日数
日
API利用料(/回)
500
円
245 0.1
百万円
0.1
百万円
▲0.9
百万円
+0.1
百万円
必要コスト
▲0.2
百万円
削減
▲0.8
百万円
削減
事務コスト
(投資家登録・
事務コスト
(投資家ID
API利用料
(投資家登録)
総計
1
2
3
4
5
*1
*2
A B C
更新指図)
登録)
0.0
百万円
0.0
百万円
*1 【作業者人件費：1処理あたり処理時間(75分)×単価＠h(2.24千円)】+【検印者人件費：1処理あたり処理時間(7.5分)単価＠h(4.08千円)】
*2 【作業者人件費：1処理あたり処理時間(15分)×単価＠h(2.24千円)】+【検印者人件費：1処理あたり処理時間(1.5分)単価＠h(4.08千円)】
API利用料
(投資家ID
参照)
営業日数
日
API利用料(/回)
100
円
245 0.0
百万円
+0.0
百万円
必要コスト
*4
*4 試算額が24,500円と少額ため、上記表の小数点の関係から0.0表記
*3
削減効果
年間
*3 AsIsの投資家登録に係る外部委託コストはカストディフィ(ST預り)に内包

View Slide

#04-5③ プロセス別試算詳細｜投資家管理｜シミュレーション
0.1
0.9
12,500.0
1.0
10,000.0
0.0 1.0 1.0 1.0 1.0
0.1
0.0
0.0 0.9 0.9 0.9 0.9
0.1 0.1 0.1
0.0 2,500.0 5,000.0 7,500.0
0.0
0.5
1.0
0 2,500 5,000 7,500 10,000 12,500
[AsIs]
[ToBe]
【新規投資家数:人】
AsIsコスト
2
3
4
百万
百万
百万
新規投資家数
1 人
最大 ▲0.9
百万円
年間

View Slide

AsIs ToBe
【買】
資金決済銀行
Progmat
移転情報
CN(金商業者)
業務概要
ⅰ 【買】金商業者にて金商毎での
決済金額を確認・計算の上、
Ⅱ
金商業者からCNにSC移転情報
が自動連携され、移転処理実行
Ⅰ 当該業務削減
資金決済銀行
【買】
Progmat
ⅱ
資金決済銀行は、振込手続きを
Ⅱ
行い、【買】金商業者へ振込完了
移転情報記録
SC発行者Node
SC移転処理完了後、SC発行者
Nodeにて移転情報を記録
3プロセス
【振込元】
【振込先】
振込指図
受領
振込手続
資金受領
SC発行者
SC移転
情報
ⅱ
振込指図
PTSからの出来通知の都度、
自動で作成され、CNに連携
Ⅰ
自動処理
振込完了
確認
振込完了
連絡
移転結果取込
CN(金商業者)
SC移転
結果確認
連絡を実施
金商業者
金商業者
決済金額
確認
金商間
送金金額
計算
宛先毎
ⅰ
自動処理
送金金額を確定
資金決済銀行へ各金商毎での
振込指図を実施
#04-6① プロセス別試算詳細｜資金決済｜業務プロセス比較

View Slide

#04-6② プロセス別試算詳細｜資金決済｜試算結果
振込
AsIs ToBe(想定)
削減効果
決済件数
3,430
件
振込手数料
660
円
2.3
百万円
営業日数
245
日
人件費(/処理)
19,626
円
4.8
百万円
7.1
百万円
決済件数
件
100
円
22,500 2.3
百万円
2.3
百万円
▲4.8
百万円
+2.3
百万円
必要コスト
▲4.8
百万円
削減
▲2.3
百万円
削減
手数料
事務コスト
(決済金額確認
SC
総計
1
2
3
5
(SC移転課金)
*1
*1 営業日数[245日]×振込先数[14社](金商業者最大14社に資金決済すると仮定) *2 三菱UFJ銀行の他行宛の振込手数料にて試算
*3
*2
*3
A B C
0.0
百万円
0.0
百万円
1日1回纏めての処理
から取引都度の処理へ
【作業者人件費：1処理あたり処理時間(32分)×14社分×単価＠h(2.24千円)】+【検印者人件費：1処理あたり処理時間(3.2分)単価＠h(4.08千円)】
年間
期間
年
0
円
1 0.0
百万円
0.0
百万円
必要コスト
SC
4
(固定)
*4
*4 SCライセンスフィについては、STのCNライセンスフィ(固定)に内包
[処理時間内訳：金商間決済金額確認(20分)、宛先毎送金金額計算(10分)、振込指図(2分)]
～振込指図)

View Slide

#04-6③ プロセス別試算詳細｜資金決済｜シミュレーション
0.0 0.5 0.9 1.4 1.8 2.3
7.1 7.1 7.1
5.7 5.3 4.8
9,000.0 13,500.0 18,000.0 22,500.0
0.0 4,500.0
0.0 7.1 7.1
0.0 6.6 6.2
AsIsコスト
2
3
4
0.0
5.0
0 4,500 9,000 13,500 18,000 22,500
[AsIs]
[ToBe]
【決済件数:件】
百万
百万
百万
決済件数
1 件
【損益分岐点】
71,000
決済件数=
(ST取扱残高約1,600億)
件
▲4.8
百万円
年間
▲6.6 ～将来的なライセンスフィは
今後調整

View Slide

#05
ネクストアクション
#43

View Slide

#05 ネクストアクション
 Progmat基盤拡張は、直近の各種検討結果や外部動向を踏まえ、FY2022/12月にAPIオープン化、FY2023中のDLTオープン化を目標とする。
 セカンダリは、ODXによるST取扱開始目標のFY2023からPTS方式が可能になる点は不変、FY2023以降にP2P方式に係る検討/開発も着手予定。
 資金決済は、SC＝電子的支払手段に係る法律施行後速やかに利用開始できるよう「Progmat Coin1.0」を用意したうえ、「Progmat5.0」リリース
に合わせたオープン化と、Progmat以外のST基盤やデジタルアセットでも決済手段として利用可能にする「Progmat Coin2.0」の検討/開発も想定。
#05-1 最新版ロードマップ
1
2
3
9
8
5
4
6
7
第1期｜
Progmat内DVP・クロスチェーンDVP具体化
第2期｜
Permissionless Chain内SC具体化
1Q - 2Q 3Q - 4Q
1Q - 2Q 3Q - 4Q
FY2021 FY2022 FY2023
3Q - 4Q
Progmat基盤拡張
関連マイルストーン
▼各種個別WGアウトプット公開
▼ODX・ST取扱開始
セカンダリ・DLT拡張
WG
当局動向
(PTS規制)
セカンダリ取引手段
(PTS+P2P)
セ
カ
ン
ダ
リ
第2期｜
ODXにてST取扱開始
ODXにて株式取扱開始
ODX業務開始準備
監督指針等改正/自主規制協議
STセカンダリ取引開始(1号案件ロックアップ終了)▼
資
金
決
済
資金決済
WG
1Q - 2Q 3Q - 4Q
FY2024
▼Progmat Coin提供開始
PTS連携方法具体化
資金決済手段
(Progmat Coin+α)
Progmat Coin2.0開発
(オープン化、クロスチェーン対応)
ホワイトラベルモデル対応
(Permissionless Chain対応)
(セカンダリ・DLT拡張WG内)
当局動向
(資金決済規制)
▼DLTオープン化(FY2023内)
APIオープン化(2022/12)▼
SCに係る初期検討 Progmat Coin1.0開発
(Private型でのSC初期構築)
Progmat
セカンダリ・決済方式
【セカンダリ】PTS
【資金決済】Progmat Coin(管理委託)
Progmat
基盤拡張
Progmat4.0開発｜APIオープン化
Progmat5.0開発｜DLTオープン化 Progmat6.0開発｜P2P対応
資金決済WG
研究会・
法案審議(SC) 改正法施行(SC)
【セカンダリ】PTS
【資金決済】Progmat Coin(直接管理)
【セカンダリ】金商業者内マッチング
【資金決済】法定通貨
ロックアップ期間
SRC
第3期｜
P2P連携方法具体化

View Slide

#06
Appendix
#45

View Slide

#06 Appendix
#06-1 想定業務フロー① | 金商直接管理型(1/4)
1
2
3
4
PTS
【売側】金商業者A
(Coin/直接/DLT)
【買側】金商業者B
(Coin/直接/DLT)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
(金商業者A)
9
CN
(金商業者B)
10
AN
(原簿管理者)
11
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
売注文
買注文
マッチング
出来通知Tx
生成・回付
出来通知Tx
取込
出来通知Tx
取込
買側資金決済
方法確認
【残論点2】
PTSにてENへデータを
連携するシステム構築
が必要。
プログラムバグによる誤
情報連携時のリスク・
責任範囲に係る整理
が必要。
約定日(取引都度～)
出来通知情報
作成(自動)
注文ID
採番
注文ID
採番
出来通知Txを受領した売側CNは、買
側CN内に登録されている買側の資金決
済方法を確認し、SC決済ならば後続処
理にてSC残高を確認。
事前登録
資金決済情報
事前登録
資金決済情報
事前登録
資金決済方法
連携Tx生成
資金決済方法
連携Tx生成
各社のCNに資金決済情報を事前登録。出来通知
Txを受領した売側CNは、登録された資金決済情
報を確認し、移転処理を実行する想定。
資金決済方法
連携Tx取込
資金決済方法
連携Tx取込

View Slide

#06 Appendix
1
2
3
4
PTS
(Coin/直接/DLT)
(Coin/直接/DLT)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
(金商業者A)
9
CN
(金商業者B)
10
AN
(原簿管理者)
11
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
買側SC残高
事前確認
買側SC残高
不足連絡
買側SC残高
不足連絡受領
SC残高不足
通知
SC残高不足
通知受領
不足金額
入金
入金確認
SC追加信託
指図
SC追加発行
処理
SC追加発行
SC残高増加
SC残高増加
確認
資金決済残高不足によるフェイル対応
：手オペ処理
：自動処理
買側SC残高
連携依頼
買側SC残高
連携依頼受領
買側SC残高
情報連携
買側SC残高
情報受領

View Slide

#06 Appendix
1
2
3
4
PTS
(Coin/直接/DLT)
(Coin/直接/DLT)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
(金商業者A)
9
CN
(金商業者B)
10
AN
(原簿管理者)
11
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
ST・SC移転
Tx生成・回付
ST・SC移転
Tx受領
ST・SC移転
Tx署名・回付
ST・SC移転
Tx受領
ST・SC移転
Tx署名・回付
買側SC残高
情報再連携
買側SC残高
情報再受領
買側SC残高
再確認
随時リトライ処理
実行。
出来通知Tx取込によって得られた情報を基に、
Txを生成。
売側ST残高
確認

View Slide

#06 Appendix
1
2
3
4
PTS
(Coin/直接/DLT)
(Coin/直接/DLT)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
(金商業者A)
9
CN
(金商業者B)
10
AN
(原簿管理者)
11
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
ST・SC移転
Tx受領
ST・SC移転
Tx署名・回付
ST・SC移転
Tx受領
NNへ二重
消費検証依頼
ST・SC移転
Tx確定・配布
ST・SC移転
Tx取込
ST・SC移転
Tx取込
ST・SC移転
Tx取込
ST・SC移転
結果確認
ST・SC移転
結果確認
NNから署名済
Tx受領

View Slide

#06 Appendix
#06-1 想定業務フロー② | 金商間接管理型(1/4)
1
2
3
4
PTS
(Coin/間接/API)
(Coin/間接/API)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
(カストディアン)
9
AN
(原簿管理者)
10
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
売注文
買注文
マッチング
出来通知Tx
生成・回付
出来通知Tx
取込
買側SC残高
事前確認
出来通知情報
作成(自動)
【残論点2】
PTSにてENへデータを連携するシステ
ム構築が必要。
プログラムバグによる誤情報連携時の
リスク・責任範囲に係る整理が必要。
注文ID
採番
注文ID
採番
買側資金決済
方法確認
事前登録
資金決済情報
事前登録
資金決済情報
事前登録
資金決済方法
連携Tx更新
資金決済方法
連携Tx更新 CNに資金決済情報を事前登録。出来通知Txを受
領したカストディアンは、買側資金決済情報を確認し、
移転処理を実行する想定。
出来通知Txを受領したCNは、買側の資
金決済方法を確認し、SC決済ならばSC
残高を確認。

View Slide

#06 Appendix
1
2
3
4
PTS
(Coin/間接/API)
(Coin/間接/API)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
9
AN
(原簿管理者)
10
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
買側SC残高
不足確認
買側SC残高
不足通知
SC残高不足
通知受領
SC残高不足
連携
SC残高不足
連携受領
不足金額
入金
入金確認
SC追加信託
指図
SC追加発行
処理
SC追加発行
SC残高増加
SC残高増加
連絡
SC残高増加
確認
SC追加信託
指図受領
SC追加信託
指図登録
資金決済残高不足によるフェイル対応
：手オペ処理
：自動処理

View Slide

#06 Appendix
1
2
3
4
PTS
(Coin/間接/API)
(Coin/間接/API)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
9
AN
(原簿管理者)
10
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
ST・SC移転
Tx生成・回付
ST・SC移転
Tx受領
ST・SC移転
Tx署名・回付
ST・SC移転
Tx受領
ST・SC移転
Tx署名・回付
ST・SC移転
Tx受領
買側SC残高
再確認
随時リトライ処理
実行。
出来通知Tx取込によって得られた情報を基に、
Txを生成。
売側ST残高
確認

View Slide

#06 Appendix
1
2
3
4
PTS
(Coin/間接/API)
(Coin/間接/API)
5 原簿管理者
6 SC発行者
7
EN
(PTS)
8
CN
9
AN
(原簿管理者)
10
SN
(SC発行者)
業
務
シ
ス
テ
ム
/ Progmat
ST・SC移転
Tx確定・配布
ST・SC移転
Tx取込
ST・SC移転
Tx取込
ST・SC移転
完了連絡
ST・SC移転
結果確認
ST・SC移転
結果確認
NNへ二重
消費検証依頼
NNから署名済
Tx受領

View Slide

#06 Appendix
#06-2 想定データフロー① | 金商直接管理型(1/4)
f
a b c d e g h i j k
原簿管理者 SC発行者
PTSシステム EN 金商内システム CN 金商内システム CN 社内システム AN
PTS(Node保有) 【売】金商業者(Coin/直接/DLT) 【買】金商業者(Coin/直接/DLT)
SC発行者システム SN
2
3
1
# 取引事由
【凡例】：DLT外データ：DLT格納データ(確定Tx) ：DLT格納データ(未確定Tx) 青字：該当処理で生成される新規情報
：署名：連携：DLT間連携
受
注
売却注文情報
・売側投資家ID
・銘柄名 or コード
・注文数量
・注文単価
・ST決済基盤コード
買付注文情報
・買側投資家ID
・注文数量
・注文単価
売却注文情報
買付注文情報
売側注文ID情報
・売側注文ID
買側注文ID情報
・買側注文ID
発
注
・
注
文
ID
採
番
注
文
発
注
事
前
登
録
資
金
決
済
情
報
登
録
資金決済情報
・投資家ID
・資金決済機関コード
資金決済情報
・投資家ID
資金決済情報
売側CN署名
資金決済情報
資金決済情報
買側CN署名
資金決済情報
【残論点3】
デジタル証券PTSでの個人情報の取扱
にあたっての課題と対処方法の整理が必要。

View Slide

#06 Appendix
6
7
4
5
g h i j k
# 取引事由
a b c d e f
出来情報
・ST約定数量
・ST約定金額
・約定ID
・売側注文ID
・買側注文ID
・取引ID
・トークンのTxID
・約定ID
・ST約定数量
出来情報
・ST約定単価
・売側注文ID
・買側注文ID
EN署名
出来情報
出来情報
買側SC残高情報
連携依頼
・買側SC残高
PTS
に
て
マ
ッ
チ
ン
グ
出
来
結
果
通
知
Tx
生
成
・
取
込
買
側
SC
残
高
確
認
マ
ッ
チ
ン
グ
出
来
結
果
通
知
Tx
生
成
・
回
付
資
金
決
済
方
法
資
金
決
済
情
報
確
認
資金決済方法確認

View Slide

#06 Appendix
10
8
9
g h i j k
# 取引事由
a b c d e f
買
側
SC
残
高
不
足
連
絡
買側SC残高
・約定ID
・買側SC不足金額
不足金額情報
買側SC残高
不足金額情報
買側SC残高
不足金額情報
SC追加信託情報
・買側SC投資家ID
・追加信託金額
SC発行金額情報
・SC発行金額
SC
追
加
発
行
SC追加発行金額
情報
再連携
・買側SC残高
買
側
SC
残
高
再
連
携
フ
ェ
イ
ル
対
応
|
資
金
（
SC
）
不
足
・SC発行金額
CN署名

View Slide

#06 Appendix
11
12
g h i j k
# 取引事由
a b c d e f
ST・SC移転情報
・取引ID
・約定ID
・ST/SC約定数量
・ST/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
生
成
回
付
二
重
消
費
検
証
・
Tx
確
定
・
取
込
ST
・
SC
移
転
処
理

View Slide

#06 Appendix
#06-2 想定データフロー② | 金商間接管理型(1/4)
f
a b c d e g h i j k
カストディアン原簿管理者 SC発行者
PTSシステム EN 金商内システム金商内システム社内システム CN 社内システム
PTS(Node保有) 【売】金商業者【買】金商業者
AN SC発行者システム SN
1
# 取引事由
2
3
受
注
売却注文情報
・注文数量
・注文単価
買付注文情報
・注文数量
・注文単価
売却注文情報
買付注文情報
・売側注文ID
・買側注文ID
発
注
・
注
文
ID
採
番
注
文
発
注
資
金
決
済
情
報
登
録
事
前
登
録
資金決済情報
・投資家ID
資金決済情報
・投資家ID
資金決済情報
資金決済情報
【残論点3】
デジタル証券PTSでの個人情報の取扱
にあたっての課題と対処方法の整理が必要。

View Slide

#06 Appendix
5
6
7
4
g h i j k
# 取引事由
a b c d e f
出来情報
・ST約定数量
・ST約定金額
・約定ID
・売側注文ID
・買側注文ID
・取引ID
・約定ID
・ST約定数量
出来情報
・ST約定金額
・売側注文ID
・買側注文ID
EN署名
PTS
に
て
マ
ッ
チ
ン
グ
出
来
通
知
Tx
生
成
・
取
込
マ
ッ
チ
ン
グ
出
来
通
知
Tx
生
成
・
回
付
出来情報
買側SC残高確認
資
金
決
済
方
法
資
金
決
済
情
報
確
認
資金決済方法確認
買
側
SC
残
高
確
認

View Slide

#06 Appendix
8
9
10
g h i j k
# 取引事由
a b c d e f
買側SC残高
・約定ID
・買側SC不足金額
不足金額情報
買側SC残高
不足金額情報
買側SC残高
不足金額情報
・追加信託金額
SCt発行金額情報
・SC発行金額
買
側
SC
残
高
不
足
連
絡
フ
ェ
イ
ル
対
応
|
資
金
(SC)
不
足
SC
追
加
発
行
買
側
SC
残
高
再
確
認
買側SC残高再確認
・SC発行金額
CN署名

View Slide

#06 Appendix
11
12
g h i j k
# 取引事由
a b c d e f
ST・SC移転情報
・取引ID
・約定ID
・ST/SC約定数量
・ST/SC約定金額
CN署名
ST・SC移転情報
CN署名
AN署名
ST・SC移転情報
CN署名
AN署名
ST・SC移転情報
CN署名
AN署名
SN署名
SN署名
NN署名(NNにて付与)
ST・SC移転情報 ST・SC移転情報
ST
・
SC
移
転
Tx
生
成
回
付
二
重
消
費
検
証
・
Tx
確
定
・
取
込
ST
・
SC
移
転
処
理

View Slide

#06-3 残論点
#06 Appendix
カテゴリ
A
残論点
B
前提
C
継続検討内容
D
1
データデジタル証券PTSでのデジタル証券PTSからの出来情報をインプットに、
そのままProgmat上で移転処理を行うため、出来情報
3
参加者のデジタル証券PTSの
責任範囲について
連携方法
の中に移転元/移転先の投資家IDを内包する必要が
あり、よってデジタル証券PTSと注文を受け付ける段階で
デジタルデジタル証券PTSに係る
コストシェアについて
デジタル証券PTSがProgmatネットワークに参加し、
Exchange Nodeを直接保持することを前提に、
デジタル証券PTSからのデータをインプットに、資金決済
を含むポストトレードプロセスが即座に完結するため、
上流工程であるPTSが負うリスク、責任分界点、
Exchange Nodeの運用コスト負担方法について、
PTSに接続する金商業者が支払う「PTS接続料金」
にどの程度織り込むかについて、継続検討。
責任範囲
証券PTS
運営方式
2
フローについて、継続検討。
個人情報取扱可否
システム構成を想定。(ライセンス料金が発生)
デジタル証券PTSがProgmatネットワークに参加し、
Exchange Nodeを直接保持することを前提に、
Exchange NodeからのTx配布を起点とした
証券決済/資金決済フローを想定。
(プログラムバグによる誤った出来情報に伴う決済等)
投資家IDについても情報連携する想定。
上場株式におけるPTSでは投資家ID情報は
取り扱っていないため、新たに取り扱うにあたっての
課題の有無と対処方法について、継続検討。
(投資家IDのみでも個人情報に該当する場合等)
[関連ページ:#46]

View Slide

免責事項
 本資料は、ディスカッション用に作成されたものであり、三菱UFJ信託銀行の個別の商品、サービスを勧誘することを
目的としたものではありません。本ディスカッション或いは資料だけで契約が成立するものではありません。従って、当
社はいかなる種類の法的義務、或いは責任を負うものではありません。
 本資料は信頼できると思われる各種データ等に基づいて作成されていますが、当社はその正確性、完全性を保証
するものではありません。ここに示したすべての内容は、当社の現時点での判断を示しているに過ぎません。また、本
資料に関連して生じた一切の損害については、当社は責任を負いません。その他専門的知識に係る問題について
は、必ず貴社の弁護士、税理士、公認会計士等の専門家にご相談の上ご確認ください。
 本資料は当社の著作物であり、著作権法により保護されております。当社の事前の承認なく、本資料の全部もしく
は一部を引用または複製、転送等により使用することを禁じます。
 商号等：三菱ＵＦＪ信託銀行株式会社登録金融機関関東財務局長（登金）第33号
 加入している協会の名称：日本証券業協会一般社団法人日本STO協会
一般社団法人金融先物取引業協会一般社団法人日本投資顧問業協会
本資料に関するお問い合わせ先
三菱ＵＦＪ信託銀行株式会社経営企画部デジタル企画室
プロダクトマネージャー齊藤達哉
(ST研究コンソーシアム事務局Mail) [email protected]

View Slide

View Slide

20220316_【SRC】セカンダリ・DLT拡張WG_第2期報告書_本紙

20220316_【SRC】セカンダリ・DLT拡張WG_第2期報告書_本紙

progmat

More Decks by progmat

Other Decks in Business

Featured

Transcript