JP5007239B2 - 分散取引照合サービス - Google Patents

Description

本発明は、取引清算システムおよび方法に関する。より具体的には、本発明は、分散取引照合サービスを含む取引清算システムおよび方法に関する。

取引所および他の機関が、取引を照合するためにコンピュータ装置を使用して取引清算機能を実行することは、広く行われている。例えば、２人のトレーダは、別のカードに取引データを記録してもよい。次いで、取引データは、取引を照合するように構成されたコンピュータシステムに入力されてもよい。典型的なコンピュータシステムは、未処理のアンマッチの取引を照合するために、所定のプロセスを踏むモノリシック清算アプリケーションを利用する。例えば、清算アプリケーションは、共通のマッチクリティカルフィールドを持つすべての取引を照合しようとしてもよい。マッチクリティカルフィールドは、個別の取引を特定するために使用される実行ブローカＩＤ、約定、価格および他の情報を含んでもよい。

既存のモノリシック清算アプリケーションは、修正や拡張が難しいことがある。例えば、新しい種類の取引を照合する必要があるとき、アプリケーションの大きなセグメントに及ぶ大規模な修正が必要になる。さらに、そのアプリケーションのモノリシック構造は、新しい機能を追加するとき必要になる修正数のために拡張性を制限する。

既存の取引清算システムおよび方法の別の制限は、「バッチ」モードで動作するように設計されることである。アンマッチの取引は周期的に分析され、アンマッチの取引を照合する手続きが取られる。アンマッチの取引を照合するために使用される基準は、時間の経過に連れて、すべてのアンマッチの取引に対して次第に緩くなる。このバッチプロセスでは、各取引がどのくらい長くアンマッチのままであるかにかかわらず、すべてのアンマッチの取引を同じく取り扱う。さらに、バッチプロセスの実行中に処理リソースが大規模に消費され、バッチプロセスの実行から実行までの期間に処理リソースが消費されないことから、リソース利用の効率が悪くなる。

それ故、当技術分野では、もっと拡張性があり効率的な取引照合システムおよび方法の必要性がある。

本発明の態様は、分散取引照合システムおよび方法を提供することにより、先行技術の問題および限界を克服する。複数のサーバが、取引を照合するために一体となって働く。一実施形態では、すべての取引データは各サーバに格納される。別の実施形態では、取引照合の作業負荷を分割するために、取引データは個別のサーバに割り当てられてもよい。アンマッチのまま残る取引データは、１つ以上のエージングキューに格納されてもよい。取引データは、エージングキューから定期的に読み出され、アンマッチの取引の照合が試みられる。個別取引の取引データがエージングキューに格納された時から時間が経過するに連れて、取引を照合するために使用される照合基準は緩められる。

本発明の実施形態によっては、開示の清算システムおよび方法は、先物取引およびオプション取引を清算するために使用されてもよい。

他の実施形態では、例えば、コンピュータで実行可能な命令またはモジュールを格納することにより、またはコンピュータで読み取り可能なデータ構造を利用することにより、コンピュータで読み取り可能な記憶媒体に一部または全部が実装されてもよい。

もちろん、上記の実施形態の方法およびシステムは、他の追加の要素、ステップ、コンピュータで実行可能な命令、またはコンピュータで読み取り可能なデータ構造も含んでもよい。

本発明のこれらおよび他の実施形態の詳細は、添付の図面および以下の説明に記載する。本発明の他の特徴および利点は、説明および図面、ならびに特許請求項から明らかになるだろう。

本発明は、部分およびステップによっては、物理的形態を取ってもよい。その実施形態を、以下の説明で詳細に記述し、その説明の一部を形成する添付図面に示す。

［典型的な動作環境］
本発明の態様は、コンピュータ装置およびコンピュータネットワークで、またはそれらを併せて使用して、実行されるのが好ましい。図１に、取引システムおよび方法を実行する典型的な取引ネットワーク環境を示す。取引コンピュータシステム１００は注文を受け付け、ユーザに注文および取引に関連する市場データを送信する。取引コンピュータシステム１００は、１台以上のメーンフレーム、デスクトップまたは他のコンピュータで実装されてもよい。ユーザデータベース１０２は、トレーダおよび取引コンピュータシステム１００の他のユーザを特定する情報を含む。データには、ユーザ名およびパスワードを含んでもよい。アカウントデータモジュール１０４は、取引中に使用されてもよいアカウント情報を処理してもよい。照合エンジンモジュール１０６は、指値と売値とをマッチさせるために含まれる。照合エンジンモジュール１０６は、売りと買いをマッチさせるために１つ以上のアルゴリズムを実行するソフトウェアで実装されてもよい。取引データベース１０８は、取引および取引銘柄を特定する情報を格納するために含まれてもよい。特に、取引データベースは、取引が行われた時刻および約定価格を特定する情報を格納してもよい。発注指示書モジュール１１０は、現在の指値と売値を計算また他の方法で決定するために含まれてもよい。市場データモジュール１１２は、市場データを集め、ユーザへの送信用にデータを準備するために含まれてもよい。リスク管理モジュール１３４は、ユーザに定められたリスク閾値に関連してユーザのリスク利用を計算し決定するために含まれてもよい。注文処理モジュール１３６は、発注指示書モジュール１１０および照合エンジンモジュール１０６による処理のために、差分ベース注文種類とバルク注文種類とを分解するために含まれてもよい。

図１に示す取引ネットワーク環境は、コンピュータ装置１１４、１１６、１１８、１２０、１２２を含む。各コンピュータ装置は、コンピュータ全体の動作を制御する中央処理装置、および中央処理装置をネットワークカードやモデムなどの１つ以上の従来の構成要素に接続するシステムバスを含む。各コンピュータ装置は、様々なインタフェース部も含み、データまたはファイルの読み取りおよび書き込みを行ってもよい。コンピュータ装置の種類に応じて、ユーザはキーボード、ポインティングデバイス、マイクロホン、ペンデバイスまたは他の入力装置を使用して、コンピュータとやりとりすることができる。

図では、コンピュータ装置１１４は、取引コンピュータシステム１００に直接接続している。取引コンピュータシステム１００およびコンピュータ装置１１４は、Ｔ１回線、普及しているローカルエリアネットワーク（ＬＡＮ）、またはコンピュータ装置を接続する他のメカニズムを介して接続されてもよい。図では、コンピュータ装置１１４は、無線機１３２に接続している。無線機１３２のユーザは、トレーダまたは取引所従業員であってもよい。無線機ユーザは、コンピュータ装置１１４のユーザに注文または他の情報を送信してもよい。次いで、コンピュータ装置１１４のユーザは、取引コンピュータシステム１００に取引または他の情報を送信してもよい。

コンピュータ装置１１６、１１８は、ＬＡＮ１２４に結合する。ＬＡＮ１２４は、１つ以上の周知のＬＡＮ接続形態であってもよく、イーサネット(登録商標)などの様々な異なるプロトコルを使用してもよい。コンピュータ１１６、１１８は、互いに通信してもよいし、またＬＡＮ１２４に接続する他のコンピュータおよび装置と通信してもよい。コンピュータおよび他の装置は、ツイストペア線、同軸ケーブル、光ファイバまたは他の媒体を介してＬＡＮ１２４に接続されてもよい。代わりに、無線携帯情報端末（ＰＤＡ）１２２は、電波を介してＬＡＮ１２４またはインターネット１２６と通信してもよい。ＰＤＡ１２２は、従来の無線ハブ１２８を介して取引コンピュータシステム１００とも通信してもよい。本明細書では、ＰＤＡには、携帯電話機および電波を介してネットワークと通信する他の無線装置を含む。

図１は、ＬＡＮ１２４がインターネットに接続していることも示す。ＬＡＮ１２４は、ＬＡＮ１２４をインターネット１２６に接続するルータを含んでもよい。図では、コンピュータ装置１２０は、インターネット１２６に直接接続している。接続は、モデム、ＤＳＬ回線、衛星放送受信アンテナ、またはコンピュータ装置をインターネットに接続する他の装置を介してであってもよい。

１つ以上の値付け業者１３０が、デリバティブまたは有価証券に対して一定の指値および売値を取引コンピュータシステム１００に提供し、市場を維持してもよい。取引コンピュータシステム１００は、取引エンジン１３８などの他の取引エンジンとも情報を交換してもよい。多数の追加のコンピュータおよびシステムが取引コンピュータシステム１００に結合してもよいことを、当業者なら理解するであろう。そのコンピュータおよびシステムには、清算システム、調整システムおよび手数料システムを含んでもよい。

図１に示すコンピュータ装置およびシステムの動作は、コンピュータで読み取り可能な記憶媒体に格納されたコンピュータで実行可能な命令により、制御されてもよい。例えば、コンピュータ装置１１６は、ユーザから注文情報を受け付け、取引コンピュータシステム１００に注文情報を送信するコンピュータで実行可能な命令を含んでもよい。別の例では、コンピュータ装置１１８は、取引コンピュータシステム１００から市場データを受信し、そのデータをユーザに表示するコンピュータで実行可能な命令を含んでもよい。

もちろん、多数の追加のサーバ、コンピュータ、ハンドヘルド装置、携帯情報端末、電話機および他の装置も、取引コンピュータシステム１００に接続されてもよい。また、図１に示す接続形態は単なる例であり、図１に示す構成要素は多数の代替接続形態で接続されてもよいことは、当業者なら理解するであろう。

［典型的な実施形態］
図２は、本発明の一実施形態に従う分散取引照合システムを図解する。フロントエンド清算アプリケーション２０２は、取引データ２０４を受信する。取引データ２０４は、実行ブローカＩＤ、約定、価格および量などの取引を特定する情報を含んでもよい。照合クライアント２０６は、フロントエンド清算アプリケーション２０２と複数台の照合サーバ２０８ａ〜２０８ｃとを通信可能にするアプリケーションプログラムインタフェースおよび／または他のソフトウェアモジュールを含んでもよい。異なるフロントエンド清算アプリケーションが照合サーバと通信するのを可能にするために、様々な異なる照合クライアントが使用されてもよい。例えば、第１のフロントエンド清算アプリケーションは、１組の照合サーバと通信するために第１の照合クライアントを使用してもよく、第２のフロントエンド清算アプリケーションは、同じ１組の照合サーバと通信するために第２の照合クライアントを使用してもよい。フロントエンド清算アプリケーション２０２は、全取引データベース２１０とも結合される。全取引データベース２１０は、行われた全取引のマスタレコードを収容する。

図２に示す実施形態は、３台の照合サーバ２０８ａ〜２０８ｃを含む。サーバ２０８ａ〜２０８ｃは、同じ場所に設置されてもよいし、地理的に分散設置されてもよい。３台のサーバは図解目的だけであり、本発明の態様は、サーバをもっと多く使用してもよいし、また少なくてもよいという理解のもとで示している。照合サーバ２０８ａ〜２０８ｃは、それぞれ互いに接続されてもよいし、共通ハブを通して接続されてもよいし、また各照合サーバを残りの照合サーバと通信可能にする別のやり方で接続されてもよい。サーバ２０８ａ〜２０８ｃは、取引所で実行される取引などの取引を照合するモジュールを収容する。サーバ２０８ａは、アンマッチの取引を照合するソフトウェアアプリケーションで実装されてもよい照合モジュール２１２ａを含む。照合モジュール２１２ａは、取引照合のためのルールセットを含んでもよいし、またそれにリンクしてもよい。取引照合ルールは、個別の取引を照合するために使用される特定の照合基準を特定してもよい。以下に詳細に記述するように、照合モジュールは、幾つかの異なる照合基準を使用してもよく、選択される照合基準は、取引データがアンマッチのままでいた期間の関数であってもよい。

照合基準は、企業、企業番号、ブローカ番号、量、実行ブローカおよび期間などのマッチクリティカルフィールドに言及してもよい。本発明の実施形態によっては、ある照合基準は正確でなければならず、決して緩めてはならない。その基準には、価格、約定および取引所のＩＤを含んでもよい。

１対１の照合を実行するのに加えて、照合モジュール２０８ａは、１対多取引および／または多対多取引を照合するようにプログラムされてもよい。照合モジュール２０２は、マッチする取引のサブセットも見つけてもよい。１つ以上の照合モジュールが、取引を照合するとき、複数のスレッドを使用してもよい。

サーバ２０８ｂ、２０８ｃは、照合モジュール２１２ａと同様の照合モジュール２１２ｂ、２１２ｃを含んでもよい。本発明の一実施形態では、照合モジュールは、特定の種類の取引または特定の場所で行われた取引を照合するために、使用されてもよい。例えば、照合モジュール２１２ａは、１つの取引所で実行された取引を照合するように構成されてもよく、照合モジュール２１２ｂは、他の取引所で実行された取引を照合するために使用されてもよい。

取引データは、最初にフロントエンド清算アプリケーション２０２から受信され、キャッシュ２１４ａ〜２１４ｂに格納される。本発明の一実施形態では、各キャッシュは、全取引データを収容する。本発明の別の実施形態では、取引データは、キャッシュ２１４ａ〜２１４ｃの間で分散される。取引がマッチすると、照合モジュール２１２ａ〜２１２ｃは互いに通信し、すでにマッチした取引を照合しようとしてリソースを費やさないようにする。

本発明の一実施形態では、照合モジュール２１２ａ〜２１２ｃおよび／またはキャッシュ２１４ａ〜２１４ｃは、Ｊａｖａ(登録商標)メッセージングサービスの標準メッセージ発行およびメッセージ購読申し込みアプリケーションプログラムインタフェース（ＡＰＩ）を使用して通信する。交換されてもよい情報の種類は、キャッシュ２１４ａ〜２１４ｃに取引データを追加、更新および除去するための情報を含む。一実装では、キャッシュの全状態を特定する情報とは対照的に、キャッシュ２１４ａ〜２１４ｃの状態の変化を特定する情報だけが交換される。

サーバ２０２ａ〜２０２ｃ間で交換された一部または全部のメッセージは、同期モジュール２１８が各サーバの構成要素の状態を維持できるように、同期モジュール２１８にも送信されてもよい。同期モジュール２１８は、照合モジュール２１２ａ〜２１２ｃ、キャッシュ２１４ａ〜２１４ｃ、および／またはエージングキュー２１６２ａ〜２１６ｃとメッセージを交換して、それら構成要素の状態を判定してもよい。サーバ２０８ａ〜２０８ｃまたは決定的に重要な構成要素の１つが故障の場合には、同期モジュール２１８は、サーバ２０８ａ〜２０８ｃが使用するデータのすべてを格納してもよい維持モジュール２２２から何のデータを取得すべきかを、別のサーバまたは構成要素に通知してもよい。例えば、サーバ２０８ａが故障した場合、同期モジュール２１８は、キャッシュ２１４ａおよびエージングキュー２１６ａに格納された取引データを特定し、維持モジュール２２２からデータを取得し、キャッシュ２１４ｂおよびエージングキュー２１６ｂにロードするようにサーバ２０８ｂに指示する。維持モジュール２２２は、データベース２２４にデータを格納してもよい。

サーバ２０８ａ〜２０８ｃは、エージングキュー２１６ａ〜２１６ｃも含んでもよい。各エージングキューは、アンマッチの取引データを収容してもよい。各エージングキューは、仕事負荷がサーバ間に分散されるように、アンマッチの取引データの固有のサブセットを収容してもよい。取引データの要素に対する時間が経過するに連れて、照合基準が緩められるように、各取引は個別に古くされてもよい。例えば、照合モジュール２１２ａは、データをエージングキュー２１６ａに１時間格納した後、照合基準を緩くし、取引データを照合するために再試行するように構成されてもよい。先行技術の照合システムでは、取引データはバッチ方式で処理され、照合基準は、所与の時刻には、アンマッチの全取引に対して同じ量緩められる。取引を個別に古くすることで、より効率的な照合システムを提供する。さらに、照合基準には、幾つかの追加のレベルが使用されてもよい。例えば、照合モジュールは、異なるレベルの照合基準で１日２回バッチプロセスを実行する代わりに、照合基準に様々なマッチレベルを使用して１０回以上照合を試みてもよい。

同期モジュール２１８は、いずれの時点でも照合モジュール２１２ａ〜２１２ｃの１台しか取引データを照合する許可を得られないように保証してもよい。一実施形態では、キャッシュ２１４ａ〜２１４ｃに格納されたアンマッチの取引データは、照合モジュールが取引を照合しようとしている間、同期モジュール２１８が取引の状態をロックすることを可能にするデータ構造または他のメカニズムを含む。例えば、照合モジュール２１２ａが特定の取引に対する取引データを照合しようとする場合、同期モジュール２１８は、キャッシュ２１４ｂ、２１４ｃに格納された取引データの複写をロックし、２つの照合モジュールが同じデータを照合しないようにするだろう。

同期モジュール２１８は、エージングキュー２１６ａ〜２１６ｃに格納された取引データへのアクセスも制御するように構成されてもよい。同期モジュール２１８および／またはエージングキュー２１６ａ〜２１６ｃは、衝突の可能性が存在するとき、取引データを古くすることを遅らせるように構成されてもよい。例えば、照合モジュール２１２ａは、エージングキュー２１６ａに格納された取引データとエージングキュー２１６ｃに格納された取引データを照合しようとして、エージングキュー２１６ｃに格納された取引データが同期モジュール２１８によりロックされていることを確認してもよい。取引データのロック状態がなかったとして、取引が照合されたとした場合、次回照合しようとするとき衝突の可能性を減少するために、取引データの各要素をランダムにまたは所定の時間遅らせてもよい。本発明の一実施形態では、各エージングキューは、後の照合試行中の衝突の可能性を減少するために、固有の遅延を割り当てる。

図２に図解するシステムは、サーバ２０８ａ内にバックアップ同期モジュール２２０を含む。バックアップ同期モジュール２２０は、同期モジュール２１８またはサーバ２０８ｃが故障の場合に、同期モジュール２１８の代わりに動作するように構成されてもよい。図２に図解するシステムでは、１つ以上の構成要素の故障時に、正常な働きを確実にする冗長性を加えてもよい。

本発明の一実施形態では、各同期モジュールまたは維持モジュールは、照合モジュールが動作可能であることを示す周期的なメッセージを、各照合モジュール２０２ａ〜２０２ｃから受信してもよい。予期されたメッセージが受信されないとき、データは、データベース２２４から読み出され、故障した照合モジュールに代わって動作を続ける別の照合モジュールに送信されてもよい。

アウトトレードローダモジュール２２６は、全取引データベース２１０とデータベース２２４との内容を同期させてもよい。同期は、例えばフロントエンド清算アプリケーション２０２が全取引データベース２１０から取引データを除去するとき、必要であってもよい。同期は、取引時間外に週１回などの定期的間隔で行われてもよい。

図３は、本発明の一実施形態に従う取引照合方法を示す。ステップ３０２で、取引データを照合サーバで受信する。上記のように、取引データは、実行ブローカＩＤ、約定、価格および量などの取引を特定する情報を含んでもよい。ステップ３０４では、取引データを照合する試みが行われる。ステップ３０４は、照合モジュール２１２ａなどの照合モジュールで実行されてもよく、取引の一方からの取引データと、同じ取引の他方からの取引データとを照合する試みを含んでもよい。

次いでステップ３０６で、取引データがマッチしたかどうかが判定される。取引データがマッチしたときは、プロセスはステップ３１８に進み、それについては後で述べる。取引データがマッチしなかったときは、ステップ３０８で取引データはエージングキューに格納される。取引データが、ステップ３１０で所定の時間エージングキューに格納された後で、照合基準は、ステップ３１２で緩められる。本明細書では、「所定の時間」は、取引データを個別に古くする時間も含むことを意図している。例えば、所定の時間は、１時間などの一定した時間間隔であってもよいし、また照合サーバの負荷で決まる一定の間隔であってもよい。「所定の時間」は、すべての取引データがバッチプロセスに従って処理されるときに終わる時間間隔を含まない。

エージングキューに取引データを所定の時間格納するのは、取引データの相手側の処理の時間を見越しているからであり、次の試みでマッチする相手を見つけられる可能性が増加する。照合基準が緩和された後、ステップ３１４で取引データを照合する試みがまた行われる。ステップ３１２では、照合基準間で緩めた照合を必要として１つ以上の照合基準の削除、または取引相手側からの取引データをマッチしやすくする他の変更を含んでもよいことは、当業者なら理解するだろう。例えば、ステップ３０４で、企業番号、ブローカ番号、量および約定について同一のマッチを見つける試みを含む場合、ステップ３１２ではブローカ番号フィールドの削除を含んでもよく、ステップ３１４では、企業番号、量および約定について同一のマッチを見つける試みを含んでもよい。

ステップ３１６では、取引データがマッチしたかどうかが再び判定される。取引データがマッチしたとき、照合サーバは、ステップ３１８で他の照合サーバに状態変更情報を送信してもよい。ステップ３１８により、他の照合サーバがマッチした取引データを照合しようとするのを停止することが可能になる。

取引データがステップ３１６でマッチしないとき、プロセスはステップ３１０に戻り、所定の時間後、照合基準は再び緩められ、取引データを照合する試みがまた行われる。

図４は、本発明の一実施形態に従う、照合サーバの耐故障運用方法を説明する。ステップ４０２で、サーバデータは複数の照合サーバに格納される。維持モジュールは、ステップ４０４で、複数の照合サーバに格納されたすべてのサーバデータの複写を維持する。新しいデータが照合サーバに到着したとき、または照合サーバが新しいデータを作成したとき、サーバデータは維持モジュールに送信され格納される。ステップ４０６で、照合サーバが故障しているかどうか判定される。ステップ４０６は、照合サーバの試験結果の分析を含んでもよい。照合サーバが故障していないと判定されると、プロセスは、ステップ４０８で所定の時間待った後、再び照合サーバの状態をチェックする。代替実施形態では、照合サーバは、同期モジュール２１８などの同期モジュールに状態メッセージを周期的に送信してもよく、同期モジュールは、メッセージの内容またはメッセージの欠如に基づき、照合サーバの一構成要素または全体が故障したと判定してもよい。

ステップ４１０では、同期モジュールまたは他の構成要素は、故障していない照合サーバにメッセージを送信してもよく、維持モジュールに格納されたサーバデータの中から、故障の照合サーバまたは構成要素に属するサーバデータを特定する。最後に、ステップ４１２でサーバデータは、故障していない照合サーバに提供される。もちろん、ステップ４１０および４１２は、故障したサーバの処理動作を２台以上の使用可能な照合サーバが引き継ぐように修正されてもよい。一代替実施形態では、同期モジュールは使用可能な照合サーバにサーバデータを直接送信してもよい。

本発明を実行する現在好ましい様式を含む特定の例に関して本発明を記述したが、上記のシステムおよび技術の変形形態および変更形態の多くが、添付の請求項の範囲に記載する本発明の精神および範囲内に入ることは、当業者なら理解するだろう。

本発明の態様を実行するために使用してもよいコンピュータネットワークシステムの模式図である。 本発明の一実施形態に従う分散取引照合システムのブロック図である。 本発明の一実施形態に従う取引照合方法のフローチャート図である。 本発明の一実施形態に従う照合サーバの耐故障運用方法のフローチャート図である。

Claims (12)

1. 取引所において取引データを照合する方法であって、
   （ａ） 照合モジュール、エージングキューおよびキャッシュを有する照合サーバが複数の取引データを受信して、前記複数の取引データを前記キャッシュに格納するステップと、
   （ｂ） 前記照合モジュールが、第１の照合基準により特定され且つ一致が示されるために一致しなければならない第１の組のマッチクリティカルフィールドについて、前記複数の取引データの１つと取引相手側からのデータとが一致するかを判断するステップと、
   （ｃ） （ｂ）の後も前記複数の取引データの前記１つが一致しないままであるとき、前記照合モジュールが、前記複数の取引データの前記１つを個別に古くするために前記エージングキューに格納するステップと、
   （ｄ） 前記照合モジュールが、前記エージングキューに前記複数の取引データの前記１つを格納してから第１の所定の時間後、第２の照合基準により特定され且つ一致が示されるために一致しなければならない第２の組のマッチクリティカルフィールドについて、前記複数の取引データの前記１つと前記取引相手側からのデータとが一致するかを判断するステップと
   を含み、
   前記第２の照合基準は前記第１の照合基準より緩いことを特徴とする方法。
2. 前記第２の組のマッチクリティカルフィールドは、前記第１の組のマッチクリティカルフィールドより少ないことを特徴とする請求項１に記載の方法。
3. （ｅ） 前記照合モジュールが、（ｄ）の後も前記複数の取引データの前記１つが一致しないままであるとき、（ｄ）から第２の所定の時間後、第３の照合基準により特定され且つ一致が示されるために一致しなければならない第３の組のマッチクリティカルフィールドについて、前記複数の取引データの前記１つと前記取引相手側からのデータとが一致するかを判断するステップをさらに含み、前記第３の照合基準が前記第２の照合基準より緩いことを特徴とする請求項１に記載の方法。
4. （ａ） 照合モジュールが、キャッシュに格納された複数の取引データの１つと取引相手側からのデータとが、第１の照合基準によって、一致するかを判断するステップと、
   （ｂ） （ａ）の後も前記複数の取引データの前記１つが一致しないままであるとき、前記照合モジュールが、前記複数の取引データの前記１つを個別に古くするためにエージングキューに格納するステップと、
   （ｃ） 前記複数の取引データの前記１つを前記エージングキューに格納してから第１の所定の時間後、前記照合モジュールが、前記複数の取引データの前記１つと前記取引相手側からのデータとが、前記第１の照合基準より緩い第２の照合基準によって、一致するかを判断するステップと
   を含むことを特徴とする取引データを照合する方法。
5. 前記第２の照合基準は、前記第１の照合基準によって特定されるマッチクリティカルフィールドより少ないマッチクリティカルフィールドを特定することを特徴とする請求項４に記載の方法。
6. 前記第１の照合基準は、実行ブローカ、約定、価格および期間を有するマッチクリティカルフィールドについて一致させることを含むことを特徴とする請求項４に記載の方法。
7. 前記照合モジュールが、（ｃ）の後も前記複数の取引データの前記１つが一致しないままであるとき、（ｃ）から第２の所定の時間後、前記複数の取引データの前記１つと前記取引相手側からのデータとが、前記第２の照合基準より緩い第３の照合基準によって、一致するかを判断するステップをさらに含むことを特徴とする請求項４に記載の方法。
8. 前記第１、第２および第３の照合基準は、価格および約定のマッチクリティカルフィールドを備えることを特徴とする請求項７に記載の方法。
9. （ａ）の前記取引相手側は複数の取引を備えることを特徴とする請求項４に記載の方法。
10. 第１の照合モジュール、第１のエージングキューおよび第１のキャッシュを有する第１の照合サーバであって、前記第１の照合モジュールが、前記第１のキャッシュに格納された第１の種類の取引の取引データを前記第１の種類の取引の取引相手側からの取引データと一致させ、一致しない前記第１の種類の取引の取引データを前記第１のエージングキューに格納するように構成された第１の照合サーバと、
    第２の照合モジュール、第２のエージングキューおよび第２のキャッシュを有する第２の照合サーバであって、前記第２の照合モジュールが、前記第２のキャッシュに格納された第２の種類の取引の取引データを前記第２の種類の取引の取引相手側からの取引データと一致させ、一致しない前記第２の種類の取引の取引データを前記第２のエージングキューに格納するように構成された第２の照合サーバと、
    前記第１の照合サーバおよび前記第２の照合サーバに結合し、前記第１の照合サーバおよび前記第２の照合サーバにそれぞれ前記第１の種類の取引の取引データおよび前記第２の種類の取引の取引データを送信するように構成された照合クライアントと、
    前記第１の照合サーバおよび前記第２の照合サーバとメッセージを交換して前記第１および第２の照合モジュール、前記第１および第２のエージングキューおよび前記第１および第２のキャッシュの状態を維持する同期モジュールを有するサーバと
    を備え、
    前記第１および第２のエージングキューは、前記第１および第２の種類の取引の取引データをそれぞれ照合する前回の試みと次回の試みとの間の時間に、一致しない前記第１および第２の種類の取引の取引データを個別に古くすることを特徴とする取引データを照合するシステム。
11. 前記第１の照合サーバおよび前記第２の照合サーバは、地理的に分散していることを特徴とする請求項１０に記載のシステム。
12. 前記第１の照合サーバおよび前記第２の照合サーバは、異なる取引所に配置されることを特徴とする請求項１１に記載のシステム。

Images