見出し画像

Why Blockchain 証券ポストトレードにブロックチェーンを適用する意味

Fintertechストラテジーグループの相原(@Kaz_Aihara)です。

今回は、2017年から取り組んできたDLT(※)約定照合プロジェクトのワーキングペーパーを題材に、証券ポストトレードにブロックチェーンを適用する意味について、プロジェクトでの議論を通じて考えてきた内容を述べたいと思います。証券ポストトレードとは、株などの証券売買の完了後から、実際の受け渡しである証券と資金の決済までの間に行われる各種業務を指します。
※DLT・・・Distributed Ledger Technologyの略。分散型台帳技術のこと。厳密にはブロックチェーンと定義が異なりますが、本稿では区別なく使っています。

ちなみに、コンソーシアム運営のポイントや実現したいビジョンなどについては前回の投稿にて川浪が語ってくれていますので、まだご覧になっていない方は是非そちらも合わせて読んでみてください。(力作です!)

ワーキングペーパーについて

今回ご紹介するワーキングペーパーはこちら(↓)です。

JPXワーキングペーパーVol.22「約定照合業務におけるブロックチェーン(DLT)適用検討」(2018/1/18)

画像7

プロジェクトのフェーズ1として、2017年9月から12月までJPXさん全面サポートのもと業界20社で議論を行った内容をまとめたものです。プロジェクトそのものの説明は前回記事にて語られているので、本記事ではそこはばっさり省き、ワーキングペーパー中のDLT技術適用に関する部分を説明しようと思います。もしお時間があれば、是非ワーキングペーパー本体にも目を通していただけるととても嬉しいです。

現在のシステム状況と課題

約定照合は、証券の振替などとは異なり法規制がない領域のため、計算方式、通知方式、各種コードなどの規格が統一されておらず、また複数のサービスプロバイダ(以降、SP)が顧客ニーズに応じたシステムをそれぞれ提供しています。過去には手作業ベースだったようなのでそこからすると大きな進歩ではありますが、まだまだ現場担当者にとっては切実な課題が存在する領域です。たとえば、システム同士の互換性がなく個別対応が必要であったり、各SPで別々のDBを持っているためシステム集約が不可であったり、といった課題です。
現在のシステム状況と課題を整理すると以下の図のようになります。

現状と課題

この構成をベースに「業界全体であるべき姿の実現に向けて動くとしたらどのような選択を採るべきか」について、「DLTありきではなく」検討した結果を、順に追ってみたいと思います。なお、上図は約定照合業務固有の要素がない汎用的な構成としているので、同様の構造を持つ業界であれば、以降の内容はそのまま当てはまる可能性があります。

あるべき姿を実現するための体制と仕組み5案

案①:仕様のみコミッティ策定方式

まずすぐに思いつく解決案は、SPシステムごとの仕様統一です。仕様統一のためには、バイサイド・セルサイド各社の意見を集約して決定を行い、さらに各社の業務内容の見直し、システム対応を行ってもらう必要があります。大変な作業ではありますが、これができれば少なくとも複数SPシステムを導入する際の手間が大幅に削減できるはずです。ただし、これだけではDB共有はできないため、各社が採用するシステムの集約ができないという課題は引き続き残ります。

案①

案②:SP1社への片寄せ方式

続いて案②は、業界全体でどこか1社のSPを採用することに決めて片寄せしてしまう案です。片寄せの際には案①と同様に仕様統一も行い、その内容をSPに反映してもらうことにします。この案によって、課題は2つとも解消する可能性がありますが、民間企業による特定業務の独占は、サービス硬直化や価格高騰や可用性低下などの新たな懸念に繋がります。

案③:中央機関提供方式

そこで、民間のSP1社ではなく、中央機関に中央集権的に仕組みを提供してもらおう、というのが案③です。証券業界で言えば、JPXさん(日本取引所グループ)やほふりさん(証券保管振替機構)が候補に挙がると思います。これで、技術的課題も独占に伴う懸念も同時に解消されるので、この状態に至ることができたらフィニッシュと言えるのではないでしょうか。

案②③

・・・確かにそうではあるのですが、業界にとってのコア業務やクリティカル課題への対応を目的に運営されている中央機関にとって、周辺領域の業務は範囲が広すぎるため対応が難しく、中央機関は仕組みを提供したくてもできなかった可能性が高いと思われます。また、周辺領域にいくにつれ、民業圧迫の懸念も浮上し手を出しづらくもなってきます。
この部分が、Why Blockchainの分かれ道だと思っています。

案④:参加企業各社DB共有方式(DLT)

お待たせしました、いよいよDLT/ブロックチェーンの登場です。
中央機関が仕組みを提供してくれたら解決するかもしれないが実際には提供のハードルが高い、しかし中央機関が作ってくれるような公共性の高い仕組みが必要、というような状況において、これまでの技術ではこれ以上の解決策を見出すことができませんでした。
そこで案④として、参加企業各社が立てたノードを繋いでDLT基盤を構築するという案が出てきます。DLTであれば、システム同士の互換性の問題もDB共有不可の問題も独占の懸念も、理論上はクリアすることができそうです。案①と同様に仕様の統一に関する議論を行い、その結果についてはスマートコントラクトとして実装する想定です。

案④

このような結論に至るDLT/ブロックチェーン検討プロジェクトは実際に多いと思いますが、バリバリの実務者が集まったこの検討においては、案④の方式は却下となりました。理由は、

・システム会社ではないので、大手以外は自社でノードを立てるのは厳しい
・社内基幹システムの大幅改変はスイッチングコストの負担が大きすぎる
・SPによる手厚いサポートの代わりに自社で新たに体制を組む必要がある

などの負担増により、DLT化のメリットを相殺してしまう懸念が出たためです。むしろ、相殺どころかデメリットの方が大きくなりそうです。さて困った、ということでさらに深掘りして検討した結果が次の最終結論です。

案⑤:サービスプロバイダ協業方式(DLT)

自社でのノード構築・運営の負担やスイッチングコストの回避のため、引き続きSP各社に約定照合システムを提供をしてもらい、その裏でSPにノードを立ててもらう、という方式が案⑤です。取引に関係する顧客(バイサイド・セルサイド)のみへのデータ配布(⇔ブロードキャスト)、という秘匿性に関する要件が実現できれば、顧客ごとにノードを立てる方式でも、チャネルなどを駆使して複数顧客を1ノードで管理する方式でもどちらでも構わないと考えています。(図は顧客ごとにノードを立てる方式)

案⑤

バイサイド・セルサイドから見ると大きなインタフェース変更がない状態で、その裏側でSP各社がDLTを通じて連携をする想定です。コミッティには仕様決定とその実装(スマートコントラクト開発)、管理ノード運営の責務が残りますが、ここまでの案と比較すればかなり極小化されました。
これがあるべき姿だろう、というのがフェーズ1における結論です。

証券ポストトレードにおけるWhy Blockchainのまとめ

業界課題の解決に向けて、DLT/ブロックチェーンありきでなく検討した結果、案①~⑤の5案が出ました。このそれぞれの案によって何が変わったのか、整理したのが下表になります。

比較表

DLT/ブロックチェーン化による構造的なメリットは以下2点です。

・SPや中央機関1社での集中管理でなく分散管理でのDB共有を可能にした点
・業界統一の「仕様の実装」とUIやインフラなどの「アプリ・DBの構築/管理」の分離を可能にした点

これが、証券ポストトレードにおける私たちなりのWhy Blockchainです。
公共性の高い仕組みが求められる非競争領域ながら、中央機関がカバーできない多くの周辺領域において、中央機関・バイサイド・セルサイド・SPなどの業界各社の強みを生かした連携による相互扶助での改善手段を獲得するために、DLT/ブロックチェーンが必要だと考えています。

なお、フェーズ1はおもに証券会社を中心とした議論でしたが、この構想を実現するためには、バイサイドである機関投資家やSPの方々にも賛同、参画していただく必要があります。そこで、フェーズ2ではバイサイドやSPの方々にもご参加いただき、この案⑤を前提に実現方式についての具体的な議論を行っていきました。そちらの詳細についてはまたの機会で紹介できればと考えています。

この既存金融の大きなマーケットにおいては、DAOやDEXのような完全に分散管理された仕組みの導入提案は、いかに目指す場所が崇高であっても、リスクが大きすぎて受け入れられません。しかしながら、ビットコインから始まったこのDLT/ブロックチェーン化の流れは不可逆なもの、という考えは、私たちだけでなく多くのプロジェクト参加者の共通認識だったと思います。ディスラプションではなく地続きでの革新に向けて、次世代金融市場の創出をミッションとする私たちは、これからもファーストペンギンとして取り組んでいく所存です!