JP2015531123A - 注文の事前マッチングリスク検証 - Google Patents

注文の事前マッチングリスク検証 Download PDF

Info

Publication number
JP2015531123A
JP2015531123A JP2015525754A JP2015525754A JP2015531123A JP 2015531123 A JP2015531123 A JP 2015531123A JP 2015525754 A JP2015525754 A JP 2015525754A JP 2015525754 A JP2015525754 A JP 2015525754A JP 2015531123 A JP2015531123 A JP 2015531123A
Authority
JP
Japan
Prior art keywords
order
account
processing logic
exchange system
margin requirement
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.)
Pending
Application number
JP2015525754A
Other languages
English (en)
Other versions
JP2015531123A5 (ja
Inventor
ヨハン ベリエヌッド，
ヨハン ベリエヌッド，
グスタフ モンゴメリー−ニールソン，
グスタフ モンゴメリー−ニールソン，
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nasdaq Technology AB
Original Assignee
OMX Technology AB
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
Application filed by OMX Technology AB filed Critical OMX Technology AB
Publication of JP2015531123A publication Critical patent/JP2015531123A/ja
Publication of JP2015531123A5 publication Critical patent/JP2015531123A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

特定の注文に対する最悪の場合の証拠金所要額をより効率的に計算する技術が提示される。計算された最悪の場合の証拠金所要額は、証拠金が差出担保額を超えるかを判定するために、特定の注文に対するその差出担保と比較することができる。最悪の場合の証拠所要額が差出担保を越える場合、次に、その注文を処理されない（即ち、マッチしない）。最悪の場合の証拠金所要額の判定では、いくつかの要素が考慮することができ、これには、限定するのではないが、スキャンリスク、限月間スプレッドチャージ、及び限月スプレッドチャージが含まれる。【選択図】 なし

Description

本明細書で提示される本発明の実施形態は、一般的には、注文の事前マッチングリスク（pre-match risk）検証に関するものである。より詳しくは、本明細書で提示される実施形態は、マッチングのための注文が取引所システムによって受け付けられる前に、取引所システムに投入される注文のリスク検証のための方法及び事前注文検証デバイスに関するものである。
電子取引所（electronic exchange）あるいは取引所システムは、金融商品を高速かつ効率的に取引するための方法をユーザに提供する。取引所システムは、年を追って大きく進化し、注文を処理する場合には様々な要素を考慮している。特に、電子取引所は、注文をマッチングするためのリスクが高くなりすぎていないかを判定するために、注文の事前検証を行うことができる。つまり、電子取引所システムは、注文をマッチングするためのリスクが高くなりすぎているかを判定するために、注文の事前マッチングリスク検証（即ち、マッチングのための注文が受け付けられる前に）を実行することができる。
時には、証拠金所要額（margin requirement）計算（例えば、デリバティブポートフォリオに対して必要とされる、要求される担保に関する計算）とも呼ばれる、証拠金（margin：マージン）計算は、主に、ポートフォリオに基づいて行われる。つまり、この計算は、完了している（即ち、マッチングされて処理されている）ポートフォリオにおける注文を考慮するものである。
到来する注文のリスクを評価し、そして、一定の閾値（例えば、現在の差出担保価格）を越える証拠金所要額が高まる注文を自動的に拒否する機能を有することの一般的な要望が存在する。例えば、最悪の場合の証拠金所要額が、アカウントに対する特定の注文に対する閾値より高い場合、注文は拒否されるべきであり、そうでない場合には、受け付けられるべきである。
標準ポートフォリオリスク解析システム（ＳＰＡＮ（登録商標））は、現在、所与のアカウントに対するポートフォリオに対する証拠金所要額を計算する。ＳＰＡＮ（登録商標）は、当初は、１９８８年にシカゴマーカンタイル取引所によって開発されたものであり、今日では、証拠金所要額を計算するために広く使用されているシステムである。ＳＰＡＮ（登録商標）による方法は、一連の計算を含み、これには、ポートフォリオストレステストと、所与の時間期間の間に影響を与え得る一定のポートフォリオで、予想される最悪のパフォーマンス損失を生み出し得る商品価格相関とを含んでいる。これを実行するために、ＳＰＡＮ（登録商標）は、一般的には、クリアリングハウス（clearinghouse：手形交換所）あるいはクリアリングハウスシステムによって設定されているパラメータのセットを利用する。ここで、このパラメータのセットは、取引される金融商品の市況を反映し、かつクリアリングハウスに、自身が要望する度合いの範囲を選択することを可能にするものである。
ＳＰＡＮ（登録商標）は、一般的には、いわゆる同属商品（combined commodities）の金融商品の区分、即ち、同一のアンダーライニングアセット（原資産：underlying asset）を共有する商品のグルーピングに基づいている。例えば、先物契約と、その先物契約におけるオプションとを含むポートフォリオは、様々な範囲（同属商品）に区分され、それぞれの範囲は、１つの特定の資産の契約だけを含んでいて、２例だけ挙げると、鉄あるいは銅がある。そして、ＳＰＡＮ（登録商標）は、同属商品それぞれのいくつかについて、また、ポートフォリオにおけるすべての同属商品のいくつかについて、いくつかの計算を実行する。
ＳＰＡＮ（登録商標）による計算は、最終結果として、当初証拠金所要額、またの名は、証拠金所要額を生み出す。この証拠金所要額は、最悪の場合のリスクシナリオでのポートフォリオの損失額を表している。証拠金所要額の公式は、例えば：
証拠金所要額＝ｍａｘ（スキャンリスク（scanning risk）＋限月間スプレッドチャージ（Intermonth Spread Charge：限月間スプレッド割増額）＋限月チャージ（Delivery Month Charge：最終決済証拠金額）−商品間スプレッドクレジット（Intercommodity Spread Credit：商品間スプレッド割引額）、ショートオプション最低チャージ（Short Option Minimum Charge：売オプション最低証拠金額））−ネットオプション価格（Net Option Value）
一般的には、この公式における各項は、別計算を必要とし、また、ポートフォリオにおいて様々な方法で実行される。
換言すれば、ＳＰＡＮ（登録商標）（デルタヘッジ）証拠金モデルでは、証拠金所要額は、上述のように、いくつかの証拠金コンポーネントを加算する（あるいは減算する）ことによって計算される。
通常、支配的なコンポーネントは、以下で説明するスキャンリスク（scanning risk）であるが、他の証拠金コンポーネント群も考慮される。
スキャンリスクは、複数の様々なシナリオポイント（例えば、１６）での各ポジションの理論価格を計算することによって判定される。シナリオポイントは、アンダーライニング価格（原価格）と予想変動率（volatility：ボラティリティ）（現在の市場価格に対してストレスが与えられている価格）によって表現される。アンダーライニング（あるいは同属商品）内で、ネット計算が実行され、ここでは、すべてのポジションが各シナリオポイントに追加され、その結果として、そのシナリオポイントにおける利益あるいは損失が得られる。これらのシナリオポイントの内の１つにおける最悪の場合の損失は、スキャンリスクを表し得る。
ストレスが与えられている価格は、アンダーライニング価格と予想変動率の変化を指し示すことができることが理解されるべきであり、ここで、ストレスが与えられている価格は、ポートフォリオの値が計算されているシナリオポイントをもたらすものである。アンダーライニング（underlying）という用語は、また、どんな証券（例えば、デリバティブ）が満期（現金決済に対して現物引き渡しを使用する場合）に入る／満期にすることができるかを指し示すことができる。上述のことから明らかなように、同属商品という用語は、ＳＰＡＮ（登録商標）用語であり、これは、同属商品の取り決めをクリアリングハウスによって取り扱うことができる１つ以上のアンダーライニングを指し示すことができる。
別の証拠金コンポーネントは、限月間スプレッドチャージ（inter-month spread charge）に関連する。限月間スプレッドチャージは、同一の原資産（同属商品）の注文のグループに対して計算される。これらの注文は所定のティア（tier）に割り当てられ、ここで、各ティアは、特定の範囲における満期を伴う注文に対応する。次に、ティアスプレッドチャージは、同属商品におけるすべてのティア内でかつすべてのティア間で形成されるスプレッドに割り当てられる。スプレッドチャージの大きさと、ティア間でスプレッドが形成されている注文は、予め構成設定されている。ポートフォリオ内の同属商品におけるすべてのスプレッドチャージの総計は、限月間スプレッドチャージである。
更にまた、別の証拠金コンポーネントは、限月チャージ（delivery month charge）に関連している。限月チャージは、１月未満の満期を伴う注文に関連し、これらの注文のポジションデルタ（position delta）に基づいてリスクを割り当てる。スプレッドは、限月における注文のポジションデルタとより上位の満期とを使用する優先度リストに従って形成される。つまり、限月は、最大優先度を有している。スプレッドは限月スプレッドチャージに割り当てられ、スプレッドを形成するために使用することができない限月におけるポジションデルタに対しては、残余ポジションがアウトライト（outright）チャージ（通常は、より大きな）に割り当てられる。限月チャージは、限月スプレッドチャージとアウトライトチャージの総計である。
ＳＰＡＮ（登録商標）モデルに対する欠点は、取引が既に実行されているアカウントに対する証拠金所要額しか計算しないことである。つまり、ＳＰＡＮ（登録商標）モデルは、特定のアカウントに対するポートフォリオ、及びマッチングを待機する注文（即ち、マッチングされていない、オープン注文）を考慮していない。その結果、オープン注文が、アカウントに対する証拠金所要額を増やすあるいは減らすかを評価することが難しい。１つの解決策は、そのアカウントに対する注文控元帳における注文から得ることができる、すべての取り得るポートフォリオに対する、証拠金、あるいは証拠金所要額を計算することになろう。しかながら、これには問題がある。なぜなら、取り得るポートフォリオの数が指数的に高い数になること（即ち、２^（＃の次数））を要求するからである。このような指数的な量は、リアルタイムで、あるいは実質的にリアルタイムで事前注文検証（即ち、注文の事前マッチングリスク検証）を実行するための計算に、不当に膨大な量の時間消費を要求する。こうして、より効率的な事前注文検証計算を提供するシステムを有することは有効であり、そうすることで、証拠金コンポーネントを相対的に正確に、かつリアルタイムで、あるいは実質的にリアルタイムで計算することができる。
別の解決策は、アカウントに関連付けられているすべての注文から得ることができるすべての取り得るポートフォリオに対する証拠金所要額を計算することで、一定の閾値（例えば、現在の差出担保価格）を越えて証拠金所要額を増やすことになるポートフォリオ構成への変更を防止することができよう。しかしながら、これも問題がある。なぜなら、これも、同様に、取り得るポートフォリオの数が指数的に高い数になること（即ち、２^（＃の次数））を要求するからである。このような指数的な量は、リアルタイムで、あるいは実質的にリアルタイムで事前注文検証（即ち、注文の事前マッチングリスク検証）を実行するための計算に、不当に膨大な数の時間消費を要求するからである。こうして、より効率的な事前注文検証計算を提供するシステムを有することは有効であり、そうすることで、証拠金コンポーネントを相対的に正確に、かつリアルタイムで、あるいは実質的にリアルタイムで計算することができる。
上述の検討事項及び他の検討事項を考慮して、本発明の様々な実施形態が実現される。特定の注文に対する最悪の場合の証拠金所要額をより効率的に計算する技術が提示される。計算された最悪の場合の証拠金所要額は、証拠金あるいは証拠金所要額が差出担保額を超えるかを判定するために、特定の注文に対するその差出担保と比較することができる。計算された最悪の場合の証拠金所要額は、また、証拠金あるいは証拠金所要額がアカウントに関連付けられている差出担保額を超えるかを判定するために、そのアカウントに関連付けられている差出担保と比較することもできる。最悪の場合の証拠所要額が差出担保を越える場合、次に、その注文は処理（即ち、マッチング）されなくても良い。最悪の場合の証拠金所要額の判定では、いくつかの要素が考慮することができ、これには、限定するのではないが、スキャンリスク、限月間スプレッドチャージ、及び限月スプレッドチャージが含まれる。
第１の態様に従えば、注文の事前マッチングリスク検証のための事前注文検証デバイスによって実行される方法が提供される。この方法は、受信機によって、クライアントシステムから、注文と、前記クライアントシステムに関係するアカウントを識別する識別情報を含む電子データメッセージを受信するステップと、前記受信機によって、クリアリングハウスシステムから、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を含む電子データメッセージを受信するステップと、前記受信機によって、取引所システムから、前記アカウントに関連付けられている注文についての情報を含む電子データメッセージを受信するステップと、処理ロジックによって、受信した前記注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記ポートフォリオに対するリスク解析を実行するステップと、前記処理ロジックによって、前記受信した注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記注文に対するリスク解析を実行するステップと、前記処理ロジックによって、前記ポートフォリオと前記注文とに対して実行される前記リスク解析に基づいて、前記アカウントに対する証拠金所要額値を判定するステップと、前記処理ロジックによって、前記証拠金所要額値が前記アカウントに対する所定の閾値よりも高いかを判定するステップと、前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、前記処理ロジックによって、前記受信した注文が前記取引所システムによる次のマッチングに対して受け付けられることを判定するステップとを備える。
この方法は、また、前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値より高い場合に、前記処理ロジックによって、前記受信した注文が前記取引所システムによる次のマッチングに対して拒否されることを判定するステップを更に備えることができる。
また、この方法は、前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、送信機によって、前記受信した注文を前記取引所システムによる次のマッチングのために、前記取引所システムへ送信するステップを更に備えることができる。
また、この方法は、送信機によって、電子データメッセージを前記クリアリングシステムへ送信するステップを更に備えることができ、前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を返信するためのリクエストを含んでいる。
更に、また、この方法は、送信機によって、電子データメッセージを前記取引システムへ送信するステップを更に備えることができ、前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられている注文についての情報を返信するためのリクエストを含んでいる。
いくつかの実施形態では、前記証拠金所要額値のパラメータを、少なくともスキャンリスクに基づいて、前記処理ロジックによって判定することができる。この方法は、更に、前記処理ロジックによって、前記アカウントに対する１つ以上のシナリオポイントを確立するステップであって、前記シナリオポイントのそれぞれは、アンダーライニング価格とアンダーライニング予想変動率との基づいている、確立するステップと、前記処理ロジックによって、前記１つ以上のシナリオポイントのそれぞれに対して、利益あるいは損失を確立するステップと、前記処理ロジックによって、最大損失を表現する最悪の場合のシナリオポイントを判定するステップと、前記処理ロジックによって、前記最悪の場合のシナリオポイントの前記最大損失を前記スキャンリスクとして設定するステップと、前記処理ロジックによって、前記スキャンリスクの前記最大損失に基づいて、前記証拠金所要額値を修正するステップとを備えることができる。加えて、この方法は、オプションとして、限月間スプレッドチャージと限月チャージの内の１つあるいは両方のパラメータを追加することによって、前記証拠金所要額値を修正するステップを更に備えることができる。
いくつかの実施形態では、前記１つ以上のシナリオポイントのそれぞれに対して、利益あるいは損失を確立する場合には、この方法は、更に、シナリオポイントのそれぞれの損失に寄与する注文のそれぞれを識別することと、前記シナリオポイントのそれぞれに対する利益あるいは損失を、前記ポートフォリオの利益あるいは損失の値と、前記シナリオポイントそれぞれについて識別される前記注文に関連付けられている損失の値とに基づいて、計算することとを含んでいる。
この方法は、前記取引所システムのマッチングデバイス（あるいはマッチングエンジン）によって、前記取引所システムの注文控元帳に既に記憶されている注文と受信した注文とをマッチングするための試行を行う前に、効果的に実行することができる。
別の態様に従えば、取引所システムの注文控元帳に既に記憶されている注文と受信した注文とをマッチングするための試行を行う前に、注文の事前マッチングリスク検証のための事前注文検証デバイスが提供される。一実施形態に従うこの事前注文検証デバイスは、受信機と処理ロジックとを備える。前記受信機は、クライアントシステムから、注文と、前記クライアントシステムに関係するアカウントを識別する識別情報を含む電子データメッセージを受信し、クリアリングハウスシステムから、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を含む電子データメッセージを受信し、前記取引所システムから、前記アカウントに関連付けられている注文についての情報を含む電子データメッセージを受信するように構成されている。また、前記処理ロジックは、受信した注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記ポートフォリオに対するリスク解析を実行し、前記受信した注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記注文に対するリスク解析を実行し、前記ポートフォリオと前記注文とに対して実行される前記リスク解析に基づいて、前記アカウントに対する証拠金所要額値を判定し、前記証拠金所要額値が前記アカウントに対する所定の閾値よりも高いかを判定し、前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、前記受信した注文が前記取引所システムによる次のマッチングに対して受け付けられることを判定するように構成されている。
前記処理ロジックは、前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値より高い場合に、前記受信した注文が前記取引所システムによる次のマッチングに対して拒否されることを判定するように更に構成することができる。
この事前注文検証デバイスは、また、前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、前記受信した注文を前記取引所システムによる次のマッチングのために、前記取引所システムへ送信するように構成されている送信機を更に備えることができる。
また、この事前注文検証デバイスは、電子データメッセージを前記クリアリングシステムへ送信するように構成されている送信機を更に備えることができ、前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を返信するためのリクエストを含んでいる。更に、また、この事前注文検証デバイスは、電子データメッセージを前記取引所システムへ送信するように構成されている送信機を更に備えることができ、前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられている注文控元帳に含まれる注文についての情報を返信するためのリクエストを含んでいる。
いくつかの実施形態に従えば、前記証拠金所要額値のパラメータが、少なくともスキャンリスクに基づいて、前記処理ロジックによって判定される。前記処理ロジックは、前記アカウントに対する１つ以上のシナリオポイントであって、前記シナリオポイントのそれぞれが、アンダーライニング価格とアンダーライニング予想変動率との基づいているシナリオポイントを確立し、前記１つ以上のシナリオポイントのそれぞれに対して、利益あるいは損失を確立し、最大損失を表現する最悪の場合のシナリオポイントを判定し、前記最悪の場合のシナリオポイントの前記最大損失を前記スキャンリスクとして設定し、前記スキャンリスクの前記最大損失に基づいて、前記証拠金所要額値を修正するように構成することができる。前記処理ロジックは、オプションとして、更に、限月間スプレッドチャージと限月チャージの内の１つあるいは両方のパラメータを追加することによって、前記証拠金所要額値を修正するように構成することができる。
いくつかの実施形態では、前記事前注文検証デバイスの前記処理ロジックは、更に、前記１つ以上のシナリオポイントのそれぞれに対して、利益あるいは損失を確立する場合に、シナリオポイントのそれぞれの損失に寄与する注文のそれぞれを識別し、前記シナリオポイントのそれぞれに対する利益あるいは損失を、前記ポートフォリオの利益あるいは損失の値と、前記シナリオポイントそれぞれについて識別される前記損失に関連付けられている損失の値とに基づいて、計算するように構成されている。
いくつかの実施形態では、この事前注文検証デバイスは、前記取引所システムに備えられている。他の実施形態では、この事前注文検証デバイスは、前記取引所システムの一部を形成するのではなく、別のエンティティである。
本発明の、これらの態様及び他の態様、特徴及び効果は、図面を参照する、本発明の実施形態の以下の説明から明らかであり、かつ解明されるであろう。
取引所システム３００の例示の実施形態の機能ブロック図である。 注文における事前注文検証あるいは事前マッチングリスク検証を実行する取引所システム３００の例示のブロック図である。 事前注文検証中のスキャンリスクを計算するための例示のアプリケーションフローチャートである。 事前注文検証中の限月間スプレッドチャージにおける概算上限を計算するための方法の例示のアプリケーションフローチャートである。 事前注文検証中の限月チャージにおける概算上限を計算するための方法の例示のアプリケーションフローチャートである。 様々なシナリオポイントのサンプルを示す図である。 どのようにしてティア構造を１つのレベルに分解するかを示す図である。 事前構成設定限月間スプレッドチャージが１つのレベルに分解することができることを示す図である。 ２つの「シナリオ」ポートフォリオを示す図である。 注文の事前マッチングリスク検証の例示の環境における事前注文検証デバイスの例示の実施形態を示す図である。
以下の記載は、説明の目的のためであって、限定するものではなく、記載の技術の理解を提供するために、特定の詳細を、例えば、特定のノード、機能エンティティ、技術、プロトコル等で説明する。他の実施形態を、以下の詳細説明から離れて実施できることが当業者に明らかであろう。他の例では、周知の方法、デバイス、技術等の詳細説明は、不必要な詳細説明で説明を曖昧にしないために省略している。個々の機能ブロックが図に示される。当業者は、これらのブロックの機能は、個別のハードウェア回路を使用して、適切なプログラム化マイクロプロセッサあるいは汎用コンピュータと協働するソフトウェアプログラムとデータを使用して、特定用途集積回路（ＡＳＩＣ）、及び／あるいは、１つ以上のデジタル信号プロセッサ（ＤＳＰ）を使用して、実現することができることが当業者は理解している。ソフトウェアプログラム命令とデータは、非一時的コンピュータ可読記憶媒体に記憶することができ、この命令がコンピュータあるいは他の適切なプロセッサ制御によって実行されると、コンピュータあるいはプロセッサは機能を実行する。データベースが以下のテーブルとして示されているが、他のフォーマット（リレーショナルデータベース、オブジェクトベースモデル、及び分散データベース）を、データを記憶し操作するために使用することができる。
プロセスステップ、アルゴリズムあるいはその類は、特定の連続する順序で記載されているあるいは請求項に記載されている場合があるが、このようなプロセスは、異なる順序で動作するように構成設定することができる。換言すれば、明示的に記載されるあるいは請求項に記載される任意のシーケンスあるいは順序のステップは、そのステップがその順序で実行されるべきあることが要件であることを必ずしも示すものではない。本明細書で記載されるプロセスのステップは、取り得る任意の順序で実行することができる。また、いくつかのステップは、同時に発生していないように記載されているあるいは暗示されている（例えば、１つのステップは、他のステップの後に記載されているからである）かに関わらず、同時に実行することができる。また、図面で表現されるプロセスの図は、図示されるプロセスが他の変形及び修正を除くことを暗示しているのではなく、また、図示されるプロセスあるいは任意のそのステップが本発明（群）に必須であることを暗示しているのではなく、また、図示されるプロセスが好ましいことを暗示しているものではない。プロセスの記述は、プロセスを実行するための装置の記載である。プロセスを実行する装置は、プロセスを実行するために適切な、例えば、プロセッサと、それらの入力デバイスと、出力デバイスとを含むことができる。
様々な形式のコンピュータ可読媒体を、プロセッサにデータ（例えば、命令のシーケンス）を搬送する際に介在させることができる。例えば、データは、（ｉ）ＲＡＭからプロセッサへ配信されても良く、（ｉｉ）任意のタイプの送信媒体（例えば、有線、無線、光等）を介して搬送されても良く、（ｉｉｉ）イーサネット（あるいはＩＥＥＥ８０２．３）、ＳＡＰ、ＡＴＰ、ブルートゥース、ＴＣＰ／ＩＰ、ＴＤＭＡ、ＣＤＭＡ、３Ｇ等のような、いくつかのフォーマット、規格あるいはプロトコルに従ってフォーマット及び／あるいは送信されても良く、及び／あるいは（ｉｖ）周知の様々な方法の任意のものでプライバシーを確保するためにあるいは流出を防止するために暗号化されても良い。
図１は、取引所３００（取引所システムとも呼ばれる）で注文を作成し、発行するように構成設定されているクライアントシステム１００に、ネットワーク２００を介して接続されている取引所システム３００の例示の実施形態の機能ブロック図を示している。クライアントシステム１００は、パーソナルコンピュータ、ＰＤＡ（パーソナルデジタルアシスタント）デバイス、携帯電話（またの名を移動電話）、サーバコンピュータ、あるいは、本明細書に記載される電子取引所３００を制御するための任意の他のシステム／デバイス、で実現することができる、及び／あるいは、を介して使用することができる。クライアントシステム１００は、取引所３００との電子取引を指示する任意の個人及び／あるいは企業とすることができることも理解されるべきである。取引所システム３００は、注文のマッチングするために複数のクライアントシステム１００と通信することができることも理解されるべきである。
クライアントシステム１００は、中央処理ユニット（ＣＰＵ）１００、メモリ１０２、及びデータ送信デバイス１０３とを含んでいる。データ送信デバイス（ＤＴＤ）１０３は、例えば、クライアントシステム１００をネットワーク２００に接続することができるネットワークインタフェースデバイスとすることができる。接続は、有線、光、あるいは無線とすることができ、また、例えば、ＷｉＦｉネットワーク、インターネット、セルラーデータサービスを介して接続することができる。データ送信デバイス１０３は、ブローカシステム１００がコンピュータ可読記憶媒体上にデータを配置することを可能にする入力／出力デバイスとすることもできる。データ送信デバイス１０３は、データを送受信することができる（即ち、送受信機）ことが理解されるべきである。データは、データパッケージ、即ち、電子データメッセージによって送受信することができる。
クライアントシステム１００は、取引所システム３００との取引を行うために使用することができる。例えば、クライアントシステム１００は、証券の購入あるいは売却するための注文の発行に関する電子データメッセージを作成し、そして、その電子データメッセージを取引所システム３００へ送信するために使用することができる。クライアントシステム１００は、デリバティブ商品のための注文をユーザから取り付けることができ、また、取引所システム３００は、その注文のマッチングを試行することができる。
取引所システム３００は、ＣＰＵ３０１、メモリ３０２、及びデータ送信デバイス３０３を含んでいる。例示の実施形態では、取引所システム３００は、複数のプロセッサ、及び／あるいはメモリを含むことができ、また、安全装備冗長性のために設計することができる。データ送信デバイス（ＤＴＤ）３００は、例えば、取引所３００をネットワーク２００へ接続することができるネットワークインタフェースデバイスとすることができる。データ送信デバイス３０３は、データを送受信することができること（即ち、送受信機）が理解されるべきである。
取引所システム３００は、また、注文をマッチングするための、１つ以上のプロセッサを使用して実現することができる、マッチングエンジン３０４と、注文を記憶するための注文控元帳メモリ３０５、及び事前注文検証エンジン３０６とを有する。注文控元帳３０５は、取引所システム３００のメモリ３０２に存在することができることが理解されるべきである。また、取引所システム３００は、いくつかの注文控元帳（図３では集約して３０５で示されている）を備えることができ、ここで、それぞれの注文控元帳は、いくつかの注文を含むことができることが理解されるべきである。
上述のように、取引所システム３００は、例えば、ネットワーク２００を介して、クライアントシステム１００から発行される注文を受信することができる。注文を受信すると、マッチングエンジン３０４は、その注文を、注文控元帳３０５の対応する注文とのマッチングを試行する。注文のマッチングの前に、事前注文検証エンジン３０６は、本明細書に記載される方法を使用して事前注文検証を実行することができる。例示の実施形態において、注文が首尾よくマッチングしない場合、取引所３００は、注文控元帳３０５に注文を記憶することができる。取引所システム３００は、注文控元帳３０５に部分的に注文をマッチングすることができることが理解されるべきである。
図２は、クリアリングハウスと対話する、取引所あるいは取引所システムの例示のブロック図である。図２に示されるように、到来注文（例えば、注文の発行に関連する電子データメッセージ）は、様々な属性を有することができ、これには、例えば、商品の売／買の指示、注文における上限価格／市場価格、量、及び／あるいは、アカウントの指示があり、これは、事前注文検証を受け得る。事前注文検証は、以下で更に説明するように、クリアリングハウスからのポジションについての情報と、取引所からの各アカウントに対する注文についての情報を使用することができる。
注文が受け付けられる場合（事前注文検証後）、マッチングエンジンは、到来注文と、注文控元帳１−Ｎにおける１つ以上の注文とのマッチングを試行する。マッチングされた注文は取引をもたらすことになり、ここで、マッチングされていない注文は単に注文控元帳に配置することができる。注文がマッチングすると、その取引は各アカウントに追加され、「ポジション」がマッチングされた注文に基づいて更新される。クリアリングハウスでは、マッチングされた注文は、所与のアカウントに対するポートフォリオに追加され、ここで、各ポートフォリオは、ポジションと取引を含む１つ以上の商品を有することができる。ポジションは、商品におけるいくつかのロング契約（long contract）とショート契約（short contract）であり得る。クリアリングハウスは、満期、オプション満期を取り扱うことができ、また、当業者に知られているような証拠金計算を実行することができる。図２に示される例では、注文は、取引所システムによって取り扱うことができ、これに対して、ポートフォリオは、クリアリングハウスによって取り扱うことができる。本明細書に記載されるいくつかの実施形態に従う事前注文検証は効果がある。これは、アカウントが、注文を買い戻す（cover）ための十分な担保を差し出していない可能性がある場合に注文がマッチングされることを防止することができるからであり、これによって、クリアリングハウスが取引による金銭を潜在的に損失することを防止する。
上述のように、ＳＰＡＮ（登録商標）システムに対する１つの欠点は、ポートフォリオだけが評価されて、注文控元帳に記憶されている現存するマッチングされてない注文も考慮して、証拠金所要額を判定する効率的な方法が存在しないことである。非限定的な例示の実装では、到来注文が取引所で受信されると、アカウントに対する既存のポートフォリオに、そのアカウントに対する注文控元帳にすべての注文を加えたものを評価することができる。この評価は、いくつかのＳＰＡＮ（登録商標）パラメータを考慮することができる。
特に、ＳＰＡＮ（登録商標）計算における１つのパラメータには、スキャンリスクがある。システムは、到来注文を受け付ける時点のシナリオポイントを評価することができる。各シナリオポイントでは、すべての既存ポジションに対する利益／損失は、この計算（例えば、スキャンリスク計算）に含まれることになり、また、各注文に対する利益／損失が計算されることになる。シナリオポイントで損失が存在する場合、注文は、この計算（例えば、スキャンリスク計算）に含まれることになる。つまり、そのシナリオポイントにける最悪の場合とは、注文が実行され、そしてポートフォリオに追加されることである。注文は、実行することができるあるいはできない買／売の指示であることが理解されるべきである。実行（全体的にあるいは部分的に）される場合、それは、１つの取引（あるいは、部分的に複数回実行される場合には複数の取引）となる。取引はアカウントと商品に対するポジションを更新することができる。アカウントと商品に対するポジションは、ロング契約とショート契約それぞれの（累積）数である。アカウント（即ち、すべての商品に対する）に対するポジションは、ポートフォリオを表している。こうして、ポートフォリオは、取引だけを有し、注文は持たないことになる。様々なシナリオポイントのサンプルが図５に提供されている。
ポジションあるいは注文に対して判定される利益／損失は、市場価格に与えることができるとともに、一連のオプションに関連する（ポジションではない）注文のオプションプレミアム（premium：価格）にも与えることができることが理解されるべきである。これらの価格は、最終証拠金所要額にも影響を与え得り、そして、最悪の場合に含まれるべき注文を選択する場合に、これらの価格を考慮することも重要である。この評価は、注文と、受付プレミアムと市場価格とを差し引いた支払済プレミアム価格に損失を加えた注文を判定することによって計算することができる。この場合、損失が存在する場合、注文が含まれ、市場価格も、ポジションに対して同一の方法で含まれる。これは、それが、最終証拠金所要額にも影響を与えるからである。
シナリオポイントをもたらす最悪の場合での損失は、最悪の場合に実行される注文の集合を加えたポートフォリオに対する、最悪の場合での証拠金所要額を表している。最悪の場合のスキャンリスクの計算に対しては、計算の数が、取り得る数が指数的に高いポートフォリオの数に比例する計算の数ではなく、注文の数に比例する。このことは、取引所あるいは取引所システムに、取引所によって既に実行されている注文に対して待機しなければならないのではなく、到来注文における事前注文検証を実行すること（即ち、リアルタイムかつ自動的に検証を実行すること）を可能にする。上述のように、最悪の場合のスキャンリスクに対する計算は、アカウント／注文に対する差出担保が計算された最悪の場合でのリスクよりも高いかを判定するために使用することができる。
別の非限定的な例示の実装では、限月間スプレッドチャージにおける上限概算を計算することができ、これは、証拠金所要額とし使用される、あるいは証拠金所要額に追加される。到来注文の限月間チャージにおける効果は、注文の既存の構成設定（コンフィグレーション）とポートフォリオに既に関連付けられているティア（tier）に依存する。伝統的には、マッチングされる（あるいはマッチングされない）注文のすべての置換を試行することなく、１つの注文の限界収益の限月間スプレッドチャージを確実に評価することは難しい。しかしながら、限月間スプレッドチャージの上限概算は判定することができる。
限月間スプレッドチャージの上限概算は、まず、同属商品のティア構造を、すべての注文を含む１つのティアに減らすことによって計算することができる。次に、このティアは、最大事前構成ティアスプレッドチャージに対応するティアスプレッドチャージに割り当てられる。上限概算は、考慮するすべての注文がポートフォリオに含まれる場合に自身の最大値に到達する。これは、単一のティア限月間スプレッドチャージは、形成されるスプレッドの数に伴い成長するからである。最大限月間スプレッドチャージは、すべての注文がマッチングされ、かつポートフォリオに置かれることを想定することによって判定される。
ティア構造がどのようにして１つのレベルに分解されるかを示す図が図７に提供される。
事前構成設定された限月間スプレッドチャージも、図８に示されるように、１つのレベルに分解することができる。
限月間スプレッドチャージの上限概算は、上述のように、最悪の場合のスキャンリスク計算と組み合わせて（例えば、追加することによって）、最悪の場合の証拠金所要額を修正することができる。これは、限月間スプレッドチャージの上限概算であるので、コンポーネントは、判定されたものよりも高い証拠金所要額を更に追加することはできず、このソリューションは、取引所システムに対して、実行する注文を待機しなければならないのではなく、リアルタイムでの事前注文検証を実行することを可能にしながら、到来注文についての検証を自動的に実行することを可能にすることを、ここでも、支援する。
別の非限定的な例示の実装では、限月チャージの上限概算も計算することができる。限月チャージは、通常、特定の限月に対してだけ適用し、そして、任意の他の注文あるいはポジションは、アウトライトをスプレッドに変換することだけをできることが理解されるべきである。例として、アンダーライニングは、８個の先物商品（例えば、２年間の間の各四半期がくる毎に満了する）を有することがあるかもしれない。これらは、８個の異なる満期を表している。各満期に対しては、いくつかのオプション商品（多くの様々な行使価格のコール（call）及びプット（put））が存在し得よう。最も満期に近い先物と、その満期に対するオプション商品は、限月に対するものであると言える。ポジション（あるいは、同属商品におけるすべての限月商品に対する集約デルタ）は、１０個のロング（ポジティブデルタ）と７個のショート（ネガティブデルタ）を、７個のスプレッドと３個のアウトライト（ポジティブ側）を伴って有することができよう。更なる例としては、この同一の同属商品の他の満期に対しては、５個のアウトサイト（ポジティブ側でも）といくつかのスプレッドが存在し得る。２個のネガティブデルタを有する非限月に対する到来注文は、限月で９個のスプレッドを有する結果となるように実行することになる。つまり、２個のアウトライトは、スプレッドに「変換されている」ことになる。
アウトライトチャージがスプレッドチャージよりも大きいという想定を使用することで、これらの計算を無視することができる。これは、このことは、証拠金所要額を削減することになるからである（これによって、上限概算は提供されない）。アカウントに対するポートフォリオ（群）の解析では、２つのポートフォリオが選択され、その１つは、注文控元帳にロングポジションが含まれている注文だけを含み、もう１つは注文控元帳にショートポジションが含まれている注文だけを含んでいる。これらのポートフォリオは、共に、例えば、互いに、実際のポートフォリオにおけるすべてのポジションを備えるという２つの「シナリオ」ポートフォリオとすることができる。注文は、それらがポジティブデルタあるいはネガティブデルタに寄与するかどうかに基づいて分割される。例えば、注文は、それらが実行される場合にはポジティブデルタあるいはネガティブデルタに寄与するかどうかに基づいて分割することができる。最大数のアウトライトを有するポートフォリオは、最悪の場合のポートフォリオとして選択される。２つの例の場合が図９で提供される。
上述のように、限月チャージの上限概算は、最悪の場合のスキャンリスク計算（及び、限月間スプレッドチャージ概算の上限）と組み合わせて、最悪の場合の証拠金所要額を修正することができる。これは、限月チャージの上限であるので、コンポーネントは、判定されたものよりも高い証拠金所要額を更に追加することはできず、このソリューションは、取引所に対して、実行する注文を待機しなければならないのではなく、リアルタイムでの事前注文検証を実行することを可能にしながら、到来注文についての検証を自動的に実行することを可能にすることを、ここでも、支援する。
上述の方法は、任意のタイプの注文に対して実現できるが、この方法は、特に、デリバティブリスクに対する事前注文検証を実行するために特に有用である。デリバティブについて上述の方法で事前注文検証を実行することによって、より正確な証拠金計算を可能にし、おそらくは、より多くの到来注文をマッチングさせることを可能にするより正確な事前注文検証スキームが提供される。
図３は、マッチングエンジン３０４によって、事前注文検証中のスキャンリスクを計算するための方法の例示のアプリケーションフローチャートを示している。このプロセスは、例えば、クライアントシステム１００から注文を受信する（Ｓ３０１）ことによって開始する。次に、注文を発行するアカウントのポートフォリオが解析される（Ｓ３０２）。非限定的な例示の実装では、ポートフォリオは、複数のポートフォリオを構成することになり、また、各ポジションは、スキャンリスクを判定する場合の各シナリオポイントに対して解析されることになる（Ｓ３０４）。
ポートフォリオの解析の後、プロセスは、注文を発行する特定のアカウントに対する注文控元帳の注文を解析する（Ｓ３０３）。ポートフォリオにおけるポジションに対する解析と同様に、例示の実装では、注文控元帳は、到来注文に加えてアカウントに対して複数の注文を含むことになる。スキャンリスク計算における各シナリオポイントに対しては、注文控元帳の各注文が、例えば、各シナリオポイントに対して解析される（Ｓ３０４）。
各シナリオポイントに関するリスクの評価に応じて（Ｓ３０４）、プロセスは、スキャンリスク評価における最悪の場合のシナリオポイントを判定することを行う（Ｓ３０５）。次に、最悪の場合の証拠金を伴うシナリオポイントが、証拠金所要額を修正するために使用される（Ｓ３０６）。これは、単に、証拠金所要額を最悪の場合のシナリオポイントに設定することによって、あるいは、最悪の場合のシナリオポイントに対して判明する価格を総証拠金所要額に追加することによって、達成することができる。例えば、証拠金所要額は、様々なＳＰＡＮ（登録商標）パラメータ（例えば、限月間スプレッドチャージ、限月チャージ）に対する他の計算を考慮することもできる。
次に、修正された証拠金所要額（即ち、計算されたスキャンリスクを考慮する証拠金所要額）は、注文を実行すること可能にするために、アカウントに対する閾値と比較される（Ｓ３０７）。例示の実装では、閾値は、最悪の場合の注文の実行に対する最高成果証拠金所要額を満足するために要求される差出担保と相関することになる。修正された証拠金所要額が差出担保よりも高い場合、システムは、注文を拒否し（Ｓ３０８）、同様に、修正された証拠金所要額が差出担保よりも低い場合、システムは、注文を受け付ける／実行することができる（Ｓ３０９）。
図３に示される例示の方法の非限定的な例示の疑似コード表現は、以下のようになる。
ポジションＰ１，Ｐ２，．．．Ｐｎからなるポートフォリオ
注文０１，０２，．．．Ｏｍは、注文控元帳に常駐している
注文Ｏが到来している
Worst = 0
Loop: Scenario points
Acc = 0
Loop: Positions in portfolio
P＆L = - Theoretical price change for Pi - market_value
Acc = Acc + P＆L
Endloop positions
Loop: Orders in the orderbook as well as incoming order
P＆L = -Theoretical price change for Oi + premium_paid
- premium_received - market_value
If loss (i.e. P＆L ＞ 0)
Acc = Acc + P＆L
Endloop orders
If Acc worse than Worst (i.e. Acc ＞ Worst)
Worst = Acc
Endloop scenario points
この方法でスキャンリスクを計算することによって、特定のアカウントに対する注文控元帳における注文の数が増えている場合でさえも、要求される計算リソースはかなりより合理的なものとなる。これは、特定のアカウントに対して、既存のマッチングされていない注文を考慮しながら、伝統的なＳＰＡＮ（登録商標）方法を採用する、到来注文の正確なリアルタイム事前注文検証を可能にする。
図３を参照すると、図１０に示されるような、非限定的な例示の実施形態の事前注文検証デバイス３０６を、ここで、詳細に説明する。事前注文検証デバイス３０６は、図３を参照して説明される方法を実行するように構成設定することができる。
この目的を達成するために、注文の事前マッチングリスク検証のための、事前注文検証デバイス３０６によって実行される方法は、クライアントシステム１００から、クライアントシステム１００も関係するアカウントを識別する識別情報と注文を含む電子データメッセージ１００１を受信すること（Ｓ３０１）を含んでいる。また、この方法は、クリアリングハウス６００から、そのアカウントに関連付けられているポートフォリオに関連付けられている情報を含む電子データメッセージ１００２を受信すること（Ｓ３０２）を含んでいる。更にまた、この方法は、取引所システム３００から、アカウントに関連付けられている注文についての情報を含む電子データメッセージ１００３を受信すること（Ｓ３０３）を含んでいる。このアカウントに関連付けられているポートフォリオに対するリスク解析が、受信した注文を受け付けるかを判定するために実行され（Ｓ３０３、Ｓ３０４）、そうすることで、取引所システム３００は、例えば、取引所システム３００のマッチングエンジン３０４によって、注文をマッチングするための試行を行うことが可能となる。また、そのアカウントに関連付けられている注文に対するリスク解析が、受信した注文を受け付けるかを判定するために実行され（Ｓ３０３、Ｓ３０４）、そうすることで、取引所システム３００は、注文をマッチングするための試行を行うことが可能となる。続いて、この方法は、そのポートフォリオとその注文に対して実行されるリスク解析に基づいて、そのアカウントに対する証拠金所要額値を判定すること（Ｓ３０５）によって継続する。その証拠金所要額値がそのアカウントに対する事前定義閾値よりも高いかも判定される（Ｓ３０７）。そのアカウントに対する証拠金所要額値がそのアカウントに対する閾値以下であると判定される（Ｓ３０９）場合、取引所システム３００による次のマッチングのために受信した注文は受け付けられる。そのアカウントに対する証拠金所要額値がそのアカウントに対する閾値よりも高いと判定される（Ｓ３０８）場合、取引所システム３００による次のマッチングのために受信した注文は拒否される。この方法は、そのアカウントに対する証拠金所要額値がそのアカウントに対する閾値以下である場合、取引所システム３００による次のマッチングのために受信した注文を取引所システム３００へ送信することも含むこともできる。
この方法は、更に、電子データメッセージをクリアリングハウスシステム６００へ送信すること（Ｓ３０２）を含むことができ、ここで、この電子データメッセージは、そのアカウントに関連付けられている識別情報と、そのアカウントに関連付けられているポートフォリオに関連付けられている情報を返信するためのリクエストを含んでいる。
また、この方法は、更に、電子データメッセージを取引所システム３００へ送信すること（Ｓ３０２）を含むことができ、ここで、この電子データメッセージは、そのアカウントに関連付けられている識別情報と、そのアカウントに関連付けられている注文についての情報を返信するためのリクエストを含んでいる。
更に、また、この方法は、そのアカウントに対する１つ以上のシナリオポイントを確立する（establish）こと（Ｓ３０６）を含むことができ、この各シナリオポイントは、アンダーライニング価格（プライス）とアンダーライニング予想変動率とに基づいている。また、方法は、１つ以上のシナリオポイントのそれぞれに対する利益／損失を確立すること（Ｓ３０６）、最大損失を表現する最悪の場合のシナリオポイントを判定すること（Ｓ３０６）、最悪の場合のシナリオポイントの最大損失をスキャンリスクとして設定すること（Ｓ３０６）、及びスキャンリスクにおける最大損失に基づいて、証拠金所要額値を修正すること（Ｓ３０６）を含んでいる。
図１０を参照して継続すると、例示の実施形態は、クライアントシステム１００、事前注文検証デバイス３０６、取引所システム３００及びクリアリングハウスシステム６００を備えている。クライアントシステム１００は、注文を含む電子データメッセージ１００１を発行するために使用される。上述のように、クライアントシステム１００は、パーソナルコンピュータ、ＰＤＡ（パーソナルデジタルアシスタント）デバイス、携帯電話、サーバコンピュータ、あるいは、本明細書に記載される電子取引所を制御するための任意の他のシステム／デバイス、で実現することができる、及び／あるいは、を介して使用することができる。クライアントシステム１００は、電子取引を指示する任意の個人及び／あるいは企業エンティティ（例えば、ブローカ（仲介業者）、ディーラ（販売業者）、トレーダ（取引業者）、あるいは値付け業者）によって操作することができる。クライアントシステム１００は、図１０では単一のエンティティによって例示されているが、いくつかのクライアントシステム１００が存在していても良いことが理解されるべきである。
取引所システム３００は、事前注文検証デバイス３０６を介して、クライアントシステム１００と通信接続可能である。また、クリアリングハウスシステム６００は、取引所システム３００と通信接続可能である。注文検証デバイス３０６は、本明細書で記載される到来注文の事前マッチングリスク検証を実行するように構成設定される。事前注文検証デバイス３０６は、通信インタフェース（ｉ／ｆ）３０６ａを備える。通信インタフェース３０６ａは、受信機（Ｒｘ）を備える。また、通信インタフェース３０６ａは、送信機（Ｔｘ）を備えることができる。選択的には、送信機能と受信機能は、送受信機（Ｔｘ／Ｒｘ）に実装することができる。また、事前注文検証デバイス３０６は、処理ロジック３０６ｂ、あるいは処理回路を備える。事前注文検証デバイス３０６は、メモリ３０６ｃを備える。例えば、メモリ３０６ｃは、コンピュータプログラムを記憶することができ、これは、処理ロジック３０６ｂによって実行される場合に、事前注文検証デバイス３０６に、本明細書の１つ以上の方法を実行させる。
上述のように、事前注文検証デバイス３０６は、取引所システム３００の注文控元帳３０５に既に記憶されている注文と受信した注文とのマッチングための試行を行う前に、注文の事前マッチングリスクのために構成設定されている。例えば、受信機（Ｒｘ）３０６ａは、クライアントシステム１００から、電子データメッセージ１００１を受信するように構成設定することができる。電子データメッセージ１００１は、電子データメッセージ（注文）を送信したクライアントシステム１００に関係するアカウントを識別する識別（ＩＤ）情報と、注文とを含むことができる。
受信機（Ｒｘ）３０６ｂも、クリアリングハウスシステム６００から、そのアカウントに関連付けられているポートフォリオに関連付けられている情報を含む電子データメッセージ１００２を受信するように構成することができる。いくつかの実施形態では、事前注文検証デバイス３０６は、自身の送信機（Ｔｘ）３０６ａを使用して、この情報をリクエストするための電子データメッセージをクリアリングハウスシステム６００へ送信するように構成することができる。より詳しくは、送信機（Ｔｘ）３０６ａは、電子データメッセージをクリアリングハウスシステム６００へ送信するように構成することができ、ここで、この電子データメッセージは、注文を送信したクライアントシステム１００に関連付けられている上述のアカウントについての情報と、そのアカウントに関連付けられている注文の情報を返信するためのリクエストを含んでいる。
加えて、受信機（Ｒｘ）３０６ａは、取引所システム３００から、アカウントに関連付けられている注文についての情報を含む電子データメッセージ１００３を受信するように構成することができる。この注文は、当業者に知られているように、取引所システムの１つ以上の注文控元帳３０５に記憶される。いくつかの実施形態では、事前注文検証デバイス３０６は、自身の送信機（Ｔｘ）３０６ａを使用して、この情報をリクエストするための電子データメッセージを取引所システム３００へ送信するように構成することができる。より詳しくは、送信機（Ｔｘ）３０６は、電子データメッセージを取引所システム３００へ送信するように構成することができ、ここで、この電子データメッセージは、注文を送信したクライアントシステム１００に関連付けられている上述のアカウントについての情報と、そのアカウントに関連付けられている注文の情報を返信するためのリクエストを含んでいる。
処理ロジック３０６ｂは、受信した注文１００１が受け付けられるかを判定するための、そのアカウントに関連付けられているそのポートフォリオに対するリスク解析を実行するように構成することができ、そうすることで、取引所システム３００は、注文をマッチングするための試行が可能となる。処理ロジック３０６ｂは、また、受信した注文１００１が受け付けられるかを判定するための、そのアカウントに関連付けられているその注文に対するリスク解析を実行するように構成することができ、そうすることで、取引所システム３００は、注文をマッチングするための試行が可能となる。また、処理ロジック３０６ｂは、そのポートフォリオとその注文に対して実行されるリスク解析に基づいて、そのアカウントに対する証拠金所要額値を判定するように構成することができる。換言すれば、このリスク解析は、ポートフォリオを注文との両方に対して実行することができる。更にまた、処理ロジック３０６ｂは、証拠金所要額値がそのアカウントに対する所定の閾値よりも高いかを判定するように構成することができる。更にまた、処理ロジック３０６ｂは、アカウントに対する証拠金所要額がそのアカウントに対する閾値以下である場合に、取引所システム３００による次のマッチングのために受信した注文が受け付けられることを判定するように構成することができる。処理ロジック３０６ｂは、更に、アカウントに対する証拠金所要額がそのアカウントに対する閾値より大きい場合に、取引所システム３００による次のマッチングのために受信した注文が拒否されることを判定するように構成することができる。
また、送信機（Ｔｘ）３０６ａは、アカウントに対する証拠金所要額がそのアカウントに対する閾値以下であると判定されている場合に、例えば、取引所システム３００のマッチングエンジン３０４による次のマッチングのための電子データメッセージ（注文）１００１を取引所システム３００へ送信する、即ち、転送するように構成することができる。
１つの例示の実施形態に従えば、証拠金所要額値のパラメータは、少なくともスキャンリスクに基づいて、処理ロジック３０６ｂによって判定することができる。例えば、処理ロジック３０６ｂは、そのアカウントに対する１つ以上のシナリオポイントを確率ように構成することができ、各シナリオポイントは、アンダーライニング価格（プライス）とアンダーライニング予想変動率とに基づいている。また、この処理ロジックは、１つ以上のシナリオポイントのそれぞれに対する利益／損失を確立する（定める）こと、最大損失を表現する最悪の場合のシナリオポイントを判定すること、最悪の場合のシナリオポイントにおける最大損失をスキャンリスクとして設定すること、及びスキャンリスクにおける最大損失に基づいて、証拠金所要額値を修正することを含んでいる。更にまた、処理ロジック３０６ｂは、更に、以下のパラメータの１つ以上を追加することによって証拠金所要額値を修正するように構成することができる。このパラメータは、限月間スプレッドチャージと、限月チャージ（詳細については以下で説明する）がある。
図１０に示されるように、取引所システムから分離する事前注文検証デバイス３０６を提供することで、注文の事前マッチングリスク検証を実行するという利点がある。このようにして、例えば、取引所システム３００のマッチングエンジン３０４によるマッチングの試行を行う前に、到来注文を効率的にフィルタにかけることができる。しかしながら、代替の実施形態では、事前注文検証デバイス３０６は、取引所システムの統合部分として実施することができる（例えば、図１参照）。
図４は、事前注文検証エンジン３０６による事前注文検証中に、限月間スプレッドチャージにおける概算上限を計算するための方法の例示のアプリケーションフローチャートを示している。このプロセスは、例えば、取引所３００が注文を受信する（４０１）場合に開始する。注文を受信すると、注文を発行するアカウントに対するポートフォリオが解析される（Ｓ４０２）とともに、その特定のアカウントに対する注文控元帳におけるその注文が解析される（Ｓ４０３）。
次に、事前構成設定された限月間ティアスプレッドチャージが確立され（Ｓ４０４）、そして、総ティアスプレッドチャージがスプレッドチャージのプリセットティアの最大値として設定される。次に、このプロセスは、注文控元帳のすべての注文がマッチングされ、ポートフォリオに入れられる（Ｓ４０５）ことを想定することができ、そこで、プロセスは、限月間スプレッドチャージに対する概算上限を判定することになる（Ｓ４０６）。概算上限の判定において、プロセスは、すべての注文（注文控元帳の注文と到来注文を加えたもの）を加えたポートフォリオにおけるすべてのポジションをループすることができる。いくつかのスプレッドは、解析で判定されるロングポジションの総数と解析で判定されるショートポジションの総数とに基づいて、判定されることになる。次に、スプレッドは、限月間スプレッドチャージにおける概算上限を判定するために、最大ティアスプレッドチャージと乗算される。
各商品は、−１から＋１の範囲を取ることができる関連デルタ（オプションに対して、例えば、行使価格、アンダーライニング価格、及び予想変動率に基づいて理論的に計算される）を有することができることが理解されるべきである。ポジションデルタは、（ロング−ショート）＊商品デルタである。注文に対して、（買数量−売数量）＊商品デルタを使用することができる。例えば、−０．５のデルタを有するプットオプションと、５のショートポジションは、２．５のポジションデルタ（ポジティブ）となる。同属商品に対して（あるいは、同属商品内のティアに対して）、ポジティブデルタとネガティブデルタは、異なる商品から要約することができる。
限月間スプレッドチャージにおける概算上限の判定に応じて、証拠金所要額は、上限概算に基づいて修正することができる（Ｓ４０７）。最悪の場合の計算されるシナリオポイントにおける証拠金所要額の修正と同様に、証拠金所要額は、限月間スプレッドチャージにおいて計算された上限値に追加することができる。
次に、修正された証拠金所要額（即ち、限月間スプレッドチャージにおける計算された上限を考慮している証拠金所要額）は、注文を実行することを可能にするために、アカウントに対する閾値と比較することができる（Ｓ４０８）。例示の実装では、この閾値は、最悪の場合での注文の実行に対する最高成果証拠金所要額を満足するために要求される差出担保と相関することになる。修正された証拠金所要額が差出担保よりも高い場合、システムは、注文を拒否し（Ｓ４０９）、同様に、修正された証拠金所要額が差出担保よりも低い場合、システムは、注文を受け付ける／実行することができる（Ｓ４１０）。
図４に示される例示の方法の非限定的な例示の疑似コード表現は、以下のようになる。
ポジションＰ１，Ｐ２，．．．Ｐｎからなるポートフォリオ
注文０１，０２，．．．Ｏｍは、注文控元帳に常駐している
注文Ｏが到来している
Tier spread charge = max of preset tier spread charges
longTot = 0
shortTot = 0
Loop: Positions in portfolio + orderbook + incoming order
PosD = Position delta of the position or order
if(PosD ＞ 0)
longTot = longTot + PosD
else
shortTot = shortTot - PosD
## shortTot will be a positive number of negative deltas
Endlooop
spreads = min (longTot, shortTot)
intermonth spread charge = tier spread charge*spreads
図５は、事前注文検証エンジン３０６による事前注文検証中に、限月間スプレッドチャージにおける概算上限を計算するための方法の例示のアプリケーションフローチャートを示している。このプロセスは、例えば、取引所３００が注文を受信する（５０１）場合に開始する。注文を受信すると、注文を発行するアカウントに対するポートフォリオが解析される（Ｓ５０２）とともに、その特定のアカウントに対する注文控元帳におけるその注文が解析される（Ｓ５０３）。
次に、判定された限月に対して実行する注文が判定される（Ｓ５０４）。例示の実装では、これらの注文は、満期が近い商品に対するものとなろう。例えば、限月は、商品契約の期間（例えば、７月限月で、７月３１に満了する注文）内の最近の非満了月となるであろう。
特定された限月に対する注文の判定に応じて、２つのポートフォリオが選択されるあるいは構築される。第１のポートフォリオは、注文控元帳にロングポジションが含まれる注文だけを有するものに関連し（Ｓ５０５）、第２のポートフォリオは、注文控元帳にショートポジションが含まれる注文だけを有するものに関連する（Ｓ５０６）。最大数のアウトライトを有するポートフォリオが、限月チャージの上限計算を概算するために用いる最悪の場合のポートフォリオとして選択される（Ｓ５０７）。スプレッドは、ポジティブデルタの数を表し、これは、その数と等しい数のネガティブデルタによって平衡に保てられていて、また、アウトライトはビッド（入札）側のデルタとすることができ、このビット側は、もう一方の側（スプレッドが形成されている後）における任意の残余デルタによって平衡を保つことができないことが理解されるべきである。
次に、証拠金所要額が、限月チャージの概算上限計算に基づいて修正される（Ｓ５０８）。スキャンリスクと限月スプレッドチャージと同様に、限月チャージを、総証拠金所要額に追加することができる。
修正された証拠金所要額（即ち、限月チャージにおいて計算された上限を考慮している証拠金所要額）は、注文を実行することを可能にするために、アカウントに対する閾値と比較される（Ｓ５０９）。例示の実装では、この閾値は、最悪の場合での注文の実行に対する最高成果証拠金所要額を満足するために要求される差出担保と相関することになる。修正された証拠金所要額が差出担保よりも高い場合、システムは、注文を拒否することができ（Ｓ５１０）、同様に、修正された証拠金所要額が差出担保よりも低い場合、システムは、注文を受け付ける／実行することができる（Ｓ５１１）。
図５に示される例示の方法の非限定的な例示の疑似コード表現は、以下のようになる。
ポジションＰ１，Ｐ２，．．．Ｐｎからなるポートフォリオ
注文０１，０２，．．．Ｏｍは、注文控元帳に常駐している
注文Ｏが到来している
o_charge = 限月におけるアウトライトポジションに対する事前構成設定チャージ
s_charge = 限月におけるスプレッドチャージに対する事前構成設定チャージ
spr = 限月に対するポートフォリオにおけるスプレッドデルタの数
outr = 限月に対するポートフォリオにおけるアウトライトデルタの数
side = 1 アウトライトがロング側である場合, そうでない場合 -1
longTot = 0
shortTot = 0
Loop: Orders in the orderbook as well as the incoming order O
if order is not for delivery month
continue with the next iteration of the loop
delta = Delta of order Oi
if(deita ＞ 0)
longTot = longTot + delta
else
shortTot = shortTot - delta
## shortTot will be a positive number of negative deltas
Endloop
if (side ＞ 0)
new_outr = max (longTot+outr, shortTot-outr)
else
new_outr = max (longTot - outr, shortTot+outr)
delivery_month_charge = spr*s_charge + new_outr*o_charge
図３−図５で上述されるプロセスは、別々の事前注文検証として、あるいは１つの全体事前注文検証として実行することができることが理解されるべきである。例えば、図３に示されるスキャンリスクに関する証拠金所要額を判定する場合において、注文が拒否される場合は、更なる解析は実行されず、注文が受け付けられる場合は、図４に示されるように、プロセスは、限月間スプレッドチャージに関する証拠金所要額を判定することができる。同様に、限月間スプレッドチャージに関する解析後に、注文が受け付けられる場合、図５に示されるように、限月チャージに関する更なる解析を行うことができる。つまり、すべての証拠金コンポーネントの総和が閾値よりも小さいと判定されている場合のみに、注文が受け付けられ、この受付とは、注文が、他の検証を行うことができるマッチングエンジンへ送信されることを意味する。
ＳＰＡＮ（登録商標）計算は、現に、アカウント（即ち、ポートフォリオ）に対して発生し、クリアリングハウスによって実行されることが理解されるべきである。上述の事前注文検証は、注文がマッチングエンジンに到達する前（かつ、続いて、それがマッチングされ、クリアリングハウスのポートフォリオに追加される前）に行うことができる。いくつかの実施形態では、クリアリングハウスに対する手段となり得る、リスクを回避するための計算を、クリアリングハウスに代わって、実行することができる。ここで、リスクとは、契約相手（例えば、投資家）が注文を次々と送信して、それが取引されるとなると、伝統的な方法では必要な担保を差し入れることができないポートフォリオとなるというリスクである（即ち、その時点で、契約相手が債務不履行の状態になる場合において、差入担保の形式でのキャピタルバッファ（buffer capital）がクリアリングに対して十分でなくなる状況）。この技術は、非限定的な例示の実施形態に関して記載されている一方で、この技術は開示の実施形態に限定されるものではなく、むしろ、様々な修正及び等価の構成を網羅するものであることが理解されるべきである。つまり、この技術は添付の請求項によってのみ制限されるものであり、そして、上述の特定の実施形態以外の他の実施形態も添付の請求項の範囲内で等しく可能である。本明細書で使用されるように、「備える」あるいは「含んでいる」は、他の要素あるいはステップの存在を除外するものではない。また、個々の特徴は異なる請求項に含めることができるが、これらは、おそらくは効果的に組み合わせることができ、また、異なる請求項の包含は、それらの特徴の組み合わせが実現可能でない、及び／あるいは利点がないことを意味するものではない。そして、請求項における参照符号は、明確化の例として単に提供されているのであって、いかなる場合でも、請求項の範囲を制限するように解釈されるべきではない。

Claims (20)

  1. 注文の事前マッチングリスク検証のための事前注文検証デバイスによって実行される方法であって、
    受信機によって、クライアントシステムから、注文と、前記クライアントシステムに関係するアカウントを識別する識別情報を含む電子データメッセージを受信するステップ（Ｓ３０１）と、
    前記受信機によって、クリアリングハウスシステムから、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を含む電子データメッセージを受信するステップ（Ｓ３０２）と、
    前記受信機によって、取引所システムから、前記アカウントに関連付けられている注文についての情報を含む電子データメッセージを受信するステップ（Ｓ３０３）と、
    処理ロジックによって、受信した前記注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記ポートフォリオに対するリスク解析を実行するステップ（Ｓ３０２、Ｓ３０４）と、
    前記処理ロジックによって、前記受信した注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記注文に対するリスク解析を実行するステップ（Ｓ３０３、Ｓ３０４）と、
    前記処理ロジックによって、前記ポートフォリオと前記注文とに対して実行される前記リスク解析に基づいて、前記アカウントの証拠金所要額値を判定するステップ（Ｓ３０５）と、
    前記処理ロジックによって、前記証拠金所要額値が前記アカウントに対する所定の閾値よりも高いかを判定するステップ（Ｓ３０７）と、
    前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、前記処理ロジックによって、前記受信した注文が前記取引所システムによる次のマッチングに対して受け付けられることを判定するステップ（Ｓ３０９）と
    を備えることを特徴とする方法。
  2. 前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値より高い場合に、前記処理ロジックによって、前記受信した注文が前記取引所システムによる次のマッチングに対して拒否されることを判定するステップ（Ｓ３０８）を更に備える
    ことを特徴とする請求項１に記載の方法。
  3. 前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、送信機によって、前記受信した注文を前記取引所システムによる次のマッチングのために、前記取引所システムへ送信するステップを更に備える
    ことを特徴とする請求項１に記載の方法。
  4. 送信機によって、電子データメッセージを前記クリアリングシステムへ送信するステップ（Ｓ３０２）を更に備え、
    前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を返信するためのリクエストを含んでいる
    ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
  5. 送信機によって、電子データメッセージを前記取引所システムへ送信するステップ（Ｓ３０２）を更に備え、
    前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられている注文についての情報を返信するためのリクエストを含んでいる
    ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
  6. 前記証拠金所要額値のパラメータが、少なくともスキャンリスクに基づいて、前記処理ロジックによって判定される
    ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
  7. 前記処理ロジックによって、前記アカウントに対する１つ以上のシナリオポイントを確立するステップであって、前記シナリオポイントのそれぞれは、アンダーライニング価格とアンダーライニング予想変動率とに基づいている、確立するステップ（Ｓ３０６）と、
    前記処理ロジックによって、前記１つ以上のシナリオポイントのそれぞれに対して、利益あるいは損失を確立するステップ（Ｓ３０６）と、
    前記処理ロジックによって、最大損失を表現する最悪の場合のシナリオポイントを判定するステップ（Ｓ３０６）と、
    前記処理ロジックによって、前記最悪の場合のシナリオポイントの前記最大損失を前記スキャンリスクとして設定するステップ（Ｓ３０６）と、
    前記処理ロジックによって、前記スキャンリスクの前記最大損失に基づいて、前記証拠金所要額値を修正するステップ（Ｓ３０６）と
    を更に備えることを特徴とする請求項６に記載の方法。
  8. 前記１つ以上のシナリオポイントのそれぞれに対して、利益あるいは損失を確立するステップは、
    前記処理ロジックによって、シナリオポイントのそれぞれの損失に寄与する注文のそれぞれを識別することと、
    前記処理ロジックによって、前記シナリオポイントのそれぞれに対する利益あるいは損失を、前記ポートフォリオの利益あるいは損失の値と、前記シナリオポイントそれぞれについて識別される前記注文に関連付けられている損失の値とに基づいて、計算することと
    を含む
    ことを特徴とする請求項７に記載の方法。
  9. 限月間スプレッドチャージと限月チャージの内の１つあるいは両方のパラメータを追加することによって、前記証拠金所要額値を修正するステップを更に備える
    ことを特徴とする請求項７または８に記載の方法。
  10. 当該方法は、前記取引所システムのマッチングデバイスによる、前記取引所システムの注文控元帳に既に記憶されている注文と前記受信した注文とをマッチングするための試行を行う前に、実行される
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
  11. 取引所システム（３００）の注文控元帳（３０５）に既に記憶されている注文と受信した注文とをマッチングするための試行を行う前の、注文の事前マッチングリスク検証のための事前注文検証デバイス（３０６）であって、
    受信機と、
    処理ロジックとを備え、
    前記受信機は、
    クライアントシステムから、注文と、前記クライアントシステムに関係するアカウントを識別する識別情報を含む電子データメッセージを受信し、
    クリアリングハウスシステムから、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を含む電子データメッセージを受信し、
    前記取引所システムから、前記アカウントに関連付けられている注文についての情報を含む電子データメッセージを受信する
    ように構成されていて、
    前記処理ロジックは、
    受信した注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記ポートフォリオに対するリスク解析を実行し、
    前記受信した注文が受け付けられるかどうかを判定することで、前記取引所システムが前記注文をマッチングすることを試行することを可能にする、前記アカウントに関連付けられている前記注文に対するリスク解析を実行し、
    前記ポートフォリオと前記注文とに対して実行される前記リスク解析に基づいて、前記アカウントの証拠金所要額値を判定し、
    前記証拠金所要額値が前記アカウントに対する所定の閾値よりも高いかを判定し、
    前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、前記受信した注文が前記取引所システムによる次のマッチングに対して受け付けられることを判定する
    ように構成されている
    ことを特徴とする事前注文検証デバイス（３０６）。
  12. 前記処理ロジックは、前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値より高い場合に、前記受信した注文が前記取引所システムによる次のマッチングに対して拒否されることを判定するように構成されている
    ことを特徴とする請求項１１に記載の事前注文検証デバイス（３０６）。
  13. 前記アカウントに対する前記証拠金所要額値が前記アカウントに対する前記閾値以下である場合に、前記受信した注文を前記取引所システムによる次のマッチングのために、前記取引所システムへ送信するように構成されている送信機を更に備える
    ことを特徴とする請求項１１または１２に記載の事前注文検証デバイス（３０６）。
  14. 電子データメッセージを前記クリアリングシステムへ送信するように構成されている送信機を更に備え、
    前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられているポートフォリオに関連付けられている情報を返信するためのリクエストを含んでいる
    ことを特徴とする請求項１１乃至１３のいずれか１項に記載の事前注文検証デバイス（３０６）。
  15. 電子データメッセージを前記取引所システムへ送信するように構成されている送信機を更に備え、
    前記電子データメッセージは、前記アカウントに関連付けられている前記識別情報と、前記アカウントに関連付けられている注文控元帳に含まれる注文についての情報を返信するためのリクエストを含んでいる
    ことを特徴とする請求項１１乃至１４のいずれか１項に記載の事前注文検証デバイス（３０６）。
  16. 前記証拠金所要額値のパラメータが、少なくともスキャンリスクに基づいて、前記処理ロジックによって判定される
    ことを特徴とする請求項１１乃至１５のいずれか１項に記載の事前注文検証デバイス（３０６）。
  17. 前記処理ロジックは、
    前記アカウントに対する１つ以上のシナリオポイントであって、前記シナリオポイントのそれぞれが、アンダーライニング価格とアンダーライニング予想変動率とに基づいているシナリオポイントを確立し、
    前記１つ以上のシナリオポイントのそれぞれに対して、利益あるいは損失を確立し、
    最大損失を表現する最悪の場合のシナリオポイントを判定し、
    前記最悪の場合のシナリオポイントの前記最大損失を前記スキャンリスクとして設定し、
    前記スキャンリスクの前記最大損失に基づいて、前記証拠金所要額値を修正する
    ように構成されている
    ことを特徴とする請求項１６に記載の事前注文検証デバイス（３０６）。
  18. 前記処理ロジックは、更に、
    シナリオポイントのそれぞれの損失に寄与する注文のそれぞれを識別し、
    前記シナリオポイントのそれぞれに対する利益あるいは損失を、前記ポートフォリオの利益あるいは損失の値と、前記シナリオポイントそれぞれについて識別される前記注文に関連付けられている損失の値とに基づいて、計算する
    ように構成されている
    ことを特徴とする請求項１７に記載の事前注文検証デバイス（３０６）。
  19. 前記処理ロジックは、更に、限月間スプレッドチャージと限月チャージの内の１つあるいは両方のパラメータを追加することによって、前記証拠金所要額値を修正するように構成されている
    ことを特徴とする請求項１７または１８に記載の事前注文検証デバイス（３０６）。
  20. 当該事前注文検証デバイスは、前記取引所システムに備えられている
    ことを特徴とする請求項１１乃至１９のいずれか１項に記載の事前注文検証デバイス（３０６）。
JP2015525754A 2012-08-06 2012-12-20 注文の事前マッチングリスク検証 Pending JP2015531123A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261680029P 2012-08-06 2012-08-06
US61/680,029 2012-08-06
PCT/EP2012/076429 WO2014023365A1 (en) 2012-08-06 2012-12-20 Pre-match risk validation of orders

Publications (2)

Publication Number Publication Date
JP2015531123A true JP2015531123A (ja) 2015-10-29
JP2015531123A5 JP2015531123A5 (ja) 2016-02-12

Family

ID=47559408

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015525754A Pending JP2015531123A (ja) 2012-08-06 2012-12-20 注文の事前マッチングリスク検証

Country Status (4)

Country Link
US (1) US20140040112A1 (ja)
JP (1) JP2015531123A (ja)
SG (1) SG11201500784PA (ja)
WO (1) WO2014023365A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021022013A (ja) * 2019-07-24 2021-02-18 株式会社インタートレード 決済処理システム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150112889A1 (en) * 2013-10-18 2015-04-23 Chicago Mercantile Exchange, Inc. Achieving margin capital efficiencies using linear programming
WO2017117191A1 (en) * 2015-12-30 2017-07-06 Chicago Mercantile Exchange Inc. Execution of co-dependent transactions in a transaction processing system

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003006436A (ja) * 2001-06-20 2003-01-10 Traders Shoken Kk 前受金を算出する機能を有する注文処理装置、前受金額算出方法及びその方法を実現するプログラム並びにそのプログラムを記録する記録媒体
US20030033240A1 (en) * 2001-06-11 2003-02-13 Opt4 Derivatives, Inc. Integrated electronic exchange of structured contracts with dynamic risk-based transaction permissioning
JP2003533828A (ja) * 2000-05-19 2003-11-11 シレックス ソシエテ アノニム 電子取引の運営方法及びシステム
JP2008512779A (ja) * 2004-09-10 2008-04-24 シカゴ マーカンタイル エクスチェンジ，インク． アクティビティに基づく証拠金計算のためのシステム及び方法
JP2008515034A (ja) * 2004-09-10 2008-05-08 シカゴ マーカンタイル エクスチェンジ，インク． 柔軟性のあるスプレッド参加のためのシステム及び方法
US20080243671A1 (en) * 2007-04-02 2008-10-02 Driscoll James R Products and processes for differentiating trading orders
JP2009528634A (ja) * 2006-03-01 2009-08-06 タウンセンド・アナリティクス・リミテッド リスク管理のための方法およびシステム
JP2010211411A (ja) * 2009-03-09 2010-09-24 Unimat Yamamaru Shoken Kk 有価証券を担保とする証拠金取引における証拠金取引管理システム
JP2010218171A (ja) * 2009-03-16 2010-09-30 Tokyo Financial Exchange Inc 外国為替取引システム及びビッド／オファーフィルタリング方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7523062B2 (en) * 2002-06-05 2009-04-21 The Nasdaq Omx Group, Inc. Securities processor and a method of processing attributable interest messages
US20030225674A1 (en) * 2002-06-05 2003-12-04 Hughes John T. Order chronicle process and method
US20030233312A1 (en) * 2002-06-05 2003-12-18 Moore Daniel F. Order entry and quote entry in a securities market
US7603303B1 (en) * 2002-11-26 2009-10-13 Trading Technologies International, Inc. System and method for risk management
US8103578B2 (en) * 2005-01-07 2012-01-24 Chicago Mercantile Exchange Inc. System and method for multi-factor modeling, analysis and margining of credit default swaps for risk offset
US20070244791A1 (en) * 2006-04-12 2007-10-18 Deutsche Borse Ag System and method for linked execution of securities transactions
US20090171824A1 (en) * 2007-12-27 2009-07-02 Dmitriy Glinberg Margin offsets across portfolios
US8266030B2 (en) * 2009-09-15 2012-09-11 Chicago Mercantile Exchange Inc. Transformation of a multi-leg security definition for calculation of implied orders in an electronic trading system
US20110119171A1 (en) * 2009-11-19 2011-05-19 Abrams Lawrence J Implied volatility based pricing and risk tool and conditional sub-order books
US8315940B2 (en) * 2010-04-27 2012-11-20 Omx Technology Ab System and method for rapidly calculating risk in an electronic trading exchange

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003533828A (ja) * 2000-05-19 2003-11-11 シレックス ソシエテ アノニム 電子取引の運営方法及びシステム
US20030033240A1 (en) * 2001-06-11 2003-02-13 Opt4 Derivatives, Inc. Integrated electronic exchange of structured contracts with dynamic risk-based transaction permissioning
JP2003006436A (ja) * 2001-06-20 2003-01-10 Traders Shoken Kk 前受金を算出する機能を有する注文処理装置、前受金額算出方法及びその方法を実現するプログラム並びにそのプログラムを記録する記録媒体
JP2008512779A (ja) * 2004-09-10 2008-04-24 シカゴ マーカンタイル エクスチェンジ，インク． アクティビティに基づく証拠金計算のためのシステム及び方法
JP2008515034A (ja) * 2004-09-10 2008-05-08 シカゴ マーカンタイル エクスチェンジ，インク． 柔軟性のあるスプレッド参加のためのシステム及び方法
JP2009528634A (ja) * 2006-03-01 2009-08-06 タウンセンド・アナリティクス・リミテッド リスク管理のための方法およびシステム
US20080243671A1 (en) * 2007-04-02 2008-10-02 Driscoll James R Products and processes for differentiating trading orders
JP2010211411A (ja) * 2009-03-09 2010-09-24 Unimat Yamamaru Shoken Kk 有価証券を担保とする証拠金取引における証拠金取引管理システム
JP2010218171A (ja) * 2009-03-16 2010-09-30 Tokyo Financial Exchange Inc 外国為替取引システム及びビッド／オファーフィルタリング方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
中村 恭二, エクイティ・デリバティブのすべてＩー基礎編, vol. 第1版, JPN6018004503, 10 February 2000 (2000-02-10), JP, pages 105 - 107, ISSN: 0003736079 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021022013A (ja) * 2019-07-24 2021-02-18 株式会社インタートレード 決済処理システム
JP7336109B2 (ja) 2019-07-24 2023-08-31 株式会社インタートレード 決済処理システム

Also Published As

Publication number Publication date
WO2014023365A1 (en) 2014-02-13
SG11201500784PA (en) 2015-02-27
US20140040112A1 (en) 2014-02-06

Similar Documents

Publication Publication Date Title
US11704720B2 (en) Matching techniques for data transaction requests with private attributes
CA2603008C (en) System and method for managing trading between related entities
US20140358757A1 (en) System and method for providing latency protection for trading orders
EP3360109A1 (en) Systems and methods for calculating a latency of a transaction processing system
US20180075530A1 (en) Message cancelation based on data transaction processing system latency
JP2005530281A5 (ja)
US10922752B2 (en) Distributed trading network and interface
US10726485B2 (en) Determination of banding start price for order evaluation
EP3398155A1 (en) Execution of co-dependent transactions in a transaction processing system
US8612323B1 (en) Methods and systems for trade fee and rebate computation and order routing
KR101805420B1 (ko) 주식 투자 성과에 기반한 주식 투자 신뢰성 평가 시스템 및 그 방법
JP2015531123A (ja) 注文の事前マッチングリスク検証
AU2022259791A1 (en) System and method for providing latency protection for trading orders
US20150154699A1 (en) Alternate-Form Options
KR20170099321A (ko) 조건 맞춤형 p2p 담보 대출 금융 기술 서비스 방법 및 그 장치
KR20170133302A (ko) 주식 투자 성과에 기반한 주식 투자 신뢰성 평가 시스템 및 그 방법
KR101805409B1 (ko) 주식 담보를 이용한 피어 투 피어 기반 금융 기술 서비스 방법 및 그 시스템
US11847697B1 (en) Compression optimization
US20150356677A1 (en) Private fund exchange system
KR20180021047A (ko) P2p 무심사 담보 대출 금융 기술 서비스 방법 및 그 장치
KR102248319B1 (ko) 주식 청약 대금 대출을 위한 금융 기술 서비스 방법 및 그 장치
US20140172664A1 (en) Processing of Exercised Options
KR101188692B1 (ko) 다수의 호가 제공 기관을 통한 외환거래 중개방법
AU2021240178A1 (en) System for managing trading between related entities
CN112631159A (zh) 监控方法、装置、存储介质和电子设备

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151217

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151217

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161125

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170106

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170406

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170703

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180209

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20180509

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180706

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180907