【文献】
村田 芳晴,STPを実現するホールセール証券システム「I−STAR」,ITソリューションフロンティア,[online],日本,2003年,pp.18,19,[検索日 2015.07.02],URL,https://www.nri.com/jp/opinion/it_solution/2003/pdf/IT20030108.pdf
【文献】
森 早苗,電子金融・証券取引,資本市場クォータリー 2000年冬号,日本,株式会社野村総合研究所,2000年 2月 1日,第3巻 第3号,pp.74−98
【文献】
宮田 慶一,証券取引のSTP化を巡る動きについて,日本銀行金融研究所ディスカッション・ペーパー・シリーズ(1999年収録分),日本,日本銀行,1999年12月17日,pp.1−29
(58)【調査した分野】(Int.Cl.,DB名)
【背景技術】
【0002】
証券会社(セルサイド)では、機関投資家などの資産運用会社(バイサイド)からの大口の有価証券取引の注文を受けて、市場等を介して実際の取引を行うという業務を有する。かかる業務は一般的には情報処理システムにより管理・支援される。
【0003】
例えば、特開2002−358414号公報(特許文献1)には、機関投資家システムからの有価証券の注文要求に応答して、該注文の約定を成立させる約定処理を行い、約定結果を機関投資家システムに送信し、約定結果を決済照合システムに送信して売買報告を行い、約定の照合を促し、決済照合システムから約定の照合結果を受信した該約定についての決済の指図を決済照合システムに行い、該決済の指図に対する照合を促し、決済照合システムから決済の指図に対する照合結果を受信した決済についての振替指示を決済機関システムに行うことで、約定から決済までの期間を短縮するシステムが記載されている。
【0004】
また、特開2003−233718号公報(特許文献2)には、複数の取引相手と管理装置の間で有価証券の約定に関する連絡を異なるデータ通信システムを介してデータを双方向に変換して行うとともに、約定のステータス変遷状況を管理することで、約定照合や決済照合を能率良く迅速に行えるようにするとともに、処理の進捗状況を容易に確認することができるようにする仕組みが記載されている。
【0005】
また、機関投資家(バイサイド)側の仕組みとして、例えば、特開2005−228029号公報(特許文献3)には、機関投資家における証券会社への株式の注文を管理する注文管理システムであって、注文データと証券会社からの約定結果データとを照合し、発注時刻から所定の時間で約定が成立していない注文を抽出して、これらの注文についての注文取消データを送信するシステムが記載されている。
【発明を実施するための形態】
【0016】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
【0017】
<概要>
図8は、従来技術におけるバイサイドとセルサイドとで行われる取引に係る業務処理の流れの例について概要を示した図である。運用会社(バイサイド)と証券会社(セルサイド)は、それぞれ個別の注文管理システム等の情報処理システムを適宜用いて業務を行うものとする。日中のザラ場では、フロントオフィス業務としてトレーディング処理を行う。ここでは、運用会社(バイサイド)と証券会社(セルサイド)との間で事前確認(S01b、S01s)を行った後、バイサイドが発注を行い(S02b)、発注データをセルサイドに送る。セルサイドでは、発注データを受けて受注および取引所への執行を行う(S02s)。その後取引が約定すると、セルサイドは約定(出来)の連絡を行い(S03s)、バイサイドでは約定連絡を受け取る(S03b)。
【0018】
市場の引け後には、フロントオフィス業務のうちのポストトレード処理を行う。ここでは、バイサイド、セルサイド双方で、約定データを取り込んでブロック化(同値寄せ)するブロッキング(S11b、S11s)を行った後、バイサイド側で注文、約定に対する口座配分(アロケーション)の指示データを作成し(S12b)、データをセルサイドに送る。セルサイドでは、アロケーションデータを受け取って、指示に基づいて約定分をバイサイドの清算口座(バイサイドにとっての顧客の口座)に配分するアロケーションを行う(S12s)。
【0019】
セルサイドでは、さらに、約定した取引の清算や決済を他の証券会社で行うようにするギブアップ処理(S13s)、先物取引等における反対売買の決済のペアリング(S14s)などの処理を行った後、手数料や税金の計算を行い(S15s)、計算結果をバイサイドに通知する(S16s)。手数料や税金の計算はバイサイド側でも行い(S15b)、その計算結果を、セルサイドから送られたセルサイド側での計算結果との間で照合する(S16b)。照合結果はバイサイドからセルサイドに通知する(S17b、S17s)。上記の一連の処理でフロントオフィス業務は終了し、その後、バックオフィス業務として、バイサイド、セルサイド双方のシステムがそれぞれのバックオフィスシステムに接続して、決済処理等を行う。
【0020】
図9は、従来技術におけるセルサイド側でのポストトレード処理の手法の例について概要を示した図である。図示するように、現状では、ポストトレード処理を含む各処理は、情報処理システムを介して行われているものの、人手でのデータ入力や実行により行われ、処理の自動化は困難であった。例えば、アロケーションについては、セルサイドが受けた注文情報や約定の出来情報だけでは配分先の口座の数などが分からず、セルサイドではアロケーションができない場合がある。また、口座の情報が分かっている場合でも、注文通りに全て約定しなかったようなイレギュラー処理がある場合には、バイサイドからのアロケーションの指示がないとセルサイドではアロケーションができない場合がある。アロケーションができない状態では手数料や税金の計算もすることができない。
【0021】
このように、人の判断が介在する処理がある上に、バイサイド毎に処理のルールやパターンなどが異なる場合が多く、バイサイド毎の個別対応が必要となる場合が多い状況にある。また、引け後の短時間に報告情報の作成なども含む大量の作業を行う必要があることから、ポストトレード処理は人手をかけて人海戦術により対応していた。
【0022】
そこで、本発明の一実施の形態である証券取引管理システムでは、各セルサイドがそれぞれ有している情報処理システムのうち、ポストトレード処理に係る部分を共通プラットフォーム化するとともに、各バイサイドがそれぞれ有している情報処理システムからも共通に連携可能とする。これにより、ポストトレード処理を双方で自動化して、人手によるオペレーションコストと処理時間を削減可能とする。また、アロケーションデータを注文時など早い段階で受信できた場合には、引け前であっても注文を予め仕分けしておくことで、引け後のポストトレード処理の時間をさらに短縮可能とする。さらに、バイサイドとセルサイドとの間の計算結果の照合の不一致の場合のコミュニケーションに係る処理を効率化する。
【0023】
<システム構成>
図1は、本発明の一実施の形態である証券取引管理システムの構成例について概要を示した図である。証券取引管理システム1は、複数のバイサイドシステム300、複数のセルサイドシステム200、およびポストトレードASP100の各情報処理システムがインターネット等のネットワーク10に接続された構成を有する。バイサイドシステム300は、各バイサイド30(運用会社等)が有する注文管理システム等を含む情報処理システムであり、セルサイドシステム200は、各セルサイド20(証券会社等)が有する注文管理システム等を含む情報処理システムである。
【0024】
ポストトレードASP100は、ポストトレード処理の実行に係る支援サービスをバイサイド30、セルサイド20に対してASP(Application Service Provider)により共通プラットフォームとして提供する情報処理システムである。本実施の形態では、当該共通プラットフォーム部分をASPサービスとして提供する構成としているが、オンプレミス型の構成として各バイサイドシステム300、セルサイドシステム200がそれぞれ個別に共通プラットフォーム部分を有する構成となっていてもよい。
【0025】
各セルサイド20の担当者等は、自身が使用する情報処理端末であるセルサイド端末21の図示しないWebブラウザ等を利用して自社のセルサイドシステム200にアクセスし、セルサイド20としての業務を行う。同様に、各バイサイド30の担当者等は、自身が使用する情報処理端末であるバイサイド端末31の図示しないWebブラウザ等を利用して自社のバイサイドシステム300にアクセスし、バイサイド30としての業務を行う。
【0026】
上記の各システムは、例えば、1つ以上のサーバ機器や、クラウドコンピューティングサービス上で構築された仮想サーバなどにより実装される。バイサイド30とセルサイド20との間の情報の共有化が可能となるという観点から、例えば、同じIT事業者により運用・監視されているのが望ましいが、これに限られない。
【0027】
セルサイドシステム200は、例えば、図示しないOS(Operating System)やDBMS(DataBase Management System)、Webサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたトレーディング処理部211を有する。また、バックオフィスシステムであるバックシステム220を有する。
【0028】
トレーディング処理部211は、セルサイドシステム200におけるセルサイド20側の注文管理システム(OMS:Order Management System)であるセルサイドOMS210を構成する一部であり、フロント業務のトレーディング処理を行う。東京証券取引所などの取引所に対してネットワーク10等を介してオンラインで売買注文の執行を行う機能も有している。セルサイドOMS210において、フロント業務のうちのポストトレード処理については、ポストトレードASP100にアクセスしてASPサービスとして提供を受けるものとする。
【0029】
ポストトレードASP100は、例えば、図示しないOSやDBMS、Webサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたポストトレード処理部110を有する。また、データベースやファイルテーブルなどにより実装される共通データベース(DB)121、バイサイドマスタDB122、セルサイドマスタDB123、および設定DB124などの各データストアを有する。
【0030】
ポストトレード処理部110は、フロント業務のポストトレード処理に係るサービスを提供する。ここでは、各セルサイド20により設定された内容や、バイサイドシステム300から取得したバイサイド30側の各種情報などに基づいて、上述したブロッキングやアロケーション、ギブアップ、決済ペアリング、および手数料計算と、結果の照合などのポストトレード処理を行う。
【0031】
共通DB121は、セルサイドシステム200とバイサイドシステム300との間で、例えば、開示についての承諾が得られたものなど、共有が可能なデータを保持するテーブルである。これを参照することにより、セルサイドシステム200とバイサイドシステム300との間の処理の効率的な連携と自動化を図ることが可能となる。共通DB121を用いずとも、バイサイドシステム300とセルサイドシステム200との間で直接のデータの送受信により情報を授受してもよいことは当然である。
【0032】
バイサイドマスタDB122およびセルサイドマスタDB123は、それぞれ、ポストトレードASP100にアクセスしてポストトレード処理の支援サービスの提供を受けることができるバイサイド30およびセルサイド20についてのマスタ情報を保持するテーブルである。ユーザについてのアカウント情報を含んでいてもよい。設定DB124は、特に、セルサイド20毎のポストトレード処理における処理条件や処理パターンの定義等の各種設定情報を保持するテーブルである。バイサイド30毎の異なる設定情報を保持していてもよい。
【0033】
バイサイドシステム300は、例えば、バイサイド30側の注文管理システムであるバイサイドOMS310、およびバックオフィスシステムであるバックシステム320を有する。バイサイドOMS310は、図示しないOSやDBMS、Webサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装されたトレーディング処理部311およびポストトレード処理部312などの各部を有する。
【0034】
トレーディング処理部311は、バイサイド30側でのフロント業務のトレーディング処理を行う。また、ポストトレード処理部312は、バイサイド30側でのポストトレード処理を行う。ポストトレードASP100にアクセスして、照合処理の際にセルサイド20側と連携することも可能である。
【0035】
<全体の処理の流れ>
図2は、本実施の形態におけるバイサイドとセルサイドとで行われる取引に係る業務処理の流れの例について概要を示した図である。本実施の形態では、基本的にバイサイド30側での処理をバイサイドシステム300によって行い、セルサイド20側での処理をセルサイドシステム200によって行うが、
図8に示した従来の例と異なり、セルサイド20側でのポストトレード処理をポストトレードASP100によって行い、手数料や税金の計算結果の照合までの一連のポストトレード処理を自動化する。
【0036】
ここでは、図示するように、バイサイドシステム300は、アロケーションまで完了したタイミングで、ポストトレードASP100に対してアロケーションデータを連携する。連携は、データを送信する方法でもよいし、共通DB121に登録する方法でもよい。セルサイドシステム200では、設定DB124にセルサイド20毎に予め設定・登録された処理パターンやルール等に基づいて、ブロッキング(S11s)から手数料計算(S15s)までの一連の処理を自動的に行う。その際、セルサイドシステム200から取得した注文データや出来データ、バイサイドシステム300から取得したアロケーションデータなどを参照し、その内容に応じて処理パターンの選択とこれに基づく処理を自動的に行う。
【0037】
そして、手数料の計算結果の授受とバイサイドシステム300での照合、照合結果の授受についても、ポストトレードASP100とバイサイドシステム300とが自動的に連携して行う。
【0038】
<ポストトレード処理>
図3は、本実施の形態におけるセルサイド20側でのポストトレード処理の手法の例について概要を示した図である。本実施の形態では、
図9に示した従来の例と異なり、引け後のポストトレード処理において人手によりデータ入力や実行を行っていたブロッキング、アロケーション、ギブアップ、決済ペアリング、および手数料計算などの処理を、ポストトレードASP100上で自動処理とする。したがって、ユーザは実行の監視と、処理結果の確認や調整を行うだけでよく、大幅な作業負荷の低減と作業時間の短縮を実現することができる。
【0039】
なお、バイサイドシステム300からのアロケーションデータの受信は、引け後での受信に限らず、例えば、バイサイド30からの注文時に口座が確定している場合や、引け前に確定した場合などでは、
図3に示すように、引け前のザラ場で受信してポストトレードASP100に前倒しで取り込んでもよい。これにより、ポストトレード処理の処理時間をさらに短縮することができる。
【0040】
また、引け後におけるポストトレード処理の自動実行は、基本的に、バイサイド30からの注文の内容に基づいて、執行後に注文を仕分けする処理を行い、仕分けられた注文毎に対応する処理パターンによってそれぞれポストトレード処理を行う。
【0041】
図4は、日中処理の平準化とポストトレード処理の自動実行の手法の例について概要を示した図である。ポストトレードASP100のポストトレード処理部110は、日中のザラ場にセルサイドシステム100のトレーディング処理部211から約定した注文や出来のデータを随時取得し、バイサイド30の属性と銘柄の属性との組み合わせ、および注文における清算口座の情報の確定の有無等の条件に応じて、注文を仕分けする。
図4の例では、“仕分け1”、“仕分け2”、“仕分け3”の3つのパターンに仕分けする場合を示している。注文時に口座の情報が確定していない場合は、“口座未確定(デフォルト)”として仕分けする。ここに仕分けられた注文については、その後バイサイドシステム300からアロケーションデータを受信してこれが取り込まれたときに、その口座指定に基づいて再仕分けを行う。したがって、再仕分けが行われるまではポストトレード処理は保留される。
【0042】
仕分けられた各注文は、引け後のポストトレード処理において、各仕分けパターンに対応する処理パターンによって自動処理が行われる。
図4の例では、“仕分け1”、“仕分け2”、“仕分け3”の3種類の仕分けパターンに対してそれぞれ対応する“パターン1”、“パターン2”、“パターン3”の3つの処理パターンで自動処理が行われることを示している。本実施の形態では、ポストトレード業務において行われる処理を大きく“ブロッキング”、“アロケーションデータ作成”、“ギブアップデータ作成”、“決済ペアリング”、“手数料計算”という5つのプロセスに分類し、各プロセスについての処理内容を組み合わせて処理パターンを予め設定しておくことができる。
【0043】
図中の“パターン1”は、例えば、ブロッキングから手数料計算までの5つの処理について、いずれも典型的な処理や単純な処理を行うバイサイドの場合であり、この場合は、5つの処理を全て予め定められた処理手順により自動処理することができる。“パターン2”は、例えば、ギブアップ処理の場合の変更先の証券会社の選択・決定のルールのみが複雑なバイサイドの場合であり、この場合は、ギブアップデータ作成のみセルサイド20の担当者が入力、実行し、他の処理は予め定められた処理手順により自動実行することができる。
【0044】
“パターン3”は、例えば、建玉指定で決済を行うバイサイドの場合であり、この場合は、決済の際に指定された建玉とペアリングするための決済ペアリングのみセルサイド20の担当者が入力、実行し、他の処理は予め定められた処理手順により自動実行することができる。このように、ポストトレードの各プロセスについて自動実行と手動実行とを適宜組み合わせた処理パターンを予め定めておくことで、バイサイド30の特性に応じて柔軟に自動処理の設定を行うことができる。
【0045】
図5は、各プロセスについて処理パターンの設定の際に指定することができる自動化属性の例について概要を示した図である。図中の“自動化属性”列は、自動処理の処理パターンを定義する上で設定することが必要な属性の項目の例を示している。例えば、ブロッキングの処理では、自動化属性に“同値寄せ”および“ブロッキングキー”があることから、“同値寄せ”および“ブロッキングキー”の設定内容に応じてブロッキング処理を自動化できることを示している。同様に、例えば、アロケーションの処理では、自動化属性に“自動アロケーション”および“手動アロケーション”があることから、これらの設定内容に応じてアロケーションを自動化できることを示している。ギブアップデータ作成、決済ペアリング、手数料計算などの他のプロセスについても同様である。
【0046】
図6は、各プロセスについての処理パターンの設定例について概要を示した図である。ここでは、「バイサイド×銘柄」の属性の組み合わせ毎に処理パターンを設定している例を示している。例えば、バイサイド30が“機関投資家”で、銘柄が“ラージ銘柄”(図中の“機関投資家×ラージ銘柄”)の場合は、一連の各プロセスを図示された内容によって予め設定されたロジックのパターンで自動実行することを示している。
【0047】
また、バイサイド30が“CTA(Commodity Trading Advisor:商品投資顧問業者)”で、銘柄が“ミニ銘柄”(図中の“CTA×ミニ銘柄”)の場合は、ギブアップデータ作成において、バイサイド30からファイルで指定された条件でギブアップするという手動処理が入る処理パターンが設定されており、自動処理がここで一時中断することを示している。同様に、バイサイド30が“地方銀行”で、銘柄が“ラージ銘柄”(図中の“地方銀行×ラージ銘柄”)の場合は、決済ペアリングにおいて手動でペアリングする処理パターンが設定されており、自動処理がここで一時中断することを示している。なお、上述した例では、注文の仕分けをバイサイド30と銘柄の属性の組み合わせ(「バイサイド×銘柄」)で行っているが、注文タイプなど他の項目との組み合わせを用いてもよい。
【0048】
このように、ポストトレードASP100において、バイサイド30や注文の属性情報などに基づいて注文を自動的に仕分けし、仕分けられた単位で予め定められた処理パターンに従ってポストトレード処理を自動化することで、オペレーションコストと処理時間を大幅に削減することができる。
【0049】
<照合処理>
ポストトレード処理では、バイサイド30、セルサイド20双方で手数料や税金の計算が行われ、これをバイサイド30側で照合(マッチング)する作業が行われる。照合が成功(マッチ)した場合は特に問題とならないが、照合が不一致(ブレイク)であった場合、その原因を確認する事務処理やバイサイド30とセルサイド20との間の連絡等が増えてしまうのに加えて、セルサイド20側の事務処理能力に対する評価の低下につながる場合がある。したがって、セルサイド20としては、照合処理の効率化に加えて、ブレイクとなった場合の修正や再計算をバイサイド30に覚知されずに速やかに行いたいというニーズがある。
【0050】
そこで、本実施の形態では、バイサイド30側での照合がブレイクした場合に、その通知をバイサイドシステム300上の画面に表示せず、すなわちバイサイド30側には通知せずに、ポストトレードASP100にのみ通知する。これにより、ポストトレードASP100上で、セルサイド20側が照合結果の確認と再計算をバイサイド30側に覚知されずに速やかに行うことが可能となる。
【0051】
図7は、本実施の形態におけるバイサイドとセルサイドとで行われる照合処理の流れの例について概要を示した図である。本実施の形態では、上述したように、ポストトレードASP100において、バイサイド30毎のアロケーションや手数料等の計算ルールを設定DB124に保持しておくことで、セルサイド20側でも手数料計算の処理を自動化することができる。
【0052】
図2に示した処理の流れと同様の処理によって、バイサイドシステム300およびセルサイド20側のポストトレードASP100のそれぞれにおいて手数料計算(S15b、S15_1s)までの処理が行われると、ポストトレードASP100から計算結果が通知され(S16_1s)、バイサイドシステム300において照合処理(S16_1b)が行われる。このとき、照合結果が不一致(ブレイク)であった場合は、その通知をバイサイドシステム300上の画面に表示せずに、すなわちバイサイド30側には覚知させずに、ポストトレードASP100にのみ通知する(S17_1b)。このとき、照合結果に加えてバイサイド30側での手数料計算結果のデータ、すなわち照合に係るバイサイド30側の「正解データ」も送信する。
【0053】
ポストトレードASP100では、照合結果の受信(S17_1s)を監視し、ブレイクが生じている場合には画面上でのメッセージ等によりセルサイド20側の担当者等に通知する。担当者は、照合結果における不一致事項の内容を確認し、手数料の更新を行う(S15_2s)。バイサイド30側での計算結果(「正解データ」)の内容に問題がない場合には、これをそのまま受け入れることも可能である。
【0054】
再計算の結果は再度バイサイドシステム300に対して通知され(S16_2s)バイサイドシステム300上で再度照合される(S16_2b)。ここでの照合も、バイサイド30側には覚知させずに自動で行う。ポストトレードASP100から送られる計算結果は、基本的にバイサイド30側での「正解データ」に基づいているため、再度の照合は成功(マッチ)する。そして、その照合結果がバイサイドシステム300からポストトレードASP100に送られる(S17_2b、S17_2s)。照合結果がマッチの場合は、バックオフィス接続(S21b、S21s)まで自動処理することができる。
【0055】
このように、バイサイド30とセルサイド20との間の計算結果の照合がブレイクした場合に、通知、再計算、再照合を、バイサイド30側に覚知させることなく行うことができる。これにより、ブレイク時のバイサイド30とセルサイド20との間の通知、連絡に係る事務処理を大幅に低減して処理を効率化することができるとともに、ブレイクの発生をバイサイド30側に覚知されることによるセルサイド20の評価への影響を回避することができる。
【0056】
なお、ポストトレードASP100においてブレイクの照合結果をバイサイドシステム300から受け取ってその内容を確認した際に、セルサイド20側の計算結果が正しいと判断される場合には、その旨の通知(「ブレイク公開通知」)をバイサイドシステム300に対して送信し、ブレイクの発生をバイサイド30側にオープンにして覚知させるようにしてもよい。この場合は、例えば、バイサイドシステム300においてセルサイド20側の計算結果のデータを取り込み、再度照合を実行することができる。
【0057】
また、
図7の例のように、バイサイドシステム300とポストトレードASP100の双方で個別に手数料計算を行い、照合することを可能とするためには、双方のシステムが手数料計算のルールおよび計算に用いるデータをそれぞれ保有する、もしくはポストトレードASP100上の共通DB121などに共有する構成を有していることが前提となる。
【0058】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。