JP4981800B2 - パラメータを自動セキュリティオーダー実行システムに送達するシステムおよび方法 - Google Patents

Description

本出願は、2005年7月11日に出願された米国仮出願第60/698219号の利益を主張する。その仮出願の内容全体は、参照によって本明細書に組み込まれている。

セキュリティ産業では自動化が進行し続けている。特に迅速に成長する1つの分野は、ソフトウエアプログラムによるセキュリティオーダーの自動実行である。これらのプログラムは、一般的には"トレーディングアルゴリズム"として知られている。

そのようなプログラムは、入力として、オーダー情報（たとえば、セキュリティの識別子および量）、ならびにユーザが指定した好み（たとえば、最大または最小の許容可能な実行価格および対象動作時間）を取り入れる。集合的に、これらの入力はパラメータと呼ばれ、その主要機能は、（a）所望の実行目的を指定する、ならびに（b）目的の遂行において、設計者指定境界内でプログラムの行動を管理することである。これらのプログラムはまた、その動作の通常部分としてリアルタイムデータおよび履歴データを処理する。

ユーザが首尾よくトレーディングアルゴリズムにアクセスするために、ユーザは、中程度から高度に複雑なメッセージ（実際にはデータ構造）に入力をパッケージ化しなければならない。これらのメッセージは、通常、パラメータの集合から主になる。

今日、多くのセキュリティオーダー情報（およびほとんどのトレーディングアルゴリズムオーダー情報）は、金融情報交換（Financial Information Exchange）（"FIX"）として知られる産業プロトコルを介して送信者から受信者に送信される。FIXは、当初、限定された事前定義パラメータのセットと共に、オーダーのオーダーパラメータを単一セキュリティにおいて送信するように設計された。FIXの使用が、トレーディングアルゴリズムへのオーダーの送信（ならびに互いに関連して実行される複数のオーダーを送信するなどの他の応用）を含むように拡張されたとき、プロトコルは、基本的なトレーディングアルゴリズムのタイプに適応するようにある程度拡張された。
米国仮出願第60/698219号明細書 米国特許出願第11/387994号明細書 インターネット＜ＵＲＬ：www.fixprotocol.org＞

今日、はるかにより大規模で複雑なパラメータセットを必要とするいわゆる"次世代"トレーディングアルゴリズムが、出現し始めている。一般的には、そのようなトレーディングアルゴリズムのベンダは、FIXプロトコルまたは他の特別な解決法への所有の拡張を定義せずに、アルゴリズムを有望なユーザ（または、オーダーエントリソフトウエアを有望なユーザに供給する第3者のベンダ）に提供することができない。複数のベンダによって供給されたトレーディングアルゴリズムを通常使用している有望なユーザは、当然ながら、複数の所有プロトコル拡張を支持することに不本意である。ベンダでさえ、プロトコルを拡張することを好まないが、その理由は、そのような拡張により、普及および認証のサイクルのコストが高くなるからである。そのような拡張により、不適切に形成されたメッセージによるサービス欠陥の確率も増大する。

同時に、次世代トレーディングアルゴリズムのユーザは、それらのアルゴリズムの拡張機能を利用することを望むが、通常、パラメータセット全体のうち自分が選択する（すなわちカスタマイズされた）サブセットのみがオーダーの提出時間（動的パラメータ）に供給されるように指定し（インタフェースの初期セットアップの際）、一方、他のパラメータを自分が選択する事前定義（静的）値に設定し、さらに他のパラメータは指定しないとする、またはベンダが確立したデフォルト値を取ることを可能にすることを好む。提出時間（動的）値は、任意または必須とすることが可能であり、デフォルト値を有しても有してなくてもよい。ユーザはまた、初期セットアップの際、提出時間パラメータについてある範囲の許容可能な値を指定することを望む可能性がある。

ユーザはまた、以前に保存されてカスタマイズされたパラメータセットを容易に呼び出し、それらを使用して、基本となるトレーディングアルゴリズムにセキュリティオーダーを指示することができることも望む。

一態様において、本発明により、トレーディングアルゴリズムのユーザが、上述された目的を共同的に達成することが可能になる。すなわち、（a）所有プロトコルの拡張を必要とせずに、（任意の）複雑さのトレーディングアルゴリズムにアクセスすることが可能になる、（b）ユーザが、動的パラメータ対静的パラメータ（および、ユーザインタフェースレイアウトを含めて、関連する詳細）の1つまたは複数のセットを容易に識別して記憶することが可能になる、ならびに（c）パラメータの任意の所与の事前定義セットが、容易に呼び出され、オーダーを提出するために使用されることが可能になる。

他の態様では、本発明は、（a）ユーザが、カスタムトレーディング戦略を設計し、インタフェース定義を創出することを可能にするように動作可能なオーサリングツール、および（b）標準プロトコルを介して送達されたカスタム戦略オーダーメッセージを受信し、対応するカスタム戦略の定義をロードし、定義に基づいてオーダーメッセージを強化し、強化されたメッセージをトレーディング戦略宛先に渡すように動作可能な前処理プロセッサを備える、コンピュータシステムを備える。

様々な実施形態において、（1）定義は、送信および記憶のためにカスタムトレーディング戦略およびインタフェース定義を符号化するためのプロトコルを使用して符号化される。（2）標準プロトコルは、FIXプロトコルである。（3）オーサリングツールは、ユーザが1つまたは複数の入力パラメータを静的パラメータまたは動的パラメータとして指定することを可能にするように動作可能である。ならびに、（4）動的パラメータは、必須入力または任意入力としてさらに指定されることが可能である。

他の態様では、本発明は、（a）高度化アプローチ戦略の定義を受信する段階、（b）高度化アプローチ戦略の定義をデータベースに記憶する段階、ならびに（c）定義に基づいて、高度化アプローチ戦略を統合および配備する段階を備える、コンピュータ実行方法を備える。

様々な実施形態において、（1）高度化アプローチ戦略の定義は、（a）戦略名、（b）親アルゴリズムを識別するデータ、（c）マニフェスト、（d）カスタムパラメータ定義、および（e）カスタムインタフェース定義を備える。（2）マニフェストは、親アルゴリズムのパラメータのリストを列挙し、どのパラメータが静的で、どれが動的であるかを識別する。（3）親アルゴリズムは、FIXメッセージを受信するように動作可能である。（4）マニフェストは、1つまたは複数の静的パラメータ値および1つまたは複数の動的パラメータ値を備える。（5）静的パラメータ値は、静的パラメータ値がFIXメッセージにおいて定義されるであろう方式と本質的に同一の方式で転記される。ならびに、（6）動的パラメータのパスイン値が挿入されるべき位置を識別するために、プレースホルダが使用される。

他の態様では、本発明は、コンピュータ可読媒体に記憶され、かつ、グラフィカルユーザインタフェースを介してユーザがカスタムトレーディング戦略をオーサリングすることを可能にするように動作可能なソフトウエアを備え、グラフィカルユーザインタフェースは、ユーザが、（a）静的パラメータ値を固定されるように割り当てる、（b）公開される動的パラメータを識別する、および（c）動的パラメータについてデフォルト値を設定することを可能にするように構成される。

様々な実施形態において、（1）ソフトウエアは、親アルゴリズム名とマニフェストとを備えるカスタム戦略を記憶するようにさらに動作可能である。（2）マニフェストは、事前定義された静的パラメータ値および動的パラメータを識別するデータを備える。（3）マニフェストは、動的パラメータのデフォルト値を識別するデータをさらに備える。（4）グラフィカルユーザインタフェースは、ユーザが、1つまたは複数の基本アクション、1つまたは複数の条件付きアクション、および1つまたは複数の条件を識別することを可能にするようにさらに構成される。（5）マニフェストは、XMLストリングまたはFIXストリングとして記憶される。ならびに、（6）ソフトウエアは、カスタムパラメータ定義およびカスタムインタフェース定義の少なくとも一方を備えるカスタム戦略を記憶するようにさらに動作可能である。

他の態様において、本発明は、（a）ユーザがカスタムトレーディング戦略およびインタフェースを設計することを可能にするように動作可能なオーサリングツール、（b）パラメータ値を受信し、標準プロトコルを介して送信されたメッセージにその値を形成するように動作可能なオーダーエントリオブジェクトインタプリタ、ならびに（c）オーダーエントリオブジェクトインタプリタからメッセージを受信し、メッセージをデータ構造に形成し、データ構造をトレーディング戦略宛先に送信するように動作可能なデータ構造パッケージャを備える、コンピュータシステムを備える。

他の態様において、本発明は、（a）ユーザが高度化アプローチ戦略の定義を入力することを可能にするように動作可能なグラフィカルユーザインタフェースを表示する段階と、（b）高度化アプローチ戦略を定義するユーザによって入力されたデータを受信する段階と、（c）高度化アプローチ戦略の定義を親アルゴリズムに送信する段階とを備える、コンピュータ実行方法を備える。

上述された態様および実施形態は、限定を意図するものではない。当業者なら、図面および詳細な記述をレビューした後、他の態様および実施形態を認識するであろう。

本発明の好ましい実施形態は、それぞれ以下において記述される3つの密接に統合されたソフトウエアアプリケーションを備える。

第1ソフトウエアアプリケーション（"オーサリングツール"）により、戦略設計者（エンドユーザであってもなくてもよい）は、以下のことが可能になる。すなわち、
a）ベンダによって提供されたもののリストから基本トレーディングアルゴリズムを選択する。
b）どのパラメータが動的であり、どれが静的であるかを選択するプロセスにより誘導される。
c）値を静的パラメータに割り当てる。
d）デフォルト値および許容可能な範囲を動的パラメータに割り当てる。
e）適切な動的オーダーパラメータエントリテンプレートを設計する。
f）上記の要素（まとめて"オーダーエントリオブジェクト"）を名前と関連付け、オブジェクトを適切なデータベースに保存する。

データベースに記憶されているオブジェクトは、第2ソフトウエアアプリケーション（"カスタムオーダーエントリオブジェクトインタプリタ"）によってオーダーエントリの時間に可読および解釈可能であり、第2ソフトウエアアプリケーションのジョブは、以下のことである。すなわち、
a）オブジェクトに関連付けられたインタフェースを提示する。
b）続いてユーザによって入力される動的パラメータ値をインタフェースに記憶する。
c）これらの値を、FIXプロトコル（"アルゴリズムトレーディングの拡張"という名称のセクションにおいて以下で記述される、プロトコルに普遍的に適用可能な拡張によって修正されている）を介してサービスプロバイダのサイトにおいて第3ソフトウエアアプリケーションに送信することができる任意の長さのメッセージに形成する。

第3ソフトウエアアプリケーション（"FIXパッケージャ"）（またはより一般的には"データ構造パッケージャ"）の機能は、改良されたFIXメッセージを受信し（可能であれば、関連データベースから読み取られた他の情報とそれを組み合わせて）、それを有効なデータ構造に形成し、この構造を最終的なトレーディング戦略宛先に送信することである。

図１は、本発明の一実施形態の要素が共にどのように作用するかを示す。

本発明の構成要素の態様は、この分野では独立型でこれまで使用されてきた。たとえば、静的情報（データベースに記憶されている）を探索することによってトレーディングアルゴリズムを宛先とするセキュリティオーダーを強化し、静的情報をそのオーダーに添付する考えが、これまで使用されてきた。同様に、静的で非カスタマイズ可能なインタフェースが、最終的にターゲットトレーディングアルゴリズムに渡されるパラメータ値を設定するために使用されてきた。しかし、そのような方式は静的であり、さらに、（a）複雑な新しいトレーディングアルゴリズムを動的に創出および配備することができる、（b）エンドユーザの個々の要求（危険管理を含む）および好みに対して容易に適合されるそのようなアルゴリズムに対するインタフェースを有する、ならびに（c）産業標準プロトコルの頻繁な所有拡張、すなわちFIXを必要としない、という複合的な問題を解決しない。

集合的に、本発明によって創出される利益は、トレーディングアルゴリズムの能力を劇的に拡張し、新しいトレーディングアルゴリズムの概念を市場に持ち込むのにかかる時間を大きく短縮する。

「トレーディングアルゴリズム」は、命令の事前定義セットに自動的に従ってオーダーを実行するエンジンである。トレーディングアルゴリズムの例は、とりわけ、VWAP、Target Strike、CAT、およびTactExを含むLehman Brothersによって使用されるものである。これらのアルゴリズムのそれぞれは、特有の目的およびトレーディングスタイルを有するが、それぞれによりまた、アルゴリズムが特定のオーダーをどのようにトレードするかをさらに定義するために、ユーザが、ある入力パラメータを指定することも可能になる。そのような入力パラメータの例には、開始時間および終了時間、ボリューム制約、緊急度レベルなどがある。これらのパラメータにより、単一のトレーディングアルゴリズムが、様々な異なるアプリケーションに対応するために柔軟に使用されることが可能になる。

いくつかの場合、トレーディングアルゴリズムは、完全アルゴリズムに基づいて合理化された変形形態をユーザまたは開発者が創出および記憶することを可能にすることが望ましい、そのような広範なパラメータ選択肢をユーザに提示する。このプロセスは、本質的に2つのステップからなる。（1）利用可能なパラメータのサブセットを"ネイリングダウン（すなわち、事前決定および記憶）"し、次いで（2）ステップ（1）において固定されなかった残りのパラメータをユーザが入力することを可能にする簡素化されたインタフェースをエンドユーザに提示する。「カスタム戦略」が、"親"トレーディングアルゴリズム（その基盤として作用する）に関連付けられ、親アルゴリズムの事前定義パラメータセッティングのサブセット、および後に指定されることが必要な任意の他のパラメータを識別するための1セットのプレースホルダからなる。

簡単な例が、これを示す。図２は、TactExトレーディングアルゴリズムの完全インタフェースを示す。様々なトレーディングスタイルを実行するように、TactExトレーディングアルゴリズムを構成するために選択することができるパラメータの約10の異なるグループが存在する。

図３は、カスタムTactEx戦略定義の例を示す。この場合、カスタム戦略は、いくつかのパラメータを事前定義している。リミットプライス="主要より2セント下"、ディスプレイサイズ=500シェア、アクション間の時間=30秒、および無作為化の選択肢が、ディスプレイサイズおよびアクション間の時間の両方についてスイッチオンされている。残りのパラメータは、それらを除外することによって、暗示的に指定されている可能性があることに留意されたい。すなわち、カスタム戦略は、PeggingおよびConvert to Aggressiveの特徴をスイッチオフしたままとするように定義されている。

重要なことは、これらのパラメータセッティング（カスタム戦略）を一度定義し、次いでエンドユーザが、パラメータセッティングを再度タイプせずに、または完全TactExインタフェースを見ることさえせずに、戦略にアクセスすることが可能になることである。代わりに、TactExパラメータのサブセットのみをエンドユーザに公開する簡略化インタフェースをユーザに提示することができる。または、TactExアルゴリズムによって必要とされるパラメータ値が失われていない場合、エンドユーザは、インタフェースを完全に迂回し、オーダーをカスタム戦略に直接提出することができる。

2つのタイプのカスタム戦略を区別することが重要であり、決定的な区別は、オーダーを提出するとき、この戦略によって、エンドユーザが追加のパラメータを指定することが可能になるかどうかである。「高度化アプローチ」は、ユーザが追加のパラメータを指定することを可能にするカスタマイズされたインタフェースがエンドユーザに提示されるとき、使用される。「基本的なアプローチ」は、すべての必須パラメータが事前に指定され、ユーザが、インタフェースを使用せずに、オーダーをカスタム戦略に直接送信することができるとき、使用される。

「静的パラメータ」は、事前定義され、オーダーを送信するときに修正することができないパラメータである。「動的パラメータ」は、オーダーをカスタム戦略に提出するとき、エンドユーザによって指定することができるパラメータである。

基本的なアプローチでは、すべての必須パラメータは静的であり、動的パラメータは存在しない。設計者は、単に、新しいカスタム戦略（すなわち"受動（Passive）"）に名称付けし、戦略をデータベースに記憶し、システムは、"受動（Passive）"に設定された戦略名を有する任意の後継オーダーが、記憶（事前定義）されたパラメータセッティングを自動的にロードし、それらのセッティングを親アルゴリズムに渡すことによって扱われるように構成される。エンドユーザは、インタフェースを提供されない。ユーザは、単に、カスタム戦略の名称でタグ付けされたオーダーを送信する。通常、カスタム戦略は、ユーザのトレーディングワークステーション上において経路指定選択肢のメニュー内の宛先として提示される。

高度化アプローチでは、すべてではないが、いくつかの必須パラメータは静的であり、エンドユーザは、カスタムインタフェースを使用して、またはある電子プロトコルにより、動的パラメータの短いリストを設定することができる。図３の例に戻ると、設計者は、オーダーがカスタム戦略に送信されるたびに、エンドユーザがLimit Priceパラメータを修正することを可能にすることを望むことが可能である。設計者は、これを達成するために簡単なインタフェース（図４参照）を創出する。

高度化アプローチカスタム戦略は、エンドユーザのトレーディングワークステーションと統合されるカスタムグラフィカルインタフェースを提供することによって、あるいは単に仕様をエンドユーザに提供し、ユーザが自分自身のインタフェースを創出する、またはさらには必須パラメータをプログラムにより設定することを可能にすることによって、実行することができることに留意されたい。

高度化アプローチ戦略を定義することは、静的パラメータを事前定義することだけでなく（基本的なアプローチの場合のように）、ユーザが動的パラメータを設定することができるグラフィカルインタフェースおよび/または電子プロトコルを定義することも含む。各動的パラメータは、パラメータが電子的に渡されることが可能であるように、定義されて、オーダーフィールドにマッピングされなければならない。エンドユーザがカスタムインタフェースを提示される場合、レイアウト、フィールドのラベル、フィールドのタイプ、およびデフォルト値も定義されなければならない。

アプローチに関係なく、後継カスタム戦略オーダーを処理し、適切なパラメータセッティングをロードし、オーダーを親トレーディングアルゴリズムに順送りするために、ある表面下の作業が行われる。前処理プロセッサは、このタスクを実行するモジュールであり、簡略化されたカスタム戦略オーダーを複雑で完全に指定された親アルゴリズムオーダーに変換する。この変換プロセスは、親アルゴリズムの上流で行うことができる（カスタム戦略の定義、または正規戦略オーダーとカスタム戦略オーダーの区別を認識する必要はない）。高度化アプローチ戦略では、前処理プロセッサは、後継動的パラメータ値をパースし、これらの値を親アルゴリズムオーダーに組み込むことができなければならない。

このセクションの残りは、図１０に示されたフォーマットに従って新しいカスタム戦略を実行するのに必要なステップおよび構成要素を説明する。

｛ステップ１：戦略を構築するためにオーサリングツールを使用する｝
オーサリングツールは、カスタム戦略およびカスタム戦略を制御するために使用されるインタフェースを設計するために使用される対話型グラフィカル環境である。ユーザは、"親"トレーディングアルゴリズムについて入力パラメータの完全なスーパーセットを表示するグラフィカルインタフェースを提示されることが好ましい。好ましいオーサリングツールの機能および構造に関するさらなる詳細が、オーサリングツール概述のセクションにおいて以下で提供される。

各パラメータについて、オーサリングツールは、戦略設計者に3つの選択肢を提示する。
（1）静的パラメータとして指定し、所望のパラメータ値を固定（事前定義）する。
（2）動的パラメータとして指定し、カスタムインタフェースまたはある電子プロトコルを介して、必須入力としてエンドユーザに公開する。あるいは、
（3）動的パラメータとして指定し、カスタムインタフェースまたはある電子プロトコルを介して、任意入力としてエンドユーザに公開する。

基本的なアプローチ戦略では、選択肢（1）のみが利用可能であり、すべての親アルゴリズムパラメータは、静的でなければならない。

高度化アプローチ戦略が創出されるとき、オーサリングツールは、静的パラメータを事前定義するためだけでなく、どの動的パラメータが前処理プロセッサに渡されるかによってプロトコルを定義し、および（任意で）任意の必須または任意動的パラメータをユーザに公開するカスタムインタフェースを構築するためにも使用される。各動的変数について、高度化アプローチの設計者は、フィールドのタイプ（整数、ストリング、日付、時間、パーセント、実、または列挙）、ならびにインタフェースが変数を前処理プロセッサに渡すことを可能にする固有パラメータタグを定義する。設計者がカスタムインタフェースを構築している場合、設計者はまた、パラメータのラベル、デフォルト値、妥当性確認の命令、およびスクリーンのレイアウトを定義することも必要である。

｛ステップ２：新しい戦略をカスタムインタフェースと共に記憶する｝
カスタム戦略の定義は、以下の構成要素を備えることが好ましい。
・カスタム戦略名（固有ストリング識別子）
・カスタム戦略の"親"として作用するトレーディングアルゴリズム
・「マニフェスト」:すべての事前定義された静的パラメータ値、および動的と指定されたすべてのパラメータの列挙セット。これは、通常、XMLストリングまたはFIXストリングとして記憶される。
・カスタムパラメータ定義（任意、以下で定義される）
・カスタムインタフェース定義（任意、以下で定義される）

基本手法カスタム戦略では、戦略名、親アルゴリズム名、およびマニフェストのみが定義される必要がある。高度化アプローチ戦略では、カスタムパラメータ定義は、定義されなければならない。カスタムインタフェースの定義は、戦略がカスタムインタフェースを必要とする場合のみ、定義されることを必要とする。一般的には、オーサリングツールは、これらの構成要素のすべてを生成することができる。

［マニフェスト］
マニフェストは、任意のプロトコルにおいて、通常はXMLまたはFIX（金融情報交換）のフォーマットにおいて定義することができる。マニフェストは、組み込まれたXMLを有するFIXメッセージフォーマットにおいて表されることが好ましい。FIX Protocol Limitedの商標であるFIXは、電子公正トレーディングのための産業標準通信である（www.fixprotocol.org参照）。これは簡単な例示である。

図５は、"シッタ（Sitter）"と呼ばれる仮説的アルゴリズムのインタフェースを示す。戦略は、6つのパラメータを取り入れる。パラメータセッティングを渡すためにシッタアルゴリズムインタフェースによって生成されたFIXメッセージは、このように見える（エンドユーザが図５に示されたパラメータ値をタイプしたと想定する）。

847 TargetStrategy=1012
168 EffectiveTime=12:12:00
126 ExpireTime=16:00:00
957 TargetStrategyParameters= <Parameters
DisplaySize=”500”
RandomizeDisplaySize="true"
AverageTimeBetweenActions="30"
RandomizeTimeBetweenActions="true" />

このメッセージは4つの行を有し、それぞれ、その行に含まれるデータのタイプを識別する数値FIXタグで接頭辞が付けられている。第1行は、アルゴリズムを識別する（1012は、シッタアルゴリズムの固有数字IDである）。第2行および第3行は、オーダーの開始時間および終了時間を示す。168および126は、時間ホライズンを制御するための標準的なFIXタグである。

第4行（上記では5つの行に分割されている）は、追加のパラメータの集合を含むXMLストリングである。図５のインタフェースの下部セクションの4つのパラメータは、すべてこのXMLストリングに符号化される。

シッタ（Sitter）を親アルゴリズムとして使用してカスタム戦略を展開する場合、マニフェストは、上記のFIXメッセージと同様に見える。実際、カスタム戦略が、動的パラメータを有さない基本的なアプローチ戦略である場合、マニフェストは、このメッセージと同一であるが、第1行（TargetStrategy）が省略される点が異なり、その理由は、基本アルゴリズム名および新しいカスタム戦略名の両方が、カスタム戦略定義に既に含まれているからである。

高度化アプローチカスタム戦略は、動的パラメータがどのように扱われるかをさらに記述することが必要である。これは、メッセージにおけるプレースホルダにより達成される。すべての動的パラメータが、パラメータ値がメッセージにおいて現れる場所を占有するプレースホルダストリングによってマニフェストにおいて表される。各プレースホルダストリングは、|DisplaySz|など、パイプ（|）記号によって囲まれたパラメータ固有IDコードである。

たとえば、ディスプレイのサイズおよび終了時間のパラメータが動的パラメータとして指定され、すべてのその他が静的として指定された場合、マニフェストは、このように見える。

168 EffectiveTime=09:30:00
126 ExpireTime=│EndTime│
957 TargetStrategyParameters= <Parameters
DisplaySize=”│DisplaySz│”
RandomizeDisplaySize="true"
AverageTimeBetweenActions="30"
RandomizeTimeBetweenActions="true" />

この例では、EndTimeおよびDisplaySzは、次のセクションにおいて説明されるように、それらの2つのパラメータの固有識別子として選択されている。

カスタムパラメータ定義
カスタムパラメータ定義は、エンドユーザに公開される動的パラメータのそれぞれを定義するために使用される。カスタムパラメータ定義では、"繰返しグループ"データ構造を有するFIXメッセージフォーマットが、以下のように使用される。

847 TargetStrategy = <カスタム戦略の固有id>
957 NoStrategyParameters = <動的パラメータの数>
958 StrategyParameterName =“<第1パラメータの固有ID>”
959 StrategyParameterType =“<第1パラメータのタイプ>”
960 StrategyParameterValue = <第1パラメータの値>
958 StrategyParameterName =“<第2パラメータの固有ID>”
...
959 StrategyParameterType =“<第2パラメータのタイプ>”
960 StrategyParameterValue = <第2パラメータの値>
958 StrategyParameterName =“<最後のパラメータの固有ID>”
959 StrategyParameterType =“<最後のパラメータのタイプ>”
960 StrategyParameterValue = <最後のパラメータの値>

各動的パラメータは、定義に含まれなければならず、すべての3つの定義の行は、958、959、および960でタグ付けされている。

最小限、利用可能なパラメータのタイプは、以下を含むはずである。
整数（Integer） 整数
ストリング（String） テキストストリング
時間（Time） 時間フォーマット（hh:mm:ss、24時間フォーマット）
パーセント（Percent） 0から1の実
実（Real） 実数（2倍精度）
ブール（Boolean） 真または偽
プライス（Price） 実数（小数点以下4桁）>0

この最小源のセットを超えて、FIXプロトコルは、支持するために有用である量および
通貨などのいくつかの他のパラメータのタイプも同様に識別する。本実施態様の目的では、これらは省略される。

パラメータが列挙される正確なオーダーは、後継オーダーには重要ではない。前処理プロセッサは、正確なパラメータIDが供給される限り、あらゆる矛盾を選別する。

カスタムパラメータフォーマットは2つの目的を有することに留意されたい。第1の目的は、パラメータを電子的にトレーディングシステムに渡すことである。これは、オーダーを表すFIXメッセージに対してカスタムパラメータ定義を上記のFIXフォーマットに含むことによって実行される。第2の目的は、後継オーダーを正確な文脈において配置することができるように、前処理プロセッサに対する基準点として作用することである。第2の場合、戦略パラメータ値フィールドは無視される。

［カスタムインタフェース定義］
カスタムインタフェース定義は、カスタム戦略に対するカスタムインタフェースを創出する1セットの命令として使用される。このインタフェースは、様々な動的パラメータをエンドユーザに公開し、エントリを確認し、パラメータ値をオーダーに添付する。カスタムインタフェースの定義を読み、命令と一貫するインタフェースを自動的に生成するエンジンが存在することが好ましい。代替として、コンピュータ化されたスクリプトが、カスタムインタフェースの定義を読み、相応してインタフェースを構築するためにインタフェース開発者に渡すことができるインタフェーススペックを自動的に生成することが可能である。このスペックは、スクリーンのレイアウト、フィールドの定義およびラベル、妥当性確認、ならびにインタフェースフィールドからオーダーに関連付けられた動的パラメータフィールドへのマッピングを記述することが可能である。最後に、当然、カスタムインタフェースの定義は、単にそのまま開発者に渡され、インタフェースを構築するために使用することができる要件の粗セットを形成することが可能である。

カスタムインタフェースの定義プロトコルは、カスタムパラメータ定義のものと極度に類似しているが、以下の3つの追加のフィールドをフォーマットに追加する。
StrategyParameterLabel（パラメータのグラフィカルユーザインタフェース[GUI]ラベル）、
StrategyParameterControl（GUIの制御要素タイプ）、および、
StrategyParameterValidation（パラメータの妥当性確認命令）。数値FIXタグは、定義から省略されるが、その理由は、この定義は、FIX線を経て電子的に渡されるように設計されていないからである。

TargetStrategy = <カスタム戦略の固有id>
NoStrategyParameters = <公開されるパラメータの数>
StrategyParameterName =“<第1パラメータの固有ID>”
StrategyParameterType =“<第1パラメータのタイプ>”
StrategyParameterValue = <第1パラメータのデフォルト値>
StrategyParameterLabel =“<第1パラメータのGUIラベル>”
StrategyParameterControl =“<第1パラメータのGUI制御>”
StrategyParameterValidation =“<第1パラメータの妥当性確認>”
StrategyParameterName =“<最後のパラメータの固有ID>”
StrategyParameterType =“<最後のパラメータのタイプ>”
StrategyParameterValue = <最後のパラメータのデフォルト値>
StrategyParameterLabel = “<最後のパラメータのGUIラベル>”
StrategyParameterControl =“<最後のパラメータのGUI制御>”
StrategyParameterValidation =“<最後のパラメータの妥当性確認>”

任意のカスタム戦略について、カスタムパラメータ定義において定義されたパラメータとカスタムインタフェースの定義のパラメータとの間に正確な対応があることが好ましい。各定義のパラメータの数は同一であり、StrategyParameterNameおよびStrategyParameterTypeのセッティングは正確に整合する。しかし、パラメータのオーダーは、同一である必要はない。

正当なパラメータのタイプは、カスタムパラメータ定義のセクションにおいて上記で列挙されたものと同じである。StrategyParameterLabelは、GUI上においてフィールドの隣に表示されるラベルを定義し、最高で40文字の任意のストリング値を呈することができる。StrategyParameterValueは、インタフェース上に表示されるデフォルト値を定義する。エンドユーザがデフォルト値を変更しない場合、インタフェースは、他のオーダーパラメータと共にデフォルト値を自動的に渡すことが必要である。戦略パラメータ値をブランクにしておくことにより、任意のデフォルト値を表示しないようにインタフェースにオーダーする。

StrategyParameterContolは、インタフェース上においてパラメータを表すためにどのようなタイプのインタフェース制御が使用されるかについて設計者に選択肢を与える。たとえば、Timeタイプを有するパラメータについて、図６に示されるように、インタフェース上に複数の可能な制御を有することができる。

簡単化のために、制御タイプは、図７に示されるように定義されることが可能である。

このフォーマットの拡張は、追加の制御タイプ（たとえば、スライダ、さらなる時間制御など）、およびインタフェースレイアウトに対する追加の制御（パラメータのグループ、並列パラメータ、間隔など）を含むことが可能である。

カスタムインタフェース定義が創出されて記憶されるとき、インタフェース定義のみが構築されており、完全機能ユーザインタフェースは構築されていないことに留意することが重要である。インタフェースを配備するために、定義をスペックとしてインタフェース開発者に渡す、またはインタフェースの定義に基づいて完全機能インタフェースを自動的に生成する一般的なツールを創出する。

StrategyParameterValidationフィールドは、各動的パラメータの妥当性確認命令を提供する。これらの命令は、インタフェースの設計に含まれる。ストリングフォーマットが使用される。妥当性確認を指定する方法は、以下のパラメータのタイプ（すなわち、StrategyParameterType）に依存する。

＜すべてのパラメータタイプ＞
・妥当性確認が実行されない場合、単にStrategyParameterValidation=""（空のストリング）を設定する。
・＼＃配列が妥当性確認ストリングのどこかに出現する場合、パラメータは、ブランクとすることができないフィールドとして識別され、正当値が指定されなければならない。
＜ストリングタイプパラメータ＞
・|（パイプ）記号を区切り記号として使用して正当値を列挙する。
・＼＾記号配列が妥当性確認ストリングのどこかに出現する場合、場合（上方/下方）は無視される。

＜整数/実/パーセント/プライスタイプパラメータ＞
・(0,1]など、標準間隔表記を使用して有効間隔を識別するために、StrategyParameterValidationストリングを使用する。
・カンマが、最小値と最大値を分離する。
・開間隔の開始および終了をそれぞれ示すために、()記号が使用される。
・閉間隔の開始および終了をそれぞれ示すために、[]記号が使用される。
・示された最小数および最大数は、パラメータタイプを与えられた正当な単位にあるべきである。例:
○整数タイプ:"[2,10]"
○パーセントタイプ:"(0.0,0.99]"
○など
・上方境界または下方境界が存在しない場合を示すために、関連する数字を省略する。たとえば、"[0,)"は、0の下方境界を有し、上方境界を有さないパラメータを示す。
・例:
○ StrategyParameterValidation =“[1,5]”→正当値={1,2,3,4,5}
○ StrategyParameterValidation =“(1,5]”→正当値={2,3,4,5}
○ StrategyParameterValidation =“[0.0,1.0)”→正当値= {0<=X<1}
○ StrategyParameterValidation =“[1,)”→正当値={任意の正の整数}
＜時間タイプパラメータ＞
・時間（Time）タイプパラメータの妥当性確認ストリングフォーマットは、Integer/Real/Percent/Priceタイプについてと同じであり、間隔は、最小値および最大値、ならびに開間隔および閉間隔を識別する()および[]記号を使用して定義される。
・最小数および最大数は、標準時間フォーマットにあるべきであり、たとえば"[09:30:00,16:00:00]"。
・妥当性確認ストリングの最小数および最大数について特定の開始時間および終了時間を入力することに加えて、以下のコードを使用することができる。
○MO:公定市場の開時間
○MC:公定市場の閉時間
[MOおよびMCは、各オーダーについて計算される。これらは、記号（US:いくつかの為替取引きファンドは、株が終わった15分後の4:15pmに閉じる）、市場、および特別な日（たとえば、祝日の前の時短日）]を考慮に入れることが可能である。
○NOW:エンドユーザが、オーダーをトレードするためにカスタムインタフェースにアクセスする時間。
・記号の配列＼＋は、カスタムインタフェース上のすべての他の時間パラメータより厳密に大きくなければならない時間パラメータを識別するために使用される。この試験は、エンドユーザがカスタムインタフェースの"実行（Execute）"ボタンをクリックするときのみ適用される。ユーザは、時間パラメータをセッティングしている間、制約されない。
・例:設計者が、2つの時間パラメータ、Start TimeおよびEnd Timeをカスタムインタフェース上において公開するように計画する。設計者は、現在と市場が閉じるまでの間で、両方のパラメータセッティングが正当時間であることを確認することを望み、ユーザは、Start Time>=End Timeを設定することができない。さらに、フィールドをブランクにしておくことはできない。Start TimeおよびEnd Timeの妥当性確認ストリングは、それぞれ、

である。
＜ブールタイプパラメータ＞
ブールタイプ変数について妥当性確認は実行されない。

｛ステップ３：戦略およびインタフェースを配備する｝
記憶されているカスタム戦略定義（戦略名、マニフェスト、およびカスタムパラメータ定義）は、後の前処理プロセッサによって参照することができるデータベースに配置される。

所望であれば、カスタム戦略定義は、クライアントまたはエンドユーザのレベルにおいて記憶することができ、それにより、特定のエンドユーザに応じて、同じカスタム戦略名を異なる戦略定義に関連付けることができる。これによりまた、設計者が同じカスタム戦略を複数のクライアントに提供するが、それぞれについてデフォルトパラメータ値の異なるセットを記憶およびロードすることが可能になる。

記憶された後、戦略名は、エンドユーザのトレーディングシステムまたはワークステーションに配備されなければならない。基本手法戦略を配備することは、より簡単であるが、その理由は、インタフェースを統合する、またはパラメータを所望のプロトコルに翻訳することを必要としないからである。一般的には、戦略名によって識別された新しい電子宛先として、カスタム戦略をワークステーションに追加することができる。

高度化アプローチ戦略を配備することは、より複雑であるが、その理由は、インタフェースを統合すること、またはそうでない場合はクライアントがパラメータセッティングを指定することができる機構を提供することを含むからである。これらのパラメータセッティングはまた、パラメータ定義に従って、適切なフォーマットでトレーディングシステムに渡されなければならない。

インタフェースが統合される場合、以下のオーサリングツールによって指定された定義に完全に準拠しなければならない。フォーマットおよびレイアウト、パラメータの利用可能性、デフォルト値、パラメータ妥当性確認、およびパラメータの渡し。

適切に統合されているとき、エンドユーザは、ユーザが追加のパラメータを設定することを可能にするために自動的に出現する関連インタフェース（あるとすれば）で、ならびに適切なフォーマットで前処理プロセッサに渡された戦略名および任意の追加のパラメータで、オーダーをワークステーションから新しいカスタム戦略に経路指定する選択肢を有する。

｛ステップ４：後継クライアントオーダーを処理する｝
戦略定義が創出されて記憶され、戦略がエンドユーザのワークステーションに完全に配備された後、ユーザは、カスタム戦略オーダーを送信することができる。これらのオーダーに対応するために、簡略化されたカスタム戦略オーダーを複雑で完全に指定された親アルゴリズムオーダーに変換する前処理プロセッサ構成要素が使用されることが可能である。

後継オーダーは、前処理プロセッサを経て経路指定され、前処理プロセッサは、後継戦略名を読み、次いで、可能であればエンドユーザ名に応じて、適切なカスタム戦略定義をデータベースからロードする。前処理プロセッサは、戦略定義をロードし、パスインパラメータ（あるとすれば）を組み込み、完全に指定されたオーダーを親トレーディングアルゴリズムに渡す。マニフェストのフォーマットは、親アルゴリズムを制御するために使用されるFIXフォーマットと非常に類似して出現するように選択されるので、前処理プロセッサは、単に、動的パラメータの任意のパスイン値を適切な場所（プレースホルダによって確定される）においてマニフェストに直接接合し、結果として得られるマニフェストFIXメッセージをオーダーに付加し、次いでオーダーを親アルゴリズムに渡すことが必要であることに留意されたい。

厳密には、ステップ４は、実際には、新しいカスタム戦略を創出する一部ではないことに留意されたい。すなわち、戦略が構築、記憶、および配備された後、新しい戦略について後継オーダーを扱うために前処理プロセッサを準備する追加のステップは存在しない。

［カスタム戦略の例］
アクションにおけるフレームワークを示すために、TactExアルゴリズムに基づくサンプルカスタム戦略が使用される。図８は、戦略の定義を示す。白いフィールドは、ネイルダウン（事前定義）パラメータを示す。影付きのフィールドは、カスタムインタフェースを介してエンドユーザに公開されるパラメータを示す。Trigger Price DiffおよびTrigger Sizeのパラメータについて、インタフェースにおいて表されるデフォルト値が定義されている。

戦略定義は、5つの部分からなる。
1.戦略名（すなわち"Peg/Step In Front"）、
2.親アルゴリズム（TactEx）、
3.マニフェスト、
4.カスタムパラメータ定義、および、
5.カスタムインタフェースの定義。

マニフェストは、TactExアルゴリズムパラメータの完全なリストを列挙し、どれがネイルダウンされており、どれをエンドユーザによって設定することができるかを識別する。
ネイルダウン エンドユーザに公開
Start Time（=1日の開始） Limit Price
End Time（=1日の終了） Convert After Min
Limit Price Type（=絶対的） Trigger Price（デフォルト2セント）
Stop Price（=ブランク/適用可能ではない） Trigger Size（デフォルト1000）
Stop Price Type（=絶対）
Display Size（=500）
Display Size Randomized?（=真）
Time Between Actions（=30秒）
Time Between Actions Randomized?（=真）
Convert to Aggressive?（=真）
Convert After Sec（=ブランク）
Pegging Enabled?（=真）
Peg Anchor（=1次）
Peg Offset（=1セントだけ前のステップ）
Trigger Price Diff Type（=セント）

FIXメッセージフォーマット（読みやすいように数値FIXタグを省略）では、マニフェストは、以下のようになる。

EffectiveTime=09:30:00
ExpireTime=16:00:00
RestrictionType=1
RestrictionDirection= 1
RestrictionScope=1
RestrictionLimitPrice= │LimitPrice│
RestrictionType=2
RestrictionMovementType=1
RestrictionPriceType=1
RestrictionMovement=1.0
TargetStrategyParameters=<Parameters DisplaySize=”500”
RandomizeDisplaySize="true" AverageTimeBetweenActions="30"
RandomizeTimeBetweenActions="true" MinTilAggressive="│ConvertMin│"
TriggerPriceDiff="│PriceTrigger│" TriggerPriceDiffType="Price"
TriggerSize="│SizeTrigger│" />

カスタムパラメータ定義は、以下のようになる（再び、FIXタグを省略）。

TargetStrategy =“Peg/Step In Front”
NoStrategyParameters = 4
StrategyParameterName =“LimitPrice”
StrategyParameterType =“Price”
StrategyParameterValue = <ここではプライス値>
StrategyParameterName =“ConvertMin”
StrategyParameterType =“Integer”
StrategyParameterValue = <ここではプライス値>
StrategyParameterName =“PriceTrigger”
StrategyParameterType =“Integer”
StrategyParameterValue = <ここではプライス値>
StrategyParameterName =“SizeTrigger”
StrategyParameterType =“Integer”
StrategyParameterValue = <ここではプライス値>

図９は、クライアントに公開されるカスタムインタフェースを示す。4つの公開されたパラメータは、ラベルおよび任意の所望のデフォルト値と共に、インタフェース上に配置される。

この特定のインタフェースのカスタムインタフェースの定義は、以下の通りである。

TargetStrategy =“Peg/Step In Front”
NoStrategyParameters = 4
StrategyParameterName =“LimitPrice”
StrategyParameterType =“Price”
StrategyParameterValue =“”
StrategyParameterLabel =“Optional Limit Price:”
StrategyParameterControl =“Price”
StrategyParameterValidation =“(0.0,)”
StrategyParameterName =“ConvertMin”
StrategyParameterType =“Integer”
StrategyParameterValue =“”
StrategyParameterLabel =
“Convert to Aggressive Order after (min):”
StrategyParameterControl =“Integer”
StrategyParameterValidation =“[1,]”
StrategyParameterName =“PriceTrigger”
StrategyParameterType =“Integer”
StrategyParameterValue = 2
StrategyParameterLabel =“Peg Trigger Price Diff (cents):”
StrategyParameterControl =“Integer”
StrategyParameterValidation =“[1,]”
StrategyParameterName =“SizeTrigger”
StrategyParameterType =“Integer”
StrategyParameterValue = 1000
StrategyParameterLabel =“Peg Trigger Size (shares):”
StrategyParameterControl =“Integer”
StrategyParameterValidation =“[ 1,]”

図１０は、カスタム戦略を構築するための好ましいステップ（上述された）を示す。

［オーサリングツールの概述］
このセクションは、Conditional Auto Trader（"CAT"）親アルゴリズムに基づいてカスタム戦略を創出するために使用されることが可能である好ましいオーサリングツールを記述する。Conditional Auto Trader（CAT）は、設計者がカスタム実行アルゴリズムをその場で構築することを可能にする適応性のツールキットである。各CAT戦略は、4つの構成要素からなる。
（a）オーダーについての全体的な時間ホライズン（Time Horizon）、開始時間および終了時間を備える。
（b）Base Action、オーダーを実行するために当初使用されたアルゴリズム（または他のアクション）。
（c）Conditional Action、事前定義された市場条件下においてトリガされる第2のアルゴリズム（または他のアクション）。および、
（d）Condition、条件付きアクションがいつおよびどのようにしてトリガされるかを管理する１セットの規則。

CATに関するさらなる詳細について、内容全体が参照によって本明細書に組み込まれている2006年3月22日に出願された"Methods and Systems for Conditional Auto Trading"という名称の同時係属米国特許出願第11/387994号を参照されたい。この記述は親アルゴリズムとしてのCATを対象としているが、当業者なら、記述は、適切に修正されて、他のトレーディングアルゴリズム（たとえば、TactEx）にも適用されることを認識するであろう。

オーサリングツールは、カスタム戦略およびカスタム戦略を制御するために使用されるインタフェースを設計するのに使用される対話型グラフィカル環境である。オーサリングツールインタフェースは、一見、CATアルゴリズムのユーザインタフェースと極めて同様に見える（図１１参照）。両方のインタフェースとも、ユーザにCATアルゴリズムパラメータの完全なセットを提示し、ユーザがパラメータ値を設定することを可能にするグラフィカル制御を提供する。1つの違いは、CATアルゴリズムインタフェースは、パラメータ値を指定し、次いでオーダーをCATに送るためにトレーダによって使用され、一方、カスタムCAT戦略オーサリングツールは、カスタム戦略と、記憶し、次いでトレーダによって繰り返して使用することができる付随する（任意で）カスタムグラフィカルインタフェースとを構築するために戦略設計者によって使用されることである。

CATアルゴリズムインタフェースは、4つのタブ（Time Config、Base Action、Condition、およびConditional Action）の周りに組織化され、各タブは、様々なパラメータに対応する。Base ActionおよびConditional Actionのタブに関して見ることができるパラメータは、ドロップダウンメニューを使用してタブの上部において指定されたアクション選択肢にさらに依存する。同様に、条件タブ上で利用可能なパラメータは、タブの上部においてドロップダウンメニューから利用可能な条件タイプ選択肢に依存する。CATオーサリングツールは、同じ4タブ組織構造を有することが好ましい。

CATアルゴリズムインタフェースにより、ユーザ（トレーダ）は、パラメータ値を設定し、次いで、"OK"ボタンをクリックして、すべてのパラメータ値セッティングと共にオーダーをCAT（または他のトレーディングアルゴリズム）に送信するすることが可能になる。CATオーサリングツールによりまた、パラメータ値が設定されることが可能になるが、さらに、ユーザ（設計者）は、パラメータを静的および動的の2つのグループに分類することが可能になる。静的パラメータは、カスタム戦略によって処理されるすべてのオーダーについて値を事前定義し、固定する。動的パラメータは、エンドユーザに公開され、オーダーごとに修正することができる。本明細書のカスタム戦略概念セクションにおいて記述されるように、各利用可能なCATアルゴリズムパラメータについて、オーサリングツールは、好ましくは設計者に3つの選択肢を与える。
（4）静的パラメータとして指定し、所望の値を固定（事前定義）する。
（5）動的パラメータとして指定し、カスタムインタフェースまたはある電子プロトコルを介して、必須入力としてエンドユーザに公開する。
（6）動的パラメータとして指定し、カスタムインタフェースまたはある電子プロトコルを介して、任意入力としてエンドユーザに公開する。

オーサリングツール内において、すべてのパラメータを定義し、固定することができる（上記の選択肢（1））が、あるパラメータのみをトレーダに公開することができる（選択肢（2）または（3））。たとえば、基本アクション、条件付きアクション、または条件の選択肢は、カスタム戦略において固定されなければならず、それらの選択肢は、トレーダに公開することはできない。公開することができるフィールドは、小さいチェックボックス（□）アイコンを使用して識別される（図１２参照）。各チェックボックス可能フィールドについて、設計者は、4つの選択肢を有する。
1.パラメータを静的と指定し、その値を入力し（またはデフォルト値を受け取り）、チェックボックスにチェックを入れないとすることによってある値を固定する。
2.パラメータを静的と指定し、パラメータフィールドをブランクとし、チェックボックスにチェックを入れないとすることによってブランク値を固定する。あるCATパラメータが、アルゴリズムによって必要とされ、これらのパラメータについて、値を入力しなければならない。必須フィールドについてブランク値を固定する試行は、エラーメッセージをもたらす。
3.パラメータを動的と指定し、デフォルト値を有さないカスタムパラメータとして、パラメータをエンドユーザ[トレーダ]に公開する。これを実行するために、設計者は、チェックボックスにチェックを入れるが、パラメータフィールドはブランクとする。
4.パラメータを静的と指定し、デフォルト値を有するカスタムパラメータとして、パラメータをエンドユーザ[トレーダ]に公開する。これは、デフォルト値をフィールドにおいて入力し、次いでチェックボックスにチェックを入れることによって達成される。戦略のカスタムインタフェースがトレーダに提示されるとき、パラメータは、設計者が指定したデフォルト値に関係なく、インタフェース上で公開される。

アルゴリズムインタフェース上において見られないボタンがオーサリングツールインタフェース上にある。
Preview-これまでのカスタムインタフェースを見る
Compile-戦略およびインタフェースを創出および記憶し、任意の必須フィールドがブランクのままである場合、エラーメッセージを生成する。必須フィールドは、それらが選択されている場合のみ、ブランクとままとすることができる（この場合、カスタムインタフェースはデフォルト値を表示しない）。

図１３は、設計者がパラメータフィールドを埋めている際に、好ましいCATオーサリングツールスクリーンがどのように見える可能性があるかという例を示す。図１３は、条件スクリーンを示す。設計者は、Size On Opposite Side条件を選択した。条件タイプ（ならびに基本アクションタイプおよび条件付きアクションタイプ）は、カスタム戦略について事前定義されなければならないことを思い出されたい。このスクリーン上では、ユーザは、設定される７つのパラメータを有する。動的パラメータとして公開することができる２つのパラメータが存在する。

設計者は、このフィールドのチェックボックス1310をクリックすることによって、第1パラメータのみを動的として指定することを選択した（サイズ閾値）。選択されるとき、ボックスは、色が変化し、Xでマークされる。ユーザは、このパラメータについて1000のデフォルト値を指定した。スクリーン上の他のパラメータは静的であり、Size Threshold Type=Shares、Range Threshold=1、Range Threshold Type=Cents、Range Anchor=Midpoint、One Shot=False、およびMin Cycle Time=1分30秒。設計者の最終的なカスタム戦略では、これらのパラメータのすべてが固定され、トリガサイズを除いて、トレーダから隠さる。トリガサイズは、1000シェアのデフォルト値で、トレーダによって修正可能である（カスタムインタフェースから、またはパラメータ値を後継オーダーと共にプログラムにより渡すことによって）。

アプリケーションは、必須パラメータと任意パラメータを区別する。親アルゴリズム（たとえば、CAT）によって必要とされるパラメータは、設計者によって事前に固定されなければならない、またはオーダーを提出するとき、ユーザによって埋められなければならない。必須パラメータについて、ブランク値は許可されない。したがって、必須変数がカスタムインタフェース上においてトレーダに公開される場合、ブランクのままである必須パラメータでユーザがオーダーを実行することを試行することを防止するために、妥当性確認が実行されなければならない。カスタム戦略概念セクションで本明細書において記述された規定に従って、＼＃配列は、パラメータを必要であると識別する任意の必須パラメータについて、戦略パラメータ妥当性確認フィールドにおいて使用される。

［CATアルゴリズムについて必須パラメータのリスト］
（1）すべてのカスタムCAT戦略について必須パラメータ
・Start TimeおよびEnd Time
・Base Actionの選択肢（たとえば、VWAP、Target Strikeなど）;
・Conditionの選択肢（たとえば、プライス条件）、および、
・Conditional Actionの選択肢（たとえば、VWAP、Target Strikeなど）
（2）基本アクションの選択肢を与えられた必須パラメータ

（3）条件の選択肢を与えられた必須パラメータ

（4）条件付きアクションの選択肢を与えられた必須パラメータ

設計者が、基本アクション、条件付きアクション、または条件の選択肢を切り替える場合、以前の選択肢に関して行われた任意のパラメータ選択肢は消去されることに留意されたい。

たとえば、図１３では、設計者は、指定されたトリガサイズをトレーダに公開される動的パラメータとして選択した。次いで、設計者が異なる条件タイプを選択する場合、オーサリングツールは、新しい条件スクリーンに切り替える前に、このSize On Opposite Side条件スクリーン上ですべての動的（チェック入り）パラメータを消去する。すなわち、選択された/条件付きアクションタイプおよび条件タイプに関するパラメータのみが、トレーダに動的パラメータとして公開可能である。

［カスタムCAT戦略をオーサリングするステップ］
1.オーサリングツールインタフェースを使用して、カスタム戦略のスケルトンを形成する基本アクションおよび条件付きアクションのタイプ（たとえば、VWAP）ならびに条件（たとえば、プライス条件）のタイプを選択する。この時点において、固定（静的パラメータ）または公開（動的パラメータ）するために利用可能なパラメータのセットは、4つのタブのそれぞれの上で示されるパラメータに限定される。
2.各タブについて、オーサリングツールインタフェースを使用して、所望の静的パラメータ値を固定されるように割り当てるためにする。パラメータのいくつかは、明示的に編集ボックスにタイプされることが必要である。その他は、プルダウンメニュー、ラジオボタン、またはチェックボックスを使用して選択されることが必要である。
3.各タブについて、影付きのチェックボックスをクリックして、動的パラメータとしてクライアントに公開される任意のパラメータを識別し、所望であればデフォルト値を指定する（例として図１３参照）。
4.カスタムインタフェースをプレビューするために、"Preview"ボタンをクリックする。
5.戦略およびインタフェースを保存するために、"Compile"をクリックする。

［オーサリングツールを使用して、カスタムCAT戦略およびインタフェースを定義する］
このセクションは、インタフェースを経てスクリーンごとに進行し、どのフィールドを動的パラメータとしてクライアントに公開することができるかを識別する。各公開可能なフィールドについて、カスタムパラメータ定義およびカスタムインタフェースの定義の必須要素が以下のように定義される。パラメータID、パラメータタイプ（整数、実、ストリングなど）、GUI（グラフィカルユーザインタフェース）上でパラメータを識別するためのラベル、GUI要素タイプ（編集ボックス、チェックボックスなど）、およびパラメータの任意の妥当性確認命令。これらの定義に関するさらなる情報に関して、カスタム戦略概念セクションを参照する。

［時間構成タブ］
図１４を参照されたい。このタブは、3つの公開可能なパラメータを特徴とする。

ラジオボタンの2つのバンクは、顧客に公開可能ではない他のパラメータ選択肢を表すことに留意されたい。たとえば、開始時間について、設計者は、"Start of Day/Now"と正確な時間のラジオボタン選択を作成しなければならない。ユーザが"Start of Day/Now"を選択する場合、開始時間は固定され、正確な時間パラメータをトレーダに公開することはできない。一方、設計者が正確な時間のラジオボタンを選択する場合、設計者は、時間を固定する選択肢（影付きチェックボックスにチェックを入れないとする）、または正確な時間制御をトレーダに公開する選択肢（デフォルト値を有してまたは有さずに）を有する。終了時間は、同様に作用する。これは、たとえば、設計者が、正確な終了時間パラメータおよび持続時間パラメータの両方をトレーダに同時に公開することができないことを意味する。

最大持続時間（MaxDuration）は、Mkt Close Time-MAX（Mkt Open Time、Time Now）（整数分において）として定義される。

基本アクションタブおよび条件付きアクションタブ
5つの可能な基本アクションおよび6つの可能な条件付きアクションが存在し、それぞれ以下において列挙される。各選択肢は、別々に議論され、選択されたアクションについて公開可能なパラメータを定義する。
基本アクション 条件付きアクション
VWAP VWAP
With Volume With Volume
Target Strike Target Strike
TWAP TWAP
Idle FastExec
Idle

戦略選択肢は、トレーダに公開されない。すなわち、ユーザが基本戦略としてVWAPとWith Volumeとの間で選択することを可能にする缶入り戦略は創出されない。この選択肢は、戦略が設計される前に作成されなければならない。また、各アクションは、公開可能な要素のそれ自体のセットを有するが、選択された基本アクションおよび条件付きアクションに関する選択のみが適用される。たとえば、ターゲットストライクベースアクションが選択され、選択肢が緊急度スライダに公開され、その後、With Volumeベース戦略に変更する場合、Target Strike緊急度スライダ要素のチェックマークは、自動的に消去される。

Idleの基本アクションおよび条件付きアクションの選択肢は、パラメータを有さない。

［相対リミットプライスに関する留意］
リミットプライスの2つのタイプ、絶対および相対が、Idleを除くすべての基本アクションおよび条件付きアクションによって支持される。相対プライスリミットが選択される場合（すなわち、"絶対プライス"以外の任意の選択肢が、基本/条件付きアクションスクリーン上のドロップダウンメニューから選択される場合）、以下の相対リミットプライス選択肢が利用可能である。[cents/bps][better/worse than][Arrival Price/VWAP/Open/Prev Close/Arrival Opp Side/Arrival Same Side/Strike Price]（たとえば、可能な相対リミットプライス選択肢は、"cents better than VWAP"または"bps worse than Arrival Opp Side"を含む）。

相対プライスリミットが使用され、設計者がLimit Priceフィールドをトレーダに公開することを選択する場合、選択された相対リミットプライスタイプがリミットプライスのGUIラベルに添付されるはずである。たとえば、設計者が、"Arrival Priceより悪いbps "でリミットプライスタイプを相対と固定する場合、リミットプライスのGUIラベルは、"Limit Price（Arrival Priceより悪いbps）"であるはずである。

リミットプライス（Limit Price）パラメータフィールドのパラメータタイプ、GUI要素タイプ、および妥当性確認ストリングは、以下の表に示されるように、プライスリミットタイプに依存する。

［基本アクションタブ:VWAP］
図１５を参照されたい。このタブは、2つの公開可能なパラメータを特徴とする。

2つの公開可能なフィールドに加えて、設計者は、このスクリーンから2つの他のパラメータセッティングを固定することができる。"Aggressive Completion"チェックボックスおよびリミットプライスタイプ（リミットプライスタイプに関する上記の議論および相対リミットプライスタイプについて添付のGUIラベルを参照されたい）。"Apply to Full Order"ボックスは、CATアルゴリズムインタフェースの一部ではないことに留意されたい。このボックスにチェックが入っている場合、指定されたリミットプライスは、基本アクションおよび条件付きアクションの両方に適用される（条件付きアクションがアイドルではない限り）。

［基本アクションタブ:TWAP］
図１６を参照されたい。このタブは、2つの公開可能なパラメータを特徴とする。

2つの公開可能なフィールドに加えて、設計者は、このスクリーンから2つの他のパラメータセッティングを固定することができる。"Aggressive Completion"チェックボックスおよびリミットプライスタイプ。

［基本アクションタブ:With Volume］
図１７を参照されたい。このタブは、2つの公開可能なパラメータを特徴とする。

2つの公開可能なフィールドに加えて、設計者は、リミットプライスタイプを固定することができる。

［基本アクションタブ:Target Strike］
図１８を参照されたい。このタブは、3つの公開可能なパラメータを特徴とする。

3つの公開可能なフィールドに加えて、設計者は、リミットプライスタイプを固定することができる。

スライダを表す有効なGUI要素タイプが存在する場合、それが代わりに使用されるはずである。この場合、正の整数入力を有する編集ボックスが使用される。

［条件付きアクションタブ:VWAP］
図１９を参照されたい。このタブは、3つの公開可能なパラメータを特徴とする。

3つの公開可能なフィールドに加えて、設計者は、このスクリーンから以下の3つの他のパラメータセッティングを固定することができる。時間構成ラジオボックス（"Until the End of the Order"または"Minutes"）、"Aggressive Completion"チェックボックス、およびリミットプライスタイプ。"Until the End of the Order"ラジオボックスが選択される場合、持続時間（分）パラメータはトレーダに公開されない。

基本アクション"Apply to Full Order"ボックスにチェックが入っている場合、条件付きアクションタブ上のLimit Price編集ボックス（ならびに関連するドロップダウンメニューおよび影付きチェックボックス）は不能にされるはずである。次いで、基本アクションリミットプライスが、同様に条件付きアクションに適用される。

［条件付きアクションタブ:TWAP］
図２０を参照されたい。このタブは、3つの公開可能なパラメータを特徴とする。

3つの公開可能なフィールドに加えて、設計者は、このスクリーンから以下の3つの他のパラメータセッティングを固定することができる。時間構成ラジオボックス（"Until the End of the Order"または"Minutes"）、"Aggressive Completion"チェックボックス、およびリミットプライスタイプ。

基本アクション"Apply to Full Order"ボックスにチェックが入っている場合、条件付きアクションタブ上のリミットプライス編集ボックス（ならびに関連ドロップダウンメニューおよび影付きチェックボックス）は、不能にされるはずである。次いで、基本アクションリミットプライスが、同様に条件付きアクションに適用される。

［条件付きアクションタブ:With Volume］
図２１を参照されたい。このタブは、2つの公開可能なパラメータを特徴とする。

2つの公開可能なフィールドに加えて、設計者は、リミットプライスタイプを固定することができる。

基本アクション"Apply to Full Order"ボックスにチェックが入っている場合、条件付きアクションタブ上のリミットプライス編集ボックス（ならびに関連ドロップダウンメニューおよび影付きチェックボックス）は、不能にされるはずである。次いで、基本アクションリミットプライスが、同様に条件付きアクションに適用される。

［条件付きアクションタブ:ターゲットストライク］
図２２を参照されたい。このタブは、3つの公開可能なパラメータを特徴とする。

3つの公開可能なフィールドに加えて、設計者は、リミットプライスタイプを固定することができる。

スライダを表す有効なGUI要素タイプが存在する場合、それが代わりに使用されるはずである。この場合、正の整数入力を有する編集ボックスが使用される。

基本アクション"Apply to Full Order"ボックスにチェックが入っている場合、条件付きアクションタブ上のリミットプライス編集ボックス（ならびに関連ドロップダウンメニューおよび影付きチェックボックス）は、不能にされるはずである。基本アクションリミットプライスが、同様に条件付きアクションに適用される。

［条件付きアクションタブ:Fast Exec］
図２３を参照されたい。このタブは、5つの公開可能なパラメータを特徴とする。

5つの公開可能なフィールドに加えて、設計者は、リミットプライスタイプ、スイーププライスタイプ（以下を参照）、アグレッシブネス選択肢（"Limit Sweep"または"2 minutes VWAP"）、およびRandomize Time/Size選択肢を固定することができる。

スイーププライスタイプは、以下のフォーマットを取ることが好ましい。[Midpoint/Opp Side/Same Side]からの[Cents/BPS/%/%Av Sprd]。デフォルト選択肢（図２３に示す）は、"Cents from Midpoint"である。他の選択肢は、"BPS from Opp Side"または"% Av Sprd from Same Side"を含むことが可能である。関連する編集ボックスがクライアントに公開される場合（上記の表の"Sweep Price"）、スイーププライスタイプが、GUIラベルとしてそのまま使用されるはずである。スイーププライスがセントで表示される場合、パラメータタイプおよびGUI要素タイプはIntegerであり、妥当性確認ストリングは"(0,)"である。そうでない場合、パラメータタイプおよびGUI要素タイプはRealであり、妥当性確認ストリングは"(0,0)"である。

"Link to Condition"チェックボックスのどちらかにチェックが入っている場合、パラメータの編集制御は不能になり（任意の関連ドロップダウンメニューおよび影付きチェックボックスと共に）、関連パラメータは、Size on Opposite Side条件からのパラメータ値を反映する。"Number of Shares"パラメータは、Size on Opposite Side条件スクリーン上の第1編集ボックス（"Size Threshold"）に連結される。"Sweep Price"パラメータ（およびすべての関連ドロップダウンメニュー）は、Size on Opposite Side条件スクリーン上の"within"編集ボックスに連結される。Size on Opposite Side条件スクリーン上に入力されたパラメータ値は、連結パラメータについてFast Execスクリーン上に表示される必要はないことに留意されたい。連結パラメータの編集制御は、単に不能にされるはずである。

Size on Opposite Side以外の任意の条件タイプが現在選択されている場合、両方の"Link to Condition"チェックボックスが不能になる。さらに、Size on Opposite Side条件スクリーン上の"Size Threshold"が、シェア以外の任意のもので現在表示されている場合（ドロップダウンメニューに基づいて）、Fast Execスクリーン上の"Number of Shares"パラメータの隣の"Link to Condition"チェックボックスは、不能にされるはずである。同様に、どちらかの"Link to Condition"チェックボックスにチェックが入った後は、設計者は、まず"Link to Condition"チェックボックスのチェックを外さずに、異なる条件タイプに切り替えることはできない。最後に、"Number of Shares"パラメータの隣の"Link to Condition"チェックボックスにチェックが入っている場合、設計者は、Size on Opposite Side条件スクリーン上の"Size Threshold"の表示を変更することはできない。

基本アクション"Apply to Full Order"ボックスにチェックが入っている場合、条件付きアクションタブ上のLimit Price編集ボックス（ならびに関連ドロップダウンメニューおよび影付きチェックボックス）は、不能にされるはずである。次いで、基本アクションリミットプライスが、同様に条件付きアクションに適用される。

［条件タブ］
条件タブは、6つの選択肢を提供し、それぞれが、関連パラメータフィールドのそれ自体のセットを有する。
［条件］
Price Condition
Time Condition
Size on Opposite Side Condition
Bid/Ask Spread Condition
Relative Return Condition
Filled Size Condition

条件の選択肢は、設計者によって固定されなければならず、缶入り戦略についてオーダーを提出するとき、トレーダに公開することはできない。基本/条件付きアクションタブと同様に、設計者が特定の条件を選択するとき、あらゆる他の条件スクリーン上で固定または公開されたあらゆるパラメータが、自動的に消去される。したがって、たとえば、設計者が時間条件を選択し、持続時間タブをトレーダに公開し、次いで新しい条件タブを選択する場合、時間条件持続時間パラメータはトレーダに公開されない。

［条件タブ:プライス条件］
図２４を参照されたい。このタブは、2つの公開可能なパラメータを特徴とする。

これらのパラメータに加えて、設計者は、いくつかの他のパラメータを固定することができる。
・第1プライス条件
○記号（トレードされている記号を示すために、ブランクのままとすることが可能である）
○オペレータ(> / <)
○トリガプライスタイプ:絶対または相対（以下を参照）
・第2プライス条件
○第2条件可能/不能（チェックボックス）
○2つの条件を組み合わせるためのAND/ORオペレータ選択肢
○記号（トレードされている記号を示すために、ブランクのままとすることが可能である）
○オペレータ(> / <)
○トリガプライスタイプ:絶対または相対（以下を参照）
・ワンショットチェックボックス
・最小サイクル時間（分値）

設計者は、第2プライストリガ条件に関係する任意のものを公開することができないことに留意されたい。第2条件に関連するパラメータ選択肢のすべてを固定することができるが、公開することはできない。

基本/条件付きアクションについてのリミットプライスの場合のように、プライス条件のトリガプライスは、絶対プライス（たとえば、"$38.50"）または相対プライス（たとえば、"入荷プライスより75bps上"）として指定することができる。図２４は、絶対トリガプライスタイプを示す。図２５は、相対的トリガプライスタイプを示す。相対トリガプライスタイプは、以下のフォーマットを取る。[Arrival Price/VWAP/Prev Close/Open/Ord Limit Price][+/-]X[Cents/BPS]。たとえば、"VWAP-25Cents"。相対または絶対トリガプライスタイプについて、設計者は、1つのパラメータのみをトレーダに公開することができる。プライス（絶対トリガプライス）、または相対トリガプライスについてのセント/bpsのオフセット数を含む編集ボックス。

パラメータタイプ、GUI要素タイプ、GUIラベル、およびこのパラメータの妥当性確認に関する詳細について、本明細書では相対リミットプライスに関する留意という名称のセクションを参照する。1つの追加の詳細、第1プライス条件の記号が入力されている場合（ブランクのままではなく）、トリガプライスのGUIラベルは、この記号で接頭辞が付けられるはずである（たとえば、"SPY Trigger Price"）。また、Price Triggerパラメータが必要とされ、したがって、妥当性確認フィールドは、＼＃記号配列で開始されるはずである。

［条件タブ:時間条件］
図２６を参照されたい。このタブは、1つの公開可能なパラメータを特徴とする。

さらに、設計者は、以下の3つの追加の変数を突き止めることが必要である。正確な時間と相対時間の間のラジオボタン選択肢、正確な時間（選択されている場合）、および相対時間タイプ。相対時間タイプは以下の3つの選択肢を有する。オーダー開始時間後の分、オーダー終了時間前の分、または市場閉鎖前の分。この相対時間タイプは、DurationのGUIラベルに添付されるべきである（たとえば、"Time Trigger（終了時間前の分）"）。

［条件タブ:Size on Opposite Side Condition］
図２７を参照されたい。このタブは、3つの公開可能なパラメータを特徴とする。

さらに、設計者は、5つの他のパラメータ（すべて静的）を定義することができる。
・Size Threshold Type（Shares、% Target Size、% Residual Size、% Typical Size）
・Range Threshold Units（Cents、BPS、% Typical Spread）
・Range Anchor（Midpoint、Opp Side of Quote、Same Side of Quote）
・ワンショットチェックボックス
・Min Cycle Time（分）

Size Threshold Typeが"Shares"である場合、Size ThresholdパラメータタイプおよびGUI要素タイプはIntegerであり、妥当性確認ストリングは

である。すべての他のSize Threshold Typeについて、Size ThresholdパラメータタイプおよびGUTタイプはRealであり、妥当性確認ストリングは

である。どちらの場合でも、GUIラベルは"Size Threshold （<Size Threshold Type>）"である。

Range Threshold Unitsが、"Cents"に設定される場合、Range ThresholdパラメータタイプおよびGUI要素タイプはIntegerであり、妥当性確認ストリングは

である。そうでない場合、Range ThresholdパラメータタイプおよびGUI要素タイプはRealであり、妥当性確認ストリングは

である。どちらの場合でも、GUIラベルは、"Range（<Anchor>からの<Units>）"を読むはずである。たとえば、"Range（Same Side of QuoteからのBPS）"。

Fast Execスクリーン（図２３参照）上において、設計者は、2つのパラメータをSize on Opposite Side条件スクリーンからのパラメータセッティングに連結する選択肢を有する。これは、このスクリーンの行動に影響を与える。さらなる詳細について、Fast Execスクリーンに関するセクションを参照されたい。

［条件タブ:Bid/Ask Spread Condition］
図２８を参照されたい。このタブは、2つの公開可能なパラメータを特徴とする。

さらに、設計者は、4つの他のパラメータ（すべて静的）を定義することができる。
・オペレータ(<,>)
・Spread Threshold Units （Cents、BPS、% Typical Spread）
・ワンショットチェックボックス
・Min Cycle Time（分）

Spread Threshold Unitsが"Cents"に設定される場合、Spread ThresholdパラメータタイプおよびGUI要素タイプはIntegerであり、妥当性確認ストリングは

である。そうでない場合、Spread ThresholdパラメータタイプおよびGUI要素タイプはRealであり、妥当性確認ストリングは

である。どちらの場合でも、GUIラベルは、"Spread Threshold （<Units>）"を読むはずである。たとえば、"Spread Threshold（Cents）"。

［条件タブ:Relative Return Condition］
図２９を参照されたい。このタブは、3つの公開可能なパラメータを特徴とする。

さらに、設計者は、4つの他のパラメータ（すべて静的）を定義することができる。
・Spread Direction（Outperforming、Underperforming、B:Out/S:Under、B:Under/S:Out）
・Reference Type（Stock、[後にインデックスを第2タイプとして追加する]）
・ワンショットチェックボックス
・Min Cycle Time（分）

［条件タブ:Filled Size Condition］
図３０を参照されたい。このタブは、1つの公開可能なパラメータを特徴とする。

さらに、設計者は、以下の1つの他の静的パラメータを定義することができる。Filled Threshold Type（シェアまたは元のオーダーの%）。

Filled Threshold TypeがSharesである場合、Filled Thresholdについて、以下の定義が適用される。パラメータタイプおよびGUI要素タイプはIntegerであり、GUIラベルは"Filled Size Threshold（Shares）"であり、妥当性確認ストリングは"(0,)"である。

Filled Threshold Typeが元のオーダーの%である場合、Filled Thresholdについて、以下の定義が適用される。パラメータタイプおよびGUI要素タイプはRealであり、GUIラベルは"Filled Size Threshold（%Order）"であり、妥当性確認ストリングは"(0.0,1.0)"である。

［プレビューボタン］
ユーザが"Preview"ボタン（図１８参照）をクリックするとき、オーサリングツールは、モックインタフェースをポップアップする。これは、静的（単にスクリーンショット）とすることが可能であるが、対話型であることが好ましく、設計者が機能および妥当性確認を試験することを可能にする。このプレビュー特徴は、本明細書のカスタム戦略概念セクションからのGUI要素タイプのそれぞれを支持することができなければならない（より詳細についてはそのセクションを参照）。プレビューインタフェースは、別のポップアップフレームにおいて表示されることが好ましい。

図３１に示されるように、プレビューインタフェースは、いくつかのセクションを有することが好ましい。

インタフェースの上部セクションは、CAT戦略の様々な部分に関連付けられたパラメータを区分するために、フレームに分割される。
・Time Config
・Limit Price
・Base Action
・Condition
・Conditional Action

少なくとも1つの動的変数を含むフレームのみが示される。空のフレームは隠される（この場合、条件付きアクションフレームが隠される）。（a）基本アクションがアイドルである、（b）条件付きアクションがアイドルである、または（c）基本アクションが公開され、設計者が"Apply to Full Order"チェックボックスにチェックを入れている場合のみ、Limit Priceフレームは適用される。これらのいずれかが適用される場合、完全オーダーに適用されるせいぜい1つのリミットプライスが存在する。このリミットプライスパラメータフィールドは、それが通常配置されるBase ActionまたはConditional Actionのセクションから移動され、それ自体のセクションに置かれる。すべての他のセクションは、CATインタフェース（およびオーサリングツール）のタブに正確に対応する。タブの1つから公開される任意の動的パラメータは、タブに関連付けられたセクションにおいてインタフェースの上に配置される。"Link to Condition"とマークされたFast Execパラメータの場合、これらのパラメータは、Conditionセクションに配置され、1回のみ表示される。

パラメータフィールドは、決して並んでではなく、垂直に積み重ねられることが好ましい。インタフェース上の各パラメータフィールドは、":"記号および次いでカスタムインタフェースの定義（チェックボックス,整数編集ボックスなど）において指定されたGUI要素が続くパラメータGUIラベル（カスタムインタフェースの定義から）からなる。カスタムインタフェースの定義において定義されたデフォルト値を有するパラメータでは、指定値は、デフォルトとしてGUI要素に表示される。GUIラベルが長過ぎて1つの線上に表示できない場合、いくつかの線の上にわたって分断することができる。

プレビューインタフェースの底部には、"OK"および"Cancel"の2つのボタンがある。プレビューインタフェースが対話型である場合、これらのボタンのどちらかをクリックすることにより、プレビューペインが閉じる。

プレビューインタフェースが対話型である場合、カスタムインタフェース定義の妥当性確認命令が、各パラメータについて実行されることが好ましい。さらに、基本タイプ関連妥当性確認が実行されることが好ましい（ユーザは、整数パラメータフィールドにおいて記号をタイプすることを防止される、など）。

このCATオーサリングツールの例では、戦略設計者がインタフェースのレイアウトに対して有する直接制御は小さいことに留意されたい。インタフェースのレイアウトは、オーサリングツールによって自動的に生成される。しかし、本明細書において記述された一般的なオーサリングツールの機能は、ツールがインタフェースレイアウトに対してより多くの制御を提供する場合を包含するように拡張される。当業者なら理解するように、設計者は、フィールドの順序付けおよびラベル付けから着色方式、さらにはスライダおよびボタンなどのカスタムインタフェース制御の定義まで、あらゆることを制御することを許可されることが可能である。

［コンパイルボタン］
コンパイルボタン（Compile Button）（図１８参照）を押すことにより、オーサリングインタフェースは、戦略およびインタフェースを記憶することを試行する。第1ステップは、すべての必須パラメータが、動的パラメータとして公開されたか、または静的パラメータとして正当値を割り当てられたかを確認する。そうでない場合、オーサリングツールは、定義されていないパラメータに注意を喚起させるエラーメッセージを設計者に提示し、戦略は記憶されない。

この試験を通過したと想定すると、オーサリングツールは、設計者に、新しいカスタム戦略の戦略名を指定するように促す。

次いで、オーサリングツールは、カスタム戦略の5つの部分を書き出す。
（1）Custom Strategy Name=<設計者によって入力された戦略名>
（2）Parent Algorithm=CAT.（各親アルゴリズムが別々のオーサリングツールを有することを思い出させる）
（3）Manifest

本明細書のカスタム戦略概念のセクションにおいて記述されたように、マニフェストフォーマットは、通常のCATオーダーについてパラメータセッティングを指定するために使用されたFIXメッセージフォーマットに密接に模してモデリングされる。静的変数と識別され、かつオーサリングツールにおいて事前定義されたすべてのパラメータは、同じパラメータセッティングを有する正規のCATオーダーを表すFIXメッセージにおいて定義されるのと全く同様にマニフェストに転記することができる。動的変数と識別されたパラメータは、2つのパイプ（|）記号の間に入れ込まれたパラメータID（本記述ではパラメータの表エントリにおいて見られる）を、パラメータセッティングが通常向かうスポットに配置することによって、マニフェストに転記される。実際には、プレースホルダが、通常はパラメータセッティングについて確保されるFIXメッセージのスポットに置かれ、プレースホルダによって識別された固有IDでタグ付けされたパスインパラメータ値を前処理プロセッサが接合するべき位置を識別する。これは、カスタム戦略概念のセクションにおいて広範に網羅されている。

（4）カスタムパラメータ定義
カスタムパラメータ定義を表すFIXメッセージは、戦略が、エンドユーザに公開される少なくとも1つの動的パラメータを有する場合のみ、創出される。

オーサリングツール（提供されたチェックボックスを使用する）において設計者によって公開された各動的パラメータは、カスタム戦略概念のセクションにおいて定義されたフォーマットにおいて繰返しグループエントリを有することが好ましい。パラメータエントリは、以下のように構築される。
・StrategyParameterName =<本文書のパラメータの表エントリからのパラメータID>
・StrategyParameterType =<本文書のパラメータの表エントリからのパラメータタイプ>
・StrategyParameterValue =""[このフィールドは、後継オーダーについてのみ使用され、戦略定義については使用されない]

繰返しリストの上部は、設計者によって入力された戦略名、および動的パラメータの総数を記録する。

（5）カスタムインタフェース定義
カスタムインタフェース定義は、カスタムパラメータ定義のレプリカで始まる。ブランクのStrategyParameterValueフィールドは、設計者によって各動的パラメータについて入力されたデフォルトセッティングで上書きされる。これらのデフォルト値は、当該のパラメータが必須パラメータとして識別されていないことを条件として、ブランクとすることが可能である。次いで、各パラメータの繰返しグループエントリは、3つの新しい行を追加することによって拡張される。
・StrategyParameterLabel=<本文書のパラメータの表エントリからのGUIラベル>
・StrategyParameterConrol=<本文書のパラメータの表エントリからのGUI要素タイプ>
・StrategyParameterValidation=<本文書のパラメータの表エントリからの妥当性確認ストリング>

これらの5つの構成要素が記憶され、オーサリングプロセスは完了する。

追加の背景について、推奨されるアルゴリズムトレーディングの拡張に関する以下の情報が提供される。

［アルゴリズムトレーディングの拡張］
＜背景＞
現在のFIX4.4バージョンは、以下の3つの戦略関連タグを組み合わせることにより、アルゴリズムトレーディングを支持する。TargetStrategy（タグ847）、TargetStrategyParameter（タグ848）、およびParticipationRate（タグ849）。ほとんどの会社では、追加のパラメータを必要とする戦略の数は増大している。いくつかの会社は、様々な実施態様を考案し、その要件を支持するためにカスタムタグを追加している。

＜推奨＞
戦略について追加のパラメータを通過させることを標準化し、より適応的な実施態様を創出して、アルゴリズムトレーディングを支持するために、以下が提案される。
1.戦略のパラメータを捕獲するために、繰返しグループ（以下を参照）を追加する。この繰返しグループは、TargetStrategyタグ（タグ847）を現在有するすべてのメッセージに追加される。これは、メッセージタイプD、E、G、8、AB、AC、s、およびtを含む。

2.タグStrategyParameters（848）およびParticipationRate（849）（FIX4.4において導入）を推奨しない。
3.この手法では、指定された開始時間および終了時間を有するVWAP戦略、ならびに2つの追加のパラメータである参加率（40%）および積極性（Y）は、以下のように表すことができる。
847 （TargetStrategy） = 1 （VWAP）
168 （EffectiveTime） = 20050606-14:00:00
126 （ExpireTime） = 20050606-20:00:00
957 （NoStrategyParameters） = 2
958 （StrategyParameterName） = ParticipationRate
959 （StrategyParameterType） = 11（パーセンテージ）
960 （StrategyParameterValue） = 0.4
958 （StrategyParameterName） = Aggressiveness
959 （StrategyParameterType） = 13（ブール）
960 （StrategyParameterValue） = Y
4.FIXの以前のバージョンのカスタム繰返しグループを支持することができない会社/ベンダについて、以下のようにタグ847&848において戦略タグを渡すことができる。
・タグ847は、戦略識別子を含む。
・タグ848は、一連のセミコロンで範囲を定めたタグ、値の対を含む。
・上記の例では、タグ847&848は、以下のようにポピュレートされる。
847=1
848=957:2;958:ParticipationRate;959:11;960:0.4;
958:Aggressiveness;959:13;960:Y
5.FIXの以前のバージョンのタグ847、848、957〜960を実行することができない会社/ベンダについて、5000シリーズ-5847、5848、5957〜5960の対応するユーザ定義タグを使用することができる。
6.まとめると、以下の表は、推奨されるタグおよび代替を示す。

本発明の実施形態は、当業者には明らかであるコンピュータ構成要素およびコンピュータ実行ステップを備える。説明を容易にするために、本発明の各ステップまたは要素は、コンピュータシステムの一部としては本明細書では記述されていないが、当業者なら、各ステップまたは要素は、対応するコンピュータシステムまたはソフトウエア構成要素を有することが可能であることを理解するであろう。したがって、そのようなコンピュータシステムおよび/またはソフトウエア構成要素は、対応するステップまたは要素（すなわち、その機能）を記述することによって可能になり、本発明の範囲内にある。

たとえば、すべての計算は、1つまたは複数のコンピュータによって実行されることが好ましい。さらに、すべての通知および他の通信、ならびにすべてのデータ転送は、法によって可能になる程度まで、コンピュータネットワーク上で電子的に送信されることが好ましい。さらに、すべてのデータは、1つまたは複数の電子データベースに記憶されることが好ましい。

パラメータを自動セキュリティオーダー実行システムに送達する好ましいシステムおよび方法を示す図である。 好ましいTactEx Interfaceのディスプレイを示す図である。 好ましいCustom Strategy Definitionのディスプレイを示す図である。 好ましいSimple Custom Strategy Interfaceのディスプレイを示す図である。 好ましいSitter Algorithm Interfaceのディスプレイを示す図である。 可能なTimeパラメータ制御の例を示す図である。 好ましい制御タイプ定義を示す図である。 Custom Strategyインタフェースの例を示す図である。 他のCustom Strategyインタフェースの例を示す図である。 Custom Strategyを構築する好ましい方法を示す図である。 好ましいLMX CATアルゴリズムインタフェースを示す図である。 チェックボックスを有する好ましいCATオーサリングツールを示す図である。 CATオーサリングツールの例を示す図である。 好ましいTime Configuration Tabのディスプレイを示す図である。 好ましいBase Action Tab:VWAPのディスプレイを示す図である。 好ましいBase Action Tab:TWAPのディスプレイを示す図である。 好ましいBase Action Tab:With Volumeのディスプレイを示す図である。 好ましいBase Action Tab:Target Strikeのディスプレイを示す図である。 好ましいConditional Action Tab:VWAPのディスプレイを示す図である。 好ましいConditional Action Tab:TWAPのディスプレイを示す図である。 好ましいConditional Action Tab:With Volumeのディスプレイを示す図である。 好ましいConditional Action Tab:Target Strikeのディスプレイを示す図である。 好ましいConditional Action Tab:Fast Execのディスプレイを示す図である。 絶対トリガプライスタイプでの好ましいCondition Tab:Price Conditionのディスプレイを示す図である。 相対トリガプライスタイプでの好ましいCondition Tab:Price Conditionのディスプレイを示す図である。 好ましいCondition Tab:Time Conditionのディスプレイを示す図である。 好ましいCondition Tab:Size on Opposite Side Conditionのディスプレイを示す図である。 好ましいCondition Tab:Bid/Ask Spread Conditionのディスプレイを示す図である。 好ましいCondition Tab:Relative Return Conditionのディスプレイを示す図である。 好ましいCondition Tab:Filled Size Conditionのディスプレイを示す図である。 好ましいCustom Interface Previewのディスプレイを示す図である。

Claims (21)

1. ユーザがトレーディングアルゴリズムの１つまたは複数の入力パラメータを、オーダーを提出するときに修正することができない予め定義されたパラメータである静的パラメータ、または、オーダーを提出するときに指定することができるパラメータである動的パラメータのどちらか一方として指定することを可能にすることによって、ユーザがカスタムトレーディング戦略を設計することを可能にするように動作可能であり、更に、ユーザがインタフェース定義を創出することを可能にするように動作可能なオーサリングツールがインストールされたエンド・ユーザーのコンピュータと、
   固有の戦略名と、前記静的パラメータについては静的な値が定義されており、かつ、前記動的パラメータについてはプレースホルダが示されているマニフェストとを含むカスタムトレーディング戦略の定義データを記憶したデータベースと、
   標準プロトコルを介して送達されたカスタムトレーディング戦略オーダーメッセージを受信し、受信したカスタムトレーディング戦略オーダーメッセージに含まれる戦略名に対応するカスタムトレーディング戦略の定義データを前記データベースからロードし、ユーザが入力した動的パラメータ値を受信しかつ該動的パラメータ値が妥当ならば、該動的パラメータ値を、ロードした定義データのマニフェストに組み込み、動的パラメータ値が組み込まれた定義データを、受信した前記カスタムトレーディング戦略オーダーメッセージに付加して、該カスタムトレーディング戦略オーダーメッセージをトレーディング戦略宛先に渡すように動作可能な前処理プロセッサとを備える、コンピュータシステム。
2. 前記定義が、送信および記憶のために前記カスタムトレーディング戦略およびインタフェース定義を符号化するためのプロトコルを使用して符号化される、請求項１に記載のコンピュータシステム。
3. 前記標準プロトコルがＦＩＸプロトコルである、請求項１に記載のコンピュータシステム。
4. 前記オーサリングツールが、ユーザがデフォルト値または許容可能な範囲を動的パラメータに割り当てることを可能にするように動作可能である、請求項１に記載のコンピュータシステム。
5. 前記オーサリングツールは、動的パラメータが、必須入力または任意入力として指定されることが可能であるように動作可能である、請求項１に記載のコンピュータシステム。
6. パラメータ値を受信し、標準プロトコルを介して送信するためのカスタム戦略オーダーメッセージに前記値を形成するように動作可能なオーダーエントリオブジェクトインタプリタを、前記エンド・ユーザーのコンピュータが更に備える、請求項１に記載のコンピュータシステム。
7. エンド・ユーザーのコンピュータにインストールされたオーサリングツールによって、トレーディングアルゴリズムの１つまたは複数の入力パラメータが、オーダーを提出するときに修正することができない予め定義されたパラメータである静的パラメータ、または、オーダーを提出するときに指定することができるパラメータである動的パラメータのどちらか一方として指定されるトレーディング戦略の定義を受信する段階と、
   固有の戦略名と、前記静的パラメータについては静的な値が定義されており、かつ、前記動的パラメータについてはプレースホルダが示されているマニフェストとを含むカスタムトレーディング戦略の定義データをデータベースに記憶する段階と、
   前処理プロセッサによって、標準プロトコルを介して送達されたカスタムトレーディング戦略オーダーメッセージを受信し、受信したカスタムトレーディング戦略オーダーメッセージに含まれる戦略名に対応するカスタムトレーディング戦略の定義データを前記データベースからロードし、ユーザが入力した動的パラメータ値を受信しかつ該動的パラメータ値が妥当ならば、該動的パラメータ値を、ロードした定義データのマニフェストに組み込み、動的パラメータ値が組み込まれた定義データを、受信した前記カスタムトレーディング戦略オーダーメッセージに付加して、該カスタムトレーディング戦略オーダーメッセージをトレーディング戦略宛先に渡す段階とを備える、コンピュータ実行方法。
8. トレーディング戦略の前記定義が、（a）戦略名、（b）親アルゴリズムを識別するデータ、（c）マニフェスト、（d）カスタムパラメータ定義、および（e）カスタムインタフェース定義を備える、請求項７に記載のコンピュータ実行方法。
9. 前記マニフェストが、前記親アルゴリズムのパラメータのリストを列挙し、どの前記パラメータが静的で、どれが動的であるかを識別する、請求項８に記載のコンピュータ実行方法。
10. 前記親アルゴリズムが、ＦＩＸメッセージを受信するように動作可能である、請求項８に記載のコンピュータ実行方法。
11. 前記マニフェストが、１つまたは複数の静的パラメータ値および１つまたは複数の動的パラメータ値を備える、請求項８に記載のコンピュータ実行方法。
12. 前記静的パラメータ値が、前記静的パラメータ値がＦＩＸメッセージにおいて定義されるであろう方式と本質的に同一の方式で転記される、請求項１１に記載のコンピュータ実行方法。
13. プレースホルダが、動的パラメータのパスイン値が挿入されるべき位置を識別するために使用される、請求項１１に記載のコンピュータ実行方法。
14. ユーザが前記トレーディング戦略の前記定義を入力することを可能にするように動作可能なグラフィカルユーザインタフェースを表示する段階と、
    前記トレーディング戦略の前記定義を親アルゴリズムに送信する段階とを更に備える、請求項７に記載のコンピュータ実行方法。
15. エンド・ユーザーのコンピュータに、グラフィカルユーザインタフェースを介して、トレーディングアルゴリズムの１つまたは複数の入力パラメータが、オーダーを提出するときに修正することができない予め定義されたパラメータである静的パラメータ、または、オーダーを提出するときに指定することができるパラメータである動的パラメータのどちらか一方として指定されるトレーディング戦略の定義を受信する段階を実行させ、
    データベースに、固有の戦略名と、前記静的パラメータについては静的な値が定義されており、かつ、前記動的パラメータについてはプレースホルダが示されているマニフェストとを含むカスタムトレーディング戦略の定義データを記憶する段階を実行させ、
    前処理プロセッサに、標準プロトコルを介して送達されたカスタムトレーディング戦略オーダーメッセージを受信し、受信したカスタムトレーディング戦略オーダーメッセージに含まれる戦略名に対応するカスタムトレーディング戦略の定義データを前記データベースからロードし、ユーザが入力した動的パラメータ値を受信しかつ該動的パラメータ値が妥当ならば、該動的パラメータ値を、ロードした定義データのマニフェストに組み込み、動的パラメータ値が組み込まれた定義データを、受信した前記カスタムトレーディング戦略オーダーメッセージに付加して、該カスタムトレーディング戦略オーダーメッセージをトレーディング戦略宛先に渡す段階を実行させるソフトウエア。
16. 前記データベースが、
    親アルゴリズム名と、
    マニフェストとを備えるカスタムトレーディング戦略を記憶するようにさらに動作可能である、請求項１５に記載のソフトウエア。
17. 前記マニフェストが、事前定義された静的パラメータ値および動的パラメータを識別するデータを備える、請求項１６に記載のソフトウエア。
18. 前記マニフェストが、前記動的パラメータのデフォルトパラメータ値を識別するデータをさらに備える、請求項１７に記載のソフトウエア。
19. 前記ユーザが、１つまたは複数の基本アクション、１つまたは複数の条件付きアクション、および１つまたは複数の条件を識別することを可能にするように、前記グラフィカルユーザインタフェースがさらに構成される、請求項１５に記載のソフトウエア。
20. 前記マニフェストが、ＸＭＬストリングまたはＦＩＸストリングとして記憶される、請求項１６に記載のソフトウエア。
21. 前記ソフトウエアが、カスタムパラメータ定義およびカスタムインタフェース定義の少なくとも一方を備えるカスタム戦略を記憶するようにさらに動作可能である、請求項１６に記載のソフトウエア。

Images