JP2008535124A - 内部注文マッチングを伴う取引システム - Google Patents

Abstract

【課題】 内部トレーダーと外部市場との間で有利な方法で取引できるようにする。
【解決手段】 クライアント端末を含む通信ネットワークにわたる為替取引注文ルーティングのためのコンピュータベースシステムが提供されており、クライアント端末は、当該クライアント端末と第１のサーバとの間で前記エンドユーザインタフェースを形成するように構成され、インタフェースは、条件列を含む注文ルーティングストラテジを構築するためのテンプレートを与えるとともに、１つ以上の注文および注文ルーティングストラテジを第１のサーバに対して提示する。プログラムは、第１の電子為替取引市場で注文をクロス売買するとともにそれぞれの第２の電子為替取引市場に注文流動資産を置くことによってルーティングストラテジを実施するために通信ネットワーク内で実行できる。方法は、所定の基準のパラメータを有する条件列を含むルーティングストラテジおよび注文を受けることによって注文ルーティングストラテジを実施し、第１段階注文処理は第１の注文数量をクロス売買場所へ割り当て、第２段階注文処理は第２の注文数量を不使用場所へ割り当てる。
【選択図】 なし

Description

本発明は、電子取引で注文を行なって実行する際の改良に関し、特に、注文流動資産の一部を外部電子取引所へ提供しつつ内部電子取引所で注文を実行するためのシステムおよび方法に関する。

優先権の主張
本出願は、参照することによりその全体が本願に組み入れられる２００５年４月５日に提出され且つ「Ｔｒａｄｉｎｇ Ｓｙｓｔｅｍ ｗｉｔｈ Ｉｎｔｅｒｎａｌ Ｏｒｄｅｒ Ｍａｔｃｈｉｎｇ」と題された米国仮出願６０／６６８，９２９号の優先権の利益を主張する。

電子証券取引市場は、複数の取引所およびブローカーがしばしば同じ特定の製品を取引するように発達してきた。例えば、多くの変額商品またはインスツルメント（例えば、株券、オプション、先物商品、インデックスなど）が複数の株取引所で取引できる。米国債商品は、自分達の注文ブックを電子的に与える複数のブローカーと取引することができ、これは、同様のスタイルのアプリケーションプログラマブルインタフェース（ＡＰＩ）を介して取引所がそれらの注文ブックをどのように提示するかに類似している。

証券を売買する際には、多くの場合、特定の商品を取引できる一組の取引所またはブローカー（用語「取引所」および「ブローカー」はここでは置き換え可能に使用される）の全体にわたって利用できる最良の価格で売買することが望ましい。多くの場合、異なる取引所は、同じ商品に関して同時に異なる価格および流動資産を有しており、そのため、所与の証券を買う或いは売るための決定は、複数の取引所で同時にその証券を買う或いは売ることを意味し得る。また、異なるブローカーは、彼らが成した取引に関して異なる手数料を請求する場合があり、また、異なる取引規則を有する場合がある。トレーダーは、低い手数料の或いは更に有利な規則を有する１つの取引所で取引をしたい場合がある。この場合、実行価格は取引所間で同じである。

多くの場合、トレーダーは、所与の期間に市場で利用できる規模（size）よりもかなり大きい規模で或いは市場がその商品を売ろう（或いは買おう）としている価格よりもより良い価格で特定の数量の商品を買い（或いは売り）たがっている。その場合、トレーダーは、自分が本当に買いたがっている（或いは、売りたがっている）規模よりも小さい規模を示したいと思う場合があり、おそらく、自分が買おうとしている或いは売ろうとしている価格で様々な取引所間でより小さい規模を示す。トレーダーは、所定の数量を更に悪い価格で買おう（或いは売ろう）としている場合さえあるが、市場が自分から離れていかない限り悪い価格を示したいとは思わない。市場状態が変化し且つトレーダーの注文が執行されると、トレーダーは、より多くの規模を元の市場に加えたい或いは自分の価格を様々な取引所で調整したいと思う場合がある。

トレーダーは、一般市場に自分の注文を示すことなく、同じファームまたは取引デスク内の他のトレーダー、或いは、さもなければ「内部」取引グループ（提携会社、好ましい顧客およびクライアント、好ましいパートナーなど）と取引したい場合がある。トレーダーは、自分が手数料を支払わないため或いは内部のトレーダーと有利な関係を有するため、市場でよりも良い価格で内部取引しようとしている場合がある。したがって、トレーダーは、自分の注文が外部で実行される前に内部で常に実行されることを確保したがっている或いはそれらの注文を外部にも示しつつより良い価格で内部で示したがっている場合がある。

最後に、市場の様々な取引所およびブローカーは、一般に、注文を送って価格を受けるための大きく異なるＡＰＩを有しており、そのため、それらの取引所の全てに同じシステムを通じて同時にアクセスすることは困難である。

一群のトレーダーが互いに内部取引できるようにするとともに、トレーダーが自分の注文を内部トレーダーと外部市場との間で有利な方法で取引できるようにすることにより、取引所の好ましい組から可能な最良の価格を達成するというトレーダーの目標を最大にするとともに、様々な取引所が提供する大きく変化するＡＰＩを統一して、同じエンドシステムから異なる取引所にアクセスできるようにする統合システムは当分野に見当たらない。本発明はこれらのニーズおよび他のニーズを満たすことができる。

本発明の１つの態様によれば、為替取引注文ルーティング（order routing）のためのコンピュータベースシステムは、少なくとも１つのプロセッサを有し且つ第１の電子為替取引市場の稼動をサポートするように構成された第１のサーバと、それぞれが少なくとも１つのプロセッサを有し且つそれぞれの第２の電子為替取引市場の稼動をサポートするように構成された１つ以上の第２のサーバと、少なくとも１つのプロセッサを有し且つ第１のサーバとの間でエンドユーザインタフェースを形成するように構成されたクライアント端末とを含む通信ネットワークを備え、エンドユーザインタフェースは、条件列（stipulation string）を含む注文ルーティングストラテジ（routing strategy）を構築するためのテンプレートを提供し且つ１つ以上の注文および注文ルーティングストラテジを第１のサーバに対して提示するように動作できる。また、前記通信ネットワーク内で実行でき且つ前記ルーティングストラテジにしたがって第１の電子為替取引市場で注文をクロス売買する（crossing）ことを試みるとともに前記ルーティングストラテジにしたがってそれぞれの第２の電子為替取引市場に注文流動資産を置くことによって前記ルーティングストラテジを実施するように構成されたプログラムを備える。

本発明の他の態様によれば、方法は、１つのプロセッサを有する第１のサーバで動作する第１の電子為替取引市場と、１つのプロセッサを有するそれぞれの第２のサーバで動作する１つ以上の第２の電子為替取引市場と、１つのプロセッサを有するクライアント端末で動作するエンドユーザインタフェースとを備えるコンピュータベース通信ネットワークで注文ルーティングストラテジを実施し、方法は、注文に関連する数量成分、価格成分、ルーティングストラテジを規定する注文を第１の端末で受け、前記ルーティングストラテジが所定の基準のパラメータを含む条件列を含むステップと、第１の注文数量をクロス売買場所（crossing location）へ割り当てるために所定の基準パラメータにしたがって第１段階注文処理を行なうステップと、第２の注文数量を不使用場所（idle location）へ割り当てるために第２段階注文処理を行なうステップとを含み、第１の注文数量がほぼ即座に執行し、不使用場所で取引が始まるときに第２の注文数量が執行する。また、事象メッセージに応じてルーティングストラテジの規則を評価する評価ステップと、前記評価ステップの結果に応じてルーティングストラテジ実行を変更して、クロス売買場所および不使用場所のうちの少なくとも一方で注文処理を最適化するステップとを含む。

本発明の更なる態様によれば、第１の電子為替取引市場及び／又はそれぞれの第２の電子為替取引市場のうちの少なくとも１つにおいてクロス売買レベルで注文数量の一部を動かすステップと、より積極的に価格設定されたクロス売買レベルに対して優先権を与えるステップと、所定の基準のうちの少なくとも１つに基づいて、注文数量の動いている部分を優先状態に置くステップを含む。

本発明の更に他の態様によれば、ルーティングストラテジのための更新された条件列を受け、更新された条件列の所定の基準にしたがって第１段階注文処理ステップおよび第２段階注文処理ステップを行なう。

これらの態様および他の態様、特徴、ステップ、利点は、添付図面および特定の例示的な実施形態の説明から更に良く理解できる。

概要および序論として、内部／連結為替取引（ＩＣＥ）システム１００の実施形態を示して説明する。ＩＣＥ１００は、内部市場および外部ブローカーおよび為替取引所の領域にわたる流動資産プールへのアクセスを自動的に最適化するためにトレーダーが内部および外部から見える市場を形成できるようにする複合セキュリティ為替・インテリジェント注文ルーティングシステムに関するものである

図１を参照すると、ＩＣＥシステム１００は、１つのファーム内のトレーダーによって成された注文を維持する内部為替取引所１４０を含む。そのファーム内のクロス売買注文は、外部ブローカーおよび為替取引所へ送られることなく、内部為替取引所１４０でマッチさせて執行することができる。内部為替取引所１４０により、ユーザは、内部為替取引所１４０でのみ利用できる価格で内部市場を提供することができ、それにより、優先的価格待遇を他の内部トレーダーに与えることができる。また、内部為替取引所１４０により、個人市場を形成することもできる。個人市場は、内部為替取引所において予め選択されたユーザの一部に見える市場である。個人市場と共に内部為替取引所および外部為替取引所により、１つの注文が異なるユーザに対して異なる価格を示すことができ、それにより、優先的な取り扱いを一部のユーザに対して与えることができる。

内部為替取引所１４０により、選択された市場を販売スタッフ、顧客、加入者に対して取引グループ外で提供することができるとともに、これらの当事者は、共通に理解された為替パラダイム（注文ブック）を介してファームと電子的に取り引きすることができる。

ＩＣＥの注文ルーティング能力は、流動資産の外部プールおよび内部流動資産にアクセスするために外部ブローカーおよび為替取引所への注文のルーティングを可能にする。ルーティング機構は、外部市場からトレーダーを抽出することができ、それにより、様々なアルゴリズムを使用して、ユーザがアクセスできる外部市場の全領域にわたって最適な発注を生じさせることができる。例えば、トレーダーは、外界へ発注されるように指定されたＩＣＥに対して買呼値を提示することができる。注文ルータ２７５は、現在の市場状態に基づいて注文がどのブローカー／為替取引所に対して送られるのかについての決定を行なうことができるとともに、各ブローカー／為替取引所の市場が変化するにつれてその決定を経時的に変更しても良い。

ＩＣＥは、１つの市場データフィードに各個人市場の内部注文ブックおよび全ての外部注文ブックを含む連結価格フィード２６５を送信することができる。

注文は複数の為替取引所へ発注されても良い。ＩＣＥは、注文と共に供給されるリスクパラメータに基づいて過剰執行の機会を管理しながら要求される大きさまで各注文を最も最適に執行するために発注を管理することができる。システムは、カスタマイズ可能な注文ルータ戦略または自動発注・実行アルゴリズムを使用して、指定された行き先が無い注文を様々な為替取引所へ最良に発注する方法を確かめても良い。ルーティングは動的に行なうことができる。この場合、注文は、様々な市場状態が変化するにつれて為替取引所および内部為替取引所間で移動される。

外部市場（ブローカーおよび為替取引所）１０５、１１０、１１５、１２０に対する接続は、ＩＣＥシステムおよびそのユーザと外部市場との間でブリッジを形成する実行接続部２０５、２１０、２１５、２２０（図２）を介して行なわれる。これらの実行接続部により、著しく異なる接続性パラダイムおよび発注モデルを有していても良い外部市場のための共通のインタフェースをＩＣＥシステム１００に対して与えることができる。

図８は、本発明を具現化するプロセスを実施できる典型的な環境の構成要素を示す。本発明を実施するために全ての構成要素が必要とされなくても良く、また、本発明の思想または範囲から逸脱することなく、構成要素の配置およびタイプの変形がなされても良い。特定の構成要素の構造は本発明にとって重大ではない。

図８は、ローカルエリアネットワーク（「ＬＡＮ」）、広域ネットワ−ク（「ＷＡＮ」）、インターネット、または、ルータ（図示せず）によって相互接続された３つの全ての組み合わせであっても良い通信ネットワーク８０２を示す。ルータは、可能な接続網を介して多くのコンピュータをリンクする中間通信ネットワーク装置であり、送信されたメッセージを受けるとともに、利用可能な経路を介してそれらのメッセージをそれらの正しい行き先へと転送する。異なるアーキテクチャおよびプロトコルに基づくネットワークを含む相互接続されたネットワークの組において、ルータは、メッセージを一方から他方へと送ることができるネットワーク間のリンクとしての機能を果たす。１つのネットワーク内の通信リンクは一般にツイストペア光ファイバまたは同軸ケーブルを含んでおり、一方、ネットワーク間の通信リンクは、アナログ電話線、Ｔ１、Ｔ２、Ｔ３、Ｔ４を含む完全または部分専用デジタルライン、デジタル総合サービス網（ＩＳＤＮ）、デジタル加入者線（ＤＳＬ）、ＷｉＦｉ、ＷＩＭＡＸ、ＧＰＲＳ、ＣＤＭＡ、ＴＤＭＡ、ＴＳＭなどの無線リンク、前記技術または将来の技術の混成体、または、当業者に公知の他の通信リンクを利用しても良い。通信ネットワーク８０２への通信は、クライアントコンピュータ８１０に関連付けられたインタフェースユニットによることが好ましく、このインタフェースユニットはリモートコンピュータ（図示せず）であっても良い。

また、コンピュータおよび他の電子機器は、モデムおよび一時的な電話リンクを介して通信ネットワークに遠隔的に接続することができる。ＷＡＮ、ＬＡＮ、ルータの数は、任意に増減されても良く、この発明の思想または範囲とは無関係である。

したがって、そのような相互接続された膨大な数のネットワーク、コンピュータ、ルータからインターネット自体が形成されても良いことは言うまでもない。一般に、用語「インターネット」とは、互いに通信するために送信制御プロトコル／インターネットプロトコル（「ＴＣＰ／ＩＰ」）および他のパケットベースのプロトコルを使用するコンピュータ、ルータ、ゲートウェイ、ネットワークの世界規模の集合体のことである。本発明の一実施形態は、本発明の思想または範囲から逸脱することなくインターネットを介して実施されても良い。また、本発明を具現化するプロセスは、本発明の思想または範囲から逸脱することなくピアツーピアまたはグリッドコンピュータアーキテクチャで実施されても良い。

図８は、通信ネットワーク８０２のための典型的な第１のサーバ８２０を示す。サーバ８２０は、第１の電子為替市場の業務をサポートするように動作しても良い。金融商品（例えば、株および債権など）の売買を伴う取引は、サーバ８２０の制御下、部分制御下、または、支援下で、通信ネットワーク８０２を介して行なわれても良い。同様に、第２のサーバ８３０、８３０は、金融商品の売り又は買いを伴う取引が行なわれるそれぞれの第２の電子為替市場の業務をサポートする。

当業者であれば分かるように、サーバ８２０、８３０は、図８に示されない多くの構成要素を含んでいても良い。しかしながら、図８は、本発明の実施形態を実行するための例示的な環境を開示するのに十分な構成要素を示す。サーバ８２０、８３０は、ネットワークインタフェースユニットを介して通信ネットワークに接続される。当業者であれば分かるように、ネットワークインタフェースユニットは、サーバ８２０、８３０を通信ネットワーク６００に接続するために必要な回路を含んでおり、ＴＣＰ／ＩＰプロトコルなどの様々な通信プロトコルと共に使用できるように構成されている。一般に、ネットワークインタフェースユニットはサーバ内に収容されるカードである。

また、サーバ８２０、８３０は、中央処理ユニット、ビデオディスプレイアダプタ、マスメモリを含むこともでき、これらは全てバスを介して接続される。マスメモリとしては、一般に、ランダムアクセスメモリ（「ＲＡＭ」）、読み出し専用メモリ（「ＲＯＭ」）、１つ以上の永久大容量記憶装置、例えば、ハードディスクドライブ、テープドライブ、光学式ドライブ、及び／又は、フロッピディスクドライブが挙げられる。マスメモリは、サーバ８２０、８３０の動作を制御するオペレーティングシステムを記憶する。また、サーバの低レベル動作を制御するために基本入出力システム（「ＢＩＯＳ」）も設けられる。ハードディスクドライブは、特にアプリケーションプログラム、データベース、プログラムデータを記憶するためにサーバ８２０、８３０により利用される。

マスメモリは、コンピュータ可読命令、データ構造、プログラムモジュール、または、他のデータなどの情報を記憶するための任意の方法または技術で実施できる揮発性および不揮発性の取り外し可能および取り外し不能な媒体を含んでいても良い。コンピュータ記憶媒体の例としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または、所望の情報を記憶するために使用でき且つコンピュータ装置によってアクセスできる任意の他の媒体が挙げられる。

また、マスメモリは、ウェブサイトを提供するためのデータおよびプログラムコードを記憶しても良い。より具体的には、マスメモリは、ＷＷＷサーバアプリケーション、電子メールサーバアプリケーション、プログラムを含むがこれらに限定されないアプリケーションを記憶しても良い。ＷＷＷサーバアプリケーションは、サーバ８２０、８３０によって実行されるときに前述したロジックの実行を含むブラウザ表示を形成するコンピュータ実行可能命令を含む。サーバ８２０、８３０は、ＪＡＶＡ（登録商標）仮想機械、電子メールを送受信するためのＳＭＴＰハンドラアプリケーション、ＨＴＴＰ要求を受信して手渡すＨＴＴＰハンドラアプリケーション、および、安全な接続を扱うためのＨＴＴＰＳハンドラアプリケーションを含んでいても良い。また、ＨＴＴＰＳハンドラアプリケーションは、電子メールなどの機密情報を安全な方法で送受信するために外部のセキュリティアプリケーションとの通信において使用されても良い。

クライアントコンピュータ８１０は、中央処理ユニット（ＣＰＵ）と、ビデオディスプレイアダプタと、メモリとを含む。メモリとしては、一般に、ＲＡＭ、ＲＯＭ、永久大容量記憶装置、例えばディスクドライブが挙げられる。メモリは、オペレーティングシステム、ＢＩＯＳ、クライアントコンピュータの動作を制御するためのプログラムを記憶する。また、メモリには、本発明の実施形態を実行するための固有のクライアントソフトウェアをロードすることができる。これらの構成要素は、フロッピディスクドライブ、ＣＤ−ＲＯＭ／ＤＶＤ−ＲＯＭなどの光学式ドライブ、及び／又は、ハードディスクドライブなどのコンピュータ可読媒体に関連付けられたドライブ機構を使用して、コンピュータ可読媒体に記憶されてクライアントコンピュータ８１０のメモリにロードされても良いことは言うまでもない。マウス、キーボードまたは他の入力装置から入力を受けるために、入力／出力インタフェースを設けることもできる。メモリ、ネットワークインタフェースユニット、ビデオディスプレイアダプタ、入力／出力インタフェースは全て、バスを介して処理ユニットに接続されている。他の周辺機器が同様の態様で処理ユニットに接続されても良い。例えば、アクセスされたデータや計算されたスコアなどを表示するために、端末にインタフェースが設けられても良い。本発明の実施形態を実施するための操作命令を含む実行可能プログラムコードは、いずれかのサーバ８２０、８３０またはクライアントコンピュータ８１０に存在することができる。

クライアントマシンは、ワークステーション、デスクトップコンピュータ、ラップトップコンピュータ、ノートパソコン、シンクライアント、および、端末などの汎用計算機から、携帯端末（ＰＤＡ）またはスマートフォンなどのあまり一般的ではない装置、特殊目的装置に及ぶ多種多様な電子機器のうちの任意の１つとして具現化できることは言うまでもない。クライアントコンピュータの物理形態に関係なく、クライアントコンピュータは、ユーザとやりとりできるように、ローカルメモリ、プロセッサ、および、入力／出力能力を含む。

当業者であれば分かるように、クライアントコンピュータ８１０は、図８に示される構成要素よりも多くの構成要素を含んでいても良い。しかしながら、本発明の実施形態を実行するための例示的な環境を開示するためにほぼ従来の構成要素が示される必要はない。

図２はＩＣＥシステム１００のコンポーネントアーキテクチャの例図である。ＩＣＥシステム１００の全ての構成要素（内部為替取引所１４０、実行接続部２０５、２１０、２１５、２２０、および、注文ルータ２７５）はＩＣＥシステム１００のユーザに対して同じ統合ＡＰＩ２５５を与え、そのため、ユーザは、任意の他の構成要素と同じ任意の構成要素により取引できる。

図２に示されるこのシステムアーキテクチャは、ＩＣＥ ＡＰＩ ２５５を使用して、内部および外部のソースの両方からのＩＣＥへの接続をサポートする。ＩＣＥにアクセスするクライアントは、トレーダーＧＵＩ２６０、自動取引システム、取引エージェント、潜在的販売スタッフ、顧客、または、クライアントがＩＣＥアクセスを行なう中間トレーディングデスク外の加入者を含む。ＩＣＥは、以下の構成要素、すなわち、連結為替・価格フィード２６５と、内部為替取引所２８０と、注文ルータ２７５と、為替取引所／ブローカー実行・価格設定コネクタ２０５、２１０、２１５、２２０と、ＩＣＥ統合ＡＰＩ ２５５と、取引管理統合（ポストトレード２４５およびセキュリティマスター２５０）、注文ルータ戦略セキュリティと、スケーラビリティと、フォールト・トレランスと、システム監視機能とを含む。

注文は、注文ルータ２７５および内部為替取引所２８０の内部での注文の処理・評価方法を制御する注文条件を伴うことができる。連結価格フィード２６５は、外部為替取引所およびブローカーおよび現在の内部為替取引所注文ブックのそれぞれからの生の価格データを含む。価格フィード２６５またはフィードデータの一部（例えば、内部為替取引所価格）は、取引ＧＵＩ、自動取引モデル、取引エージェント、注文ルータ戦略で使用することができ、あるいは、外部で公表することができる。

内部為替取引所２８０により、特定のユーザに対する様々な注文ブックの視認性を制限する「個人市場」を規定することができる。連結価格フィード２６５は各個人市場毎に存在することができる。

内部為替取引所２８０は、取引されたインスツルメント毎に注文ブックで認可されるユーザにより内部（すなわち、局所的には、証券会社内、商社内、投資信託会社内など）でリストアップされる買呼値／売呼値および買い／売りを管理する従来の買呼値／売呼値取引所またはワークアップ取引所である。市場の同じ曲面で同じ価格で受けられた注文は、時間優先（各注文が為替取引所によって受けられた時間）と注文条件との組み合わせに基づいて執行優先状態に置かれる。

注文ブック内の逆の注文がマッチする（買呼値／売呼値モデルで）と、マッチする規模は、マッチの各サイド毎に執行されていると見なされる。１つの注文が他のマッチする注文よりも大きい規模を含む場合には、部分的な執行が可能である。クロス売買サイドの注文が優先して執行される。注文マッチングのこの技術は凍結市場を許容しない。あるいは、ワークアップモデルでは、買呼値および売呼値が同じクロス売買価格で存在し得る。クロス売買価格での買い又は売りは、取引を開始してクロス売買買呼値または売呼値に抗して執行しなければならない。

全てのクロス売買価格は一般に最良の価格で執行され、これにより、価格改善が起こり得る。クロス売買注文の価格が市場の反対のサイドで最良価格から外れている場合、市場の反対のサイドからの最良価格が最初に執行される。

内部為替取引所２８０は、選択されたユーザに対してだけ見える「個人市場」２８５、２９０の概念をサポートする。個人市場２８５、２９０は、「親」個人市場２８５、２９０で見える全ての注文を表示するために他の個人市場２８５、２９０から「引き継いで」も良い。それらが特定の個人市場で利用できる価格を有することを定める注文だけをその市場およびその任意の「子」市場で取引することができる。トップレベル個人市場は、全てのユーザが見ることができる「公設市場」と見なされる。

注文条件により、様々な個人市場２８５、２９０内の注文の利用可能性を注文毎に設定することができる。内部為替取引所２８０へ送られる各注文は、注文が取引可能で且つ各個人市場毎に見える価格及び／又は隠れた価格である個人市場２８５、２９０を規定しても良い。見える価格は、その個人市場２８５、２９０および全ての子個人市場２８５、２９０における注文ブック内で表示されるべき価格である。隠れた価格は、執行できるより良い価格を注文が定めることができるようにする。この隠れた価格は、個人市場２８５、２９０における注文ブック内に表示されない。

隠れ注文価格は、所定の個人市場のための内部為替取引所の価格フィード２６５に表示されないが、クロス売買されるときに通常の見える価格のようにマッチできる。隠れた価格は、可視注文（visible order）の後、所与の価格における執行優先状態に置かれる。可視注文が隠れ注文（hidden order）と同じサイドおよび価格で成される場合には、可視注文が執行優先状態の隠れ注文よりも先に進む。

子市場において注文が見える価格または隠れた価格を規定する場合、その規定は親規定に優先する。例えば、公設市場で１０ＭＭにおいて９９−１２＋買呼値が存在する場合、全ての子個人市場は１２＋買呼値が見える。しかしながら、子市場で１０ＭＭにおいて９９−１２６買呼値として取引するように注文が規定する場合には、その買呼値を、指定された市場およびその全ての子市場において代わりに示すことができる。同様に、隠れ注文は、子市場へと伝えられる。９９−１２６買呼値が子市場において９９−１３０の隠れた価格を有する場合、その市場は、９９−１２６買呼値を明白に示すが、その子市場に対して内部で隠れた買呼値として９９−１３０買呼値をリストアップし、９９−１３０以下の価格をもって売りをマッチさせることができる。

他の実施形態では、所与のユーザに対してだけ示される許可を各注文に与えることができる１つの市場を使用できる。これは、個人市場と同じ結末をもたらす。また、内部為替取引所２８０は、内部為替取引所２８０内での注文の動き変えるために注文に付随されても良い多くの他の条件をサポートする。これらの条件は、内部為替取引所の設定により有効にされ或いは無効にされても良い。以下の条件の全てが連結為替取引所のユーザによってアクセスできる必要はない。これは、連結為替取引所２９５が以下の条件の一部を使用して内部業務を行なうからである。

内部為替取引所の条件は、以下を含んでいても良い。
１．条件付注文（conditional order）。これらは、執行する可能性が高いが、そうすることを保証しない注文である。これらの注文は、一般に、外部市場でも成されたが内部で執行される前に内部でキャンセルされる（内部および外部の両方で注文が果たされないようにするため）注文である。条件付注文は、その条件（例えば、外部注文のキャンセル）が満たされるまでマッチするクロス売買注文を執行しない。条件付注文は、執行優先状態の隠れ注文の後で成される。この執行形態は、条件付注文がそれを執行できるクロス売買注文を特定し且つその条件を処理し始めた場合であっても依然として変わらない。他の注文が条件付注文と同じサイドで且つ同じ価格に到達する場合には、新たな注文が条件付注文よりも先に進むことができ、それにより、クロス売買注文が執行され、条件付注文が執行されないままとなる（その外部注文を再び出す必要がある）。

２．参考注文（indicative order）。注文は、内部為替取引所２８０で「参考」となるようにリストアップされても良く、このことは、それらの注文を実際には執行できないことを意味している。参考注文は、執行注文状態で且つ特定の「参考の」指標を用いて最後に個人市場の注文ブック中に示される。これらの注文は、特定のトレーダーが取引したがっているが即座に執行したがっていない規模が存在する指標をトレーダーに対して与える。参考注文は、執行優先状態の条件付注文の後で成される。いつでも、参考注文が注文へと変えられても良く、その時点で、参考注文は任意の他の定期的な注文のように振舞う。参考注文は、１つの注文が外部でリストアップされ且つその注文がそれ自体内部で執行される前に幾つかの外部基準を満たすのを待っている間、内部為替取引所で「参考の」価格／規模を表示するために使用できる。また、参考注文の使用は、条件付注文を実施するために用いることができる。

３．即時執行注文（fill or kill order）。これらの注文は、直ちにクロス売買されてそれらの発注規模まで執行することができる。任意の執行されていない規模は、直ちにキャンセルされ、受動的注文として注文ブックに記されない。即時執行注文は最小規模を有していても良い。すなわち、とにかく執行されるべき注文に関して執行されなくてはならない所与の規模を意味する。最小規模を執行できない場合、注文は決して注文ブックに記されない。

４．最小規模注文。これらの注文は、注文がとにかく執行されるべき場合に直ちに執行される必要がある最小執行規模を有する。これらの注文は、直ちにクロス売買されてそれらの最小規模を執行し、あるいは、直ちにキャンセルされて決して注文ブックに記されない。最小規模注文の最小規模が執行されるが注文規模全体が執行されない場合には、残りの規模が受動的注文として注文ブックに記される。

本発明は、前述した注文タイプをサポートするためだけに限定されない。一般に知られるグッドツーキャンセル（good-to-cancel）注文、隠れ注文、執行及び取り消し(fill and kill）注文などの他の注文タイプが全て内部為替取引所２８０でサポートできる。

１つの実施形態において、内部為替取引システム１００は、その取引に対して手数料を加えることができる。手数料は、設定で変えられる手数料スケジュールによって設定することができる。流動資産プロバイダおよび流動資産受取人に関して、また、取引ユーザ別に、異なる手数料を設定することができる（受動的注文またはアクティブな注文）。手数料は、取引価格に含めることができ、あるいは、別個の手数料として取引記録中に取引価格とは別個に記録することができる。

内部為替取引システム１００は、各個人市場２８５、２９０毎にマーケットピクチャ（market picture）または注文ブックを作成することができる。個人市場２８５、２９０がどのように機能するかの一例を示すため、図３に示される個人市場の階層を想定されたい。個人市場Ｂ ３２０は、公設市場Ａ ３２０から引き継いでおり、したがって、公設市場Ａ ３１０の子である。公設市場Ａ ３１０で成された全ての注文を個人市場Ｂ ３２０で示すことができる（公設市場Ａ ３１０での注文がその個人市場Ｂ ３２０の価格／規模を明らかに無視しなければ）。

以下の表１に示される注文は、指示された価格、規模、条件で且つ連続的時間順序で内部為替取引所２８０により受けられる。以下の表２−４は、各個人市場２８５、２９０で構成される結果として得られる注文ブックを示す。

注文ブックでは、以下の表記、すなわち、ＴｒａｄａｂｌｅＳｉｚｅ，ＵｎａｖａｉｌＳｉｚｅ（１ｓｔＯｒｄｅｒ＃：１ｓｔＯｒｄｅｒＳｉｚｅ，２ｎｄＯｒｄｅｒ＃：２ｎｄＯｒｄｅｒＳｉｚｅ，．．．）が規模欄で使用される。この場合、ＴｒａｄａｂｌｅＳｉｚｅは、所与の価格で個人市場のユーザにより取引ができて見える全体の規模を示しており、ＵｎａｖａｉｌＳｉｚｅは、それが参考または条件付であることから所与の価格で利用することができない全体の規模を示しており、また、括弧の中の数は、所与の価格で取引可能で且つ利用できない全体の規模を作り上げる個々の注文を示す。

以下の文字は、ナンバー（＃）記号に続く可能なパラメータである。注文＃の後の「Ｈ」は、隠れ注文を表わしている。この注文は、注文ブック中にリストアップされるが、内部為替取引所２８０の任意のユーザには見えない。所与の価格レベルの全ての注文が隠されている場合には、そのレベルが表中に斜字体で示される。これは、その価格レベルで執行できる注文が注文ブック中に存在する場合であっても所与の価格レベルがユーザに見えないことを示す。

注文＃の後の「Ｕ」は、利用できない注文を表わしている。この注文は、注文ブックにリストアップされ、内部為替取引所２８０のユーザに見えるが、ユーザはその規模に抗して執行することができない。

注文＃の後の「Ｃ」は、条件付注文または参考注文を表わしている。この注文は、外部条件（external condition）が満たされる必要があり（例えば、当該注文が外部為替取引所１０５、１１０、１１５、１２０から引き寄せられる）、あるいは、それが内部で執行される前に確約（参考ではない）できる。

なお、示された例において、可視注文は、隠れ注文（個人市場Ｂ ３２０およびＣ ３３０では、注文９が注文６よりも先である）および条件付注文（個人市場Ｃ ３３０では、注文８が注文７よりも先である）に優先して先に執行される状態に置かれる。

図２を再び参照すると、注文ルータ（order router）２７５は、内部為替取引所２８０および様々な外部ブローカー／為替取引所２０５、２１０、２１５、２２０の間でＩＣＥ１４０を用いて発注される注文を割り当てるために使用される。注文ルータ２７５は、それが任意の他のＩＣＥ１００要素（内部為替取引所２８０または外部為替取引所またはブローカー２０５、２１０、２１５、２２０への接続性）が成し得るような方式に抗して取引され得るようにＩＣＥ ＡＰＩ ２５５を実施し、それにより、１つの構成要素を使用する取引から他の構成要素を使用する取引へとユーザプログラムを変えることが途切れなく行なわれる。

ルーティングストラテジは、ルーティングストラテジインタフェースで実施し且つユーザ要求に応じて数量を動かすためのロジックを与える実行可能コードとしてＩＣＥ１００内に含められる（ここで、「ルーティングストラテジ」とは、ルーティングストラテジを実施するコンピュータモジュールのことであり、ルーティングストラテジは、取り扱われるインスツルメント（instrument）のための発注方法に関する概念である）。ルーティングストラテジは、内在する為替取引に関する数量の割り当てを取り扱うとともに、動かされた数量の状態の変化を反映する上向き事象を形成する。実行コネクタ２０５、２１０、２１５、２２０は、内部為替取引所２８０または他の取引所／ブローカー１０５、１１０、１１５、１２０への接続部である。これらの接続部はＩＣＥ ＡＰＩ ２５５を実施する。ＩＣＥシステム１００は、外部で注文して連結価格フィード２６５における価格データを受けるために各外部ブローカー／為替取引所１０５、１１０、１１５、１２０への接続を行ない、あるいは、様々な媒介（第三者接続ツール、第三者ホストサービス、ＦＩＸプロトコルなどの共通ＡＰＩ）により接続することができる。注文は、取引実行のためのブロックの規模または価格要素に関連する一連のブロック規模を示す数量要素を含む。一連のブロック規模は、ユーザによって提示されたルーティングストラテジの一部である条件列で提示され予め定められた基準のパラメータ値にしたがった価格構成をもって実施される。また、注文は、ユーザにより提示されたルーティングストラテジにしたがって実施される成り行き注文、売呼値注文、または、複数の統一小売価格を含むことができる価格要素を含む。

数量を動かすための注文ルータ２７５への要求は、マスター注文と称される注文としてフォーマットされる。マスター注文４１０は１つのルーティングストラテジによって所有され制御される。ここで、ルーティングストラテジは注文の発生/消滅（lifecycle）の全ての態様を取り扱う。マスター注文の状態は、所有するルーティングストラテジの方策に制約される内在する実行コネクタ２０５、２１０、２１５、２２０による注文によって決定される。マスター注文は、注文ルータによって所有されるＭｋｔＤｅｆｉｎｉｔｉｏｎオブジェクトに関連付けられるＭｋｔＯｒｄｅｒ ＴＯＣオブジェクトとして表わされる。

図４は、注文ルータにおける典型的なマスター注文関係を示す。１つのマスター注文４１０は注文ルータへ提出され、ルーティングストラテジによって３つの下位の為替取引所へと発注される。異なる為替取引所において、動かされた数量は、異なる数の為替注文へと分割される。スレーブ注文４６０は、現在の為替注文を有しておらず、下位の為替取引所から追加の確認を待っている。ルーティングストラテジは、内在する為替取引コネクタ２０５、２１０、２１５、２２０によりスレーブ注文４２０、４６０、４７０をすることによってマスター注文を機能させるための要求を満たす能力を有する。これらのスレーブ注文は、１つのマスター注文によって所有されるとともに、内在する為替取引コネクタのＭｋｔＤｅｆｉｎｉｔｉｏｎに基づくＭｋｔＯｒｄｅｒオブジェクトとして表わされる。スレーブ注文４２０、４６０、４７０は、ＭｋｔＯｒｄｅｒオブジェクトにおける「ＭａｓｔｅｒＯｒｄｅｒ」フィールドを介してそれらの対応するマスター注文４１０を参照する。マスター注文４１０およびスレーブ注文４２０、４６０、４７０はワーキング注文と称される。ワーキング注文は、所与の為替取引コネクタにより動かされる数量を表わす概略注文であり、その数量が内在する為替取引所でとる形態とは無関係に内在する為替取引コネクタにより要求される数量に対して安定した取り扱いを行なう。ワーキング注文は、「Ｗ」の「ＯｒｄｅｒＴｙｐｅ」フィールドを伴うＭｋｔＯｒｄｅｒオブジェクトとして表わされる。

為替取引注文は、為替取引コネクタによって分かる所与の為替取引に関する実際の数量を表わす−なお、多くの理由により、ワーキング注文から為替取引注文までの関係が一対一である必要はない。多くの為替取引においては、ワーキング注文要求を効率的に満たすため、数量は、内在する為替取引所での幾つかの注文へと分割される。ワーキング注文に関する数量を動かすために為替取引注文が形成される場合、為替取引注文オブジェクト「ＰａｒｅｎｔＯｒｄｅｒ」フィールドは、それがリンクされているワーキング注文を指し示す。為替取引注文は、「Ｅ」の「ＯｒｄｅｒＴｙｐｅ」を伴うＭｋｔＯｒｄｅｒオブジェクトとして表わされる。

ＩＣＥ ＡＰＩ ２５５を使用して構築された注文ルータ２７５は、ＩＣＥシステム２４０内の他のオブジェクトに対して同様のインタフェースを与える。すなわち、注文ルータは、注文を形成して動かすための手続きベースのインタフェースを提供するとともに、事象に応じてオブジェクトを形成して更新する。これらの注文および処理オブジェクトは、様々なメッセージング方式を用いてユーザに送り戻すことができる。注文ルータ２７５で動かされた注文、すなわち、ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ、ＷｏｒｋＯｒｄｅｒ、ＲｅｓｅｔＷｏｒｋｉｎｇＯｒｄｅｒは、ワーキング注文手続きインタフェースによって操作される。注文ルータ２７５は、ＷｏｒｋＯｒｄｅｒ手続きコールに添えられるテキスト条件の形態を成す更なるルーティングストラテジ特有の引数を受け入れる。その許容値は、マスター注文を動かす（機能させる）ために使用されるルーティングストラテジによって決まる。

ユーザからの要求および事象の処理において、注文ルータ２７５は、注文ルータ２７５で動かされるマスター注文に対応するＭｋｔＯｄｅｒオブジェクトを形成することができ、このオブジェクトは、ルーティングストラテジにより、内在するスレーブ注文からの事象に関して更新できる。また、マスター注文の状態を変える事象に関してマスター注文オブジェクトを参照するＭｋｔＴｒａｎｓａｃｔｉｏｎオブジェクトが公開される。消費者は、マスター注文オブジェクトの最新情報を聞くことにより事象の集合効果を見ることができ、あるいは、内在するスレーブワーキング注文または為替取引注文オブジェクトにおける事象を見ることにより更に詳しい情報を得ることができる。

数量は、ＭａｋｅＭａｒｋｅｔまたはＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒへのユーザコールによって形成される１つのワーキング注文を介して注文ルータで動かされ、それにより、マスター注文の不変パラメータ、すなわち、市場のサイド（買呼値／売呼値）、注文の価格、注文を動かすために使用されるルーティングストラテジ（「戦略」条件など）が指定される。

これらのパラメータは、異なる価格で注文ルータ２７５により数量を動かすためにマスター注文４１０にとって欠かせないものであり、したがって、ＭａｋｅＭａｒｋｅｔまたはＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒへの新たなコールを行なって、新たなＭｋｔＯｒｄｅｒオブジェクトを形成しなければならない。

マスター注文４１０の形成後、その規模および現在のルーティングパラメータは、ＭａｋｅＭａｒｋｅｔへの連続コール（同じ戦略を用いた同じサイドおよび価格で）により或いはＷｏｒｋＯｄｅｒへのコールにより変えることができる。これらのコールは、現在のルーティング属性を変える（例えば、ルーティング場所の許容リストを変える）ことができ、あるいは、注文の規模またはアクションを変えることができる（能動対受動の量）。

マスター注文４１０がもはやユーザによって動かされない（完全に執行されるようになり或いは規模が０まで動かされる）場合には、注文がリセットされる。ワーキング注文４２０のリセットは、執行される規模をゼロまで減少させるとともに、全てのＭｋｔＴｒａｎｓａｃｔｉｏｎをそのワーキング注文から新たに形成された（閉じられた）履歴ワーキング注文ＭｋｔＯｒｄｅｒオブジェクトへと動かす。リセットは、注文がゼロのオープン規模に達する際の自動リセットに加え、ＲｅｓｅｔＷｏｒｋｉｎｇＯｒｄｅｒへのコールによって明確に行なうことができる。

以下の例は、注文ルータ２７５で数量を動かすＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ・ＷｏｒｋＯｄｅｒ手続きインタフェースを使用する手続きコールの組を示す。コールのこの組（適切なオブジェクト識別子が置き換えられる）は、注文ルータ２７５を使用して数量を動かすためのアプリケーションへと挿入できる。これらのコール自体は、任意の数の良く知られた遠隔手続きコール概念を使用して実施できるが、理論上、これらは以下のように見えると考えられても良い。
ＰＲＯＣ ＯｒｄｅｒＲｏｕｔｅｒ：：ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ（「０００００００００００００００００００１」，９９．９６，「Ｂ」，「Ｓｔｒａｔｅｇｙ＝Ｄｅｆａｕｌｔ）
ＰＲＯＣ ＯｒｄｅｒＲｏｕｔｅｒ：：ＷｏｒｋＯｒｄｅｒ（「０００００００００００００００００００２」，０，２０，「Ａ」，
「ＥｘｔｅｒｎａｌＭａｒｋｅｔｓ＝Ｂｒｏｋｅｒ１，Ｂｒｏｋｅｒ２；ＩｎｔｅｒｎａｌＳｈｏｗ＝Ｉｎｄｉｃａｔｉｖｅ」）

最初のコールは、デフォルトルーティングストラテジを使用してオブジェクト０００００００００００００００００００１により表わされるインスツルメントに関する新たなワーキング注文を形成し、それにより、新たなワーキング注文ブジェクト０００００００００００００００００００２が戻される。そのワーキング注文オブジェクトは、その後、内部為替取引所で及びＢｒｏｋｅｒ１外部市場とＢｒｏｋｅｒ２外部市場との間で数量を動かすために使用される。ＷｏｒｋＯｒｄｅｒへの連続コールは、現在のルーティングパラメータおよびＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒコール中に形成されたワーキング注文の規模を変更する。クライアントがこのワーキング注文を使用して数量を動かすことにもはや興味をもたない場合、任意のオープン数量を処分するために、ゼロの作業規模をもってＷｏｒｋＯｒｄｅｒコールを提示することができる。

手続きコールに応じて、注文ルータ２７５は、それが事象に応じて注文の現在の状態と共に維持するマスター注文ＭｋｔＯｒｄｅｒオブジェクトを形成する。個々のルーティングストラテジは、これらのオブジェクトが事象および要求に応じて更新される方法を決定づけるが、殆どのルーティングストラテジは、マスター注文オブジェクトを常に更新されたままにしておき、それにより、全てのＭｋｔＴｒａｎｓａｃｔｉｏｎをそのＭｋｔＯｒｄｅｒオブジェクトに反映させる。また、ルーティングストラテジは、マスター注文に関する要求に応じてマスター注文におけるＭｋｔＴｒａｎｓａｃｔｉｏｎｓとして事象を公開するとともに、内在するスレーブ注文４２０、４６０、４７０における事象を公開する。

ルーティングストラテジは、マスター注文におけるＭｋｔＴｒａｎｓａｃｔｉｏｎｓの以下のタイプを公開する能力を有する。

１．ユーザ作業要求。ユーザ作業要求がなされると、現在の作業要求の状態を反映するマスター注文に対してＭｋｔＴｒａｎｓａｃｔｉｏｎが加えられる。

２．執行。内在するスレーブ注文における執行は、ルーティングストラテジを介してマスター注文４１０へ反映される。なお、スレーブ注文４２０、４６０、４７０における複数の執行は、マスター注文４１０における１つの執行として要約されても良い。

３．エラー。マスター注文４１０の処理中のエラーは、エラーを示すＴＯＣＭｋｔＴｒａｎｓａｃｔｉｏｎオブジェクトとして公開される。

４．リセット。任意の手動または自動のリセットは、マスター注文４１０におけるリセットＭｋｔＴｒａｎｓａｃｔｉｏｎにより達成することができる。

注文ルータ２７５は、標準的なＩＣＥ ＡＰＩ ２５５手続きインタフェースを提供して、その環境内への標準的なオブジェクトまたはメッセージを公開する。したがって、ネットワークアプリケーションは、注文ルータ２７５およびそのオブジェクトとやりとりすることができる。また、特定のプラットフォームにおいて、為替取引コネクタ２０５、２１０、２１５、２２０は、言語ネイティブオブジェクトを与えるネイティブライブラリと注文ルータ２７５およびオブジェクトとやりとりするためのインタフェースとによってアクセス可能であってもよい。このライブラリは、内在するリターンオブジェクトの上のあるレベルの抽出・翻訳時タイプの安全性を与えるとともに、手続きコールのための更なるエラーチェック・処理を行なう。

図５は、内在する為替接続部により注文するために注文ルータ内の異なる戦略とやりとりする一方で、内部為替取引所を介して戦略にわたって内部流動資産を共有できる、本発明の一実施形態に係る注文ルータ５２０の複数のエンドユーザを示す。注文ルータ５２０は、幾つかの更なる管理方法を用いてワーキング注文手続きインタフェースを提供する。なお、注文ルータ５２０は、為替取引注文を実施せず、したがって、為替取引注文手続きインタフェース（ＡｄｄＯｒｄｅｒ手続き、ＭｏｄｉｆｙＯｒｄｅｒ手続き、および、ＣａｎｃｅｌＯｒｄｅｒ手続き）を有していない。

ＭａｋｅＭａｒｋｅｔ手続きコールは、ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ手続きコールとＷｏｒｋＯｄｅｒ手続きコールとの組み合わせである高レベルの手続きコールである。ＭａｋｅＭａｒｋｅｔ手続きコールは、各ユーザ毎に所与の価格およびサイドに関して１つのマスター注文を形成して操作する−同じユーザにおける同じサイドおよび価格に関する全てのＭａｋｅＭａｒｋｅｔコールは、注文ルータ５２０における同じマスター注文を操作し、それにより、その規模および作業条件が変えられ、それらが現在の要求と一致される。

標準的なＭａｋｅＭａｒｋｅｔ手続きコール引数に加えて、一組の条件を指定することができる。これらの条件は、この注文を発注するために使用されるべきルーティングストラテジと、注文を動かすためのそのルーティングストラテジの任意の更なるパラメータとを指定する。空の条件列は、最初のコールではデフォルト条件として解釈され、その後のコールでは現在の戦略が不変のままとなることを求める。

デフォルトルーティングストラテジ５２５を使用するＭａｋｅＭａｒｋｅｔ手続きコールの一例は以下のように見える。
ＯｒｄｅｒＲｏｕｔｅｒ：：ＭａｋｅＭａｒｋｅｔ（「０００００００００００００００００００１」，１３，９９．０１５６２５，「Ｐ」，
「Ｏ」，「Ｓｔｒａｔｅｇｙ＝Ｄｅｆａｕｌｔ；ＥｘｔｅｒｎａｌＭａｒｋｅｔｓ＝Ｂｒｏｋｅｒ１」）

この例において、０００００００００００００００００００１は１つのインスツルメントの識別子である。このＭａｋｅＭａｒｋｅｔコールは、条件列「ＥｘｔｅｒｎａｌＰｒｉｏｒｉｔｙ＝Ｂｒｏｋｅｒ１」を与えることができるデフォルトルーティングストラテジ５２５を使用して注文ルータ５２０におけるマスター注文５３０、５３２、５３５を形成する。注文は、デフォルトルーティングストラテジ５２５によって解釈される価格９９．０１５６２の規模１３における受動的な売呼値である。

ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒへのコールは、ワーキング注文の発生/消滅を始めるとともに、注文の全ての不変パラメータを含む。これらのパラメータは、ＷｏｒｋＯｒｄｅｒへのその後のコールによって変えることができない。標準的なＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ引数に加えて、この注文におけるルーティングストラテジを指定する更なるテキスト条件が指定されなければならない。注文ルータ５２０で１つのデフォルトルーティングストラテジ５２５だけがインスタンス化される標準的な設定では、この条件を省くことができる−「Ｓｔｒａｔｅｇｙ＝ＤｅｆａｕｌｔＢｒｏｋｅｒ」になると想定される。

更なる戦略特有の条件をＣｒｅａｔｅＷｏｒｋｉｎｇＯｄｅｒコールに加えることができ、この条件は、その後、ＷｏｒｋＯｒｄｅｒへのその後のコールによって無効にされなければ依然として有効である。

ＣｒｅａｔＷｏｒｋｉｎｇＯｒｄｅｒ手続きコールは、状態コードおよびメモフィールドと共に、新たに形成されたワーキング注文を戻す。ＣｒｅａｔＷｏｒｋｉｎｇＯｒｄｅｒコールの後、新たに形成されたワーキング注文は、オープン規模を有しておらず、実際に数量を動かすためのその後のＷｏｒｋＯｒｄｅｒコールに備えられる。

ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒによるマスター注文５３０、５３２、５３５の形成後、ＷｏｒｋＯｒｄｅｒ手続きコールは、注文の発生/消滅中の注文数量の操作を可能にし、それにより、内在するルーティングストラテジに合わせた規模、アクション、条件の変更が可能になる。ルーティングストラテジは、ＷｏｒｋＯｒｄｅｒコールのパラメータの変化を内在する市場で効率的に生かすように構築されなければならない−実行効率および待ち行列位置などのファクタが保たれるような内在する市場における１つの状態から他の状態への移行を特定のルーティングストラテジが効果的に計算できると仮定すると、注文ルータ５２０のエンドユーザは、パラメータの変化をもってＷｏｒｋＯｒｄｅｒ手続きコールを自由に行なうことができる。

ＲｅｓｅｔＷｏｒｋｉｎｇＯｒｄｅｒのコールは、マスター注文５３０、５３２、５３４の手動リセットを要求するための機構を与える。リセットが注文の執行数量をゼロまで動かし、それにより、作業数量が減じられ、マスター注文におけるオープン規模がリセットの前後で同じになる。また、マスター注文５３０、５３２、５３４における全ての処理が新たに形成された（閉じられるように形成される）履歴ワーキング注文へと移動されるとともに、１つのリセット処理が現在のワーキング注文（リセット後にこのマスター注文にリンクされる処理のみであっても良い）に対して加えられる。なお、マスター注文５３０、５３２、５３４におけるリセットは、内在するスレーブ注文に影響を与えない。

注文ルータ５２０は、厳密にはワーキング注文手続きインタフェースの一部ではないが、為替取引注文の代わりにマスター注文５３０、５３２、５３４で動作する標準的な為替取引ＣａｎｃｅｌＡｌｌおよびＣａｎｃｅｌＡｌｌＥｘｃｈａｎｇｅＯｒｄｅｒ手続きコールを実施する。これらの方法は、それらが他の為替取引コネクタで使用される際には、所与のユーザにおいて或いは所定のサイドで全てのマスター注文５３０、５３２、５３４をキャンセルするために使用できる。マスター注文のキャンセルは、その全てのスレーブ注文をキャンセルし、注文を０の規模まで動かすのに相当する。

標準的な為替取引コネクタワーキング注文手続きに加えて、注文ルータ５２０は、為替接続性に伴う問題または予期しないシステム故障などのファクタに起因して連結市場システムの状態に一貫性がないことが分かっている状況において使用される２つの更なる管理手続きをエクスポートする。

ＰａｎｉｃＷｏｒｋｉｎｇＯｒｄｅｒ手続きコールは、特定のマスター注文において管理上のパニックを引き起こす−それにより、マスター注文における事象の処理が一時中断され、内在する為替取引コネクタの全ての為替取引アダプタ５５０，５６０におけるマスター注文に関する全てのスレーブ注文が強制的にキャンセルされる。この管理上のパニックは、注文を処理するために使用される特定のルーティングストラテジとは無関係に扱われ、したがって、戦略における障害とは無関係である。注文においてパニックを引き起こすことはターミナル操作である−注文がゾンビとしてマークされ、全てのスレーブ注文がキャンセルされる。スレーブ注文キャンセルは、注文の終値の確認が内在する為替取引所から受けられるまで再び試みられる。パニック後、注文のためのルーティングストラテジは、注文における事象をもはや処理しない。

特定の戦略名をもって呼び出すことができるＰａｎｉｃＲｏｕｔｉｎｇＳｔｒａｔｅｇｙ手続きコールを用いて、よりグローバルなシャットダウンを達成することができる。つまり、全ての戦略でグローバルなパニックを引き起こす引数はない。戦略パニックを行なうと、戦略上の全ての注文は、それらで呼び出されるＰａｎｉｃＷｏｒｋｉｎｇＯｄｅｒを有する。また、戦略において新たな事象が許容されない−ＣｒｅａｔＷｏｒｋｉｎｇＯｒｄｅｒまたはＭａｋｅＭａｒｋｅｔによる新たな注文の要求は、エラー状態を伴って拒絶される。

注文ルータ５２０は、内在する為替取引ワーキング注文における事象およびユーザ要求に応じてＭｋｔＯｒｄｅｒオブジェクトおよびＭｋｔＴｒａｎｓａｃｔｉｏｎオブジェクトの状態を示すメッセージを公開する。注文ルータ手続きコールからのマスター注文５３０、５３２、５３４、５４２、５４５は、オープンＭｋｔＯｒｄｅｒオブジェクトの「ＭｋｔＤｅｆ」フィールドを見ることによって決定することができる−全ての注文ルータマスター注文５３０、５３２、５３４、５４２、５４５は、「ＯｒｄｅｒＲｏｕｔｅｒ」の「Ｓｏｕｒｃｅ」フィールドを有するＭｋｔＤｅｆｉｎｉｔｉｏｎオブジェクトを用いて形成される。同様に、マスター注文における処理は、それらをＭｋｔＴｒａｎｓａｃｔｉｏｎオブジェクトにおけるＭｋｔＯｒｄｅｒフィールドによって注文と相互参照することにより識別することができる。

注文ルータマスター注文オブジェクトは、その全ての処理（取引）からの注文の組み合わされた状態を反映する。この場合、ＭｋｔＯｒｄｅｒ状態は、注文を処理するルーティングストラテジによって予約された執行および全ての完了したユーザ要求から要約される。ルーティングストラテジ５２５、５４０は、内在するスレーブ注文においてそれが数量をどのように管理するかに関して制約されず、したがって、任意の時点で、マスター注文オブジェクトにおける数量が、ＭａｋｅＭａｒｋｅｔまたはＷｏｒｋＯｒｄｅｒコールからのユーザ要求された数量に対応しない場合がある。例えば、多足インスツルメントまたは過剰執行の危険を与えるインスツルメントにおける戦略において、内在するスレーブ注文で動かされる数量は、マスター注文と同じインスツルメントに基づかない場合があり、当初の要求に直接に匹敵しない。注文ルータ５２０におけるマスター注文に対応するＭｋｔＯｒｄｅｒオブジェクトは、現在の要求数量およびどの程度執行されたかに関する良好な表示を与える−しかし、その数量がどのように動かされるのかに関する見通しを与えない。

注文ルータマスター注文５３０、５３２、５３４は、現在の要求数量およびその数量を満たすようにした進行状況を反映させることにより、自動取引エージェントおよびグラフィック取引アプリケーションの高レベル要約画面において役に立つ。同様に、マスター注文ＴＯＣオブジェクトを参照して公開されるＭｋｔＴｒａｎｓａｃｔｉｏｎｓは、内在するスレーブ注文における事象の高レベルの反映である。

マスター注文の状態に関する多大な情報は、内在するスレーブ注文の状態の中に含められる。スレーブ注文は、ＩＣＥシステム１００内の他の為替取引コネクタにおいて動かされる数量および注文である。スレーブ注文は、所望のマスター注文ＴＯＣオブジェクトの「ＭａｓｔｅｒＯｒｄｅｒ」フィールドを有し且つワーキング注文タイプであるＭｋｔＯｒｄｅｒオブジェクトを列挙することよって決定することができる（「ＯｒｄｅｒＴｙｐｅ」フィールドは「Ｗ」）。所定のマスター注文における注文のこの組は、異なる為替取引コネクタにわたる数量の現在の割り当てを表わす。

スレーブ注文は、リスク評価に役立つとともに、複数の為替取引にわたって注文がどのように動かされるのかの更なる見通しを与えるのに役立つ。これらの注文におけるＭｋｔＴｒａｎｓａｃｔｉｏｎは、内在する為替取引コネクタで動かされる数量およびこれらの注文に対する市場での反応の詳細を反映する。外部為替取引所５５０、５６０および内部為替取引所５８０において、処理（取引）は、内在する為替取引処理を反映するとともに、このスレーブ注文に関する全ての事象に対する詳細な視点を与える。

最も詳細なレベルで、内在する為替取引所における注文を映し出すＭｋｔＯｒｄｅｒＴＯＣオブジェクトが維持される。これらの注文は、為替取引所におけるスレーブワーキング注文を参照する「ＰａｒｅｎｔＯｒｄｅｒ」フィールドによって跡をたどることができる。このレベルの注文は、内在する為替取引所とワーキング注文との間で公知のやりとりを行なう。このレベルの注文は、為替取引の固有の注文にわたる数量の分担に関する実際の情報を与えるとともに、為替取引コネクタが市場状態およびユーザ要求に応じて数量をどのように動かしたのかを示す。為替取引注文の分担は、内在する為替取引所における注文優先を維持しつつ所与の為替取引所で数量を上下に動かそうとする複数の試みに起因して為替取引数量がどのように分裂されたのかを示す。

ＩＣＥ１４０に提示される注文は、注文ルータまたは様々なルーティングストラテジが注文を発注するために使用されても良いというルーティング規則を示す条件を与えても良い。注文ルータ５２０、２７５および他の戦略によって実施される様々なタイプの条件および規則としては、前述したものを含めてそれ以外に、以下を挙げることができる。

１．注文が成されなければならない、注文が成されても良い、或いは、注文が成されてはならない為替取引所を指定するルーティング条件。また、注文は、ルーティング条件を何ら伴うことなく届いても良く、このことは、注文ルータ５２０、２７５が指定された注文ルータ戦略５２５、５４０を使用して最も適当であると考えるような注文を自由に自動的に行なうことができることを示す。

２．注文が特定の為替取引所でなされる場合に適用される価格変更を示す価格変更条件。例えば、注文は、任意の外部為替取引所に対して送られる価格よりも１／４ティック良い価格が内部為替取引所に送られても良いことを示しても良い。価格条件を伴わない注文は、全ての有効な為替取引で同じ価格が使用されるべきであることを示す。

３．全費用込みの手数料条件は、注文ルータ５２０、２７５またはその戦略５２５、５４０が、各為替取引所で注文が成されるときにその為替取引所によって請求できる手数量を計算してその手数料を為替取引所に送られた価格の中に含めなければならないことを示す。例えば、買呼値が連結為替取引所２９５に提示されて全部込みの費用を使用すべき場合には、各為替取引所において買呼値が有効価格レベルに置かれ、それにより、各為替取引所の手数料を含めて支払われる実際の価格は、注文が各為替取引所毎に定めた価格よりも良く或いはそれに等しい。

規模設定条件は、任意の所与の時間に特定の為替取引所で設定できる最大規模および最小規模を示す。例えば、注文は、注文の全体規模が１０ＭＭであっても任意の所与の価格で２ＭＭの最大規模のみが１つの外部為替取引所に送られるべきであることを示しても良い。規模設定条件を伴わない注文は、それらの全体規模が全ての有効な為替取引所で成される。また、注文は、各為替取引所で成すことができる最小規模を示しても良い。注文が為替取引所で成すことができる最小規模よりも小さい執行規模を有する場合には、注文が為替取引所で全く成されない。

任意の条件は、注文が所与の条件をはっきりと示さないときに効力を生じるように設定されたデフォルト値を有していても良い。また、これらのデフォルト値は、注文がデフォルト値を無効にできないように設定することもできる（例えば、注文は、Ｂｒｏｋｅｒ１において許容されるデフォルト最大規模よりも大きい最大規模をＢｒｏｋｅｒ１に関して規定することができなくても良い）。

注文ルータ５２０、２７５は、特定の規則を使用して注文の割り当て方法を決定する。

すなわち、入ってくる注文が任意の「成されなければならない」ルーティング条件を有する場合、注文ルータ５２０、２７５はその注文を指定された為替取引所に対して送る。注文が特定の注文戦略を指定する場合には、注文がその注文ルータ戦略５２５、５４０へ送られる。

入ってくる注文が任意の「成されても良い」ルーティング条件を有する場合あるいは条件を全く有していない場合、注文ルータ戦略は、指定された注文ルータ戦略５２５、５４０（あるいは、注文における条件で何も指定されていない場合には、デフォルト注文ルータ戦略５２５）を使用して、注文および適切な規模をそれぞれの適用可能な為替取引所へ送ることができる。注文ルータ戦略５２５、５４０がその後に規模の再分配を決定する場合には、注文ルータ５２０、２７５および戦略５２５、５４０がそれに応じて各為替取引所で応答する。

任意の為替取引所からの注文における任意の部分的または完全な執行により、注文ルータ５２０、２７５および戦略５２５、５４０は、全ての他の為替取引所からの執行量をキャンセルするとともに、メイン注文における執行量を示す。これは、注文の全ての規模が執行されるまで或いは注文がキャンセルされるまで続く。

注文ルータへ送られる注文は、即時執行注文条件および最小規模条件を定めても良い。１つの為替取引所が所与の条件をサポートする場合、その条件は注文が所与の為替取引所へ送られるときに使用できる。１つの為替取引所が所与の条件をサポートしない場合には、所与の為替取引所で注文を成すことができない。注文ルータ５２０、２７５は、外部為替取引所により請求される手数料をＩＣＥ２４０のユーザに対して伝えるように設定されていても良い。

多くの注文ルーティングストラテジ５２５、５４０は、例えば、１つの為替取引所で注文を行なったり１つの注文を１つの為替取引所から引き出すなどのルーティングタスクを実行し、マスター注文５３０、５３２、５３４をスレーブ注文５５２、５５５に対して結び付け、スレーブ注文を形成し、スレーブ注文をキャンセルするなどのために、同じ共通の機能の組を使用する。

前述した条件は、注文ルータおよびその戦略によって使用されても良い一般的な条件について記述する。特定の条件を使用する注文ルータ戦略の特定の実施については以下で説明する。デフォルト注文ルータ戦略５２５は、リアルタイムの動的な為替取引注文ルーティングストラテジの実施である。当該戦略は少なくとも２つの目的を果たす。第１としては、現在の市場状態を判断することにより複数の為替取引所にわたってユーザ注文を執行しようとする注文ルータ戦略の生産品質実施である。第２としては、顧客構築ルーティングストラテジのためのテンプレートとしての機能を果たすことができるサンプルルーティングストラテジである。

複数の為替取引所にわたってスレーブ注文を管理することに加え、デフォルト戦略は、利用可能な流動資産に関する情報を内部為替取引所５８０に対して公開し、それにより、内部取引が容易になるとともに、内部流動資産が利用できるときに内部流動資産がうまく利用される。デフォルト戦略５２５は要求毎に高度に設定できる。異なる入力条件を用いて注文を動かすことにより、デフォルト戦略５２５の作用は、ユーザの現在の要求とマッチするように変わる。デフォルト注文ルーティングストラテジ５２５は、現在、現金両替用に設定されている。しかしながら、当業者であれば分かるように、戦略は、必要以上の検証を伴わない先物商品取引のための作業戦略として実施することができる。

注文ルータ５２０、２７５は、ＭａｋｅＭａｒｋｅｔ手続きコール、ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ手続きコール、ＷｏｒｋＯｒｄｅｒキャビネット手続きコールを介して、他の為替取引所コネクタのエンドユーザインタフェースに類似するエンドユーザインタフェースを与える。注文は、注文ルータ５２０、２７５において形成され得るとともに、指定されたルーティングストラテジ５２５、５４０を使用して数量を動かすように指示され得る。ＭａｋｅＭａｒｋｅｔコール或いはＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒコールにおける戦略条件が「Ｄｅｆａｕｌｔ」に設定される場合には、注文ルータへ提示される注文がデフォルトルーティングストラテジ５２５を使用して動かされる。

ＭａｋｅＭａｒｋｅｔコール或いはＷｏｒｋＯｒｄｅｒコールに対する一般的な作業パラメータ（価格、サイド、数量、アクション）に加えて、デフォルト注文ルーティングストラテジ５２５は、「ｋｅｙ＝ｖａｌｕｅ」という形態の一組のセミコロン画定条件として入力を取得する。ＭａｋｅＭａｒｋｅｔコールにおける条件列の一例は以下のように見える。
Ｓｔｒａｔｅｇｙ＝Ｄｅｆａｕｌｔ；ＯｖｅｒｆｉｌｌＲｉｓｋＦａｃｔｏｒ＝０；ＥｘｔｅｒｎａｌＭａｒｋｅｔｓ＝Ｂｒｏｋｅｒ１，Ｂｒｏｋｅｒ２；ＩｎｔｅｒｎａｌＳ
ｈｏｗ＝Ｉｎｄｉｃａｔｉｖｅ；ＩｎｔｅｒｎａｌＦｉｌｌＷａｉｔＳｅｃｏｎｄｓ＝１０；ＥｘｔｅｒｎａｌＳｈｏｗＥｘｃｈａｎｇｅＳｉｚｅ＝５；ＥｘｔｅｒｎａｌＳｈｏｗＴｏｔａｌＳｉｚｅ＝７

この条件列は、Ｂｒｏｋｅｒ１およびＢｒｏｋｅｒ２を使用した過剰執行が不可なデフォルトルーティングストラテジ５２５を使用して注文が動かされなければならないことを示す。内在する為替取引所における受動的作業は、注文規模とは無関係に、５（five）の価格規模（内在するインスツルメントの名目元本において）に制限され、また、この注文における全体の外部数量が常に７（seven）に制限される。また、この注文は、内部為替取引所５８０でも動いている。内部為替取引所においてクロス売買注文が存在しない場合、戦略は、参考注文を成して、利用可能な規模を内部で公開する。クロス売買注文が出現しない場合、戦略は、参考注文を確約にするが、執行のために１０（ten）秒を越えては待たずに、あきらめてＢｒｏｋｅｒ１およびＢｒｏｋｅｒ２に働きかけ続ける。

デフォルトルーティングストラテジ５２５は、高度に設定可能であり、特定の注文を動かすときにその意思決定論理を変更するために以下のパラメータを受け入れる。同じワーキング注文におけるその後のＭａｋｅＭａｒｋｅｔコール及びＷｏｒｋＯｒｄｅｒコールに関する条件は、現在効力がある条件に上書きし、それにより、新たなルーティングパラメータが有効になる。許容される条件の全てのリストが表５に挙げられている。

デフォルト注文ルーティングストラテジ５２５は、処理を２つの段階に分け、最初に、即座に執行する可能性が高い場所へ数量を割り当てることを試み、その後、任意の残りの数量を、取引が次に始まるときに数量を優先注文状態において執行するであろうと確信している場所（不使用場所）へ割り当てる。戦略は、所与の為替取引所価格設定要件によって許容されるほどの積極的な価格を選択する（例えば、ティック境界に置かれない注文は、内部為替取引所５８０において正確な価格に置かれつつ、為替取引所により許容される次の最小の積極的なティックに切り捨てられる）。注文が市場を越えることができないようにする為替取引所では、反対のサイドを超える最小の積極的な注文が成される。

為替取引所からの事象（価格更新、オンラインおよびオフラインでくる市場）およびユーザ要求からの応答時、注文ルーティングストラテジ５２５、５４０は、その内部規則を再評価し、その規則に基づいて、内在する為替取引所で注文を動かそうとする。なお、注文ルーティングストラテジ５２５、５４０は、注文に対して提示されたＥｘｔｅｒｎａｌＭａｒｋｅｔ条件にリストアップされる為替取引所へと注文を発注するだけである。また、注文ルータ戦略５２５、５４０は、マスター注文においてアクティブ数量を動かす際に、アクティブ数量を１つのスレーブ注文上に置くだけである。

マスター注文５３０、５３２、５３４、５４２、５４５（注文ルータ５２５を用いて成される注文）におけるクロス売買場所は、以下のようにマスター注文のインスツルメントにおける注文のＥｘｔｅｒｎａｌＭａｒｋｅｔ条件リストで指定される１つの為替取引所における１つの外部市場として規定される。

１．市場が取引しておらず、マスター注文数量がアクティブであり、マスター注文の価格が反対のサイドの注文と付き合わさる。

２．市場が取引しており、マスター注文が取引の受動的なサイドにあり且つ取引価格と付き合わさる。

３．市場が取引しており、マスター注文数量がアクティブであり、注文が取引のアクティブなサイドにあり且つ取引価格と付き合わさる。

各クロス売買場所ごとに、付き合わさっている一組の価格レベル（クロス売買場所ごとに少なくとも１つ）が存在する。クロス売買レベルは、この注文が付き合わさる反対のサイドに何らかの注文が存在する市場の価格レベルである。ルーティングストラテジは、全ての適格なクロス売買場所にわたって全てのクロス売買レベルで数量を動かし、それにより、各クロス売買レベルでマスター注文の反対のサイドにおいて最大正味数量を動かそうとする。１つのレベルのサイドの正味数量は、そのレベルの両サイドに共通の規模が除去された後にそのレベルのサイドで利用可能な数量として規定される。ルーティングストラテジは、無論、あまり積極的に価格設定されないクロス売買レベルよりも、積極的に価格設定されたクロス売買レベルの方を好む。複数のクロス売買レベルが同じ価格にある場合には、その注文において指定されたＥｘｔｅｒｎａｌＰｒｉｏｒｉｔｅｓリストで早期に取引するために優先権が与えられる。

全体の注文数量が全てのクロス売買場所にわたって置かれない場合、残りの数量は、クロス売買場所のうちの１つで動かされる。この残りの数量を分配する方法に関しては幾つかの選択肢がある。

１．ＥｘｔｅｒｎａｌＭａｒｋｅｔリスト内の最初のクロス売買場所に、積極性が最も少ないクロス売買レベルの全ての残りの数量を置く。

２．最も少ない正味数量がマスター注文と同じサイドにあるクロス売買場所に、積極性が最も少ないクロス売買レベルの全ての残りの数量を置く。

３．残りの数量を全てのクロス売買場所にわたって比例的に分け、それにより、各場所で積極性が最も少ないクロス売買レベルの数量を増大させる。

デフォルト注文ルーティングストラテジ５２５は、積極性が最も少ないクロス売買レベルの全ての残りの数量を、ＥｘｔｅｒｎａｌＭａｒｋｅｔリスト内の最初のクロス売買場所に置く。なお、注文のＯｖｅｒｆｉｌｌＲｉｓｋＦａｃｔｏｒ条件、ＥｘｔｅｒｎａｌＳｈｏｗＥｘｃｈａｎｇｅＳｉｚｅ条件、および、ＥｘｔｅｒｎａｌＳｈｏｗＴｏｔａｌＳｉｚｅ条件は、能動的場所への数量の配置に影響を与えない。

クロス売買場所が存在しない場合、デフォルト注文ルーティングストラテジ５２５は、近い将来にマッチするために利用可能になる可能性が高い場所に数量を置くことを試みる。これは、取引が始まるときに最初に注文が執行されるラインにのる可能性が高くなるように為替取引所のキュー内の注文の場所を最大にしようとすることにより達成される。戦略は、以下の基準を使用して利用可能な不使用場所を注文する。

１．注文の価格レベルに規模を有していないＥｘｔｅｒｎａｌＭａｒｋｅｔｓで指定されるクロス売買市場。したがって、そのレベルで最初の注文となることにより、スレーブ注文優先権を与える。複数の場所は、ＥｘｔｅｒｎａｌＭａｒｋｅｔｓ条件リスト内でのそれらの場所によって選択される。

２．空きのレベルを利用できない場合、戦略は、市場に既にある規模を結び付ける。クロス売買場所のそれと同様に、残りの場所の注文は、注文のＥｘｔｅｒｎａｌＭａｒｋｅｔｓリスト内のその場所の為替取引所の注文に基づくことができ、あるいは、大きい規模よりも小さい規模を好む各為替取引所での注文の価格レベルの規模に基づくことができる。

注文ルーティングストラテジ５２５は、注文のＥｘｔｅｒｎａｌＭａｒｋｅｔｓリスト中においてその取引が先となる場所を好む。オープン数量全体に限定されるクロス売買場所での数量とは異なり、不使用場所に置かれた全数量は、過剰執行調整数量と称される現在のオープン規模の現在の注文のＯｖｅｒｆｉｌｌＲｉｓｋＦａｃｔｏｒ倍だけ増大される。例えば、１０Ｍにおける１つの注文が０．５の過剰執行リスクを有する場合、注文のＥｘｔｅｒｎａｌＳｈｏｗＴｏｔａｌＳｉｚｅ条件およびＥｘｔｅｒｎａｌＳｈｏｗＥｘｃｈａｎｇｅＳｉｚｅ条件の制約を受ける不使用場所に置くために１０Ｍ＋（１０Ｍ^*０．５）＝１５Ｍを利用できる。

注文ルータ５２０、２７５は、注文の利用可能な不使用場所にわたって繰り返し、それにより、以下の制約内で使われていないそれぞれの場所で可能な最大数量を動かす。

１．現在のオープン規模を越える規模を１つの為替取引所に決して置かない。

２．現在のＥｘｔｅｒｎａｌＳｈｏｗＥｘｃｈａｎｇｅＳｉｚｅを越える規模を１つの為替取引所に決して置かない。

３．全体の外部数量が注文のＥｘｔｅｒｎａｌＳｈｏｗＴｏｔａｌＳｉｚｅを越えるように数量を置かない。

注文を外部に発注するための論理に加えて、デフォルト注文ルーティングストラテジ５２５は、内部為替取引所２８０、５８０で注文を行ない、可能な調和をうかがい、確定注文とともに応答することで、内部の流動資産をうまく利用する。注文のＩｎｔｅｒｎａｌＳｈｏｗ条件が「Ｎｅｖｅｒ」に設定されない場合、デフォルト注文ルーティングストラテジ５２５は、注文を行なって利用可能な数量を公表することにより内部為替取引所２８０、５８０をうまく利用し、あるいは、流動資産をうまく利用する。

デフォルトルーティングストラテジ５２５は、不使用場所からの使用されない数量を割り当てて内部為替取引所で確約数量を与えることにより或いは参考注文を行なって不使用場所で現在動かされている流動資産の存在に関して他に知らせることより内部為替取引所２８０、５８０で数量を広告する少なくとも２つの異なる方法を有する。いずれの状況においても、デフォルトルーティングストラテジ５２５は、内部流動資産を生かすために（必要に応じて、過剰執行制限を満たすために）外部市場から注文を引き出す。

内部作業の２つのタイプは、それらが内部数量を示す方法が異なっている。すなわち、注文のＩｎｔｅｒｎａｌＳｈｏｗ条件が「ＦｉｒｍＯｎｌｙ（確約のみ）」に設定される場合、その注文は、内部為替取引所２８０、５８０における確約数量だけを示す。これは、数量を外部で割り当てることができないからであり、あるいは、内部為替取引所２８０、５８０での差し迫ったクロス売買によるものである。注文のＩｎｔｅｒｎａｌＳｈｏｗ条件が「Ｉｎｄｉｃａｔｉｖｅ（参考）」に設定される場合、注文の全オープン数量は、注文が不使用場所での作業数量である場合には、内部為替取引所２８０、５８０における数量として常に示されるとともに、外部の制約に起因して内部為替取引所２８０に置かれることができる確約部分と残りのオープン数量との間で分けられる。

「ＦｉｒｍＯｎｌｙ」または「Ｉｎｄｉｃａｔｉｖｅ」のいずれかに設定されたＩｎｔｅｒｎａｌＳｈｏｗ条件を伴う注文は、注文をクロス売買するために内部為替取引所２８０、５８０を見守り、内部為替取引所２８０、５８０で示される数量をマッチさせるためにクロス売買場所または不使用場所でそれらの数量を減少させることによりそれらをマッチさせようとする（必要に応じて、過剰執行制限内となるようにする）。多くの方法で、内部為替取引所２８０、５８０は、それがクロス売買場所である場合には、あたかもそれが注文のＥｘｔｅｒｎａｌＭａｒｋｅｔｓリストの冒頭にある外部為替取引所５５０、５６０であるかのように、そしてそれが不使用場所である場合には、それが注文のＥｘｔｅｒｎａｌＭａｒｋｅｔｓリストの最後にある外部為替取引所５５０、５６０であるかのように、以下の違いをもって、取り扱うことができる。

クロス売買場所として扱われると、クロス売買注文を執行するために必要な正確な数量だけが内部為替取引所２８０、５８０に置かれる。過剰な数量は、それを他のクロス売買場所で動かすことができる場合、内部為替取引所で動かされない。また、数量は、数量を受けることができる他のクロス売買場所が存在しない場合には、内部為替取引所がクロス売買場所として機能されている間、不使用場所で動かされる。

不使用場所として扱われると、外部の制限を全く受けない。すなわち、内部為替取引所２８０、５８０は、注文のＥｘｔｅｒｎａｌＳｈｏｗＴｏｔａｌＳｉｚｅ制限およびＥｘｔｅｒｎａｌＳｈｏｗＥｘｃｈａｎｇｅＳｉｚｅ制限に晒されない。

注文がその数量を他の場所に置くことができるときに執行することなく内部為替取引所２８０、５８０で確約数量を残していないといういくらかの保障を与えるため、可能な取引の完了に関して注文が内部為替取引所２８０、５８０で待つ期間に制限がある。ＩｎｔｅｒｎａｌＦｉｌｌＷａｉｔＳｅｃｏｎｄｓ条件は、クロス売買注文に応じて内部為替取引所２８０、５８０で確約注文を行なった後に注文が執行を待つ期間に関して上限を設定する。内部のクロス売買状況により注文ルータがその数量を他の場所に置くことができるときに内部為替取引所２８０、５８０で確約注文を行なう場合、ルーティングストラテジ５２５、５４０は、現在の注文を再評価して数量を他の場所に置く前に注文のＩｎｔｅｒｎａｌＦｉｌｌＷａｉｔＳｅｃｏｎｄｓ時間まで待つ。このタイムアウトのシナリオは幾つかの理由で殆ど共通に起こり得る。これは、内部為替取引所２８０、５８０での注文を外部注文のキャンセルの遅れにより確約できないからである。ＩｎｔｅｒｎａｌＦｉｌｌＷａｉｔＳｅｃｏｎｄｓ条件は、内部の流動資産を生かすことにより注文にペナルティを課すことができる期間を制限しようとする。

このコンセプトの一例は、マスター注文０１が過剰執行を伴うことなく（ＯｖｅｒｆｉｌｌＲｉｓｋＦａｃｔｏｒ＝０）注文ルータで行なわれ且つ外部の制限を伴うことなく（ＩｎｔｅｒｎａｌＳｈｏｗ＝Ｉｎｄｉｃａｔｉｖｅ）Ｂｒｏｋｅｒ１（ＥｘｔｅｒｎａｌＭａｒｋｅｔ＝Ｂｋｒ１）で取引できるケースを考慮することによって説明できる。デフォルトルーティングストラテジ５２５は、内部為替取引所でそれをクロス売買する注文が存在しないことを見込み、Ｂｒｏｋｅｒ１で受動的に注文の全数量を動かす。また、当該戦略は、内部為替取引所２８０における全ての注文の規模に関して参考注文を行なう。

しかしながら、マスター注文０２は、過剰執行を伴うことなく（ＯｖｅｒｆｉｌｌＲｉｓｋＦａｃｔｏｒ＝０）注文ルータ５２０、２７５で行なわれるとともに、Ｂｒｏｋｅｒ２で取引することができる（ＥｘｔｅｒｎａｌＭａｒｋｅｔｓ=Ｂｒｏｋｅｒ２）。マスター注文０２は、ＩｎｔｅｒｎａｌＳｈｏｗ＝ＩｎｄｉｃａｔｉｖｅおよびＩｎｔｅｒｎａｌＷａｉｔＦｉｌｌＳｅｃｏｎｄｓ=5の状態で指定される。マスター注文０２は、マスター注文０１の反対のサイドにあって同じ価格であり、マスター注文０１と付き合わす。全ての市場の状態を評価する際、マスター注文０２は、マスター注文０１における内部為替取引所２８０、５８０での参考注文と正確にマッチする一方で、それが付き合わすことができＢｒｏｋｅｒ２における注文も存在する。外部の流動資産よりも内部の流動資産を好むため、マスター注文０１における確約注文は、内部為替取引所２８０、５８０で行なわれるとともに、５秒間タイマーをスタートさせる。

マスター注文０１は、マスター注文０２からの確約スレーブ注文に起因して内部為替取引所２８０、５８０で変化が見られる。マスター注文０１は、Ｂｒｏｋｅｒ１におけるその数量を過剰執行限度内となるように減少させるとともに、内部為替取引所２８０、５８０に確約マッチング注文を発注する。

注文ルータが内部為替取引所２８０、５８０においてマスター注文０２のＩｎｔｅｒｎａｌＷａｉｔＦｉｌｌＳｅｃｏｎｄｓ条件の５秒の窓内でマスター注文０１に関してスレーブ注文をキャンセルできなかった場合、注文ルータ５２０、２７５は、内部為替取引所２８０、５８０でマスター注文０２のスレーブ注文を引き出すとともに、その注文をＢｒｏｋｅｒ２に発注する。注文ルータ５２０、２７５は、マスター注文０２がクロス売買場所で作用しなくなるまでマスター注文０１とマッチするための決定を繰り返さず、したがって、マスター注文０２がどこかで直ちに執行されることはまずない。この繰り返しの制約は、外部市場の流動資産を利用できない程度まで内部の流動資産をうまく利用する注文にペナルティを課さないようにしつつ、内部の流動資産をうまく利用することとの間で良いバランスをとる。

注文ルータ５２０、２７５は、実行・価格設定コネクタ２０５、２１０、２１５、２２０を介して外部為替取引所とブローカー１０５、１１０、１１５、１２０とを結び付ける。為替取引所／ブローカー実行・価格設定コネクタ２０５、２１０、２１５、２２０は、異なる為替取引所で注文を行なって生の価格データを集めるために各為替取引所固有のクライアントＡＰＩとの交渉に関与する。これらのコネクタは、個々の為替取引所の機構からシステムを抽出するために一様なＡＰＩ／プロトコルを注文ルータ２７５、５２０に対して与えても良い。

コネクタにより、注文ルータ２７５、５２０からの複数の注文を、１つのログインにより所定のブローカー／為替取引所に対して送信される１つの注文に組み合わせることができ、１つのログイン下で異なる注文として送信することができ、ユーザにより望まれる異なるログイン下で異なる注文として送信することができる。

外部為替取引所との任意のつながりまたは当該取引所に伴う他の破綻（または、外部為替取引所が「古い」システム・アドミニストレータ通知）は、注文ルータ２７５、５２０が有する、有効な為替取引所および連結価格フィードのリストから破綻した為替取引所を除去する。

中央情報センタを市場価格データに与えるため、取引できない為替取引所または他の価格設定ソース２３５からのブローカー／為替取引所価格設定データを連結価格設定フィード２５６に組み合わせることができる。これらの価格は、価格フィードで「取引不能」としてマーキングされる。

ＩＣＥシステム１００は、様々な為替取引所、ブローカープラットフォーム、ＥＣＮ、注文ルータ２７５、５２０にわたって正規化インタフェースを与える。為替取引所接続プロセスは、規則化された市場コネクタインタフェースと内在する顧客ブローカーシステムまたはＥＣＮとの間にインタフェースを与える。異なる内在する為替取引所、ＥＣＮ、ブローカーインタフェースにわたる差異はかなりのものである。これらの差異を管理するため、為替取引コネクタは階層機能性手法を使用して、インタフェース正規化の異なる度合いをサポートする。１つの実施形態において、各為替取引コネクタは、為替取引注文ＡＰＩおよびワーキング注文ＡＰＩの両方をサポートする。

為替取引注文ＡＰＩ層は、内在システムのセマンティックス（semantics）に最も近い。このインタフェースおよびオブジェクトの組は、内在システムの挙動を厳密に反映する。その結果、内在システムの特異性の一部がユーザに晒される。必然的に、内在システムの内容が露呈されるため、為替取引注文ＡＰＩは更に複雑になる。為替取引注文ＡＰＩの使用では、ユーザに、内在する為替取引所のセマンティックスの差異を説明する必要がある。

また、為替取引コネクタは、注文配置および管理に関してこれらの差異を正規化するワーキング注文ＡＰＩ層をサポートすることができる。ワーキング注文ＡＰＩは、為替取引注文ＡＰＩの上に構築され、為替取引所にわたって内在する意味内容上の差異を明らかにするとともに、これらの差異をユーザから抽出する。殆どのユーザはワーキング注文ＡＰＩを使用すべきである。なぜなら、ワーキング注文ＡＰＩを使用することがプログラミングを全ての為替取引所に対して統一し簡略化するからである。

ワーキング注文ＡＰＩは、ユーザのための統一された１つのワーキング注文を所与の価格で管理する。ワーキング注文ＡＰＩを介して、為替取引コネクタは、内在する為替取引所ＡＰＩにおける注文の発生/消滅とは無関係に内部注文の正確な発生/消滅を管理する。上記アダプタは、ワーキング注文と内在する為替取引注文との間の適切なマッピング（写像的な関連付け）（mapping）を管理する。幾つかのケースで、これは、多くの異なる為替取引注文を１つのワーキング注文にマッピングすることを意味する。この手法により、ユーザは必要に応じてワーキング注文の発生/消滅を制御することができる。

ワーキング注文ＡＰＩは、以下のＡＰＩコール、すなわち、ＭａｋｅＭａｒｋｅｔ；ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ６１２；ＷｏｒｋＯｒｄｅｒ６２６；ＣｌｏｓｅＷｏｒｋｉｎｇＯｒｄｅｒ；ＲｅｓｅｔＷｏｒｋｉｎｇＯｒｄｅｒを含む。

また、ワーキング注文ＡＰＩは、ワーキング注文管理に特に関連付けられたＭｋｔＯｒｄｅｒオブジェクトおよびＭｋｔＴｒａｎｓａｃｔｉｏｎオブジェクトを形成して管理する。これらのオブジェクトは、「Ｗ」のＯｒｄｅｒＴｙｐｅ値をもって示される。

ワーキング注文の発生/消滅は為替取引コネクタ２０５、２１０、２１５、２２０によって管理される。ワーキング注文は、為替取引コネクタ２０５、２１０、２１５、２２０の作動期間中オープンに保持される寿命が長いオブジェクトである。殆どのワーキング注文は、不使用を示す「０」の突出した規模を有する。コネクタがシャットダウンされると、その全てのワーキング注文は閉じられる。

ワーキング注文は、アクティブまたは過去となり得る。アクティブなワーキング注文は、所与の価格で為替取引所に置かれた未執行の規模に対して安定した取り扱いを行なう。プログラマは、この取り扱いを使用して、注文の規模を上下に操作する。注文のＷｏｒｋｉｎｇＳｉｚｅはＷｏｒｋＯｒｄｅｒまたはＭａｋｅＭａｒｋｅｔＡＰＩコールのいずれかによってユーザにより制御される。規模は、ユーザの要求に基づいて増大することができるとともに、ユーザの要求がなければ稀にしか減少しない。規模は、内在する為替取引所が独立に注文をキャンセルするとき或いはアダプタ自体がシャットダウンされるときに減少することができる。リセットプロセスは、アクティブな注文を過去の注文へ変える機構である。注文のＷｏｒｋＳｉｚｅがＦｉｌｌｅｄＳｉｚｅとなり且つＯｐｅｎＳｉｚｅ=0になると、注文をリセットできる。リセット中、アダプタは、最近執行された規模またはアクティブな注文を過去の注文へ保管して、アクティブな注文のＷｏｒｋｉｎｇＳｉｚｅ、ＦｉｌｌｅｄＳｉｚｅおよびＯｐｅｎＳｉｚｅをすべて０にリセットする。

図６は、本発明の一実施形態に係るワーキング注文の発生/消滅のプロセス６００を示す。状態６０５は、注文が存在していない状態である。ユーザは、ステップ６１２において、システムをワーキング注文オープン状態（the Open Working Order State）６２０へ移行させるためにエンドユーザインタフェースを利用するワーキング注文を形成する。システムが状態６２０にある間、状態移行部６２２は、オープン注文規模が、注文が完全に執行されたことを示すゼロに等しいかどうかを決定する。注文が執行されたことを状態移行部６２２が決定する場合、システムは、ステップ６３０において、執行された規模を取引された注文へ自動的に保管するとともに、当初の注文を、ゼロ規模およびゼロ執行規模を有する状態へリセットする。システムがステップ６３０を実行し且つステップ６３０でゼロオープン規模を有する注文があると状態移行部６２２が決定すると、状態移行部６２２は、システムを元のワーキング注文オープン状態６２０に戻す。

ワーキング注文オープン状態６２０において、ユーザは、移行部６２６において、システムをワーキング注文係属状態（the Pending Working order State）６４０へ移行させるワーク注文を形成することができる。あるいは、ユーザは、ワーキング注文取引状態６６０をもたらすために移行部６４４で取引を始めることができる。ワーキング注文係属状態６４０において、ユーザは、移行部６２６で他のワーク注文を入力することができる。ワーキング注文係属状態６４０の間、為替取引所は、移行部６４４において取引を開始することができ、それにより、ワーキング注文係属＆取引状態（the Pending ＆ Trading Working Order State）６５０となる。また、ユーザは、システムがワーキング注文係属＆取引状態６５０の間に移行部６２６において他のワーク注文を入力するという選択肢も有する。為替取引所は、移行部６５４により、システムをワーキング注文係属＆取引状態６５０から元のワーキング注文係属状態６４０へ移すことができる。ワーキング注文係属＆取引状態６５０から、システムは、状態移行部６５６を介して、ワーキング注文取引状態６６０へ移行することができる。例えば、これは、係属処理（pending transaction）がゼロに等しいときに起こり得る。システムがワーキング注文取引状態にあると、ユーザは、システムを元のワーキング注文係属＆取引状態６５０へ戻すワーク注文６２６を入力することもできる。

あるいは、システムは、状態図にわたってワーキング注文オープン状態から反時計周りに進むことができる。このプロセスは、ユーザ制御されないが、為替取引所が６４４で取引し始め且つシステムがワーキング注文取引状態６６０へ移行するときに為替取引所によって開始される。また、為替取引所は、移行部６５４で取引を終わらせることによって、システムを元のワーキング注文オープン状態６２０へ移行させることもできる。このプロセスは、それ自体、為替取引所が移行を開始するかどうか或いはユーザが移行を開始するかどうかに応じていずれかの方向で繰り返すことができる。ワーキング注文は、表６に示されるフィールドをＭｋｔＯｄｅｒオブジェクトで使用してその状態を維持する。

各ワーキング注文はリセット操作をサポートする。ワーキング注文は、手動または自動でリセットできる。ＲｅｓｅｔＴｙｐｅ条件は、どのリセット機構が使用されるのかを示す。デフォルトにより、注文リセットは、自動であるが、以下の条件にしたがって先行注文設定できる。
−ＲｅｓｅｔＴｙｐｅ＝Ａｕｔｏｍａｔｉｃ
−ＲｅｓｅｔＴｙｐｅ＝Ｅｘｐｉｃｉｔ

アクティブなワーキング注文だけを特定の条件下でのみリセットすることができる。注文のリセットタイプが自動である場合、アダプタは、適切な時に注文を自動的にリセットする。リセットタイプが明示的である場合、ユーザは、ＲｅｓｅｔＷｏｒｋｉｎｇＯｒｄｅｒＡＰＩコールを呼び出すことにより注文をリセットできる。ワーキング注文は、以下の条件下でのみリセットできる。

１．内在する為替取引注文が、現在、取引状態にない。

２．全ての内在する為替取引注文が完全に開放しており（ＷｏｒｋｉｎｇＳｉｚｅ=ＯｐｅｎＳｉｚｅ）或いは完全に閉じられている（ＷｏｒｋｉｎｇＳｉｚｅ=ＦｉｌｌｅｄＳｉｚｅ）。

任意の他の時間でのリセット試行が拒絶される。

注文リセット中、現在の注文状態が過去のワーキング注文へ保管される。リセット操作は、完全に執行された全ての為替取引注文をアクティブなワーキング注文から動かして、それらを新たに形成された過去のワーキング注文上に置く。現在のーキング注文は、その既存のＩｎｔｅｒｎａｌＯｒｄｅｒＩｄを保持する。新たな過去のＩｎｔｅｒｎａｌＯｒｄｅｒＩｄが形成されて過去の注文で加味される。過去のＩｎｔｅｒｎａｌＯｒｄｅｒＩｄはフォーマット＜ｏｒｉｇｉｎａｌ ｏｒｄｅｒＩｄ＞．＜ｒｅｓｅｔ ｒｅｖｉｓｉｏｎ＞を有する。

以下は、完全執行リセットの一例である。
［初期注文状態］
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝Ｗ００００１
ＷｏｒｋｉｎｇＳｉｚｅ＝１０
ＯｐｅｎＳｉｚｅ＝０
ＦｉｌｌｅｄＳｉｚｅ＝１０
ＴｒａｄｉｎｇＳｔａｔｅ＝「」

リセット操作後
［リセット注文］
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝Ｗ００００１
ＷｏｒｋｉｎｇＳｉｚｅ＝０
ＯｐｅｎＳｉｚｅ＝０
ＦｉｌｌｅｄＳｉｚｅ＝１０

［過去の注文（新たに形成された）］
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝Ｗ０００１．２
ＷｏｒｋｉｎｇＳｉｚｅ＝１０
ＯｐｅｎＳｉｚｅ＝０
ＦｉｌｌｅｄＳｉｚｅ＝１０

以下は部分執行リセットの一例である
［初期注文状態］
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝Ｗ００００２
ＷｏｒｋｉｎｇＳｉｚｅ＝１０
ＯｐｅｎＳｉｚｅ＝３
ＦｉｌｌｅｄＳｉｚｅ＝７
ＴｒａｄｉｎｇＳｔａｔｅ＝「」
（内在する為替取引注文１）
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝ＥＸ０００１，ＷｏｒｋｉｎｇＳｉｚｅ＝７，ＦｉｌｌｅｄＳｉｚｅ＝７
（内在する為替取引注文２）
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝ＥＸ００２，ＷｏｒｋｉｎｇＳｉｚｅ＝３，ＦｉｌｌｅｄＳｉｚｅ＝０

リセット操作後
［リセット注文］
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝Ｗ００００２
ＷｏｒｋｉｎｇＳｉｚｅ＝３
ＯｐｅｎＳｉｚｅ＝３
ＦｉｌｌｅｄＳｉｚｅ＝０
ＴｒａｄｉｎｇＳｔａｔｅ＝「」
（内在する為替取引注文１）
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝ＥＸ００２，ＷｏｒｋｉｎｇＳｉｚｅ＝３，ＦｉｌｌｅｄＳｉｚｅ＝０

［過去の注文（新たに形成された）］
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝Ｗ０００２
ＷｏｒｋｉｎｇＳｉｚｅ＝７
ＯｐｅｎＳｉｚｅ＝０
ＦｉｌｌｅｄＳｉｚｅ＝７
ＴｒａｄｉｎｇＳｔａｔｅ＝「」
（内在する為替取引注文１）
ＩｎｔｅｒｎａｌＯｒｄｅｒＩｄ＝ＥＸ０００１，ＷｏｒｋｉｎｇＳｉｚｅ＝７，ＦｉｌｌｅｄＳｉｚｅ＝７

ワーキング注文は、ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒ６１２へのコールによって形成することができる。インスタンス化の後、ユーザは、ＷｏｒｋＯｒｄｅｒ６２６へのコールにより、未執行の注文規模を変更することができる。ある時点で、注文は、完了されるとともに、ｐｅｎｄｉｎｇ＝ｆａｌｓｅ、ＯｐｅｎＳｉｚｅ＝０、ＴｒａｄｉｎｇＳｔａｔｕｓ＝「」によって識別される。注文がＲｅｓｅｔＴｙｐｅ＝ｅｘｐｌｉｃｉｔをもって成されたと仮定すると、この時点で、ユーザは、注文をリセットすることができ或いはＣｌｏｓｅＷｏｒｋｉｎｇＯｒｄｅｒへのコールによって注文を閉じることができる。ＣｌｏｓｅＷｏｒｋｉｎｇＯｒｄｅｒは、ワーキング注文にＳｔａｔｕｓ＝Ｄをマーキングするとともに、その注文における更なる操作を許容しない。

ＭａｋｅＭａｒｋｅｔは、Ａｄｄ機能、キャンセル機能、変更機能を含む為替取引コネクタ２０５、２１０、２１５、２２０とやりとりするための高レベル機能である。ＭａｋｅＭａｒｋｅｔは、そのパラメータとして示される規模を動かしていなければならない正確な低レベル操作を知的に置く。それにより、ユーザは、自分達が現在動いており且つ既に執行された現在の規模とは無関係に市場で動かしたいと思う規模を指定することができる。

例えば、５０の規模を有し且つその後２０の規模を有するＭａｋｅＭａｒｋｅｔへのコールは、最初に、５０の規模を加えるためのＡｄｄＯｒｄｅｒコマンドを発行し、その後、為替取引所およびそれがサポートするものに応じて、２０へのＭｏｄｉｆｙＡｂｓｏｌｕｔｅを発行する。ＭａｋｅＭａｒｋｅｔにより、ワーキング注文に関して条件を設定できる。

ＣｒｅａｔｅＷｏｒｋｉｎｇＯｒｄｅｒコール６１２は、指定されたインスツルメント、サイド、価格に基づいて新たなワーキング注文をインスタンス化する。実際の注文は、ユーザがＷｏｒｋＯｒｄｅｒ６２６を呼び出すまで為替取引所で行なわれない。ＣｒｅａｔｅＷｏｋｉｎｇＯｒｄｅｒ６１２は、その後のＷｏｒｋＯｒｄｅｒ６２６コールによって操作できる注文オブジェクトへの参照を形成する。ＣｒｅａｔＷｏｒｋｉｎｇＯｒｄｅｒ６１２により、ワーキング注文に関して条件を設定できる。

ＷｏｒｋＯｒｄｅｒ６２６は、既存のワーキング注文の未執行の規模を変える。現在および所望の未執行の規模に基づいて、ＷｏｒｋＯｒｄｅｒ６２６は、目標に達するために、内在する為替取引注文を行なう及び／又はキャンセルする。ＷｏｒｋＯｒｄｅｒ６２６は、異なる内在する為替取引注文の有利な時間優先を保とうとすることにより規模を増減するときに知的に挙動する。ＷｏｒｋＯｒｄｅｒ６２６は、挙動のキャンセル／置換を回避し、その代わり、複数の内在する注文を１つの単位として管理する。同様に、注文をキャンセルする場合或いは規模を減少させる場合には、注文が逆にキャンセルされ、それにより、最後に成された為替取引注文が最初にキャンセルされる為替取引注文となる。ＷｏｒｋｉｎｇＯｒｄｅｒ６２６を閉じて除去するように試みる。ＯｐｅｎＳｉｚｅが０のＷｏｒｋｉｎｇＯｒｄｅｒのみを閉じることができる。何らかの理由により注文を閉じることができない場合、ユーザに対してエラーが示される。

リセット操作によって規定されるようにワーキング注文をリセットすることを試みる。ＲｅｓｅｔＴｙｐｅ=Explicitとなる注文を提示するユーザは、この機能を呼び出してリセット操作を明示的に行なうことができる。

ＩＣＥ ＡＰＩ ２５５は遠隔手続きコール機能によってアクセスされる。起動および初期化の際、為替取引コネクタは、コールに対するユーザ適用のための以下の遠隔手続きを登録する。
−ＡｄｄＯｒｄｅｒ
−ＣａｎｃｅｌＯｒｄｅｒ
−ＣａｎｃｅｌＡｌｌ
−ＭｏｄｉｆｙＯｒｄｅｒ
−ＣａｎｃｅｌＡｌｌＥｘｃｈａｎｇｅＯｒｄｅｒs

ＡｄｄＯｒｄｅｒは、呼び出しているユーザのための指定された価格および規模で新たな注文を為替取引所に対して加える。注文を成す為替取引ユーザは、システム設定の一部として維持されるユーザマッピングを取引するためにＴＯＣユーザによって決定される。取引に応じて、付加注文（add order）は、前の注文が市場に残っているときに異なる態様で挙動する。複数の注文を同じ価格で所与の接続部においてサポートしない為替取引所において、付加注文は、アダプタにより、改変注文命令へ変換される。この操作は、付加された量だけ既存の注文の規模を増大することを試みる。所与の価格の複数の注文を提示できるこれらの為替取引所において、付加注文機能は、複数の異なる注文を為替取引所に対して加える。ＡｄｄＯｒｄｅｒにより、ワーキング注文に関して条件を設定することができる。

ＣａｎｃｅｌＯｒｄｅｒは、為替取引所における１つ以上の既存の注文をキャンセルする。ＣａｎｃｅｌＯｒｄｅｒは、特定された為替取引注文の全規模をキャンセルするための要望を示す。注文規模の一部のみをキャンセルするには、下位規模（アブソリュートまたはデルタのいずれか）を示すＭｏｄｉｆｙＯｒｄｅｒ手続きを実行する。為替取引コネクタ２０５、２１０、２１５、２２０は為替取引所の動作に起因して未執行の注文規模の全体をキャンセルしようとするが、これは常に可能であるとは限らない。したがって、ＣａｎｃｅｌＯｒｄｅｒコールにより、一部だけのキャンセルが成されても良い。これは、例えば、ホールドインタイムの為替取引所内で注文をキャンセルしようとするとき或いは注文がキャンセルされている間に執行が行なわれる場合に起こり得る。実際のキャンセルされる規模は、結果として得られる取引で示される。

ユーザは、ＣａｎｃｅｌＯｒｄｅｒ手続きコールにより、自分自身の注文だけをキャンセルすることができる。他のユーザの注文をキャンセルするため、ＣａｎｃｅｌＡｌｌＥｘｃｈａｎｇｅＯｒｄｅｒ手続きが呼び出される。ＣａｎｃｅｌＯｒｄｅｒは、キャンセルするための注文配列を指定することにより、複数の個々の注文をキャンセルすることができる。キャンセルするための注文のより一般的なクラスを指定するためにＣａｎｃｅｌＡｌｌ機能を使用する。

ＣａｎｃｅｌＡｌｌは、為替取引所内の注文の状況に基づいて、為替取引所における１つ以上の既存の注文をキャンセルする。個々の指定された注文をキャンセルするにはＣａｎｃｅｌＯｒｄｅｒ手続きを使用する。ＣａｎｃｅｌＡｌｌは、特定された為替取引注文の規模全体をキャンセルするための要望を示す。注文規模の一部のみをキャンセルするには、下位規模（アブソリュートまたはデルタのいずれか）を示すＭｏｄｉｆｙＯｒｄｅｒ手続きを実行する。ＣａｎｃｅｌＡｌｌは、呼び出しているユーザのための注文をキャンセルすることを試みる。そうするためにＣａｎｃｅｌＡｌｌＥｘｃｈａｎｇｅＯｒｄｅｒsを使用する。

ＭｏｄｉｆｙＯｒｄｅｒにより、ユーザは、既存の注文の状態を変更することができる。注文は、アブソリュートターム（absolute term）で或いはデルタターム（delta term）で変更することができる。所与の時間には、１つのアブソリュート変更だけが許容される。その後の全ての変更は、内在する為替取引所からの確認またはエラーにより最初の絶対的な変更が完了されるまで、絶対的変更不能後に（エラー処理を経由して）要求する。複数のデータ変更は１つの時間で係属することができる。

条件構造は、ＭａｋｅＭａｒｋｅｔ手続き、ＣｒｅａｔＷｏｒｋｉｎｇＯｒｄｅｒ６１２、ＡｄｄＯｒｄｅｒ手続き、ＭｏｄｉｆｙＯｒｄｅｒ手続きへ文字列(ストリング)として送り込まれる名前付きの型付けされた値のフレキシブルなリストである。ＴｏｃＶａｌｕｅ構文解析・タイプチェック機能は、タイプ正確性をランタイムで確保する。例えば、文字列条件リスト「ＦｉｌｌＯｒＫｉｌｌ＝Ｔｒｕｅ，ＨｉｄｄｅｎＳｉｚｅ＝２０」は、２つの条件−第１として、ＦｉｌｌＯｒＫｉｌｌを示すブーリアン、第２として、注文における隠された規模を示す２値−へと構文解析される。

市場価格オブジェクトは、為替取引ハンドラの価格フィード側によって使用される。これらのオブジェクトは、外部市場が作動（tick）するときに外部市場の状態を示すために為替取引コネクタによって送信される。ＭｋｔＰｉｃｔｕｒｅオブジェクトは、市場価格情報を送るために使用される。ＭｋｔＰｉｃｔｕｒｅオブジェクトは、所与の時間における１つの為替取引所における市場の状態を表わしている。ＭｋｔＰｉｃｔｕｒｅオブジェクトは、価格スタック（買呼値側および売呼値側）、取引状態（買い注文キュー（queue）及び売り注文キュー）、取引情報のためのフィールドを含む。

ＭｋｔＰｉｃｔｕｒｅオブジェクトは、取引している市場及び取引していない市場に関する市場情報を含む。市場と取引している間、買い側および売り側の当事者は、第１のレベルの注文スタックとして示される。例えば、以下の市場およびその後のアクティブな注文を考慮する。
不活発市場
１００−１４＋ −２４６ ３０ｘ１０
１００−２４ −２５ ５０ｘ５０
１００−２３＋ １０ｘ
注文：１００−２４＋での１０の売り
取引市場
１００−２４＋ ＨＩＴ １０
−−−−−−−−−−−−−−−
１００−２４＋ −２４＋ ２０ｘ０ ←取引状態の動きはマーケットピクチャの
レベル０で複製される
１００−２４ −２４６ ５０ｘ１０
１００−２３＋ −２５ １０ｘ５０

ネットワーク帯域幅を効率良く使用するため、為替取引コネクタ２０５、２１０、２１５、２２０は、デルタアルゴリズムを使用してＭｋｔＰｉｃｔｕｒｅオブジェクト間の変化のみを送信する。ＭｋｔＰｉｃｔｕｒｅ消費者がＭｋｔＰｉｃｔｕｒｅオブジェクトに関して最初に問い合わせを行なうと、全てのオブジェクトがクライアントへと送信される。その時から、変化のみが送信される。これにより、オーバヘッドが大きく減少され、クライアント、コネクタ、汎用システムの性能が高められる。

したがって、ＭｋｔＰｉｃｔｕｒｅオブジェクトの消費者は、対象のＭｋｔＰｉｃｔｕｒｅオブジェクトのキャッシュを維持しなければならない。これは、適切なＭｋｔＰｉｃｔｕｒｅオブジェクトのＴＯＣＩｎＭｅｍＴａｂｌｅキャッシュを使用することによって最もうまく達成される。あるいは、対象の各ＭｋｔＰｉｃｔｕｒｅＴＯＣオブジェクトに対する少なくとも１つの基準をアプリケーションが常に維持しても良い。

ＭｋｔＰｉｃｔｕｒｅオブジェクトによって主に使用されるＭｋｔＬｅｖｅｌオブジェクトは、完全なマーケットピクチャの注文スタックの位置またはレベルを表わしている。このオブジェクトは、価格、全体規模、特定の規模における当事者を含む特定の価格レベルに関する情報を含む。ＭｋｔＬｅｖｅｌオブジェクトにより主に使用されるＭｋｔＰａｒｔｉｃｉｐａｎｔオブジェクトは、市場価格情報の最下位レベル部分である。ＭｋｔＰａｒｔｉｃｉｐａｎｔオブジェクトは、市場スタック内の特定のレベルの特定の注文キューに位置を占める１つの為替取引所における１つの注文を表わしている。ＭｋｔＰａｒｔｉｃｉｐａｎｔオブジェクトは、注文の発行者のユーザ識別子および当事者がクリアされるユーザ（または複数のユーザ）の識別子を示すフィールドを含む。

ときどき、コネクタに応じて、ＭｋｔＬｅｖｅｌのＴｏｔａｌＳｉｚｅは、そのレベルの当事者の合計に等しくない場合がある。これは、為替取引所の固有のＡＰＩが当事者情報を異なる速度で市場スタック情報を送るとき或いは為替取引所の固有のＡＰＩが所定数の当事者に制限されるときに起こり得る。そのような状況が検出される場合、為替取引コネクタは、そのレベルで欠けている規模を明らかにするために擬態当事者（synthetic participant）を創り出す。擬態当事者は、特定のユーザコードでフラグ立てられ、擬態当事者は特定のレベルの特定の配列の最後の当事者である。

為替取引ユーザコードは、異なる為替取引所からの価格間の差を簡単に特定するために使用される。これらにより、異なる為替取引当事者および擬態当事者は、異なる為替取引値（交換価値）を有することができる。当事者ユーザコードは、以下の形態のマスクとして構成される。
０ｘＡＥＥＵＵＵＵ
ここで、
−「Ａ」は４ビット属性マスク（擬態当事者に関して０ｘ８）である。
−「ＥＥＥ」は、Ｅｘｃｈａｎｇｅ：：ＥｘｃｈａｎｇｅＣｏｄｅフィールドに対してマッピング（写像的関連付け）する１２ビット為替取引所マスクである。
−「ＵＵＵＵ」は、１６ビットの固有のユーザコードである。１０００を上回るユーザコードが実際のユーザである。ユーザコード０ｘ０００１は、その特定の為替取引所における擬態ユーザを示す。

「１」のユーザコードは、未知の外部ユーザを示す。これは、異なる為替取引所における外部ユーザをサポートするために為替取引所コードでマスキングすることができるとともに、発信元当事者情報を維持しつつ市場の連結（合併）を可能にする。

為替取引所オブジェクトは、その為替取引所の当事者を識別するために使用されるフィールドＥｘｃｈａｎｇｅＣｏｄｅを有する。フィールドＥｘｃｈａｎｇｅ：：ＥｘｃｈａｎｇｅＣｏｄｅは、以下の形態の１２ビット値でなければならない。
０ｘ０ｘｘｘ００００
ここで、任意の「ｘｘｘ」ビットを設定できる。すなわち、（Ｅｘｃｈａｎｇｅ：：ＥｘｃｈａｎｇｅＣｏｄｅ＆〜０ｘ０ｆｆｆ０００）＝０である。

これらの値は固有のものでなければならず、また、Ｅｘｃｈａｎｇｅ：：ＥｘｃｈａｎｇｅＣｏｄｅデータベースフィールドは、各為替取引所がそれ自体の為替取引所コードを有することを要求する独自の制約を有する。

例えば、Ｂｒｏｋｅｒ１が為替取引所コード０ｘ０００１００００を有し且つＢｒｏｋｅｒ２が為替取引所コード０ｘ０００２００００を有する場合には、以下が異なるユーザコードである。
−０ｘ８００１０００１−未知のＢｒｏｋｅｒ１擬態当事者
−０ｘ０００１０３８ｅ−Ｂｒｏｋｅｒ１ユーザ１
−０ｘ０００１０３８ｆ−Ｂｒｏｋｅｒ１ユーザ２
−０ｘ８００１０３８ｅ−Ｂｒｏｋｅｒ１ユーザ２における参考の擬態当事者
−０ｘ８００２０００１−未知のＢｒｏｋｅｒ２擬態当事者
−０ｘ０００２０３８ｅ−Ｂｒｏｋｅｒ２ユーザ１
−０ｘ０００２０３８ｆ−Ｂｒｏｋｅｒ２ユーザ２
−０ｘ８００２０３８ｅ−Ｂｒｏｋｅｒ２ユーザ２における参考の擬態当事者

任意の所定の時点において、ＩＣＥシステム１００は、内部および外部で利用できる流動資産を含む連結価格フィード２６５を生成することができる。連結価格フィード２６５は各個人市場の注文ブックを含むことができるが、ユーザは、ユーザが見る許可を持つ個人市場しか見ることができない。

連結マーケットピクチャの一例として、内部為替取引所１４０が上記表１−４に示される注文を含むと仮定する。この場合、個人市場Ｃ３３０価格フィード／可視ピクチャは以下の表９に示される。

外部市場が以下のピクチャを含むと仮定する。

個人市場Ｃ３３０において示される連結価格フィードは、以下の表１２に示されるように見える。この場合、「ＩＥ」は内部為替取引所２８０における規模を示しており、「ｅ」はＢｒｏｋｅｒ１における規模を示しており、「ｂ」はＢｒｏｋｅｒ２における規模を示す。「Ｕ」は利用できない規模を示す。

明確のため、以下の価格フィードピクチャは、各為替取引所毎に各価格レベルでの個々の当事者スタックを示していない。しかしながら、実際の価格フィードは、個々の当事者リストを、これらのリストを提供する各為替取引所における全ての価格に関して含むことができる。

外部為替取引所のうちの１つが取引を開始する場合、連結価格フィード２６５はその状態を示す。例えば、売り手が１０ＭＭを提供し且つ買い手が８０ＭＭを望む状態で、Ｂｒｏｋｅｒ１が９９−１２６でトレードアップし始めると仮定する。連結価格フィード２６５は、以下に示されるように、Ｂｒｏｋｅｒ１の取引状態を反映する。

為替取引コネクタ２０５、２１０、２１５、２２０の注文処理サブシステムによって市場注文オブジェクトが使用される。これらのオブジェクトは、それらが為替取引所に置かれて操作される際に注文を監視する。

注文を形成したアダプタは、ＡＰＩコールに基づき、ＭｋｔＯｒｄｅｒオブジェクトおよびＭｋｔＴｒａｎｓａｃｔｉｏｎＴＯＣオブジェクトに対して任意の全ての操作を行なう。ユーザは、これらのオブジェクトを直接に編集してはならない−そのようにすると、不安定性がシステムに導入される可能性がある。ＭｋｔＯｒｄｅｒオブジェクトまたはＭｋｔＴｒａｎｓａｃｔｉｏｎオブジェクトにおける値を変えるため、ユーザは適切な市場コネクタＡＰＩコールを行なうことができる。

ＭｋｔＯｒｄｅｒは、１つの為替取引所でユーザが成した注文を表わしている。このオブジェクトは注文状態の要約を含む。このオブジェクトは、そのグローバルな状態を変える個々の処理によって参照される。注文自体は、所与の注文で実行される全ての低レベルな処理の統一表示である。以下は、ＭｋｔＯｒｄｅｒにおける様々な状態およびタイプコードである。

ＭｋｔＴｒａｎｓａｃｔｉｏｎは為替取引所における特定の操作を示す。処理の例としては、ＡＤＤ、ＭＯＤＩＦＹ、ＣＡＮＣＥＬが挙げられる。処理は、所与の注文に対して適用され、ＰＥＮＤＩＮＧ、ＣＯＮＦＩＲＭＥＤ、または、ＥＲＲＯＲの状態を有する。無効な操作により、ＥＲＲＯＲ処理が再びＮＵＬＬ注文を形成する。以下は、ＭｋｔＴｒａｎｓａｃｔｉｏｎ状態およびタイプコードである。

図７は、それぞれの注文の発生/消滅を制御する均等注文モデルプロセス７００における注文状態図を示す。ＡｄｄＯｒｄｅｒコマンドを用いて新しい注文が始まる。この注文は、以下のうちの１つまで存在し続ける。

・注文がキャンセルされる（ユーザまたは為替取引所のいずれかによって）。

・注文が完全に執行されて取引市場から出る。

・注文が取引市場に入って出る。

注文がワークアップの期間中に取引価格にある場合、注文は取引市場に参加すると言われる。取引市場が終了すると、注文は、未執行規模を有し、あるいは、完全に執行される。未執行規模が存在する場合には、残りの注文規模がキャンセルされ、残りの規模における新たな注文が自動的に形成される。なお、取引市場中の取引価格の背後の注文は、取引市場の一部と見なされず、取引状態の変化によって影響されない。

殆どの為替取引コネクタ２０５、２１０、２１５、２２０は、均等注文モデルを実行するために命令処理を使用する。外部為替取引所の機能に応じて、為替取引コネクタは、適切な処理でユーザの要求を知的に発注して注文モデルを維持しなければならない場合がある。命令処理は、ユーザの要求を変更して、為替取引所に適した等価なサポートされたアクションを行なう。例えば、特定のインスツルメント（instrument）に関して所与の価格で所定のサイドの１つの未執行注文だけをサポートする為替取引所では、ＡｄｄＯｒｄｅｒユーザ要求を事前の既存の注文におけるデルタ変更へと自動的に変えることができる。ユーザの要求によって生じる処理は、為替取引所で実行される本来の操作情報を含むことができる。

以下の一般的な命令トランスレータまたはその組み合わせが存在する。

Ａｄｄ−Ｔｏ−Ｍｏｄｉｆｙ−Ｕｐ−サイドおよび価格毎に１インスツルメント当たり１つの注文のみを必要とする為替取引所において、Ａｄｄ−Ｔｏ−Ｍｏｄｉｆｙ−Ｕｐトランスレータは、新しいＡｄｄＯｒｄｅｒ要求をデルタ注文変更へと加えられた量だけ変換する。例えば、１０において未執行の買呼値注文が１００−１２＋で存在する場合、ユーザは他の２０に関してＡｄｄＯｒｄｅｒを行なう。そのＡｄｄＯｒｄｅｒ要求は、当初の注文における２０の上向き変更へと変換される。

Ｄｅｌｔａ−Ｔｏ−Ａｂｓｏｌｕｔｅ−絶対的な規模における注文の配置のみをサポートする為替取引所において、Ｄｅｌｔａ−Ｔｏ−Ａｂｓｏｌｕｔｅトランスレータは、全てのデルタ注文変更を全規模における絶対的変更へと変換する。例えば、１０において未執行の買呼値注文が１００−１２＋で存在する場合、ユーザは他の２０に関してＡｄｄＯｒｄｅｒを行なう。そのＡｄｄＯｒｄｅｒ要求は、３０の全規模に対する当初の注文の変更へと変換される。

図７を参照すると、状態７０５は、注文が存在しない状態のことである。ステップ７０７では、ＩＣＥ ＡＰＩ ２２５を利用するクライアント２６０によってユーザ追加（user add）機能７０７が実行される。ユーザ追加機能７０７を実行する結果として、システムは、ユーザ追加が係属中の状態７１０へと移行することができる。追加機能の結果が追加エラー（add Error）７１２を為替取引所処理としてもたらす場合、システムは、注文が閉じられる状態７１５へと移行することができる。７１５において注文が閉じられた後、仕上げ機能のための条件が満たされて、仕上げ機能が実行され、それにより、システムは、注文追加が完全に終了される完了状態７２０へと移行する。あるいは、為替取引所で追加確認（add confirm）をもたらす為替取引所追加（exchange add）機能がうまく実行する場合には、システムが一次注文実行状態７２５へと移行する。

一次注文実行条件付状態７２５は、実際の状態ではないが、所望の条件が満たされるまで連続的に実行する状態のループである。１つのそのような条件は、ステップ７６３においてＰｅｎｄｉｎｇ Ｔｒａｎｓａｃｔｉｏｎ＝０およびＯｐｅｎＳｉｚｅ=０となるときである。この時点で、確認された注文の執行および取引に関与する状態が実行を停止して完了した注文状態７１５へと移行し、その後、仕上げ機能７１７が完了状態７２０へと移行する。

条件付状態７２５内には３つの状態がある。条件付状態７２５は注文オープン状態７３０で始まる。ユーザによって取引開始機能７３２が実行され、それにより、注文取引状態７３５が得られる。次に、ユーザが取引終了機能７３７を実行し、それにより、注文取引済状態７４０が得られる。ここで、システムは、ステップ７４４において、Ｏｐｅｎ Ｓｉｚｅがゼロよりも大きく且つＦｉｌｌｅｄ Ｓｉｚｅがゼロよりも大きいかどうかを決定する。両方の条件が満たされると、条件付状態７２５が注文を部分的に執行する。システムは、ステップ７４５において、条件付移行７４４での注文の未執行部分に関して新たな注文を形成することによってこれを修正する。これにより、執行するための注文が依然として存在する場合には、少なくとも１つの注文が取引済規模＝０を有する。注文取引済状態から、システムは、条件付ステップ７４２において、Ｔｒａｄｅｄ Ｓｉｚｅ＝０となるオープン注文があるかどうかを決定する。Ｔｒａｄｅｄ Ｓｉｚｅ＝０となる注文が存在する場合、条件付ステップは、この条件が不足し且つシステムが前述したように条件付移行７６３でＰｅｎｄｉｎｇＴｒａｎｓａｃｔｉｏｎ＝０およびＯｐｅｎＳｉｚｅ＝０であることを決定するまで、このプロセスにわたってもう一度循環することができる。

システムが実行している間、条件付ループ７２５は、所与の注文に関して全ての未執行取引を執行しようと試みる。ユーザは、３つの異なるタイプの処理、すなわち、アブソリュート変更（Abs Mod）７４７；デルタ変更(Delta Mod)７２２；または、キャンセル７７９を開始することができる。ユーザがＡｂｓ Ｍｏｄ処理７４７を開始すると、システムがＡｂｓ Ｍｏｄ Ｐｅｎｄｉｎｇ状態７５０へ移行する。Ａｂｓ Ｍｏｄ Ｐｅｎｄｉｎｇ状態７５０において、システムは、７４９で変更を確認し或いは７５９で変更に関するエラーメッセージを送信する為替取引所処理を実行する。また、為替取引所は、自動的に、７２９で要求を満たすことができ或いは７２７で確認をキャンセルすることができる。システムがＡｂｓ変更係属（Ｍｏｄ Ｐｅｎｄｉｎｇ）状態７５０にある間、ユーザは、取消処理７７９を入力してシステムをＡｂｓ変更＆取消係属（Ｍｏｄ＆Ｃａｎｃｅｌ Ｐｅｎｄｉｎｇ）状態７６０へと移行させることができる。システムがＡｂｓ変更＆取消係属状態７６０にある間、システムは、確認をキャンセルすることができ（７２７）、変更を果たすことができ（７２９）、あるいは、ユーザがキャンセルをキャンセルすることができる（７７９）。ユーザがキャンセルする場合には、係属中のキャンセルがゼロに等しくなるため、条件付処理７５８をトリガすることができる。この状態は、システムを元のＡｂｓ変更係属状態７５０へ戻すことができる。あるいは、システムは、変更を確認し（７４９）或いは変更に関するエラーメッセージを形成する（７５９）為替取引所により、Ａｂｓ変更＆取消係属状態７６０から取消継続（Ｃａｎｃｅｌ Ｐｅｎｄｉｎｇ）状態７７０へと移行することができる。その後、システムは、条件付７５８をトリガしてシステムを元の条件付ループ７２５へと移行させるために、Ｃａｎｃｅｌ Ｐｅｎｄｉｎｇ＝０となるまで取消係属状態７７０を保つことができる。

ユーザがデルタ変更（Ｄｅｌｔａ Ｍｏｄ）処理７２２を開始すると、システムがデルタ変更係属（Ｄｅｌｔａ Ｍｏｄ Ｐｅｎｄｉｎｇ）状態７９０へと移行する。デルタ変更係属状態７９０において、システムは、自動的に、７２９で要求を満たすことができ或いは７２７で確認をキャンセルすることができる。システムがデルタ変更係属状態７５０にある間、ユーザは、デルタ変更（Ｄｅｌｔａ Ｍｏｄ）処理７９３を入力することができ、それにより、注文が変化する。Ｐｅｎｄｉｎｇ Ｄｅｌｔａ Ｍｏｄｉｆｙがゼロに等しくなると、条件付処理７２４は、システムをデルタ変更係属状態７９０から元の条件付ループ７２５へと移行させることができる。あるいは、ユーザは、取消処理７７９を入力して、システムをデルタ変更＆取消係属（Ｄｅｌｔａ Ｍｏｄ＆Ｃａｎｃｅｌ Ｐｅｎｄｉｎｇ）状態７８０へと移行させることができる。システムがデルタ変更＆取消継続状態７８０にある間、システムは、確認をキャンセルすることができ（７２７）、変更を果たすことができ（７２９）、あるいは、ユーザがキャンセルをキャンセルすることができる（７７９）。ユーザがキャンセルする場合には、係属中のキャンセルがゼロに等しくなるため、条件付処理７８９をトリガすることができる。これは、システムを元のデルタ変更係属状態７９０へ戻すことができる。あるいは、システムは、移行部７８２でＰｅｎｄｉｎｇ Ｄｅｌｔａ Ｍｏｄｉｆｙがゼロに等しくなる場合、デルタ変更＆取消係属状態７８０から取消係属状態７７０へと移行することができる。その後、システムは、条件付７５８をトリガしてシステムを元の条件付ループ７２５へと移行させるために、Ｃａｎｃｅｌ Ｐｅｎｄｉｎｇ＝０となるまで取消係属状態７７０を保つことができる。

残りの可能な状態は、ユーザが取消処理７９９を条件付ループ状態７２５から入力するときに得ることができる。これが起こると、システムが状態７７０へと移行する。この状態において、為替取引所は、確認をキャンセルすることができ（７２７）、要求を満たすことができ（７２９）、あるいは、ユーザはキャンセルをキャンセルすることができる（７７９）。移行部７５８で係属中のキャンセルがゼロに等しくなると、システムは、元の条件付ループ７２５へ戻ることができ、適切なアクションが起こるのを待つことができるとともに、システムを他の状態へ移行させることができる。最終的に、全ての注文が果たされると、システムが完了状態７２０へと移行できる。

このように、本発明の基本的な新規な特徴を幾つかの実施形態に適用するように図示し、説明し、指摘してきたが、本発明の思想および範囲から逸脱することなく、図示の装置の形態および内容並びにそれらの動作における様々な省略、置換、変更が当業者によって成されても良いことは言うまでもない。１つの実施形態から他の実施形態の要素の置き換えも十分に意図され且つ考えられる。また、図面が必ずしも一定の倍率で描かれておらず、図面が実際には単なる概念的なものであることは言うまでもない。本発明は、添付の請求項およびそこに列挙されたものの等価物に関してのみ規定される

本発明の一実施形態に係る為替取引システムを示す。 図１に示される実施形態のアーキテクチャの例示である。 個人市場の階層を示す。 本発明の一実施形態に係る典型的な注文関係を示す。 図１の実施形態にしたがって注文ルータとやりとりする複数の戦略を示す。 本発明の一実施形態に係るワーキング注文の発生/消滅のプロセスを示す。 本発明の一実施形態に係るプロセスにおける注文状態図を示す。 本発明を具現化するプロセスを実施できる典型的な環境の構成要素を示す。

Claims (18)

1. 為替取引注文ルーティングのためのコンピュータベースシステムであって、
   少なくとも１つのプロセッサを有する第１のサーバと、それぞれが少なくとも１つのプロセッサを有する１つ以上の第２のサーバと、少なくとも１つのプロセッサを有するクライアント端末とを含む通信ネットワークと、
   条件列を含む注文ルーティングストラテジを構築するためのテンプレートを提供し且つ１つ以上の注文および注文ルーティングストラテジを第１のサーバに対して提示するように動作可能なエンドユーザインタフェースとを備え、
   第１のサーバは、第１の電子為替取引市場の稼動をサポートするように構成され、１つ以上の第２のサーバは、それぞれの第２の電子為替取引市場の稼動をサポートするように構成され、クライアント端末は、当該クライアント端末と第１のサーバとの間で前記エンドユーザインタフェースを形成するように構成され、
   前記通信ネットワーク内で実行でき且つ前記ルーティングストラテジにしたがって第１の電子為替取引市場で注文をクロス売買することを試みるとともに前記ルーティングストラテジにしたがってそれぞれの第２の電子為替取引市場に注文流動資産を置くことによって前記ルーティングストラテジを実施するように構成されたプログラムを備えるコンピュータベースシステム。
2. 前記条件列は、ルーティングストラテジを規定する予め定められた基準のパラメータを備える請求項１に記載のシステム。
3. 予め定められた前記基準は、過剰執行リスクファクタ、外部為替取引所の優先リスト、為替取引注文規模部分限度、内部注文インジケータ、内部注文執行時間のうちの少なくとも１つを含む請求項２に記載のシステム。
4. １つのプロセッサを有する第１のサーバで動作する第１の電子為替取引市場と、１つのプロセッサを有するそれぞれの第２のサーバで動作する１つ以上の第２の電子為替取引市場と、１つのプロセッサを有するクライアント端末で動作するエンドユーザインタフェースとを備えるコンピュータベース通信ネットワークで注文ルーティングストラテジを実施するための方法であって、
   注文に関連する数量成分、価格成分、ルーティングストラテジを規定する注文を第１の端末で受け、前記ルーティングストラテジが予め定められた基準のパラメータを備える条件列を含むステップと、
   第１の注文数量をクロス売買場所へ割り当てるために予め定められた基準パラメータにしたがって第１段階注文を処理するステップと、
   第２の注文数量を不使用場所へ割り当てるために第２段階注文を処理するステップとを含み、
   第１の注文数量がほぼ即座に執行され、不使用場所で取引が始まるときに第２の注文数量が執行され、
   事象メッセージに応じてルーティングストラテジの規則を評価する評価ステップと、
   前記評価ステップの結果に応じてルーティングストラテジの実行を変更して、クロス売買場所および不使用場所のうちの少なくとも一方で注文処理を最適化するステップとを含む方法。
5. 予め定められた前記基準パラメータにおけるクライアント端末値を受けるステップを更に含み、
   予め定められた基準は、過剰執行リスクファクタ、外部為替取引所の優先リスト、為替取引注文規模部分限度、内部注文インジケータ、内部注文執行時間のうちの少なくとも１つである請求項４に記載の方法。
6. 前記内部注文インジケータ値および前記内部注文執行時間が満たされることにより、第２段階注文処理ステップの発生前に第１段階注文処理ステップが所定時間にわたって起こり、内部注文執行時間中に更なる第１の注文数量を割り当てるステップを更に含む請求項５に記載の方法。
7. 前記事象メッセージは、価格更新、数量更新、オンラインでくる電子為替取引市場、オフラインでいく電子為替取引市場、注文状態メッセージ、ユーザ要求のうちの少なくとも１つである請求項４に記載の方法。
8. 第１の電子為替取引市場のうちの少なくとも１つ及びそれぞれの第２の電子為替取引市場のうちの少なくとも１つにおいてクロス売買レベルで注文数量の一部を動かすステップと、
   より積極的に価格設定されたクロス売買レベルに対して優先権を与えるステップと、
   予め定められた基準のうちの少なくとも１つに基づいて、注文数量の動いている部分を優先状態に置くステップとを更に含む請求項４に記載の方法。
9. 前記注文数量の動いている部分を優先状態に置く前記ステップは、動いている部分を第２の為替取引優先基準にしたがって第２の電子為替取引市場のうちの選択された１つに置く請求項８に記載の方法。
10. 前記クロス売買場所および不使用場所でクロス売買することができないときに、任意の残りの注文流動資産を外部電子為替取引所に置き、それにより、外部電子為替取引所で取引が始まるときに注文が執行するようにするステップを更に含む請求項４に記載の方法。
11. 市場が注文における価格レベルで係属中の数量を欠いていることを決定することにより、不使用場所を識別するステップを更に含む請求項４に記載の方法。
12. 過剰執行リスクファクタ基準によって注文数量を増大させるステップを更に含む請求項１１に記載の方法。
13. 前記クロス売買場所は、第１のサーバで動作される内部電子為替取引所であり、不使用場所は、それぞれの第２のサーバで動作される１つ以上の外部電子為替取引所である請求項４に記載の方法。
14. 前記不使用場所でのタイムアウト発生時に、第２の注文数量の少なくとも一部を内部為替取引所に対して割り当てるステップを更に含む請求項４に記載の方法。
15. １つ以上の外部為替取引所で注文を執行できる前に内部為替取引所に置かれる注文の係属時間を制限し、内部為替取引所で注文を執行する機会を高めるステップを更に含む請求項４に記載の方法。
16. 係属時間の満了時に、注文ルーティングストラテジを再評価するステップと、
    前記再評価ステップの結果に基づいて、１つ以上の外部為替取引所に注文を置いて、注文処理を最適化するステップとを更に含む請求項１５に記載の方法。
17. 前記クロス売買場所は、第１のサーバで動作される第１の外部電子為替取引所であり、不使用場所は、それぞれの第２のサーバで動作される１つ以上の第２の外部電子為替取引所である請求項４に記載の方法。
18. 前記ルーティングストラテジのための更新された条件列を受けるステップであって、少なくとも１つの予め定められた基準パラメータが変えられるステップと、
    更新された条件列の予め定められた基準にしたがって第１段階注文処理ステップおよび第２段階注文処理ステップを行なうステップとを更に含む請求項４に記載の方法。

Images