JP6397622B2 - 証券フロントシステム - Google Patents

Description

本発明は、株式等の有価証券の売買取引を処理する技術に関し、特に、顧客からの大口の売買注文を処理する証券フロントシステムに適用して有効な技術に関するものである。

証券会社における顧客からの取引注文を処理する業務、特に、大口／ホールセールでのバスケット取引業務は、正式に受注する前のプライシングと、受注後の注文執行のプロセスに大別される。

プライシング業務では、顧客からの１つ以上のバスケットを含む売買の引き合いに対して、自社の利益やリスク等を考慮して対応可能な価格を計算して提示する。ここでは、基本的に、顧客からの引き合いに応じて口頭等での調整により複数のトレーダーの中から一人が担当者となり、業務を担当する。

また、注文執行業務では、プライシングの結果、当該顧客から正式な注文を受けた場合に、これをいったん自社のポジションとし、過剰となったポジションについて、その後、取引所に対して実際の売買注文を執行することによって解消する。このとき、自社のポジション内でのクロス取引や他の注文とのマッチング処理等を行って、実際に取引所に対して注文を執行する量を減らし、処理コストや、市場に対する影響を低減することが行われる。この注文執行業務では、通常、対象の注文についてプライシング業務で約定価格計算を担当したトレーダーが実際の売買処理を行う。

一般的には、複数の引き合いや注文に対するプライシングや注文執行などの業務を、複数のトレーダーが同時並行的に行ない、各トレーダーがそれぞれ自身が担当する案件のみを個別的に管理しているのが実情である。

証券会社等における顧客からの引き合いや注文を処理する際の技術については、各種のものが提案されており、例えば、特開２００５−１９００８１号公報（特許文献１）には、顧客から有価証券の売却を依頼された販売者が、その有価証券を特定の購入希望者に販売することを可能とする、有価証券の取引方法に係る技術が記載されている。ここでは、取引市場における特定銘柄の有価証券の買い注文の購入数量及び発注者の情報を含む取引状況を取得して、特定の投資家層と関連する情報として記憶された特定の発注者から所定数量の買い注文が出現したかを検出する購入取引状況監視工程と、前記買い注文を検出した場合に、前記販売処理システムが当該買い注文に対当する当該有価証券の売り注文を発注する売り注文発注工程とを備えている。

また、特開２０１０−２０４７０７号公報（特許文献２）には、流動性を高めることができるとともに、顧客に有利な換金を実現することができる有価証券売買処理システムに係る技術が記載されている。ここでは、売注文を受け付けると、売買区分・換金方法判定処理手段により、有価証券買取システムへの買取請求または売買市場への売注文の発注のいずれが顧客に有利かを判断する。買取請求が顧客に有利と判断した場合には、有価証券買取システムへ買取請求信号を送信し、売買市場への発注が顧客に有利と判断した場合には、注文データを売注文用記憶手段に記憶させることにより売買市場への売注文の発注処理を実行する。また、買注文を受け付けると、注文データを買注文用記憶手段に記憶させることにより売買市場への買注文の発注処理を実行する。

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

上述したように、大口の顧客からのバスケット取引等の注文については、トレーダー間での作業の分担や進捗状況の確認は口頭で行われているのが一般的であり、情報の共有がなされていない状況である。従って、例えば、特定のバスケットに着目した場合、既に担当者が割り当てられているか否か、担当者は誰であるか、プライシングは完了しているか、正式な受注をしたか、売買取引が完了したか等の、案件（バスケット）毎の進捗状況の把握が困難であるという課題を有する。

また、各取引の内容や、プライシング時の計算内容の情報がトレーダー間で共有されていないため、例えば、作業の途中から別の担当者に引き継いで交代したい、というような要望に対して対応することが困難であるという課題も有する。

そこで本発明の目的は、証券会社等において大口の顧客等からのバスケット取引の引き合いや注文を受け付けた際に、バスケット単位で進捗状況などのステータスや案件に係る各種情報等を管理し、複数のトレーダー間で共有することを可能とする証券フロントシステムを提供することにある。

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

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

本発明の代表的な実施の形態による証券フロントシステムは、有価証券の売買取引を取り扱う企業による、顧客からの１つ以上の有価証券の銘柄を含むバスケット取引の注文を受け付けて売買取引を行う業務を支援する証券フロントシステムであって、顧客からの売買取引の引き合いもしくは注文を受け付けて、バスケットの単位で案件の内容に係る情報を案件テーブルに登録し、当該売買取引に対してプライシングを行うトレーダーからの要求に応じて、前記案件テーブルに登録された１つ以上の案件の内容に係る一覧情報を、当該トレーダーの情報処理端末上に表示させるプライシング部を有するものである。

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

すなわち、本発明の代表的な実施の形態によれば、証券会社等において大口の顧客等からのバスケット取引の引き合いや注文を受け付けた際に、バスケット単位で進捗状況などのステータスや案件に係る各種情報等を一元的に管理し、複数のトレーダー間で共有することが可能となる。

本発明の一実施の形態である証券フロントシステムの構成例について概要を示した図である。 本発明の一実施の形態におけるバスケット取引の引き合いから注文の執行に至る処理の流れの例について概要を示した図である。 本発明の一実施の形態における案件の状態遷移の例を示した状態遷移図である。 本発明の一実施の形態における案件内の銘柄単位での明細の状態遷移の例を示した状態遷移図である。 本発明の一実施の形態における案件テーブルの構成例について概要を示した図である。 本発明の一実施の形態における明細テーブルの構成例について概要を示した図である。 本発明の一実施の形態における各受注案件の状態を管理する受注案件管理画面の例について概要を示した図である。 本発明の一実施の形態における各案件のプライシングに係る情報を表示するプライシング画面の例について概要を示した図である。

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

本発明の一実施の形態である証券フロントシステム／エクイティフロントシステムは、証券会社等において、顧客からの株式等の有価証券の売買の引き合いを受け付けてプライシングを行ったり、プライシングの結果に基づいて売買の注文を受け付けて、これを自己の注文との間でクロス取引したり、取引所等に対して執行したりという、有価証券の売買に係る業務を支援する処理を行うフロントエンドシステムである。

本実施の形態では、大口の顧客からのバスケット取引の引き合いや注文に対して、取引内容や進捗状況をデータベースに登録して一元的に管理し、複数のトレーダーが当該システムを利用してデータベースを参照して業務を行うことで、バスケット取引に係る情報の共有を可能とし、より適切かつ効率的な取引業務処理を可能とするものである。また、注文管理システムやプライシングシステムなどのサブシステム間で、バスケット取引に係るデータの連携や共有を行うことが可能となるため、データ入力などのトレーダーの作業負荷を低減させることが可能である。

上述したように、証券フロントシステムは、主にプライシング業務と注文執行業務とを行い、プライシング業務では顧客からの１つ以上のバスケットを含む売買の引き合いに対して、自社の利益やリスク等を考慮して対応可能な価格を計算して応答する。また、注文執行業務では、プライシングの結果、当該顧客から正式な注文を受けた場合に、これをいったん自社のポジションとし、過剰となったポジションについて、その後、取引所に対して実際の売買注文を執行することによって解消する。このとき、自社のポジション内でのクロス取引や他の注文とのマッチング処理等を行って、実際に取引所に対して注文を執行する量を減らし、処理コストや、市場に対する影響を低減することが行われる。

＜システム構成＞
図１は、本発明の一実施の形態である証券フロントシステムの構成例について概要を示した図である。証券フロントシステム１は、複数のサブシステムからなり、顧客が保有する情報処理端末である顧客端末３、および証券取引所の業務システムである取引所システム４と、図示しないインターネットやＶＰＮ（Virtual Private Network）等を利用したネットワークを介して接続される構成を有する。また、当該証券フロントシステム１を有する証券会社において各種のバックオフィス業務を行うバックオフィスシステム２と、図示しない社内ネットワーク等を介して接続される。

ここで、顧客端末３は、例えば、図示しない取引用の専用アプリケーション等を利用して証券フロントシステム１にアクセスし、株式等の有価証券の売買に係る引き合いや注文等の処理を行う。証券フロントシステム１が有するインタフェースに応じて、ファイル転送プログラム等を利用してデータファイルを送受信するものであってもよい。なお、顧客には、自身が保有する有価証券の売買を行う個人および法人も含まれ得るが、通常は投資顧問や機関投資家など、他の顧客の資産に基づいて売買を行う者である。また、取引所システム４には、例えば、東京証券取引所や大阪証券取引所などの証券取引所に加え、ＰＴＳ（Proprietary Trading System：私設取引システム）も含まれるものとする。

証券フロントシステム１は、例えば、サーバ機器や、クラウドコンピューティング環境上の仮想サーバなどにより構成されるサブシステムとして、顧客ＧＷ（ゲートウェイ）１０、委託ＯＭＳ（Order Management System：注文管理システム）２０、取引所ＧＷ（ゲートウェイ）３０、マッチングシステム４０、プライシングシステム５０、自己ＯＭＳ（注文管理システム）６０、ポジション管理システム７０、レンディングシステム８０、およびポストトレードシステム９０などを有する。これらのサブシステムは、それぞれが高い独立性をもって構成されるものとし、一部のサブシステムのみを新たに更改したりすることで柔軟かつ効率的な開発と運用を行うことを可能とする。

顧客ＧＷ１０は、顧客端末３からのアクセスを受け付けて取引に係るデータを取得するインタフェースを有し、必要に応じて後述する委託ＯＭＳ２０が処理することができるフォーマットにデータや電文等を変換した上で、委託ＯＭＳ２０に受け渡す機能を有する。顧客端末３上の図示しない専用アプリケーション等により提供される画面により入力されたデータを取得するインタフェースを提供するものであってもよいし、データファイルを読み込んで入力を受け付けるインタフェースを提供するものであってもよい。

委託ＯＭＳ２０は、顧客端末３を介した顧客からの売買に係る引き合いや注文を受け付けて管理する機能を有する。注文を受けた取引について、必要に応じて自動執行部２１を介して取引所ＧＷ３０を介して取引所システム４に対してシステム的に取り次いで自動執行することが可能である。取引所ＧＷ３０は、委託ＯＭＳ２０や、後述する自己ＯＭＳ６０の自動執行部２１、６１からの注文に係るデータに基づいて、各取引所システム４に対して当該注文を執行するための電文やメッセージを生成して、取引所システム４に送信し、応答を取得する機能を有する。

ここで、顧客からの注文が大口のバスケット取引等である場合は、そのまま取引所に取り次いで執行すると株価を変動させるような大きな影響を与えてしまう場合があることから、顧客がいわゆるプリンシパル取引を指定した場合は、証券会社が自己の注文との間で行うクロス取引や、他の顧客からの注文と突き合わせるマッチングなどの処理を行って注文を証券会社内で解消し、取引所に対して一時に執行する量を低減させることが行われる。なお、証券会社は、その後、必要に応じて自己が保有する株式の在庫（ポジション）調整のために非同期で取引所に対して注文を行う。

マッチングシステム４０およびプライシングシステム５０は、上記のマッチング処理や、クロス取引に係る処理およびこれらの処理を行うことを前提とした、顧客の大口の取引の引き合いに対する、自己の注文とのクロス取引も考慮した価格の見積りを行う機能を有する。

マッチングシステム４０は、委託ＯＭＳ２０からの手動／自動での要求に基づいて、他の顧客からの注文（バスケット）との間でネッティングできるものがあるか否かを判定し、トレーダーからの指示に基づいてネッティングする機能を有する。また、プライシングシステム５０についても、委託ＯＭＳ２０からの手動／自動での要求に基づいて、自己の注文との間でクロス取引が可能か否かを判定し、トレーダーからの指示に基づいて、ネッティングを行うことを前提として、顧客からの引き合いに対して、バスケット単位で基準価格や約定価格を計算するプライシングの機能を有する。

自己ＯＭＳ６０は、証券会社の自己部門での取引を管理する機能を有する。従って、顧客からの注文に対して、自己の注文との間でクロス取引を行って対応する場合、これに係る取引についても自己ＯＭＳ６０によって管理することになる。その結果、自己が保有する在庫の調整のために取引所に対する売買の注文が必要な場合は、自動執行部６１によって取引所ＧＷ３０を介して取引所システム４に対して注文を執行することも可能である。自己の注文とのクロス取引等の結果は、ポジション管理システム７０によって、在庫（ポジション）として図示しないデータベース等に登録・反映され、管理される。また、例えば、顧客の大量の買い注文に対して、自己の在庫では不足するために信用売りする場合に、信用取引を行ったり、レンディングシステム８０を介して外部の信託銀行や証券会社等から借株をしたりすることも可能である。

ポストトレードシステム９０は、顧客からの注文に対して、取引所に対する注文、もしくは自己の注文との間のクロス取引等が約定した場合に、例えば、複数のファンドをまとめた注文であった場合に、約定の結果を各ファンドに配分したり等の後処理を行って、顧客端末３に対して約定結果を通知する機能を行う。

なお、上記のシステム構成はあくまで一例であり、これに限られるものではなく、フロントエンドシステムとして同様の機能を実現することができる構成であれば、他のシステム構成であってもよいことは当然である。

＜処理の流れ＞
図２は、本実施の形態の証券フロントシステム１における、顧客からのバスケット取引の引き合いから注文の執行に至る処理の流れの例について概要を示した図である。まず、引き合い処理として、委託売買の業務を担当する委託トレーダーが、顧客からのバスケット取引の引き合い（仮注文）の情報を委託ＯＭＳ２０に取り込む引き合い受けの処理を行う（Ｓ０１）。

ここでは、例えば、顧客ＧＷ１０において画面入力やファイル転送などの手段により顧客から取得した引き合いに係る情報を、自動もしくは委託トレーダーの手動により顧客ＧＷ１０に取り込む。このとき、例えば、ファイルフォーマットを自動判別してデータを取り込んだり、取り込む際に銘柄コードや売買単位等の項目に対する妥当性チェックを行ったりしてもよい。その後、引き合いに係る案件の仮注文のデータについて、大口のバスケット取引等で顧客がプリンシパル取引を指定した場合には、委託トレーダーからの指示等に基づいて、委託ＯＭＳ２０およびプライシングシステム５０に送信（開示）する。

プライシングシステム５０では、証券会社の自己部門による売買業務を担当する自己トレーダーが、対象の案件についてバスケット単位で価格を見積もり、委託ＯＭＳ２０側に応答する（Ｓ０２）。ここでは、例えば、自己トレーダーが、プライシングシステム５０により提供される案件監視画面等を参照して委託トレーダー／委託ＯＭＳ２０側からのプライシングの依頼があることを確認し、バスケット番号等を指定して当該案件のデータを読み込み、自己トレーダーの情報処理端末上に表示する。

このとき、プライシングのために必要な参照情報として、例えば、引き合い案件の銘柄毎に、株数や、ポジション管理システム７０から取得した自己のポジション情報としての残高、借株合計などの情報を表示する。また、各銘柄についての売買を市場で執行した場合のマーケットインパクトを所定の手法やモデルにより計算し、これを積み上げて全体としてのインパクトを計算して表示する。このとき、先物でのヘッジなどを考慮してもよい。また、バスケットの変動性や流動性、自己のリスクなどを示す各種の指標についても所定の手法やモデルにより計算して表示する。

これらの情報を参照し、自己トレーダーは、例えば、構成比率の大きな銘柄や推定解消日数の長い銘柄の提示価格を個別に修正するなどし、修正結果に基づいて案件全体のマーケットインパクトを再計算する。この計算結果等に基づいて、最終的に自己トレーダーが価格を調整して決定し、委託ＯＭＳ２０側に提示する。

引き合い案件についての見積価格の提示を受けた委託ＯＭＳ２０側では、その情報を、例えば、顧客ＧＷ１０を介して顧客端末３に対して受け渡すことで連絡する（Ｓ０３）。受け渡しの手段は特に限定されず、例えば、委託トレーダーが電話等により手動で連絡するものであってもよいし、結果情報のデータファイルをファイル転送したり、ダウンロード可能な状態とした上で通知したり、電子メールにより送信したり等の各種の手段をとることも可能である。

その後、提示した価格に対して顧客が承諾した場合、約定処理として、まず、受注による売買が成立したものとして、委託ＯＭＳ２０において、委託トレーダーが、仮注文の状態の案件について正式に受注したステータスに更新する受注処理を行う（Ｓ０４）。このとき、プライシングシステム５０に対してもステータスが受注状態となったことが通知され、案件監視画面等において当該案件が受注状態となったことが把握可能なように表示される。

プライシングシステム５０では、例えば、自己トレーダーからの指示に基づいて、受注状態となった案件について案件データの再読み込みを行い、顧客に提示した価格情報に基づいて各銘柄の単価を再計算し、執行する市場を決定して、自己の注文との間でクロス取引を行ってクロス約定の情報を他のシステムや取引所に対して報告するクロス発注処理を行う（Ｓ０５）。

クロス取引による売りと買いの情報をセットで取引所に送信したものについて約定の結果を受信すると、これを委託ＯＭＳ２０側に通知するとともに、ポジション管理システム７０に対して、指定された銘柄についてポジションの更新を行う約定受信処理を行う（Ｓ０６）。委託ＯＭＳ２０側では、受信した約定情報を委託トレーダーにより所定の方法で顧客に対して通知する約定報告処理（Ｓ０７）を行う。ここでは、例えば、案件が複数のファンドをまとめた注文であった場合に、約定の結果を各ファンドに配分したり等の後処理をポストトレードシステム９０により行って、顧客端末３に対して通知することが可能である。

一方、ポジション管理システム７０においてポジションの更新が行われた場合、アンワインディング処理として、自己トレーダーは、必要な場合には在庫の銘柄の価格変動のリスクを低減するために、現物のポジションの場合は先物でヘッジするなどのポジションヘッジ処理を行う（Ｓ０８）。その後、先物でヘッジした後のポジションのリスクが減少するように、在庫調整のために行う売買のリバランス案件のバスケットを作成する（Ｓ０９）。その後、リバランス案件について、他の案件から生じた同様の解消案件との間でネッティングを行って、残った銘柄について別のバスケットを生成する。さらに、生成された各バスケットを流動性に応じて所定の条件に基づいて仕分けした後、自己ＯＭＳ６０の自動執行部６１によって取引所ＧＷ３０を介して取引所システム４に対して執行する執行処理を行う（Ｓ１０）。

以上の一連の処理により、大口の顧客からのバスケット取引の引き合いや注文に対して、複数のトレーダーによるバスケット取引に係る情報の共有を可能とし、より適切かつ効率的な取引業務処理が可能となる。また、委託ＯＭＳ２０、自己ＯＭＳ６０や、プライシングシステム５０などのサブシステム間で、バスケット取引に係るデータの連携や共有を行うことが可能となるため、データ入力などのトレーダーの作業負荷を低減させることが可能となる。

＜状態遷移＞
図３は、本実施の形態の証券フロントシステム１における案件（バスケット）の状態遷移の例を示した状態遷移図である。委託ＯＭＳ２０側において顧客から引き合いを受け、その情報がプライシングシステム５０側に送信（開示）されると、開示（ＳＴ０１）状態の案件が生成される。この状態で、いずれかの自己トレーダーが当該案件を担当することになり、当該案件のデータをプライシングシステム５０によって読み込むと、プライシング（ＳＴ０２）の状態となる。プライシング（ＳＴ０２）状態では、プライシングシステム５０によって行われた各種計算の結果等を自己トレーダーが参照し、顧客に対する提示価格の決定が行われる。

案件についての価格が決定されて顧客に提示され、顧客から正式な注文を受けると、新規に注文を受け付けた状態である本注文（ＳＴ０３）の状態に遷移する。なお、顧客に対して価格を提示していない開示（ＳＴ０１）の状態や、引き合いを受けていない状態からも、正式な注文を受け付けて本注文（ＳＴ０３）の状態に遷移することができる。

本注文（ＳＴ０３）の状態で、プライシングシステム５０において案件に係るデータが再度読み込まれると、案件読込（ＳＴ０４）の状態に遷移する。ここで、本注文（ＳＴ０３）もしくは案件読込（ＳＴ０４）の状態で、案件内の銘柄の追加や訂正などの新規登録があった場合は、訂正（ＳＴ０５）の状態に遷移する。訂正されたデータを反映（読み込み）させると、案件読込（ＳＴ０４）の状態に戻る。

案件読込（ＳＴ０４）の状態で、ポジションヘッジやリバランスなどの処理が行われた後、取引所に対して執行がなされると、執行中（ＳＴ０６）の状態に遷移する。その後、取引所から執行結果の応答を受けると、完了（ＳＴ０７）の状態に遷移して終了する。

図４は、本実施の形態の証券フロントシステム１における案件内の銘柄単位での明細の状態遷移の例を示した状態遷移図である。明細の状態遷移も、基本的には案件（バスケット）の状態遷移と同様であるが、明細の場合は、本注文（ＳＴ１３）および案件読込（ＳＴ１４）の状態を合わせて取消可能（ＳＴ１８）の状態として管理する。この状態では当該明細について取り消すことができ、これにより取消（ＳＴ１５）の状態に遷移して終了する。また、案件読込（ＳＴ１４）の状態で取引所に対して執行が行われ、執行中（ＳＴ１６）の状態に遷移した後、最終的に処理結果としてエラーを受け取った場合、案件読込（ＳＴ１４）の状態に戻る。これにより、エラー原因を訂正して再度執行することが可能となる。

このように、案件（バスケット）単位の状態遷移と、案件内の明細（銘柄）単位の状態遷移とを連携させつつ個別に管理することで、適切かつきめ細かい処理の制御と、複数のトレーダーによる各案件の状況の適切なトラッキングが可能となる。

＜データ構成＞
図５は、本実施の形態の証券フロントシステム１における案件テーブル５１の構成例について概要を示した図である。案件テーブル５１は、データベースやファイルテーブルにより実装され、プライシングシステム５０においてトランザクションの単位である各案件（バスケット）についての情報を一元的に保持するテーブルであり、例えば、案件ＩＤ、案件ステータス、トレーダーＩＤ、バスケット番号、入力時刻、顧客ＩＤ、顧客タイプ、クロス区分、クロス相手、買い明細数、売り明細数、買い銘柄数、売り銘柄数、および概算金額などの各項目を有する。

案件ＩＤの項目は、各案件を一意に識別することができるＩＤやシーケンス番号等の情報を保持する。案件ステータスの項目は、対象の案件についての上記図３に示した各状態を特定するコード値等の情報を保持する。トレーダーＩＤの項目は、対象の案件を担当するトレーダーを特定するＩＤ等の情報を保持する。バスケット番号の項目は、対象の案件に対応するバスケットの番号の情報を保持する。入力時刻の項目は、対象の案件の情報が当テーブルに入力された日時の情報を保持する。

顧客ＩＤおよび顧客タイプの各項目は、それぞれ、対象の案件の発注元である顧客を特定するＩＤ等の情報、および顧客のタイプなどを分類するコード情報を保持する。顧客のタイプとしては、例えば、リテール、ホールセール、ブローカーなどの区分を指定することができる。クロス区分およびクロス相手の各項目は、それぞれ、対象の案件について自己の注文との間でクロス取引する際の処理区分を示すコード値等の情報、およびクロス相手についてのＩＤや引き合い・注文を受領した委託ＯＭＳ２０などを特定する情報を保持する。クロス取引の処理区分としては、例えば、銘柄単位もしくはバスケット単位でのクロス取引、いわゆるプリンシパル取引やエージェンシー取引、ブローカー取引などの区分を指定することができる。

買い明細数および売り明細数の各項目は、それぞれ、対象の案件における買いおよび売りの明細数（件数）の情報を保持する。また、買い銘柄数および売り銘柄数の各項目は、それぞれ、対象の案件における買いおよび売りの銘柄数の情報を保持する。概算金額の項目は、対象の案件の概算の金額の情報を保持する。

図６は、本実施の形態の証券フロントシステム１における明細テーブル５２の構成例について概要を示した図である。明細テーブル５２は、案件テーブル５１と同様に、データベースやファイルテーブルにより実装され、プライシングシステム５０において各案件（バスケット）に含まれる銘柄毎の明細についての注文情報を一元的に保持するテーブルであり、例えば、注文ＩＤ、案件ＩＤ、執行ステータス、明細ステータス、銘柄コード、売買種別、注文数量、執行価格、値段区分、新規処理時刻、訂正時刻、取消時刻、基準値、基準値種別、執行市場、執行単位、および自己売買区分などの各項目を有する。

注文ＩＤおよび案件ＩＤの各項目は、それぞれ、各注文（明細）を一意に識別することができるＩＤやシーケンス番号等の情報、および対象の注文が含まれる案件を特定する案件ＩＤの情報を保持する。案件ＩＤの項目は、上記の図５に示した案件テーブル５１における案件ＩＤと同内容である。執行ステータスの項目は、対象の注文についての執行の実施状況を示す情報を保持する。例えば、新規、応答受信待ち、応答受信済み、エラー、約定済みなどの各状況を識別可能なコード値などにより表される。明細ステータスの項目は、対象の注文についての上記図４に示した各状態を特定するコード値等の情報を保持する。

銘柄コードの項目は、対象の注文における売買の対象の銘柄を特定する銘柄コードの情報を保持する。売買種別の項目は、対象の注文（明細）の取引が売りなのか買いなのかを特定するコード値等の情報を保持する。注文数量の項目は、対象の注文についての取引数量の情報を保持する。執行価格の項目は、プライシングシステム５０および自己トレーダーにより決定もしくは設定された、対象の注文を執行する際の価格の情報を保持する。値段区分の項目は、対象の注文に対して設定された価格の区分の情報を保持する。例えば、通常の価格か、ＶＷＡＰ（Volume Weighted Average Price：売買高加重平均価格）か、ＶＷＡＰの場合はどの期間のものか、などを特定するコード値等の情報を保持する。

新規処理時刻、訂正時刻、および取消時刻の各項目は、それぞれ、対象の注文を最初に受け付けて処理した日時、訂正があった場合に訂正処理を行った日時、および取消があった場合に取消処理を行った日時の情報をそれぞれ保持する。基準値および基準値種別の各項目は、それぞれ、対象の注文についての基準の価格の情報、および当該基準値の種別を特定するコード値等の情報を保持する。基準値の種別としては、例えば、現在価格、前場／後場の始値、各種ＶＷＡＰなどの種別を指定することができる。

執行市場および執行単位の各項目は、それぞれ、対象の注文を執行する際の取引市場として指定もしくは設定された市場を特定するコード値等の情報、および執行の単位を特定するコード値等の情報を保持する。執行の単位としては、例えば、単一銘柄取引、バスケット取引、終値取引などの種別を指定することができる。自己売買区分の項目は、対象の注文に対して行う自己売買が売りなのか買いなのかを特定するコード値等の情報を保持する。信用取引を行う場合の信用取引の種別を特定する情報を含んでいてもよい。

なお、上述の図４、図５で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。また、本実施の形態では、上記の各テーブルはプライシングシステム５０が有するものとしているが、これに限定されるものではなく、また、各サブシステム間で可能な限り共通してアクセス可能なように構成するのが望ましい。

このように、案件（バスケット）単位で案件テーブル５１に情報を一元的に保持し、バスケット内の明細を明細テーブル５２に保持するようにすることで、各トレーダーが案件毎の情報を共有することができ、より適切かつ効率的な取引業務処理が可能となる。

＜ユーザインタフェース＞
図７は、本実施の形態の証券フロントシステム１における各受注案件の状態を管理する受注案件管理画面の例について概要を示した図である。当画面は、例えば、委託ＯＭＳ２０や自己ＯＭＳ６０、プライシングシステム５０などについての共通した管理画面とすることができ、各サブシステムについての管理対象の案件およびその進捗状況を、委託トレーダーや自己トレーダーが保有する図示しない情報処理端末上に表示可能とすることで、トレーダーが各案件の進捗状況等を一覧として把握することができる。

図示するように、各サブシステムにおいて参照可能な各案件（バスケット）について、例えば、トレーダーのＩＤ単位で処理中もしくは処理可能な案件を絞り込んで、案件ステータスや、顧客、売買規模の情報などを一覧表示する。これにより、各トレーダーについて、処理中の案件については進捗状況等のトラッキングが可能であるとともに、顧客から新たに引き合いを受けた案件等で担当するトレーダーが未定の案件については、対応可能なトレーダーが順次着手して取引を進めることができ、全体としてリソースを有効活用した効率的な取引を実現することができる。

例えば、プライシングシステム５０において、図７に示すような案件管理画面上で自己トレーダーが１つ以上の特定の案件（バスケット）を選択して指示した場合、当該案件（バスケット）についてのプライシングに係る各種情報を詳細画面に表示する。図８は、本実施の形態の証券フロントシステム１のプライシングシステム５０における各案件のプライシングに係る情報を表示するプライシング画面の例について概要を示した図である。

ここでは、対象の案件（バスケット）について、売り／買い毎に、全体としての銘柄数や明細数、株数の情報、およびプライシングの結果の情報（提示するＢＰＳ（Basis PointS）に係る情報等）を表示している（複数案件の場合は集計、合算等したものを表示）。また、参照情報として、モデルによって計算されたインパクトやリスク等についての各種の指標（例えば、Ｔ．Ｅ．やＲ＾２、β等）を表示している。また、案件に含まれる各銘柄についても、株数や価格などのプライシングに必要となる情報が一覧表示され、トレーダーが個別に提示価格を調整して決定することが可能である。

以上に説明したように、本発明の一実施の形態である証券フロントシステム１によれば、顧客からのバスケット取引の引き合いや注文に対して、取引内容や進捗状況を案件テーブル５１や明細テーブル５２等のデータベースに登録して一元的に管理し、複数のトレーダーが当該システムを利用してデータベースを参照して業務を行うことで、バスケット取引に係る情報の共有が可能となり、より適切かつ効率的な取引業務処理が可能となる。また、委託ＯＭＳ２０や自己ＯＭＳ６０、プライシングシステム５０などのサブシステム間で、バスケット取引に係るデータの連携や共有を行うことが可能となるため、データ入力などのトレーダーの作業負荷を低減させることが可能である。

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

本発明は、顧客からの大口の売買注文を処理する証券フロントシステムに利用可能である。

１…証券フロントシステム、２…バックオフィスシステム、３…顧客端末、４…取引所システム、
１０…顧客ＧＷ、２０…委託ＯＭＳ、２１…自動執行部、３０…取引所ＧＷ、４０…マッチングシステム、５０…プライシングシステム、５１…案件テーブル、５２…明細テーブル、６０…自己ＯＭＳ、６１…自動執行部、７０…ポジション管理システム、８０…レンディングシステム、９０…ポストトレードシステム。

Claims (4)

1. 有価証券の売買取引を取り扱う企業による、顧客からの１つ以上の有価証券の銘柄を含むバスケット取引の注文を受け付けて売買取引を行う業務を支援する証券フロントシステムであって、
   顧客からの売買取引の引き合いもしくは注文を受け付けて、バスケットの単位で案件の内容に係る情報を案件テーブルに登録し、当該売買取引に対してプライシングを行うトレーダーからの要求に応じて、前記案件テーブルに登録された１つ以上の案件の内容に係る一覧情報を、当該トレーダーの情報処理端末上に表示させるプライシング部を有し、
   前記プライシング部と、顧客からの委託取引の注文を管理する委託注文管理部、および前記企業の自己部門による取引を管理する自己注文管理部との間で、前記案件テーブルに登録された案件の情報を共有し、
   前記プライシング部は、前記トレーダーにより入力された前記バスケットの見積もり額を前記委託注文管理部へ提示し、
   前記委託注文管理部は、前記見積もり額について承諾された場合、受注処理を行う、
   証券フロントシステム。
2. 請求項１に記載の証券フロントシステムにおいて、
   前記プライシング部は、案件のバスケットに含まれる銘柄毎の明細の単位で内容に係る情報を明細テーブルに登録し、トレーダーからの要求に応じて、前記案件テーブルに登録された特定の案件の内容、および前記明細テーブルに登録された当該案件のバスケットに含まれる明細の内容に係る情報を、当該トレーダーの情報処理端末上に表示させる、証券フロントシステム。
3. 請求項１または２に記載の証券フロントシステムにおいて、
   前記案件テーブルに登録された案件の情報には、当該案件に係る取引業務の進捗の状況を示すステータスの情報が含まれる、証券フロントシステム。
4. 請求項１〜３のいずれか１項に記載の証券フロントシステムにおいて、
   トレーダーの情報処理端末上に表示された前記一覧情報に含まれる案件のうち、担当するトレーダーが未決のものについて、前記情報処理端末を介したトレーダーからの指示に基づいて、当該トレーダーが担当するものとして割り当てる、証券フロントシステム。

Images