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

Abstract

【課題】ＶＷＡＰ取引の注文について、取引時間が終了してＶＷＡＰ値が確定し次第、速やかに約定単価の計算と約定処理を行うことを可能とする。
【解決手段】有価証券の売買取引の注文を受け付けて相対取引を行う業務を支援する証券フロントシステム１であって、売買取引の引き合いもしくは注文を受け付けて、案件の内容に係る情報を案件テーブルに登録し、トレーダーからの要求に応じて、前記案件テーブルに登録された１つ以上の案件の内容に係る一覧情報を、当該トレーダーの情報処理端末上に表示させるプライシングシステム５０を有し、プライシングシステム５０は、案件に係る売買取引がＶＷＡＰ取引であった場合に、約定処理のために用いられる所定の情報の一部もしくは全部について、ＶＷＡＰ値が確定する前に予め登録を受け付け、ＶＷＡＰ値が確定した後に、当該ＶＷＡＰ値と前記所定の情報とに基づいて約定単価を算出し、約定処理を実行する。
【選択図】図１

Description

本発明は、証券会社と顧客との間の株式等の有価証券の相対取引を処理する技術に関し、特に、いわゆるＶＷＡＰ（Volume Weighted Average Price：出来高加重平均価格）取引を処理する証券フロントシステムに適用して有効な技術に関するものである。

証券会社が、顧客、特に大口の顧客との間で株式等の有価証券を相対取引する際の処理としては、一般的に、顧客からの売買の引き合いに対して、自社の利益やリスク等を考慮して対応可能な価格を計算して提示し（プライシング）、当該顧客から正式な注文を受けた場合に、これをいったん自社のポジションとし、過剰となったポジションについて、その後、取引所に対して実際の売買注文を執行することによって在庫調整を行い解消するという流れとなる。このとき、自社のポジション内でのクロス取引や他の注文とのマッチング処理等を行って、実際に取引所に対して注文を執行する量を減らし、処理コストや、市場に対する影響を低減することが行われる。

一方、相対取引の一形態であるＶＷＡＰ取引やＶＷＡＰ−Ｇ（ＶＷＡＰギャランティー）取引の場合は、前場寄り付き前や後場寄り付き前の相場が止まっているタイミングで証券会社が顧客から受注し、預かった注文について実際に売買した平均価格（ＶＷＡＰ）がその後の終日もしくは前場や後場での市場の平均価格（ＶＷＡＰ）と同じになるように、もしくはこれに近づくように証券会社が取引所に対して売買注文を執行するものである。これにより、例えば、顧客が日中の価格変動等を意識せずに売買することができる等のメリットが得られる。

この場合であっても、実際には、証券会社がいったん自社のポジションとした後に在庫調整するという上記の一般的な相対取引と同様の処理は行われ得る。また、ＶＷＡＰ取引では、顧客との間の約定処理は前場や後場の取引時間が終了した後に計算されるＶＷＡＰ値を基準として行われるのが一般的である（ＶＷＡＰ−Ｇ取引の場合は証券会社が自己のリスクによりＶＷＡＰ値での約定を保証する代わりに一定の手数料を得る）。

ＶＷＡＰ取引に関連する技術としては、例えば、特開２００５−１００１４８号公報（特許文献１）には、トレーダーの執行した取引に対するＶＷＡＰと市場での取引に対するＶＷＡＰとの差であるＶＷＡＰ損益を、マーケット要因評価手段、タイミング要因評価手段、及び執行価格要因評価手段により、市場の変動に起因する損益を示すマーケット要因と、トレーダーの売買を執行する時間区分の選択に起因して生じる損益を示すタイミング要因と、トレーダーの売買を執行する価格に起因して生じる損益を示す執行価格要因とに分離し、その結果をデータ出力手段により出力することで、トレーダーの行った取引執行の巧拙の評価を行う技術が記載されている。

また、特開２０１０−５５５２６号公報（特許文献２）には、発注元とマーケットメイカーの入出力端末と、ＶＷＡＰクロッシング・システムと、情報系システムと通信でき、発注元が失効注文を約定するために許容できる許容スプレッド値を含む条件を記憶する発注元側条件受付手段と、マーケットメイカーに失効注文を約定させるために必要な受諾スプレット値を含む条件を記憶するマーケットメイカー側条件受付手段と、レーティング値を管理するレーティング値管理手段と、記憶された条件とレーティング値とから回送先を決定する回送先決定手段と、仮約定を確定させる仮約定管理手段と、本約定を確定させる本約定管理手段とを備えるＶＷＡＰハイブリッド・システムが記載されている。これによれば、約定率を向上させ、機関投資家等の発注元の負担を軽減し、マーケットインパクトを与えることなく、効率的にＶＷＡＰ値を用いて大口注文を処理することが可能になるとされる。

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

上述したように、ＶＷＡＰ取引では、確定的なＶＷＡＰ値が取引時間終了後に算出され、これに基づいて約定単価が決定されて約定処理が行われる。証券会社における従来の約定処理システムでは、約定単価が決定した後でなければ種々のデータを登録することができないのが通常である。従って、ＶＷＡＰ値が確定する取引時間終了後（引け後）にデータ登録等の作業が集中し、処理効率が低下して処理に要する時間も増えてしまうという課題を有する。

そこで本発明の目的は、ＶＷＡＰ取引の注文について、取引時間が終了してＶＷＡＰ値が確定し次第、速やかに約定単価の計算と約定処理を行うことを可能とする証券フロントシステムを提供することにある。

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

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

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

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

すなわち、本発明の代表的な実施の形態によれば、ＶＷＡＰ取引の注文について、ＶＷＡＰ値が確定する前に、約定処理に必要な各種パラメータを予め登録しておくことで、取引時間が終了してＶＷＡＰ値が確定し次第、各種データを取得して速やかに約定単価の計算と約定処理を行うことが可能となる。

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

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

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

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

本実施の形態では、顧客から受けた注文がＶＷＡＰ取引（本実施の形態では、特に断らない限り、ＶＷＡＰ取引とは、証券会社がＶＷＡＰ値での約定を保証するＶＷＡＰ−Ｇ取引を指すものとする）であり、ＶＷＡＰ値およびこれに基づく約定価格が取引時間終了時まで確定できないような場合であっても、約定処理に必要な各種パラメータを予め登録しておくことで、取引時間が終了してＶＷＡＰ値が確定し次第、各種データを取得して速やかに約定単価の計算と約定処理を行うことを可能とする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図３は、本実施の形態の証券フロントシステム１における、顧客からのＶＷＡＰ取引の引き合いから注文の執行に至る処理の流れの例について概要を示した図である。ステップステップＳ１１〜Ｓ１４までは、図２の例のステップＳ０１〜Ｓ０４の処理と同様であるため、再度の説明は省略する。なお、プライシング（Ｓ１２）の処理では、図２の例におけるプライシング（Ｓ０２）の処理と同様に、指定された各銘柄についてのマーケットインパクトの情報などに基づいて、ＶＷＡＰ値に対して上乗せするマージンを算出する。

ステップＳ１４で、委託ＯＭＳ２０において委託トレーダーにより受注処理が行われ、プライシングシステム５０に対してステータスが受注状態となったことが通知されると、プライシングシステム５０では、例えば、自己トレーダーからの指示に基づいて案件データの再読み込みを行い、指定された各銘柄について、約定価格としてその時点での価格（例えば前場寄り付き前の場合は前日の終値、後場寄り付き前の場合は前場の終値）を設定する仮入力処理を行う（Ｓ１５）。

さらに、ポジション管理システム７０に対して、指定された銘柄についてポジションの更新を行う仮約定受信処理を行う（Ｓ１６）。このとき、更新するポジションを仮ポジションとして登録しておくことで、当該ポジションがＶＷＡＰ取引によって登録された仮のものであることを容易に把握できるようにする。なお、仮ポジションの更新の場合は、この時点での取引所へのデータの送信は行わず、ポジション管理システム７０のデータの更新のみを行うものとする。取引所へのデータの送信は、取引時間が終了してＶＷＡＰ値が確定した後に行うことになる。

ポジション管理システム７０において仮ポジションの更新が行われると、アンワインディング処理として、自己トレーダーは、例えば、マッチングシステム４０を介して、仮ポジションを含む自己のポジション内で、他の案件との間でネッティングが可能である場合にネッティングを行う（Ｓ１７）。さらに、ＰＴＳ（私設取引システム）等のものも含めて、他の案件との間でクロス取引が可能であるか否かを探索するようにしてもよい（Ｓ１８）。これにより、ネッティングの機会が可能な限り増えるようにすることができる。

その後、仮ポジションの銘柄について、在庫調整における実際の売買のＶＷＡＰ値が市場全体のＶＷＡＰ値と同じになるように、もしくはこれに近づくように、自己ＯＭＳ６０の自動執行部６１によって取引所ＧＷ３０を介して取引所システム４に対してヘッジトレーディングを行う（Ｓ１９）。

その後、取引時間が終了し、ＶＷＡＰ値が確定した後に、図２の例のＳ０５の処理と同様に、顧客に提示した価格情報に基づいて各銘柄の約定単価を再計算し、執行する市場等を決定して、自己の注文との間でクロス取引を行ってクロス約定の情報を他のシステムや取引所に対して報告するクロス発注処理を行う（Ｓ２０）。

ここで、クロス発注による約定処理を行うためには、上記のように、約定単価の他に、執行市場や、グロス／ネットの別などの、取引所に対して執行する際に必要となる条件や、ＶＷＡＰ値からの上乗せ率や、端数の丸め方などの、約定単価を決める際に必要となる条件、約定の結果をポジションに反映させる際に必要な自己のアカウントの条件など、各種のデータやパラメータの設定が必要となる。本実施の形態では、これらのデータやパラメータの一部もしくは全部を予め登録可能とすることで、ＶＷＡＰ値が確定した段階で、自動的に約定単価の計算を行い、速やかにクロス取引による約定処理を行うことが可能となる。

クロス取引による売りと買いの情報をセットで取引所に送信したものについて約定の結果を受信すると、図２の例のステップＳ０６の処理と同様に、これを委託ＯＭＳ２０側に通知するとともに、ポジション管理システム７０に対して、指定された銘柄についてポジションの更新を行う約定受信処理を行う（Ｓ２１）。委託ＯＭＳ２０側では、図２の例のＳ０７の処理と同様に、受信した約定情報を委託トレーダーにより所定の方法で顧客に対して通知する約定報告処理（Ｓ２２）を行う。最後に、ステップＳ１６で更新した仮ポジションを削除して、ポジションをフラットにする仮約定削除処理（Ｓ２３）を行う。

以上の一連の処理において、例えば、顧客がＡ銘柄を１００株売る場合を想定すると、ステップＳ１６で更新される仮ポジションは、「Ａ銘柄：−１００株」となる。その後、自動執行部６１によりＡ銘柄について＋１００株のヘッジトレーディング（Ｓ１９）が行われると、ポジションは「Ａ銘柄：±０株」となる。取引時間が終了し、顧客との間でクロス取引を正式に行うと（Ｓ２０）、ポジションは「Ａ銘柄：−１００株」となるが、最後に仮ポジション「Ａ銘柄：−１００株」を削除することにより（Ｓ２３）、再び「Ａ銘柄：±０株」となってフラットになる。このとき、ポジション管理システム７０において自己ポジション側に残るのは、自身が行ったヘッジトレーディングの「Ａ銘柄：＋１００株」と、顧客とのクロス取引の「Ａ銘柄：−１００株」のみとなる。

以上の一連の処理のように、ＶＷＡＰ取引の引き合いや注文に対して、例えば、仮ポジションとして取り扱ってポジション管理システム７０に登録することで、基本的には図２の例に示したような通常の大口のバスケット取引と同様の処理によって対応することが可能となる。

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

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

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

案件読込（ＳＴ０４）の状態では、仮ポジションの更新が行われ、ポジションヘッジやリバランス、ポジションネッティングやクロス機会探索などのアンワインディング処理が行われる。取引時間終了後に、取引所に対してクロス取引が送信されると、執行中（ＳＴ０６）の状態に遷移する。その後、取引所から執行結果の応答を受けると、完了（ＳＴ０７）の状態に遷移して終了する。

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

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

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

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

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

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

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

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

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

新規処理時刻、訂正時刻、および取消時刻の各項目は、それぞれ、対象の注文を最初に受け付けて処理した日時、訂正があった場合に訂正処理を行った日時、および取消があった場合に取消処理を行った日時の情報をそれぞれ保持する。基準値および基準値種別の各項目は、それぞれ、対象の注文についての基準の価格の情報、および当該基準値の種別を特定するコード値等の情報を保持する。基準値の種別としては、例えば、現在価格、前場／後場の始値、各種ＶＷＡＰ（前場、後場、終日など）等の種別を指定することができる。丸めタイプの項目は、ＶＷＡＰ値等の基準値に基づいて約定単価を計算する際の端数の丸め方を示す情報を保持する。例えば、四捨五入、切り捨て、切り上げなどの方法を識別可能なコード値などにより表される。

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

グロス／ネット区分の項目は、対象の注文がグロス決済かネット決済かを特定するコード値等の情報を保持する。ＶＷＡＰベーシスコストの項目は、ＶＷＡＰ取引の場合に、確定したＶＷＡＰ値に基づいて約定単価を算出する際に上乗せするベーシスコストの値を保持する。この値は、例えば、顧客から注文を受けた際に合意によって設定される。

上記の各データ項目のうち、例えば、丸めタイプや、執行市場、執行単位、自己アカウント、グロス／ネット区分、ＶＷＡＰベーシスコストなど、ＶＷＡＰ取引の注文を受けた際には必ずしも必要ではないが、約定単価を決定して取引所に執行する際には必要となる項目について、本実施の形態では、注文を受けた際や取引時間中など（例えば、図３のステップＳ１５など）に、自己トレーダー等が予め設定・登録しておくものとする。

これにより、取引時間が終了してＶＷＡＰ値が確定し次第、これらのデータを取得して自動的に約定単価を計算し、速やかにクロス発注による約定処理（図３のステップＳ２０）を行うことが可能である。

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

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

また、ＶＷＡＰ取引による案件および明細についても、通常の案件と同様に案件テーブル５１および明細テーブル５２に登録することで、通常の案件についての処理手順と同様の処理で対応することができるとともに、通常の案件と同様にネッティングやクロス取引の対象とすることもできる。このとき、明細テーブル５２において、明細単位で価格や基準値の情報がＶＷＡＰ取引を対象としたものであることを指定して識別できるようにし、また、ポジション管理システム７０においても同様に識別可能なように登録する、すなわち、仮ポジションとして管理することで、ヘッジトレーディング等の際の対象を容易に把握することが可能である。

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

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

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

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

以上に説明したように、本発明の一実施の形態である証券フロントシステム１によれば、顧客から受けた注文がＶＷＡＰ取引であり、ＶＷＡＰ値およびこれに基づく約定価格が取引時間終了時まで確定できないような場合であっても、約定処理に必要な各種パラメータの一部もしくは全部を予め登録しておくことで、取引時間が終了してＶＷＡＰ値が確定し次第、各種データを取得して速やかに約定単価の計算と約定処理を行うことが可能となる。

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

本発明は、いわゆるＶＷＡＰ取引を処理する証券フロントシステムに利用可能である。

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

Claims (2)

1. 有価証券の売買取引を取り扱う企業による、顧客からの１つ以上の有価証券の銘柄を含む売買取引の注文を受け付けて相対取引を行う業務を支援する証券フロントシステムであって、
   顧客からの売買取引の引き合いもしくは注文を受け付けて、案件の内容に係る情報を案件テーブルに登録し、当該売買取引に対してプライシングを行うトレーダーからの要求に応じて、前記案件テーブルに登録された１つ以上の案件の内容に係る一覧情報を、当該トレーダーの情報処理端末上に表示させるプライシング部を有し、
   前記プライシング部は、案件に係る売買取引がＶＷＡＰ取引であった場合に、当該案件に含まれる各銘柄について、前記トレーダーの情報処理端末から、確定したＶＷＡＰ値に基づく約定処理のために用いられる所定の情報の一部もしくは全部について、ＶＷＡＰ値が確定する前に予め登録を受け付け、ＶＷＡＰ値が確定した後に、当該ＶＷＡＰ値と前記所定の情報とに基づいて約定単価を算出し、約定処理を実行する、証券フロントシステム。
2. 請求項１に記載の証券フロントシステムにおいて、
   確定したＶＷＡＰ値に基づく約定処理のために用いられる前記所定の情報は、前記案件に含まれる各銘柄についての約定単価を算出するための条件、および、約定処理を取引所に対して実行するための条件を含む、証券フロントシステム。
   

Images