JPWO2008139525A1 - 証拠金取引会社システム、コンピュータプログラム及び記憶媒体 - Google Patents

Abstract

証拠金取引会社システムにおける拡張性を確保し、処理性能の向上を容易に図ることを可能とする。証拠金取引会社システムは、複数の取引端末から受信した注文情報の受領処理を行う複数の処理部と、複数の処理部のそれぞれが一定期間に受領した注文情報の第１の合計値を各処理部から取得し、取得した各第１の合計値に基づいて第２の合計値を算出する算出部と、第２の合計値と閾値とを比較して、該第２の合計値が該閾値以上の場合に、各処理部に、該各処理部の第１の合計値の少なくとも１つが閾値以上となるように注文処理を行う注文部と、カバー取引銀行端末に対して、カバー注文を行うカバー注文部とを備える。

Description

本発明は、証拠金取引会社システム、コンピュータプログラム及び記憶媒体に関する。

近年、金融機関や個人投資家を対象とした債券、資金、外国為替等の金融商品取引市場では、証拠金取引と呼ばれる取引が行われている。この証拠金取引では、取引代金を丸々用意しておこなう従来の為替取引とは異なり、証拠金のみを預け入れて取引が行われる。

このような証拠金取引は、証拠金会社が顧客からの注文を受け付け取引が行われる。このとき証拠金会社は、顧客から受け付けた注文に応じて、カバー取引銀行とよばれる銀行に対してカバー注文を出している。

このカバー注文は、証拠金会社のネットポジションをフラットに維持するために行われる。例えば、証拠金会社が、顧客からドル／円で１００万ドルの買い、９０万ドルの売り注文を受けた場合、ネットポジションの（１００万−９０万＝）１０万ドルが自己のポジション（顧客から見て１０万ドル買いポジション＝証拠金会社から見て１０万ドルの売りポジション）となり、為替の変動リスクを受ける。

このリスクを無くす、又は軽減するために、カバー取引銀行に対し一定割合額（ここでは、簡単のため１０万ドル）の買い注文のカバー注文を行うことで自己のポジションをフラットに近づけ、為替の変動リスクを無くすことができる。

このような証拠金取引を実現するためのシステム構成は図８に示すようになる。図８において、証拠金取引会社システム１０００は、カバー取引銀行端末１０１０及びユーザー端末１０２０と接続されている。

証拠金取引会社システム１０００は、ユーザー端末１０２０から「売り注文」又は「買い注文」の売買注文を受け付ける。売買注文は、証拠金取引会社システム１０００の下位アプリケーション（ＡＰ）レイヤ１００３が受け付ける。下位ＡＰレイヤー１００３は、複数の下位ＡＰコンポーネント（専用の情報処理端末）で構成され、各下位ＡＰコンポーネントは、受け付けた注文情報を、業務ロジック１００２へ通知する。

業務ロジック１００２は、複数の業務ロジックＡＰコンポーネント（専用の情報処理端末）で構成され、対応する下位ＡＰコンポーネントから通知された注文情報について、コンポーネント間で同期を取る。ここで、コンポーネント間の同期とは、共通のデータベース（ＤＢ）に対して各コンポーネントが注文を受け付けるたびに書き込みに行くことにより実現される。即ち、該データベースには、全てのコンポーネントにおいて受け付けた注文の情報が一元的に管理されることとなる。これにより、証拠金取引会社システム１０００におけるポジションを決定することができる。例えば、上記の例であれば、「１０万の売りポジション」と決定できる。

注文情報の同期を取った後、業務ロジック１００２は、ポジションの情報に従って、上位ＡＰレイヤ１００１を介してカバー取引銀行端末１０１０に対し、ポジションをフラットにするためのカバー注文を行う。例えば、「１０万ドルの売りポジション」の場合には、「１０万ドルの買い注文」が行われる。

以上のようにして、従来の証拠金取引会社システム１０００では、複数のユーザー端末１０２０から受け付けた注文を合計して、自身のネットポジションをフラットにするためのカバー注文処理を行っている。

なお、特許文献１は証拠金取引システムについて開示している。
特開２００６−１８９９８２号公報

従来の証拠金取引会社システム１０００では、ユーザー端末１０２０から注文を受け付けた場合に、データベースへの書き込みを行い、該書き込みが完了した場合に、注文の受領応答を行っている。即ち、書き込みが完了しない場合には、ユーザーの注文は完了しない。当然のことながら、金融取引は一刻を争うので、注文処理の即時性は非常に重要な要素である。

一般的に、即時性を向上させる方策としては、ユーザ端末１０２０から注文を受け付ける下位ＡＰコンポーネントや業務ロジックＡＰコンポーネントの数を増加させることが考えられる。しかしながら、コンポーネント数を増加させれば、ユーザー端末１０２０がアクセスできるコンポーネント数は増えるものの、同時にデータベースへの書込を行うコンポーネント数が増加することとなる。この結果、データベースへの書込完了に長時間を要することとなり、却ってユーザー端末１０２０への応答速度が低下してしまう。また、各コンポーネントの配置拠点を地理的に分散させた場合も、距離的な要因により、データベースへの書込完了に時間を要することとなる。

このように、コンポーネント数の増加やコンポーネントの配置拠点の分散化を図っても、同期処理応答速度が却って阻害されてしまうというジレンマに陥ってしまう。

以上のように、従来の証拠金取引会社システムは同期処理による拡張性の限界のために、処理性能を向上させることが困難であった。

そこで、本発明は、証拠金取引会社システムにおける拡張性を確保し、処理性能の向上を容易に図ることを可能とすることを目的とする。

上記課題を解決するための本発明は、
複数の取引端末と、カバー取引銀行端末とにネットワークを介して接続される証拠金取引会社システムであって、
前記複数の取引端末から注文情報を受信する受信部と、
受信した注文情報の受領処理を行う複数の処理部と、
前記複数の処理部のそれぞれが一定期間に受領した注文情報の第１の合計値を各処理部から取得し、取得した各第１の合計値に基づいて第２の合計値を算出する算出部と、
前記第２の合計値と閾値とを比較して、該第２の合計値が該閾値以上の場合に、前記各処理部に、該各処理部の前記第１の合計値の少なくとも１つが前記閾値以上となるように注文処理を行う注文部と、
前記カバー取引銀行端末に対して、カバー注文を行うカバー注文部と
を備え、
前記閾値以上となった前記第１の合計値を有する処理部は前記カバー注文部に対してカバー注文実行指示を行い、
前記カバー注文部が該カバー注文実行指示に従って前記カバー注文を行い、
前記複数の処理部は、それぞれが外部記憶装置を備え、前記受信した注文情報の前記外部記憶装置への書き込み完了に基づいて前記受領処理を実行する
ことを特徴とする。

本発明によれば、証拠金取引会社システムにおける拡張性を確保し、処理性能の向上を容易に図ることができる。

発明の実施形態に対応する証拠金取引システムの構成を示す図である。 発明の実施形態に対応する証拠金取引会社システムの構成の一例を示す図である。 発明の実施形態に対応する情報処理端末のハードウェア構成の一例を示す図である。 発明の実施形態に対応するＰＭ端末において実行される処理の一例に対応するフローチャートである。 発明の実施形態に対応するＮＰＷ２０５及びＮＰＣ２０６において実行される処理の一例を示すフローチャートである。 発明の実施形態に対応するＮＰＣ２０６において実行される処理の一例を示すフローチャートである。 発明の実施形態に対応するＰＭ端末毎の情報の一例を示す図である。 発明の実施形態に対応するＰＭ端末毎の情報の一例を示す図である。 従来の証拠金取引システムの構成を示す図である。

以下、添付する図面を参照して、発明の実施形態を説明する。

図１は、発明の実施形態に対応する証拠金取引システムの一般的な構成を示しており、ここでは、取引の仲介を行う証拠金取引会社システム１０１と、証拠金取引会社システム１０１がカバー注文を発行するカバー取引銀行端末１０２と、証拠金取引会社システム１０１に対して注文を発行する証券会社等の顧客が使用する取引端末１０３（ＡからＮ）とが、インターネット等のネットワーク１０４を介して接続されている。取引端末１０３は、汎用のパーソナルコンピュータ等で構成される。

証拠金取引会社システム１０１に対して取引端末１０３から発行される注文情報は、注文対象を示す銘柄、売り買いの区別を示す売買区分、レート（年利率）または単価、注文数量（または注文金額、以下同様。）、その他の取引の条件等から構成される。これらの注文情報は、証拠金取引会社システム１０１から各取引端末１０３に提供され、各取引端末１０３のディスプレイ上に表示される。

次に、図２を参照して、証拠金取引会社システム１０１のハードウェア構成について説明する。図２は、証拠金取引会社システム１０１のハードウェア構成の一例を示す図である。証拠金取引会社システム１０１は、ルーター２０１、２１０の他、情報処理端末により構成される各種コンポーネントで構成される。

ルーター２０１は、ネットワーク１０４を介して顧客の取引端末１０３と接続するために提供される。ルータ２０１はＡＧＷ２０２とバス２１１を介して接続される。ＡＧＷ（Application Service Provider Gateway）２０２は、下位ＡＰレイヤとして機能するコンポーネントであって、顧客からの注文情報を受け付けると共に、注文情報をＰＭ２０３に送信する。また、顧客のポジションを管理する。ＡＧＷ２０２は、例えば３台の情報処理端末により構成することができる。

ＰＭ（Position Manager）２０３は、例えば３台の情報処理端末と各情報処理端末に与えられた３つのデータベース（ＤＢ）で構成されるコンポーネントである。各ＰＭ端末は、ＡＧＷ２０２から受信した注文情報を自身のデータベースに保持すると共に、自身のポジションを管理し、ポジションサマリ情報をＮＰＷ２０５に送信する。また、ポジションサマリ情報に基づいて、ＤＯＣ２０４に対してカバー注文の実行指示を自律的に行う。

ＤＯＣ（Dealing Order Controller）２０４は、例えば３台の情報処理端末で構成されるコンポーネントである。ＤＯＣ２０４は、ＰＭ２０３からのカバー注文の実行指示に従い、ＧＷ２０９を介してカバー取引銀行端末１０２に対してカバー注文を行う。なお、カバー取引銀行端末１０２は、カバー取引銀行の種類に応じて複数存在してもよく、その場合には、ＰＤ２０７から提供される各カバー取引銀行のレート情報に基づいて、どのカバー取引銀行端末１０２に対してカバー注文を行うかを決定する。

ＮＰＷ（Net Position Watcher）２０５は、例えば２台の情報処理端末で構成されるコンポーネントである。ＮＰＷ２０５は、全てのＰＭ端末よりポジションサマリ情報を受信し、システム全体としてのネットサマリ情報を生成する。生成したネットサマリ情報は、各ポジションサマリ情報と共に、ＮＰＣ２０６に送信する。

ＮＰＣ（Net Position Controller）２０６は、例えば２台の情報処理端末で構成されるコンポーネントである。ＮＰＣ２０６は、ＮＰＷ２０５より受信したネットサマリ情報と各ポジションサマリ情報に基づいて、各ＰＭ端末に対して注文処理を行い、ＰＭ端末間のポジションを調整する。

ＰＤ(Price Distributer)２０７は、カバー取引銀行から提示されているレート情報を管理する。また、ＤＯＣ２０４からの依頼に応じて、ＤＯＣ２０４に対してレート情報の提供を行う。

以上のＰＭ２０３、ＤＯＣ２０４、ＮＰＷ２０５、ＮＰＣ２０６及びＰＤ２０７は、業務ロジックＡＰレイヤとして機能することができる。

ＧＷ（Gateway）２０９は、カバー取引銀行端末１０２との通信を行うためのゲートウェイ（上位ＡＰレイヤ）として機能するコンポーネントであって、例えば２台の情報処理端末で構成される。ルーター２１０は、ネットワーク１０４を介してカバー取引銀行端末１０２との接続をＧＷ２０９に提供するために機能する。バス２１１、２１２、２１３及び２１４は各ルータ、各コンポーネント間の相互接続を行う。

次に、図３を参照して、図２の各コンポーネントを構成する情報処理端末のハードウェア構成について説明する。

図３において、ＣＰＵ３０１で、ＲＡＭ（ランダムアクセスメモリ）３０２やＲＯＭ（リードオンリメモリ）３０５に格納されたプログラムやデータ等を用いて情報処理端末の制御を行うと共に、各コンポーネントとしての機能を達成するための処理を行う。ＲＡＭ３０２で、内部記憶装置３０７内に格納された処理プログラムや外部記憶装置３０８に格納されている情報を読み込むエリアを備えると共に、ＣＰＵ３０１が各種の処理を実行する際に用いるワークエリアも備える。

入力部３０３は情報処理端末の管理者から入力を受付ける入力手段であって、キーボードやマウスなどで構成される。通信Ｉ／Ｆ（インタフェース）３０４は、バス２１１等に接続するためのＩ／Ｆとして機能する。ＲＯＭ３０５は、情報処理端末全体の制御を行うプログラム（例えばブートプログラム等）等を格納する。表示部３０６は表示画面としての表示部で、ＣＲＴや液晶画面により構成されている。

３０７は内部記憶装置で、主としてハードディスクで構成され、情報処理端末が属するコンポーネントの機能を達成するための処理を実行するためのプログラムや各種アプリケーションデータを格納する。ここに格納されているデータは必要に応じてＲＡＭ３０２に読み出される。

外部記憶装置３０８は、情報処理端末がＰＭ２０３のＰＭ端末として機能する場合に利用されるデータベースであり、ＡＧＷ２０２から受信した注文情報が随時格納される。バス３０９は上述の各ブロックの相互接続を提供する。

次に、証拠金取引会社システム１０１において実行される各種処理について説明する。

まず、図４は、証拠金取引会社システム１０１を構成するコンポーネントの１つであるＰＭ２０３の各ＰＭ端末において実行される処理の流れを示すフローチャートである。図４のフローチャートに対応する処理は、ＰＭ端末内の内部記憶装置３０７に格納されている対応処理プログラムをＲＡＭ３０２に読み出し、ＣＰＵ３０１が実行することによって実現される。

図４において、ステップＳ４０１では、ＣＰＵ３０１内のソフトウェアタイマーをリセットし、リスタートする。次に、ステップＳ４０２では、ＡＧＷ２０２から注文情報を受信したか否かを判定する。もし、受信した場合には（ステップＳ４０２において「ＹＥＳ」）、ステップＳ４０３へ移行する。一方、受信しない場合には（ステップＳ４０２において「ＮＯ」）、ステップＳ４０９に移行する。ステップＳ４０９では、所定時間が経過したか否かを、タイマーの計時値に基づいて判定する。この所定時間は、例えば１秒とすることができる。もし、所定時間が経過した場合には（ステップＳ４０９において「ＹＥＳ」）、ステップＳ４０５に移行する。一方、所定時間が経過しない場合には（ステップＳ４０９において「ＮＯ」）、ステップＳ４０２に戻って、注文情報の受信処理を継続する。

次に、ステップＳ４０３では、受信した注文情報をデータベースとして利用する外部記憶装置３０８に書き込む。データベース３０８への書込を完了したら、ステップＳ４０４に移行してＡＧＷ２０２へ注文受領通知を送信する。その後、ステップＳ４０２に戻って注文情報の受信処理を継続する。ＡＧＷ２０２は、受信した注文受領通知を、注文情報の送信元顧客の取引端末１０３に対し転送する。

なお、ステップＳ４０３及びステップＳ４０４における処理により、各ＰＭ端末は自身のみが利用するデータベースへ書込を行い注文受領通知を発行する。このように即座に注文の受領処理ができるので、注文情報を受け付ける際の高い応答速度を確保することができる。その一方で、各ＰＭ端末が受領した注文情報は各データベース３０８に格納されており、システム全体としてのポジションの把握が困難となっている。これを解消するためにステップＳ４０５以降の処理を行う。

ステップＳ４０５では、データベース３０８に格納した注文情報に基づいて、ポジションサマリ情報を生成する。このポジションサマリ情報とは、その時点で受け付けている注文情報の合計値である。本実施形態では、「買い注文」における注文数量（金額）を正の値として取り扱い、「売り注文」における注文数量（金額）を負の数として取り扱い、これらの注文数量の和に基づいてポジションサマリ情報を算出する。

例えば、１秒間に、５万ドルの買い注文（＋５万）、１０万ドルの買い注文（＋１０万）、３万ドルの売り注文（−３万）を受け付けた場合には、ポジションサマリ情報として５万＋１０万−３万＝１２万となる。このようにして得られたポジションサマリ情報は、ステップＳ４０６で、ＮＰＷ２０５へ送信する。

続くステップＳ４０７では、ポジションサマリ情報の値Ｏｔｏｔａｌと、カバー注文を行うか否かを決定するための閾値Ｏｔｈとを比較する。この閾値Ｏｔｈは、証拠金取引システム１０１を運営する証拠金取引会社が取れるリスクに応じて、例えば、５０万ドルといったように設定できる。

もし、Ｏｔｏｔａｌ≧Ｏｔｈの場合には（ステップＳ４０７において「ＹＥＳ」）、ステップＳ４０８へ移行する。一方、Ｏｔｏｔａｌ＜Ｏｔｈの場合には（ステップＳ４０７において「ＮＯ」）、ステップＳ４０１へ移行する。ステップＳ４０８では、ポジションサマリ情報の値Ｏｔｏｔａｌの大きさに基づいて、ＤＯＣ２０４へカバー注文実行指示を行う。ＤＯＣ２０４では、このカバー注文実行指示に基づいてカバー注文を行う。

カバー注文の例を説明する。例えば、ポジションサマリ情報の値が＋５０万ドルに達した場合を考える。この場合ポジションサマリ情報の符号が正であるので、買い注文が先行していることとなる。そこで、カバー注文では買い注文に対する反対注文として、売り注文が行われる。その際、５０万ドルと一致する額の注文を行ってもよいし、一定の割合に相当する額（例えば、６割として、３０万ドル）の売り注文を行ってもよい。もし、３０万ドルの売り注文を行えば、ポジションサマリ情報の値を２０万ドルまで下げて、よりフラットに近づけることができる。

次に、図５を参照して、ＮＰＷ２０５及びＮＰＣ２０６において実行される処理について説明する。図５は、証拠金取引会社システム１０１を構成するコンポーネントであるＮＰＷ２０５及びＮＰＣ２０６において実行される処理の流れを示すフローチャートである。図５のフローチャートに対応する処理は、各コンポーネント内の情報処理端末の内部記憶装置３０７に格納されている対応処理プログラムをＲＡＭ３０２に読み出し、ＣＰＵ３０１が実行することによって実現される。

まず、ステップＳ５０１において、ＮＰＷ２０５は、ＰＭ端末からポジションサマリ情報を受信する。次に、ステップＳ５０２では、ＮＰＷ２０５は全てのＰＭ端末からポジションサマリ情報を受信したか否かを判定する。もし、全てのＰＭ端末から受信した場合には（ステップＳ５０２において「ＹＥＳ」）、ステップＳ５０３に移行する。

ステップＳ５０３では、ＮＰＷ２０５は、受信したポジションサマリ情報を合計して、システムのネットポジション情報Ｎｐを計算する。このネットポジション情報Ｎｐは、ポジションサマリ情報を足し合わせることにより計算できる。例えば、３台のＰＭ端末がＰＭ−１、ＰＭ−２、ＰＭ−３として、ＰＭ−１から＋１０万ドル、ＰＭ−２から＋１０万ドル、ＰＭ−３から＋４０万ドルが通知された場合には、ポジションサマリ情報として＋６０万ドルと計算することができる。

次に、ステップＳ５０４では、ＮＰＷ２０５は、ネットポジション情報Ｎｐと受信したポジションサマリ情報をＮＰＣ２０６に送信する。ステップＳ５０５では、ＮＰＣ２０６が、受信したネットポジション情報Ｎｐと、所定の閾値Ｐｔｈとを比較する。この閾値Ｐｔｈは、上述のカバー注文を行うか否かを決定するための閾値Ｏｔｈと同一の値とすることができる。

もし、Ｎｐ≧Ｐｔｈの場合には（ステップＳ５０５において「ＹＥＳ」）、ステップＳ５０６へ移行する。一方、Ｎｐ＜Ｐｔｈの場合には（ステップＳ５０５において「ＮＯ」）、ステップＳ５０１に戻って、ＮＰＷ２０５がポジションサマリ情報の受信を行う。

上述のポジションサマリ情報が＋６０万ドルの例では、閾値Ｐｔｈを５０万ドルとすれば６０万ドル＞５０万ドルであるので、閾値Ｐｔｈを超えることとなり、ステップＳ５０６に移行することとなる。

ステップＳ５０６では、ＮＰＣ２０６は、各ＰＭ端末におけるポジションサマリに基づいて、各ＰＭ端末への注文処理を行う。この注文処理のないようについては、図６を参照してより詳細に説明する。注文処理が終了すると、ステップＳ５０１に戻って、ＮＰＷ２０５がポジションサマリ情報の受信を行う。

次に、図６を参照して、ＮＰＣ２０６において実行されるＰＭ２０３への注文処理について説明する。図６は、証拠金取引会社システム１０１を構成するコンポーネントであるＮＰＣ２０６において実行される処理の流れを示すフローチャートである。図６のフローチャートに対応する処理は、コンポーネント内の情報処理端末の内部記憶装置３０７に格納されている対応処理プログラムをＲＡＭ３０２に読み出し、ＣＰＵ３０１が実行することによって実現される。

まず、ステップＳ６０１では、ポジションサマリ情報が最大のＰＭ端末を決定する。この場合、ネットポジション情報の値は、絶対値において扱う。即ち、＋５０万ドルと、−７０万ドルであれば、−７０万ドルの方が大きいこととなる。以下、図７ａの例を参照して説明を行う。

図７Ａは、ＰＭ−１からＰＭ−３までの各ＰＭ端末から受信したポジションサマリ情報と、ネットサマリ情報と、閾値Ｐｔｈの一例を示す。この場合、ＰＭ−１とＰＭ−２におけるポジションサマリ情報は、＋１０万ドルとなっている。一方、ＰＭ−３のポジションサマリ情報は、＋４０万ドルとなっている。従って、ネットサマリ情報は、合計して＋６０万ドルである。また、Ｐｔｈは５０万ドルであるので、ネットサマリ情報は、閾値Ｐｔｈを超えている。

この状況で、ステップＳ６０１では、最大値を有するＰＭ端末をＰＭ−３と決定することができる。

次に、ステップＳ６０２では、残りのＰＭ端末に対して各端末のポジションサマリ情報を相殺するための反対注文を行う。即ち、図７ａの例では、ＰＭ−１とＰＭ−２に対して、１０万ドルずつの売り注文を行う。なお、反対注文は、各端末のポジションサマリ情報を完全に相殺するものでなくてもよく、ステップＳ６０３における処理対象のＰＭ端末のポジションサマリ情報が閾値を超える数量（金額）で有ればよい。

続くステップＳ６０３では、ステップＳ６０２で行った反対注文の更に反対注文を、ステップＳ６０２における注文数を相殺する注文数だけ、ステップＳ６０１で決定されたポジションサマリ情報が最大のＰＭ端末に対して行う。図７Ａの例では、２０万ドルの買い注文を、ＰＭ−３に対して行う。

なお、ステップＳ６０２及びステップＳ６０３における注文処理に基づく注文情報は、ステップＳ４０２において各ＰＭ端末受信する注文情報として扱われる。

この結果、図７Ｂに示すように、各端末におけるポジションサマリ情報が変更される。即ち、システム全体として、注文情報が単一の端末に集約された形となる。そして、注文情報が集約された形となった端末であるＰＭ−３は、ステップＳ４０７及びステップＳ４０８の処理を経て、ＤＯＣ２０４に対してカバー注文実行指示を通知することができる。

このようにして、ＮＰＷ２０５及びＮＰＣ２０６を利用することにより、１つのＰＭ端末に注文情報を集約させることで、随時カバー注文を自動的に行うことが可能となる。

なお、図７Ａの例では、各端末におけるポジションサマリ情報が全て同一符号の場合を記載した。しかし、当然に端末毎に売りが先行したり（負に振れたり）、買いが先行したり（正に振れたり）する場合がある。そのような場合には、システム全体としてのリスクを軽減するために、所謂付け合い注文を行って、各端末のポジションのバラツキを吸収することができる。

例えば、ＰＭ−１のポジションサマリ情報が−１０万ドル、ＰＭ−２のポジションサマリ情報が−２０万ドル、ＰＭ−３のポジションサマリ情報が４０万ドルの場合、売り注文の合計が３０万ドル、買い注文の合計が４０万ドルとなる。この場合、売りについて３０万ドル、買いについて４０万ドルで、計７０万ドルのリスクを背負うこととなる。その一方で、ネットポジションとして見た場合には、＋１０万ドルしか買いが先行していない。

このような状況では、リスクを軽減し、また収益を拡大するために同額の反対注文を一部のＰＭ端末に行い、全体としてのポジションをフラットにする。即ち、ＰＭ−１とＰＭ−２に対して、それぞれ１０万ドル、２０万ドルの付け合わせの買い注文を行い、ＰＭ−３に対して３０万ドルの付け合わせの売り注文を行う。

このような付け合わせ注文により、ＰＭ−１とＰＭ−２のポジションサマリ情報は０となり、ＰＭ−３のポジションサマリ情報は１０万ドルとなり、ネットポジション情報とシステムが背負うリスクとが一致する。

なお、各端末におけるポジションサマリ情報の符号が一致しない場合は、上述の付け合わせ注文を行った後に、図６の処理をしてもよい。

以上の本実施形態に対応する証拠金取引会社システムの構成によれば、ＰＭ２０３を構成する各ＰＭ端末は、各端末のデータベースに書き込みを完了させるだけで受領応答が可能である。よって、ＰＭ端末の数を増加させても、地理的に分散して配置しても、従来のように受領応答速度の低下を招くことはない。即ち、本発明によればシステムの拡張性が得られる。

また、システム全体としてのポジションは、ＮＰＷ２０５やＮＰＣ２０６により集中管理するので、共通のデータベースにリアルタイムに書き込みを行わないことのリスクは担保することができる。また、ＮＰＷ２０５やＮＰＣ２０６による管理は受領応答ほどのリアルタイム性は要求されないので、システムの負荷も少なくて済む。

ここで、以上の本実施形態に対応する証拠金取引会社システムの構成に基づく効果を、従来構成と比較して更に具体的に説明する。

例えば、図８に説明した構成において、業務ロジック１００２を構成する２台の端末（ＡＰ１、ＡＰ２）のそれぞれに対し、１秒間に１０件の注文情報を受け付けた場合を考える。この場合、ＡＰ１とＡＰ２とは、ＤＢに対して１件ごとに書き込みを行うため、ＤＢには１秒間で２０回の書き込み処理が行われることとなる。もし、業務ロジック１００２の構成端末を更に増加すれば、増加数×１０だけＤＢへの書き込み処理回数が増加することとなる。このように、注文情報の受け付け件数（取引件数）とＤＢへの書き込み処理件数とは比例することとなる。

これに対し、図２に示すような本実施形態に対応するシステム構成では、注文情報の受領処理を行うＰＭ端末のＰＭ−１からＰＭ−３までに１秒間に１０件の注文情報が入力されたとしても、ＰＭ端末がＮＰＷ２０５に送信するのは、１秒間に１回のポジションサマリ情報のみである。このポジションサマリ情報の送信回数は、ＰＭ端末の注文情報の処理件数に関わらず常に一定である。従って、ＮＰＷ２０５は、ＰＭ端末と同数のポジションサマリ情報を処理するだけでよく、ＰＭ端末が仮に追加された場合であっても、処理件数は追加台数分に比例するだけであって、取引件数の増加は無関係である。

このように、従来構成では、取引件数の増加及び業務ロジック端末の増加に伴って、システム全体のポジションの情報を取得するための処理の負荷が比例的に増加したため、システムの拡張性が阻害されたり、また、注文処理速度が阻害されたりした。これに対して本実施形態の構成では、システム全体のポジションの情報を取得するための処理に対する取引件数の増加は無視できる程度であり、ＰＭ端末の増加のみを考慮すればよい。よって、システムの拡張性を持たせることが可能となる。また、注文の受領処理はＰＭ端末内で完結するので、応答速度が阻害されることはない。仮に台数が足りなくなれば、拡張性を生かして増設すればよい。

［他の実施形態］
以上の処理（例えば上記実施形態に示したフローチャートに従った処理）をプログラムとしてＣＤ−Ｒ、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、ＭＯ等のコンピュータで読み取り可能な記憶媒体に記憶させ、この記憶媒体に記憶されているプログラムをコンピュータに読み込ませる（インストール、もしくはコピーさせる）ことで、このコンピュータは以上の処理を行うことができる。よって、当該コンピュータプログラムや当該記憶媒体も本発明の範疇にあることは明白である。

複数の取引端末と、カバー取引銀行端末とにネットワークを介して接続される証拠金取引会社システムであって、
前記複数の取引端末から注文情報を受信する受信装置と、
複数の処理装置であって、各処理装置が、
外部記憶装置と、
前記受信した注文情報を前記外部記憶装置へ書き込む書込手段と、
前記外部記憶装置への書込の完了に基づいて注文受領通知を前記受信装置に送信する第１の送信手段と、
前記外部記憶装置に記憶されている前記注文情報の第１の合計値を一定期間毎に算出する算出手段と、
を備える複数の処理装置と、
前記複数の処理装置のそれぞれが算出した前記第１の合計値を各処理装置から取得し、取得した各第１の合計値に基づいて第２の合計値を算出する算出装置と、
注文装置であって、
前記算出装置で算出された前記第２の合計値と閾値とを比較する比較手段と、
前記比較手段による比較の結果、該第２の合計値が該閾値以上の場合に、前記複数の処理装置のうち前記第１の合計値が最大となる第１の処理装置を決定する決定手段と、
前記第１の処理装置以外の他の処理装置の前記第１の合計値を相殺する第１の注文情報と、該第１の注文情報を相殺する第２の注文情報とを生成する生成手段と、
前記生成手段が生成した前記第１の注文情報を前記他の処理装置に送信し、前記第２の注文情報を前記第１の処理装置に送信する第２の送信手段と
を備える注文装置と、
前記カバー取引銀行端末に対して、カバー注文を行うカバー注文装置と
を備え、
前記受信装置は、前記処理装置から受信した前記注文受領通知を、該注文に対応する取引端末へ送信し、
前記処理装置の前記第１の送信手段は、前記第１の合計値を前記閾値と比較し、前記第１の合計値が前記閾値以上の場合に、前記カバー注文装置に対してカバー注文実行指示を送信し、
前記カバー注文装置が該カバー注文実行指示に従って、所定金額のカバー注文情報を前記カバー取引銀行端末に送信する、
ことを特徴とする。

Claims (5)

1. 複数の取引端末と、カバー取引銀行端末とにネットワークを介して接続される証拠金取引会社システムであって、
   前記複数の取引端末から注文情報を受信する受信部と、
   受信した注文情報の受領処理を行う複数の処理部と、
   前記複数の処理部のそれぞれが一定期間に受領した注文情報の第１の合計値を各処理部から取得し、取得した各第１の合計値に基づいて第２の合計値を算出する算出部と、
   前記第２の合計値と閾値とを比較して、該第２の合計値が該閾値以上の場合に、前記各処理部に、該各処理部の前記第１の合計値の少なくとも１つが前記閾値以上となるように注文処理を行う注文部と、
   前記カバー取引銀行端末に対して、カバー注文を行うカバー注文部と
   を備え、
   前記閾値以上となった前記第１の合計値を有する処理部は前記カバー注文部に対してカバー注文実行指示を行い、
   前記カバー注文部が該カバー注文実行指示に従って前記カバー注文を行い、
   前記複数の処理部は、それぞれが外部記憶装置を備え、前記受信した注文情報の前記外部記憶装置への書き込み完了に基づいて前記受領処理を実行する
   ことを特徴とする証拠金取引会社システム。
2. 前記注文部は、
   前記複数の処理部のうち前記第１の合計値が最大となる第１の処理部を決定し、
   前記第１の処理部以外の他の処理部の前記第１の合計値を相殺する第１の注文を該他の処理部に対して行い、
   前記第１の注文を相殺する第２の注文を前記第１の処理部に対して行う
   ことにより、前記第１の端末の第１の合計値を前記閾値以上とすることを特徴とする請求項１に記載の証拠金取引会社システム。
3. 前記注文情報には、買い注文の情報と売り注文の情報とが含まれ、
   前記第１の合計値は、前記買い注文の数量に正の符号を与え、売り注文の数量に負の符号を与えた場合の、前記各処理部における注文数量の和に基づいて算出されることを特徴とする請求項１又は２に記載の証拠金取引会社システム。
4. コンピュータを請求項１乃至３のいずれかに記載の証拠金取引会社システムとして機能させるためのコンピュータプログラム。
5. 請求項４に記載のコンピュータプログラムを記憶した、コンピュータで読み取り可能な記憶媒体。

Images