JPX WORKING PAPER
JPX WORKING PAPER
約定照合業務におけるDLT適用検討フェーズ2
～JPXワーキング・ペーパーVol.22を踏まえたさらなる検討結果と今後の展望～
2019年2月19日
xx証券グループプロジェクトチーム
xxxx、xxxx、xxx、xxx、xxx、xxxx、xxxx、xxxx
※ 本稿は、2018年1月18日に公表されたJPX ワーキング・ペーパーVol.22「約定照合業務におけるブロックチェーン(DLT)適用検討」(*)の内容を踏まえ、筆者等が実施したさらなる検討について、その概要をとりまとめたものである
(*) xxxxx://xxx.xxx.xx.xx/xxxxxxxxx/xxxxxxxx-xxxxx/xxxxxxx-xxxxx/xxxxxx0000000x0x-xxx/XXX_xxxxxxx_xxxxx_Xxx00.xxx
JPX ワーキング・ペーパーは、株式会社日本取引所グループ及びその子会社・関連会社の役職員及び外部研究者による調査・研究の成果を取りまとめたものであり、学会、研究機関、市場関係者他、関連する方々から幅広くコメントを頂戴することを意図しております。なお、掲載されているペーパーの内容や意見は執筆者個人に属し、日本取引所グループ等及び筆者らが所属する組織の公式見解を示すものではありません。
約定照合業務におけるDLT適用検討 フェーズ２
～JPXワーキング・ペーパーVol.22を踏まえたさらなる検討結果と今後の展望～
【JPX業界連携型DLT実証実験】
2019年2月19日xx証券グループプロジェクトチーム
本資料は、当社が信頼できると判断した情報源から取得した情報に基づいて作成いたしておりますが、その正確性、完全性を保証するものではありません。
本資料の内容につきましては、貴社のご判断に基づき、ご活用いただきますようお願いいたします。なお、本資料の内容に関する一切の権利につきましては 0
当社に帰属し、本資料の全部又は一部を当社の承諾なしに公表又は第三者に伝達することはできませんので、貴社限りとしてご活用ください。
xxxx、xxxx、xxx、xxx、xxx、xxxx、xxxx、xxxx
目次
Ⅰ. | サマリー | P. 2 |
Ⅱ. | プロジェクト概要 | P. 4 |
Ⅲ. | 検討結果 | X. 12 |
Ⅳ. | 今後の展望 | P. 28 |
Ⅰ. サマリー
サマリー
⚫ 現行の約定照合業務は、単価・売買代金や手数料などの計算方式、通知方式、各種コードなどの規格が統一されておらず、業界全体の観点からは、必ずしも最適化されていない。
⚫ 約定照合業務の全体最適化において、DLT（分散型台帳技術）※の活用は有効な選択肢である。
⚫ DLT適用構想では、各サービスプロバイダ（以下、「SP」）が独自に開発して金融機関に提供している約定照合システム機能の一部を、DLT上にスマートコントラクトとして実装し共同利用で きるようにすることで、情報連携の効❹化を図る。
⚫ 当該DLT基盤が提供する機能群は、データ標準化・連携（Function1）、マッチング処理
（Function2）、各種計算ロジック標準化（Function3）の3つに分類される。
⚫ また、当該DLT基盤には、高度な情報セキュリティとともに、事業環境や利用者ニーズの変化に合わせて機能を適切にアップデートすることが求められる。
⚫ DLT適用構想の実現には、システムの開発・運営に加え、営業・マーケティングや管理部門と いった役割も求められる。これらを一体として提供するにあたっては、当該事業を担う法人の設立が必要となる可能性がある。
⚫ 中長期的な視点では、参加者の拡大と機能強化により、後続の決済領域やデータビジネス向け基盤など、約定照合以外の領域における業務効❹化基盤としての活用も期待される。
※ DLT：Distributed Ledger Technologyの略。ネットワークの参加者間で権利の移転を相互認証し、暗号技術を用いて実質的に改ざん不可能な形で台帳を共有する技術基盤。
Ⅱ. プロジェクト概要
⚫ 本プロジェクトの背景
▸ 約定照合業務プロセスのさらなる効率化推進にあたり、DLTは課題解決の要素技術となる可能性がある。
▸ ただし、DLT実用化のためには、技術そのものの発展とともに、機関投資家、SP、金融機関等による業界全体としての議論と連携が必要である。
⚫ “約定照合業務におけるDLT適用検討 フェーズ２”（以下、「本プロジェクト」）は、フェーズ1※の検討結果を踏まえ、より多くの関係者を巻き込んだ議論により、約定照合業務におけるDLT適用構想を具体化し、その実現に向けた道筋をつけることを目的とする。
グ・ペーパーVol.22『約定照合業務に
※フェーズ1の詳細は「JPX ワーキン
おけるブロックチェーン(DLT)適用検討』」（2018.1.18）を参照
⚫ 本プロジェクトの目的
▸ 機関投資家、SP、金融機関等による議論により、システムソリューションとしてDLT適用構想を具体化すること。
▸ DLT適用構想の要件や課題を整理し、必要な機能や体制、枠組み をまとめ、その実現に向けた道筋をつけること。
xxxxx://xxx.xxx.xx.xx/xxxxxxxxx/xxxxxxxx- study/working-paper/tvdivq0000008q5y- att/JPX_working_paper_Vol22.pdf
⚫ 機関投資家、SP、金融機関等 計26社およびxx証券グループプロジェクトチームが、 JPX業界連携型DLT実証実験を活用し本プロジェクトを実施。
HSBC証券会社 | xx證券株式会社 |
株式会社エックスネット | 株式会社xx総合研究所 |
株式会社オージス総研 | BNPパリバ証券株式会社 |
岡三証券株式会社 | 丸三証券株式会社 |
株式会社QUICK | xxx証券株式会社 |
ゴールドマン・サックス証券株式会社 | 三井住友アセットマネジメント株式会社 |
DTCC Japan KK | 三井住友信託銀行株式会社 |
東海東京フィナンシャル・ホールディングス株式会社 | 三井住友トラスト・アセットマネジメント株式会社 |
内藤証券株式会社 | 三菱UFJ国際投信株式会社 |
日興アセットマネジメント株式会社 | 三菱UFJモルガン・スタンレー証券株式会社 |
ニッセイ アセットマネジメント株式会社 | メリルリンチ日本証券株式会社 |
日本マスタートラスト信託銀行株式会社 | リフィニティブ※ |
xxアセットマネジメント株式会社 | 他1社 |
◼ 参加企業一覧（五十xx）、オブザーバー等、xx証券グループプロジェクトチーム
※ リフィニティブ（Refinitiv）は、トムソン・ロイターのファイナンシャル・リスク（F&R）部門の新名称（2018年10月1日～）。
オブザーバー
株式会社証券保管振替機構
Supported by
株式会社日本取引所グループ
xx証券グループプロジェクトチーム
xx証券株式会社 |
大和証券投資信託委託株式会社 |
Fintertech株式会社 |
株式会社xx総研 |
Day | 日程（仮） | 時間 | 会場 | タイトル | ゴール |
① | 9/12（水） | 17:00 ～18:45 | JPX 大会議室 | キックオフ | フェーズ1の理解ギャップ埋め、討論の土台の構築約定照合における課題認識の洗い出し |
② | 9/25（火） | 17:00 ～18:30 | 〃 | 現状把握 | バイサイド・セルサイドの課題の相違と共通点の明確化業界変革（全体最適化）に対する目線合わせ |
③ | 10/9（火） | 〃 | 〃 | 全体最適案の検討 | スピード、情報の交換、ミスマッチなどの解決方法の整理 コンソーシアムで取り組むべき事項、および優先順位の決定 |
－ | 10/16（火） | 16:00 ～18:00 | Fintertech株式会社 | SP打ち合わせ | ①～③に対するRFP視点（システム視点）からの検討 |
➃ | 10/30（火） | 17:00 ～18:30 | JPX 大会議室 | 構想検討 | SP打ち合わせ結果の共有 DLT適用構想の掘り下げ |
⑤ | 11/13（火） | 〃 | 〃 | 実現性検討① | 実現に向けた検討①（システム面、運営面） |
⑥ | 11/27（火） | 〃 | 〃 | 実現性検討② | 実現に向けた検討②（システム面、運営面） |
－ | 12/4（火） | 〃 | 〃 | SP打ち合わせ | ➃～⑥に対するRFP視点（システム視点）からの検討 |
－ | 12/19（水） | 〃 | 〃 | とりまとめ | 検討結果のとりまとめ |
⚫ プロジェクト期間は2018年9月～12月の約4か月。
⚫ 全体会6回、SP分科会2回のプロジェクトミーティングを実施。
⚫ 「JPX業界連携型DLT実証実験」は、金融インフラにおけるDLT適用可能性に関する実証実験や調査・検討を行うために、株式会社日本取引所グループが提供する業界連携プラットフォーム。
◼ 業界連携型DLT実証実験のプラットフォームについて
金融機関A
金融機関B
金融機関C
共同検討及び知見の共有によるオープンイノベーションの推進
DLTアプリケーション
TSEアプリ他社アプリ
DLTコアレイヤー
(ミドルウェア)
物理インフラ(サーバ)
(ハードウェア)
DLT実験環境
コミュニティサイト
ITベンダーA
ITベンダーB
OSE TSE JSCC
出所：日本取引所グループＨＰ xxxxx://xxx.xxx.xx.xx/xxxxxxxxx/xxxxxxxx-xxxxx/xxx/xxxxx.xxxx
⚫ 注文の成立後、セルサイドとバイサイドは、お互いが認識している約定情報とアロケーション結果を照らし合わせ、認識に齟齬がないことを確認する。これを「約定照合」という。
◼ 現在の約定照合業務
▸ セルサイド（証券会社）は、バイサイド（機関投資家）からの注文を受け、取引所でその注文を執行し、取引結果をバイサイドに通知する。
▸ バイサイドは通知の受領後、複数ファンドへの割り当て（アロケーション）を行い、アロケーション情報をセルサイドと共有する。
▸ セルサイドとバイサイドは、お互いが認識している約定情報とアロケーション情報に齟齬がないことを確認する。これを約定照合という。
約定照合業務
【主な照合項目】
ファンドコード銘柄コード約定日
決済日 売買区分数量
単価
約定金額消費税 手数料 決済金額
出所：xx証券グループプロジェクトチーム作成
⚫ 日々の基準価額公表のために、バイサイド、セルサイドは大引け直後から一斉に約定照合業務を開始。
⚫ 短時間での業務完了が求められ、15:00～15:30のトレーディングルームは極度の煩忙状態になる。
◼ 約定照合の実務イメージ※
9時
10時
11時
12時
13時
14時
15時
16時
17時
9:00
前場
11:30
12:30
後場
15:00
通常業務時間帯
▸ 大引け後の15:00から、トレーディングルームで本格的な約定照合業務がスタート。
▸ 原則として15:30までに照合業務を終える必要があり、15:00からの30分間は極度の煩 忙状態になる。
▸ もしアンマッチ（金額等の相違）があれば、
相違状態を解消するために緊急の対応が必要となる。
▸ バイサイドは約定照合後、信託銀行等へ確定したデータを送信する必要がある。
▸ 16:30頃までにデータが確定しないと、販売 会社ウェブサイトや新聞での投資信託の基準価額が公表できなくなってしまう恐れがある。
（9:00～15:00）
煩忙時間帯
メインの約定照合業務
（15:00～16:00）
アンマッチ有
18時
業務終了 コンファメーションの引き戻し
修正・再送信
※厳密には、各社、各担当者によって業務の内容やタイムライン、煩忙度は異なる
⚫ 業務プロセスのさらなる効❹化において、規格の統一やSPシステム間連携には検討の余地がある。
◼ 現在の約定照合業務システムのイメージ
▸ 注文・出来通知から約定照合までの一連の業務は、従来メールやFAXなど人手を介して行われてきたが、昨今では様々なシステムが開発・導入され、効率化されている。
▸ ただし、単価計算等のルールはバイサイドと セルサイドとの合意に委ねられており、統一さ
れていない。
▸ また、異なるSPシステム間で連携ができない
（左図イメージ）。
▸ 業務プロセスのさらなる効❹化が求められている。
出所：xx証券グループプロジェクトチーム作成
Ⅲ. 検討結果
Ⅲ-1. 現状と課題
Ⅲ-2. DLT適用による課題の解決（DLT適用構想）
Ⅲ-3. DLT適用構想の実現に向けた課題
⚫ 現行の約定照合業務は、単価・売買代金や手数料などの計算方式、通知方式、各種コードなどの規格が統一されておらず、各社がそれぞれ独自の対応を行っている。
⚫ それらは業界全体の観点からは、必ずしも最適化されていない。
◼ ルール・規格の違い
カテゴリ
単価計算
現状と課題
個別単価と平均単価がある。個別単価は、国内市場における従来の方式。平均単価はグローバルな計算方式であり、現在の主流となっているが、個社ごとの事情から、個別単価を採用している会社もある。
手数料計算
四捨五入、キャップ・フロアー、少額差異（1円～数円単位の差異）、消費税などの取り扱いについて、複数のルールが乱立している。
アロケーション通知
取引明細 (ﾌﾟﾚｺﾝﾌｧﾒｰｼｮﾝ)
バイサイドが伝送手段を指定する。主に電子メールや、外部サービスプロバイダによる複数のサービスから選択する。
ExcelやCSVの場合はバイサイドがフォーマットを指定し、セルサイドはそのリクエストに沿ったファイルをEUCで対応する場合もある。外部サービスプロバイダサービスの場合、サービス毎にインターフェースや機能仕様が異なる。
各種コード
ローカルコードと数種類のグローバルコードが存在し、セルサイドはバイサイドの求めるコードで約定照合を行う必要がある。
障害対応
障害時のコンティンジェンシープランが会社ごとに異なっている。
⚫ バイサイドもセルサイドも、時間が掛かる仕組みをなくしたい。
⚫ 多様な仕様や対応を標準化することで、コストの削減やボトルネックの解消が見込まれる。
◼ 「約定照合業務でなくしたいと思うもの」 についての回答結果
セルサイド がなくしたいもの
• 各社ごとのコンファメーション
• 各社・商品ごとのベンダーシステム
• 各社ごとの照合項目
• 平均単価の不採用口座
• 少額相違への訂正作業
• 各社ごとの手数料計算
• バラバラな銘柄コード
• 煩雑な口座開設
セルサイド・バイサイド両方がなくしたいもの
• 多様な要求・仕様
• SPシステム間でデータ連携不可
• 顧客・SPシステムごとに異なるフォーマット、コード体系
• 口座開設・変更の煩雑な手続き
• 少額差異への対応
• 一口計算等の手数料計算方法
• 個別単価での処理
• メールやFAX
バイサイド がなくしたいもの
• 基準価額算定の遅延
• アンマッチ解消に要する時間
• 障害の復旧に要する時間
• トラブル時における通常とは異なる作業・手順
• トラブル時の例外対応
• 双方が同一画面で話せない状況
• 多様なシステム障害対応
なくしたいもの | 課題解決の方向性 | 標準取決め | DLT 実装 | ||
通常時 | 多様な要求 ・仕様 | SPシステム間でデータ連携不可 | • フォーマットを規定して必ず入れる項目やこの項目がマッチしたら良いという決めごとを作ればよい。 • バイサイド、セルサイドというよりSP側が対応するかどうかの問題。SP側のインセンティブは要検討。 | ○ | ○ |
顧客・SPシステムごとに異なるフォーマット、コード体系 | • 業界標準があれば進められる。 • 現在のシステムでも適応できるが、共通テーブルを持つにはDLTが適している。 | ○ | ○ | ||
口座開設・変更の煩雑な手続き | • 各社での対応は不可。業界全体での取り組み必須。DLT情報連携で解決できる可能性がある。 | ○ | ○ | ||
少額差異への対応 | • 少額差異の発生自体をゼロにすることはできない。 • ただし、少額発生時の対応ルールを決めておき、自動的に処理することはできる。 | ○ | |||
一口計算等の手数料計算方法 | • 業界標準がない中、当事者同士でそれぞれのルールを形成し、対応してきた。 | ○ | |||
個別単価での処理 | • 日本特有の慣習。スポンサー意向による部分が大きいため、バイサイドだけでも決められない。 • ゼロにするには、行政からのガイダンスが効果がありそう。 | ○ | |||
メールやFAXによるコンファメーション | • セルサイドから「なくしましょう」とはいいにくい。自然にはなくならない。業界機運が高まると良い。 • DLTで解決できる可能性もある。 | ○ | ○ | ||
双方が同一画面で話せない状況 | • 異なるフォーマット、コード体系で会話していることが意思疎通を阻害している。 • どこで何が起きているか、同じ情報を全員で見ることができるDLTに活用余地がある。 | ○ | ○ | ||
障害 発生時 | 多様なシステム障害対応 | • 障害が発生しても、代替手段があればトレード先が変えられるという懸念が低減するはず。 • DLTによるSPシステム連携（業務継続を可能とする代替手段の提供）で解決できる可能性。 | ○ | ○ | |
⚫ 約定照合手続きの標準やベストプラクティスを定めることで解決できる課題は多い。
⚫ 標準化されたルールで各社が業務を遂行するには、DLTによる実装が適している可能性が高い。
⚫ DLT適用構想では、各種機能及びデータ項目を標準化し、DLT上にスマートコントラクト及び分散型台帳として実装する。SPは従来どおり顧客にサービス提供するが、各社はそれぞれDLTノードを保有し、機能自体はDLT上で標準化されたプロセスで実行される。
⚫ データはDLT上に格納され、顧客はどのSP経由からでも自社のデータを参照・操作できる形とする。
⚫ DLT基盤が提供するライブラリ（機能群）は、データ標準化・連携（Function１）、マッチング処理
（Function2）、各種計算ロジック標準化（Function3）の3点に分類できる。
◼ DLT基盤が提供する実現可能性（縦軸）とファンクションの期待効果（横軸）による分類
Function2
Function1
マッチング処理
xxxxx・xxx
（居住者取引における差異調整機能）
プレコンファメーション
情報共有
データ連携シーケンスデータ変換（ETL）
ction3
手数料計算ロジック
単価計算ロジック
Fun
Function1 | データ標準化・連携 |
Function2 | マッチング処理 |
Function3 | 各種計算ロジック標準化 |
大
実現可能性
小
小 期待効果
※ Function1 はFunction2および3の前提条件
※ Function2と3は並列関係にあり、両者に前後関係xxx
x
なくしたいもの | 課題解決の方向性 | 標準取決め | DLT 実装 | ||
通常時 | 多様な要求 ・仕様 | SPシステム間でデータ連携不可 | • フォーマットを規定して必ず入れる項目やこの項目がマッチしたら良いという決めごとを作ればよい。 • バイサイド、セルサイドというよりSP側が対応するかどうかの問題。SP側のインセンティブは要検討。 | ○ | ○ |
顧客・SPシステムごとに異なるフォーマット、コード体系 | • 業界標準があれFばu進nめcらtれioるn。1 • 現在のシステムでも適応できるが、共通テーブルを持つにはDLTが適している。 | ○ | ○ | ||
口座開設・変更の煩雑な手続き | • 各社での対応は不可。業界全体での取り組み必須。DLT情報連携で解決できる可能性がある。 | ○ | ○ | ||
少額差異への対応 | • 少額差異の発生F自u体nをcゼtiロoにnす2ることはできない。 • ただし、少額発生時の対応ルールを決めておき、自動的に処理することはできる。 | ○ | |||
一口計算等の手数料計算方法 | • 業界標準がない中、当事者同士でそれぞれのルールを形成し、対応Fしuてnきcたt。ion3 | ○ | |||
個別単価での処理 | • 日本特有の慣習課。題スポのンサ所ー在意と向による部分が大きいため、バイサイドだけでも決められない。 • 課ゼロ題に解する決にはの、xxx向か性らのにガつイダいンスてが情効果報が発あ信りそう。 | ○ | |||
メールやFAXによるコンファメーション | • セルサイドから「なくしましょう」とはいいにくい。自然にはなくならない。業界機運が高まると良い。 • DLTで解決できる可能性もある。 | ○ | ○ | ||
双方が同一画面で話せない状況 | • 異なるフォーマット、コード体系で会話していることが意思疎通を阻害している。 • どこで何が起きてFいuるかn、c同tiじo情n報1を全員で見ることができるDLTに活用余地がある。 | ○ | ○ | ||
障害 発生時 | 多様なシステム障害対応 | • 障害が発生してもF、u代n替ct手io段nが2あればトレード先が変えられるという懸念が低減するはず。 • DLTによるSPシステム連携（業務継続を可能とする代替手段の提供）で解決できる可能性。 | ○ | ○ | |
⚫ DLT適用構想の実現によって「なくしたいもの」をなくし、業務プロセス全体の効❹化を図る。
Function | 概要 | |
1. | データ 標準化・連携 | ▸ DLT技術を用いたプラットフォーム内でSP間のデータ連携を実現する。 ▸ 異なるSPシステムを利用している企業間での約定照合業務が可能となる。 ▸ データ連携にあたっては、各SPシステムにて異なるデータ項目やコード体系の標準化が併せて必要になるため、各SPは自社サービスを標準仕様に合わせて改修するか、 DLTとの接続においてETL等でデータ項目の変換を行う。 ▸ 異なるSPシステム同士でのマッチング方式の標準化は行わないが、方式の違いを吸収する機能を合わせて開発する。 ▸ DLT基盤をSPシステムの裏側に構築することで、バイサイド、セルサイドへの影響を 最小限に抑える。 ▸ システム障害発生時のBCPとしての役割も期待される。 ▸ 業界データ連携基盤として、約定情報連携以外にも、新規ファンドの口座情報等に 対しての汎用的な活用も期待できる。 ▸ レギュラトリーレポート等、台帳情報を活用した各種レポート作成業務との親和性も 高いと考えられる。 |
⚫ DLT 盤を構築し、データ項目を標準化した約定情報によるSPシステム間データ連携を可能とする。
⚫ 既存のSPシステムとDLT間をETL※等で接続することで、SPシステム利用者への影響を最低限とする。
⚫ 約定情報連携以外にも、業界データ連携 盤としての汎用的な活用も期待できる。
※ ETL：Extract(抽出)/Transform(変換)/Load(読み込み)の略。異なる形式のデータを持つシステム間の連携に用いられる方式、ツールを指す。
⚫ SPシステム間連携により、個別SPシステムへの対応負荷軽減、BCPとしての活用を見込む。
⚫ 汎用的な情報連携 盤として、約定情報以外の情報共有(例:ファンドの口座情報等)にも期待できる。
SPシステム
SP
ノード
ノード
SPシステム
SP
DLT
運営者
ノード
SPシステムとDLT間を ETL等で接続し利用者へ
スマートコントラクト
共通コントラクト
各種レポート作成業務との親和性も高い
の影響を最低限に
レコード登録
レコード更新
レポート作成
バイサイド
約定情報台帳
分散型台帳
口座情報台帳
セルサイド
No. 銘柄ｺｰﾄﾞ 数量 単価 手数料 …… No. 口座ｺｰﾄﾞ 受託銀行 信託口座番号 ……
当初国内株式を想定するが、
XXXX XXXX XXX XXX XXX …… XXXX XXXX XXX XXX XXX ……
XX XXXX XXX XXX
XX XXXX XXX XXX
バ…イ…サイドと異なるSP システム経由で連携可能に
障害時……にはBCPとしても活用
将来的な対象アセット拡大を見 XXXX XXXX XXX XXX XXX ……
込み、FIXメッセージベースで XXXX XXXX XXX XXX XXX ……
標準化したデータ項目にて共有
XX XXXX XXX XXX ……
XX XXXX XXX XXX ……
SP ノード
約定情報以外の情報連携にも活用
ノード SP
SPシステム SPシステム
Function | 概要 | |
2. | マッチング処理 | ▸ 双方の算出結果を付き合わせるマッチング処理をブロックチェーン上に実装することで、異 なるSPシステム同士でも自動でマッチング処理を行うことが可能となる。 ▸ 「あらかじめ定められた一定の条件下における一定額以内の差異が発生した場合、あらかじめ決めた側の金額を正として採用する」等のトレランス・ルールを組み込むことで、少 額差異が発生した際の対応について一定の自動化が期待できる。 ▸ ただし、約定金額は本来一致すべきものであり、原因不明の照合不一致に関しては、安易に自動調整機能を導入するべきではない。居住者取引におけるxxxxx・xxx の導入範囲は、必要最小限の範囲にとどめるべきである。 ▸ 通知機能をDLT上に組み込むことで、電子メールやFTP（File Transfer Protocol）、 FAXによるプレコンファメーションの送受信を省略できる可能性がある。 |
⚫ マッチング処理機能を実装することで、異なるSPシステム間の自動マッチングが可能になる。
⚫ トレランス・ルールは少額差異への対応策として有用であるが、適用範囲は必要最小限にとどめる。
⚫ 通知機能の組み込みにより、プレコンファメーション送受信を省略できる可能性がある。
⚫ 少額差異の調整機能を持ったマッチング機能をDLT上に実装することで照合業務の自動化を促進する。
⚫ 拡張のための個別台帳/コントラクト登録機能や、バイ/セルサイド自身によるDLTへの直接参加も想定
SPシステム
SPシステム
SP
スマートコントラクト
共通コントラクト(応用) 個別コントラクト
ノード
ノード
標準化したルールによる
レポート作成
少額差異調整
マッチング
ノード
SP
ノード
バイサイド
マッチング機能、少額差異の調整機能を提供
レコード登録
共通コントラクト(基本)
レコード更新
拡張のために、各社による個別台帳、個別コントラクトの登録を可能とする
セルサイド
分散型台帳
共通台帳 個別台帳
約定情報台帳
バイ/セルサイドが自身の ノードを立ててDLTの機能を直接利用するケースも想定
SP
SPシステム
ノード
口座情報台帳
ノード
セルサイド
セルサイドシステム
Function | 概要 | |
3. | 各種計算 ロジック標準化 | ▸ セルサイド・バイサイドが合意している各種計算ロジック（約定単価計算・手数 料計算等）をスマートコントラクトとしてDLT上に実装する。 ▸ これにより、現在バイサイド・セルサイドが各々おこなっている計算プロセス・マッチン グ処理を省略し（照合作業自体をSTP化し）、コストの低下を図る。また、時間的制限がある実務のなかで、ミスマッチ発生可能性の低減を図る。 ▸ 注文の大半はプログラム化可能であるが、各バイサイドごとに複雑な計算ロジックを 使用しているパターンも散見される。 ▸ プログラム可能なパターンに関しては、標準計算ロジックとしてスマートコントラクトを数パターン搭載する。それらに該当しないユニークなロジックは、当該バイサイドが 主体となってスマートコントラクトを載せることを検討する。 ▸ バイサイドがスマートコントラクトを載せるにあたってセルサイドからのレビューが必要になる。 ▸ スマートコントラクトの実装は、開発力があるセルサイドが、バイサイトからの委託を受けて実施するなどの方法が考えられる。 |
⚫ 各種計算ロジックをスマートコントラクトとしてDLT上に実装。
⚫ 照合プロセス処理の省略により、コスト削減とミスマッチ発生可能性の低減を図る。
⚫ ユニークなロジックは、標準外として個別にスマートコントラクトへの実装を検討する。
⚫ DLTに標準的な各種計算機能を実装することで、照合作業そのものをなくす。
⚫ ユニークなロジックについても、Function2の機能、もしくは個別コントラクト登録にて対応可能。
SPシステム
SPシステム
SP
スマートコントラクト
SP
共通コントラクト(応用) 個別コントラクト
ノード
よく使われる計算ロジックを標準機能として提供
ノード
レポート作成
少額差異調整
単価計算
マッチング
手数料計算
アロケーション
A社手数料計算
B社手数料計算
ノード
標準化が難しいロジックにつノいーてドはバイサイドの要件を反映した 個別コントラクトとして登録
バイサイド
レコード登録
共通コントラクト(基本)
レコード更新
セルサイド
分散型台帳
共通台帳 個別台帳
SP
SPシステム
ノード
約定情報台帳
口座情報台帳
ノード
セルサイド
セルサイドシステム
⚫ 業界全体での利用を想定するDLT 盤には、高度な情報セキュリティが求められる。
⚫ 法規制や取り扱い商品の変化、取引参加者の変化、技術の発展などに際し、タイムリーかつ継続的にシステムをアップデートし、サービス品質を高めることも求められる。
高度な情報セキュリティ
継続的なサービス
品質の向上
• セルサイド、バイサイドを含む業界データ連携の基盤
• 約定照合業務のプラットフォーム
• 約定情報以外の情報共有の基盤としての展開可能性
▸ DLT基盤は、バイサイド、セルサイド、その他のノード保有者すべてが利用できる業界データ連携の基盤。
▸ 業界全体での利用を想定するDLT基盤には
、可用性(使いたいときに使えること)を中心に
高度な情報セキュリティが求められる。
▸ 最適なシステムのあり方は、法規制や取り扱い商品の変化、取引参加者の変化、技術の発展などによって変化する。
▸ 環境の変化に合わせたタイムリーかつ継続的
なアップデートやサービス品質の向上が求められる。
◼ DLT基盤に求められるもの①
⚫ DLT適用構想の実現には、システム開発・運営機能に加え、営業機能や管理機能が求められる。
⚫ 上記機能を一体として提供するにあたっては、事業を担う法人の設立が求められる可能性がある。
◼ DLT基盤の運営に求められるもの②
事業を担う
法人の設立が求められる
可能性
1. | システム開発・運営機能 | ▸ ▸ | 高度な情報セキュリティが確保されたシステムを開発し、安定的に運営する機能 開発したシステムを、事業環境や利用者ニーズの変化に合わせ、適切 にアップデートする機能 |
2. | 営業・サポート・マーケティング機能 | ▸ ▸ ▸ | 利用者を獲得するための営業機能、利用者・潜在利用者に対するサ ポート窓口機能 利用者のニーズを適切に把握するためのマーケティング機能 法改正等の様々な環境の変化を迅速に把握する調査・研究機能 |
3. | 管理機能 | ▸ ▸ ▸ ▸ | 必要な費用を調達するための資金調達機能 継続的に利益を生み出し、安定的な財務基盤を維持する利益創出 ＆蓄積機能 収益の一部をシステムの更新や新たな投資に振り分け、次の安定的な収益源を育成する資源配分機能 xx、透明かつ健全な事業の運営を行うためのガバナンス機能 |
⚫ DLT
ティブ、資金調達の多様化・円滑化などの観点から、株式会社が望ましいと考えられる。
盤の開発・運営管理者の組織形態は、経営の透明性の確保、業務効❹化や新規業務へのインセン
◼ 運営組織の検討における組織形態の比較
運営組織の要件 | 株式会社 | 一般社団法人 | 一般財団法人 |
経営意思決定に対する利用者の関与 | ○ （出資により株主として意思決定に関与可） | ○ （理事会の承認等 により社員として関与可） | △ （設立時の財産拠出者に依存） |
経営の透明性の確保 | ◎ （取締役設置会社は監査役の設置義務） （大会社は会計監査人の設置義務） | ○ （理事会設置法人は監事の設置義務あり） | ○ （評議員制度あり） |
業務の効率化に対するインセンティブ | ◎ （取締役には善管注意義務） （出資者への剰余金分配可） | ○ （理事には善管注意義務） | ○ （理事には善管注意義務） |
ニーズへの迅速な対応や新規業務へのインセンティブ | ◎ （取締役には善管注意義務） （出資者への剰余金分配可） | ○ （理事には善管注意義務） | △ （設立時の財産拠出者に依存） |
資金調達の多様化・円滑化 | ◎ （増資可、上場可） | △ （基金募集による資金調達は可） | × （事実上借入れに限られる） |
※ 大会社とは、資本金5億円以上または負債の合計金額が200億円以上の株式会社をいう。
Ⅳ. 今後の展望
非競争領域の共通化による顧客サービスの向上
販売会社
信託銀行
海外 情報ベンダー
当局、協会
Data Function
⚫ 業界各社で重複して行っているデータ加工・連携等の非競争領域業務をDLT 盤によって共通化・自動化し、あるべき競争領域への経営資源の集中を可能とする。
セルサイド
バイサイド
セルサイド
バイサイド
◼ DLT基盤の適用による短～中長期の期待効果
情報連携の効❹化によるコスト削減
適用範囲の拡大による更なる利便性の向上
• バイサイド、セルサイドで重複して行っているデータ加工・連携業務をDLTで効率化
• 限定的な領域・参加者からスタート
• 参加者の拡大によるネットワーク効果
• 後続の決済領域、データビジネス向け 基盤、当局へのレポーティング、販売会社との情報連携など、約定照合以外の領域へ機能強化を伴って拡大
• DLT化によって非競争領域を広範囲で 共通化・自動化
• 各社が付加価値の高い競争領域に経営資源を集中
⚫ 本DLT適用構想は、金融システムにおける業務効率の改善と、新たな サービスや商品の創出に向けた有力な選択肢であり、最終受益者である投資家の利益につながると考える。
⚫ 本構想の実現にあたっては、今後、システム開発・運営等を担う枠組みの決定、必要な費用の精査、開発資金の調達、潜在的な利用者との協調・連携が求められる。
⚫ 今後は、関係各社とのさらなる連携のもと、引き続き、本構想の実現にむけた取り組みを進める。