(57)【要約】【課題】誤発注を起こしてからリカバリー注文を行うまでの時間を短くすることが可能な株式売買管理装置を提供する。【解決手段】本発明に係る株式売買管理装置２０は、誤発注が疑われる銘柄を検出する為の誤発注検出条件を保持する誤発注検出条件保持部２２２と、証券会社が発注した株式売買注文を保持する売買注文保持部２２４と、相場情報を複数の銘柄毎に単位時間ごとに取得する相場情報取得部２１２と、相場情報取得部２１２が取得した相場情報を保持する相場情報保持部２２０と、誤発注検出条件を満たす銘柄を疑誤発注銘柄として検出する疑誤発注銘柄検出部２０４と、疑誤発注銘柄検出部２０４が疑誤発注銘柄を検出した時間から一定時間前までの間に発注されており、かつ誤発注が疑われる株式売買注文である疑誤発注注文を抽出する疑誤発注注文抽出部２０６とを具備する。【選択図】図２
2008146423.tif 000002
【特許請求の範囲】
【請求項１】
証券会社で管理され、株式売買の誤発注注文を検出する株式売買管理装置であって、
株式の現在値、出来高及び板情報を含む相場情報の変動で構成される条件であり、誤発注が疑われる銘柄を検出する為の誤発注検出条件を保持する誤発注検出条件保持部と、
前記証券会社が発注した株式売買注文データを保持する売買注文保持部と、
証券取引所が管理する売買処理システムから前記相場情報を複数の銘柄コード毎に単位時間ごとに取得する相場情報取得部と、
前記相場情報取得部が取得した前記相場情報を保持する相場情報保持部と、
前記相場情報保持部が保持している前記相場情報を解析することにより、前記誤発注検出条件保持部が保持している前記誤発注検出条件を満たす銘柄の銘柄コードを疑誤発注銘柄コードとして検出する疑誤発注銘柄検出部と、
前記売買注文保持部が保持しており、かつ前記疑誤発注銘柄コードに関する前記株式売買注文データのうち、前記疑誤発注銘柄検出部が前記疑誤発注銘柄コードを検出した時間から一定時間前までの間に発注された株式売買注文データである疑誤発注注文データを抽出する疑誤発注注文抽出部と、
を具備する株式売買管理装置。
【請求項２】
誤発注注文データからリカバリー注文データを生成するためのプログラムを保持するリカバリー注文生成プログラム保持部と、
前記リカバリー注文生成プログラム保持部が保持している前記プログラム及び前記疑誤発注注文データを用いて、リカバリー注文データを生成し、該リカバリー注文データを前記売買処理システムに送信するリカバリー注文生成部と、
を具備する請求項１に記載の株式売買管理装置。
【請求項３】
前記疑誤発注注文データが示す発注が誤発注と確認されて前記リカバリー注文データの送信指示が入力された場合に、前記リカバリー注文生成部は、生成した前記リカバリー注文データを前記売買処理システムに送信する処理を行う請求項２に記載の株式売買管理装置。
【請求項４】
前記疑誤発注注文データが示す発注が誤発注と確認され、生成された前記リカバリー注文データが前記売買処理システムに送信された場合に、前記疑誤発注注文データ及び前記リカバリー注文データの約定状態に基づいて前記誤発注による確定損失を算出する確定損失算出部を更に具備する請求項２又は３に記載の株式売買管理装置。
【請求項５】
前記誤発注検出条件は、前記単位時間内に前記現在値が１ティックの定数倍動くことである請求項１〜４のいずれか一項に記載の株式売買管理装置。
【請求項６】
コンピュータを請求項１〜５に記載の株式売買管理装置として機能させる為のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、株式売買注文の誤発注注文に対するリカバリー注文を行う為の株式売買管理装置及びプログラムに関する。
【背景技術】
【０００２】
証券会社の売買担当者が顧客から依頼された株式の売買注文を発注する場合、売買注文の入力を手入力で行うことが多々ある。このため、売買注文の入力ミスによって株式売買の誤発注を起こしてしまうことがある（例えば非特許文献１，２）。誤発注を起こした場合、誤発注に対するリカバリー処理を行う必要がある。リカバリー処理は、例えば証券取引所からの連絡によって誤発注を確認した後に行われ、約定済みの数量に対するリカバリー注文、及び誤発注による損害計算が含まれる。
【０００３】
【非特許文献１】「立花証券誤発注、市場で株買い戻し、損失１０億円超の可能性」、日本経済新聞  朝刊、２００６年６月２１日、ｐ４
【非特許文献２】「みずほ証券、大量発注ミス、新規上場株売買  −  ８日時点、損失２７０億円」、日本経済新聞  朝刊、２００５年１２月９日、ｐ１
【発明の開示】
【発明が解決しようとする課題】
【０００４】
誤発注による損害を少なくする為には、誤発注を起こしてからリカバリー注文を行うまでの時間を短くする必要がある。従来は誤発注の検出及びリカバリー注文の発注を手作業で行っていた為、誤発注を起こしてからリカバリー注文を行うまでの時間を短くすることができなかった。また、リカバリー注文の発注は緊迫した状況で行われる為、再び誤発注を起こす可能性があった。
【０００５】
本発明は上記のような事情を考慮してなされたものであり、その目的は、誤発注を起こしてからリカバリー注文を行うまでの時間を短くすることが可能な株式売買管理装置及びプログラムを提供することにある。また本発明の他の目的は、リカバリー注文におけて誤発注を行うことを防止できる株式売買管理装置及びプログラムを提供することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、本発明に係る株式売買管理装置は、証券会社で管理され、株式売買の誤発注注文を検出する株式売買管理装置であって、
株式の現在値、出来高及び板情報を含む相場情報の変動で構成される条件であり、誤発注が疑われる銘柄を検出する為の誤発注検出条件を保持する誤発注検出条件保持部と、
前記証券会社が発注した株式売買注文データを保持する売買注文保持部と、
証券取引所が管理する売買処理システムから前記相場情報を複数の銘柄コード毎に単位時間ごとに取得する相場情報取得部と、
前記相場情報取得部が取得した前記相場情報を保持する相場情報保持部と、
前記相場情報保持部が保持している前記相場情報を解析することにより、前記誤発注検出条件保持部が保持している前記誤発注検出条件を満たす銘柄の銘柄コードを疑誤発注銘柄コードとして検出する疑誤発注銘柄検出部と、
前記売買注文保持部が保持しており、かつ前記疑誤発注銘柄コードに関する前記株式売買注文データのうち、前記疑誤発注銘柄検出部が前記疑誤発注銘柄コードを検出した時間から一定時間前までの間に発注された株式売買注文データである疑誤発注注文データを抽出する疑誤発注注文抽出部とを具備する。
【０００７】
誤発注注文データからリカバリー注文データを生成するためのプログラムを保持するリカバリー注文生成プログラム保持部と、前記リカバリー注文生成プログラム保持部が保持している前記リカバリー注文生成条件及び前記疑誤発注注文データを用いて、リカバリー注文データを生成し、該リカバリー注文データを前記売買処理システムに送信するリカバリー注文生成部とを具備してもよい。
この場合、前記疑誤発注注文データが示す発注が誤発注と確認されて前記リカバリー注文データの送信指示が入力された場合に、前記リカバリー注文生成部は、生成した前記リカバリー注文データを前記売買処理システムに送信する処理を行ってもよい。
【０００８】
前記疑誤発注注文データが示す発注が誤発注と確認され、生成された前記リカバリー注文データが前記売買処理システムに送信された場合に、前記疑誤発注注文データ及び前記リカバリー注文データの約定状態に基づいて前記誤発注による確定損失を算出する確定損失算出部を更に具備してもよい。
【０００９】
前記誤発注検出条件は、例えば前記単位時間内に前記現在値が１ティックの定数倍動くことである
【００１０】
本発明に係るプログラムは、コンピュータを上記の株式売買管理装置として機能させる為のプログラムである。
【発明の効果】
【００１１】
本発明によれば、誤発注を起こしてからリカバリー注文を行うまでの時間を短くすることができる。また、リカバリー注文におけて誤発注を行うことを防止できる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の実施形態について説明する。図１は本発明の実施形態に係る株式売買管理装置２０を有する株式売買システムの構成を説明する為の図である。株式売買管理装置２０は証券会社で管理される装置であり、社内通信網を介して売買担当者端末１０及び管理者端末１１に接続されている。株式売買管理装置２０は、売買担当者端末１０に入力された株式の売買注文データを、専用回線を介して証券取引所の売買処理システム６０に送信する。また株式売買管理装置２０は、誤発注の可能性がある売買注文データである疑誤発注注文データを抽出して管理者端末１１に表示させ、かつ疑誤発注注文データが示す発注が自社からの誤発注であると確認された場合にリカバリー処理を行う。以下、図を用いて詳細に説明する。
【００１３】
図２は、株式売買管理装置２０の構成を説明する為のブロック図である。株式売買管理装置２０は、発注処理部２０２、疑誤発注銘柄検出部２０４、疑誤発注注文抽出部２０６、リカバリー注文生成部２０８、確定損失算出部２１０、損失データベース（以下ＤＢと記載）２１０ａ、相場情報取得部２１２、相場情報ＤＢ２２０、誤発注検出条件ＤＢ２２２、売買注文ＤＢ２２４、及びリカバリー注文生成プログラム保持部２２６を具備する。
【００１４】
発注処理部２０２は、売買担当者が売買担当者端末１０に入力した株式の売買注文データを取得し、注文ＩＤを付した上で売買処理システム６０に送信し、かつ売買注文データを注文ＩＤに対応付けて売買注文ＤＢ２２４に格納する。また発注処理部２０２は、約定した売買注文データを特定するデータを売買処理システム６０から受信し、約定済みを示すデータ及び約定済みの数量を、受信したデータによって特定される売買注文データに対応付けて売買注文ＤＢ２２４に格納する。また発注処理部２０２は、平均約定価格を算出して売買注文ＤＢ２２４に格納する。
【００１５】
相場情報取得部２１２は、全ての銘柄の現在値、出来高及び板情報を含む相場情報を定期的（例えば１秒おき）に売買処理システム６０から取得し、取得した相場情報を取得時刻に対応付けて相場情報ＤＢ２２０に格納する。
【００１６】
なお、疑誤発注銘柄検出部２０４、疑誤発注注文抽出部２０６、リカバリー注文生成部２０８、及び確定損失算出部２１０が行う処理の詳細は、フローチャートを用いて後述する。また各ＤＢのデータ構成は、図を用いて後述する。
【００１７】
図３は、相場情報ＤＢ２２０のデータ構成の一例をテーブル形式で示す図である。相場情報ＤＢ２２０は、全ての銘柄それぞれ毎に、相場情報の履歴を示す情報を銘柄コード及び銘柄名に対応付けて保持している。相場情報の履歴を示す情報には、相場情報が取得された時刻、現在値、出来高、売気配値、売気配板数、買気配値、及び買気配板数が含まれている。このため、相場情報ＤＢ２２０に保持されているデータを用いることにより、相場情報の変化、例えば単位時間内の現在値の変化又は単位時間内の出来高を算出することができる。
【００１８】
図４は、誤発注検出条件ＤＢ２２２のデータ構成の一例をテーブル形式で示す図である。誤発注検出条件ＤＢ２２２は、誤発注が疑われる銘柄（以下、疑誤発注銘柄と記載）を検出する為の条件を保持している。この条件は、相場情報ＤＢ２２０が保持している相場情報の変動に関する条件であり、例えば現在値が所定時間内（例えば５秒間）に１ティックの所定倍（例えば１０ティック）動いたこと、現在値が所定時間内（例えば３秒間）に１ティックの所定倍（例えば５ティック）動いてストップ高（又はストップ安）に張り付くこと、又は直近の所定時間内（例えば５秒間）の出来高が平均の所定倍（例えば１００倍）になったこと、などである。
【００１９】
図５は、売買注文ＤＢ２２４のデータ構成の一例をテーブル形式で示す図である。売買注文ＤＢ２２４には、自社が発注処理したすべての売買注文データ、及び約定データが保持されている。売買注文データには、注文ＩＤ、銘柄コード、発注時刻、売買区分、注文数量、並びに注文単価又は成行注文を示す情報が含まれる。約定データには、約定価格別の約定数量、平均約定価格、全量約定したか否かを示すデータ、並びに取消の有無を示すデータすなわち証券取引所の売買処理システム６０に有効な売買注文データが残っているか否かを示すデータが含まれる。なお部分的に約定している場合、約定の有無を示すデータの代わりに約定済みの数量が格納される。
【００２０】
また、売買注文ＤＢ２２４は、リカバリー注文が発注された場合、リカバリー注文の詳細を示すリカバリー注文データを売買注文データの一つとして格納する。このとき売買注文ＤＢ２２４は、リカバリー注文データを、どの売買注文データに対するリカバリー注文かを示すデータ（例えば誤発注である売買注文データの注文ＩＤ）に対応付けて格納する。
【００２１】
本図に示した第１の例では、「注文ＩＤ００３」の売買注文データが、数量１０００００株の誤発注を行い、かつ９５０００株が約定したことを示している。そして「注文ＩＤ００４」、「注文ＩＤ００５」、及び「注文ＩＤ００６」の売買注文データが、指値で行われた「注文ＩＤ００３」に対応するリカバリー注文データである。例えば「注文ＩＤ００４」は指値が５５８円のリカバリー注文に関するデータであるが、９５０００株の買注文に対して所定期間（例えば１分）以内に３００００株しか約定していないことを示している。「注文ＩＤ００５」に関するデータは、「注文ＩＤ００４」の未約定の株数である７００００株を指値５５９円で再度リカバリー注文し直したことを示している。同様に「注文ＩＤ００６」に関するデータは、「注文ＩＤ００６」の所定期間経過後の未約定の株数である２５０００株を、指値５６０円で再度リカバリー注文し直したことを示している。なお、「注文ＩＤ００４」及び「注文ＩＤ００５」に関するリカバリー注文は所定期間経過後に取り消されている為、取消の有無を示す欄に、取り消したことを示すデータが格納されている。
【００２２】
また本図に示した第２の例では、「注文ＩＤ００８」の売買注文データが、数量１００００００株の成行の誤発注を行い、かつ９０００００株が約定したことを示している。そして「注文ＩＤ００９」の売買注文データが、「注文ＩＤ００８」に対応する成行のリカバリー注文データである。
【００２３】
リカバリー注文生成プログラム保持部２２６は、誤発注された注文データからリカバリー注文データを自動で生成するためのプログラムが格納されている。
図６（Ａ）及び（Ｂ）は、それぞれリカバリー注文生成プログラムＤＢ２２６が格納しているプログラムによって行われる売買注文を説明するための図である。例えば図６（Ａ）に示すプログラムは、まず誤発注である売買注文を取り消すことを示す取消注文データの生成及び送信を行い、その後、取消前に約定した数量分の反対売買を成行で行う為の成行注文データを生成して送信する、というものである。また図６（Ｂ）に示すプログラムは、まず誤発注の取消注文データの生成及び送信を行い、その後、取消前に約定した数量分の反対売買を指値注文で行う為の指値注文データを生成して送信する、というものである。指値注文データの生成及び送信においては、指値を予め決められた時間ごと（例えば１分ごと）に変更するために、指値注文データの取消注文及び新たな指値注文データの生成を上記した予め決められた時間ごとに行い、これら注文データを送信する。なお、指値注文データは一つの指値注文データであってもよいし、注文数量を分割した複数の指値注文データであっても。後者の場合、それぞれの指値注文データが示す注文数量を予め定められた数にしてもよい。
なお、図６（Ａ）及び（Ｂ）に示したプログラムの詳細については、フローチャートを用いて後述するが。
【００２４】
図７は、株式売買管理装置２０が有する疑誤発注銘柄検出部２０４、疑誤発注注文抽出部２０６、リカバリー注文生成部２０８、及び確定損失算出部２１０が行う処理の詳細の動作を説明する為のフローチャートである。株式売買管理装置２０の発注処理部２０２及び相場情報取得部２１２は、図７に示すフローチャートとは関係なしに動作している。
【００２５】
まず、疑誤発注銘柄検出部２０４は、誤発注が疑われる銘柄である疑誤発注銘柄の銘柄コードの検出処理を行う（Ｓ２）。疑誤発注銘柄の銘柄コードが検出されると疑誤発注注文抽出部２０６は、売買注文ＤＢ２２４を検索し、自社が発注した売買注文のうち疑誤発注銘柄の銘柄コードを含む売買注文データ（以下疑誤発注注文データと記載）を抽出し、この詳細データを管理者端末１１に表示させる（Ｓ４）。
【００２６】
その後、管理者が、疑誤発注注文データが示す売買注文が自社からの誤発注であると確認し、管理者端末１１にその旨の入力を行った場合（Ｓ６：Ｙｅｓ）、管理者端末１１は疑誤発注注文データの注文ＩＤをリカバリー注文生成部２０８に送信する。リカバリー注文生成部２０８は受信した注文ＩＤをリカバリー注文の発注指示と認識し、リカバリー注文データの生成及びリカバリー注文データの送信処理すなわちリカバリー注文の発注を行う（Ｓ８）。また確定損失算出部２１０は、リカバリー注文が約定するたびに確定損失の算出又は更新を行う（Ｓ８）。
【００２７】
図８は、図７のＳ２、すなわち疑誤発注銘柄検出部２０４が行う処理の詳細を説明する為のフローチャートである。疑誤発注銘柄検出部２０４は、所定時間（例えば５秒）が経過するたびに、以下に説明する処理（Ｓ２４〜Ｓ３２）を行う（Ｓ２２）。
【００２８】
まず疑誤発注銘柄検出部２０４は、売買注文ＤＢ２２４に格納されているすべての売買注文データに含まれる銘柄コードを読み出す。そして読み出した銘柄コードの一つを選択し（Ｓ２４）、選択された銘柄コードに対応する現在の相場情報と、以前（例えば５秒前）の相場情報を相場情報ＤＢ２２０から読み出す（Ｓ２６）。次いで、これら２つの相場情報を演算処理することにより、直前の相場情報の変動量（例えば直近５秒間に現在値が何ティック動いたか、または出来高がどれだけ増えたか等）を算出し（Ｓ２８）、算出した変動量が、誤発注検出条件ＤＢ２２２が保持している条件のいずれかに該当するか否かを判断する（Ｓ３０）。いずれかの条件に該当すると判断した場合（Ｓ３０：Ｙｅｓ）、疑誤発注銘柄検出部２０４は、Ｓ２４で選択していた銘柄コードを疑誤発注注文抽出部２０６に出力し、疑誤発注注文抽出部２０６に疑誤発注注文データの抽出処理を行わせる（図７のＳ４）。例えば図５に示す注文ＩＤ００３の売買注文データが誤送信（すなわち誤発注）された場合、例えば直近の所定時間内（例えば５秒間）の出来高が平均の所定倍になるため、疑誤発注注文抽出部２０６は、注文ＩＤ００３に含まれる銘柄コードが誤発注検出条件ＤＢ２２２が保持している条件に該当すると判断し、疑誤発注注文抽出部２０６に出力する。疑誤発注銘柄検出部２０４は、Ｓ２４〜Ｓ３０に示した処理を、読み出した全ての銘柄コードに対して行う（Ｓ３２）。
【００２９】
図９は、図７のＳ４、すなわち疑誤発注注文抽出部２０６が行う処理の詳細を説明する為のフローチャートである。疑誤発注注文抽出部２０６は、疑誤発注銘柄検出部２０４から銘柄コードを受信した時刻（例えば図５に示す注文ＩＤ００３の売買注文データが誤送信された場合は９時８分５０秒）を認識し、この時刻から所定時間前（例えば２０秒前：図５に示す注文ＩＤ００３の売買注文データが誤送信された場合は９時８分３０秒）の間に送信された売買注文データを売買注文ＤＢ２２４から抽出し（Ｓ４２）、さらに抽出した売買注文データの中に、疑誤発注銘柄検出部２０４から受信した銘柄コードを含むデータ、すなわち疑誤発注注文データがあるか否かを確認する（Ｓ４４）。疑誤発注注文データがある場合（Ｓ４４：Ｙｅｓ）、この疑誤発注注文データ（例えば図５に示す注文ＩＤ００３の売買注文データ）を抽出し（Ｓ４８）、管理者端末１１に送信して表示させ、処理を終了する（Ｓ５０）。なお、Ｓ４４に示した条件を満たし、かつ注文数量が単位単元の所定倍以上である売買注文データを疑誤発注注文データとして抽出しても良い。
【００３０】
図１０は、図７のＳ８、すなわちリカバリー注文生成部２０８及び確定損失算出部２１０が行う処理の詳細の第１例を説明する為のフローチャートである。本図に示す例において、リカバリー注文生成部２０８は、図６（Ａ）に示したプログラムを用いてリカバリー注文データを生成する。
【００３１】
売買注文ＤＢ２２４には、発注処理部２０２によって、取消注文が受け付けられるまでに約定した数量及び平均約定価格が格納されている。リカバリー注文生成部２０８は、リカバリー注文生成プログラム保持部２２６から図６（Ａ）に対応するプログラムを読み出し、このプログラムに従って以下の処理を行う。まずリカバリー注文生成部２０８は、管理者端端末１１から誤発注の注文ＩＤを受信する。そしてこの注文ＩＤを用いて、売買注文ＤＢ２２４から誤発注の銘柄コード（例えば図５の注文ＩＤ００８に対応する銘柄コード）、注文数量（例えば図５の注文ＩＤ００８の例においては１００００００）、約定済みの数量（例えば図５の注文ＩＤ００８の例においては９０００００）、及び平均約定価格（例えば図５の注文ＩＤ００８の例においては１００８．９）を読み出す（Ｓ８１）。
【００３２】
次いでリカバリー注文生成部２０８は、注文数量から約定済みの数量を差し引くことにより、取消注文すべき数量を算出し（例えば図５の注文ＩＤ００８の例においては１０００００）、この数量を対象とした誤発注の取消注文データを生成する。またリカバリー注文生成部２０８は、約定済みの数量を注文数量（例えば図５の注文ＩＤ００８の例においては９０００００）とした誤発注した銘柄の反対売買の成行注文データ（例えば図５の注文ＩＤ００９に示す売買注文データ）を生成する（Ｓ８２）。次いでリカバリー注文生成部２０８は、生成した取消注文データ及び成行注文データを取引所の売買処理システム６０に送信する。このようにして、取消注文及びリカバリーの為の成行注文が発注される（Ｓ８３）。
【００３３】
このときリカバリー注文生成部２０８は、売買注文ＤＢ２２４のうち誤発注注文に関する欄に取消注文を発注した旨を示す情報を格納し、かつ成行注文データに注文ＩＤ（例えば００９）を付して、この注文ＩＤ（例えば００９）、誤発注の注文ＩＤ（例えば００８）、及び成行注文データを売買注文ＤＢ２２４に格納する。またリカバリー注文生成部２０８は、損失ＤＢ２１０ａに誤発注の注文ＩＤ、銘柄コード、平均約定価格、約定済みの数量、及びリカバリーの為の成行注文データの注文ＩＤを格納する。
【００３４】
その後発注処理部２０２は、売買処理システム６０から取消完了数量、並びに取消失敗数量（すなわち成行注文を生成した（Ｓ８２に示した処理）後、取消完了の間に約定した数量）及びその約定価格をそれぞれ受信し、取消完了数量を売買注文ＤＢ２２４に格納するとともに、取消失敗数量を約定価格に対応付けて売買注文ＤＢ２２４に格納する。また発注処理部２０２は、取消完了数量、並びに取消失敗数量及びその約定価格をリカバリー注文生成部２０８に送信する。
【００３５】
リカバリー注文生成部２０８は、発注処理部２０２から受け取った情報に取消失敗数量が含まれていた場合（Ｓ８４：Ｙｅｓ）、取消失敗数量を注文数量とした誤発注の反対売買の成行注文データを再び生成し（Ｓ８５）、取引所の売買処理システム６０に送信する（Ｓ８６）。このときリカバリー注文生成部２０８は、再び生成した成行注文データに注文ＩＤを付して、この注文ＩＤ及び成行注文データを売買注文ＤＢ２２４に格納する。またリカバリー注文生成部２０８は、損失ＤＢ２１０ａに再び生成した成行注文の注文ＩＤを格納する。またリカバリー注文生成部２０８は、取消失敗数量及びその約定価格を用いて損失ＤＢ２１０ａに格納されている約定数及び平均約定価格を更新し、かつ再び送信したリカバリーの為の成行注文データの注文ＩＤを損失ＤＢ２１０ａに格納する。
【００３６】
発注処理部２０２は、リカバリー注文（例えば図５の注文ＩＤ００９に示す売買注文データ）が約定した旨及び約定価格ごとの約定数量を売買処理システム６０から受信すると、約定した旨を示すデータ、約定価格ごとの約定数量、及び平均約定価格を売買注文ＤＢ２２４に格納する。その後、確定損失算出部２１０は、損失ＤＢ２１０ａが保持しているリカバリー注文の注文ＩＤ（例えば図５の注文ＩＤ００９）を用いて、売買注文ＤＢ２２４からリカバリー注文の平均約定価格（例えば１０１０円）を読み出す。また確定損失算出部２１０は、誤発注の注文ＩＤ（例えば図５の注文ＩＤ００８）を用いて誤発注の平均約定価格（例えば１００８．８円）を損失ＤＢ２１０ａから読み出す。そして確定損失算出部２１０は、誤発注注文における平均約定価格とリカバリー注文における平均約定価格の差分（例えば１．２円）を算出し、この差分と誤発注注文における約定数量（例えば９０００００）の積を算出することにより、誤発注における確定損失（１０８００００円）を算出する。そして確定損失算出部２１０は、算出した確定損失を、確定損失を算出するときに用いた各データとともに損失ＤＢ２１０ａに格納する（Ｓ８５）。
【００３７】
図１１は、図７のＳ８、すなわちリカバリー注文生成部２０８及び確定損失算出部２１０が行う処理の詳細の第２例を説明する為のフローチャートである。本図に示す例において、リカバリー注文生成部２０８は、図６（Ｂ）に示した条件に従ってリカバリー注文を生成する。
【００３８】
本例においても、売買注文ＤＢ２２４には、発注処理部２０２によって、取消注文が受け付けられるまでに約定した数量が格納されている。リカバリー注文生成部２０８は、リカバリー注文生成プログラム保持部２２６から図６（Ｂ）に対応するプログラムを読み出し、このプログラムに従って以下の処理を行う。まずリカバリー注文生成部２０８は、管理者端端末１１から誤発注の注文ＩＤ（例えば図５の例においては００３）を受信する。そしてこの注文ＩＤを用いて、売買注文ＤＢ２２４から誤発注の銘柄コード（例えば図５の注文ＩＤ００３に対応する銘柄コード）、注文数量（例えば図５の注文ＩＤ００３の例においては１０００００）、約定済みの数量（例えば図５の注文ＩＤ００３の例においては９５０００）、及び平均約定価格（例えば図５の注文ＩＤ００３の例においては５５７．５）を読み出す（Ｓ９１）。
【００３９】
次いでリカバリー注文生成部２０８は、注文数量から約定済みの数量を差し引くことにより、取消注文すべき数量（例えば図５の注文ＩＤ００３の例では５０００）を算出し、この数量を対象とした取消注文データを生成する。またリカバリー注文生成部２０８は、相場情報ＤＢ２２０から誤発注した銘柄の現在価格（例えば図５の注文ＩＤ００３の例では５５８円）を取得し、この現在価格を注文価格とし、かつ約定済みの数量の全量を注文数量とした誤発注とは反対売買の指値注文データ（例えば図５の注文ＩＤ００４に示す売買注文データ）を生成する（Ｓ９２）。リカバリー注文生成部２０８は、この指値注文データを指値が同一の複数の注文データに分割し、それぞれの指値注文データが示す注文数量を、反対売買を行うべき数量より小さな数にしてもよい。次いでリカバリー注文生成部２０８は、生成した取消注文データ及び指値注文データを取引所の売買処理システム６０に送信する。このようにして、取消注文及びリカバリーの為の指値注文が発注される（Ｓ９３）。
【００４０】
このときリカバリー注文生成部２０８は、売買注文ＤＢ２２４のうち誤発注注文に関する欄に取消注文を発注した旨を示す情報を格納し、かつ指値注文データに注文ＩＤ（例えば注文ＩＤ００４）を付して、この注文ＩＤ及び指値注文データを、誤発注の注文ＩＤに対応付けて売買注文ＤＢ２２４に格納する。またリカバリー注文生成部２０８は、損失ＤＢ２１０ａに誤発注の注文ＩＤ、銘柄コード、平均約定価格、約定済みの数量、並びにリカバリーの為の指値注文データの注文ＩＤを格納する。
【００４１】
その後発注処理部２０２は、売買処理システム６０から取消完了数量、並びに取消失敗数量（すなわち指値注文を生成した（Ｓ９２に示した処理）後、取消完了の間に約定した数量）及びその約定価格をそれぞれ受信し、取消完了数量を売買注文ＤＢ２２４に格納するとともに、取消失敗数量を約定価格に対応付けて売買注文ＤＢ２２４に格納する。また発注処理部２０２は、取消完了数量、並びに取消失敗数量及びその約定価格をリカバリー注文生成部２０８に送信する。
【００４２】
リカバリー注文生成部２０８は、発注処理部２０２から受け取った情報に取消失敗数量が含まれていた場合（Ｓ９４：Ｙｅｓ）、Ｓ９２と同じ価格を注文価格とし、取消失敗数量を注文数量としたリカバリーの為の指値注文データを再び生成し（Ｓ９５）、取引所の売買処理システム６０に送信する（Ｓ９６）。このときリカバリー注文生成部２０８は、再び生成した指値注文データに注文ＩＤを付して、この注文ＩＤ及び指値注文データを売買注文ＤＢ２２４に格納する。またリカバリー注文生成部２０８は、損失ＤＢ２１０ａに再び生成した指値注文データの注文ＩＤを格納する。またリカバリー注文生成部２０８は、取消失敗数量及びその約定価格を用いて損失ＤＢ２１０ａに格納されている約定数及び平均約定価格を更新し、かつ再び送信した指値注文データの注文ＩＤを損失ＤＢ２１０ａに格納する。
【００４３】
発注処理部２０２は、現在の指値においてリカバリーの為の指値注文データが示す注文が部分的に約定した旨を示すデータ及びその数量を売買処理システム６０から受信する度に、現在までの約定数量を売買注文ＤＢ２２４に格納し、又は更新する。そして発注処理部１０は、指値注文データが示す注文が約定した旨の情報を確定損失算出部２１０に送信する。すると確定損失算出部２１０は、損失ＤＢ２１０ａが保持しているリカバリーの為の指値注文データの注文ＩＤを用いて、売買注文ＤＢ２２４が格納しているリカバリーの為の指値注文データの約定数量を読み出す。次いで損失ＤＢ２１０ａが格納している誤発注注文における平均約定価格とリカバリーの為の指値注文データが示す注文における現在の指値との差分を算出し、この差分と現在の指値における約定数量との積を算出することにより、現在の指値において確定した損失を算出する。そして既に確定していた損失に新たに確定した損失を加えることにより、現在までの確定損失を算出し、損失ＤＢ２１０ａに格納する（Ｓ９７）。また確定損失算出部２１０は、注文ＩＤを用いて、指値別の約定数量を格納し、又は更新する。
【００４４】
リカバリー注文生成部２０８は、所定時間（例えば１分）が経過すると（Ｓ９８：Ｙｅｓ）、リカバリーの為の指値注文データの注文ＩＤ（例えば００４）を損失ＤＢ２１０ａから読み出す。そしてこの注文ＩＤに対応する情報を売買注文ＤＢ２２４から読み出し、リカバリーの為の指値注文データが示す注文数量が全て約定したか否かを確認する（Ｓ９９）。指値注文が示す注文の全量約定が完了していない場合（Ｓ９９：Ｎｏ）、売買注文ＤＢ２２４が保持している情報を用いて、指値注文のうち約定していない数量すなわちリカバリーすべき数量を再度算出し（Ｓ１００：例えば図５に示す例では６５０００）、この数量を注文数量とし、かつ指値を１ティック上げた反対売買の指値注文データ（例えば図５の注文ＩＤ００５に示す売買注文データ）を生成する（Ｓ１０１）。またリカバリー注文生成部２０８は、既に発注済のリカバリーの為の指値注文の取消注文データを生成する（Ｓ１０１）。次いでリカバリー注文生成部２０８は、生成した取消注文データ及び指値注文データを売買処理システム６０に送信して発注する（Ｓ１０２）。このときリカバリー注文生成部２０８は、指値注文データに注文ＩＤ（例えば注文ＩＤ００５）を付して、この注文ＩＤ及び指値注文データを売買注文ＤＢ２２４に格納する。またリカバリー注文生成部２０８は、リカバリーの為の指値注文データの注文ＩＤを損失ＤＢ２１０ａに格納する。その後、リカバリー注文生成部２０８及び確定損失算出部２１０は、Ｓ９７〜Ｓ９９で示した処理を再び行う。
【００４５】
リカバリー注文生成部２０８及び確定損失算出部２１０は、指値注文データが示す注文数量の全てが約定する（すなわちリカバリー終了：Ｓ９９でＹｅｓ）まで上記した処理を繰り返す。
【００４６】
図１２は、損失ＤＢ２１０ａが保持しているデータの一例をテーブル形式で示す図である。本図に示す例において損失ＤＢ２１０ａは、誤発注した銘柄の銘柄コード、誤発注の注文ＩＤ（例えば注文ＩＤ００３）、誤発注において取消前に約定した株式数（例えば９００００）、平均約定価格（例えば５５８．５円）、リカバリー注文の注文ＩＤ（例えば注文ＩＤ００４，００５，００６）、指値（例えば５５８円、５５９円、及び６００円）、指値ごとの約定数量（例えば３００００、４００００、２５０００）、及び確定損失（例えば１１３５０００円）を保持している。このため、管理者等は、損失ＤＢ２１０ａを確認することにより、現在までのリカバリー状況及び確定損失を容易に認識することができる。
【００４７】
なお、上記した各処理は、例えば管理者端末１１から中止指令を受信した場合、即座に中止されても良い。
【００４８】
以上、本発明によれば、株式売買管理装置２０が誤発注の可能性がある疑誤発注注文データを抽出して管理者端末１１に表示させる。このため、誤発注を早期に検出することができ、その結果、誤発注を起こしてからリカバリー注文を行うまでの時間を短くすることができる。また管理者端末１１に対して誤発注である旨の入力が行われた場合、株式売買管理装置２０がリカバリー注文の売買注文データを生成して発注する。このため、誤発注を起こしてからリカバリー注文を行うまでの時間をさらに短くすることができ、かつリカバリー注文において誤発注を起こすことを防止できる。また複数の誤発注が同じタイミングで生じた場合においても、リカバリー注文を同じタイミングで正確に行うことができる。
【００４９】
尚、本発明は上述した実施形態に限定されるものではなく、本発明の主旨を逸脱しない範囲内で種々変更して実施することが可能である。例えば疑誤発注注文データを抽出した場合に、管理者端末１１から疑誤発注注文データの注文ＩＤを受信する前に、リカバリー注文の売買注文データを上記した方法を用いて予め生成しておき、管理者端末１１から疑誤発注注文データの注文ＩＤを受信した場合に、予め生成しておいたリカバリー注文の売買注文データを売買処理システム６０に送信しても良い。また、図７を用いて説明した処理において、Ｓ６に示した処理を省略し、疑誤発注注文を検出した場合に管理者の確認を行わずにリカバリー注文の生成及び発注を行っても良い。
【図面の簡単な説明】
【００５０】
【図１】本発明の実施形態に係る株式売買管理装置２０を有する株式売買システムの構成を説明する為の図。
【図２】証券売買管理装置２０の構成を説明する為のブロック図。
【図３】相場情報ＤＢ２２０のデータ構成の一例をテーブル形式で示す図。
【図４】発注検出条件ＤＢ２２２のデータ構成の一例をテーブル形式で示す図。
【図５】売買注文ＤＢ２２４のデータ構成の一例をテーブル形式で示す図。
【図６】（Ａ）及び（Ｂ）は、それぞれリカバリー注文生成プログラム保持部２２６が格納しているプログラムによって行われる売買注文を説明する為の図。
【図７】株式売買管理装置２０が行う処理の詳細の動作を説明する為のフローチャート。
【図８】図７のＳ２の詳細を説明する為のフローチャート。
【図９】図７のＳ４の詳細を説明する為のフローチャート。
【図１０】図７のＳ８の第１の詳細例を説明する為のフローチャート。
【図１１】図７のＳ８の第２の詳細例を説明する為のフローチャート。
【図１２】損失ＤＢ２１０ａが保持しているデータの一例をテーブル形式で示す図。
【符号の説明】
【００５１】
１０…売買担当者端末、１１…管理者端末、２０…株式売買管理装置、６０…売買処理システム、２０２…発注処理部、２０４…疑誤発注銘柄検出部、２０６…疑誤発注注文抽出部、２０８…リカバリー注文生成部、２１０…確定損失算出部、２１０ａ…損失ＤＢ、２１２…相場情報取得部、２２０…相場情報ＤＢ、２２２…誤発注検出条件ＤＢ、２２４…売買注文ＤＢ、２２６…リカバリー注文生成プログラム保持部
【図１】
2008146423.tif 000003
【図２】
2008146423.tif 000004
【図３】
2008146423.tif 000005
【図４】
2008146423.tif 000006
【図５】
2008146423.tif 000007
【図６】
2008146423.tif 000008
【図７】
2008146423.tif 000009
【図８】
2008146423.tif 000010
【図９】
2008146423.tif 000011
【図１０】
2008146423.tif 000012
【図１１】
2008146423.tif 000013
【図１２】
2008146423.tif 000014