JP6710737B2 - 決済システム及び決済方法 - Google Patents

Description

本発明は、注文者間の取引の決済を行なうための決済システム及び決済方法に関する。

ピア・ツー・ピア・ネットワークを活用したブロックチェーン技術が決済等に利用されつつある（例えば、非特許文献１参照）。非特許文献１に記載された技術では、ブロックチェーンを活用して、大規模な決済システムを新規に構築することなく、約定情報を改ざん不可能なデータとして瞬時に共有・決済できる仕組みが検討されている。このブロックチェーン技術では、順序付けられたレコードを、分散台帳で連続的に管理することにより、ブロック内のデータの遡及的な変更を防止する。

また、オンライン取引において利用されている仮想通貨の改ざんを防止するために、ブロックチェーン技術が利用される場合もある（例えば、特許文献１参照）。この技術では、約定情報に基づく残高情報をブロックチェーンで繋げたまとまりとして分散台帳に記録する。

また、複数のコンピューティングノードを含む分散型ブロックチェーン・コンピューティングシステムを用いて取引を支援する技術も検討されている（例えば、特許文献２参照）。この技術では、取引所は、注文書と、異なるクライアントに関連する複数のデジタルウォレットを格納する。コンピュータシステムは、注文書に追加される新たなデータ取引要求を受け取る。データ取引要求の間のマッチが識別され、個別のデータ取引要求に関連するデジタルウォレットに関連するハッシュが生成される。取引相手は、相手方のハッシュを、マッチに関する情報とともに受け取り、各当事者は、ブロックチェーン取引をブロックチェーンに追加させる。両方のマッチがブロックチェーンに追加されたかどうかを判断するためにブロックチェーンをモニタする。

また、分散型台帳技術を用いて、債務記録情報の正当性を確認できる基盤システムを利用して、支払を支援するための支払支援システム及び支払支援方法を提供する（例えば、特許文献３参照）。この技術では、支払人端末及び支払人金融機関サーバに接続され、ブロックチェーン等の分散型台帳技術により情報の正当性を確認できる基盤システムを用いる。支払人端末は、債務者から債権者に対する支払方式の選択情報を取得し、選択された支払方式の債務記録情報を分散台帳に記録し、選択された支払方式に応じた支払人金融機関サーバに債務記録情報の発行を通知する。支払人金融機関サーバは、分散台帳を確認し、債務記録情報の承認情報を分散台帳に記録し、支払方式に基づいて、債権者に対する支払処理を行ない、債務記録情報の失効情報を分散台帳に記録する。

特開２０１６−１５１８０２号公報 特表２０１８−５１５８３３号公報 特許第６３６３２５４号公報

株式会社みずほ銀行、「国境を越えた証券取引の決済プロセス効率化に向けた実証実験を実施」、平成２８年３月８日、［online］、株式会社みずほ銀行、［平成３０年９月９日検索］、インターネット＜https://www.mizuhobank.co.jp/release/pdf/20160308release_jp.pdf＞

株式のように日々大量の約定や決済が行なわれる取引では、大きなシステム投資により、取引照合及び決済を実現できる。しかし、証券取引では、日々の約定決済件数の少ない取引が存在する。このような証券取引においても、安全で効率的な決済のためには、取引照合やＤＶＰ決済等において株式と同等なシステムが必要とされる。しかし、件数が少ない場合、各取引当たりのシステム投資が大きくなる。

上記課題を解決する決済システムは、注文者システムに接続される取引所システムが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された清算機関システムを含む。そして、前記取引所システムが、前記分散台帳に記録され、約定可能な注文情報を取得し、前記取得した注文情報のマッチングを行なうことにより、約定した注文情報を特定し、約定されなかった注文情報について、失効情報を分散台帳に記録し、前記清算機関システムが、前記約定された注文情報に基づいて決済を行なう。

本発明によれば、分散台帳による情報共有技術と、情報の正当性を確認できる基盤システムとを利用して、効率的な取引、すなわち約定から決済までの一連の処理を支援することができる。

本実施形態のシステム概略図。 ハードウェア構成例の説明図。 本実施形態の各システムの説明図であって、（ａ）はユーザシステム、（ｂ）は取引所システム、（ｃ）は決済口座管理機関システム、（ｄ）は清算機関システムの説明図。 本実施形態で分散台帳に記録される情報の説明図であって、（ａ）は注文情報、（ｂ）は約定成立情報、（ｃ）は失効情報、（ｄ）は承認依頼情報、（ｅ）は決済承認情報、（ｆ）は決済予告情報、（ｇ）は決済完了情報の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。

以下、図１〜図７を用いて、決済システム及び決済方法を具体化した一実施形態を説明する。本実施形態では、証券銘柄について注文を行ない、約定した取引の決済を支援する。この決済には、ＤＶＰ決済等やクリアリングハウスによる決済が含まれる。以下では、ＤＶＰ決済を行なう場合を想定するが、他の決済に適用してもよい。
図１に示すように、本実施形態では、分散台帳Ｄ１に接続されたユーザシステム１０、取引所システム２０、決済口座管理機関システム３０、清算機関システム４０を用いる。本実施形態では、ブロックチェーンにより取引決済情報の記録の正当性を確認できる基盤システムを用いて、取引や決済を支援する場合を想定する。なお、ネットワークに接続された複数のノードで同じデータを保持し合う分散台帳Ｄ１（分散型台帳）を用いるものであれば、ブロックチェーン技術を用いる場合に限定されるものではない。そして、取引決済情報は、金融機関の注文、約定、決済に関する情報を電子的に記録するものであり、取引決済情報は分散台帳Ｄ１に記録され、ブロックチェーン技術により固定化される。更に、所謂仮想通貨とは異なり、この記録自体では決済は完了せず、単に注文〜決済に関する情報が記録されるだけである。本実施形態では、取引決済情報に関わる関係者間で契約に基づき、承認又は定められた方法で初めて決済が完了する（債権債務関係の成立）。

ユーザシステム１０〜清算機関システム４０は、ピア・ツー・ピア（Peer to Peer）のネットワークで接続されている。このピア・ツー・ピアは、多数のシステム間で通信を行なうためのアーキテクチャのひとつであり、ピア同士が通信を行なう通信方式の基盤システムである。例えば、情報の改ざんを防止するために、ブロックチェーン方式を用いることができる。ブロックチェーン方式では、「取引の記録」をまとめた「ブロック」を「チェーン」状に順次追加していく。ブロックチェーンを構成するそれぞれのブロックは、そのブロックと一つ前のブロックに関する情報を含む「ヘッダ」と、ある時間内に行なわれた取引のリストを記録した「トランザクション」とにより構成される。ブロックチェーンにおいては、過去からの全取引記録が記録されているため、仮に不正を行なおうとした場合、不正以降の全ブロックを書き換える必要があり、計算負荷が大きく改ざんを困難にしている。そして、ピア・ツー・ピアネットワークに接続されている各システムは、一つのピアが発信した情報を、それぞれで分散して共有することになる。

そして、ユーザシステム１０〜清算機関システム４０は、それぞれ、ピア・ツー・ピアネットワークにおいて共有する情報を保存する分散台帳Ｄ１を保持する。一つのシステムの分散台帳Ｄ１に、所定の情報が書き込まれた場合、ピア・ツー・ピアネットワークにより、他のすべてのシステムが保有する分散台帳Ｄ１に、同じ分散情報が書き込まれる。

（ハードウェア構成例）
図２は、ユーザシステム１０〜清算機関システム４０等として機能する情報処理装置Ｈ１０のハードウェア構成例である。

情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を有する。なお、このハードウェア構成は一例であり、他のハードウェアを有していてもよい。

通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。

入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイやタッチパネル等である。

記憶部Ｈ１４は、ユーザシステム１０〜清算機関システム４０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置（例えば、情報記憶部Ｍ２）である。例えば、記憶部Ｈ１４は、情報記憶部Ｍ２に示した情報を記憶する。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。

プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、ユーザシステム１０〜清算機関システム４０における各処理（例えば、台帳管理部Ｍ１における処理）を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサＨ１５は、ユーザシステム１０〜清算機関システム４０のアプリケーションプログラムが起動された場合、後述する図５、図６に示す各処理を実行するプロセスを動作させる。

プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行うものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行う専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサは、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。

（各情報処理装置の機能）
図３に示すように、ユーザシステム１０〜清算機関システム４０は、それぞれ、台帳管理部Ｍ１、情報記憶部Ｍ２を備える。台帳管理部Ｍ１は、自システムの情報記憶部Ｍ２に書き込まれた情報を、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に書き込む。

図３（ａ）に示すユーザシステム１０は、買い注文、売り注文の注文者が用いるコンピュータシステムである。ユーザシステム１０は、制御部１１を備える。制御部１１は、注文者の入力に応じて、注文情報を生成し、取引所システム２０に送信する。

図３（ｂ）に示す取引所システム２０は、各注文者の注文情報（買い注文、売り注文）を取得し、注文条件が整合する注文の約定を管理する取引所のコンピュータシステムである。この取引所システム２０は、取引管理部２１、参加者情報記憶部２２、取引情報記憶部２４を備える。

取引管理部２１は、各銘柄について、売り注文と買い注文とをマッチングして、約定成立させる処理を行なう。このため、取引管理部２１は、約定成立を行なう条件について、予め定められたルールを保持している。ルールとしては、例えば、約定成立させるタイミング（１時間毎、１日毎）や、複数の同一注文が分散台帳Ｄ１上に記録されている場合の約定成立させる注文を特定する条件（時間優先または抽選等）がある。
また、注文者が他の決済口座管理機関に口座を保有する場合には、取引管理部２１は、決済承認依頼を行なう。

参加者情報記憶部２２には、取引所の参加者を管理するための参加者管理情報が記録される。この参加者管理情報には、参加者コード、保有口座が記録される。
参加者コードデータ領域には、取引所の参加者（注文者）を特定するための識別子に関するデータが記録される。

保有口座データ領域には、この参加者の決済口座管理機関の口座を特定するための識別子に関するデータが記録される。参加者自身が決済口座管理機関の場合には、参加者自身の決済口座管理機関の口座を特定するための識別子に関するデータが記録される。また、他の決済口座管理機関に口座を保有している場合には、他の決済口座管理機関及び口座を特定するための識別子に関するデータが記録される。

取引情報記憶部２４には、注文情報に基づいて約定された取引管理情報が記録される。この取引管理情報には、取引コード、約定日、銘柄、買い注文者、売り注文者、約定金額、数量に関する情報が記録される。

取引コードデータ領域には、各注文を特定するための識別子に関するデータが記録される。
約定日データ領域には、約定成立の年月日及び時刻に関するデータが記録される。

銘柄データ領域には、約定成立した取引対象（証券銘柄）を特定するための識別子に関するデータが記録される。

買い注文者、売り注文者データ領域には、それぞれ約定成立した取引の銘柄の買い注文者、売り注文者を特定するための識別子に関するデータが記録される。
約定金額データ領域には、約定成立した取引金額に関するデータが記録される。
数量データ領域には、約定成立した取引数量に関するデータが記録される。

図３（ｃ）に示す決済口座管理機関システム３０は、各注文者の口座を管理する金融機関のコンピュータシステムである。この決済口座管理機関システム３０は、口座管理部３１、口座情報記憶部３２を備える。
口座管理部３１は、注文者の口座を管理する処理を実行する。本実施形態では、取引所システム２０からの承認依頼に応じて、注文者の口座に残高があることを確認した上で決済承認を行なう。

口座情報記憶部３２には、注文者が決済口座管理機関に保有する口座を管理するための口座管理情報が記録される。この口座管理情報には、参加者コード、口座識別子、残高、入出金履歴が記録される。

参加者コードデータ領域には、取引所の参加者（注文者）を特定するための識別子に関するデータが記録される。
口座識別子データ領域には、この参加者の口座を特定するための識別子に関するデータが記録される。
残高データ領域には、この口座の残高に関するデータが記録される。
入出金履歴データ領域には、この口座への入金や、この口座からの出金の履歴情報が記録される。

図３（ｄ）に示す清算機関システム４０は、取引所から取得した取引情報に基づいて、注文者間の決済を清算する清算機関（ＣＣＰ：セントラル・カウンターパーティ）のコンピュータシステムである。清算機関における清算には、決済口座管理機関等が参加する。なお、注文者自身が決済口座管理機関の場合も、この清算に参加する。この清算機関システム４０は、清算管理部４１、決済情報記憶部４２を備える。

清算管理部４１は、取引所システム２０において行なわれた取引についての決済（本実施形態では、ＤＶＰ決済）を行なう。そして、清算管理部４１は、ネッティングに基づいて清算予定情報を生成し、分散台帳Ｄ１に記録する。

決済情報記憶部４２には、約定成立した取引についてネッティングを行なった決済予定情報が記録される。決済予定情報には、決済予定日、決済口座管理機関、銘柄、決済予定数量、決済予定金額に関する情報が含まれる。

決済予定日データ領域には、ＤＶＰ決済を行なう予定日に関するデータが記録される。
決済口座管理機関データ領域には、決済口座管理機関を特定するための識別子に関するデータが記録される。

銘柄データ領域には、約定成立した取引対象（証券銘柄）を特定するための識別子に関するデータが記録される。
決済予定数量、決済予定金額の各データ領域には、それぞれ、決済予定の証券数量、支払予定金額に関するデータが記録される。

（分散台帳に記録される情報）
図４に示すように、分散台帳Ｄ１には、注文情報５１０、約定成立情報５２０、失効情報５３０、承認依頼情報５４０、決済承認情報５５０、決済予告情報５６０、決済完了情報５７０が記録される。

図４（ａ）に示すように、注文情報５１０には、発行番号、銘柄、売買識別子、注文者、指値、数量に関する情報が含まれる。この注文情報５１０は、必要に応じて、本取引に関わる関係者（ユーザシステム１０〜清算機関システム４０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、取引のための注文を特定するための識別子に関するデータが記録される。実施形態では、この発行番号は、分散台帳Ｄ１に記録される一連の情報を特定するための識別子として用いられる。
銘柄データ領域には、取引対象の証券を特定するための識別子に関するデータが記録される。

売買識別子データ領域には、「売り」又は「買い」を特定するためのフラグが記録される。
注文者データ領域には、この注文の注文者を特定するための識別子に関するデータが記録される。

指値データ領域には、この銘柄の取引希望価格に関するデータが記録される。
数量データ領域には、この銘柄の取引希望数量に関するデータが記録される。

図４（ｂ）に示すように、約定成立情報５２０には、発行番号、銘柄、買い注文者、売り注文者、約定金額、数量に関する情報が含まれる。この約定成立情報５２０は、必要に応じて、本取引に関わる関係者（ユーザシステム１０〜清算機関システム４０等）で復号可能なキーにより暗号化される。
発行番号データ領域には、約定された取引を特定するための識別子に関するデータが記録される。ここでは、買い注文、売り注文についての発行番号（例えば、注文情報５１０の発行番号）を含める。
銘柄データ領域には、取引対象の証券を特定するための識別子に関するデータが記録される。

買い注文者、売り注文者の各データ領域には、それぞれ、約定された注文の買い注文者、売り注文者を特定するための識別子に関するデータが記録される。
約定金額、数量の各データ領域には、それぞれ、約定された取引の約定金額、数量に関するデータが記録される。

図４（ｃ）に示すように、失効情報５３０には、発行番号、注文失効に関する情報が含まれる。この失効情報５３０は、必要に応じて、本取引に関わる関係者（ユーザシステム１０〜清算機関システム４０等）で復号可能なキーにより暗号化される。
発行番号データ領域には、取引のための注文を特定するための識別子（例えば、注文情報５１０の発行番号）に関するデータが記録される。
注文失効データ領域には、この注文が他の注文と約定成立しなかったことを示すフラグが記録される。

図４（ｄ）に示すように、承認依頼情報５４０には、発行番号、銘柄、売買識別子、注文者、約定金額、数量、決済口座管理機関に関する情報が含まれる。この承認依頼情報５４０は、必要に応じて、本取引に関わる関係者（ユーザシステム１０〜清算機関システム４０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、約定された取引を特定するための識別子（例えば、注文情報５１０の発行番号）に関するデータが記録される。
銘柄データ領域には、約定された取引対象の証券を特定するための識別子に関するデータが記録される。

売買識別子データ領域には、約定された取引対象の「売り」又は「買い」を特定するためのフラグが記録される。
注文者データ領域には、この取引所の参加者である注文者を特定するための識別子に関するデータが記録される。
約定金額、数量の各データ領域には、それぞれ、約定された取引の約定金額、数量に関するデータが記録される。
決済口座管理機関データ領域には、注文者が口座を保有する決済口座管理機関であって、取引承認を依頼する決済口座管理機関を特定するための識別子に関するデータが記録される。

図４（ｅ）に示すように、決済承認情報５５０には、発行番号、銘柄、売買識別子、注文者、決済口座管理機関、承認結果に関する情報が含まれる。この決済承認情報５５０は、必要に応じて、本取引に関わる関係者（ユーザシステム１０〜清算機関システム４０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、約定された取引を特定するための識別子（例えば、注文情報５１０の発行番号）に関するデータが記録される。
銘柄データ領域には、約定された取引対象の証券を特定するための識別子に関するデータが記録される。

売買識別子データ領域には、約定された取引対象の「売り」又は「買い」を特定するためのフラグが記録される。
注文者データ領域には、この取引所の参加者である注文者を特定するための識別子に関するデータが記録される。

決済口座管理機関データ領域には、取引承認を行なった決済口座管理機関を特定するための識別子に関するデータが記録される。
承認結果データ領域には、取引承認の結果を特定するためのフラグが記録される。

図４（ｆ）に示すように、決済予告情報５６０には、発行番号、決済対象者、決済予定日時、決済内容に関する情報が含まれる。この決済予告情報５６０は、必要に応じて、本取引に関わる関係者（ユーザシステム１０〜清算機関システム４０等）で復号可能なキーにより暗号化される。
発行番号データ領域には、決済予告を特定するための識別子に関するデータが記録される。
決済対象者データ領域には、決済対象者を特定するための識別子に関するデータが記録される。ここで、決済対象者は、注文者、決済口座管理機関（参加者が決済口座管理機関の場合も含む）である。

決済予定日時データ領域には、決済を行なう年月日及び時刻に関するデータが記録される。
決済内容データ領域には、決済対象の内容が記録される。例えば、注文者の取引については、銘柄毎の累計（数量）、取引金額の累計が記録される。決済口座管理機関については、銘柄毎の累計（数量）、取引金額の累計が記録される。

図４（ｇ）に示すように、決済完了情報５７０には、発行番号、決済完了に関する情報が含まれる。この決済完了情報５７０は、必要に応じて、本取引に関わる関係者（ユーザシステム１０〜清算機関システム４０等）で復号可能なキーにより暗号化される。
発行番号データ領域には、決済予告を特定するための識別子に関するデータが記録される。
決済完了データ領域には、決済予告についてのＤＶＰ決済を完了したことを示すフラグが記録される。

（取引処理）
次に、図５〜図７を用いて、取引処理を説明する。ここでは、例えば、注文情報５１０〜決済完了情報５７０として、ブロックチェーンを利用するオープンアセットプロトコルによるカラードコインを用いる。

まず、図５に示すように、ユーザシステム１０は、注文情報の登録処理を実行する（ステップＳ１−１）。具体的には、売り注文者、買い注文者は、ユーザシステム１０を用いて、注文情報を作成する。この注文情報には、銘柄、「売り」又は「買い」を示す売買識別子、指値、数量に関する情報を含める。そして、注文指示が入力された場合、制御部１１は、注文情報５１０、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に注文情報５１０を書き込む。
図７に示すように、売り注文ｓ１〜ｓ４、買い注文ｂ１〜ｂ３の注文情報５１０が、分散台帳Ｄ１に記録された場合を想定する。

次に、取引所システム２０は、マッチング処理を実行する（ステップＳ１−２）。具体的には、取引所システム２０の取引管理部２１は、分散台帳Ｄ１に記録された注文情報５１０の中で、発行番号により約定成立情報５２０や失効情報５３０が関連付けられていない、約定可能な注文情報５１０を特定する。そして、取引管理部２１は、各銘柄の注文情報５１０について、予め定められたルール（約定成立を行なう条件）に基づいて、同じ銘柄の買い注文及び売り注文の指値をマッチングする。そして、取引管理部２１は、指値に応じて約定可能な買い注文及び売り注文を検索する。

次に、取引所システム２０は、約定成立かどうかについての判定処理を実行する（ステップＳ１−３）。具体的には、取引所システム２０の取引管理部２１は約定可能な買い注文及び売り注文を特定できた場合には、約定成立と判定する。

約定成立と判定した場合（ステップＳ１−３において「ＹＥＳ」の場合）、取引所システム２０は、約定成立登録処理を実行する（ステップＳ１−４）。具体的には、取引所システム２０の取引管理部２１は、約定成立した注文がある場合には、注文情報に基づいて取引管理情報を生成し、取引情報記憶部２４に記録する。そして、取引管理部２１は、取引が成立した売り注文及び買い注文の発行番号に基づいて発行番号を付与した約定成立情報５２０を生成する。この約定成立情報５２０には、発行番号、約定された取引の銘柄、買い注文者、売り注文者、約定金額、数量に関するデータを含める。そして、取引所システム２０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、約定成立情報５２０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に約定成立情報５２０を書き込む。

図７に示すように、「売り注文ｓ１と買い注文ｂ３」、「売り注文ｓ２と買い注文ｂ１」、「売り注文ｓ４と買い注文ｂ２」が約定成立した場合を想定する。この場合、各約定成立について約定成立情報５２０を分散台帳Ｄ１に記録する。

一方、約定可能な注文がなく、約定不成立と判定した場合（ステップＳ１−３において「ＮＯ」の場合）、取引所システム２０は、約定成立登録処理（ステップＳ１−４）をスキップする。

次に、取引所システム２０は、約定注文以外の注文の失効登録処理を実行する（ステップＳ１−５）。具体的には、取引所システム２０の取引管理部２１は、分散台帳Ｄ１に記録された注文情報５１０において、約定成立しなかった注文情報５１０を特定する。そして、取引管理部２１は、特定した注文情報５１０の発行番号を記録した失効情報５３０を生成して、情報記憶部Ｍ２の分散台帳Ｄ１に、失効情報５３０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に失効情報５３０を書き込む。

次に、図６に示すように、取引所システム２０は、他の決済口座管理機関の登録があるかどうかについての判定処理を実行する（ステップＳ２−１）。具体的には、取引所システム２０の取引管理部２１は、参加者情報記憶部２２を用いて、約定成立した注文者（参加者）の決済口座管理機関を特定する。この場合、参加者自身が決済口座管理機関の場合と、参加者が他の決済口座管理機関の口座を保有する決済口座管理機関利用者の場合とがある。少なくとも一人の注文者の参加者管理情報に他の決済口座管理機関情報が記録されている場合には、他の決済口座管理機関の登録があると判定する。

他の決済口座管理機関の登録があると判定した場合（ステップＳ２−１において「ＹＥＳ」の場合）、取引所システム２０は、承認依頼処理を実行する（ステップＳ２−２）。具体的には、取引所システム２０の取引管理部２１は、参加者情報記憶部２２を用いて、注文者が他の決済口座管理機関に保有する口座を特定する。そして、取引管理部２１は、特定した他の決済口座管理機関に決済の承認を依頼するための承認依頼情報５４０を生成する。この承認依頼情報５４０には、発行番号、銘柄、売買識別子、注文者、約定金額、数量、決済口座管理機関に関するデータを含める。そして、取引所システム２０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、承認依頼情報５４０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に承認依頼情報５４０を書き込む。
一方、他の決済口座管理機関の登録がないと判定した場合（ステップＳ２−１において「ＮＯ」の場合）、取引所システム２０は、承認依頼処理（ステップＳ２−２）をスキップする。

次に、取引所システム２０は、注文者が決済口座管理機関かどうかについての判定処理を実行する（ステップＳ２−３）。具体的には、取引所システム２０の取引管理部２１は、参加者情報記憶部２２を用いて、他の決済口座管理機関が登録されていない注文者を検索する。他の決済口座管理機関が登録されていない注文者を特定できた場合には、注文者（参加者）自身が決済口座管理機関と判定する。

注文者が決済口座管理機関と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、取引所システム２０は、自動承認処理を実行する（ステップＳ２−４）。具体的には、取引所システム２０の取引管理部２１は、注文者（参加者）自身が決済可能と判定し、自動承認の決済承認情報５５０を生成する。そして、取引管理部２１は、情報記憶部Ｍ２の分散台帳Ｄ１に、決済承認情報５５０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に決済承認情報５５０を書き込む。
一方、すべての注文者が決済口座管理機関でないと判定した場合（ステップＳ２−３において「ＮＯ」の場合）、取引所システム２０は、自動承認処理（ステップＳ２−４）をスキップする。

承認依頼情報５４０を取得した決済口座管理機関システム３０は、決済承認処理を実行する（ステップＳ２−５）。具体的には、決済口座管理機関システム３０の口座管理部３１は、分散台帳Ｄ１に記録された承認依頼情報５４０を用いて、口座情報記憶部３２において、注文者の口座を特定する。次に、口座管理部３１は、注文者の口座残高において、決済可能な場合には、決済承認情報５５０を生成する。そして、決済口座管理機関システム３０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、決済承認情報５５０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に決済承認情報５５０を書き込む。

図７に示すように、「売り注文ｓ１」、「売り注文ｓ２」、「買い注文ｂ１」、「買い注文ｂ２」は、取引所以外の決済口座管理機関を利用している場合を想定する。この場合、各約定についての決済承認情報５５０を分散台帳Ｄ１に記録する。

次に、清算機関システム４０は、分散台帳Ｄ１を用いた集計処理を実行する（ステップＳ２−６）。具体的には、清算機関システム４０の清算管理部４１は、分散台帳Ｄ１に記録された決済承認を用いて、承認した（自動承認分も含む）決済口座管理機関の取引内容を集計する。ここでは、銘柄毎に約定数量及び全約定金額を集計する。

次に、清算機関システム４０は、分散台帳Ｄ１を用いた決済予告処理を実行する（ステップＳ２−７）。具体的には、清算機関システム４０の清算管理部４１は、清算機関への参加者（注文者や決済口座管理機関）毎に、約定を集計した約定数量、約定金額（約定数量、約定金額）を含めた決済予告情報５６０を生成する。清算機関システム４０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、決済予告情報５６０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に決済予告情報５６０を書き込む。

図７に示すように、清算機関への参加者、決済口座管理機関について、それぞれの決済予告情報５６０を分散台帳Ｄ１に記録する。

次に、清算機関システム４０は、ＤＶＰ決済処理を実行する（ステップＳ２−８）。具体的には、清算機関システム４０の清算管理部４１は、決済予告情報５６０の決済予定日時に到達した場合に、ＤＶＰ決済を行なう。

次に、清算機関システム４０は、決済完了登録処理を実行する（ステップＳ２−９）。具体的には、清算機関システム４０の清算管理部４１は、決済完了情報５７０を生成する。そして、清算機関システム４０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、決済完了情報５７０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に決済完了情報５７０を書き込む。
図７に示すように、決済予告情報５６０に対応した決済完了情報５７０を分散台帳Ｄ１に記録する。

本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、注文情報５１０、約定成立情報５２０、失効情報５３０、承認依頼情報５４０、決済承認情報５５０、決済予告情報５６０、決済完了情報５７０が分散台帳Ｄ１に記録される。これにより、取引の関係者が、取引内容や取引状況を確認することができる。そして、ブロックチェーンを用いた分散台帳Ｄ１により、分散台帳による情報共有技術と、ブロックチェーン等による記録の改竄防止技術とを利用して、記録の内容が不変で、記録の照合が容易であり、迅速で効率的な証券取引、すなわち約定から決済までの一連の処理を支援することができる。

（２）本実施形態では、ユーザシステム１０は、注文情報の登録処理を実行する（ステップＳ１−１）。また、取引所システム２０は、マッチング処理（ステップＳ１−２）、約定成立かどうかについての判定処理（ステップＳ１−３）を実行する。そして、約定可能な注文があると判定した場合（ステップＳ１−３において「ＹＥＳ」の場合）、取引所システム２０は、約定成立登録処理を実行する（ステップＳ１−４）。これにより、特定の銘柄について複数の注文の中で、所定のルールに基づいて条件が合う注文を約定させて、注文を完結させることができる。

（３）本実施形態では、取引所システム２０は、約定注文以外の注文の失効登録処理を実行する（ステップＳ１−５）。これにより、約定できなかった注文情報５１０を、分散台帳上において、失効させて、注文を完結させることができる。

（４）本実施形態では、他の決済口座管理機関の登録があると判定した場合（ステップＳ２−１において「ＹＥＳ」の場合）、取引所システム２０は、承認依頼処理を実行する（ステップＳ２−２）。そして、決済口座管理機関システム３０は、決済承認処理を実行する（ステップＳ２−５）。これにより、取引所以外で、注文者の口座が管理されている場合にも、分散台帳Ｄ１に記録された承認に基づいて決済手続を進めることができる。

（５）本実施形態では、注文者が決済口座管理機関と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、取引所システム２０は、自動承認処理を実行する（ステップＳ２−４）。これにより、注文者が決済口座管理機関の場合、分散台帳Ｄ１に記録された承認に基づいて決済手続を進めることができる。

（６）本実施形態では、清算機関システム４０は、分散台帳Ｄ１を用いた集計処理（ステップＳ２−６）、分散台帳Ｄ１を用いて決済予告処理（ステップＳ２−７）、ＤＶＰ決済処理（ステップＳ２−８）を実行する。これにより、個々の取引を集約して、効率的に決済を行なうことができる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、注文情報５１０〜決済完了情報５７０として、ビットコインのブロックチェーンを利用するオープンアセットプロトコル（カラードコイン）を用いる場合を想定した。分散台帳Ｄ１に記録される各情報は、カラードコインに限定されるものではない。ビットコイン以外の分散台帳Ｄ１を応用した、通貨以外の役割・機能を持たすことを主目的とした基盤システムを利用することができる。

・上記実施形態では、注文情報５１０〜決済完了情報５７０を分散台帳Ｄ１に記録する。分散台帳Ｄ１に記録する情報はこれらに限定されるものではない。
・上記実施形態では、清算機関システム４０は、分散台帳Ｄ１を用いた集計処理（ステップＳ２−６）、分散台帳Ｄ１を用いた決済予告処理（ステップＳ２−７）を実行する。ここで、約定された取引情報と、決済口座管理機関毎に集計した決済予告とをリンクさせる情報を、分散台帳Ｄ１に記録してもよい。
・上記実施形態では、清算機関システム４０は、分散台帳Ｄ１を用いた集計処理（ステップＳ２−６）、分散台帳Ｄ１に決済予告処理（ステップＳ２−７）、ＤＶＰ決済処理（ステップＳ２−８）を実行する。この場合、各参加者が決済予告の内容を確認し、決済予告承認情報を分散台帳Ｄ１に記録するようにしてもよい。この場合、清算機関システム４０は、決済予告承認情報に基づいて、ＤＶＰ決済処理を実行する（ステップＳ２−８）。

・上記実施形態では、取引所システム２０は、約定成立登録処理を実行する（ステップＳ１−４）。この場合、取引管理部２１は、約定が成立した売り注文及び買い注文の発行番号に基づいて発行番号を付与した約定成立情報５２０を生成する。ここで、約定成立情報５２０と各注文情報５１０とを関連付ける情報は、発行番号に限定されるものではない。例えば、約定成立情報５２０に、各注文情報５１０の発行番号を含めてもよい。
また、注文情報５１０毎に約定成立情報５２０を生成するようにしてもよい。この場合には、約定成立情報５２０に、取引約定した相手方の注文情報の発行番号を記録しておく。
・上記実施形態では、分散台帳Ｄ１に記録する情報は、必要に応じて、本取引に関わる関係者で復号可能なキーにより暗号化される。暗号化の必要性は、ネットワークや情報に応じて行なえばよい。例えば、関係者のみが用いるクローズド型（プライベート型）ネットワークの場合には、暗号化の必要はない。
・上記実施形態では、分散台帳Ｄ１に記録される一連の情報を特定するための識別子として、注文情報５１０の発行番号等を用いる。一連の情報を特定できる識別子であれば、注文情報５１０の発行番号に限定されるものではない。

１０…ユーザシステム、１１…制御部、２０…取引所システム、２１…取引管理部、２２…参加者情報記憶部、２４…取引情報記憶部、３０…決済口座管理機関システム、３１…口座管理部、３２…口座情報記憶部、４０…清算機関システム、４１…清算管理部、４２…決済情報記憶部、Ｄ１…分散台帳、Ｍ１…台帳管理部、Ｍ２…情報記憶部。

Claims (6)

1. 注文者システムに接続される取引所システムが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された清算機関システムを含む決済システムであって、
   前記取引所システムが、
   前記分散台帳に記録され、約定可能な注文情報を取得し、
   前記取得した注文情報のマッチングを行なうことにより、約定した注文情報を特定し、
   約定されなかった注文情報について、失効情報を前記分散台帳に記録し、
   前記約定された注文情報の発注者が決済口座管理機関であると判定した場合には、前記決済口座管理機関の口座を用いて決済を行なう決済承認情報を前記分散台帳に記録し、
   前記清算機関システムが、
   前記約定された注文情報に基づいて決済を行なうことを特徴とする決済システム。
2. 注文者システムに接続される取引所システムが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された清算機関システムを含む決済システムであって、
   前記取引所システムが、
   前記分散台帳に記録され、約定可能な注文情報を取得し、
   前記取得した注文情報のマッチングを行なうことにより、約定した注文情報を特定し、
   約定されなかった注文情報について、失効情報を前記分散台帳に記録し、
   前記約定された注文情報の発注者及び受注者の少なくとも何れか一方が自身以外を決済口座管理機関として登録している決済口座管理機関利用者と判定した場合には、前記決済口座管理機関利用者の決済口座管理機関システムに対して、承認依頼を送信し、
   前記清算機関システムが、
   前記決済口座管理機関システムの決済承認情報が前記分散台帳に記録された場合に、前記約定された注文情報に基づいて決済を行なうことを特徴とする決済システム。
3. 前記清算機関システムが、
   前記約定された注文情報に基づいて、決済予告を前記分散台帳に記録し、
   前記決済予告の後で決済を行なうことを特徴とする請求項１又は２に記載の決済システム。
4. 前記清算機関システムが、前記約定された注文情報の取引者毎に、取引金額を集計して前記決済予告を行なうことを特徴とする請求項３に記載の決済システム。
5. 注文者システムに接続される取引所システムが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された清算機関システムを含む決済システムを用いて、決済を支援する方法であって、
   前記取引所システムが、
   前記分散台帳に記録され、約定可能な注文情報を取得し、
   前記取得した注文情報のマッチングを行なうことにより、約定した注文情報を特定し、
   約定されなかった注文情報について、失効情報を前記分散台帳に記録し、
   前記約定された注文情報の発注者が決済口座管理機関であると判定した場合には、前記決済口座管理機関の口座を用いて決済を行なう決済承認情報を前記分散台帳に記録し、
   前記清算機関システムが、
   前記約定された注文情報に基づいて決済を行なうことを特徴とする決済方法。
6. 注文者システムに接続される取引所システムが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された清算機関システムを含む決済システムを用いて、決済を支援する方法であって、
   前記取引所システムが、
   前記分散台帳に記録され、約定可能な注文情報を取得し、
   前記取得した注文情報のマッチングを行なうことにより、約定した注文情報を特定し、
   約定されなかった注文情報について、失効情報を前記分散台帳に記録し、
   前記約定された注文情報の発注者及び受注者の少なくとも何れか一方が自身以外を決済口座管理機関として登録している決済口座管理機関利用者と判定した場合には、前記決済口座管理機関利用者の決済口座管理機関システムに対して、承認依頼を送信し、
   前記清算機関システムが、
   前記決済口座管理機関システムの決済承認情報が前記分散台帳に記録された場合に、前記約定された注文情報に基づいて決済を行なうことを特徴とする決済方法。

Images