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

Description

本発明は、証券取引の技術に関し、特に、取引成立後のポストトレード業務を支援する証券取引管理システムに適用して有効な技術に関するものである。

証券会社（セルサイド）では、機関投資家などの資産運用会社（バイサイド）からの大口の有価証券取引の注文を受けて、市場等を介して実際の取引を行うという業務を有する。かかる業務は一般的には情報処理システムにより管理・支援される。

例えば、特開２００２−３５８４１４号公報（特許文献１）には、機関投資家システムからの有価証券の注文要求に応答して、該注文の約定を成立させる約定処理を行い、約定結果を機関投資家システムに送信し、約定結果を決済照合システムに送信して売買報告を行い、約定の照合を促し、決済照合システムから約定の照合結果を受信した該約定についての決済の指図を決済照合システムに行い、該決済の指図に対する照合を促し、決済照合システムから決済の指図に対する照合結果を受信した決済についての振替指示を決済機関システムに行うことで、約定から決済までの期間を短縮するシステムが記載されている。

また、特開２００３−２３３７１８号公報（特許文献２）には、複数の取引相手と管理装置の間で有価証券の約定に関する連絡を異なるデータ通信システムを介してデータを双方向に変換して行うとともに、約定のステータス変遷状況を管理することで、約定照合や決済照合を能率良く迅速に行えるようにするとともに、処理の進捗状況を容易に確認することができるようにする仕組みが記載されている。

また、機関投資家（バイサイド）側の仕組みとして、例えば、特開２００５−２２８０２９号公報（特許文献３）には、機関投資家における証券会社への株式の注文を管理する注文管理システムであって、注文データと証券会社からの約定結果データとを照合し、発注時刻から所定の時間で約定が成立していない注文を抽出して、これらの注文についての注文取消データを送信するシステムが記載されている。

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

セルサイド、バイサイドでは、それぞれが、受発注の実行、約定の管理などのトレーディング業務に加えて、約定後の処理として、バイサイドの各口座への取引配分（アロケーション）や、手数料等の計算、照合（マッチング）、資金や証券の決済などのいわゆるポストトレード業務を行う。

ここで、例えば口座配分（アロケーション）や手数料計算などの処理の際のルールや手法は、バイサイド毎にそれぞれ異なり、特に日本の資産運用会社では特殊なパターンをとる場合も多い。この点につき、バイサイド側では、自社のルール等に対応するよう個別化したシステムなどにより対応することができるが、複数のバイサイドを顧客として取り扱うセルサイド側では、バイサイド毎の個別対応を人手をかけて人海戦術により対応しているというのが現状である。また、ポストトレード業務は通常は引け後に行うため、処理時間の制約も厳しく、短時間で処理を行うためにも人手をかけて対応している。

そこで本発明の目的は、ポストトレード業務に係る処理を自動化するとともに、状況に応じて処理を前倒しで行うことを可能とする証券取引管理システムを提供することにある。

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

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

本発明の代表的な実施の形態による証券取引管理システムは、バイサイドからの注文を受けてセルサイドが行う証券取引を管理する証券取引管理システムであって、バイサイドにおいてセルサイドに対する注文を管理するバイサイド注文管理システムを含む１つ以上のバイサイドシステムと、セルサイドにおいてバイサイドからの注文を管理するセルサイド注文管理システムを含む１つ以上のセルサイドシステムと、前記各セルサイドシステムに対して、セルサイド毎にポストトレード処理の少なくとも一部をサービスとして提供するポストトレードサービス提供システムと、を有し、前記ポストトレードサービス提供システムは、セルサイド毎に予め設定された、セルサイドにおけるポストトレード処理についての１つ以上の処理パターンに基づいて、バイサイドからの注文に対するポストトレード処理の少なくとも一部を自動的に実行するものである。

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

すなわち、本発明の代表的な実施の形態によれば、ポストトレード業務に係る処理を自動化するとともに、状況に応じて処理を前倒しで行うことが可能となり、ポストトレード業務に係るオペレーションの負荷の低減と処理時間の短縮が可能となる。

本発明の一実施の形態である証券取引管理システムの構成例について概要を示した図である。 本発明の一実施の形態におけるバイサイドとセルサイドとで行われる取引に係る業務処理の流れの例について概要を示した図である。 本発明の一実施の形態におけるセルサイド側でのポストトレード処理の手法の例について概要を示した図である。 本発明の一実施の形態における日中処理の平準化とポストトレード処理の自動実行の手法の例について概要を示した図である。 本発明の一実施の形態における処理パターンの設定の際に指定することができる自動化属性と設定内容の例について概要を示した図である。 本発明の一実施の形態における各プロセスについての処理パターンの設定例について概要を示した図である。 本発明の一実施の形態におけるバイサイドとセルサイドとで行われる照合処理の流れの例について概要を示した図である。 従来技術におけるバイサイドとセルサイドとで行われる取引に係る業務処理の流れの例について概要を示した図である。 従来技術におけるセルサイド側でのポストトレード処理の手法の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

＜概要＞
図８は、従来技術におけるバイサイドとセルサイドとで行われる取引に係る業務処理の流れの例について概要を示した図である。運用会社（バイサイド）と証券会社（セルサイド）は、それぞれ個別の注文管理システム等の情報処理システムを適宜用いて業務を行うものとする。日中のザラ場では、フロントオフィス業務としてトレーディング処理を行う。ここでは、運用会社（バイサイド）と証券会社（セルサイド）との間で事前確認（Ｓ０１ｂ、Ｓ０１ｓ）を行った後、バイサイドが発注を行い（Ｓ０２ｂ）、発注データをセルサイドに送る。セルサイドでは、発注データを受けて受注および取引所への執行を行う（Ｓ０２ｓ）。その後取引が約定すると、セルサイドは約定（出来）の連絡を行い（Ｓ０３ｓ）、バイサイドでは約定連絡を受け取る（Ｓ０３ｂ）。

市場の引け後には、フロントオフィス業務のうちのポストトレード処理を行う。ここでは、バイサイド、セルサイド双方で、約定データを取り込んでブロック化（同値寄せ）するブロッキング（Ｓ１１ｂ、Ｓ１１ｓ）を行った後、バイサイド側で注文、約定に対する口座配分（アロケーション）の指示データを作成し（Ｓ１２ｂ）、データをセルサイドに送る。セルサイドでは、アロケーションデータを受け取って、指示に基づいて約定分をバイサイドの清算口座（バイサイドにとっての顧客の口座）に配分するアロケーションを行う（Ｓ１２ｓ）。

セルサイドでは、さらに、約定した取引の清算や決済を他の証券会社で行うようにするギブアップ処理（Ｓ１３ｓ）、先物取引等における反対売買の決済のペアリング（Ｓ１４ｓ）などの処理を行った後、手数料や税金の計算を行い（Ｓ１５ｓ）、計算結果をバイサイドに通知する（Ｓ１６ｓ）。手数料や税金の計算はバイサイド側でも行い（Ｓ１５ｂ）、その計算結果を、セルサイドから送られたセルサイド側での計算結果との間で照合する（Ｓ１６ｂ）。照合結果はバイサイドからセルサイドに通知する（Ｓ１７ｂ、Ｓ１７ｓ）。上記の一連の処理でフロントオフィス業務は終了し、その後、バックオフィス業務として、バイサイド、セルサイド双方のシステムがそれぞれのバックオフィスシステムに接続して、決済処理等を行う。

図９は、従来技術におけるセルサイド側でのポストトレード処理の手法の例について概要を示した図である。図示するように、現状では、ポストトレード処理を含む各処理は、情報処理システムを介して行われているものの、人手でのデータ入力や実行により行われ、処理の自動化は困難であった。例えば、アロケーションについては、セルサイドが受けた注文情報や約定の出来情報だけでは配分先の口座の数などが分からず、セルサイドではアロケーションができない場合がある。また、口座の情報が分かっている場合でも、注文通りに全て約定しなかったようなイレギュラー処理がある場合には、バイサイドからのアロケーションの指示がないとセルサイドではアロケーションができない場合がある。アロケーションができない状態では手数料や税金の計算もすることができない。

このように、人の判断が介在する処理がある上に、バイサイド毎に処理のルールやパターンなどが異なる場合が多く、バイサイド毎の個別対応が必要となる場合が多い状況にある。また、引け後の短時間に報告情報の作成なども含む大量の作業を行う必要があることから、ポストトレード処理は人手をかけて人海戦術により対応していた。

そこで、本発明の一実施の形態である証券取引管理システムでは、各セルサイドがそれぞれ有している情報処理システムのうち、ポストトレード処理に係る部分を共通プラットフォーム化するとともに、各バイサイドがそれぞれ有している情報処理システムからも共通に連携可能とする。これにより、ポストトレード処理を双方で自動化して、人手によるオペレーションコストと処理時間を削減可能とする。また、アロケーションデータを注文時など早い段階で受信できた場合には、引け前であっても注文を予め仕分けしておくことで、引け後のポストトレード処理の時間をさらに短縮可能とする。さらに、バイサイドとセルサイドとの間の計算結果の照合の不一致の場合のコミュニケーションに係る処理を効率化する。

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

ポストトレードＡＳＰ１００は、ポストトレード処理の実行に係る支援サービスをバイサイド３０、セルサイド２０に対してＡＳＰ（Application Service Provider）により共通プラットフォームとして提供する情報処理システムである。本実施の形態では、当該共通プラットフォーム部分をＡＳＰサービスとして提供する構成としているが、オンプレミス型の構成として各バイサイドシステム３００、セルサイドシステム２００がそれぞれ個別に共通プラットフォーム部分を有する構成となっていてもよい。

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

上記の各システムは、例えば、１つ以上のサーバ機器や、クラウドコンピューティングサービス上で構築された仮想サーバなどにより実装される。バイサイド３０とセルサイド２０との間の情報の共有化が可能となるという観点から、例えば、同じＩＴ事業者により運用・監視されているのが望ましいが、これに限られない。

セルサイドシステム２００は、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたトレーディング処理部２１１を有する。また、バックオフィスシステムであるバックシステム２２０を有する。

トレーディング処理部２１１は、セルサイドシステム２００におけるセルサイド２０側の注文管理システム（ＯＭＳ：Order Management System）であるセルサイドＯＭＳ２１０を構成する一部であり、フロント業務のトレーディング処理を行う。東京証券取引所などの取引所に対してネットワーク１０等を介してオンラインで売買注文の執行を行う機能も有している。セルサイドＯＭＳ２１０において、フロント業務のうちのポストトレード処理については、ポストトレードＡＳＰ１００にアクセスしてＡＳＰサービスとして提供を受けるものとする。

ポストトレードＡＳＰ１００は、例えば、図示しないＯＳやＤＢＭＳ、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたポストトレード処理部１１０を有する。また、データベースやファイルテーブルなどにより実装される共通データベース（ＤＢ）１２１、バイサイドマスタＤＢ１２２、セルサイドマスタＤＢ１２３、および設定ＤＢ１２４などの各データストアを有する。

ポストトレード処理部１１０は、フロント業務のポストトレード処理に係るサービスを提供する。ここでは、各セルサイド２０により設定された内容や、バイサイドシステム３００から取得したバイサイド３０側の各種情報などに基づいて、上述したブロッキングやアロケーション、ギブアップ、決済ペアリング、および手数料計算と、結果の照合などのポストトレード処理を行う。

共通ＤＢ１２１は、セルサイドシステム２００とバイサイドシステム３００との間で、例えば、開示についての承諾が得られたものなど、共有が可能なデータを保持するテーブルである。これを参照することにより、セルサイドシステム２００とバイサイドシステム３００との間の処理の効率的な連携と自動化を図ることが可能となる。共通ＤＢ１２１を用いずとも、バイサイドシステム３００とセルサイドシステム２００との間で直接のデータの送受信により情報を授受してもよいことは当然である。

バイサイドマスタＤＢ１２２およびセルサイドマスタＤＢ１２３は、それぞれ、ポストトレードＡＳＰ１００にアクセスしてポストトレード処理の支援サービスの提供を受けることができるバイサイド３０およびセルサイド２０についてのマスタ情報を保持するテーブルである。ユーザについてのアカウント情報を含んでいてもよい。設定ＤＢ１２４は、特に、セルサイド２０毎のポストトレード処理における処理条件や処理パターンの定義等の各種設定情報を保持するテーブルである。バイサイド３０毎の異なる設定情報を保持していてもよい。

バイサイドシステム３００は、例えば、バイサイド３０側の注文管理システムであるバイサイドＯＭＳ３１０、およびバックオフィスシステムであるバックシステム３２０を有する。バイサイドＯＭＳ３１０は、図示しないＯＳやＤＢＭＳ、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたトレーディング処理部３１１およびポストトレード処理部３１２などの各部を有する。

トレーディング処理部３１１は、バイサイド３０側でのフロント業務のトレーディング処理を行う。また、ポストトレード処理部３１２は、バイサイド３０側でのポストトレード処理を行う。ポストトレードＡＳＰ１００にアクセスして、照合処理の際にセルサイド２０側と連携することも可能である。

＜全体の処理の流れ＞
図２は、本実施の形態におけるバイサイドとセルサイドとで行われる取引に係る業務処理の流れの例について概要を示した図である。本実施の形態では、基本的にバイサイド３０側での処理をバイサイドシステム３００によって行い、セルサイド２０側での処理をセルサイドシステム２００によって行うが、図８に示した従来の例と異なり、セルサイド２０側でのポストトレード処理をポストトレードＡＳＰ１００によって行い、手数料や税金の計算結果の照合までの一連のポストトレード処理を自動化する。

ここでは、図示するように、バイサイドシステム３００は、アロケーションまで完了したタイミングで、ポストトレードＡＳＰ１００に対してアロケーションデータを連携する。連携は、データを送信する方法でもよいし、共通ＤＢ１２１に登録する方法でもよい。セルサイドシステム２００では、設定ＤＢ１２４にセルサイド２０毎に予め設定・登録された処理パターンやルール等に基づいて、ブロッキング（Ｓ１１ｓ）から手数料計算（Ｓ１５ｓ）までの一連の処理を自動的に行う。その際、セルサイドシステム２００から取得した注文データや出来データ、バイサイドシステム３００から取得したアロケーションデータなどを参照し、その内容に応じて処理パターンの選択とこれに基づく処理を自動的に行う。

そして、手数料の計算結果の授受とバイサイドシステム３００での照合、照合結果の授受についても、ポストトレードＡＳＰ１００とバイサイドシステム３００とが自動的に連携して行う。

＜ポストトレード処理＞
図３は、本実施の形態におけるセルサイド２０側でのポストトレード処理の手法の例について概要を示した図である。本実施の形態では、図９に示した従来の例と異なり、引け後のポストトレード処理において人手によりデータ入力や実行を行っていたブロッキング、アロケーション、ギブアップ、決済ペアリング、および手数料計算などの処理を、ポストトレードＡＳＰ１００上で自動処理とする。したがって、ユーザは実行の監視と、処理結果の確認や調整を行うだけでよく、大幅な作業負荷の低減と作業時間の短縮を実現することができる。

なお、バイサイドシステム３００からのアロケーションデータの受信は、引け後での受信に限らず、例えば、バイサイド３０からの注文時に口座が確定している場合や、引け前に確定した場合などでは、図３に示すように、引け前のザラ場で受信してポストトレードＡＳＰ１００に前倒しで取り込んでもよい。これにより、ポストトレード処理の処理時間をさらに短縮することができる。

また、引け後におけるポストトレード処理の自動実行は、基本的に、バイサイド３０からの注文の内容に基づいて、執行後に注文を仕分けする処理を行い、仕分けられた注文毎に対応する処理パターンによってそれぞれポストトレード処理を行う。

図４は、日中処理の平準化とポストトレード処理の自動実行の手法の例について概要を示した図である。ポストトレードＡＳＰ１００のポストトレード処理部１１０は、日中のザラ場にセルサイドシステム１００のトレーディング処理部２１１から約定した注文や出来のデータを随時取得し、バイサイド３０の属性と銘柄の属性との組み合わせ、および注文における清算口座の情報の確定の有無等の条件に応じて、注文を仕分けする。図４の例では、“仕分け１”、“仕分け２”、“仕分け３”の３つのパターンに仕分けする場合を示している。注文時に口座の情報が確定していない場合は、“口座未確定（デフォルト）”として仕分けする。ここに仕分けられた注文については、その後バイサイドシステム３００からアロケーションデータを受信してこれが取り込まれたときに、その口座指定に基づいて再仕分けを行う。したがって、再仕分けが行われるまではポストトレード処理は保留される。

仕分けられた各注文は、引け後のポストトレード処理において、各仕分けパターンに対応する処理パターンによって自動処理が行われる。図４の例では、“仕分け１”、“仕分け２”、“仕分け３”の３種類の仕分けパターンに対してそれぞれ対応する“パターン１”、“パターン２”、“パターン３”の３つの処理パターンで自動処理が行われることを示している。本実施の形態では、ポストトレード業務において行われる処理を大きく“ブロッキング”、“アロケーションデータ作成”、“ギブアップデータ作成”、“決済ペアリング”、“手数料計算”という５つのプロセスに分類し、各プロセスについての処理内容を組み合わせて処理パターンを予め設定しておくことができる。

図中の“パターン１”は、例えば、ブロッキングから手数料計算までの５つの処理について、いずれも典型的な処理や単純な処理を行うバイサイドの場合であり、この場合は、５つの処理を全て予め定められた処理手順により自動処理することができる。“パターン２”は、例えば、ギブアップ処理の場合の変更先の証券会社の選択・決定のルールのみが複雑なバイサイドの場合であり、この場合は、ギブアップデータ作成のみセルサイド２０の担当者が入力、実行し、他の処理は予め定められた処理手順により自動実行することができる。

“パターン３”は、例えば、建玉指定で決済を行うバイサイドの場合であり、この場合は、決済の際に指定された建玉とペアリングするための決済ペアリングのみセルサイド２０の担当者が入力、実行し、他の処理は予め定められた処理手順により自動実行することができる。このように、ポストトレードの各プロセスについて自動実行と手動実行とを適宜組み合わせた処理パターンを予め定めておくことで、バイサイド３０の特性に応じて柔軟に自動処理の設定を行うことができる。

図５は、各プロセスについて処理パターンの設定の際に指定することができる自動化属性の例について概要を示した図である。図中の“自動化属性”列は、自動処理の処理パターンを定義する上で設定することが必要な属性の項目の例を示している。例えば、ブロッキングの処理では、自動化属性に“同値寄せ”および“ブロッキングキー”があることから、“同値寄せ”および“ブロッキングキー”の設定内容に応じてブロッキング処理を自動化できることを示している。同様に、例えば、アロケーションの処理では、自動化属性に“自動アロケーション”および“手動アロケーション”があることから、これらの設定内容に応じてアロケーションを自動化できることを示している。ギブアップデータ作成、決済ペアリング、手数料計算などの他のプロセスについても同様である。

図６は、各プロセスについての処理パターンの設定例について概要を示した図である。ここでは、「バイサイド×銘柄」の属性の組み合わせ毎に処理パターンを設定している例を示している。例えば、バイサイド３０が“機関投資家”で、銘柄が“ラージ銘柄”（図中の“機関投資家×ラージ銘柄”）の場合は、一連の各プロセスを図示された内容によって予め設定されたロジックのパターンで自動実行することを示している。

また、バイサイド３０が“ＣＴＡ（Commodity Trading Advisor：商品投資顧問業者）”で、銘柄が“ミニ銘柄”（図中の“ＣＴＡ×ミニ銘柄”）の場合は、ギブアップデータ作成において、バイサイド３０からファイルで指定された条件でギブアップするという手動処理が入る処理パターンが設定されており、自動処理がここで一時中断することを示している。同様に、バイサイド３０が“地方銀行”で、銘柄が“ラージ銘柄”（図中の“地方銀行×ラージ銘柄”）の場合は、決済ペアリングにおいて手動でペアリングする処理パターンが設定されており、自動処理がここで一時中断することを示している。なお、上述した例では、注文の仕分けをバイサイド３０と銘柄の属性の組み合わせ（「バイサイド×銘柄」）で行っているが、注文タイプなど他の項目との組み合わせを用いてもよい。

このように、ポストトレードＡＳＰ１００において、バイサイド３０や注文の属性情報などに基づいて注文を自動的に仕分けし、仕分けられた単位で予め定められた処理パターンに従ってポストトレード処理を自動化することで、オペレーションコストと処理時間を大幅に削減することができる。

＜照合処理＞
ポストトレード処理では、バイサイド３０、セルサイド２０双方で手数料や税金の計算が行われ、これをバイサイド３０側で照合（マッチング）する作業が行われる。照合が成功（マッチ）した場合は特に問題とならないが、照合が不一致（ブレイク）であった場合、その原因を確認する事務処理やバイサイド３０とセルサイド２０との間の連絡等が増えてしまうのに加えて、セルサイド２０側の事務処理能力に対する評価の低下につながる場合がある。したがって、セルサイド２０としては、照合処理の効率化に加えて、ブレイクとなった場合の修正や再計算をバイサイド３０に覚知されずに速やかに行いたいというニーズがある。

そこで、本実施の形態では、バイサイド３０側での照合がブレイクした場合に、その通知をバイサイドシステム３００上の画面に表示せず、すなわちバイサイド３０側には通知せずに、ポストトレードＡＳＰ１００にのみ通知する。これにより、ポストトレードＡＳＰ１００上で、セルサイド２０側が照合結果の確認と再計算をバイサイド３０側に覚知されずに速やかに行うことが可能となる。

図７は、本実施の形態におけるバイサイドとセルサイドとで行われる照合処理の流れの例について概要を示した図である。本実施の形態では、上述したように、ポストトレードＡＳＰ１００において、バイサイド３０毎のアロケーションや手数料等の計算ルールを設定ＤＢ１２４に保持しておくことで、セルサイド２０側でも手数料計算の処理を自動化することができる。

図２に示した処理の流れと同様の処理によって、バイサイドシステム３００およびセルサイド２０側のポストトレードＡＳＰ１００のそれぞれにおいて手数料計算（Ｓ１５ｂ、Ｓ１５＿１ｓ）までの処理が行われると、ポストトレードＡＳＰ１００から計算結果が通知され（Ｓ１６＿１ｓ）、バイサイドシステム３００において照合処理（Ｓ１６＿１ｂ）が行われる。このとき、照合結果が不一致（ブレイク）であった場合は、その通知をバイサイドシステム３００上の画面に表示せずに、すなわちバイサイド３０側には覚知させずに、ポストトレードＡＳＰ１００にのみ通知する（Ｓ１７＿１ｂ）。このとき、照合結果に加えてバイサイド３０側での手数料計算結果のデータ、すなわち照合に係るバイサイド３０側の「正解データ」も送信する。

ポストトレードＡＳＰ１００では、照合結果の受信（Ｓ１７＿１ｓ）を監視し、ブレイクが生じている場合には画面上でのメッセージ等によりセルサイド２０側の担当者等に通知する。担当者は、照合結果における不一致事項の内容を確認し、手数料の更新を行う（Ｓ１５＿２ｓ）。バイサイド３０側での計算結果（「正解データ」）の内容に問題がない場合には、これをそのまま受け入れることも可能である。

再計算の結果は再度バイサイドシステム３００に対して通知され（Ｓ１６＿２ｓ）バイサイドシステム３００上で再度照合される（Ｓ１６＿２ｂ）。ここでの照合も、バイサイド３０側には覚知させずに自動で行う。ポストトレードＡＳＰ１００から送られる計算結果は、基本的にバイサイド３０側での「正解データ」に基づいているため、再度の照合は成功（マッチ）する。そして、その照合結果がバイサイドシステム３００からポストトレードＡＳＰ１００に送られる（Ｓ１７＿２ｂ、Ｓ１７＿２ｓ）。照合結果がマッチの場合は、バックオフィス接続（Ｓ２１ｂ、Ｓ２１ｓ）まで自動処理することができる。

このように、バイサイド３０とセルサイド２０との間の計算結果の照合がブレイクした場合に、通知、再計算、再照合を、バイサイド３０側に覚知させることなく行うことができる。これにより、ブレイク時のバイサイド３０とセルサイド２０との間の通知、連絡に係る事務処理を大幅に低減して処理を効率化することができるとともに、ブレイクの発生をバイサイド３０側に覚知されることによるセルサイド２０の評価への影響を回避することができる。

なお、ポストトレードＡＳＰ１００においてブレイクの照合結果をバイサイドシステム３００から受け取ってその内容を確認した際に、セルサイド２０側の計算結果が正しいと判断される場合には、その旨の通知（「ブレイク公開通知」）をバイサイドシステム３００に対して送信し、ブレイクの発生をバイサイド３０側にオープンにして覚知させるようにしてもよい。この場合は、例えば、バイサイドシステム３００においてセルサイド２０側の計算結果のデータを取り込み、再度照合を実行することができる。

また、図７の例のように、バイサイドシステム３００とポストトレードＡＳＰ１００の双方で個別に手数料計算を行い、照合することを可能とするためには、双方のシステムが手数料計算のルールおよび計算に用いるデータをそれぞれ保有する、もしくはポストトレードＡＳＰ１００上の共通ＤＢ１２１などに共有する構成を有していることが前提となる。

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

本発明は、取引成立後のポストトレード業務を支援する証券取引管理システムに利用可能である。

１…証券取引管理システム、
１０…ネットワーク、２０…セルサイド、２１…セルサイド端末、３０…バイサイド、３１…バイサイド端末、４０…取引所システム、
１００…ポストトレードＡＳＰ、１１０…ポストトレード処理部、１２１…共通ＤＢ、１２２…バイサイドマスタＤＢ、１２３…セルサイドマスタＤＢ、１２４…設定ＤＢ、
２００…セルサイドシステム、２１０…セルサイドＯＭＳ、２１１…トレーディング処理部、２２０…バックシステム、
３００…バイサイドシステム、３１０…バイサイドＯＭＳ、３１１…トレーディング処理部、３１２…ポストトレード処理部、３２０…バックシステム

Claims (6)

1. バイサイドからの注文を受けてセルサイドが行う証券取引を管理する証券取引管理システムであって、
   バイサイドにおいてセルサイドに対する注文を管理するバイサイド注文管理システムを含む１つ以上のバイサイドシステムと、
   セルサイドにおいてバイサイドからの注文を管理するセルサイド注文管理システムを含む１つ以上のセルサイドシステムと、
   前記各セルサイドシステムに対して、セルサイド毎にポストトレード
   処理の少なくとも一部をサービスとして提供するポストトレードサービス提供システムと、を有し、
   前記ポストトレードサービス提供システムは、約定したバイサイドからの注文の情報を前記セルサイドシステムから取得し、取得した各注文の情報を、引け前に、当該注文を行ったバイサイドの属性情報、および当該注文に係る銘柄の属性情報を含む属性情報の組み合わせに基づいて１つ以上の区分に仕分けし、前記各区分に対してセルサイド毎に予め設定された、セルサイドにおけるポストトレード処理の各プロセスについて自動実行と手動実行とを組み合わせた１つ以上の処理パターンに基づいて、バイサイドからの注文に対するポストトレード処理の少なくとも一部を自動的に実行する、証券取引管理システム。
2. 請求項１に記載の証券取引管理システムにおいて、
   前記ポストトレードサービス提供システムは、バイサイドによる注文に係る口座配分情報を前記バイサイドシステムから取得し、前記口座配分情報に基づいて、セルサイドのポストトレード処理における口座配分処理を行う、証券取引管理システム。
3. 請求項７に記載の証券取引管理システムにおいて、
   前記ポストトレードサービス提供システムは、前記口座配分情報を、引け前に前記バイサイドシステムから取得する、証券取引管理システム。
4. 請求項７に記載の証券取引管理システムにおいて、
   前記ポストトレードサービス提供システムは、前記セルサイドシステムから取得した各注文の情報を仕分けする際に、当該注文を行ったバイサイドの前記バイサイドシステムから前記口座配分情報を取得していない場合は、所定の区分に仕分けしてポストトレード処理を保留し、その後前記口座配分情報を取得した際に再度仕分けを行う、証券取引管理システム。
5. 請求項１に記載の証券取引管理システムにおいて、
   前記ポストトレードサービス提供システムは、バイサイド毎の手数料計算のルールに係る情報を保持しており、ポストトレード処理において前記ルールに基づいて注文に係る手数料を計算して前記バイサイドシステムに送信し、
   前記バイサイドシステムは、前記バイサイドシステムが計算した手数料と、前記ポストトレードサービス提供システムから受信した手数料とを照合する、証券取引管理システム。
6. 請求項１０に記載の証券取引管理システムにおいて、
   前記バイサイドシステムは、前記照合の結果が不一致の場合、照合結果の情報を、前記バイサイドシステムにおいて出力せずに前記ポストトレードサービス提供システムに送信し、
   前記ポストトレードサービス提供システムは、前記バイサイドシステムから受信した前記照合結果の情報に基づいて手数料を更新して前記バイサイドシステムに再送信する、証券取引管理システム。

Images