JP5731116B2 - アルゴリズム取引処理の方法、システムおよびソフトウェア - Google Patents

Description

本発明は、アルゴリズム取引処理の方法、システムおよびソフトウェアに関する。

本出願は2006年5月16日に出願された米国仮特許出願番号60/800，700を基礎として優先権を主張するものである。その全ての内容は、本明細書に引用により組み込まれている。

[アルゴリズムチャレンジ]
ますます多くのブローカーが、彼らの顧客にアルゴリズム取引ストラテジを提供するようになり、商品化までの時間が、取引システムのための重要な事項(consideration)となっている。またプロバイダは、継続的に新しいストラテジを付加するとともに、古いものを調整している。実際、多くの業界アナリストによれば、ブローカーによるアルゴリズムのカスタマイズは、すぐに差別化のための重要なファクターになるという。取引システム - 特に売買ルーティングシステム - は、新しいアルゴリズムをサポートするためまたは古いものを変更するために、新しいクライアント側の技術(例えばリアルティック(RealTick(商標))など)およびサーバ側の技術(例えばエクスチェンジハンドラー(Exchange Handler)など)を開発する必要がある。クライアント側の開発は、一般的にアルゴリズムパラメータをセット/調整するため、およびコア注文にアルゴリズムパラメータを付け加えるためのインターフェースを加えることを伴う。サーバ側では、すべての注文パラメータは、取引所に必要とされるフォーマットに変換されなければならない。今日、アルゴリズムプロバイダの大多数は、FIXプロトコルを使用している。FIXは、コアパラメータに独自のコンセプトを備えるとともにベンダー特有のデータを考慮に入れており、それは望ましくは、アルゴリズムパラメータがプロバイダに転送される方法である。

新しいクライアント・サーバソフトウェアを提供することは時間がかかり、そして既存のアルゴリズムを最新に変更するのに遅れずについていくことは、終わりなき戦いのようなものである。それぞれのアルゴリズムのパラメータは、売買ルーティングシステムのクライアント・サーバソフトウェアに、少しまたは全く役に立たないので、もし、アルゴリズムの変更/追加によっても、クライアント・サーバソフトウェアの新しいバージョンを必要としなかったならば、多くの仕事を省くとともに、我々の製品化までの時間を加速する。

[業界動向]
アルゴリズム取引に入る/編集するために必要なインターフェースを、なんらかのスキーマ(schema)から自動的に生成することができるように、FIX規格委員会は、アルゴリズムプロバイダのアルゴリズムを記述するための標準的方法を用意することに取り組んでいる。前記スキーマは、FIXプロトコルを使用してパラメータを転送する方法も記述する。前記スキーマは、ウェブサービスを介して作成してもよいため、スキーマの変更はクライアントのアップグレードを必要としない。このソリューションは、FIXベースの取引システムでは役に立つが、クライアントアプリケーションとサーバ間の通信にFIXを使用しない売買ルーティングシステムでは、実用的でない。

少なくとも一つの実施構成において、本発明は、注文のパラメータをコアとアルゴリズムの二つのパートに分けることでアルゴリズム証券売買注文を処理する。注文のアルゴリズムパラメータを注文がそのオリジナルフォームで意図していた電子的宛先(electronic destination)へ転送するとともに、"コア(core)"とみなすフィールドを処理することを、FIX以外を使用した取引システムに許可することは、アルゴリズムフィールドの変換を不要とする。

[注文(orders)]
注文は、証券を売りまたは買うための顧客の意思を表す。証券は、取引所(trading venue)で売買が行なわれ、それぞれどのように注文を満たすかという命令を顧客が指示することを許可する"注文タイプ"の標準セットをサポートする。

注文の基本プロパティ(ティッカーシンボル，サイド(side)(買いまたは売り)，量，有効期限(expiration)，注文タイプ，およびルート)は、"コアパラメータ(core parameters)"とされている。いくつかの簡単な注文タイプの実行は、単純なアルゴリズムを必要とするが、これらのタイプはあまりに標準的なため、誰もこれらをアルゴリズム取引とは呼ばない。

[FIX]
"FIX"は、ファイナンシャルインフォメーションエクスチェンジ(Financial Information Exchange)を表し、コンピュータソフトウェアを介して証券取引のためのデータをやりとりするために使用される標準プロトコルである。トレーダー/証券会社間の通信に関する合意した規格をベースにしている。FIXには、例えば、マイクロソフト株式を１００株という買い注文を送信したり、その注文状況を確認したり、その注文をキャンセルしたり、またはその注文を拒否したりするのに電子言語(electronic language)が使用されている。

[アルゴリズム取引]
アルゴリズム取引は、付加的なハンドリング/執行命令を伴う注文であり、それは(一般的に)取引所によりサポートされるそれらよりも複雑である。アルゴリズムエンジンは、プロバイダ - 通常はブローカー/ディーラー - により保守されるとともに顧客と取引所の間に介在する(使用されているアルゴリズムは、市況に基づき、顧客の注文の一部を異なる取引所に送信しうる)。アルゴリズムは、単純でも複雑であってもよく、以下の一つまたは複数のことを成しうる。
1.小さいチャンク(chunks)のまとまった注文を送信する。
2.注文の一部を一日のさまざまな時間に送信する。
3.最適な価格のために可能な取引所をスキャンする。
4.いつ(a)取引執行(placing)を開始/停止するか、および/またはいつ(b)さらに消極的(passive)/積極的(aggressive)にするか、を決定するための市場指数および他の指標を調べる。
5.取引に最適な時刻を決定するために出来高のトレンド経過を調べる。
6.一つの取引所での注文を遂行するとともに、その後残りの注文を他の取引所で行なうことを試みる。

[アルゴリズムパラメータ]
本明細書において、アルゴリズムのストラテジに特有のすべてのパラメータを、"アルゴリズムパラメータ"という。

それぞれのアルゴリズムプロバイダは、複数のストラテジを提供する。それぞれのストラテジの背後にあるロジックは複雑であり、さまざまなパラメータに基づいている。前記プロバイダは、一般的に、前記アルゴリズムエンジンが実際に使用するパラメータの一部を顧客が設定することを許可している。これは機密情報を隠すため(顧客が自分で同じことをするのを止めるため)にされうるし、また前記アルゴリズムの使用を簡素化するためにしてもよい。また、双方のためであってもよい。いくつかのストラテジのために、プロバイダは、顧客に対しストラテジの名前の指定以外何にも許可しないかもしれない。プロバイダによっては、顧客に多数のパラメータを入力することを許可するかもしれない。

アルゴリズム取引特有の複雑性にもかかわらず、好適な取引システムは、前記コアパラメータを決定するためにそれぞれのアルゴリズム取引を解析する。好適な取引システムは残りのパラメータそのままをなるべく残すとともに、それをアルゴリズムの宛先へその所望のフォーマットで転送する。

[アルゴリズムチャレンジ]
ますます多くのブローカーが、彼らの顧客にアルゴリズム取引ストラテジを提供するようになり、商品化までの時間が、取引システムのための重要な事項(consideration)となっている。またプロバイダは、継続的に新しいストラテジを付加するとともに、古いものを調整している。実際、多くの業界アナリストによれば、ブローカーによるアルゴリズムのカスタマイズは、すぐに差別化のための重要なファクターになるという。取引システム - 特に売買ルーティングシステム - は、新しいアルゴリズムをサポートするためまたは古いものを変更するために、新しいクライアント側の技術(例えばリアルティック(RealTick(商標))など)およびサーバ側の技術(例えばエクスチェンジハンドラー(Exchange Handler)など)を開発する必要がある。クライアント側の開発は、一般的にアルゴリズムパラメータをセット/調整するため、およびコア注文にアルゴリズムパラメータを付け加えるためのインターフェースを加えることを伴う。サーバ側では、すべての注文パラメータは、取引所に必要とされるフォーマットに変換されなければならない。今日、アルゴリズムプロバイダの大多数は、FIXプロトコルを使用している。FIXは、コアパラメータに独自のコンセプトを備えるとともにベンダー特有のデータを考慮に入れており、それは望ましくは、アルゴリズムパラメータがプロバイダに転送される方法である。

新しいクライアント・サーバソフトウェアを提供することは時間がかかり、そして既存のアルゴリズムを最新に変更するのに遅れずについていくことは、終わりなき戦いのようなものである。それぞれのアルゴリズムのパラメータは、売買ルーティングシステムのクライアント・サーバソフトウェアに、少しまたは全く役に立たないので、もし、アルゴリズムの変更/追加によっても、クライアント・サーバソフトウェアの新しいバージョンを必要としなかったならば、多くの仕事を省くとともに、我々の製品化までの時間を加速する。

[業界動向]
アルゴリズム取引に入る/編集するために必要なインターフェースを、なんらかのスキーマ(schema)から自動的に生成することができるように、FIX規格委員会は、アルゴリズムプロバイダのアルゴリズムを記述するための標準的方法を用意することに取り組んでいる。前記スキーマは、FIXプロトコルを使用してパラメータを転送する方法も記述する。前記スキーマは、ウェブサービスを介して作成してもよいため、スキーマの変更はクライアントのアップグレードを必要としない。このソリューションは、FIXベースの取引システムでは役に立つが、クライアントアプリケーションとサーバ間の通信にFIXを使用しない売買ルーティングシステムでは、実用的でない。

本発明の実施構成は、アルゴリズム取引をコアパラメータとアルゴリズムパラメータの二つに分割することによりこの問題へのソリューションを提供する。売買ルーティングシステムは、コアパラメータを考慮することが可能であるか、またはそうでなければアルゴリズムパラメータをそれぞれの注文とともに受動的に転送される"ブラックボックス"として扱いながら別の処理をすることができる。

XMLに基づく実施構成の場合、アルゴリズムパラメータのために使用されるXMLフォーマットは、XMLタグを直接FIXタグにマップ(map)する。ウェブサービスコールを介して得られるアルゴリズムスキーマの上記の方法と組み合わせた場合、この実施構成は、結果としてシステムが、クライアントまたはサーバのアップグレードを必要としないでアルゴリズムストラテジをハンドル可能であるとともに、それはFIXベースでない取引システムに、クライアントとサーバソフトウェア間の通信のためにFIXを使用するように書き換えることを要求する。

一構成において、本発明の方法は、
(a)第一フォーマットによるコアパラメータおよびストラテジパラメータを有する証券売買注文を受信するステップと、
(b)前記注文をフォーム(form)に変換するステップと、
(c)前記コアパラメータを処理するステップと、
(d)前記変換した注文を注文管理システムへ送信するステップと、
を具備し、
前記コアパラメータおよび前記ストラテジパラメータは、パラメータの異なるグループに分けられることを特徴とする。

さまざまな実施構成において、
(1)前記第一フォーマットは、XMLである。
(2)前記変換ステップは、前記注文を注文管理システムと互換性のある第二フォーマットへ変換することをさらに備える。
(3)前記第二フォーマットは、FIXである。

別の実施構成において、本発明は、コンピュータ読み取り可能な媒体に保持されたソフトウェアであって、
前記ソフトウェアは、
(a)第一フォーマットによるコアパラメータおよびストラテジパラメータを有する証券売買注文を受信するためのソフトウェアと、
(b)前記注文をフォームへ変換するためのソフトウェアと、
(c)前記コアパラメータを処理するためのソフトウェアと、
(d)変換された注文を前記注文管理システムへ送信するためのソフトウェアと、
を具備し、
前記コアパラメータおよび前記ストラテジパラメータは、パラメータの異なるグループに分けられることを特徴とする。

さまざまな実施構成において、
(1)第一フォーマットは、XMLである。
(2)変換するためのソフトウェアは、前記注文を前記注文管理システムと互換性のある第二フォーマットへ変換するためのソフトウェアをさらに具備する。
(3)第二フォーマットは、FIXである。

別の実施構成において、本発明は、コンピュータシステムを有し、
前記コンピュータシステムは、
(a)第一フォーマットによるコアパラメータおよびストラテジパラメータを有する証券売買注文を受信可能な注文コンポーネントと、
(b)前記注文をフォームに変換可能な変換コンポーネントと、
(c)前記コアパラメータを処理可能な処理コンポーネントと、
(d)変換された注文を前記注文管理システムへ送信可能な送信コンポーネントと、
を具備し、
前記コアパラメータおよび前記ストラテジパラメータは、パラメータの異なるグループに分けられることを特徴とする。

さまざまな実施構成において、
(1)前記第一フォーマットは、XMLである。
(2)前記変換コンポーネントは、前記注文を前記注文管理システムと互換性のある第二フォーマットへさらに変換可能である。
(3)前記第二フォーマットは、FIXである。
(4)前記システムは、ストラテジXMLフィールドをFIXプロトコルへマッピングするための一つまたは複数の注文ハンドラをさらに具備する。
(5)前記注文コンポーネントは、ウェブサーバを具備する。
(6)前記注文コンポーネントは、コンピュータネットワークと通信するワークステーションを具備する。

図１は、本発明におけるシステムおよびアルゴリズム取引フローの一実施例を示している。

図２は、典型的なコア注文のグラフィカル表示を示している。

図３は、典型的なアルゴリズム取引のためのグラフィカル・インターフェースを示している。

アルゴリズム取引を宛先に送信することに関与するサーバ側の要素(piece)は、組み込まれたXMLからアルゴリズムパラメータを追加することを除き、前記注文を標準的な注文として扱う。組み込まれたXMLは、FIXタグを備えるため、アルゴリズムを変更してもこの要素の変更を必要としない - パラメータをXMLにパッキング(packing)するのに使用されたスキーマをアップデートするだけである。ストラテジXML要素は、FIXタグを使わないアルゴリズムを使用するためのXMLパラメータのための追加セクションも含んでもよい。前記コンセプトは、この場合でも同様である - アルゴリズムプロトコルを変更しても、サーバ側要素を変更する必要はない。

サーバおよびクライアントの開発の必要性を省くことは、新しいアルゴリズムを実装するための時間および既存のものを変更するまでの時間を加速する。

[取引フロー(Order Flow)]
図１は、本発明の実施形態におけるアルゴリズム取引フローを示す

ユーザは、リアルティックなどのトレーディングアプリケーションを介し、またはウェブブラウザなどを介し、システムにアルゴリズム取引を始めるように指示できる。

リアルティックのようなクライアントアプリケーションでは、ユーザは、固有の(通常ファット(fat)クライアントと呼ばれる)グラフィカル・ユーザー・インターフェースを介し、またはウェブページに組み込まれたものを介し、図３に示されるようなアルゴリズムパラメータの選択を与えられる。

ユーザがパラメータの選択をするとともに注文を実行した後、システム(クライアント・サーバ)は、ブローカーエクスチェンジ注文ハンドラを介し、コア注文パラメータ(図２に示されている例を参照)およびストラテジパラメータを処理する。

コア & ストラテジパラメータ処理を行なうタスクを課されるウェブサーバで、ウェブページインターアクションのための処理フローは類似している。

以下は、アルゴリズム注文フロー(図１参照)への典型的なエントリーポイントのリストである。
1)リアルティックアルゴリズムのDLL。
2)リアルティックは、アルゴリズムパラメータを設定するブラウザウィンドウを表示(spawning)し、アルゴリズム取引を作成したブローカーによりホストされる(hosted)。
3)ウェブサービスは、取引システムを直接コールする。
4)ウェブブラウザウィンドウは、リアルティックに組み込まれた事前取引分析タイプサービスを提供するとともにアルゴリズム取引を生成するためにクライアント側スクリプティングコール(scripting call)をリアルティックに送信する。
5)直接FIXトラフィック。

[仕様]
前記コアフィールドと前記アルゴリズムストラテジフィールド間の分離は、例えば注文ルーティングソフトウェア(例：リアルティック)のまたはウェブサーバの注文ルーティングエンジンにより遂行される。

図２は、典型的なコア注文のグラフィック表示を示したものである。前記注文の詳細は、図２の210領域に示されている。

図２は、色づけされたティア(tiers)の下のグラフィック表示内の注文のコアパートを示している。グラフィック表示されているすべてのコアフィールドは、以下に書き出されている(spelled out)。

図２に示されている前記注文に相当するものが、コード化されたフォーマット(好適なバイナリフォーマットで単純化された表現)で以下に説明されている。

コアデータ(括弧内の数字は、フィールドIDであり、コアバイナリフォーマットに相当する)。

コア + ストラテジフィールド例
図３は、アルゴリズム取引のためのグラフィカル・インターフェースの一実施例を示している。

図３中にGUIで表示されるそれぞれのパラメータは、下で示されるように、XMLストラテジフィールド(Strat field)と一致する。

本発明の実施形態は、その注文を以下の表２のように変換する。

前記stratParametersセクションは、できれば、三種類のタグを具備するのが望ましい（表３）。

(属性にキーワード"tag"を使用しないこと)

異なるアルゴリズム取引プロバイダによって使用される実際のFIXタグは、異なりうることに注意。

本発明をほんの一例として説明してきたが、本発明の精神および範囲から逸脱することなくそれの改良態様および変形態様は作成可能である。例えば、本発明の範囲から逸脱することなく、注文管理およびルーティングシステムは、XML以外を使用してもよく、また注文管理および実行システムは、FIX以外を使用してもよい。

本発明におけるシステムおよびアルゴリズム取引フローの一実施例を示している。 典型的なコア注文のグラフィカル表示を示している。 典型的なアルゴリズム取引のためのグラフィカル・インターフェースを示している。

Claims (15)

1. コンピュータにより実施される方法であって、
   コンピュータが、ユーザにより選択された証券売買注文を受信するステップと、
   前記注文を、注文管理システム(ＯＭＳ)が解釈可能な第一フォーマットに変換するステップと、
   前記変換された注文を前記注文管理システムに送信するステップと、
   を具備し、
   前記第一フォーマットに変換された前記証券売買注文は、パラメータを備えており、
   前記パラメータは、コアパラメータと、ストラテジパラメータとが異なるグループに分けられており、それぞれのグループにおいて処理可能であることを特徴とする方法。
2. 前記第一フォーマットは、ＸＭＬであることを特徴とする請求項１に記載の方法。
3. 前記変換するステップは、前記注文を前記第一フォーマットから前記注文管理システムと互換性のある第二フォーマットへ変換するステップをさらに具備することを特徴とする請求項１に記載の方法。
4. 前記第二フォーマットは、FIXであることを特徴とする請求項３に記載の方法。
5. プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
   前記プログラムは、コンピュータに、
   ユーザにより選択された証券売買注文を示す情報を前記コンピュータが受信する機能と、
   前記証券売買注文を示す情報を、注文管理システム(ＯＭＳ)が解釈可能な第一フォーマットへ変換する機能と、
   前記変換された証券売買注文を示す情報を前記注文管理システムへ送信するための機能と、
   を実現させ、
   前記第一フォーマットに変換された前記証券売買注文は、パラメータを備えており、
   前記パラメータは、コアパラメータと、ストラテジパラメータとが異なるグループに分けられており、それぞれのグループにおいて処理可能であることを特徴とするコンピュータ読み取り可能な記録媒体。
6. 前記第一フォーマットは、ＸＭＬであることを特徴とする請求項５に記載のコンピュータ読み取り可能な記録媒体。
7. 前記変換する機能は、前記証券売買注文を示す情報を前記第一フォーマットから前記注文管理システムと互換性のある第二フォーマットへ変換するための機能をさらに具備することを特徴とする請求項５に記載のコンピュータ読み取り可能な記録媒体。
8. 前記第二フォーマットは、ＦＩＸであることを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
9. コンピュータシステムは、
   ユーザにより選択された証券売買注文を受信可能な注文コンポーネントと、
   前記注文を、注文管理システム(ＯＭＳ)が解釈可能な第一フォーマットに変換可能な変換コンポーネントと、
   変換された注文を前記注文管理システムへ送信可能な送信コンポーネントと、
   を具備し、
   前記第一フォーマットに変換された前記証券売買注文は、パラメータを備えており、
   前記パラメータは、コアパラメータと、ストラテジパラメータとが異なるグループに分けられており、それぞれのグループにおいて処理可能であることを特徴とするコンピュータシステム。
10. 前記第一フォーマットは、ＸＭＬであることを特徴とする、請求項９に記載のシステム。
11. 前記変換コンポーネントは、前記注文を前記第一フォーマットから前記注文管理システムと互換性のある第二フォーマットへさらに変換可能であることを特徴とする請求項９に記載のシステム。
12. 前記第二フォーマットは、ＦＩＸであることを特徴とする請求項１１に記載のシステム。
13. ストラテジXMLフィールドをFIXプロトコルへ適応するための一つまたは複数の注文ハンドラをさらに具備することを特徴とする請求項９に記載のシステム。
14. 前記注文コンポーネントは、ウェブサーバを具備することを特徴とする請求項９に記載のシステム。
15. 前記注文コンポーネントは、コンピュータネットワークと通信するワークステーションを具備することを特徴とする請求項９に記載のシステム。

Images