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

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

Info

Publication number
JP4171065B1
JP4171065B1 JP2008113224A JP2008113224A JP4171065B1 JP 4171065 B1 JP4171065 B1 JP 4171065B1 JP 2008113224 A JP2008113224 A JP 2008113224A JP 2008113224 A JP2008113224 A JP 2008113224A JP 4171065 B1 JP4171065 B1 JP 4171065B1
Authority
JP
Japan
Prior art keywords
order
cover
total value
processing
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008113224A
Other languages
English (en)
Other versions
JP2008276771A (ja
Inventor
伸一郎 浦島
Original Assignee
セントラル短資オンライントレード株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/JP2007/059214 external-priority patent/WO2008139525A1/ja
Application filed by セントラル短資オンライントレード株式会社 filed Critical セントラル短資オンライントレード株式会社
Priority to JP2008113224A priority Critical patent/JP4171065B1/ja
Application granted granted Critical
Publication of JP4171065B1 publication Critical patent/JP4171065B1/ja
Publication of JP2008276771A publication Critical patent/JP2008276771A/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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

Description

本発明は、証拠金取引会社システム、コンピュータプログラム及び記憶媒体に関する。
近年、金融機関や個人投資家を対象とした債券、資金、外国為替等の金融商品取引市場では、証拠金取引と呼ばれる取引が行われている。この証拠金取引では、取引代金を丸々用意しておこなう従来の為替取引とは異なり、証拠金のみを預け入れて取引が行われる。
このような証拠金取引は、証拠金会社が顧客からの注文を受け付け取引が行われる。このとき証拠金会社は、顧客から受け付けた注文に応じて、カバー取引銀行とよばれる銀行に対してカバー注文を出している。
このカバー注文は、証拠金会社のネットポジションをフラットに維持するために行われる。例えば、証拠金会社が、顧客からドル/円で100万ドルの買い、90万ドルの売り注文を受けた場合、ネットポジションの(100万−90万=)10万ドルが自己のポジション(顧客から見て10万ドル買いポジション=証拠金会社から見て10万ドルの売りポジション)となり、為替の変動リスクを受ける。
このリスクを無くす、又は軽減するために、カバー取引銀行に対し一定割合額(ここでは、簡単のため10万ドル)の買い注文のカバー注文を行うことで自己のポジションをフラットに近づけ、為替の変動リスクを無くすことができる。
このような証拠金取引を実現するためのシステム構成は図8に示すようになる。図8において、証拠金取引会社システム1000は、カバー取引銀行端末1010及びユーザー端末1020と接続されている。
証拠金取引会社システム1000は、ユーザー端末1020から「売り注文」又は「買い注文」の売買注文を受け付ける。売買注文は、証拠金取引会社システム1000の下位アプリケーション(AP)レイヤ1003が受け付ける。下位APレイヤー1003は、複数の下位APコンポーネント(専用の情報処理端末)で構成され、各下位APコンポーネントは、受け付けた注文情報を、業務ロジック1002へ通知する。
業務ロジック1002は、複数の業務ロジックAPコンポーネント(専用の情報処理端末)で構成され、対応する下位APコンポーネントから通知された注文情報について、コンポーネント間で同期を取る。ここで、コンポーネント間の同期とは、共通のデータベース(DB)に対して各コンポーネントが注文を受け付けるたびに書き込みに行くことにより実現される。即ち、該データベースには、全てのコンポーネントにおいて受け付けた注文の情報が一元的に管理されることとなる。これにより、証拠金取引会社システム1000におけるポジションを決定することができる。例えば、上記の例であれば、「10万の売りポジション」と決定できる。
注文情報の同期を取った後、業務ロジック1002は、ポジションの情報に従って、上位APレイヤ1001を介してカバー取引銀行端末1010に対し、ポジションをフラットにするためのカバー注文を行う。例えば、「10万ドルの売りポジション」の場合には、「10万ドルの買い注文」が行われる。
以上のようにして、従来の証拠金取引会社システム1000では、複数のユーザー端末1020から受け付けた注文を合計して、自身のネットポジションをフラットにするためのカバー注文処理を行っている。
なお、特許文献1は証拠金取引システムについて開示している。
特開2006−189982号公報
従来の証拠金取引会社システム1000では、ユーザー端末1020から注文を受け付けた場合に、データベースへの書き込みを行い、該書き込みが完了した場合に、注文の受領応答を行っている。即ち、書き込みが完了しない場合には、ユーザーの注文は完了しない。当然のことながら、金融取引は一刻を争うので、注文処理の即時性は非常に重要な要素である。
一般的に、即時性を向上させる方策としては、ユーザ端末1020から注文を受け付ける下位APコンポーネントや業務ロジックAPコンポーネントの数を増加させることが考えられる。しかしながら、コンポーネント数を増加させれば、ユーザー端末1020がアクセスできるコンポーネント数は増えるものの、同時にデータベースへの書込を行うコンポーネント数が増加することとなる。この結果、データベースへの書込完了に長時間を要することとなり、却ってユーザー端末1020への応答速度が低下してしまう。また、各コンポーネントの配置拠点を地理的に分散させた場合も、距離的な要因により、データベースへの書込完了に時間を要することとなる。
このように、コンポーネント数の増加やコンポーネントの配置拠点の分散化を図っても、同期処理応答速度が却って阻害されてしまうというジレンマに陥ってしまう。
以上のように、従来の証拠金取引会社システムは同期処理による拡張性の限界のために、処理性能を向上させることが困難であった。
そこで、本発明は、証拠金取引会社システムにおける拡張性を確保し、処理性能の向上を容易に図ることを可能とすることを目的とする。
上記課題を解決するためのある側面に対応する本発明は、
複数の取引端末と、カバー取引銀行端末とにネットワークを介して接続される証拠金取引会社システムであって、
前記複数の取引端末から注文情報を受信する受信装置と、
複数の処理装置であって、各処理装置が、
外部記憶装置と、
前記受信した注文情報を前記外部記憶装置へ書き込む書込手段と、
前記外部記憶装置への書込の完了に基づいて注文受領通知を前記受信装置に送信する第1の送信手段と、
前記外部記憶装置に記憶されている前記注文情報の第1の合計値を一定期間毎に算出する算出手段と、
を備える複数の処理装置と、
前記複数の処理装置のそれぞれが算出した前記第1の合計値を各処理装置から取得し、取得した各第1の合計値に基づいて第2の合計値を算出する算出装置と、
注文装置であって、
前記算出装置で算出された前記第2の合計値と閾値とを比較する比較手段と、
前記比較手段による比較の結果、該第2の合計値が該閾値以上の場合に、前記複数の処理装置のうちいずれかの第1の処理装置を決定する決定手段と、
前記第1の処理装置以外の他の処理装置の前記第1の合計値を相殺する第1の注文情報と、該第1の注文情報を相殺する第2の注文情報とを生成する生成手段と、
前記生成手段が生成した前記第1の注文情報を前記他の処理装置に送信し、前記第2の注文情報を前記第1の処理装置に送信する第2の送信手段と
を備える注文装置と、
前記カバー取引銀行端末に対して、カバー注文を行うカバー注文装置と
を備え、
前記受信装置は、前記処理装置から受信した前記注文受領通知を、該注文に対応する取引端末へ送信し、
前記処理装置の前記第1の送信手段は、前記第1の合計値を前記閾値と比較し、前記第1の合計値が前記閾値以上の場合に、前記カバー注文装置に対してカバー注文実行指示を送信し、
前記カバー注文装置が該カバー注文実行指示に従って、所定金額のカバー注文情報を前記カバー取引銀行端末に送信する、
ことを特徴とする。
上記課題を解決するための他の側面に対応する本発明は、
複数の取引端末と、カバー取引銀行端末とにネットワークを介して接続される証拠金取引会社システムであって、
前記複数の取引端末から注文情報を受信する受信装置と、
複数の処理装置であって、各処理装置が、
外部記憶装置と、
前記受信した注文情報を前記外部記憶装置へ書き込む書込手段と、
前記外部記憶装置への書込の完了に基づいて注文受領通知を前記受信装 置に送信する第1の送信手段と、
前記外部記憶装置に記憶されている前記注文情報の第1の合計値を一定期間毎に算出する算出手段と、
を備える複数の処理装置と、
前記複数の処理装置のそれぞれが算出した前記第1の合計値を各処理装置から取得し、取得した各第1の合計値に基づいて第2の合計値を算出する算出装置と、
注文装置であって、
前記算出装置で算出された前記第2の合計値と閾値とを比較する比較手段と、
前記比較手段による比較の結果、該第2の合計値が該閾値以上の場合に、前記カバー注文実行指示を行う、カバー注文実行指示手段と
を備える注文装置と、
前記カバー注文実行指示に応じて、前記カバー取引銀行端末に対してカバー注文を行うカバー注文装置と
を備え、
前記注文装置は、前記複数の処理装置のうちいずれか1つの第1の処理装置の前記第1の合計値が前記カバー注文後の前記第2の合計値と一致し、前記第1の処理装置以外の他の処理装置の前記第1の合計値が相殺されるように、前記各処理装置に対して注文処理を行う注文手段を更に備える
ことを特徴とする。
本発明によれば、証拠金取引会社システムにおける拡張性を確保し、処理性能の向上を容易に図ることができる。
以下、添付する図面を参照して、発明の実施形態を説明する。
図1は、発明の実施形態に対応する証拠金取引システムの一般的な構成を示しており、ここでは、取引の仲介を行う証拠金取引会社システム101と、証拠金取引会社システム101がカバー注文を発行するカバー取引銀行端末102と、証拠金取引会社システム101に対して注文を発行する証券会社等の顧客が使用する取引端末103(AからN)とが、インターネット等のネットワーク104を介して接続されている。取引端末103は、汎用のパーソナルコンピュータ等で構成される。
証拠金取引会社システム101に対して取引端末103から発行される注文情報は、注文対象を示す銘柄、売り買いの区別を示す売買区分、レート(年利率)または単価、注文数量(または注文金額、以下同様。)、その他の取引の条件等から構成される。これらの注文情報は、証拠金取引会社システム101から各取引端末103に提供され、各取引端末103のディスプレイ上に表示される。
次に、図2を参照して、証拠金取引会社システム101のハードウェア構成について説明する。図2は、証拠金取引会社システム101のハードウェア構成の一例を示す図である。証拠金取引会社システム101は、ルーター201、210の他、情報処理端末により構成される各種コンポーネントで構成される。
ルーター201は、ネットワーク104を介して顧客の取引端末103と接続するために提供される。ルータ201はAGW202とバス211を介して接続される。AGW(Application Service Provider Gateway)202は、下位APレイヤとして機能するコンポーネントであって、顧客からの注文情報を受け付けると共に、注文情報をPM203に送信する。また、顧客のポジションを管理する。AGW202は、例えば3台の情報処理端末により構成することができる。
PM(Position Manager)203は、例えば3台の情報処理端末と各情報処理端末に与えられた3つのデータベース(DB)で構成されるコンポーネントである。各PM端末は、AGW202から受信した注文情報を自身のデータベースに保持すると共に、自身のポジションを管理し、ポジションサマリ情報をNPW205に送信する。また、ポジションサマリ情報に基づいて、DOC204に対してカバー注文の実行指示を自律的に行う。
DOC(Dealing Order Controller)204は、例えば3台の情報処理端末で構成されるコンポーネントである。DOC204は、PM203からのカバー注文の実行指示に従い、GW209を介してカバー取引銀行端末102に対してカバー注文を行う。なお、カバー取引銀行端末102は、カバー取引銀行の種類に応じて複数存在してもよく、その場合には、PD207から提供される各カバー取引銀行のレート情報に基づいて、どのカバー取引銀行端末102に対してカバー注文を行うかを決定する。
NPW(Net Position Watcher)205は、例えば2台の情報処理端末で構成されるコンポーネントである。NPW205は、全てのPM端末よりポジションサマリ情報を受信し、システム全体としてのネットサマリ情報を生成する。生成したネットサマリ情報は、各ポジションサマリ情報と共に、NPC206に送信する。
NPC(Net Position Controller)206は、例えば2台の情報処理端末で構成されるコンポーネントである。NPC206は、NPW205より受信したネットサマリ情報と各ポジションサマリ情報に基づいて、各PM端末に対して注文処理を行い、PM端末間のポジションを調整する。
PD(Price Distributer)207は、カバー取引銀行から提示されているレート情報を管理する。また、DOC204からの依頼に応じて、DOC204に対してレート情報の提供を行う。
以上のPM203、DOC204、NPW205、NPC206及びPD207は、業務ロジックAPレイヤとして機能することができる。
GW(Gateway)209は、カバー取引銀行端末102との通信を行うためのゲートウェイ(上位APレイヤ)として機能するコンポーネントであって、例えば2台の情報処理端末で構成される。ルーター210は、ネットワーク104を介してカバー取引銀行端末102との接続をGW209に提供するために機能する。バス211、212、213及び214は各ルータ、各コンポーネント間の相互接続を行う。
次に、図3を参照して、図2の各コンポーネントを構成する情報処理端末のハードウェア構成について説明する。
図3において、CPU301で、RAM(ランダムアクセスメモリ)302やROM(リードオンリメモリ)305に格納されたプログラムやデータ等を用いて情報処理端末の制御を行うと共に、各コンポーネントとしての機能を達成するための処理を行う。RAM302で、内部記憶装置307内に格納された処理プログラムや外部記憶装置308に格納されている情報を読み込むエリアを備えると共に、CPU301が各種の処理を実行する際に用いるワークエリアも備える。
入力部303は情報処理端末の管理者から入力を受付ける入力手段であって、キーボードやマウスなどで構成される。通信I/F(インタフェース)304は、バス211等に接続するためのI/Fとして機能する。ROM305は、情報処理端末全体の制御を行うプログラム(例えばブートプログラム等)等を格納する。表示部306は表示画面としての表示部で、CRTや液晶画面により構成されている。
307は内部記憶装置で、主としてハードディスクで構成され、情報処理端末が属するコンポーネントの機能を達成するための処理を実行するためのプログラムや各種アプリケーションデータを格納する。ここに格納されているデータは必要に応じてRAM302に読み出される。
外部記憶装置308は、情報処理端末がPM203のPM端末として機能する場合に利用されるデータベースであり、AGW202から受信した注文情報が随時格納される。バス309は上述の各ブロックの相互接続を提供する。
次に、証拠金取引会社システム101において実行される各種処理について説明する。
まず、図4は、証拠金取引会社システム101を構成するコンポーネントの1つであるPM203の各PM端末において実行される処理の流れを示すフローチャートである。図4のフローチャートに対応する処理は、PM端末内の内部記憶装置307に格納されている対応処理プログラムをRAM302に読み出し、CPU301が実行することによって実現される。
図4において、ステップS401では、CPU301内のソフトウェアタイマーをリセットし、リスタートする。次に、ステップS402では、注文情報を受信したか否かを判定する。もし、受信した場合には(ステップS402において「YES」)、ステップS403へ移行する。一方、受信しない場合には(ステップS402において「NO」)、ステップS409に移行する。ステップS409では、所定時間が経過したか否かを、タイマーの計時値に基づいて判定する。この所定時間は、例えば1秒とすることができる。もし、所定時間が経過した場合には(ステップS409において「YES」)、ステップS405に移行する。一方、所定時間が経過しない場合には(ステップS409において「NO」)、ステップS402に戻って、注文情報の受信処理を継続する。
次に、ステップS403では、受信した注文情報をデータベースとして利用する外部記憶装置308に書き込む。データベース308への書込を完了したら、ステップS404に移行してAGW202へ注文受領通知を送信する。その後、ステップS402に戻って注文情報の受信処理を継続する。AGW202は、受信した注文受領通知を、注文情報の送信元顧客の取引端末103に対し転送する。
なお、ステップS403及びステップS404における処理により、各PM端末は自身のみが利用するデータベースへ書込を行い注文受領通知を発行する。このように即座に注文の受領処理ができるので、注文情報を受け付ける際の高い応答速度を確保することができる。その一方で、各PM端末が受領した注文情報は各データベース308に格納されており、システム全体としてのポジションの把握が困難となっている。これを解消するためにステップS405以降の処理を行う。
ステップS405では、データベース308に格納した注文情報に基づいて、ポジションサマリ情報を生成する。このポジションサマリ情報とは、その時点で受け付けている注文情報の合計値である。本実施形態では、「買い注文」における注文数量(金額)を正の値として取り扱い、「売り注文」における注文数量(金額)を負の数として取り扱い、これらの注文数量の和に基づいてポジションサマリ情報を算出する。
例えば、1秒間に、5万ドルの買い注文(+5万)、10万ドルの買い注文(+10万)、3万ドルの売り注文(−3万)を受け付けた場合には、ポジションサマリ情報として5万+10万−3万=12万となる。このようにして得られたポジションサマリ情報は、ステップS406で、NPW205へ送信する。
続くステップS407では、ポジションサマリ情報の値Ototalと、カバー注文を行うか否かを決定するための閾値Othとを比較する。この閾値Othは、証拠金取引システム101を運営する証拠金取引会社が取れるリスクに応じて、例えば、50万ドルといったように設定できる。
もし、Ototal≧Othの場合には(ステップS407において「YES」)、ステップS408へ移行する。一方、Ototal<Othの場合には(ステップS407において「NO」)、ステップS401へ移行する。ステップS408では、ポジションサマリ情報の値Ototalの大きさに基づいて、DOC204へカバー注文実行指示を行う。DOC204では、このカバー注文実行指示に基づいてカバー注文を行う。
カバー注文の例を説明する。例えば、ポジションサマリ情報の値が+50万ドルに達した場合を考える。この場合ポジションサマリ情報の符号が正であるので、買い注文が先行していることとなる。そこで、カバー注文では買い注文に対する反対注文として、売り注文が行われる。その際、50万ドルと一致する額の注文を行ってもよいし、一定の割合に相当する額(例えば、6割として、30万ドル)の売り注文を行ってもよい。もし、30万ドルの売り注文を行えば、ポジションサマリ情報の値を20万ドルまで下げて、よりフラットに近づけることができる。
次に、図5を参照して、NPW205及びNPC206において実行される処理について説明する。図5は、証拠金取引会社システム101を構成するコンポーネントであるNPW205及びNPC206において実行される処理の流れを示すフローチャートである。図5のフローチャートに対応する処理は、各コンポーネント内の情報処理端末の内部記憶装置307に格納されている対応処理プログラムをRAM302に読み出し、CPU301が実行することによって実現される。
まず、ステップS501において、NPW205は、PM端末からポジションサマリ情報を受信する。次に、ステップS502では、NPW205は全てのPM端末からポジションサマリ情報を受信したか否かを判定する。もし、全てのPM端末から受信した場合には(ステップS502において「YES」)、ステップS503に移行する。
ステップS503では、NPW205は、受信したポジションサマリ情報を合計して、システムのネットポジション情報Npを計算する。このネットポジション情報Npは、ポジションサマリ情報を足し合わせることにより計算できる。例えば、3台のPM端末がPM−1、PM−2、PM−3として、PM−1から+10万ドル、PM−2から+10万ドル、PM−3から+40万ドルが通知された場合には、ポジションサマリ情報として+60万ドルと計算することができる。
次に、ステップS504では、NPW205は、ネットポジション情報Npと受信したポジションサマリ情報をNPC206に送信する。ステップS505では、NPC206が、受信したネットポジション情報Npと、所定の閾値Pthとを比較する。この閾値Pthは、上述のカバー注文を行うか否かを決定するための閾値Othと同一の値とすることができる。
もし、Np≧Pthの場合には(ステップS505において「YES」)、ステップS506へ移行する。一方、Np<Pthの場合には(ステップS505において「NO」)、ステップS501に戻って、NPW205がポジションサマリ情報の受信を行う。
上述のポジションサマリ情報が+60万ドルの例では、閾値Pthを50万ドルとすれば60万ドル>50万ドルであるので、閾値Pthを超えることとなり、ステップS506に移行することとなる。
ステップS506では、NPC206は、各PM端末におけるポジションサマリに基づいて、各PM端末への注文処理を行う。この注文処理の内容については、図6Aを参照してより詳細に説明する。注文処理が終了すると、ステップS501に戻って、NPW205がポジションサマリ情報の受信を行う。
次に、図6Aを参照して、NPC206において実行されるPM203への注文処理について説明する。図6Aは、証拠金取引会社システム101を構成するコンポーネントであるNPC206において実行される処理の流れを示すフローチャートである。図6Aのフローチャートに対応する処理は、コンポーネント内の情報処理端末の内部記憶装置307に格納されている対応処理プログラムをRAM302に読み出し、CPU301が実行することによって実現される。
まず、ステップS601では、ポジションサマリ情報が最大のPM端末を決定する。この場合、ネットポジション情報の値は、絶対値において扱う。即ち、+50万ドルと、−70万ドルであれば、−70万ドルの方が大きいこととなる。以下、図7Aの例を参照して説明を行う。
図7Aは、PM−1からPM−3までの各PM端末から受信したポジションサマリ情報と、ネットサマリ情報と、閾値Pthの一例を示す。この場合、PM−1とPM−2におけるポジションサマリ情報は、+10万ドルとなっている。一方、PM−3のポジションサマリ情報は、+40万ドルとなっている。従って、ネットサマリ情報は、合計して+60万ドルである。また、Pthは50万ドルであるので、ネットサマリ情報は、閾値Pthを超えている。
この状況で、ステップS601では、最大値を有するPM端末をPM−3と決定することができる。
次に、ステップS602では、残りのPM端末に対して各端末のポジションサマリ情報を相殺するための反対注文を行う。即ち、図7Aの例では、PM−1とPM−2に対して、10万ドルずつの売り注文を行う。なお、反対注文は、各端末のポジションサマリ情報を完全に相殺するものでなくてもよく、ステップS603における処理対象のPM端末のポジションサマリ情報が閾値を超える数量(金額)で有ればよい。
続くステップS603では、ステップS602で行った反対注文の更に反対注文を、ステップS602における注文数を相殺する注文数だけ、ステップS601で決定されたポジションサマリ情報が最大のPM端末に対して行う。図7Aの例では、20万ドルの買い注文を、PM−3に対して行う。
なお、ステップS602及びステップS603における注文処理に基づく注文情報は、ステップS402において各PM端末受信する注文情報として扱われる。なお、ステップS402において、NPC206から注文情報を受信した場合、ステップS404における注文受領通知は、AGW202ではなくNPC206に送信される。
この結果、図7Bに示すように、各端末におけるポジションサマリ情報が変更される。即ち、システム全体として、注文情報が単一の端末に集約された形となる。そして、注文情報が集約された形となった端末であるPM−3は、ステップS407及びステップS408の処理を経て、DOC204に対してカバー注文実行指示を通知することができる。
このようにして、NPW205及びNPC206を利用することにより、1つのPM端末に注文情報を集約させることで、随時カバー注文を自動的に行うことが可能となる。
なお、図7Aの例では、各端末におけるポジションサマリ情報が全て同一符号の場合を記載した。しかし、当然に端末毎に売りが先行したり(負に振れたり)、買いが先行したり(正に振れたり)する場合がある。そのような場合には、システム全体としてのリスクを軽減するために、所謂付け合い注文を行って、各端末のポジションのバラツキを吸収することができる。
例えば、PM−1のポジションサマリ情報が−10万ドル、PM−2のポジションサマリ情報が−20万ドル、PM−3のポジションサマリ情報が40万ドルの場合、売り注文の合計が30万ドル、買い注文の合計が40万ドルとなる。この場合、売りについて30万ドル、買いについて40万ドルで、計70万ドルのリスクを背負うこととなる。その一方で、ネットポジションとして見た場合には、+10万ドルしか買いが先行していない。
このような状況では、リスクを軽減し、また収益を拡大するために同額の反対注文を一部のPM端末に行い、全体としてのポジションをフラットにする。即ち、PM−1とPM−2に対して、それぞれ10万ドル、20万ドルの付け合わせの買い注文を行い、PM−3に対して30万ドルの付け合わせの売り注文を行う。
このような付け合わせ注文により、PM−1とPM−2のポジションサマリ情報は0となり、PM−3のポジションサマリ情報は10万ドルとなり、ネットポジション情報とシステムが背負うリスクとが一致する。
なお、各端末におけるポジションサマリ情報の符号が一致しない場合は、上述の付け合わせ注文を行った後に、図6Aの処理をしてもよい。
上記において、図6AのステップS601では、ポジションサマリ情報が最大のPM端末を決定したが、ここで選択されるPM端末は、必ずしもポジションサマリ情報が最大のPM端末でなくてもよい。例えば、ポジションサマリ情報が最小のPM端末を含めて、複数のPM端末のいずれであってもよいし、予め定められた特定のPM端末(例えば、図7AのPM−1)であってもよい。このような場合、ステップS601に続くステップS602では、ステップS601で決定されたPM端末以外の端末を対象として反対注文を実行し、ステップS603では、ステップS601で決定したPM端末に該反対注文を相殺する注文処理を実行する。
また、更なる場合として、図4のステップS407及びS408における処理をPM端末では行わないこととしてもよい。この場合、NPC206においてカバー注文処理を実行することができる。即ち、図6Aのフローチャートの代わりに、図6Bに示すフローチャートに従った処理を行うことができる。
図6Bのフローチャートでは、ステップS611において、NPW205から受信したネットポジション情報Npと、カバー注文を行うか否かを決定するための閾値Othとを比較する。ここで、もし、ネットポジション情報Npが閾値Oth以上の値を有する場合は(ステップS611において「YES」)、ステップS612に移行する。一方、ネットポジション情報Npが閾値Oth未満の値を有する場合は(ステップS611において「NO」)、本処理を終了する。
ステップS612では、ネットポジション情報Npの値の大きさに基づいて、DOC204へカバー注文実行指示を行う。DOC204では、このカバー注文実行指示に基づいてカバー注文を行う。カバー注文の内容については、図4のステップS408で説明したのと同様であるので、ここでの説明は省略する。このカバー注文処理により、ネットポジション情報Npの値がカバー注文分だけ減少することとなる。
続くステップS613では、PM203を構成する複数のPM端末のうち、いずれか1つのPM端末を選択する。続くステップS614では、複数のPM端末のうちステップS613で選択されなかった残りのPM端末に対し、各端末のポジションサマリ情報を相殺するための反対注文を行う。ここでの処理は、図6AのステップS602における処理と同様である。図7Aの例を用いて説明すると、ステップS613で選択されたPM端末がPM−1とすると、ステップS614ではPM−2とPM−3に対して−10万ドル、−40万ドルの反対注文がそれぞれ行われ、各端末のポジションサマリ情報が相殺される。
続くステップS615では、ステップS613で選択されたPM端末のポジションサマリ情報を、カバー注文後のネットポジション情報Npの値に一致させるための注文処理を行う。例えば、ステップS612においてネットポジション情報Npが+60万ドルの場合に、カバー注文が−30万ドル行われた場合、カバー注文後のネットポジション情報Npは+30万ドルとなる。そこで、ステップS613では、PM−1のポジションサマリ情報をカバー注文後のネットポジション情報Npに一致させるために+20万ドルの注文処理をPM−1に対して行う。以上により、PM−1、PM−2、PM−3の各ポジションサマリ情報は、+30万ドル、0、0となる。以上の処理によれば、図4及び図6Aの処理を行った場合と同様のポジションサマリの状況を構成することができる。
以上の本実施形態に対応する証拠金取引会社システムの構成によれば、PM203を構成する各PM端末は、各端末のデータベースに書き込みを完了させるだけで受領応答が可能である。よって、PM端末の数を増加させても、地理的に分散して配置しても、従来のように受領応答速度の低下を招くことはない。即ち、本発明によればシステムの拡張性が得られる。
また、システム全体としてのポジションは、NPW205やNPC206により集中管理するので、共通のデータベースにリアルタイムに書き込みを行わないことのリスクは担保することができる。また、NPW205やNPC206による管理は受領応答ほどのリアルタイム性は要求されないので、システムの負荷も少なくて済む。
ここで、以上の本実施形態に対応する証拠金取引会社システムの構成に基づく効果を、従来構成と比較して更に具体的に説明する。
例えば、図8に説明した構成において、業務ロジック1002を構成する2台の端末(AP1、AP2)のそれぞれに対し、1秒間に10件の注文情報を受け付けた場合を考える。この場合、AP1とAP2とは、DBに対して1件ごとに書き込みを行うため、DBには1秒間で20回の書き込み処理が行われることとなる。もし、業務ロジック1002の構成端末を更に増加すれば、増加数×10だけDBへの書き込み処理回数が増加することとなる。このように、注文情報の受け付け件数(取引件数)とDBへの書き込み処理件数とは比例することとなる。
これに対し、図2に示すような本実施形態に対応するシステム構成では、注文情報の受領処理を行うPM端末のPM−1からPM−3までに1秒間に10件の注文情報が入力されたとしても、PM端末がNPW205に送信するのは、1秒間に1回のポジションサマリ情報のみである。このポジションサマリ情報の送信回数は、PM端末の注文情報の処理件数に関わらず常に一定である。従って、NPW205は、PM端末と同数のポジションサマリ情報を処理するだけでよく、PM端末が仮に追加された場合であっても、処理件数は追加台数分に比例するだけであって、取引件数の増加は無関係である。
このように、従来構成では、取引件数の増加及び業務ロジック端末の増加に伴って、システム全体のポジションの情報を取得するための処理の負荷が比例的に増加したため、システムの拡張性が阻害されたり、また、注文処理速度が阻害されたりした。これに対して本実施形態の構成では、システム全体のポジションの情報を取得するための処理に対する取引件数の増加は無視できる程度であり、PM端末の増加のみを考慮すればよい。よって、システムの拡張性を持たせることが可能となる。また、注文の受領処理はPM端末内で完結するので、応答速度が阻害されることはない。仮に台数が足りなくなれば、拡張性を生かして増設すればよい。
[他の実施形態]
以上の処理(例えば上記実施形態に示したフローチャートに従った処理)をプログラムとしてCD−R、CD−ROMやDVD−ROM、MO等のコンピュータで読み取り可能な記憶媒体に記憶させ、この記憶媒体に記憶されているプログラムをコンピュータに読み込ませる(インストール、もしくはコピーさせる)ことで、このコンピュータは以上の処理を行うことができる。よって、当該コンピュータプログラムや当該記憶媒体も本発明の範疇にあることは明白である。
発明の実施形態に対応する証拠金取引システムの構成を示す図である。 発明の実施形態に対応する証拠金取引会社システムの構成の一例を示す図である。 発明の実施形態に対応する情報処理端末のハードウェア構成の一例を示す図である。 発明の実施形態に対応するPM端末において実行される処理の一例に対応するフローチャートである。 発明の実施形態に対応するNPW205及びNPC206において実行される処理の一例を示すフローチャートである。 発明の実施形態に対応するNPC206において実行される処理の一例を示すフローチャートである。 発明の実施形態に対応するNPC206において実行される処理の他の一例を示すフローチャートである。 発明の実施形態に対応するPM端末毎の情報の一例を示す図である。 発明の実施形態に対応するPM端末毎の情報の一例を示す図である。 従来の証拠金取引システムの構成を示す図である。

Claims (5)

  1. 複数の取引端末と、カバー取引銀行端末とにネットワークを介して接続される証拠金取引会社システムであって、
    前記複数の取引端末から注文情報を受信する受信装置と、
    複数の処理装置であって、各処理装置が、
    外部記憶装置と、
    前記受信した注文情報を前記外部記憶装置へ書き込む書込手段と、
    前記外部記憶装置への書込の完了に基づいて注文受領通知を前記受信装置に送信する第1の送信手段と、
    前記外部記憶装置に記憶されている前記注文情報の第1の合計値を一定期間毎に算出する算出手段と、
    を備える複数の処理装置と、
    前記複数の処理装置のそれぞれが算出した前記第1の合計値を各処理装置から取得し、取得した各第1の合計値に基づいて第2の合計値を算出する算出装置と、
    注文装置であって、
    前記算出装置で算出された前記第2の合計値と閾値とを比較する比較手段と、
    前記比較手段による比較の結果、該第2の合計値が該閾値以上の場合に、前記複数の処理装置のうちいずれかの第1の処理装置を決定する決定手段と、
    前記第1の処理装置以外の他の処理装置の前記第1の合計値を相殺する第1の注文情報と、該第1の注文情報を相殺する第2の注文情報とを生成する生成手段と、
    前記生成手段が生成した前記第1の注文情報を前記他の処理装置に送信し、前記第2の注文情報を前記第1の処理装置に送信する第2の送信手段と
    を備える注文装置と、
    前記カバー取引銀行端末に対して、カバー注文を行うカバー注文装置と
    を備え、
    前記受信装置は、前記処理装置から受信した前記注文受領通知を、該注文に対応する取引端末へ送信し、
    前記処理装置の前記第1の送信手段は、前記第1の合計値を前記閾値と比較し、前記第1の合計値が前記閾値以上の場合に、前記カバー注文装置に対してカバー注文実行指示を送信し、
    前記カバー注文装置が該カバー注文実行指示に従って、所定金額のカバー注文情報を前記カバー取引銀行端末に送信する、
    ことを特徴とする証拠金取引会社システム。
  2. 複数の取引端末と、カバー取引銀行端末とにネットワークを介して接続される証拠金取引会社システムであって、
    前記複数の取引端末から注文情報を受信する受信装置と、
    複数の処理装置であって、各処理装置が、
    外部記憶装置と、
    前記受信した注文情報を前記外部記憶装置へ書き込む書込手段と、
    前記外部記憶装置への書込の完了に基づいて注文受領通知を前記受信装 置に送信する第1の送信手段と、
    前記外部記憶装置に記憶されている前記注文情報の第1の合計値を一定期間毎に算出する算出手段と、
    を備える複数の処理装置と、
    前記複数の処理装置のそれぞれが算出した前記第1の合計値を各処理装置から取得し、取得した各第1の合計値に基づいて第2の合計値を算出する算出装置と、
    注文装置であって、
    前記算出装置で算出された前記第2の合計値と閾値とを比較する比較手段と、
    前記比較手段による比較の結果、該第2の合計値が該閾値以上の場合に、前記カバー注文実行指示を行う、カバー注文実行指示手段と
    を備える注文装置と、
    前記カバー注文実行指示に応じて、前記カバー取引銀行端末に対してカバー注文を行うカバー注文装置と
    を備え、
    前記注文装置は、前記複数の処理装置のうちいずれか1つの第1の処理装置の前記第1の合計値が前記カバー注文後の前記第2の合計値と一致し、前記第1の処理装置以外の他の処理装置の前記第1の合計値が相殺されるように、前記各処理装置に対して注文処理を行う注文手段を更に備える
    ことを特徴とする証拠金取引会社システム。
  3. 前記注文情報には、買い注文の情報と売り注文の情報とが含まれ、
    前記第1の合計値は、前記買い注文の数量に正の符号を与え、売り注文の数量に負の符号を与えた場合の、前記各処理装置における注文数量の和に基づいて算出されることを特徴とする請求項1又は2に記載の証拠金取引会社システム。
  4. コンピュータを請求項1乃至3のいずれか1項に記載の証拠金取引会社システムを構成する各装置として機能させるためのコンピュータプログラム。
  5. 請求項4に記載のコンピュータプログラムを記憶した、コンピュータで読み取り可能な記憶媒体。
JP2008113224A 2007-04-27 2008-04-23 証拠金取引会社システム、コンピュータプログラム及び記憶媒体 Expired - Fee Related JP4171065B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008113224A JP4171065B1 (ja) 2007-04-27 2008-04-23 証拠金取引会社システム、コンピュータプログラム及び記憶媒体

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
PCT/JP2007/059214 WO2008139525A1 (ja) 2007-04-27 2007-04-27 証拠金取引会社システム、コンピュータプログラム及び記憶媒体
JP2008113224A JP4171065B1 (ja) 2007-04-27 2008-04-23 証拠金取引会社システム、コンピュータプログラム及び記憶媒体

Publications (2)

Publication Number Publication Date
JP4171065B1 true JP4171065B1 (ja) 2008-10-22
JP2008276771A JP2008276771A (ja) 2008-11-13

Family

ID=39985885

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008113224A Expired - Fee Related JP4171065B1 (ja) 2007-04-27 2008-04-23 証拠金取引会社システム、コンピュータプログラム及び記憶媒体

Country Status (1)

Country Link
JP (1) JP4171065B1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6141364B2 (ja) * 2015-07-31 2017-06-07 株式会社 みずほ銀行 プライスプロバイダとカスタマとの取引を支援するためのシステム及び取引支援方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003099610A (ja) * 2001-07-19 2003-04-04 Traders Shoken Kk 外国為替取引に関する注文処理装置、注文処理方法、その方法を実現するプログラム
JP2005032049A (ja) * 2003-07-08 2005-02-03 Mizuho Securities Co Ltd 債券データ処理システム、コンピュータシステムにおける債券データの処理方法及びそのコンピュータプログラム
JP2006268557A (ja) * 2005-03-24 2006-10-05 Nomura Research Institute Ltd Sma管理システム

Also Published As

Publication number Publication date
JP2008276771A (ja) 2008-11-13

Similar Documents

Publication Publication Date Title
Masiak et al. Initial coin offerings (ICOs): market cycles and relationship with bitcoin and ether
US20210374842A1 (en) System and method for apportioning trading orders based on size of displayed quantities
JP6262274B2 (ja) 取引管理装置、取引管理システム、取引管理システムにおける取引管理方法、プログラム
US8799040B2 (en) Engine, system and method of providing business valuation and database services using alternative payment arrangements
US10922752B2 (en) Distributed trading network and interface
WO2017007810A1 (en) Modifying data structures to indicate derived relationships among entity data objects
JP7156783B2 (ja) 金融資産ファンドを管理するためのコンピュータベースのシステムおよびコンピュータにより実行される方法
US20210027377A1 (en) Referential data structures for automatically updating asset attributes in real time based on streaming data
JP2015210675A (ja) 為替予約システム、情報処理方法及びプログラム
US8275637B1 (en) Earnings at risk method and system
JP4113253B1 (ja) 証拠金取引会社システム、コンピュータプログラム及び記憶媒体
Kim et al. Who are robo-advisor users?
US20200372522A1 (en) Computer network systems for electronic market estimation of an indicative term structure for an interest rate benchmark with market-based measures
WO2016012217A1 (en) Computer systems and methods for balancing indexes
JP4171065B1 (ja) 証拠金取引会社システム、コンピュータプログラム及び記憶媒体
Davis et al. Estimating the'coordinated Effects' of Mergers
Fan et al. Fiscal transfers based on inputs or outcomes? Lessons from the Twelfth and Thirteenth Finance Commission in India
US20210174438A1 (en) Computer network systems for electronic market estimation of forward looking term rate composed form real-world funding transaction data
TWM629759U (zh) 數位理財的信託投資管理系統
EP3951692A1 (en) Data processing system, data processing method, and program
Siciliani The Disruption of the Prudential Regulatory Framework
US20150363878A1 (en) Exchange traded collateral system and methods of performing the same
US20150127517A1 (en) Methods and apparatus for facilitating fairnetting and distribution of currency trades
JP2004348487A (ja) 年金ポートフォリオ最適化システム
TWI820362B (zh) 智能投資系統

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080711

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080807

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110815

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110815

Year of fee payment: 3

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140815

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees