JPWO2016207981A1 - 証券取引管理システム - Google Patents

Abstract

複数のセルサイドが提供するダークプールの連携、もしくは複数のセルサイドが参加するダークプールの実現を可能とし、さらにバイサイドの潜在的な注文についてもマッチングを可能とする証券取引管理システムを提供する。代表的な実施の形態によれば、証券取引に参加する参加者となるバイサイドもしくはセルサイドにおいて相手方との間の注文を管理する注文管理システムを含む１つ以上の情報処理システムと、各情報処理システムから取得した、各参加者のＩＯＩの情報をデータベースに記録し、各ＩＯＩに含まれる注文の間で売り買いをマッチングさせるポテンシャルオーダープールシステムとを有する。

Description

本発明は、証券取引の技術に関し、特に、ダークプールを利用した取引を支援する証券取引管理システムに適用して有効な技術に関するものである。

証券会社（セルサイド）では、機関投資家などの資産運用会社（バイサイド）からの大口の有価証券取引の注文を受けて、市場等を介して実際の取引を行っている。近年では、例えば、大口の売買を市場で行うことによる取引価格への影響の回避などのため、セルサイド内の情報処理システムにおいて投資家の売買注文をマッチングさせて取引を行うといういわゆるダークプールのサービスも行われている。ここでは、取引参加者の情報や価格、注文量などの注文情報の匿名性が確保されるとともに、約定率や約定単価の改善などが期待できることから、ファンドにおける個別銘柄の売買に係る運用計画等を秘匿したい機関投資家などを対象に利用が拡大している。

ダークプールに関する技術としては、例えば、特開２０１０−２２４７１０号公報（特許文献１）には、新規注文情報を社内取引システムと外部の取引市場システムの双方に対して同時に送信する方式をとることで、社内ダークプールと証券取引所のいずれに注文を回送すべきかの判断に伴う時間的な損失を低減可能とする仕組みが記載されている。

また、特開２０１３−１３０９３６号公報（特許文献２）には、複数種類のアルゴリズム取引のタイプを有するアルゴリズム取引群に対応したマッチングロジックに基づいて売買注文データ同士のマッチング処理を所定間隔で定期的に行うことで、ダークプール環境下での注文条件が複雑化したアルゴリズム注文の約定率を向上させる仕組みが記載されている。

特開２０１０−２２４７１０号公報 特開２０１３−１３０９３６号公報

従来技術では、各セルサイドが提供するダークプールにおいて各バイサイドが注文情報の匿名性を確保しつつ取引を行うことができる。しかしながら、例えば、他のセルサイドが提供するダークプールとの連携や、複数のセルサイドが参加するダークプールの実現といった流動性を高める、より高度かつ拡張された仕組みについては実現が困難である。

また、従来技術では、実際に行なわれた注文に基づいてマッチングを行い、取引を成立させることは行われている。しかしながら、例えば、バイサイドが運用計画として持っている将来の潜在的な注文についてはマッチングの対象にできないため、結果的に取引タイミングや執行先について必ずしも最適とはいえない条件で取引を行うことになる場合も生じている。

そこで本発明の目的は、複数のセルサイドが提供するダークプールの連携、もしくは複数のセルサイドが参加するダークプールの実現を可能とし、さらにバイサイドの潜在的な注文についてもマッチングを可能とする証券取引管理システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による証券取引管理システムは、相手方からの注文を受けてセルサイドが行う証券取引を管理する証券取引管理システムであって、証券取引に参加する参加者となるバイサイドもしくはセルサイドにおいて相手方との間の注文を管理する注文管理システムを含む１つ以上の情報処理システムと、前記各情報処理システムから取得した、前記各参加者のＩＯＩ（Indication of Interest）の情報をデータベースに記録し、前記各ＩＯＩに含まれる注文の間で売り買いをマッチングさせるポテンシャルオーダープールシステムと、を有するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、複数のセルサイドが提供するダークプールの連携、もしくは複数のセルサイドが参加するダークプールの実現が可能となり、さらにバイサイドの潜在的な注文についてもマッチングを可能とすることが可能となる。

本発明の実施の形態１である証券取引管理システムの構成例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰサービスの例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドとセルサイドとの間のマッチングの例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドとセルサイドとの間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチングの例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチングの他の例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチング処理の他の例について概要を示したシーケンス図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドセルサイドとの間のマッチングの他の例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドとセルサイドとの間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態２におけるＰＯＰでの参加者間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態２におけるＰＯＰでの参加者間のマッチング処理の他の例について概要を示したシーケンス図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態１）
＜システム構成＞
図１は、本発明の実施の形態１である証券取引管理システムの構成例について概要を示した図である。証券取引管理システム１は、複数のバイサイドシステム３００、複数のセルサイドシステム２００、およびポテンシャルオーダープールシステム１００の各情報処理システムがインターネット等のネットワーク１０に接続された構成を有する。バイサイドシステム３００は、各バイサイド３０（運用会社等）が有する注文管理システム等を含む情報処理システムであり、セルサイドシステム２００は、各セルサイド２０（証券会社等）が有する注文管理システム等を含む情報処理システムである。

ポテンシャルオーダープールシステム１００は、各バイサイド３０や各セルサイド２０とは独立した中立の事業者により運用管理される情報処理システムであり、各バイサイド３０や各セルサイド２０から「ポテンシャルオーダー」を含むＩＯＩ（Indication of Interest：「取引意思の表示」）の情報を取得して蓄積し、売り買いをマッチングして取引を成立させる「ポテンシャルオーダープール（以下では「ＰＯＰ」と略記する場合がある）」サービスをＡＳＰ（Application Service Provider）サービス等として提供する機能を有する。ＰＯＰサービスの内容については後述する。

各セルサイド２０の担当者等は、自身が使用する情報処理端末であるセルサイド端末２１の図示しないＷｅｂブラウザ等を利用して自社のセルサイドシステム２００にアクセスし、セルサイド２０としての業務を行う。直接ＰＯＰシステム１００にアクセスしてデータの授受等を行ってもよい。同様に、各バイサイド３０の担当者等は、自身が使用する情報処理端末であるバイサイド端末３１の図示しないＷｅｂブラウザ等を利用して自社のバイサイドシステム３００にアクセスし、バイサイド３０としての業務を行う。直接ＰＯＰシステム１００にアクセスしてデータの授受等を行ってもよい。

ＰＯＰシステム１００、セルサイドシステム２００、およびバイサイドシステム３００の各システムは、それぞれが例えば１つ以上のサーバ機器やクラウドコンピューティングサービス上で構築された仮想サーバなどにより実装される。バイサイド３０およびセルサイド２０からの「ポテンシャルオーダー」を含むＩＯＩの情報を一元的に蓄積してＰＯＰサービスを提供するという観点からは、例えば、各システムは同じＩＴ事業者により共通のシステム基盤上で運用・監視されているのが望ましいが、必ずしもこれに限られない。

セルサイドシステム２００は、例えば、セルサイド２０側の注文管理システム（ＯＭＳ：Order Management System）であるセルサイドＯＭＳ２１０、およびバックオフィスシステムであるバックシステム２２０を有する。セルサイドＯＭＳ２１０は、東京証券取引所などの取引所システム４０に対してネットワーク１０等を介してオンラインで売買注文の執行を行う機能も有している。また、バイサイドシステム３００は、例えば、バイサイド３０側の注文管理システムであるバイサイドＯＭＳ３１０、およびバックオフィスシステムであるバックシステム３２０を有する。

ＰＯＰシステム１００は、例えば、データベースやファイルテーブルなどにより実装されるポテンシャルオーダープール（ＰＯＰ）データベース（ＤＢ）１２１、バイサイドマスタＤＢ１２２、セルサイドマスタＤＢ１２３、および設定ＤＢ１２４などの各データストアを有する。各バイサイド３０および各セルサイド２０に対してＰＯＰサービスを提供する機能を有するソフトウェアとして実装されたマッチング処理部１１０などの各部を有していてもよい。

ＰＯＰＤＢ１２１は、セルサイドシステム２００（もしくはセルサイド端末２１）やバイサイドシステム３００（もしくはバイサイド端末３１）から取得した「ポテンシャルオーダー」を含むＩＯＩの情報を保持するテーブルである。これ以外にも、注文処理に用いられる各種情報のうち、例えば、バイサイド３０とセルサイド２０との間で開示についての承諾が得られたものなど、共有が可能なデータを保持するものとしてもよい。

バイサイドマスタＤＢ１２２およびセルサイドマスタＤＢ１２３は、それぞれ、ＰＯＰシステム１００にアクセスしてＰＯＰサービスの提供を受けることができるバイサイド３０およびセルサイド２０についてのマスタ情報を保持するテーブルである。ユーザについてのアカウント情報を含んでいてもよい。設定ＤＢ１２４は、ＰＯＰシステム１００における動作や処理等についての各種設定情報を保持するテーブルである。セルサイド２０やバイサイド３０毎に固有の設定情報を保持するようにしてもよい。

マッチング処理部１１０は、ＰＯＰサービスとして、各バイサイド３０や各セルサイド２０からの「ポテンシャルオーダー」を含むＩＯＩの情報を取得、蓄積し、後述するような手法により売り買いをマッチングして取引を成立させる機能を有する。取引成立に係る通知や、その後のバイサイド３０やセルサイド２０の間での受発注、約定の処理を中継、仲介する機能を有していてもよい。

＜ポテンシャルオーダープール（ＰＯＰ）サービス＞
図２は、本実施の形態におけるＰＯＰサービスの例について概要を示した図である。ポテンシャルオーダープール（ＰＯＰ）１２０は、ＰＯＰシステム１００のＰＯＰＤＢ１２１およびマッチング処理部１１０等により実現される概念上のダークプールを模式的に示したものである。

投資家と証券会社との間の取引では、取引を成立させるための有用な参照情報として、ＩＯＩを出して取引相手を探すことが行われる場合がある。この場合、ＩＯＩには、実行する予定の注文についての内容や、希望するもしくは対応が可能な条件などの情報が含まれる。したがって、これを用いることにより、当日に実行の意思を有している取引については効率的にマッチングして成立させることが可能である。

一方で、例えば機関投資家（バイサイド３０）については、必ずしも当日実行することまでは予定していないものの、近い将来には実行することが確実に予定されている取引（以下ではこれを「ポテンシャルオーダー」と記載する）を有している場合がある。例えば、一定期間の運用計画に沿って売買時期を決めている場合や、大口の売買について市場への影響を回避するために複数回に分散して売買する場合などがある。いずれの場合でも、近い将来にどのような売買が行われるか、という情報は、バイサイド３０としては本来秘匿すべき情報であり開示されないのが通常である。

しかしながら、これらのポテンシャルオーダーについても、将来の予定の日に必ず実行するという類のものではなく、例えば、対象の銘柄について当日に特定のセルサイド２０（ブローカー）が特に有利な条件でＩＯＩを出しており、このタイミングで売買することが有効であると判断される場合には、予定に関わらずに当日に売買を行うなどの柔軟な対応がとられる。従来は、このような判断は、例えばバイサイド３０のトレーダーなどの人手の判断によりもたらされていた。

そこで、ダークプールにおける情報の秘匿性を活かし、本実施の形態では、このようなポテンシャルオーダーの情報についてもＩＯＩとしてバイサイド３０から取得してＰＯＰ１２０を形成し、当日の取引としてマッチングの対象とする。

上述したように、例えば、バイサイドシステム３０とＰＯＰシステム１００が同じ中立の事業者により運用管理されている場合は、元々バイサイドシステム３０において管理されていたポテンシャルオーダーの情報が、実質上は同じ事業者によって参照範囲が拡張されるだけに留まるといえ、開示に対する心理的・物理的障害は少ない。また、このような中立の事業者が運用管理するＰＯＰ１２０に対して各セルサイド２０がＩＯＩを出す構成とすることで、複数のセルサイド２０のダークプールの連携が可能となるとともに、ダークプールサービスにおける透明性、公正・公平性を担保することができる。

図２の例では、ＰＯＰ１２０に対してバイサイドＡ（３０ａ）、バイサイドＢ（３０ｂ）、およびセルサイドＡ（２０ａ）、セルサイドＢ（２０ｂ）が参加して、ポテンシャルオーダーを含むＩＯＩの情報（図中ではＩＯＩ３２ａ、３２ｂ、およびＩＯＩ２２ａ、２２ｂの各表で示す）を登録した状態を示している。ＰＯＰシステム１００は、バイサイド３０およびセルサイド２０から、例えばＦＩＸ（Financial Information eXchange）プロトコルでの通信もしくはファイルの送受信によってＩＯＩ情報を取得してＰＯＰＤＢ１２１に蓄積し、マッチング処理部１１０によりＩＯＩ間で売り買いのマッチングを行う。マッチングのアルゴリズム等については特に限定されず、公知の手法を適宜用いることができる。

なお、マッチングの際の約定単価は、例えば、取引所の前日終値や当日仲値とすることができる。また、マッチングは、バイサイド３０とセルサイド２０との間だけに限らず、後述するように、バイサイド３０同士やセルサイド２０同士でマッチングすることも可能である。マッチングが成立した際に対象のバイサイド３０やセルサイド２０に通知される相手方の取引内容の情報は原則として匿名であるが、例えば、設定ＤＢ１２４などに予め取引先として登録されている相手の場合には、当該相手方の情報を開示するようにしてもよい。

＜（１）バイサイド−セルサイド間のマッチング＞
図３は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチングの例について概要を示した図である。図３の例では、バイサイドＡ（３０ａ）が出したＩＯＩ３２ａと、セルサイドＡ（２０ａ）が出したＩＯＩ２２ａにおいて、銘柄“△△”について売り買いがマッチしたことを示している。

この場合、例えば、発注に係る情報は、ＦＩＸプロトコルのメッセージによってバイサイドＡ（３０ａ）のバイサイドシステム３００からセルサイドＡ（２０ａ）のセルサイドシステム２００に対して送信される。セルサイドＡ（２０ａ）では、発注情報に基づいて取引所システム４０に対する注文の執行が行われる。約定に係るデータは、例えば、ＰＯＰシステム１００を介したファイルの授受等によりバイサイドＡ（３０ａ）に送付される。

図４は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチング処理の例について概要を示したシーケンス図である。まず、バイサイド３０（すなわちバイサイドシステム３００もしくはバイサイド端末３１。以下同様。）およびセルサイド２０（すなわちセルサイドシステム２００もしくはセルサイド端末２１。以下同様。）は、ＰＯＰ１２０（すなわちＰＯＰシステム１００。以下同様。）に対して、ＦＩＸプロトコルのメッセージもしくはファイルによりＩＯＩ情報を登録する（Ｓ０１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ０２）、マッチした取引については、対象のバイサイド３０とセルサイド２０に対してそれぞれその旨を通知する（Ｓ０３）。

マッチング結果の通知を受けたバイサイド３０およびセルサイド２０では、それぞれ、マッチした内容に対してＡｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ０４）。ＰＯＰ１２０では、いずれの応答もＡｃｋであった場合に取引成立と判定し（Ｓ０５）、バイサイド３０およびセルサイド２０に対して取引が成立した旨を通知する（Ｓ０６）。その後、成立した取引の実行として、バイサイド３０からＦＩＸプロトコルのメッセージによりセルサイド２０に対して発注が行われ（Ｓ０７）、セルサイド２０において執行した結果の約定内容がバイサイド３０に対して通知される（Ｓ０８）。

＜（２）バイサイド間のマッチング（執行先指定）＞
図５は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチングの例について概要を示した図である。上述したように、本実施の形態では、バイサイド３０同士でＩＯＩをマッチングさせることができる。図５の例では、バイサイドＡ（３０ａ）が出したＩＯＩ３２ａと、バイサイドＢ（３０ｂ）が出したＩＯＩ３２ｂにおいて、銘柄“△△”について売り買いがマッチしたことを示している。

この場合、双方のバイサイド３０は、それぞれが取引契約を有する所定のセルサイド２０に対して個別に発注処理を行う。図５の例では、バイサイドＡ（３０ａ）はセルサイドＡに、バイサイドＢ（３０ｂ）はセルサイドＢ（２０ｂ）に対して発注を行った場合を示している。発注情報には、バイサイドシステム３００もしくはＰＯＰ１２０により、マッチした相手方のバイサイド３０の発注先のセルサイド２０の情報がクロス取引先のブローカー（セルサイド２０）の情報として付加される。例えば、バイサイドＡ（３０ａ）からの発注情報には、マッチした相手方のバイサイドＢ（３０ｂ）の発注先であるセルサイドＢ（２０ｂ）の情報が付加される。

これにより、発注情報を受け取ったセルサイド２０では、クロス取引の相手方となるセルサイド２０の情報を確認することができ、当該セルサイド２０との間のクロス取引を取引所システム４０に対して執行することができる。なお、各セルサイド２０からの約定データの通知については上述の図３の例と同様であるため説明は省略する。

図６は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチング処理の例について概要を示したシーケンス図である。まず、各バイサイド３０（図６の例ではバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）の２つ）は、ＰＯＰ１２０に対してＩＯＩ情報を登録する（Ｓ１１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ１２）、マッチした取引について、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対してその旨をそれぞれ通知する（Ｓ１３）。

マッチング結果の通知を受けたバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）では、それぞれ、取引執行を行うブローカー（セルサイド２０）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ１４）。上述したように、ここでのブローカーは、例えば、各バイサイド３０が取引契約を有するセルサイド２０である。対象のセルサイド２０の情報を予めＰＯＰシステム１００の設定ＤＢ１２４にデフォルト値として登録しておき、自動的にブローカーが選択されるようにしてもよい。

ブローカー指定を受けたＰＯＰ１２０では、取引が仕掛中となった旨をバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して通知する（Ｓ１５）とともに、ブローカーとして指定された各セルサイド２０（図６の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対してクロス取引の依頼を行う（Ｓ１６）。依頼には、クロス取引に係る銘柄、各バイサイド３０の情報、クロス相手のブローカーの情報などが含まれる。

クロス取引依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ１７）。ＰＯＰ１２０では、いずれの応答もＡｃｋであった場合に取引成立と判定し（Ｓ１８）、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して取引が成立した旨を通知する（Ｓ１９）。

その後、成立した取引の実行として、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）からそれぞれＦＩＸプロトコルのメッセージによりセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）に対して発注が行われ（Ｓ２０）、セルサイドＡ（２０ａ）とセルサイドＢ（２０ｂ）との間でクロス取引の執行が行われた後（Ｓ２１）、約定内容がバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対してそれぞれ通知される（Ｓ２２）。クロス取引（Ｓ２１）に必要となる情報は、発注（Ｓ２０）の際の情報に付加してもよいし、クロス取引依頼（Ｓ１６）の際に渡された情報を用いるようにしてもよい。

なお、上述の例ではバイサイド３０同士のマッチングの場合を示したが、セルサイド２０同士のマッチングの場合も同様である。

＜（３）バイサイド間のマッチング（手数料引き合い）＞
図７は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチングの他の例について概要を示した図である。図７の例では、上述の図５に示したのと同様なバイサイド３０間でのマッチングの後、双方のバイサイド３０と取引契約のある複数のセルサイド２０に対して手数料の引き合いを行い、最も低い手数料を提示したセルサイド２０を発注先として決定する場合を示している。すなわち「手数料コンペ」によって発注先のセルサイド２０を決定する。図７の例では、セルサイドＡ（２０ａ）、セルサイドＢ（２０ｂ）、およびセルサイドＣ（２０ｃ）に手数料の引き合いを行い、最も低い「１ＢＰ（＝０．０１％）」という手数料を提示したセルサイドＡ（２０ａ）を自動的に発注先と決定している。

図８は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチング処理の他の例について概要を示したシーケンス図である。上述の図６の例と同様に、まず、各バイサイド３０（図７の例ではバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）の２つ）は、ＰＯＰ１２０に対してＩＯＩ情報を登録する（Ｓ３１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ３２）、マッチした取引について、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対してその旨をそれぞれ通知する（Ｓ３３）。

マッチング結果の通知を受けたバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）では、それぞれ、取引を行うブローカー（セルサイド２０）を手数料の引き合いにより選択する旨を指定してＰＯＰ１２０に対して通知する（Ｓ３４）。引き合い要求を受けたＰＯＰ１２０では、取引が仕掛中となった旨をバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して通知する（Ｓ３５）とともに、各バイサイド３０が取引契約を有するセルサイド２０（図７の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対して手数料の引き合いを依頼する（Ｓ３６）。引き合いには、取引に係る銘柄、数量、売りと買いの各バイサイド３０の情報などが含まれる。

引き合いの依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、条件提示として手数料のＢＰを設定して応答する（Ｓ３７）。ＢＰの値は、都度セルサイドシステム２００側で入力や設定を行ってもよいし、セルサイドシステム２００やＰＯＰシステム１００の設定ＤＢ１２４などにバイサイド３０毎に予め登録しておいてもよい。セルサイド２０において「手数料コンペ」に不参加とする選択をした場合にその旨を応答することも可能である。一定時間応答がない場合に自動的に不参加として取り扱うようにしてもよい。

ＰＯＰ１２０では、対象の全てのセルサイド２０から条件が提示された場合、もしくは所定の時間が経過した場合に、各セルサイド２０から提示された条件のリストをバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して通知する（Ｓ３８）。発注先の候補は、手数料のＢＰが最も低いセルサイド２０（ＢＰが同じ場合はその中で条件提示（ステップＳ３７）の時刻が最も早いセルサイド２０）となり、その条件に対して各バイサイド２０が発注先として決定する場合には、その旨をＰＯＰ１２０に通知する（Ｓ３９）。各バイサイド２０から決定通知を受けたＰＯＰ１２０は、発注先として決定されたセルサイド２０（図８の例ではセルサイドＡ（２０ａ））には取引成立を通知し（Ｓ４０）、他のセルサイド２０（図８の例ではセルサイドＢ（２０ｂ））には取引不成立を通知する（Ｓ４１）。

以上の処理により、バイサイド３０は、有利な手数料の条件で取引を行うことができる。また、セルサイド２０は、大口注文の手数料コンペに参加することができ、委託売買の機会を得ることができる。

＜（４）バイサイド−セルサイド間のマッチング（執行先指定）＞
図９は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチングの他の例について概要を示した図である。図９の例では、上述の図３に示したのと同様なバイサイドＡ（３０ａ）とセルサイドＡ（２０ａ）との間のマッチングの結果、マッチしたセルサイドＡ（２０ａ）とは別のセルサイドＢ（２０ｂ）に対して発注を行う場合を示している。

この場合、発注に係る情報は、ＦＩＸプロトコルのメッセージによってバイサイドＡ（３０ａ）のバイサイドシステム３００から、セルサイドＢ（２０ｂ）のセルサイドシステム２００に対して送信される。発注情報には、バイサイドシステム３００もしくはＰＯＰ１２０により、マッチした相手方のセルサイド２０（図９の例ではセルサイド２０Ａ（２０ａ））の情報が付加される。したがって、発注情報を受け取ったセルサイドＢ（２０ｂ）では、クロス取引の相手方となるセルサイドＡ（２０ａ）の情報を確認することができ、セルサイドＡ（２０ａ）との間のクロス取引を取引所システム４０に対して執行することができる。

図１０は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチング処理の例について概要を示したシーケンス図である。上述した図４の例と同様に、まず、バイサイド３０およびセルサイドＡ（２０ａ）は、ＰＯＰ１２０に対して、ＦＩＸプロトコルのメッセージもしくはファイルによりＩＯＩ情報を登録する（Ｓ５１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ５２）、マッチした取引について、対象のバイサイド３０とセルサイドＡ（２０ａ）に対してそれぞれその旨を通知する（Ｓ５３）。

マッチング結果の通知を受けたバイサイド３０では、取引を行うブローカー（セルサイド２０）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して指定する（Ｓ５４）。上述したように、ここでのブローカーは、例えば、セルサイド２０（図１０の例ではセルサイドＢ（２０ｂ））である。対象のセルサイド２０の情報を予めＰＯＰシステム１００の設定ＤＢ１２４にデフォルト値として登録しておき、自動的にブローカーが選択されるようにしてもよい。

また、マッチング結果の通知を受けたセルサイドＡ（２０ａ）では、マッチした内容に対してＡｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ５５）。ＰＯＰ１２０では、バイサイド３０からのブローカーの指定を伴うＡｃｋと、セルサイドＡ（２０ａ）からＡｃｋの応答を受けた場合に、ブローカーとして指定されたセルサイドＢ（２０ｂ）に対してクロス取引の依頼を行う（Ｓ５６）。依頼には、クロス取引に係る銘柄、バイサイド３０の情報、クロス相手のブローカーの情報などが含まれる。

クロス取引依頼を受けたセルサイドＢ（２０ｂ）では、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ５７）。ＰＯＰ１２０では、Ａｃｋの応答を受けた場合に取引成立と判定し（Ｓ５８）、バイサイド３０およびセルサイドＡ（２０ａ）に対して取引が成立した旨を通知する（Ｓ５９）。その後、成立した取引の実行として、バイサイド３０からＦＩＸプロトコルのメッセージによりセルサイド２０に対して発注が行われ（Ｓ６０）、セルサイドＡ（２０ａ）とセルサイドＢ（２０ｂ）との間でクロス取引の執行が行われた後（Ｓ６１）、約定内容がバイサイド３０に対して通知される（Ｓ６２）。

上述の図６の例と同様に、クロス取引（Ｓ６１）に必要となる情報は、発注（Ｓ６０）の際の情報に付加してもよいし、クロス取引依頼（Ｓ５６）の際に渡された情報を用いるようにしてもよい。

以上に説明したように、本発明の実施の形態１である証券取引管理システム１によれば、バイサイド３０およびセルサイド２０に対して中立の事業者が運用管理するＰＯＰシステム１００において、ＰＯＰＤＢ１２１に１つ以上のバイサイド３０のポテンシャルオーダーも含むＩＯＩ情報と、１つ以上のセルサイド２０のＩＯＩ情報とを蓄積してマッチングさせる。これにより、複数のセルサイド２０のダークプールの連携が可能となり、バイサイド３０はより幅広い範囲で好適な条件での取引の成立を図ることが可能となる。また、透明性、公正・公平性を担保したダークプールサービスを提供することが可能となる。

また、バイサイド３０のポテンシャルオーダーについてもＩＯＩ情報として取得し、マッチングの対象とすることで、将来の一定期間にわたって分散して行われる予定の取引について、より好適な条件となるタイミングで実行することが可能となる。

（実施の形態２）
上述の実施の形態１では、ＰＯＰ１２０での取引について、バイサイド３０が参加者になる場合とセルサイド２０が参加者になる場合とを区別し、考え得るパターンとして、（１）バイサイド３０とセルサイド２０との間のマッチング、（２）バイサイド３０間でのマッチング（執行先を指定したクロス取引）、（３）バイサイド３０間でのマッチング（手数料引き合い）、および（４）バイサイド３０とセルサイド２０との間のマッチング（執行先を指定）、という４つのパターンについて処理の内容を説明した。

一方、証券取引管理システム１として実装する上で、実務での実態や慣行等を考慮すると、ＰＯＰ１２０でのマッチングの時点において通常はマッチングの相手方がバイサイド３０となるのかセルサイド２０となるのかは不明であるため、参加者がバイサイド３０であるのかセルサイド２０であるのかにより処理フローを区別することが困難な場合も生じる。

また、例えば、（１）のバイサイド３０とセルサイド２０との間のマッチングが行われるケースにおいて、バイサイド３０が執行先のセルサイド２０（執行ブローカー）を指定しないケースは通常では生じ難い。また、（４）のバイサイド３０とセルサイド２０との間のマッチングが行われるケースにおいても同様に、例えば、マッチングされたバイサイド３０とセルサイド２０との間に仮に取引契約がない場合であっても、取引契約のあるセルサイド２０（執行ブローカー）が指定されるのが自然であると考えられる。

したがって、実務上は、ＰＯＰ１２０での取引の相手方についてバイサイド３０かセルサイド２０かを区別せず、（Ａ）参加者間でマッチングした後に執行先のセルサイド２０（執行ブローカー）を指定するケース、および（Ｂ）参加者間でマッチングした後に執行先のセルサイド２０（執行ブローカー）を手数料コンペにより決定するケース、の２つのパターンを実装することで足りるものと考えられる。

図１１は、本実施の形態におけるＰＯＰ１２０での参加者間のマッチング処理の例について概要を示したシーケンス図である。ここでは、上記の（Ａ）参加者間でマッチングした後に執行ブローカーを指定するケースについての処理の流れを示している。基本的には上述の実施の形態１で図６に示した（２）バイサイド３０間でのマッチング（執行先を指定したクロス取引）の処理と同様であるため、重複する内容についての再度の説明は省略する場合がある。図１１の例では、図６の例と異なり、ＰＯＰ１２０での取引への参加者がバイサイド３０ではなく参加者５０（図１１の例では参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）の２つ）となっている。参加者５０は、バイサイド３０もしくはセルサイド２０のいずれであってもよい。

まず、各参加者５０（図１１の例では参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）の２つ）は、ＰＯＰ１２０に対してＩＯＩ情報を登録する（Ｓ７１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ７２）、マッチした取引について、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対してその旨をそれぞれ通知する（Ｓ７３）。なお、ここまでの処理は、図１１の例に示した（Ａ）参加者間でマッチングした後に執行ブローカーを指定するケースと、後述する（Ｂ）参加者間でマッチングした後に執行ブローカーを手数料コンペにより決定するケースとで共通である。

図１１の例では、マッチング結果の通知を受けた参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）では、それぞれ、取引執行を行うブローカー（セルサイド２０）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ７４）。ここでのブローカーは、例えば、参加者５０がバイサイド３０である場合は、上述したように、当該バイサイド３０が取引契約を有するセルサイド２０である。また、参加者５０がセルサイド２０である場合は、通常は、当該セルサイド２０自身が執行先とされる。図１１の例では、参加者Ａ（５０ａ）は執行ブローカーとしてセルサイドＡ（２０ａ）指定し、参加者Ｂ（５０ｂ）はセルサイドＢ（２０ｂ）を指定したことを示している。なお、これらの執行ブローカーが同一のセルサイド２０となる場合もある。

ブローカー指定を受けたＰＯＰ１２０では、取引が仕掛中となった旨を参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対して通知する（Ｓ７５）とともに、ブローカーとして指定された各セルサイド２０（図１１の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対してクロス取引の依頼を行う（Ｓ７６）。依頼には、クロス取引に係る銘柄、各バイサイド３０の情報、クロス相手のブローカーの情報などが含まれる。図１１の例では、参加者Ａ（５０ａ）により指定されたセルサイドＡ（２０ａ）には、参加者Ａ（５０ａ）の取引についてのクロス取引の依頼が行われ、一方、参加者Ｂ（５０ｂ）により指定されたセルサイドＢ（２０ｂ）には、参加者Ｂ（５０ｂ）の取引についてのクロス取引の依頼が行われる。

クロス取引依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ７７）。ＰＯＰ１２０では、いずれの応答もＡｃｋであった場合に取引成立と判定し（Ｓ７８）、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対して取引が成立した旨を通知する（Ｓ７９）。

その後、成立した取引の実行として、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）からＦＩＸプロトコルのメッセージによりそれぞれの執行ブローカーであるセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）に対して発注が行われる（Ｓ８０）。セルサイドＡ（２０ａ）とセルサイドＢ（２０ｂ）との間で取引所システム４０を介してクロス取引の執行が行われた後（Ｓ８１）、約定内容が参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対してそれぞれ通知される（Ｓ８２）。

図１２は、本実施の形態におけるＰＯＰ１２０での参加者間のマッチング処理の他の例について概要を示したシーケンス図である。ここでは、上記の（Ｂ）参加者間でマッチングした後に執行ブローカーを手数料コンペにより決定するケースについての処理の流れを示している。基本的には上述の実施の形態１で図８に示した（３）バイサイド３０間でのマッチング（手数料引き合い）の処理と同様であるため、重複する内容についての再度の説明は省略する場合がある。また、上述したように、図１２の例におけるステップＳ９１〜Ｓ９３までの処理は、図１１の例におけるステップＳ７１〜Ｓ７３と共通である。

図１２の例では、マッチング結果の通知を受けた参加者Ａ（５０ａ）は、図１１の例と同様に、取引執行を行うブローカー（セルサイド２０）としてセルサイドＡ（２０ａ）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知している（Ｓ９４）。一方で、マッチング結果の通知を受けた参加者Ｂ（５０ｂ）は、図１１の例と異なり、取引を行うブローカー（セルサイド２０）を手数料の引き合いにより選択する旨を指定したＡｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ９４）。図１２の例では、参加者５０の一方である参加者Ｂ（５０ｂ）のみが手数料コンペを指定した場合を示しているが、参加者Ａ（５０ａ）、参加者Ｂ（５０ｂ）のいずれもが手数料コンペを指定した場合も同様である。

手数料の引き合いの指定（およびブローカー指定）を受けたＰＯＰ１２０では、取引が仕掛中となった旨を参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対して通知する（Ｓ９５）とともに、ブローカー指定がされている場合には、指定された各セルサイド２０（図１２の例では参加者Ａ（５０ａ）により指定されたセルサイドＡ（２０ａ））に対してクロス取引の依頼を行う（Ｓ９６）。クロス取引依頼を受けたセルサイドＡ（２０ａ）では、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ９７）。

また、ＰＯＰ１２０は、手数料の引き合いの指定に基づいて、各セルサイド２０（図１２の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対して手数料の引き合いを依頼する（Ｓ９８）。引き合いには、取引に係る銘柄、数量、売りと買いの参加者５０（図１２の例では手数料の引き合いを指定した参加者Ｂ（５０ｂ））の情報などが含まれる。引き合いの依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、条件提示として手数料のＢＰを設定して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ９９）。なお、参加者５０のいずれもが手数料の引き合いを指定した場合、各セルサイド２０は双方の引き合いを受けてそれぞれについて条件提示するものとする。

ＰＯＰ１２０では、対象の全てのセルサイド２０から条件が提示された場合、もしくは所定の時間が経過した場合に、各セルサイド２０から提示された条件のリストを、手数料の引き合いを指定した各参加者５０（図１２の例では参加者Ｂ（５０ｂ））に対して通知する（Ｓ１００）。図８の例と同様に、発注先の候補は、手数料のＢＰが最も低いセルサイド２０（ＢＰが同じ場合はその中で条件提示（ステップＳ９９）の時刻が最も早いセルサイド２０）となり、その条件に対して各参加者５０が発注先として決定する場合には、その旨をＰＯＰ１２０に通知する（Ｓ１０１）。

各参加者５０から決定通知を受けたＰＯＰ１２０は、発注先として決定されたセルサイド２０（図１２の例ではセルサイドＡ（２０ａ））には取引成立を通知し（Ｓ１０２）、他のセルサイド２０（図１２の例ではセルサイドＢ（２０ｂ））には取引不成立を通知する（Ｓ１０３）。また、各参加者５０にも取引が成立した旨を通知する（Ｓ１０４）。

なお、図１２の例では、参加者Ａ（５０ａ）が指定した執行ブローカーと、参加者Ｂ（５０ｂ）の指定による手数料の引き合いの結果決定した発注先のセルサイド２０とが、同じセルサイドＡ（２０ａ）である。したがって、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）の双方がセルサイドＡ（２０ａ）に対して発注を行い（Ｓ１０５）、セルサイドＡ（２０ａ）より取引所システム４０を介してクロス取引の執行が行われた後（Ｓ１０６）、約定通知が参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）にそれぞれ通知される（Ｓ１０７）。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、取引の受発注や約定処理に係る業務を支援する証券取引管理システムに利用可能である。

１…証券取引管理システム、
１０…ネットワーク、２０…セルサイド、２０ａ…セルサイドＡ、２０ｂ…セルサイドＢ、２０ｃ…セルサイドＣ、２１…セルサイド端末、２２ａ、ｂ…ＩＯＩ、
３０…バイサイド、３０ａ…バイサイドＡ、３０ｂ…バイサイドＢ、３１…バイサイド端末、３２ａ、ｂ…ＩＯＩ、４０…取引所システム、５０ａ…参加者Ａ、５０ｂ…参加者Ｂ、
１００…ポテンシャルオーダープールシステム、１１０…マッチング処理部、１２０…ポテンシャルオーダープール、１２１…ポテンシャルオーダープールＤＢ、１２２…バイサイドマスタＤＢ、１２３…セルサイドマスタＤＢ、１２４…設定ＤＢ、
２００…セルサイドシステム、２１０…セルサイドＯＭＳ、２２０…バックシステム、
３００…バイサイドシステム、３１０…バイサイドＯＭＳ、３２０…バックシステム

Claims (8)

1. 相手方からの注文を受けてセルサイドが行う証券取引を管理する証券取引管理システムであって、
   証券取引に参加する参加者となるバイサイドもしくはセルサイドにおいて相手方との間の注文を管理する注文管理システムを含む１つ以上の情報処理システムと、
   前記各情報処理システムから取得した、前記各参加者のＩＯＩ（Indication of Interest）の情報をデータベースに記録し、前記各ＩＯＩに含まれる注文の間で売り買いをマッチングさせるポテンシャルオーダープールシステムと、を有する、証券取引管理システム。
2. 請求項１に記載の証券取引管理システムにおいて、
   前記参加者の前記ＩＯＩには、前記参加者が将来実行する予定の注文であるポテンシャルオーダーの情報を含む、証券取引管理システム。
3. 請求項１に記載の証券取引管理システムにおいて、
   前記ポテンシャルオーダープールシステムは、前記参加者であるバイサイドのＩＯＩに含まれる注文と、前記参加者であるセルサイドのＩＯＩに含まれる注文との間で売り買いをマッチングさせる、証券取引管理システム。
4. 請求項１に記載の証券取引管理システムにおいて、
   前記ポテンシャルオーダープールシステムは、前記参加者である第１のバイサイドのＩＯＩに含まれる注文と、前記参加者である第２のバイサイドのＩＯＩに含まれる注文との間で売り買いをマッチングさせる、証券取引管理システム。
5. 請求項１に記載の証券取引管理システムにおいて、
   前記ポテンシャルオーダープールシステムは、前記参加者である第１のセルサイドのＩＯＩに含まれる注文と、前記参加者である第２のセルサイドのＩＯＩに含まれる注文との間で売り買いをマッチングさせる、証券取引管理システム。
6. 請求項１に記載の証券取引管理システムにおいて、
   前記ポテンシャルオーダープールシステムは、第１の参加者と第２の参加者との間でマッチングされた注文につき、前記第１の参加者により指定された執行先のセルサイドにおける第１の情報処理システム、および前記第２の参加者により指定された執行先のセルサイドにおける第２の情報処理システムに対して、前記注文に係るクロス取引の実行依頼を通知し、前記第１の情報処理システムおよび前記第２の情報処理システムの双方から承諾の通知を受領した場合に、前記注文に係る取引が成立した旨を前記第１の参加者における第３の情報処理システム、および前記第２の参加者における第４の情報処理システムに通知し、
   前記第３の情報処理システムは、前記第１の情報処理システムに対して前記注文の発注を行い、
   前記第４の情報処理システムは、前記第２の情報処理システムに対して前記注文の発注を行い、
   前記第１の情報処理システムと、前記第２の情報処理システムとの間で前記注文に係るクロス取引を実行する、証券取引管理システム。
7. 請求項１に記載の証券取引管理システムにおいて、
   前記ポテンシャルオーダープールシステムは、第１の参加者と第２の参加者との間でマッチングされた注文につき、前記第１の参加者により指定された執行先のセルサイドにおける第１の情報処理システムに対して、前記注文に係るクロス取引の実行依頼を通知し、前記第２の参加者により指定された手数料の引き合いにつき、前記参加者である前記各セルサイドにおける前記情報処理システムに対して手数料の引き合いを行い、最も有利な手数料を提示した前記セルサイドを発注先として決定し、前記第１の情報処理システムから前記クロス取引に係る承諾の通知を受領した場合に、前記注文に係る取引が成立した旨を前記第１の参加者における第３の情報処理システム、および前記第２の参加者における第４の情報処理システムと、手数料の引き合いを行った前記各セルサイドにおける前記情報処理システムに通知し、
   前記第３の情報処理システムは、前記第１の情報処理システムに対して前記注文の発注を行い、
   前記第４の情報処理システムは、発注先として決定された前記セルサイドにおける第２の情報処理システムに対して前記注文の発注を行い、
   前記第１の情報処理システムと、前記第２の情報処理システムとの間で前記注文に係るクロス取引を実行する、証券取引管理システム。
8. 請求項１に記載の証券取引管理システムにおいて、
   前記ポテンシャルオーダープールシステムは、第１の参加者と第２の参加者との間でマッチングされた注文につき、前記第１の参加者および前記第２の参加者により指定された手数料の引き合いにつき、それぞれ、前記参加者である前記各セルサイドにおける前記情報処理システムに対して手数料の引き合いを行い、各引き合いに対して最も有利な手数料を提示した前記セルサイドをそれぞれ第１の発注先および第２の発注先として決定し、前記注文に係る取引が成立した旨を前記第１の参加者における第１の情報処理システム、および前記第２の参加者における第２の情報処理システムと、手数料の引き合いを行った前記各セルサイドにおける前記情報処理システムに通知し、
   前記第１の情報処理システムは、前記第１の発注先として決定された前記セルサイドにおける第３の情報処理システムに対して前記注文の発注を行い、
   前記第２の情報処理システムは、前記第２の発注先として決定された前記セルサイドにおける第４の情報処理システムに対して前記注文の発注を行い、
   前記第３の情報処理システムと、前記第４の情報処理システムとの間で前記注文に係るクロス取引を実行する、証券取引管理システム。

Images