JP2004502243A - 匿名取引システムでのクレジット限度記憶 - Google Patents
匿名取引システムでのクレジット限度記憶 Download PDFInfo
- Publication number
- JP2004502243A JP2004502243A JP2002506499A JP2002506499A JP2004502243A JP 2004502243 A JP2004502243 A JP 2004502243A JP 2002506499 A JP2002506499 A JP 2002506499A JP 2002506499 A JP2002506499 A JP 2002506499A JP 2004502243 A JP2004502243 A JP 2004502243A
- Authority
- JP
- Japan
- Prior art keywords
- credit
- trading
- transaction
- message
- anonymous
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/08—Auctions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
Abstract
匿名取引システムは、それぞれが価格照合、取引実行、およびマーケットディストリブーション（市場分配）を実行する取引者ノードのネットワークを含む。取引者端末は、取引フロアにあり、所定の取引者ノードに取引エージェントノードを介し接続されている。クレジットは、所定の取引フロアにその取引エージェントノードに格納されるか、またはクレジットエージェントノードに格納される。クレジットエージェントノードには、取引フロアのグループのクレジット限界を記憶される。提案された取引のパーティーのクレジット限界がクレジットエージェントノードに格納されているとき、取引実行プロセスは、クレジットエージェントノードに利用可能クレジットをチェックするように回される。システムは、機関が取引を希望する相手パーティーとのローカルおよびグローバルのクレジットアサイメントのいかなる組合せも受け入れることを許容する。
Description
【０００１】
（発明の分野）
本発明は、電子仲介システムに関し、特に、相手方が、一定のクレジット限度内で匿名で取り引きをするシステムに関する。このようなシステムは、外国為替および金利先渡し契約のような金融商品を取り引きすることができる。本発明は、特にこのようなシステムでの、双方当事者間でのクレジット限度の処理に関する。
【０００２】
（発明の背景）
当業者にとっては、多数の匿名取引システムは周知のものである。ロイター社に譲渡された、ＥＰ−Ａ−０，３９９，８５０号、ＥＰ−Ａ−０，４０６，０２６号およびＥＰ−Ａ−０，４１１，７４８号すべては、ホスト・コンピュータが、ネットワークを通してホストに接続している端末が提出した入札およびオファーの中央データベースを維持している自動照合システムの種々の機能を開示している。ホストは、また、各取引銀行およびこれらの銀行と進んで取引きする相手方との間のクレジット限度の記録も維持している。ホスト・コンピュータは、入札およびオファーを照合し、相手方のクレジット限度を含む照合基準に基づいて注文を売買するために、その中央データベース内の情報を使用する。
【０００３】
通常、相手方のクレジット限度は、各銀行または各立会場（取引フロア）に対して設定されていて、ホスト・コンピュータは、可能な当事者の組に対する総当事者クレジット限度を確立する。総当事者クレジット限度は、２人の当事者間の残りのクレジットの最小額である。
【０００４】
取引業者端末は、通常は、最も高額のいくつかの入札およびオファーである取引記録のサブセットを表示する。取引業者が確実に市場の本当の姿を見ることができるように、これらの入札およびオファーは周期的に更新される。
【０００５】
上記システムに関する１つの問題は、取引業者が、自分が取引きのために、上記入札またはオファーを行っている相手方に対して十分なクレジットを持っているかどうかにかかわらず、上記入札およびオファーを閲覧することができることである。その結果、取引業者は、行使できるクレジットがない場合でも、取引きの申し込みを行うことができる。システムは匿名であるので、取引業者は、取引きが完了するまで相手方を知ることができず、そのため、その取引業者が入札またはオファーを行うのに成功した場合、クレジットを持っていないという理由で、受諾してよいのか拒否したらよいのかについて全然わからない。このことは、取引業者にとって非常に困った問題であって、特に、取引きの機会がすぐに失われてしまう動きの速い市場では特に困った問題である。上記問題の原因は、取引きが申し込まれ、成立の可能性がある場合に、ホスト・コンピュータだけしか、行使できるクレジットをチェックできないという事実によるものである。
【０００６】
この問題は、ＥＢＳディーリング・リソース社に譲渡されたＷＯ９３／１５４６７号により解決済みである。各取引業者に、実際の取引記録またはその一部を表示する代わりに、各取引業者に、自分たちが、十分なクレジットを持っていないか、全然クレジットを持っていない相手方からの入札およびオファーが映し出されている他の市場の様子が表示される。それ故、取引業者は、自分が取引きすることができる価格を見るだけですむ。
【０００７】
ＷＯ９３／１５４６７号のシステムのアーキテクチャは、ロイター・システムとは非常に異なっていて、照合を行う多数の仲介業者を含む分散型ネットワークに基づいている。実際のクレジット限度は、各銀行の取引端末が接続しているローカル銀行ノードに記憶されていて、それにより、どのようにしても、変動しやすいクレジット・データを銀行の物理的サイトから取り出すことができないようになっている。実際の取引記録は、仲介業者により市場配給業者に送られる。市場配給業者は、所定の立会場（取引フロア）に特有の市場の展望を作成し、それを関連銀行ノードに送る。クレジット基準により、各取引立会場について、異なる市場の展望を作成することができる。それ故、各銀行ノードに配布される市場の展望は、クレジット審査の場についての完全な市場展望であり、それにより、銀行または銀行内の所定の立会場は、クレジットが不十分な任意の価格をふるい落とすことができる。
【０００８】
さらに、市場配給業者は、また、ある程度のクレジット情報を持っていて、所定の相手方に対して、１つの「はい（ｙｅｓ）−いいえ（ｎｏ）」クレジット・インジケータを記憶することができるクレジット・マトリックスを維持している。取引きが成立すると、価格がクレジットのためにすでに選択されているので、銀行ノードは、任意の前に与えられたクレジットがすでに使用されてしまっているかどうかをチェックするために、クレジット・マトリックスにより第２のクレジット・チェックを行う。
【０００９】
ＷＯ９３／１５４６７号のシステムの場合には、特定の立会場は、個々に、他の立会場に、またはクレジット構成要素としてグループに統合された立会場に、クレジットを割り当てることができる。しかし、ある機関レベルまたはグローバルなレベルからのクレジットの割当てに対する規定はない。
【００１０】
クレジット機能は、クレジット・グループおよび実際のクレジット限度額についての情報を維持している銀行ノードに常駐している。銀行ノードは、はい／いいえクレジット関係によってだけ、仲介業者にクレジット情報を送る。所定の相手方に対するクレジット額は、毎日の自動的なリセット、または立会場の管理者による手動介入により、または、取引きの間に変化する場合がある。使用できるクレジットがゼロになるか、またはゼロから正の数値にリセットされると、クレジット更新メッセージが、銀行ノードからそのクレジット・グループに属する立会場の仲介業者に送られる。
【００１１】
上記両方のシステムは、多年にわたって、金融取引市場で使用され成功を収めてきたが、両システムは、クレジットの処理については非常に柔軟性に乏しいという欠点をもっている。これらのシステムの場合には、銀行は、その取引活動のある領域内で、多額のクレジットとタイアップしなければならない。通常の銀行は、多数の金融商品、および多数の異なる市場を扱い、各取引日内に、そのクレジット限度一杯まで取引きを行いたいと考える。ある特定の市場が活気がない場合には、その市場に割り当てられたクレジットを別の分野に流用できればと考えるだろう。同様に、特定の市場が非常に活況の場合には、その市場は、その活況を利用できればと考えるだろう。所定の銀行は、異なる市場で、多くの同じ相手方と取引きすることができることを思い出されたい。それ故、所定の相手方との特定の１つの商品による取引きを行うためにクレジットを提携することは望ましいことではない。何故なら、そのように固定すると、それ自身のグローバルな取引限度内のその銀行の取引容量が低減する場合があるからである。また、クレジット限度が割り当てられる方法は、多くの銀行がクレジットを処理し、割り当てる方法に影響を与えない。クレジットに関する限り、ある銀行はあるシステムを別の方法で処理しなければならなくなり、そうなると、銀行はそのシステムを使用したがらなくなる。
【００１２】
（発明の概要）
本発明の目的は、先行技術のシステムよりももっと柔軟にクレジットを割り当てられるシステムを提供することである。
【００１３】
本発明の一実施形態は、電子メッセージを送信するための通信ネットワークを含む金融商品または他の商品を取引きするための匿名取引システムを提供する。複数の取引業者端末が上記ネットワークに接続していて、各端末は、入札および／またはオファー価格を含み、他の取引業者端末から取引業者情報を通信することができる電子価格取引メッセージを発生することができる。１つまたはそれ以上の照合エンジンが、入札およびオファーを照合するために、ネットワークに接続していて、ある取引きが成立すると、取引きを実行する。ネットワークに接続している市場配給手段は、価格メッセージを取引業者端末に配給し、取引価格メッセージおよび照合エンジンに応答する。クレジット限度記憶手段は、立会場または立会場のグループと可能な相手方の立会場または立会場のグループとの間の取引きに対して使用することができるクレジット限度を記憶する。クレジット限度記憶手段は、少なくとも１つの立会場のグループに対するクレジット限度を記憶する少なくとも１つのクレジット・エージェント・ノードを含む。
【００１４】
クレジット・エージェント・ノードを使用することにより、ある機関のクレジットをグローバルに処理することができる。すなわち、クレジットを立会場ベースで割り当てる必要がなくなる。そのため、システムのユーザは、立会場から相手方の立会場へ、立会場の多数のグループの中の１つから個々のまたは多数の立会場のグループへ、団体から団体、またはこれらのローカルおよびグローバルなクレジット機関の任意の組合わせへ柔軟にクレジットを割り当てることができる。また、そのため、システムのユーザは、先行技術のシステムより高い柔軟性を持つことができ、取引日の間、使用できるクレジット限度を全部容易に利用することができる。
【００１５】
好適には、取引業者端末は、取引エージェント・ノードを通してネットワークに接続していることが好ましい。構成を簡単にするために、クレジット・エージェント・ノードとして取引エージェント・ノードを使用することもできる。接続している取引業者端末に対する自分自身のクレジット情報を持っていない各取引エージェント・ノードは、提案された取引メッセージを受信した場合に、クレジット・エージェント・ノードに、クレジット問合わせメッセージを送信するための手段を含む。クレジット・エージェントは、取引エージェント・ノードに対するクレジット問合わせメッセージを受信し、使用できるクレジットをチェックし、またシステムに、取引きを進めることができるかどうかを表示するための手段を含む。好適には、上記表示は、全取引きに対してクレジットが不足している場合には、提案された金額の一部に対して取引きを進めることができることを表示することができることが好ましい。好適には、クレジット・エージェント・ノードは、取引エージェント・ノードに直接接続しないで、クレジット問合わせメッセージを取引成立エンジンの中の１つを通して送信することが好ましい。好適には、クレジット・エージェントからの取引インジケータ・メッセージは、それを相手方の取引エージェントに転送する取引成立エージェントの中の１つに送信することが好ましい。
【００１６】
１つの実施形態の場合には、所定の当事者のクレジット限度記憶手段が、その複数の外部クレジット限度記憶手段に対してインターフェースとしての働きをする。そのため、システムのクレジットを種々の媒体を通して処理することができ、または、それに対する相手方が、種々の商品を処理することができるその商品に対するその当事者の全クレジット・スキームの一部として処理することができる。
【００１７】
システムは、多くのクレジット・エージェント・ノードを含むことができる。
【００１８】
第２の観点から見た場合、本発明では、クレジット・エージェントが、照合エンジンに関連するクレジット仲介業者により置き換えられていて、複数の団体に対するクレジット限度を記憶する。各記憶されているクレジット限度は、その機関の立会場、またはその機関の立会場のグループと相手方の機関、または相手方の機関の選択した立会場または立会場のグループとの間の取引きに使用することができるクレジットを表す。
【００１９】
照合エンジンに関連するクレジット仲介業者を使用すると有利である。何故なら、クレジットをチェックするために必要な時間が最も短くてすむからである。ある取引きの場合、販売者（ｍａｋｅｒ）と購入者（ｔａｋｅｒ）の両方が、グローバルなクレジット制度を使用している場合には、両者に対するクレジットは、クレジット仲介業者によりチェックすることができる。そのため、取引処理時間が大幅に短縮する。
【００２０】
１つの好適な実施形態の場合には、照合エンジンは、ＷＯ９３／１５４６７号に記載されている仲介業者であり、クレジット・エージェントは、好適には、ローカル・エリア・ネットワークにより接続していることが好ましい、各仲介業者に関連している。他の好適な実施形態の場合には、取引システムは、照合、取引きの実行、市場配給の機能を行う仲介ノードの多数のクリークを備え、クレジット仲介業者は、仲介ノードに内蔵されていて、そのため、各ノードはクレジット仲介機能を持つ。
【００２１】
複数のクレジット仲介業者を使用する場合には、ある機関に対するクレジットは、クレジット仲介業者の間に割り当てることができる。好適には、システムは、クレジット・チェックを行うために、呼び出される可能性が最も高い仲介業者にそのクレジットを確実に割り当てることができることが好ましい。これは、最も能動的な仲介業者に関連するクレジット仲介業者である。ある取引きに対してクレジットを使用することができるが、その取引きを処理している照合エンジンに関連するクレジット仲介業者に全部を割り当てることができない場合には、好適には、そのクレジット割当ての一部の留保を要求している他のクレジット仲介業者の中の１人に送ることが好ましい。
【００２２】
好適には、クレジット割当ては、クレジット仲介業者の間で移転することができることが好ましい。
【００２３】
本発明の１つの好適な実施形態の場合には、金融商品を含む商品の匿名商取引のための自動取引システムは、立会場を含む１つまたはそれ以上の取引業者端末に接続している複数の相互に接続している仲介ノードを持つコンピュータ通信ネットワークを備える。各仲介ノードは、取引業者端末から価格相場（付け値）メッセージとしてシステムに入力された入札およびオファーを照合するための照合エンジンと、価格が折り合った場合に取引きを実行するための手段と、価格相場（付け値）メッセージおよび照合エンジンに応答して取引業者端末へ価格メッセージを分配するための市場配給手段とを備える。１つまたはそれ以上のクレジット・エージェント・ノードが設置されていて、各クレジット・エージェント・ノードは、可能な相手方の立会場または立会場のグループとの取引きに対して、多数の取引エージェント・ノードに接続している立会場に対するクレジット限度を記憶する。その接続している立会場のクレジット限度が、クレジット・エージェント・ノードのところに記憶されていないこれらの取引エージェントは、それ自身のクレジット限度を記憶するためのクレジット限度記憶手段を含む。
【００２４】
別な方法としては、クレジット・エージェント・ノードを、複数の各機関により、複数の可能な相手方の機関に割り当てられたクレジット限度を記憶するための少なくとも１つの照合エンジンに関連する１人のクレジット仲介業者で置き換えることができる。
【００２５】
添付の図面を参照しながら本発明の実施形態について説明するが、これは単に例示としてのものに過ぎない。
【００２６】
（好適な実施形態の説明）
以下に説明する、図１−図８の取引アーキテクチャを参照しながら、本発明の第１の機能について説明する。しかし、本発明のこの機能は、上記アーキテクチャに限定されるのではなく、任意の匿名取引システムで実行することができることを理解されたい。例えば、本発明の第１の機能は、当業者にとって周知の上記のロイター社、およびＥＢＳディーリング・リソース社の先行技術のシステムのどちらでも実行することができる。同様に、図９−図１１を参照しながら、本発明の第２の機能について説明するが、この第２の機能は、これらの図面の特定のアーキテクチャ構成に限定されない。
【００２７】
これから説明する電子仲介システムは、少なくとも下記の商品、すなわち、ＦＸ（外国為替）スポット、ＦＲＡおよび先物、およびＦＸ先物、ＣＦＤ、短期政府および／または中央銀行紙幣、商業手形、ＣＤ、銀行間預金、コマーシャル・ペーパー、レポ、金利先物取引、スワップ、オプション、およびこれらの種々の金融商品に基づく種々の注文の変種を取引きするためのプラットフォームを提供する。これらは、すべて金融商品と呼ばれる。上記電子仲介システムは、また、商品のような非金融商品の取引きのためにも使用することができる。
【００２８】
取引業者端末のところの取引業者は、端末間で電子メッセージを交換することができる通信ネットワークに接続している。これらのメッセージは、後でシステム全体の複数の各仲介業者ノードに送られる相場（付け値）およびヒットの提出を含む。相場（付け値）は、「取引する（ｍａｋｅ ｍａｒｋｅｔ）」ために取引業者が提出する入札およびオファーであり、市場展望の一部として他の取引業者に配布される。それ故、相場（付け値）は、他の取引業者が目で見ることができるで注文である。ヒットは、１つまたはそれ以上の相場（付け値）から入手した自分の市場展望上に表示された値段に基づいて取引きを行いたいと考えている取引業者が出した買い注文または売り注文である。ヒットは他の取引業者には見えない注文である。
【００２９】
図１のコンピュータ取引システムは、複数の取引エージェント１０を含み、各エージェントは、複数の仲介業者ノード１２の中の少なくとも１つに接続している。各取引エージェントは、それにより、取引業者端末が、所定の取引業者端末が、１つまたはそれ以上の取引エージェントに取り付けられている取引システムにアクセスする手段である。
【００３０】
取引業者端末（図示せず）としては、ワークステーション、または（通常は、特殊化されたキーパッドによる）入札および／またはオファー価格、相場（付け値）および注文を含む電子注文メッセージを発生し、提出し、また、取引き対象の金融商品に対して使用することができる価格および金額を含む市場展望データを通信するように構成されている他のコンピュータ端末等がある。上記通信は、通常、表示により行われるが、情報の印刷、音声合成、またはその他の方法によって行うこともできる。取引業者端末は、手動により、または自動的に注文を入力することができる。後者の場合、取引業者は、市場が所定の状態になった場合に、注文を出すように端末をプログラムすることができる。別な方法としては、取引業者端末を個々のワークステーションにしないで、機関の自動取引機能に内蔵させることもできる。これらすべての修正は、注文入力デバイスの数例にしか過ぎない。
【００３１】
取引業者は、通常、取引業者を立会場の一部として配置する銀行のような金融機関の一部としてグループ分けされる。立会場は、立会場に対するクレジット・ラインを他の立会場に対して割り当てる立会場管理者の共通の制御下の取引業者のグループである。ある取引業者、または取引業者のグループに対する市場展望は、市場を反映する取引業者が見ることができる市場情報（価格、数量等）である。市場展望は、好適には、ＷＯ９３／１５４６７号が開示しているように、クレジットの互換性に対して予め審査したものであることが好ましい。上記特許の内容は、本願に引用して援用する。それ故、取引業者だけが、それにより自分達が取引きすることができる表示相場（付け値）を見ることができる。立会場へのクレジットの供与の他に、クレジット全体を銀行に供与することもできるし（多くの銀行は、立会場とは無関係のいくつかの場所を持っている）、または個々の取引業者または取引業者のグループに供与することもできる。クレジット全体を、銀行から、立会場から、または個々の取引業者から供与することもできる。このプロセスについては、後で詳細に説明する。
【００３２】
上記システムは、仲介業者が作成した市場展望が、価格のソースを識別しないで、価格および金額情報を含む匿名取引システムである。使用できる入札およびオファー、およびその価格で使用することができる金額に対して表示される価格は、１つまたはそれ以上の相場（付け値）の集合体である。予め審査したクレジット基準を満足する当事者の相場（付け値）だけが、表示の価格の集合体内に含まれる。それ故、仲介業者が作成した市場展望は、クレジット割当てにより、立会場毎に異なる。
【００３３】
取引エージェント・ノードは、特定の立会場または取引業者のグループにサービスを提供する。これらのサービスは、各取引ワークステーションに対するネットワークへのアクセスの供給、取引きの完了、取引きチケットの作成、取引業者のための過去の取引情報の維持を含む。各取引エージェント・ノードは、取引システムにアクセスするために、少なくとも１つの仲介業者ノードに接続していなければならない。それ故、取引業者端末のグループは、システムにアクセスするために、取引エージェント１０に接続している。
【００３４】
各仲介業者ノード１２は、基本的注文照合サービス、および価格配布サービスを行う。仲介業者ノードは、非常に特殊な、しかし、簡単なルールに従って、もっと高速の通信転送を行うことができるクリーク・ツリーと呼ばれる構造体内に配置されている。クリーク・ツリーは、個々のノードがクリークにグループ分けされていて、その後で、クリークがツリー構造体の形に配置されているネットワーク構造体である。各仲介業者は、その近隣仲介業者と呼ばれる多数の仲介業者に論理的にリンクすることができる。仲介業者間の通信は、同じレベル上に位置していて、ネットワーク内において「上下」関係はない。
【００３５】
図１の実施形態の場合には、クリークの数は三つである。すなわち、仲介業者１２ａ、１２ｂおよび１２ｃにより形成されているクリーク、仲介業者１２ｂ、１２ｄ、１２ｅおよび１２ｆにより形成されているクリーク、仲介業者１２ｅおよび１２ｆにより形成されているクリークである。仲介業者１２ｂおよび１２ｅは、両方とも、２つのクリーク内に位置していることが分かるだろう。分かりやすくするために、簡単な例だけを示したことを理解することができるだろう。実際には、ネットワークは、多数のクリークを含んでいて、遥かに複雑なものになる場合がある。
【００３６】
取引エージェントは、少なくとも１つの仲介業者ノードに接続しなければならないが、取引エージェントは、クリーク・ツリーのメンバーではなく、構造体の外に位置している。複数の仲介業者ノードに接続している取引エージェントは、複数の組の市場価格を受信する。異なる仲介業者ノードからの価格情報が、実質的に同じである場合はあっても、上記情報は、異なる時間的間隔で受信することができる。取引エージェントは、所定の取引注文を１つの仲介業者ノードだけに送信する。
【００３７】
仲介業者ノードという用語は、仲介機能を供給しているコンピュータ・ネットワーク内で、物理的または論理的に配置されているコンピュータを表すために使用される。基本的仲介機能は、相場（付け値）の記憶、市場展望の形による取引業者への相場（付け値）の供給、および相場（付け値）と注文との照合である。上記実施形態内の仲介業者ノードも、他の機能を実行するが、これらの機能は、仲介業者ノードと定義される本質的な機能ではない。
【００３８】
それ故、各仲介業者ノードは、提出された入札およびオファーを照合して成立した場合には、取引きを実行するための、ネットワークに接続している照合エンジンを供給する。仲介業者ノードは、また、取引価格メッセージおよび照合エンジンに応じて、取引業者端末に価格メッセージを配布する市場配給業者の機能を実行する。本発明においては、好適には、照合機能および市場配給機能は、仲介業者ノード内で融合されることが好ましいが、本発明は、上記機能が独立していて、地理的および／または論理的に離れている位置で実行されるシステムにも、等しく適用することができる。このようなシステムの一例が、上記のＷＯ９３／１５４６７号が開示しているシステムである。
【００３９】
各仲介業者ノードは同じものであり、同じ機能を行う。その内部のネットワークおよびその位置の配置は、仲介業者ノードに対して透明である。仲介業者ノードは、その近隣について知っているだけでよい。各仲介業者ノードは、市場内のすべての注文を知っていて、提出されるとすぐに、注文を照合することができる。各仲介業者ノードは、市場内の注文の全リストを維持しているので、取引エージェントの必要に応じて市場展望をカスタム化することもできるし、受信するとすぐに市場情報により早く反応することもできる。
【００４０】
分散型仲介業者ノード配置の目的を理解してもらうために、図２を参照しながら、価格の配布および取引きの実行について説明する。
【００４１】
取引プロセスは、取引業者端末に注文を提出する１人またはそれ以上の取引業者によりスタートする。注文は、価格および数量のような、特定の制限を含む買いまたは売りついての指示を含む、ある取引業者からの取引要求である。相場（付け値）は、システム内で引き続き使用することができる永続性の注文であり、相場（付け値）情報の一部として配布される。相場（付け値）（Ｑｕｏｔｅ：クォート：付け値）は、「取引する（ｍａｋｅ ｔｈｅ ｍａｒｋｅｔ）」ために使用され、入札またはオファーとして取引業者に通知される。ヒットは、「目で見ることができない」および「ｆｉｌｌ（満たす） ｏｒ（または） ｋｉｌｌ（殺す）」特性（目で見ることができない）を持つ注文である。ヒットは、相場（付け値）の一部として配布されない。ヒットはシステム内に残留しない。入力したときに処理されない場合には、そのヒットは除去される。
【００４２】
注文記録は、市場で利用することができるすべての注文のリストである。相場（付け値）は、使用できる唯一の注文ではないので、注文記録は、相場（付け値）のリストからなる。相場（付け値）は、正しい取引順序で待ち行列の形に配置されている。待ち行列のソート順序は、異なる取引製品に対して変化することができる。デフォールト・ソート順序は、価格および時間の順番になっている。システムにおいては、各仲介業者ノードは、すべての利用できる相場（付け値）の完全なリストを維持する。外国為替のようなシステムにおいては、効果を上げるために、２つの記録があり、一方の記録は、買い注文を示し、他方の記録は売り注文を示す。
【００４３】
システム内のメッセージの流れについては、各メッセージが、ネットワーク全体を通して適当なパラメータを運ぶ名前付きの複数のメッセージにより説明する。相場（付け値）（永続的注文）の提出プロセスは、取引エージェントが、取引業者のワークステーションから、取引業者が入札またはオファーを発行したという情報を受信した時にスタートする。その後で、取引エージェントは、相場（付け値）提出プロセスをスタートする。取引エージェントが、取引業者のワークステーションから相場（付け値）情報を受信すると、取引エージェントは、相場（付け値）に対するコンテキストを生成する。その後で、取引エージェントは、自分が接続している仲介業者ノードに、相場（付け値）提出メッセージを送る。仲介業者ノードは相場（付け値）を確認し、有効であればその相場（付け値）を受け入れる。相場（付け値）を受信するこの第１の仲介業者ノードは、この相場（付け値）に対して「オーナー」仲介業者ノードになる。図２の例の場合には、「オーナー」仲介業者ノードは、仲介業者ノード５である。このノードが、取引きに相場（付け値）を追加することができる唯一の仲介業者ノードである。仲介業者ノードは、コンテキストまたは「相場（付け値）対象物」を生成し、正しい取引可能な製品に対するその待ち行列に分類する。
【００４４】
相場（付け値）がその待ち行列内に挿入された後で、オーナー仲介業者ノードは、他の仲介業者ノードに対して使用可能な相場（付け値）メッセージを送信することにより、ネットワーク全体に相場（付け値）を配布する。この例の場合には、仲介業者ノード５は、使用可能な相場（付け値）メッセージを仲介業者ノード２および６に送る。各仲介業者ノードは、上記メッセージを受信すると、コンテキスト（相場（付け値）対象物）を生成し、それをその待ち行列（注文記録）に分類する。各仲介業者ノードは、コンテキスト内に、どの仲介業者ノードが、それに上記メッセージを送ったのかを記録する。それを待ち行列内に挿入した後で、仲介業者ノードは、同じクリーク内に、そのメッセージを送った仲介業者と同じクリーク内に位置する仲介業者を除いて、すべての隣接仲介業者に、放送転送規則により、使用可能な相場（付け値）メッセージを送信する。それ故、仲介業者ノード２は、仲介業者ノード１、３および４に上記メッセージを送信する。その後で、仲介業者ノード４は、上記メッセージを仲介業者ノード７に送信する。この時点で、すべての仲介業者ノードは、相場（付け値）について知ることになり、それに従って、注文記録を更新する。
【００４５】
放送転送規則は、ネットワーク・トラフィックが、効率的な方法で確実に処理されるように、また、メッセージの流れのすべての重複を低減するために適用される。
【００４６】
放送規則とは下記のようなものである。
【００４７】
１．仲介業者ノード発信情報は、それをその隣接するすべての仲介業者ノードに送信される。
【００４８】
２．上記情報を受信する仲介業者ノードは、上記情報を送信した仲介業者ノードと同じクリーク内に位置する仲介業者ノードを除いて、それをその隣接するすべての仲介業者ノードに送信する。
【００４９】
３．あるメッセージが、相場（付け値）のような永続性情報を含んでいる場合には、その情報は、そこからその情報を受信した仲介業者ノードの識別子と一緒に記憶される。
【００５０】
これらの規則は、情報については言及しているが、それを含むメッセージについては言及していないことに留意されたい。例えば、相場（付け値）についての情報は、ある仲介業者ノードに対しては、提案取引メッセージにより送信され、他の仲介業者ノードに対しては、市場更新メッセージにより送信される。しかし、同じ情報は、同じ仲介業者ノードに送られ、そのため、上記規則が適用される。
【００５１】
価格配布は、取引業者端末における取引業者への市場情報供給プロセスである。この情報は、仲介業者ノードにより生成され、取引業者へ配布するために、取引エージェントに送られる。図３はこのプロセスを示す。
【００５２】
各仲介業者ノードは、相場（付け値）（注文記録）の待ち行列をチェックし、それに接続している各取引エージェントに対するその市場展望を計算する。この展望は、そのエージェントが代表する立会場用に特に構成される。展望は、クレジットおよび他の要因により異なる場合がある。市場展望を判断するための正確なプロセスは、取引商品による異なる。市場展望情報は、市場展望メッセージにより、取引エージェントに送られる。それ故、各仲介業者は、各取引業者および可能な相手方に関するクレジット情報を保持することになる。
【００５３】
ある相場（付け値）にヒットすることが、２人の取引業者の間で取引きを生成する基本的なプロセスである。ある取引業者からのヒットは、他の取引業者からの相場（付け値）と照合される。図４はこのプロセスを示す。自分の市場展望ディスプレイ上に表示されているある価格にヒットしている取引業者端末の取引エージェントは、その仲介業者ノードにヒット提出メッセージを送る。このメッセージの目標は、ある価格であって、特定の相場（付け値）ではない。この仲介業者ノードは、その相場（付け値）を走査し、そのヒットと照合することができる待ち行列内で第１の相場（付け値）を発見する。この照合規則は、取引商品により変化する場合がある。
【００５４】
そのヒットがある相場（付け値）と一致した場合には、仲介業者ノードは、その相場（付け値）に対するそのコンテキストを修正し、一致した金額を、「使用可能な取引き」から「予約係属取引き」へと移動する。そうすることにより、その相場（付け値）の同じ金額が、他のヒットと照合されるのが防止される。その後で、仲介業者ノードは、その仲介業者ノードが、そこからその相場（付け値）を受信した仲介業者ノードへ、提出取引メッセージを送信する。このメッセージの目標は、特定の相場（付け値）である。この例の場合には、ヒットは、仲介業者７に接続している取引エージェントに接続している取引業者からのものである。仲介業者７は、上記メッセージを仲介業者４に送信する。
【００５５】
各仲介業者が提案取引メッセージを受信すると、その仲介業者は、その待ち行列内の相場（付け値）をチェックする。提案された取引の金額が、待ち行列内で依然として使用できる場合には、仲介業者ノードは、仲介業者ノードの照合と類似のプロセスを実行する。提案の取引の金額は、「使用可能な取引き」から「予約係属取引き」へと移される。その後で、提案取引メッセージは、そこからその相場（付け値）を受信した仲介業者ノードに送られる。この例の場合には、仲介業者ノード４は、上記メッセージを仲介業者ノード２に送る。その後で、仲介業者ノード２は、それを仲介業者ノード５に送る。
【００５６】
提案取引メッセージの転送は、目標とする転送規則により行われる。目標とするる転送は、情報を特定の仲介業者ノードに送るために使用される。特定の仲介業者ノードの知識はシステムに組み込まれていないので、目標は特定の仲介業者ノードではなく、そこからその情報が発信された仲介業者ノードである。例えば、あるメッセージは、「仲介業者ノード７１４」には送信されないで、「仲介業者ノードで発生された相場（付け値）（クォート）４２」に送られる。目標とする規則は、下記の規則である。
【００５７】
１．特定の情報に関するメッセージを発信する仲介業者ノードは、そのメッセージを、情報ノードが、そこから元の情報を受信した仲介業者ノードに送信する。
【００５８】
２．発信しなかった特定の情報に関するメッセージを受信する仲介業者ノードは、上記メッセージを、そのノードが、そこから元の情報を受信した仲介業者ノードに送信する。
【００５９】
それ故、上記メッセージは、元の情報の経路を通ってそのソースに戻る。この例の場合には、上記経路は、仲介業者ノード７から、仲介業者ノード４および２を経由して、仲介業者ノード５に達している。
【００６０】
その相場（付け値）を最初に生成した仲介業者ノードが、提案取引メッセージを受信した場合には、上記ノードは、他の仲介業者ノードと同じチェックおよび金額留保を行う。この仲介業者ノードはその相場（付け値）を所有しているので、このノードは、その相場（付け値）を処理するために追加することができる。提案取引メッセージは、そのヒットを処理するために追加できることを表す。その後で、仲介業者ノードは、ヒット金額メッセージをその相場（付け値）を提出した取引エージェントに送ることにより、取引プロセスをスタートする。取引実行プロセスについては後で説明する。
【００６１】
取引照合プロセスが行われた場合には、各仲介業者ノードのところに維持されている相場（付け値）のリストを最新の状態に維持しなければならない。このプロセスは、図５に示すように、ある相場（付け値）を変更した場合、他の仲介業者ノードにそれを通知する各仲介業者ノードにより行われる。
【００６２】
各仲介業者ノードが、その待ち行列内のある相場（付け値）を変更した場合には、各仲介業者ノードは、それが、そこから上記変更を受信したクリーク内の仲介業者ノードを除いて、近隣のすべての仲介業者ノードに通知する。上記例の場合には、仲介業者ノード４は、提案取引メッセージにより、仲介業者ノード７から、ある待ち行列内のある変更を受信した。仲介業者ノード４は、提案取引メッセージを送って、仲介業者ノード２に通知する。仲介業者ノード４は、仲介業者ノード１および３に通知しなければならない。この通知は、これら仲介業者ノードに、市場更新メッセージを送信することにより行われる。
【００６３】
その相場（付け値）に関する情報は、通常の転送規則により、ネットワーク内の各仲介業者ノードに配布される。市場更新メッセージを受信している任意の仲介業者ノードは、それがそこから受信するクリーク内に位置していない、すべての近隣仲介業者ノードにそれを送る。提案取引メッセージを送信しているある仲介業者ノードは、同じ仲介業者ノードに、市場更新メッセージを送信してはいけないことに留意されたい。もし送信した場合には、情報がダブって受信され、取引金額が２回留保されることになる。
【００６４】
取引照合プロセスが終了すると、すでに説明したように、取引実行プロセスがスタートする。このプロセスにより取引きが完了し、ある取引きにその取引業者が付託される。図６は、このプロセスを示す。照合が行われ、取引きがスタートすると、取引業者は情報を入手することができるようになる。この情報は、取引業者に、取引きが中断中であることを知らさせために使用される。任意の所定の取引アプリケーションにより、取引業者に通知すべきか否かを判断することができる。いずれにせよ、情報を入手することができる。
【００６５】
最初の照合が行われるや否や、購入者の取引エージェント・ノードに通知が行われ、提案取引メッセージが送信される。この時点で、このエージェントは、取引業者のワークステーションに通知することができる。この取引中断情報は、照合プロセス進行中に変化することができる。メーカー（ｍａｋｅｒ）の取引エージェントが、クレジットをチェックし、取引状態メーカー・メッセージを送信した場合には、メーカーのワークステーションに通知が送られる。
【００６６】
メーカーの取引エージェントが、その仲介業者ノードからヒット金額メッセージを受信した場合には、取引実行プロセスがスタートする。このメッセージは、エージェントに、その相場（付け値）の中の１つに対して照合が行われたことを通知する。このメッセージは、相場（付け値）およびヒットの金額、相手方およびヒットの識別を識別する。エージェントはその相場（付け値）が、依然として使用することができることを確認するために、取引業者のワークステーションと一緒にチェックを行う。エージェントは、ワークステーションに対して、ヒット金額メッセージを送信する。ワークステーションは、ワークステーションが依然として動作していること、および取引業者が、もはや相場（付け値）を中断できないことを示すために、ヒット金額メッセージで応答する。この時点においては、取引業者は、もはやその取引を中断することはできない。
【００６７】
次に、取引エージェントは、相手方の使用することができるクレジットをチェックする。クレジットをチェックすることにより、その取引きをできるようにすることもできるし、その取引きの金額を少なくすることもできるし、その取引きをできないようにすることもできる。使用できるクレジットのこの減額は、将来の取引きに影響を与える恐れがある。メーカーの取引エージェントは、その仲介業者ノードに取引状態メーカー・メッセージを送ることにより、受け手（ｔａｋｅｒ）の取引エージェントに、その取引きについて知らせることができる。情報メッセージは、そのヒットを識別するためのものである。ネットワーク仲介業者ノードは、上記メッセージをヒットのオーナー仲介業者ノードに転送し、その仲介業者ノードは、それを購入者のエージェントに送る。このメッセージが送信されると、メーカーのエージェントは、ある取引きが実行されたかもしれないが、その取引きに疑惑があり、応答がまだ行われていないことを知る。受け手の取引エージェントは、取引実行プロセスを終了する。上記プロセスのこの部分は、エージェントがメーカーから取引状態メーカー・メッセージを受信したときに行われる。メッセージが取引きが有効であることを示している場合には、プロセスは続行する。
【００６８】
次に、購入者の取引エージェントは、メーカーと類似の方法により、相手方と一緒に、クレジットが使用できるかどうかをチェックする。クレジットのチェックを行うことにより、クレジットをチェックすることによりその取引きをできるようにすることもできるし、その取引きの金額を少なくすることもできるし、その取引きをできないようにすることもできる。その後で、エージェントは、その取引きに必要な金額だけ使用できるクレジットを減額する。使用できるクレジットのこの減額により、将来の取引きが影響を受ける場合がある。この段階においては、取引きが拒否される可能性は少ないことを覚えておいてほしい。何故なら、取引業者に表示された価格は、クレジットに対して予め審査したものであるからである。購入者の取引エージェントは、そのディスクにその取引きをログする。情報が永続的な記憶装置に付託されると、取引きが行われる。取引状態についての任意にチェックすれば、その取引きが拘束取引きであることがわかる。エージェントは、取引業者に通知し、取引きチケットを印刷し、任意の他の後取引処理を実行する。この時点で、取引きが行われるが、メーカーはまだそれを知らない。取引きが行われるや否や、購入者の取引エージェントは、その仲介業者ノードに取引状態受け手メッセージを送信することにより、メーカーに通知する。このメッセージは、相場（付け値）を対象としたもので、メーカーのエージェントに転送される。
【００６９】
取引状態購入者メッセージは、取引きに関する最終情報、すなわち、相場（付け値）に対する最終変更を含んでいる。この情報は、ネットワーク・仲介業者ノードおよび取引エージェントにより使用される。取引状態購入者メッセージは、仲介業者ノードを通して転送されるので、各転送仲介業者ノードは、その相場（付け値）のコンテキストを更新するために上記情報を使用する。取引金額は、「留保」から「終了」に送られる。相場（付け値）がまだ生きている場合には、実行されなかった部分は、「留保」から「使用できる」に移される。その後で、それは、ネットワーク転送規則により、他のすべてのの仲介業者ノードに、市場更新メッセージを送信することにより、他の仲介業者ノードに、変更および取引きを通知する。
【００７０】
取引状態受け手メッセージが、相場（付け値）のオーナー仲介業者ノードに到着すると、上記ノードは、それを取引エージェントに送信する。上記エージェントは、ディスクにその取引きを記録する。この時点で、取引きはハッキリとしてきている。エージェントは、取引業者に通知し、取引チケットを印刷し、必要な任意の他の処理を実行する。ある種の取引商品は、取引きのために交換する追加情報を必要とする。その一例は、ＥＢＳスポットＦ／Ｘに対する決済指定である。このタイプの情報は、取引情報メッセージにより送信される。取引きの処理が行われた後で、エージェントは、この情報を生成することができる。取引情報メッセージは、仲介業者ノードに送信される。その後で、ネットワーク仲介業者ノードは、上記メッセージを他のエージェントに転送し、そこで、上記情報は、商品の必要に応じて処理される。これで、取引きが完了する。
【００７１】
取引きが完了すると、両当事者は、初めて、その各相手方の識別を知る。上記識別は、その端末のスクリーン上に表示され、例えば、その取引セッション内で実行された取引きのリスト内に入れられ、取引チケット上に印刷され、ディスクにログされる。これらの各プロセスは、各当事者、実行した取引き、その取引きへの相手方を識別するための手段を含む。
【００７２】
上記システムでクレジットが処理される方法について、より詳細に検討する。
【００７３】
すでに説明したように、システムは、価格およびクレジットを使用する一致した取引きを審査するので、その結果、ある取引業者に表示されるすべての価格は、取引きに使用できるものでなければならない。上記の説明を読めば、このことは、各仲介業者に、クレジット決定を行うことができるだけの、十分なクレジット情報を持たなければならないことを要求することを理解することができるだろう。それは、仲介業者ノードが、通信している取引エージェントに配布する市場展望の作成を担当するからである。実際のクレジット・データは、非常に複雑なものであり、商品および指示により変化する場合がある。例えば、Ｆ／Ｘ取引システムのクレジットの概念は、簡単なものである。何故なら、スポット市場であるからである。しかし、ＦＲＡのような商品の場合には、もっと複雑である。何故なら取引きが、種々の時間にわたって行われるからである。さらに、ある種の銀行は、その取引活動の全範囲にわたって、相手方にクレジットを割り当てることを好むが、一方、ある種の銀行は、所定の金融商品に対してだけ、相手方にクレジットを割り当てることを好む。
【００７４】
上記処理を簡単なものにするために、システムは、クレジット・データの簡単なサブセットを配布し、使用する。最終クレジット権限は、全クレジット情報を持つノードが握っている。このシステムの場合には、このノードは、銀行取引エージェント・ノードであるが、これは強制的なものではなく、本発明は、クレジットが他の場所に記憶されているクレジットにも適用することができる。
【００７５】
クレジットは、立会場、相手方の立会場および取引き可能な素子の、各組合わせに対して、１つの数値を使用している。この数値の目的は、２つの立会場が、特定の素子内の取引きに対して、クレジットをもっているかどうかを判断することである。上記数値の意味は、取引き中の商品に特有なものである。例えば、スポットＦ／Ｘは、はい／いいえフラッグ（１または０）として、上記数値を使用しているが、一方、金利先渡し契約（ＦＲＡ）の場合には、ＦＲＡＢＢＤＡ／ＩＳＤＡ判断用のビットマスクとして、上記数値が使用されている。他の商品は、他の意味を持つ。クレジットは、双務的なものである。クレジットは、任意の取引活動が行われる２つの立会場の間に存在していなければならない。クレジット・チェックは、その商品により決定された所定の取引素子、または取引素子のパターンに対して行われる。システムが双務的なものであるので、仲介業者は、２つのクレジットの数値、すなわち、第１の立会場により、第２の立会場に与えられたクレジットの数値、および第２の立会場により第１の立会場に与えられたクレジットの数値を比較する。上記２つの数値が、互換性のあるものである場合には、取引動作を行うことができる。互換性という用語の意味は、その商品により決まる。スポットＦ／Ｘの場合には、その取引きに対して提案された金額は、２つのクレジットの数値の低い方より低いか、等しい場合には、取引きを進めることができる。その取引きが、低い方のクレジットの数値より大きい場合であっても、取引きを進めることはできるが、それは、低い方のクレジットの数値に等しい提案取引き金額の部分に対してだけである。
【００７６】
立会場の全クレジット情報は、ある立会場に対してクレジット権限を持つ取引エージェントに対して発信される。このエージェントは、全情報の中のそれ自身の立会場に関連する一部しか持っていない。しかし、１つ以上の立会場を一つの取引エージェントに接続することができる。クレジット情報が変更された場合には、取引エージェントは、クレジット更新メッセージをその仲介業者ノードに送信する。仲介業者ノードは、上記エージェントからの情報をその全クレジット・マトリックスと結合し、上記メッセージを上記規則に従う放送メッセージとして、近隣の仲介業者に送る。各仲介業者は、また、そこから所定の立会場に対する情報が送られてきた記録を記憶する。
【００７７】
ＷＯ９３／１５４６７号記載の先行技術のシステムの場合には、銀行ノードは、ある立会場に対するクレジット権限を保持していて、その立会場に対する取引き活動を担当する。上記取引き実行プロセスは、ローカル・クレジットと呼ばれるこのクレジット・モデルに基づいて行われる。
【００７８】
取引き実行中、取引エージェントには、潜在的な取引きが提示される。上記エージェントは、上記取引きの詳細をチェックし、その取引きを完了するには、どのくらいのクレジットが必要なのかを判断する。上記エージェントは、使用できるクレジットをチェックし、クレジットが十分でない場合には、このエージェントは、その取引きの金額を減額するか、その取引きをできないようにする。実際に必要なクレジットの金額（全額または減額した金額）は、使用できるクレジットのプールから留保される。このクレジットは、他の取引きに使用することはできない。この確保により、他の取引きに対して使用することができるクレジットが、取引きしきい値より小さくなった場合には、エージェントは、仲介業者にクレジットがもはや使用できないことを通知するために、クレジット更新メッセージを送信する。正当な方法で留保したクレジットが、留保できなくなくなった場合には、システムは、クレジットが使用できなくなったことを知らせるために、もう１つのクレジット更新メッセージを送信することができる。
【００７９】
取引きが完了すると、メーカーのエージェントは、取引き状態購入者メッセージを受け取る。その後で、購入者のエージェントは、取引きが完了したことを知る。その後で、エージェントは、その取引きにより実際に使用されたクレジットを決定する。このクレジットは、消費されたクレジットとして、クレジット・プールから除去される。もとの留保額からのすべての残りの金額は、元のプールに戻される。
【００８０】
ローカル・クレジットに対する別の方法として、銀行は、ある立会場に対してクレジット権限を保持している取引エージェントが、その立会場に対して取引き活動を行う同じエージェントでない、グローバル・クレジット・モデルを採用することができる。クレジット権限を持つエージェントは、ある立会場に対して取引き活動を行うことができるが、必ず行わなければならないわけではない。この配置により、ある機関のすべての立会場は、クレジットの共通のプールを共有することができ、ネットワーク内に、いくつかの立会場に対して、別々のクレジット・ノードを生成することができる。グローバル・クレジット関係を採用するか、またはローカル・クレジット関係を採用するかどうかの判断は、取引きシステムの外部において、参加銀行により行われる。本質的なことは、システムが、当事者間で、ローカルおよびグローバル・クレジット処理の任意の組合わせを処理することができることである。種々の可能性について以下に説明する。下記の例の場合には、機関Ａは、クレジットを機関Ｂにも適用している。
【００８１】
＜例１．ローカル−グローバル＞
この場合、機関Ａは、ローカル・クレジット制度の下で動作し、機関Ｂは、グローバルなクレジット制度の下で動作する。それ故、各立会場または機関Ａは、機関Ｂ内のすべての立会場との取引きに対して、クレジット限度を設定しなければならない。
【００８２】
機関Ａ 機関Ｂ
サイト１ サイト１
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例１．ローカル−グローバル
ローカル−グローバル関係は、上記の現在の匿名取引システムの普通な関係である。その１つの理由は、これらのシステムの場合には、機関は、個々の立会場と、それにより取引きをしたい各相手方との間に、クレジット限度を割り当てなければならないという制限があるからである。そのため、いくつかの銀行は、先行技術のシステムの柔軟性を持たない要件に一致させるために、このグループ分けの関係に基づいて、スポットＦＸクレジット・ラインを割り当てることになる。他の銀行は、そのクレジットの一部を将来のためにとっておいて、純粋に、匿名システム上での取引きのために、ローカル−グローバル・クレジットによりそれを割り当てる。上記銀行は、その残りの営業活動に対して他のクレジット関係を使用する。
【００８３】
＜例２．グローバル−グローバル＞
このモデルの場合には、機関Ａは、機関Ｂのすべての立会場に対して、そのすべての立会場に対するクレジットを適用する。このことは、機関Ａの任意の所定の立会場が、機関Ｂとすることができる取引き金額が、機関Ａの他の立会場が行った機関Ｂとの取引き金額により影響を受けることを意味する。
【００８４】
機関Ａ 機関Ｂ
サイト１ サイト１
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例２．グローバル−グローバル
グローバル−グローバル・クレジット関係は、最も基本的または基礎的なタイプである。
【００８５】
＜例３．グローバル−ローカル＞
このモデルの場合には、機関Ａの全体が、クレジットの結合ラインを機関Ｂの個々の立会場に適用する。このタイプは、機関Ａが、クレジットの長いラインを適用するのを嫌がる１つの特定の立会場があり、機関Ｂは同じ程度に信頼に値しないと考える場合に適している。別な場合としては、その内部に立会場が位置している国を特定のケースと見なす必要がある場合、または立会場が、機関Ｂ内に適当な法的状態をもつことができない場合がある。
【００８６】
機関Ａ 機関Ｂ
サイト１ サイト１
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例３．グローバル−ローカル
＜例４．ローカル−ローカル＞
ある状況の場合、機関Ａは、個々の立会場が、クレジット・ラインを機関Ｂの個々の立会場に、適用することを許可することができる。このようなことは、例えば、新しく出現中の市場、またはその国内の機関Ａの支店からだけ、その国内の機関Ｂの支店に対する取引きが行われる外国の場合に起こる。通常、機関Ａと機関Ｂのこれら支店との間に、他の相互作用は行われない。
【００８７】
機関Ａ 機関Ｂ
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例４．ローカル−ローカル
相手方とのクレジット限度を設定する場合には、機関は、最初にクレジット関係を定義し、その後で、そのクレジット関係に従って、クレジットを割り当てなければならない。このようなグループ分けは中央で行うことができる。通常のクレジット・グループ分けは、下記の通りである。
【表１】
【００８８】
上記表１内においては、機関Ａは、それ自身のサイトの三つのグループ、および機関Ｂのサイトの三つのグループを形成した。機関Ａのグループは下記の通りである。
グループ１ サイト１
グループ２ サイト２
グループ３ サイト３および４
サイト１ サイト１
機関Ｂのグループは、下記の通りである。
グループ１ サイト１
グループ２ サイト２および３
グループ３ サイト４。
【００８９】
割り当てられたクレジット限度は、グループ関係に基づいている。それ故、グループＡ３は、＄１５ＭのクレジットをグループＢ２に適用し、＄１２ＭのクレジットをグループＢ３に適用する。表１は、下記表のように表示することもできる。
【表２】
【００９０】
それ故、グループＡ３およびＢ３は、１つ以上の立会場からできていて、クレジットの１つのプールを共有する。表示のグループ関係は、ローカル・クレジット・モデルとグローバル・クレジット・モデルのハイブリッドであることを理解することができるだろう。機関Ａおよび機関Ｂとの間の関係の場合、複数のローカル−グローバル・タイプの関係が存在する場合がある。それ故、グループＡ３およびグループＢ２は、主要な取引き諸国内のすべての立会場を表すことができる。これらのグループの間の関係は、本質的には、グローバル−グローバル・タイプである。一方、グループＡ１とＢ１またはＢ４との間の関係は、ローカル−ローカル・タイプであり、グループＡ１またはＡ２とＢ２との間の関係は、ローカル−グローバル・タイプであり、グループＡ３およびＢ１またはＢ３との間の関係は、グローバル−ローカル・タイプである。他の関係も存在する。
【００９１】
上記の説明は、機関Ａと機関Ｂとの間の関係である。２つの機関の間の関係内には種々の関係が存在する場合がある。グループの形成に関連する流れは、下記の要因により異なる。
【００９２】
１．機関サイトのグループ分け、このグループ分けは下記により行うことができる。
ａ．集中型 − 本社が、そのサイトに対するすべてのグループを定義するか、または代理サイトにすべてのグループの定義をまかせる。
ｂ．分散型 − 本社が、いくつかの主要なサイトをおよび他のサイトの、グループ分けを担当するいくつかの主要サイトを定義する。例えば、ヨーロッパのサイトはロンドンから、米国のサイトはニューヨークからグループ分けすることができる。サイトをグループ分けする権限は、地理および／または法的状態に基づくことができる。分散型システムの場合には、いくつかのグループ分けを依然として中央で行うことができる。例えば、所定のローカル・センターは、中央による処理されるある種の法的状態を除いて、所定の地理的領域内のすべてのサイトをグループ分けすることができる。
【００９３】
２．クレジット限度を定義するための権限の付与
この権限の付与は、下記のように行うことができる。
ａ．中央処理タイプ
ｂ．分散タイプ
その機関自身のサイトのグループ分けと同じ方法による付与。
【００９４】
３．相手方をグループ分けしなければならない。この場合も、このグループ分けは、機関自身のサイトのグループ分けと同じ方法で、行うことができる。これた三つの決定は、同じ方法で行う必要はない。
【００９５】
２つの機関の間には、完全なグローバル−グローバル関係が存在することができる。これらすべての意志決定は、中央で行われる。この場合、表１および表２のクレジットのグループ分けは、下記表のようになる。
【表３】
【００９６】
上記説明は、例えば、Ｆ／Ｘスポット取引きのためのクレジットの割当てのような、取引きする所定の金融商品に対する銀行のクレジットの割当てに関連する。所定の機関自身の内部クレジット・システムの性質により、上記クレジット関係は、他の匿名システム、音声仲介業者および会話型取引きシステムを含む、すべての可能な方法により取引きを行っている商品に対するその機関のクレジット限度とインターフェースしなければならない場合がある。他のまたは別な方法としては、その取引き活動の範囲を通して、相手方の機関にクレジットを割り当てるある機関のグローバルなクレジット機構とインターフェースしなければならない場合もある。このようなシステムは、必ず非常に複雑なものである。何故なら、クレジットの観念が、取引きを行っているある商品が、長期間にわたるクレジットを必要とする場合には変化するからである。
【００９７】
図１−図７のシステムでのグローバル・クレジットの処理に戻って説明する。グローバルなタイプのクレジット協定に対する取引き実行プロセスは、上記のローカル・クレジット例より複雑であることを理解することができるだろう。
【００９８】
機関の間の関係は、単一のものでなく、ハイブリッドな関係もありうる。例えば、下記の表４は、２つの機関の間の混合型のグローバル−グローバル関係、およびグローバル−ローカル関係を示す。
【表４】
【００９９】
この関係の場合には、本社は、それ自身のグループ分け、相手方のグループ分け、およびクレジット・ラインを決定する。しかし、機関Ｂの子会社は、その機関の残りとは別にクレジットが与えられる。
【０１００】
下記の表５の場合には、機関Ａは、相手方の立会場に対してローカル−ローカル関係を維持し、依然としてグローバルなベースで、相手方の大部分の立会場にクレジットを割り当てる。それ故、サイト１、すなわち、機関Ａの本社は、それ自身のグループ分け、相手方のグループ分け、およびサイト１からサイト４へのクレジット・ラインを決定するが、外国の場所である場合があるサイト５は、機関Ｂのサイト４に対して、ローカル−ローカルな関係を持つ。機関Ａのサイト５は、機関Ｂのサイト４へのクレジット・ラインを決定する。
【表５】
【０１０１】
ローカル−グローバルな関係は、同じグローバルな相手方へのその各立会場に対して、異なるクレジット・ライン場を持つことができる。厳密にいえば、これは、組合わせではなく、それを下記表６に示す。サイト１、すなわち、本社は、それ自身のグループ分け、相手方のグループ分けを決定するが、各サイトは、クレジット・ラインを管理する（ラインそれ自身は、本社で決定することができる）。
【表６】
【０１０２】
図８は、グローバル・クレジットにおける取引実行の際のクレジット・メッセージの流れを示す。
【０１０３】
クレジット配分プロセスは、クレジット情報がこの場合もすべての仲介業者に配布されるという点でローカル・クレジットの例と同じである。どの仲介業者も情報の発信元を知っており、クレジット認可権限を持った取引エージェントにメッセージを送り返すことができる。
【０１０４】
図８の例では、メーカー取引エージェント１００および購入者取引エージェント１０２は自らの立会場のクレジット認可権限を持たない。したがって、認可権限を持った２人の取引エージェント１２０、１３０によってクレジットは確認されなくてはならない。これらエージェントは、メーカー・クレジット・エージェントおよび購入者クレジット・エージェントと称されることもある。
【０１０５】
メーカー取引エージェント１００が取引を処理する際、まずは上記の説明と同じやりかたで相場（付け値）が依然として利用可能であることを調べ、ディーラーにこれから行う取引について通知する。ただし、クレジット・ポジションそのものを調べることはできないため、取引き状態メーカー・メッセージそのものを送ることはしない。その代わり、取引きクレジット・メーカー・メッセージ１４０が取引エージェントが付いている仲介業者１５０に送られる。仲介業者１５０は取引きクレジット・メーカー・メッセージ１４０を、取引エージェント１００が取引活動を行っている立会場のクレジット情報の発信元であるメーカー・クレジット・エージェント１２０に送る。メーカー・クレジット・エージェント１２０は上記説明の通りにクレジット調査を実施した後に、仲介業者１７０に取引き状態メーカー・メッセージ１６０を送る。
【０１０６】
取引き状態メーカー・メッセージ１６０は仲介業者１７０によって、購入者取引エージェントにではなく、購入者のクレジットの発信元に送られる。この場合、この２つは同一ではなく、取引き状態メーカー・メッセージは購入者クレジット・エージェント１３０に送られる。続いて購入者クレジット・エージェント１３０が上記説明の通りにクレジット調査を行い、購入者クレジット・エージェントが接続される仲介業者１９０に取引きクレジット購入者メッセージ１８０を送る。購入者取引エージェントが立会場のクレジット情報を持っている場合、取引きクレジット購入者メッセージ１８０は不要である。
【０１０７】
取引きクレジット購入者メッセージ１８０は、上記説明の経路指定規則を使用して、仲介業者の手によって最初のヒットの発信元に送られる。
【０１０８】
取引を最初に提案した取引エージェント１１０が取引きクレジット購入者メッセージ１８０を受け取ると、取引は成立し、購入者取引エージェントで記録され、取引実行処理は上記図６の際に説明したのと同じように実施される。
【０１０９】
メーカー・クレジット・エージェント１２０および購入者クレジット・エージェント１３０は、ローカル・クレジットの例で説明したのと同様にクレジット予約を実施する。メーカー・クレジット・エージェントは取引きクレジット・メーカー・メッセージを受け取るとクレジットを予約し、購入者クレジット・エージェントは取引き状態メーカー・メッセージ１６０を受け取るとクレジットを予約する。クレジットの消費は、メーカー・クレジット・エージェント１２０および購入者クレジット・エージェント１３０とが取引き状態購入者メッセージ１８０を購入者取引エージェント１０２から受け取った後に実施される。
【０１１０】
信頼性およびパフォーマンスを向上するためには、２人以上の取引エージェントが立会場のクレジット認可権限を持つことが望ましい。このような場合、これらクレジット・エージェントであれば誰でも取引を確認することができる。相互に情報をやりとりし、互いにクレジットのプールを適正に保つのはこれらエージェントの責任である。このプロセスは証券や機関に特化したものである。各仲介業者は同じ立会場から複数のクレジット更新メッセージを受け取る。仲介業者はどのメッセージを受け入れるかを決定しなければならない。仲介業者は発信元の最も近いメッセージを決定するために「ホップカウント」を調べる。ホップカウントの高いメッセージは処理されず、送られない。
【０１１１】
立会場や機関のクレジット・エージェントは利用可能なクレジットのプールを維持し、クレジットが利用されたり、回復した際にクレジット情報を調整する。これを行う方法は機関、および取り引きされる商品の両方に特化されたものである。
【０１１２】
銀行がクレジットに関してグローバルな取り組みをするのは、取引の柔軟性を増すためである。銀行が、様々な当事者に対してあらかじめ割り当てられたクレジット量を持つ複数の立会場からなる場合、一部の立会場ではクレジット限度まで取引が進む一方、その他はそこまで進んでいないという状況も考えられる。クレジット限度までいった立会場は、所定の当事者との銀行の全体取引限度内で取引を最大化するために、他の立会場の未利用のクレジットを利用できるのが望ましい。この全体取引限度は１つの取引商品に限られるのではなく、銀行の活動の全体を網羅し、匿名電子システム上で取り引きできるものと、そうでないものとが含まれることも考えられる。
【０１１３】
ここで説明するシステムが、ローカル−グローバル型のクレジット関係をどのようにも組み合わせることができるということを理解されたい。これによって、機関は他の取引作業同様に匿名取引システムを利用して取引作業にクレジットを割り当てられるようになる。これによって適当とされる場合には、先行技術に基づくシステムに比べてクレジットの扱いをより柔軟にすることができる。また、これによって機関はそのクレジット限度まで取引を進める機会を増やし、したがって、取引活動による利益を最大化することができる。
【０１１４】
クレジット限度関係は、特に仲介業者ノードからなるネットワークを利用するシステムに関して解説した。本発明のこの態様は、当事者間で双務的クレジット限度を割り当てるどのようなシステムにも同じように適応できることを理解されたい。このようなシステムには上記ＥＰ−Ａ−０，３９９，８５０号、ＥＰ−Ａ−０，４０６，０２６号、ＥＰ−Ａ−０，４１１，７４８号、およびＷＯ９３／１５４６７号が含まれる。
【０１１５】
図９−図１１は、本発明の第２の実施形態を示す。上記実施形態では、クレジットをグローバルに取り扱う場合に、各立会場はクレジット限度を扱うためにクレジット・エージェントを利用する。この方法では、クレジット予約を可能にするために追加メッセージングや別々のコンピュータが必要となるため、パフォーマンス面で不利になる可能性がある。取引を成立させるには、情報のやりとりに少なくとも４台のコンピュータ、取引エージェントおよびクレジット・エージェントがそれぞれ２人必要となり、完了時間を大幅に長引かせることが考えられる。
【０１１６】
この状況は、合致するエンジンを持った１人または複数のクレジット仲介業者を割り当てることで回避することができる。クレジット仲介業者はグローバルなクレジットを扱えるように構成された機関のためにクレジット予約を実施し、上記実施形態とは異なり、取引の両側のクレジット調査を行うことができる。
【０１１７】
図９は、当申請者の既存の旧来システムを変更してクレジット仲介業者を盛り込む方法を示す。既存システムは、ＷＯ９３／１５４６７号でのその全容が解説されており、これを参照することが望ましい。照合および取引の実行は、世界各地にいる３人の調停者２００のうち１人が行う。調停者２００はニューヨークに１人、ロンドンに１人、東京に１人いる。調停者２００は、銀行ノードを介して立会場２２０に配布するための市況概況を作成する市場配給業者２１０に接続される。ある立会場の実際の市況概況は、システム内に相場（付け値）を持つ様々な当事者とのクレジット限度によって異なる。
【０１１８】
クレジット仲介業者２３０は調停者の横に置かれ、１人の調停者２００に対してクレジット仲介業者２３０が１人いる。取引完了時間への影響を最小限にとどめるために、クレジット仲介業者は高速ＬＡＮによって調停者に接続される。
【０１１９】
ＷＯ９３／１５４６７号で解説する現在のシステムでは、取引を完了させるうえで３人の調停者のうち誰が活動状態にあっても構わない。特定の銀行のクレジット情報を持つクレジット仲介業者が、取引を開始する調停者に最も近いことが望ましい。これは最も活動の多い調停者にクレジット情報を移動させる予測アルゴリズムによって実現することができる。それ故、クレジットの詳細は１人のクレジット仲介業者内の特定機関について固定されるのではなく、動き回ることになる。実際には、一日の活動を通じて、各国の市場が開始、終了することによって最も活動の多い調停者の位置は変化していく。
【０１２０】
各クレジット仲介業者は、ＷＯ９３／１５４６７号のシステム内の立会場の銀行ノードが提供するのと同じクレジット情報を、ローカルの調停者に提供する。クレジット仲介業者はグローバル・クレジットに参加するすべての立会場のためにクレジット情報を提供する。クレジット割り当てが完全に利用されたり、クレジット管理者によって変更される都度、調停者には新しいクレジット情報が提供される。
【０１２１】
図９は、取引完了、およびクレジット予約プロセスにおける各種メッセージの流れを示す。まずクレジット予約を見ると、メーカー・ワークステーション２４０が入札またはオファーを行うと、そのワークステーションは相場（付け値）提出ＷＳメッセージ３００をその銀行ノード２２０に送る。このメッセージはメーカーによる匿名取引システムへの相場（付け値）の提出である。銀行ノードはこの相場（付け値）を認証し、相場（付け値）リストの中で相場（付け値）コンテキストを作成し、相場（付け値）を相場（付け値）提出メッセージ３０２に入れて調停者に送る。
【０１２２】
メーカー調停者２００はこの相場（付け値）を認証し、メーカーの銀行ノードに受取通知メッセージ相場（付け値）提出受信通知３０４を送る。銀行ノードはこの相場（付け値）を受け入れるか、拒絶する。例えば、相場（付け値）額などのような詳細が欠落している場合、相場（付け値）が拒絶される場合がある。
【０１２３】
メーカーの銀行ノードが相場（付け値）提出受信通知メッセージ３０２を受信すると、そのノードは相場（付け値）が拒絶されたかどうかを調べる。拒絶されている場合、メーカー・ワークステーションに相場（付け値）ＣｘｒｅｄＷＳメッセージ（図示せず）を、調停者に相場（付け値）割込みメッセージを送る。次に相場（付け値）リストから相場（付け値）コンテキストを取り除く。
【０１２４】
相場（付け値）が調停者に受け入れられた場合、メーカー調停者は使用可能な相場（付け値）メッセージ３０６をすべてのローカル・市場配給業者（図示せず）、およびその他すべての調停者に送る。この時点で、相場（付け値）はローカル・メーカーからの売り要求、他の調停者からのヒットの標的となり、もしくは調停者がシステム内の他の相場（付け値）との照合を自動的に行うａｕｔｏｍａｔｃｈに参加することもできる。
【０１２５】
購入者がワークステーション画面に表示されるメーカーの相場（付け値）をヒットする場合、そのワークステーションはＷＮ＿ヒット提出ＷＳメッセージ３０８をその銀行ノードに送る。銀行ノードはそれに応えてＮＡ＿ヒット提出メッセージ３１０をその調停者２００に送る。受け手調停者はこのヒット提出メッセージをメーカー調停者にヒット相場（付け値）メッセージ３０９として流し、調停者はヒット相場（付け値）受信通知メッセージ３１１でその受け取りを通知する。
【０１２６】
次に調停者は適合する相場（付け値）を選び、固有の取引識別名を作成し、ＡＮ＿ヒット通知メッセージ３１２をメーカーの銀行ノードに送る。これは購入者によるそのヒットに対する応答である場合と、購入者が提出した相場（付け値）のａｕｔｏｍａｔｃｈの結果である場合とがある。同時に、メーカー調停者２００はメーカーと受け手の銀行ノードの両方に成り代わりクレジット仲介業者に対してクレジット予約を開始する。クレジット仲介業者は、上記実施形態のクレジット・エージェントとは違って取引の双方のクレジットを取り扱うということを理解することが重要である。
【０１２７】
メーカーの銀行ノードがＮＷ＿ヒット金額３１４メッセージをメーカー・ワークステーションに送り、その取引に関わる相場（付け値）の存在を確認する。その相場（付け値）が取引業者によって割込みされていない場合、取引業者はこれから行おうとする取引について通知を受け、これから行おうとするこの取引に関係する相場（付け値）の部分をもはや割込みすることはできない。メーカー・ワークステーションはＷＮ＿ヒット金額受信通知メッセージ３１６を銀行ノードに送り返し、ヒット金額メッセージの受け取りを通知する。相場（付け値）が割込みされた場合、銀行ノードは取引を取り消し、ＮＡ＿取引不成功メッセージ（図示せず）を調停者に送り返す。
【０１２８】
相場（付け値）が割込みされていないことを前提にすると、メーカーの銀行ノードはこれから行おうとする取引を割り当てレコードとして取引業者データベースに記録し、取引状態を「不確か」として表示する。次に、取引を確認するために、銀行ノードは取引き確認メッセージ３２０をその調停者２００に送る。
【０１２９】
その前にクレジット予約を開始している調停者は、クレジット予約の結果を待つ。それをクレジット仲介業者２３０から受け取ると、取引き確認メッセージ３２０が取引金額を伴って受け手調停者２００に送られる。この額は、取引の一部だけを完了するクレジットしかない場合と、取引金額全額に満たない場合とがある。取引確認メッセージは受け手銀行ノードに送られ、受け手銀行ノードは、これから行おうとする取引のリスト中に取引のためのコンテキストを作成する。次にこの取引を取引データベースに記録し、取引状態が確認された状態での取引レコードを作成する。取引には固有のチケット番号が割り当てられ、取引の取引監査が作成される。次に受け手銀行ノードはＮＡ＿取引き状態購入者メッセージ３２２を受け手調停者に送り、最終取引金額を伴ってＮＷ＿取引き状態ＷＳ＿購入者メッセージ３２４を受け手ワークステーションに送る。
【０１３０】
次に、受け手調停者は、取引き確認メッセージ３２０の受け取りを通知するために取引き確認受信通知メッセージ３２６をメーカー調停者に送る。メーカー調停者は受取通知メッセージをメーカー銀行ノードに流す。このメッセージを受け取ると、メーカーの銀行ノードはその取引データベース内の取引状態を「コミットしている」に変更し、取引にチケット番号を割り当てる。次に、調停者にＮＡ＿取引き状態メーカー・メッセージ３２８、メーカー・ワークステーションに最終取引金額を伴ってＮＷ＿取引き状態ＷＳメーカー・メッセージ３３０を送る。これら２つのメッセージはメーカー・ワークステーションと調停者に対して取引状態の変更を確認するものである。
【０１３１】
メーカーの銀行ノードは次に商品メーカー・メッセージ３３２をその調停者に送る。このメッセージには決済に関する指示が含まれている。このメッセージは受け手調停者に、次いで受け手の銀行ノードに送られ、ここで決済に関する指示が取引データベースに記録される。取引状態は「決済済み」に変更される。取引に順番号が割り当てられ、取引チケットが印刷される。次に受け手の銀行ノードが、受け手の決済に関する指示を含んだ商品購入者メッセージ３３４をその調停者に送る。このメッセージは、２人の調停者を介してメーカーの銀行ノードに送られる。また、受け手の銀行ノードも、取引の完了作業を実施し、取引業者に取引が記録されたことを通知している受け手ワークステーションにＮＷ−ＬｏｇｇｅｄＷＳ購入者メッセージ３３６を送る。
【０１３２】
メーカー銀行ノードで商品購入者メッセージが受領されると、決済に関する指示が取引データベースに記録され、取引状態が「決済済み」に変更される。受け手銀行ノード同様、順番号が割り当てられ、取引チケットが印刷される。次にメーカー銀行ノードがＮＷ＿商品のログＷＳメーカー・メッセージ３３８を、メーカー・ワークステーションに送り取引を完了させる。
【０１３３】
以下の説明は、上記の取引実行プロセスにおけるクレジット仲介業者の作業に関する。
【０１３４】
上記説明では、メーカーの調停者が、ＡＮ＿ヒット通知メッセージがメーカー銀行ノードに送られたときにクレジット予約を開始する。このクレジット予約は取引の当事者の一方だけがグローバル・クレジットに参加している場合に実施される。その場合、メーカー調停者はＡＣ＿クレジットの留保メッセージ３４０をクレジット仲介業者２１０に送る。この予約クレジット・メッセージには取引識別名、これから行おうとする取引の金額、取引がＦＸスポットの場合は通貨対識別名、そうでない場合はこれ以外の商品識別名、ならびにメーカーと購入者の立会場の名称が含まれる。後者は「フロアキー」と呼ばれるものである。
【０１３５】
メーカーの立会場がグローバル・クレジットに参加している場合、クレジット仲介業者でのクレジット調査は継続され、さもなくばメーカーのクレジット予約はメーカー側のクレジット調査を完了させるために状態は「メーカーが不確か」となり、購入者のクレジット調査が継続される。
【０１３６】
メーカーがグローバル・クレジットに参加しているものとすると、クレジット仲介業者はまずメーカーの立会場を含む授与者グループを解散する。被授与者はフロアキーを使用して授与者グループから解散される。これにより、これから行おうとする取引のために利用する割り当て分が提供される。取引金額は割り当て分に関連するクレジット限度通貨という点でクレジット利用に換算される。
【０１３７】
ある割り当て内で利用可能な総クレジットは、取引に必要な額と比較される。最少規模の取引に必要なクレジットが得られない場合、予約プロセスは中断され、ＣＡ＿クレジット受信通知の留保メッセージ３４２が調停者に送られ、利用可能なクレジットが使い果たされたことを知らせる。
【０１３８】
クレジット仲介業者が購入者の予約も処理している場合、つまり購入者の機関がグローバル・クレジットに参加している場合、市場のクレジットはメッセージを送る前に振り出される。充分なクレジットがあるものの、その額が提案されている取引の金額に満たない場合、取引金額と予約額が減額される。
【０１３９】
総クレジット額が充分である場合、仲介業者が、予約を完了するのに物理的に充分なクレジットをローカル・クレジット仲介業者のところに持っているかどうかを特定する。そうである場合、仲介業者は利用額を、その割り当てに対する総利用に加算し、ＣＡ＿クレジット受信通知の留保メッセージ３４２にメーカーが取引金額で予約しているものとしてマークを付ける。次に、そのクレジット仲介業者が購入者クレジットを同様に処理する。
【０１４０】
総クレジット額が充分なものの、仲介業者が、予約を完了するのに物理的に充分なクレジットをローカル・クレジット仲介業者のところに持たない場合、遠隔の適切なクレジット仲介業者に予約の完了を依頼しなければならない。これは物理的な割り当てを持っていると思われるクレジット仲介業者にＣＣ＿遠隔クレジットの留保メッセージ３４４を送ることで実施する。このメッセージには依頼番号、授与者と被授与者のフロアキー、割り当て識別名、および予約額が含まれる。図１０は、２人のクレジット仲介業者が関与する状況を示す。ここではメーカー調停者が２００、発信元クレジット仲介業者、つまり図９のクレジット仲介業者は２３０（ａ）となっている。第２のクレジット仲介業者は２３０（ｂ）となっており、それに関連する調停者は示されていない。
【０１４１】
ＣＣ＿遠隔クレジットの留保メッセージ３４４を受け取ったクレジット仲介業者は自分のローカル割り当てを調べる。その予約に対応できる場合はその額が予約される。対応できない場合、受け取り側のクレジット仲介業者が利用可能な総クレジット額を調べ、依頼が不成功に終わったことを知らせるＣＣ＿遠隔クレジット受信通知の留保メッセージ３４６でその依頼を拒否するか、依頼を第３のクレジット仲介業者に転送する。ＷＯ９３／１５４６７号のアーキテクチャに基づくシステムでは、クレジット仲介業者は３人、各調停者につき１人いることを思い返されたい。
【０１４２】
発信元のクレジット仲介業者が受け取ったＣＣ＿遠隔クレジット受信通知の留保メッセージ３４６がクレジットが予約されたことを示していれば、購入者側の予約処理を行う。これが成功裏に完了すると、これから行おうとする取引のための額が成功裏に予約されたことを知らせるＣＡ＿遠隔クレジットの留保メッセージ３４２が依頼調停者２００に送られる。
【０１４３】
調停者は、いつ取引が確認されたかをクレジット仲介業者２１０に知らせる必要がある。これによってクレジット仲介業者は予約額を最終決定することができ、遠隔クレジット仲介業者が関与している場合、割り当てが利用されたことを遠隔クレジット仲介業者に通知することができる。これは調停者からクレジット仲介業者に宛てたＡＣ＿取引き状態メッセージ３４８で行う。クレジット仲介業者は、取引状態メッセージで取引の最終状態を知る。取引が不成功の場合、クレジット予約は元通りに戻される。成功の場合、遠隔クレジット仲介業者が関与していれば、遠隔クレジット仲介業者はＣＣ＿留保の完了メッセージ３５０によってクレジットが利用された旨の通知を受ける。このメッセージには割り当て識別名、および割り当てに対して確認された額が含まれる。これによってクレジット仲介業者は総割り当ての運用可能残高を正確に把握することができる。
【０１４４】
遠隔クレジット仲介業者２３０（ｂ）は予約完了メッセージ３５０を受け取ると、ローカルで持つ割り当てのどれかを他のクレジット仲介業者に転送するべきかどうかを判断する。この判断は各クレジット仲介業者によって最近処理された予約依頼の数、利用可能な総割り当て、および各クレジット仲介業者において利用可能なローカル割り当てに基づく。１人の仲介業者が他の仲介業者に割り当てを転送する場合、すべてのクレジット仲介業者にＣＦＣ＿割当て転送メッセージ３５２を送る。このメッセージには譲渡と受取仲介業者の両方の名称、ならびに転送額が含まれる。このメッセージによって割り当ては最も必要とされる場所に転送されると同時に、仲介業者は利用可能な割り当てがどこにあるかを正確に把握することができる。クレジット調査を実施する際のメッセージの数が減り、取引を取りまとめる調停者の近くでクレジット調査が行われるようになることであることを理解されたい。いずれの要素も取引完了プロセスの迅速化に貢献する。
【０１４５】
図９および図１０に関する上記解説は、ＷＯ９３／１５４６７号のアーキテクチャへのグローバル・クレジット、またはグローバル／ローカル、ローカル／グローバル・クレジット制度の導入方法を示したものである。ただし、ここで説明する原理はクレジット調査を必要とするどのような匿名取引システムにも応用することができる。例えば、図１から図７の仲介業者ノード型分散システムから、調停者と仲介業者ノードを組み合わせたハイブリッド・システムにも同様に応用することができる。
【０１４６】
図１１は、調停者２００が市場配給業者４０、およびそれぞれがローカル・クレジット制度ＬＣ２５０を運用する相互接続されたいくつかの銀行ノードによって保持されているハイブリッド・モデルを示す。
【０１４７】
取引業者ワークステーションＷＳと立会場管理者ワークステーションＴＦＡ ＷＳは、仲介業者のプラットフォームＡＰＩを介して銀行ノードと通信する。これによって立会場管理者がクレジット仲介業者のところに保存されるクレジット限度を変更することができる。図１から図７で説明する種類の仲介業者も調停者と組を成す。仲介業者は以前は銀行ノード、および市場配給業者が取り扱っていた機能を果たし、この中には取引業者ワークステーションに配分クレジットでフィルターをかけて市況概況を取引業者ワークステーションに配布する機能が含まれる。仲介業者ノードはゲートウェイを介して調停者を通信し、ワークステーションは仲介業者のプラットフォームＡＰを介して仲介業者ノードを通信する。仲介業者ノードには、取引の一方がグローバル・クレジットを、もう一方がローカル・クレジットを利用している取引が行われているクレジット仲介業者と通信するローカル・クレジット・モジュールが含まれることもある。ローカル・クレジット・モジュールは、管理者が保存されているクレジット限度を変更できるように、立会場管理者ワークステーションＴＦＡ ＷＳでアクセスすることができる。
【０１４８】
純粋な仲介業者ノード実行の場合には、クレジット仲介業者の機能が、各仲介業者ノードに内蔵されるということを除いて、アーキテクチャは、図１−図７に示すようになる。それ故、ＷＯ９３／１５４６７号の類推により、各仲介業者ノードは、取引の照合および実行を含む、銀行ノード、市場配給業者、調停者の機能、およびグローバル・クレジット仲介業者の機能を行う。仲介業者は、上記のクリーク・ツリー構造体により、相互に接続していて、取引業者のワークステーションは、仲介業者のプラットフォームを通して、仲介業者ノードに接続している。
【０１４９】
上記説明において、ローカル・クレジットは、１つの立会場に割り当てられたクレジットを単に参照する必要はなく、例えば、１つの地理的領域をカバーしている多数の立会場にクレジットが割り当てられる地域的クレジットを含むことができる。同様に、グローバル・クレジットの概念は、厳密に、機関の階層内の最高の点を意味する必要はなく、地域的なものであってもよい。一例を挙げると、グローバルなクレジットは、ローカル・クレジット・レベルとして処理されている各国内の個々の立会場と取引きをしているある機関のヨーロッパの立会場を意味することもできる。
【０１５０】
上記の配置に対する他の種々の修正および別の配置が可能であり、当業者であれば、それらに思い付くことができるだろう。そのような変更および修正は、すべて添付の特許請求の範囲によってだけ定義される、本発明の精神および範囲内に含まれる。
【図面の簡単な説明】
【図１】本発明の第１の機能を実行する取引システムの全体図である。
【図２】システムで新しい相場（付け値）が提出された場合の、図１のシステムでのメッセージの流れを示す。
【図３】図１のシステムでの取引業者に対する市場展望の作成を示す。
【図４】取引業者が買い注文または売り注文を出した場合の、図１のシステムでのメッセージの流れを示す。
【図５】買い注文または売り注文を出した後での、仲介業者ノードを更新するためのメッセージの流れを示す。
【図６】仲介業者が相場（付け値）を修正した場合の、メッセージの流れを示す。
【図７】取引実行プロセスを示す。
【図８】グローバル・クレジット・モデルでのメッセージの流れを示す。
【図９】本発明の第２の機能を実行する取引システムの一部の簡単なアーキテクチャである。
【図１０】図９のシステム内のもう１人のクレジット仲介業者の使用を示す。
【図１１】仲介業者、仲介ノード、グローバルおよびローカル・クレジットの組合わせを使用するハイブリッド・システムである。
（発明の分野）
本発明は、電子仲介システムに関し、特に、相手方が、一定のクレジット限度内で匿名で取り引きをするシステムに関する。このようなシステムは、外国為替および金利先渡し契約のような金融商品を取り引きすることができる。本発明は、特にこのようなシステムでの、双方当事者間でのクレジット限度の処理に関する。
【０００２】
（発明の背景）
当業者にとっては、多数の匿名取引システムは周知のものである。ロイター社に譲渡された、ＥＰ−Ａ−０，３９９，８５０号、ＥＰ−Ａ−０，４０６，０２６号およびＥＰ−Ａ−０，４１１，７４８号すべては、ホスト・コンピュータが、ネットワークを通してホストに接続している端末が提出した入札およびオファーの中央データベースを維持している自動照合システムの種々の機能を開示している。ホストは、また、各取引銀行およびこれらの銀行と進んで取引きする相手方との間のクレジット限度の記録も維持している。ホスト・コンピュータは、入札およびオファーを照合し、相手方のクレジット限度を含む照合基準に基づいて注文を売買するために、その中央データベース内の情報を使用する。
【０００３】
通常、相手方のクレジット限度は、各銀行または各立会場（取引フロア）に対して設定されていて、ホスト・コンピュータは、可能な当事者の組に対する総当事者クレジット限度を確立する。総当事者クレジット限度は、２人の当事者間の残りのクレジットの最小額である。
【０００４】
取引業者端末は、通常は、最も高額のいくつかの入札およびオファーである取引記録のサブセットを表示する。取引業者が確実に市場の本当の姿を見ることができるように、これらの入札およびオファーは周期的に更新される。
【０００５】
上記システムに関する１つの問題は、取引業者が、自分が取引きのために、上記入札またはオファーを行っている相手方に対して十分なクレジットを持っているかどうかにかかわらず、上記入札およびオファーを閲覧することができることである。その結果、取引業者は、行使できるクレジットがない場合でも、取引きの申し込みを行うことができる。システムは匿名であるので、取引業者は、取引きが完了するまで相手方を知ることができず、そのため、その取引業者が入札またはオファーを行うのに成功した場合、クレジットを持っていないという理由で、受諾してよいのか拒否したらよいのかについて全然わからない。このことは、取引業者にとって非常に困った問題であって、特に、取引きの機会がすぐに失われてしまう動きの速い市場では特に困った問題である。上記問題の原因は、取引きが申し込まれ、成立の可能性がある場合に、ホスト・コンピュータだけしか、行使できるクレジットをチェックできないという事実によるものである。
【０００６】
この問題は、ＥＢＳディーリング・リソース社に譲渡されたＷＯ９３／１５４６７号により解決済みである。各取引業者に、実際の取引記録またはその一部を表示する代わりに、各取引業者に、自分たちが、十分なクレジットを持っていないか、全然クレジットを持っていない相手方からの入札およびオファーが映し出されている他の市場の様子が表示される。それ故、取引業者は、自分が取引きすることができる価格を見るだけですむ。
【０００７】
ＷＯ９３／１５４６７号のシステムのアーキテクチャは、ロイター・システムとは非常に異なっていて、照合を行う多数の仲介業者を含む分散型ネットワークに基づいている。実際のクレジット限度は、各銀行の取引端末が接続しているローカル銀行ノードに記憶されていて、それにより、どのようにしても、変動しやすいクレジット・データを銀行の物理的サイトから取り出すことができないようになっている。実際の取引記録は、仲介業者により市場配給業者に送られる。市場配給業者は、所定の立会場（取引フロア）に特有の市場の展望を作成し、それを関連銀行ノードに送る。クレジット基準により、各取引立会場について、異なる市場の展望を作成することができる。それ故、各銀行ノードに配布される市場の展望は、クレジット審査の場についての完全な市場展望であり、それにより、銀行または銀行内の所定の立会場は、クレジットが不十分な任意の価格をふるい落とすことができる。
【０００８】
さらに、市場配給業者は、また、ある程度のクレジット情報を持っていて、所定の相手方に対して、１つの「はい（ｙｅｓ）−いいえ（ｎｏ）」クレジット・インジケータを記憶することができるクレジット・マトリックスを維持している。取引きが成立すると、価格がクレジットのためにすでに選択されているので、銀行ノードは、任意の前に与えられたクレジットがすでに使用されてしまっているかどうかをチェックするために、クレジット・マトリックスにより第２のクレジット・チェックを行う。
【０００９】
ＷＯ９３／１５４６７号のシステムの場合には、特定の立会場は、個々に、他の立会場に、またはクレジット構成要素としてグループに統合された立会場に、クレジットを割り当てることができる。しかし、ある機関レベルまたはグローバルなレベルからのクレジットの割当てに対する規定はない。
【００１０】
クレジット機能は、クレジット・グループおよび実際のクレジット限度額についての情報を維持している銀行ノードに常駐している。銀行ノードは、はい／いいえクレジット関係によってだけ、仲介業者にクレジット情報を送る。所定の相手方に対するクレジット額は、毎日の自動的なリセット、または立会場の管理者による手動介入により、または、取引きの間に変化する場合がある。使用できるクレジットがゼロになるか、またはゼロから正の数値にリセットされると、クレジット更新メッセージが、銀行ノードからそのクレジット・グループに属する立会場の仲介業者に送られる。
【００１１】
上記両方のシステムは、多年にわたって、金融取引市場で使用され成功を収めてきたが、両システムは、クレジットの処理については非常に柔軟性に乏しいという欠点をもっている。これらのシステムの場合には、銀行は、その取引活動のある領域内で、多額のクレジットとタイアップしなければならない。通常の銀行は、多数の金融商品、および多数の異なる市場を扱い、各取引日内に、そのクレジット限度一杯まで取引きを行いたいと考える。ある特定の市場が活気がない場合には、その市場に割り当てられたクレジットを別の分野に流用できればと考えるだろう。同様に、特定の市場が非常に活況の場合には、その市場は、その活況を利用できればと考えるだろう。所定の銀行は、異なる市場で、多くの同じ相手方と取引きすることができることを思い出されたい。それ故、所定の相手方との特定の１つの商品による取引きを行うためにクレジットを提携することは望ましいことではない。何故なら、そのように固定すると、それ自身のグローバルな取引限度内のその銀行の取引容量が低減する場合があるからである。また、クレジット限度が割り当てられる方法は、多くの銀行がクレジットを処理し、割り当てる方法に影響を与えない。クレジットに関する限り、ある銀行はあるシステムを別の方法で処理しなければならなくなり、そうなると、銀行はそのシステムを使用したがらなくなる。
【００１２】
（発明の概要）
本発明の目的は、先行技術のシステムよりももっと柔軟にクレジットを割り当てられるシステムを提供することである。
【００１３】
本発明の一実施形態は、電子メッセージを送信するための通信ネットワークを含む金融商品または他の商品を取引きするための匿名取引システムを提供する。複数の取引業者端末が上記ネットワークに接続していて、各端末は、入札および／またはオファー価格を含み、他の取引業者端末から取引業者情報を通信することができる電子価格取引メッセージを発生することができる。１つまたはそれ以上の照合エンジンが、入札およびオファーを照合するために、ネットワークに接続していて、ある取引きが成立すると、取引きを実行する。ネットワークに接続している市場配給手段は、価格メッセージを取引業者端末に配給し、取引価格メッセージおよび照合エンジンに応答する。クレジット限度記憶手段は、立会場または立会場のグループと可能な相手方の立会場または立会場のグループとの間の取引きに対して使用することができるクレジット限度を記憶する。クレジット限度記憶手段は、少なくとも１つの立会場のグループに対するクレジット限度を記憶する少なくとも１つのクレジット・エージェント・ノードを含む。
【００１４】
クレジット・エージェント・ノードを使用することにより、ある機関のクレジットをグローバルに処理することができる。すなわち、クレジットを立会場ベースで割り当てる必要がなくなる。そのため、システムのユーザは、立会場から相手方の立会場へ、立会場の多数のグループの中の１つから個々のまたは多数の立会場のグループへ、団体から団体、またはこれらのローカルおよびグローバルなクレジット機関の任意の組合わせへ柔軟にクレジットを割り当てることができる。また、そのため、システムのユーザは、先行技術のシステムより高い柔軟性を持つことができ、取引日の間、使用できるクレジット限度を全部容易に利用することができる。
【００１５】
好適には、取引業者端末は、取引エージェント・ノードを通してネットワークに接続していることが好ましい。構成を簡単にするために、クレジット・エージェント・ノードとして取引エージェント・ノードを使用することもできる。接続している取引業者端末に対する自分自身のクレジット情報を持っていない各取引エージェント・ノードは、提案された取引メッセージを受信した場合に、クレジット・エージェント・ノードに、クレジット問合わせメッセージを送信するための手段を含む。クレジット・エージェントは、取引エージェント・ノードに対するクレジット問合わせメッセージを受信し、使用できるクレジットをチェックし、またシステムに、取引きを進めることができるかどうかを表示するための手段を含む。好適には、上記表示は、全取引きに対してクレジットが不足している場合には、提案された金額の一部に対して取引きを進めることができることを表示することができることが好ましい。好適には、クレジット・エージェント・ノードは、取引エージェント・ノードに直接接続しないで、クレジット問合わせメッセージを取引成立エンジンの中の１つを通して送信することが好ましい。好適には、クレジット・エージェントからの取引インジケータ・メッセージは、それを相手方の取引エージェントに転送する取引成立エージェントの中の１つに送信することが好ましい。
【００１６】
１つの実施形態の場合には、所定の当事者のクレジット限度記憶手段が、その複数の外部クレジット限度記憶手段に対してインターフェースとしての働きをする。そのため、システムのクレジットを種々の媒体を通して処理することができ、または、それに対する相手方が、種々の商品を処理することができるその商品に対するその当事者の全クレジット・スキームの一部として処理することができる。
【００１７】
システムは、多くのクレジット・エージェント・ノードを含むことができる。
【００１８】
第２の観点から見た場合、本発明では、クレジット・エージェントが、照合エンジンに関連するクレジット仲介業者により置き換えられていて、複数の団体に対するクレジット限度を記憶する。各記憶されているクレジット限度は、その機関の立会場、またはその機関の立会場のグループと相手方の機関、または相手方の機関の選択した立会場または立会場のグループとの間の取引きに使用することができるクレジットを表す。
【００１９】
照合エンジンに関連するクレジット仲介業者を使用すると有利である。何故なら、クレジットをチェックするために必要な時間が最も短くてすむからである。ある取引きの場合、販売者（ｍａｋｅｒ）と購入者（ｔａｋｅｒ）の両方が、グローバルなクレジット制度を使用している場合には、両者に対するクレジットは、クレジット仲介業者によりチェックすることができる。そのため、取引処理時間が大幅に短縮する。
【００２０】
１つの好適な実施形態の場合には、照合エンジンは、ＷＯ９３／１５４６７号に記載されている仲介業者であり、クレジット・エージェントは、好適には、ローカル・エリア・ネットワークにより接続していることが好ましい、各仲介業者に関連している。他の好適な実施形態の場合には、取引システムは、照合、取引きの実行、市場配給の機能を行う仲介ノードの多数のクリークを備え、クレジット仲介業者は、仲介ノードに内蔵されていて、そのため、各ノードはクレジット仲介機能を持つ。
【００２１】
複数のクレジット仲介業者を使用する場合には、ある機関に対するクレジットは、クレジット仲介業者の間に割り当てることができる。好適には、システムは、クレジット・チェックを行うために、呼び出される可能性が最も高い仲介業者にそのクレジットを確実に割り当てることができることが好ましい。これは、最も能動的な仲介業者に関連するクレジット仲介業者である。ある取引きに対してクレジットを使用することができるが、その取引きを処理している照合エンジンに関連するクレジット仲介業者に全部を割り当てることができない場合には、好適には、そのクレジット割当ての一部の留保を要求している他のクレジット仲介業者の中の１人に送ることが好ましい。
【００２２】
好適には、クレジット割当ては、クレジット仲介業者の間で移転することができることが好ましい。
【００２３】
本発明の１つの好適な実施形態の場合には、金融商品を含む商品の匿名商取引のための自動取引システムは、立会場を含む１つまたはそれ以上の取引業者端末に接続している複数の相互に接続している仲介ノードを持つコンピュータ通信ネットワークを備える。各仲介ノードは、取引業者端末から価格相場（付け値）メッセージとしてシステムに入力された入札およびオファーを照合するための照合エンジンと、価格が折り合った場合に取引きを実行するための手段と、価格相場（付け値）メッセージおよび照合エンジンに応答して取引業者端末へ価格メッセージを分配するための市場配給手段とを備える。１つまたはそれ以上のクレジット・エージェント・ノードが設置されていて、各クレジット・エージェント・ノードは、可能な相手方の立会場または立会場のグループとの取引きに対して、多数の取引エージェント・ノードに接続している立会場に対するクレジット限度を記憶する。その接続している立会場のクレジット限度が、クレジット・エージェント・ノードのところに記憶されていないこれらの取引エージェントは、それ自身のクレジット限度を記憶するためのクレジット限度記憶手段を含む。
【００２４】
別な方法としては、クレジット・エージェント・ノードを、複数の各機関により、複数の可能な相手方の機関に割り当てられたクレジット限度を記憶するための少なくとも１つの照合エンジンに関連する１人のクレジット仲介業者で置き換えることができる。
【００２５】
添付の図面を参照しながら本発明の実施形態について説明するが、これは単に例示としてのものに過ぎない。
【００２６】
（好適な実施形態の説明）
以下に説明する、図１−図８の取引アーキテクチャを参照しながら、本発明の第１の機能について説明する。しかし、本発明のこの機能は、上記アーキテクチャに限定されるのではなく、任意の匿名取引システムで実行することができることを理解されたい。例えば、本発明の第１の機能は、当業者にとって周知の上記のロイター社、およびＥＢＳディーリング・リソース社の先行技術のシステムのどちらでも実行することができる。同様に、図９−図１１を参照しながら、本発明の第２の機能について説明するが、この第２の機能は、これらの図面の特定のアーキテクチャ構成に限定されない。
【００２７】
これから説明する電子仲介システムは、少なくとも下記の商品、すなわち、ＦＸ（外国為替）スポット、ＦＲＡおよび先物、およびＦＸ先物、ＣＦＤ、短期政府および／または中央銀行紙幣、商業手形、ＣＤ、銀行間預金、コマーシャル・ペーパー、レポ、金利先物取引、スワップ、オプション、およびこれらの種々の金融商品に基づく種々の注文の変種を取引きするためのプラットフォームを提供する。これらは、すべて金融商品と呼ばれる。上記電子仲介システムは、また、商品のような非金融商品の取引きのためにも使用することができる。
【００２８】
取引業者端末のところの取引業者は、端末間で電子メッセージを交換することができる通信ネットワークに接続している。これらのメッセージは、後でシステム全体の複数の各仲介業者ノードに送られる相場（付け値）およびヒットの提出を含む。相場（付け値）は、「取引する（ｍａｋｅ ｍａｒｋｅｔ）」ために取引業者が提出する入札およびオファーであり、市場展望の一部として他の取引業者に配布される。それ故、相場（付け値）は、他の取引業者が目で見ることができるで注文である。ヒットは、１つまたはそれ以上の相場（付け値）から入手した自分の市場展望上に表示された値段に基づいて取引きを行いたいと考えている取引業者が出した買い注文または売り注文である。ヒットは他の取引業者には見えない注文である。
【００２９】
図１のコンピュータ取引システムは、複数の取引エージェント１０を含み、各エージェントは、複数の仲介業者ノード１２の中の少なくとも１つに接続している。各取引エージェントは、それにより、取引業者端末が、所定の取引業者端末が、１つまたはそれ以上の取引エージェントに取り付けられている取引システムにアクセスする手段である。
【００３０】
取引業者端末（図示せず）としては、ワークステーション、または（通常は、特殊化されたキーパッドによる）入札および／またはオファー価格、相場（付け値）および注文を含む電子注文メッセージを発生し、提出し、また、取引き対象の金融商品に対して使用することができる価格および金額を含む市場展望データを通信するように構成されている他のコンピュータ端末等がある。上記通信は、通常、表示により行われるが、情報の印刷、音声合成、またはその他の方法によって行うこともできる。取引業者端末は、手動により、または自動的に注文を入力することができる。後者の場合、取引業者は、市場が所定の状態になった場合に、注文を出すように端末をプログラムすることができる。別な方法としては、取引業者端末を個々のワークステーションにしないで、機関の自動取引機能に内蔵させることもできる。これらすべての修正は、注文入力デバイスの数例にしか過ぎない。
【００３１】
取引業者は、通常、取引業者を立会場の一部として配置する銀行のような金融機関の一部としてグループ分けされる。立会場は、立会場に対するクレジット・ラインを他の立会場に対して割り当てる立会場管理者の共通の制御下の取引業者のグループである。ある取引業者、または取引業者のグループに対する市場展望は、市場を反映する取引業者が見ることができる市場情報（価格、数量等）である。市場展望は、好適には、ＷＯ９３／１５４６７号が開示しているように、クレジットの互換性に対して予め審査したものであることが好ましい。上記特許の内容は、本願に引用して援用する。それ故、取引業者だけが、それにより自分達が取引きすることができる表示相場（付け値）を見ることができる。立会場へのクレジットの供与の他に、クレジット全体を銀行に供与することもできるし（多くの銀行は、立会場とは無関係のいくつかの場所を持っている）、または個々の取引業者または取引業者のグループに供与することもできる。クレジット全体を、銀行から、立会場から、または個々の取引業者から供与することもできる。このプロセスについては、後で詳細に説明する。
【００３２】
上記システムは、仲介業者が作成した市場展望が、価格のソースを識別しないで、価格および金額情報を含む匿名取引システムである。使用できる入札およびオファー、およびその価格で使用することができる金額に対して表示される価格は、１つまたはそれ以上の相場（付け値）の集合体である。予め審査したクレジット基準を満足する当事者の相場（付け値）だけが、表示の価格の集合体内に含まれる。それ故、仲介業者が作成した市場展望は、クレジット割当てにより、立会場毎に異なる。
【００３３】
取引エージェント・ノードは、特定の立会場または取引業者のグループにサービスを提供する。これらのサービスは、各取引ワークステーションに対するネットワークへのアクセスの供給、取引きの完了、取引きチケットの作成、取引業者のための過去の取引情報の維持を含む。各取引エージェント・ノードは、取引システムにアクセスするために、少なくとも１つの仲介業者ノードに接続していなければならない。それ故、取引業者端末のグループは、システムにアクセスするために、取引エージェント１０に接続している。
【００３４】
各仲介業者ノード１２は、基本的注文照合サービス、および価格配布サービスを行う。仲介業者ノードは、非常に特殊な、しかし、簡単なルールに従って、もっと高速の通信転送を行うことができるクリーク・ツリーと呼ばれる構造体内に配置されている。クリーク・ツリーは、個々のノードがクリークにグループ分けされていて、その後で、クリークがツリー構造体の形に配置されているネットワーク構造体である。各仲介業者は、その近隣仲介業者と呼ばれる多数の仲介業者に論理的にリンクすることができる。仲介業者間の通信は、同じレベル上に位置していて、ネットワーク内において「上下」関係はない。
【００３５】
図１の実施形態の場合には、クリークの数は三つである。すなわち、仲介業者１２ａ、１２ｂおよび１２ｃにより形成されているクリーク、仲介業者１２ｂ、１２ｄ、１２ｅおよび１２ｆにより形成されているクリーク、仲介業者１２ｅおよび１２ｆにより形成されているクリークである。仲介業者１２ｂおよび１２ｅは、両方とも、２つのクリーク内に位置していることが分かるだろう。分かりやすくするために、簡単な例だけを示したことを理解することができるだろう。実際には、ネットワークは、多数のクリークを含んでいて、遥かに複雑なものになる場合がある。
【００３６】
取引エージェントは、少なくとも１つの仲介業者ノードに接続しなければならないが、取引エージェントは、クリーク・ツリーのメンバーではなく、構造体の外に位置している。複数の仲介業者ノードに接続している取引エージェントは、複数の組の市場価格を受信する。異なる仲介業者ノードからの価格情報が、実質的に同じである場合はあっても、上記情報は、異なる時間的間隔で受信することができる。取引エージェントは、所定の取引注文を１つの仲介業者ノードだけに送信する。
【００３７】
仲介業者ノードという用語は、仲介機能を供給しているコンピュータ・ネットワーク内で、物理的または論理的に配置されているコンピュータを表すために使用される。基本的仲介機能は、相場（付け値）の記憶、市場展望の形による取引業者への相場（付け値）の供給、および相場（付け値）と注文との照合である。上記実施形態内の仲介業者ノードも、他の機能を実行するが、これらの機能は、仲介業者ノードと定義される本質的な機能ではない。
【００３８】
それ故、各仲介業者ノードは、提出された入札およびオファーを照合して成立した場合には、取引きを実行するための、ネットワークに接続している照合エンジンを供給する。仲介業者ノードは、また、取引価格メッセージおよび照合エンジンに応じて、取引業者端末に価格メッセージを配布する市場配給業者の機能を実行する。本発明においては、好適には、照合機能および市場配給機能は、仲介業者ノード内で融合されることが好ましいが、本発明は、上記機能が独立していて、地理的および／または論理的に離れている位置で実行されるシステムにも、等しく適用することができる。このようなシステムの一例が、上記のＷＯ９３／１５４６７号が開示しているシステムである。
【００３９】
各仲介業者ノードは同じものであり、同じ機能を行う。その内部のネットワークおよびその位置の配置は、仲介業者ノードに対して透明である。仲介業者ノードは、その近隣について知っているだけでよい。各仲介業者ノードは、市場内のすべての注文を知っていて、提出されるとすぐに、注文を照合することができる。各仲介業者ノードは、市場内の注文の全リストを維持しているので、取引エージェントの必要に応じて市場展望をカスタム化することもできるし、受信するとすぐに市場情報により早く反応することもできる。
【００４０】
分散型仲介業者ノード配置の目的を理解してもらうために、図２を参照しながら、価格の配布および取引きの実行について説明する。
【００４１】
取引プロセスは、取引業者端末に注文を提出する１人またはそれ以上の取引業者によりスタートする。注文は、価格および数量のような、特定の制限を含む買いまたは売りついての指示を含む、ある取引業者からの取引要求である。相場（付け値）は、システム内で引き続き使用することができる永続性の注文であり、相場（付け値）情報の一部として配布される。相場（付け値）（Ｑｕｏｔｅ：クォート：付け値）は、「取引する（ｍａｋｅ ｔｈｅ ｍａｒｋｅｔ）」ために使用され、入札またはオファーとして取引業者に通知される。ヒットは、「目で見ることができない」および「ｆｉｌｌ（満たす） ｏｒ（または） ｋｉｌｌ（殺す）」特性（目で見ることができない）を持つ注文である。ヒットは、相場（付け値）の一部として配布されない。ヒットはシステム内に残留しない。入力したときに処理されない場合には、そのヒットは除去される。
【００４２】
注文記録は、市場で利用することができるすべての注文のリストである。相場（付け値）は、使用できる唯一の注文ではないので、注文記録は、相場（付け値）のリストからなる。相場（付け値）は、正しい取引順序で待ち行列の形に配置されている。待ち行列のソート順序は、異なる取引製品に対して変化することができる。デフォールト・ソート順序は、価格および時間の順番になっている。システムにおいては、各仲介業者ノードは、すべての利用できる相場（付け値）の完全なリストを維持する。外国為替のようなシステムにおいては、効果を上げるために、２つの記録があり、一方の記録は、買い注文を示し、他方の記録は売り注文を示す。
【００４３】
システム内のメッセージの流れについては、各メッセージが、ネットワーク全体を通して適当なパラメータを運ぶ名前付きの複数のメッセージにより説明する。相場（付け値）（永続的注文）の提出プロセスは、取引エージェントが、取引業者のワークステーションから、取引業者が入札またはオファーを発行したという情報を受信した時にスタートする。その後で、取引エージェントは、相場（付け値）提出プロセスをスタートする。取引エージェントが、取引業者のワークステーションから相場（付け値）情報を受信すると、取引エージェントは、相場（付け値）に対するコンテキストを生成する。その後で、取引エージェントは、自分が接続している仲介業者ノードに、相場（付け値）提出メッセージを送る。仲介業者ノードは相場（付け値）を確認し、有効であればその相場（付け値）を受け入れる。相場（付け値）を受信するこの第１の仲介業者ノードは、この相場（付け値）に対して「オーナー」仲介業者ノードになる。図２の例の場合には、「オーナー」仲介業者ノードは、仲介業者ノード５である。このノードが、取引きに相場（付け値）を追加することができる唯一の仲介業者ノードである。仲介業者ノードは、コンテキストまたは「相場（付け値）対象物」を生成し、正しい取引可能な製品に対するその待ち行列に分類する。
【００４４】
相場（付け値）がその待ち行列内に挿入された後で、オーナー仲介業者ノードは、他の仲介業者ノードに対して使用可能な相場（付け値）メッセージを送信することにより、ネットワーク全体に相場（付け値）を配布する。この例の場合には、仲介業者ノード５は、使用可能な相場（付け値）メッセージを仲介業者ノード２および６に送る。各仲介業者ノードは、上記メッセージを受信すると、コンテキスト（相場（付け値）対象物）を生成し、それをその待ち行列（注文記録）に分類する。各仲介業者ノードは、コンテキスト内に、どの仲介業者ノードが、それに上記メッセージを送ったのかを記録する。それを待ち行列内に挿入した後で、仲介業者ノードは、同じクリーク内に、そのメッセージを送った仲介業者と同じクリーク内に位置する仲介業者を除いて、すべての隣接仲介業者に、放送転送規則により、使用可能な相場（付け値）メッセージを送信する。それ故、仲介業者ノード２は、仲介業者ノード１、３および４に上記メッセージを送信する。その後で、仲介業者ノード４は、上記メッセージを仲介業者ノード７に送信する。この時点で、すべての仲介業者ノードは、相場（付け値）について知ることになり、それに従って、注文記録を更新する。
【００４５】
放送転送規則は、ネットワーク・トラフィックが、効率的な方法で確実に処理されるように、また、メッセージの流れのすべての重複を低減するために適用される。
【００４６】
放送規則とは下記のようなものである。
【００４７】
１．仲介業者ノード発信情報は、それをその隣接するすべての仲介業者ノードに送信される。
【００４８】
２．上記情報を受信する仲介業者ノードは、上記情報を送信した仲介業者ノードと同じクリーク内に位置する仲介業者ノードを除いて、それをその隣接するすべての仲介業者ノードに送信する。
【００４９】
３．あるメッセージが、相場（付け値）のような永続性情報を含んでいる場合には、その情報は、そこからその情報を受信した仲介業者ノードの識別子と一緒に記憶される。
【００５０】
これらの規則は、情報については言及しているが、それを含むメッセージについては言及していないことに留意されたい。例えば、相場（付け値）についての情報は、ある仲介業者ノードに対しては、提案取引メッセージにより送信され、他の仲介業者ノードに対しては、市場更新メッセージにより送信される。しかし、同じ情報は、同じ仲介業者ノードに送られ、そのため、上記規則が適用される。
【００５１】
価格配布は、取引業者端末における取引業者への市場情報供給プロセスである。この情報は、仲介業者ノードにより生成され、取引業者へ配布するために、取引エージェントに送られる。図３はこのプロセスを示す。
【００５２】
各仲介業者ノードは、相場（付け値）（注文記録）の待ち行列をチェックし、それに接続している各取引エージェントに対するその市場展望を計算する。この展望は、そのエージェントが代表する立会場用に特に構成される。展望は、クレジットおよび他の要因により異なる場合がある。市場展望を判断するための正確なプロセスは、取引商品による異なる。市場展望情報は、市場展望メッセージにより、取引エージェントに送られる。それ故、各仲介業者は、各取引業者および可能な相手方に関するクレジット情報を保持することになる。
【００５３】
ある相場（付け値）にヒットすることが、２人の取引業者の間で取引きを生成する基本的なプロセスである。ある取引業者からのヒットは、他の取引業者からの相場（付け値）と照合される。図４はこのプロセスを示す。自分の市場展望ディスプレイ上に表示されているある価格にヒットしている取引業者端末の取引エージェントは、その仲介業者ノードにヒット提出メッセージを送る。このメッセージの目標は、ある価格であって、特定の相場（付け値）ではない。この仲介業者ノードは、その相場（付け値）を走査し、そのヒットと照合することができる待ち行列内で第１の相場（付け値）を発見する。この照合規則は、取引商品により変化する場合がある。
【００５４】
そのヒットがある相場（付け値）と一致した場合には、仲介業者ノードは、その相場（付け値）に対するそのコンテキストを修正し、一致した金額を、「使用可能な取引き」から「予約係属取引き」へと移動する。そうすることにより、その相場（付け値）の同じ金額が、他のヒットと照合されるのが防止される。その後で、仲介業者ノードは、その仲介業者ノードが、そこからその相場（付け値）を受信した仲介業者ノードへ、提出取引メッセージを送信する。このメッセージの目標は、特定の相場（付け値）である。この例の場合には、ヒットは、仲介業者７に接続している取引エージェントに接続している取引業者からのものである。仲介業者７は、上記メッセージを仲介業者４に送信する。
【００５５】
各仲介業者が提案取引メッセージを受信すると、その仲介業者は、その待ち行列内の相場（付け値）をチェックする。提案された取引の金額が、待ち行列内で依然として使用できる場合には、仲介業者ノードは、仲介業者ノードの照合と類似のプロセスを実行する。提案の取引の金額は、「使用可能な取引き」から「予約係属取引き」へと移される。その後で、提案取引メッセージは、そこからその相場（付け値）を受信した仲介業者ノードに送られる。この例の場合には、仲介業者ノード４は、上記メッセージを仲介業者ノード２に送る。その後で、仲介業者ノード２は、それを仲介業者ノード５に送る。
【００５６】
提案取引メッセージの転送は、目標とする転送規則により行われる。目標とするる転送は、情報を特定の仲介業者ノードに送るために使用される。特定の仲介業者ノードの知識はシステムに組み込まれていないので、目標は特定の仲介業者ノードではなく、そこからその情報が発信された仲介業者ノードである。例えば、あるメッセージは、「仲介業者ノード７１４」には送信されないで、「仲介業者ノードで発生された相場（付け値）（クォート）４２」に送られる。目標とする規則は、下記の規則である。
【００５７】
１．特定の情報に関するメッセージを発信する仲介業者ノードは、そのメッセージを、情報ノードが、そこから元の情報を受信した仲介業者ノードに送信する。
【００５８】
２．発信しなかった特定の情報に関するメッセージを受信する仲介業者ノードは、上記メッセージを、そのノードが、そこから元の情報を受信した仲介業者ノードに送信する。
【００５９】
それ故、上記メッセージは、元の情報の経路を通ってそのソースに戻る。この例の場合には、上記経路は、仲介業者ノード７から、仲介業者ノード４および２を経由して、仲介業者ノード５に達している。
【００６０】
その相場（付け値）を最初に生成した仲介業者ノードが、提案取引メッセージを受信した場合には、上記ノードは、他の仲介業者ノードと同じチェックおよび金額留保を行う。この仲介業者ノードはその相場（付け値）を所有しているので、このノードは、その相場（付け値）を処理するために追加することができる。提案取引メッセージは、そのヒットを処理するために追加できることを表す。その後で、仲介業者ノードは、ヒット金額メッセージをその相場（付け値）を提出した取引エージェントに送ることにより、取引プロセスをスタートする。取引実行プロセスについては後で説明する。
【００６１】
取引照合プロセスが行われた場合には、各仲介業者ノードのところに維持されている相場（付け値）のリストを最新の状態に維持しなければならない。このプロセスは、図５に示すように、ある相場（付け値）を変更した場合、他の仲介業者ノードにそれを通知する各仲介業者ノードにより行われる。
【００６２】
各仲介業者ノードが、その待ち行列内のある相場（付け値）を変更した場合には、各仲介業者ノードは、それが、そこから上記変更を受信したクリーク内の仲介業者ノードを除いて、近隣のすべての仲介業者ノードに通知する。上記例の場合には、仲介業者ノード４は、提案取引メッセージにより、仲介業者ノード７から、ある待ち行列内のある変更を受信した。仲介業者ノード４は、提案取引メッセージを送って、仲介業者ノード２に通知する。仲介業者ノード４は、仲介業者ノード１および３に通知しなければならない。この通知は、これら仲介業者ノードに、市場更新メッセージを送信することにより行われる。
【００６３】
その相場（付け値）に関する情報は、通常の転送規則により、ネットワーク内の各仲介業者ノードに配布される。市場更新メッセージを受信している任意の仲介業者ノードは、それがそこから受信するクリーク内に位置していない、すべての近隣仲介業者ノードにそれを送る。提案取引メッセージを送信しているある仲介業者ノードは、同じ仲介業者ノードに、市場更新メッセージを送信してはいけないことに留意されたい。もし送信した場合には、情報がダブって受信され、取引金額が２回留保されることになる。
【００６４】
取引照合プロセスが終了すると、すでに説明したように、取引実行プロセスがスタートする。このプロセスにより取引きが完了し、ある取引きにその取引業者が付託される。図６は、このプロセスを示す。照合が行われ、取引きがスタートすると、取引業者は情報を入手することができるようになる。この情報は、取引業者に、取引きが中断中であることを知らさせために使用される。任意の所定の取引アプリケーションにより、取引業者に通知すべきか否かを判断することができる。いずれにせよ、情報を入手することができる。
【００６５】
最初の照合が行われるや否や、購入者の取引エージェント・ノードに通知が行われ、提案取引メッセージが送信される。この時点で、このエージェントは、取引業者のワークステーションに通知することができる。この取引中断情報は、照合プロセス進行中に変化することができる。メーカー（ｍａｋｅｒ）の取引エージェントが、クレジットをチェックし、取引状態メーカー・メッセージを送信した場合には、メーカーのワークステーションに通知が送られる。
【００６６】
メーカーの取引エージェントが、その仲介業者ノードからヒット金額メッセージを受信した場合には、取引実行プロセスがスタートする。このメッセージは、エージェントに、その相場（付け値）の中の１つに対して照合が行われたことを通知する。このメッセージは、相場（付け値）およびヒットの金額、相手方およびヒットの識別を識別する。エージェントはその相場（付け値）が、依然として使用することができることを確認するために、取引業者のワークステーションと一緒にチェックを行う。エージェントは、ワークステーションに対して、ヒット金額メッセージを送信する。ワークステーションは、ワークステーションが依然として動作していること、および取引業者が、もはや相場（付け値）を中断できないことを示すために、ヒット金額メッセージで応答する。この時点においては、取引業者は、もはやその取引を中断することはできない。
【００６７】
次に、取引エージェントは、相手方の使用することができるクレジットをチェックする。クレジットをチェックすることにより、その取引きをできるようにすることもできるし、その取引きの金額を少なくすることもできるし、その取引きをできないようにすることもできる。使用できるクレジットのこの減額は、将来の取引きに影響を与える恐れがある。メーカーの取引エージェントは、その仲介業者ノードに取引状態メーカー・メッセージを送ることにより、受け手（ｔａｋｅｒ）の取引エージェントに、その取引きについて知らせることができる。情報メッセージは、そのヒットを識別するためのものである。ネットワーク仲介業者ノードは、上記メッセージをヒットのオーナー仲介業者ノードに転送し、その仲介業者ノードは、それを購入者のエージェントに送る。このメッセージが送信されると、メーカーのエージェントは、ある取引きが実行されたかもしれないが、その取引きに疑惑があり、応答がまだ行われていないことを知る。受け手の取引エージェントは、取引実行プロセスを終了する。上記プロセスのこの部分は、エージェントがメーカーから取引状態メーカー・メッセージを受信したときに行われる。メッセージが取引きが有効であることを示している場合には、プロセスは続行する。
【００６８】
次に、購入者の取引エージェントは、メーカーと類似の方法により、相手方と一緒に、クレジットが使用できるかどうかをチェックする。クレジットのチェックを行うことにより、クレジットをチェックすることによりその取引きをできるようにすることもできるし、その取引きの金額を少なくすることもできるし、その取引きをできないようにすることもできる。その後で、エージェントは、その取引きに必要な金額だけ使用できるクレジットを減額する。使用できるクレジットのこの減額により、将来の取引きが影響を受ける場合がある。この段階においては、取引きが拒否される可能性は少ないことを覚えておいてほしい。何故なら、取引業者に表示された価格は、クレジットに対して予め審査したものであるからである。購入者の取引エージェントは、そのディスクにその取引きをログする。情報が永続的な記憶装置に付託されると、取引きが行われる。取引状態についての任意にチェックすれば、その取引きが拘束取引きであることがわかる。エージェントは、取引業者に通知し、取引きチケットを印刷し、任意の他の後取引処理を実行する。この時点で、取引きが行われるが、メーカーはまだそれを知らない。取引きが行われるや否や、購入者の取引エージェントは、その仲介業者ノードに取引状態受け手メッセージを送信することにより、メーカーに通知する。このメッセージは、相場（付け値）を対象としたもので、メーカーのエージェントに転送される。
【００６９】
取引状態購入者メッセージは、取引きに関する最終情報、すなわち、相場（付け値）に対する最終変更を含んでいる。この情報は、ネットワーク・仲介業者ノードおよび取引エージェントにより使用される。取引状態購入者メッセージは、仲介業者ノードを通して転送されるので、各転送仲介業者ノードは、その相場（付け値）のコンテキストを更新するために上記情報を使用する。取引金額は、「留保」から「終了」に送られる。相場（付け値）がまだ生きている場合には、実行されなかった部分は、「留保」から「使用できる」に移される。その後で、それは、ネットワーク転送規則により、他のすべてのの仲介業者ノードに、市場更新メッセージを送信することにより、他の仲介業者ノードに、変更および取引きを通知する。
【００７０】
取引状態受け手メッセージが、相場（付け値）のオーナー仲介業者ノードに到着すると、上記ノードは、それを取引エージェントに送信する。上記エージェントは、ディスクにその取引きを記録する。この時点で、取引きはハッキリとしてきている。エージェントは、取引業者に通知し、取引チケットを印刷し、必要な任意の他の処理を実行する。ある種の取引商品は、取引きのために交換する追加情報を必要とする。その一例は、ＥＢＳスポットＦ／Ｘに対する決済指定である。このタイプの情報は、取引情報メッセージにより送信される。取引きの処理が行われた後で、エージェントは、この情報を生成することができる。取引情報メッセージは、仲介業者ノードに送信される。その後で、ネットワーク仲介業者ノードは、上記メッセージを他のエージェントに転送し、そこで、上記情報は、商品の必要に応じて処理される。これで、取引きが完了する。
【００７１】
取引きが完了すると、両当事者は、初めて、その各相手方の識別を知る。上記識別は、その端末のスクリーン上に表示され、例えば、その取引セッション内で実行された取引きのリスト内に入れられ、取引チケット上に印刷され、ディスクにログされる。これらの各プロセスは、各当事者、実行した取引き、その取引きへの相手方を識別するための手段を含む。
【００７２】
上記システムでクレジットが処理される方法について、より詳細に検討する。
【００７３】
すでに説明したように、システムは、価格およびクレジットを使用する一致した取引きを審査するので、その結果、ある取引業者に表示されるすべての価格は、取引きに使用できるものでなければならない。上記の説明を読めば、このことは、各仲介業者に、クレジット決定を行うことができるだけの、十分なクレジット情報を持たなければならないことを要求することを理解することができるだろう。それは、仲介業者ノードが、通信している取引エージェントに配布する市場展望の作成を担当するからである。実際のクレジット・データは、非常に複雑なものであり、商品および指示により変化する場合がある。例えば、Ｆ／Ｘ取引システムのクレジットの概念は、簡単なものである。何故なら、スポット市場であるからである。しかし、ＦＲＡのような商品の場合には、もっと複雑である。何故なら取引きが、種々の時間にわたって行われるからである。さらに、ある種の銀行は、その取引活動の全範囲にわたって、相手方にクレジットを割り当てることを好むが、一方、ある種の銀行は、所定の金融商品に対してだけ、相手方にクレジットを割り当てることを好む。
【００７４】
上記処理を簡単なものにするために、システムは、クレジット・データの簡単なサブセットを配布し、使用する。最終クレジット権限は、全クレジット情報を持つノードが握っている。このシステムの場合には、このノードは、銀行取引エージェント・ノードであるが、これは強制的なものではなく、本発明は、クレジットが他の場所に記憶されているクレジットにも適用することができる。
【００７５】
クレジットは、立会場、相手方の立会場および取引き可能な素子の、各組合わせに対して、１つの数値を使用している。この数値の目的は、２つの立会場が、特定の素子内の取引きに対して、クレジットをもっているかどうかを判断することである。上記数値の意味は、取引き中の商品に特有なものである。例えば、スポットＦ／Ｘは、はい／いいえフラッグ（１または０）として、上記数値を使用しているが、一方、金利先渡し契約（ＦＲＡ）の場合には、ＦＲＡＢＢＤＡ／ＩＳＤＡ判断用のビットマスクとして、上記数値が使用されている。他の商品は、他の意味を持つ。クレジットは、双務的なものである。クレジットは、任意の取引活動が行われる２つの立会場の間に存在していなければならない。クレジット・チェックは、その商品により決定された所定の取引素子、または取引素子のパターンに対して行われる。システムが双務的なものであるので、仲介業者は、２つのクレジットの数値、すなわち、第１の立会場により、第２の立会場に与えられたクレジットの数値、および第２の立会場により第１の立会場に与えられたクレジットの数値を比較する。上記２つの数値が、互換性のあるものである場合には、取引動作を行うことができる。互換性という用語の意味は、その商品により決まる。スポットＦ／Ｘの場合には、その取引きに対して提案された金額は、２つのクレジットの数値の低い方より低いか、等しい場合には、取引きを進めることができる。その取引きが、低い方のクレジットの数値より大きい場合であっても、取引きを進めることはできるが、それは、低い方のクレジットの数値に等しい提案取引き金額の部分に対してだけである。
【００７６】
立会場の全クレジット情報は、ある立会場に対してクレジット権限を持つ取引エージェントに対して発信される。このエージェントは、全情報の中のそれ自身の立会場に関連する一部しか持っていない。しかし、１つ以上の立会場を一つの取引エージェントに接続することができる。クレジット情報が変更された場合には、取引エージェントは、クレジット更新メッセージをその仲介業者ノードに送信する。仲介業者ノードは、上記エージェントからの情報をその全クレジット・マトリックスと結合し、上記メッセージを上記規則に従う放送メッセージとして、近隣の仲介業者に送る。各仲介業者は、また、そこから所定の立会場に対する情報が送られてきた記録を記憶する。
【００７７】
ＷＯ９３／１５４６７号記載の先行技術のシステムの場合には、銀行ノードは、ある立会場に対するクレジット権限を保持していて、その立会場に対する取引き活動を担当する。上記取引き実行プロセスは、ローカル・クレジットと呼ばれるこのクレジット・モデルに基づいて行われる。
【００７８】
取引き実行中、取引エージェントには、潜在的な取引きが提示される。上記エージェントは、上記取引きの詳細をチェックし、その取引きを完了するには、どのくらいのクレジットが必要なのかを判断する。上記エージェントは、使用できるクレジットをチェックし、クレジットが十分でない場合には、このエージェントは、その取引きの金額を減額するか、その取引きをできないようにする。実際に必要なクレジットの金額（全額または減額した金額）は、使用できるクレジットのプールから留保される。このクレジットは、他の取引きに使用することはできない。この確保により、他の取引きに対して使用することができるクレジットが、取引きしきい値より小さくなった場合には、エージェントは、仲介業者にクレジットがもはや使用できないことを通知するために、クレジット更新メッセージを送信する。正当な方法で留保したクレジットが、留保できなくなくなった場合には、システムは、クレジットが使用できなくなったことを知らせるために、もう１つのクレジット更新メッセージを送信することができる。
【００７９】
取引きが完了すると、メーカーのエージェントは、取引き状態購入者メッセージを受け取る。その後で、購入者のエージェントは、取引きが完了したことを知る。その後で、エージェントは、その取引きにより実際に使用されたクレジットを決定する。このクレジットは、消費されたクレジットとして、クレジット・プールから除去される。もとの留保額からのすべての残りの金額は、元のプールに戻される。
【００８０】
ローカル・クレジットに対する別の方法として、銀行は、ある立会場に対してクレジット権限を保持している取引エージェントが、その立会場に対して取引き活動を行う同じエージェントでない、グローバル・クレジット・モデルを採用することができる。クレジット権限を持つエージェントは、ある立会場に対して取引き活動を行うことができるが、必ず行わなければならないわけではない。この配置により、ある機関のすべての立会場は、クレジットの共通のプールを共有することができ、ネットワーク内に、いくつかの立会場に対して、別々のクレジット・ノードを生成することができる。グローバル・クレジット関係を採用するか、またはローカル・クレジット関係を採用するかどうかの判断は、取引きシステムの外部において、参加銀行により行われる。本質的なことは、システムが、当事者間で、ローカルおよびグローバル・クレジット処理の任意の組合わせを処理することができることである。種々の可能性について以下に説明する。下記の例の場合には、機関Ａは、クレジットを機関Ｂにも適用している。
【００８１】
＜例１．ローカル−グローバル＞
この場合、機関Ａは、ローカル・クレジット制度の下で動作し、機関Ｂは、グローバルなクレジット制度の下で動作する。それ故、各立会場または機関Ａは、機関Ｂ内のすべての立会場との取引きに対して、クレジット限度を設定しなければならない。
【００８２】
機関Ａ 機関Ｂ
サイト１ サイト１
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例１．ローカル−グローバル
ローカル−グローバル関係は、上記の現在の匿名取引システムの普通な関係である。その１つの理由は、これらのシステムの場合には、機関は、個々の立会場と、それにより取引きをしたい各相手方との間に、クレジット限度を割り当てなければならないという制限があるからである。そのため、いくつかの銀行は、先行技術のシステムの柔軟性を持たない要件に一致させるために、このグループ分けの関係に基づいて、スポットＦＸクレジット・ラインを割り当てることになる。他の銀行は、そのクレジットの一部を将来のためにとっておいて、純粋に、匿名システム上での取引きのために、ローカル−グローバル・クレジットによりそれを割り当てる。上記銀行は、その残りの営業活動に対して他のクレジット関係を使用する。
【００８３】
＜例２．グローバル−グローバル＞
このモデルの場合には、機関Ａは、機関Ｂのすべての立会場に対して、そのすべての立会場に対するクレジットを適用する。このことは、機関Ａの任意の所定の立会場が、機関Ｂとすることができる取引き金額が、機関Ａの他の立会場が行った機関Ｂとの取引き金額により影響を受けることを意味する。
【００８４】
機関Ａ 機関Ｂ
サイト１ サイト１
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例２．グローバル−グローバル
グローバル−グローバル・クレジット関係は、最も基本的または基礎的なタイプである。
【００８５】
＜例３．グローバル−ローカル＞
このモデルの場合には、機関Ａの全体が、クレジットの結合ラインを機関Ｂの個々の立会場に適用する。このタイプは、機関Ａが、クレジットの長いラインを適用するのを嫌がる１つの特定の立会場があり、機関Ｂは同じ程度に信頼に値しないと考える場合に適している。別な場合としては、その内部に立会場が位置している国を特定のケースと見なす必要がある場合、または立会場が、機関Ｂ内に適当な法的状態をもつことができない場合がある。
【００８６】
機関Ａ 機関Ｂ
サイト１ サイト１
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例３．グローバル−ローカル
＜例４．ローカル−ローカル＞
ある状況の場合、機関Ａは、個々の立会場が、クレジット・ラインを機関Ｂの個々の立会場に、適用することを許可することができる。このようなことは、例えば、新しく出現中の市場、またはその国内の機関Ａの支店からだけ、その国内の機関Ｂの支店に対する取引きが行われる外国の場合に起こる。通常、機関Ａと機関Ｂのこれら支店との間に、他の相互作用は行われない。
【００８７】
機関Ａ 機関Ｂ
サイト２ サイト２
サイト３ サイト３
サイト４ サイト４
例４．ローカル−ローカル
相手方とのクレジット限度を設定する場合には、機関は、最初にクレジット関係を定義し、その後で、そのクレジット関係に従って、クレジットを割り当てなければならない。このようなグループ分けは中央で行うことができる。通常のクレジット・グループ分けは、下記の通りである。
【表１】
上記表１内においては、機関Ａは、それ自身のサイトの三つのグループ、および機関Ｂのサイトの三つのグループを形成した。機関Ａのグループは下記の通りである。
グループ１ サイト１
グループ２ サイト２
グループ３ サイト３および４
サイト１ サイト１
機関Ｂのグループは、下記の通りである。
グループ１ サイト１
グループ２ サイト２および３
グループ３ サイト４。
【００８９】
割り当てられたクレジット限度は、グループ関係に基づいている。それ故、グループＡ３は、＄１５ＭのクレジットをグループＢ２に適用し、＄１２ＭのクレジットをグループＢ３に適用する。表１は、下記表のように表示することもできる。
【表２】
それ故、グループＡ３およびＢ３は、１つ以上の立会場からできていて、クレジットの１つのプールを共有する。表示のグループ関係は、ローカル・クレジット・モデルとグローバル・クレジット・モデルのハイブリッドであることを理解することができるだろう。機関Ａおよび機関Ｂとの間の関係の場合、複数のローカル−グローバル・タイプの関係が存在する場合がある。それ故、グループＡ３およびグループＢ２は、主要な取引き諸国内のすべての立会場を表すことができる。これらのグループの間の関係は、本質的には、グローバル−グローバル・タイプである。一方、グループＡ１とＢ１またはＢ４との間の関係は、ローカル−ローカル・タイプであり、グループＡ１またはＡ２とＢ２との間の関係は、ローカル−グローバル・タイプであり、グループＡ３およびＢ１またはＢ３との間の関係は、グローバル−ローカル・タイプである。他の関係も存在する。
【００９１】
上記の説明は、機関Ａと機関Ｂとの間の関係である。２つの機関の間の関係内には種々の関係が存在する場合がある。グループの形成に関連する流れは、下記の要因により異なる。
【００９２】
１．機関サイトのグループ分け、このグループ分けは下記により行うことができる。
ａ．集中型 − 本社が、そのサイトに対するすべてのグループを定義するか、または代理サイトにすべてのグループの定義をまかせる。
ｂ．分散型 − 本社が、いくつかの主要なサイトをおよび他のサイトの、グループ分けを担当するいくつかの主要サイトを定義する。例えば、ヨーロッパのサイトはロンドンから、米国のサイトはニューヨークからグループ分けすることができる。サイトをグループ分けする権限は、地理および／または法的状態に基づくことができる。分散型システムの場合には、いくつかのグループ分けを依然として中央で行うことができる。例えば、所定のローカル・センターは、中央による処理されるある種の法的状態を除いて、所定の地理的領域内のすべてのサイトをグループ分けすることができる。
【００９３】
２．クレジット限度を定義するための権限の付与
この権限の付与は、下記のように行うことができる。
ａ．中央処理タイプ
ｂ．分散タイプ
その機関自身のサイトのグループ分けと同じ方法による付与。
【００９４】
３．相手方をグループ分けしなければならない。この場合も、このグループ分けは、機関自身のサイトのグループ分けと同じ方法で、行うことができる。これた三つの決定は、同じ方法で行う必要はない。
【００９５】
２つの機関の間には、完全なグローバル−グローバル関係が存在することができる。これらすべての意志決定は、中央で行われる。この場合、表１および表２のクレジットのグループ分けは、下記表のようになる。
【表３】
上記説明は、例えば、Ｆ／Ｘスポット取引きのためのクレジットの割当てのような、取引きする所定の金融商品に対する銀行のクレジットの割当てに関連する。所定の機関自身の内部クレジット・システムの性質により、上記クレジット関係は、他の匿名システム、音声仲介業者および会話型取引きシステムを含む、すべての可能な方法により取引きを行っている商品に対するその機関のクレジット限度とインターフェースしなければならない場合がある。他のまたは別な方法としては、その取引き活動の範囲を通して、相手方の機関にクレジットを割り当てるある機関のグローバルなクレジット機構とインターフェースしなければならない場合もある。このようなシステムは、必ず非常に複雑なものである。何故なら、クレジットの観念が、取引きを行っているある商品が、長期間にわたるクレジットを必要とする場合には変化するからである。
【００９７】
図１−図７のシステムでのグローバル・クレジットの処理に戻って説明する。グローバルなタイプのクレジット協定に対する取引き実行プロセスは、上記のローカル・クレジット例より複雑であることを理解することができるだろう。
【００９８】
機関の間の関係は、単一のものでなく、ハイブリッドな関係もありうる。例えば、下記の表４は、２つの機関の間の混合型のグローバル−グローバル関係、およびグローバル−ローカル関係を示す。
【表４】
この関係の場合には、本社は、それ自身のグループ分け、相手方のグループ分け、およびクレジット・ラインを決定する。しかし、機関Ｂの子会社は、その機関の残りとは別にクレジットが与えられる。
【０１００】
下記の表５の場合には、機関Ａは、相手方の立会場に対してローカル−ローカル関係を維持し、依然としてグローバルなベースで、相手方の大部分の立会場にクレジットを割り当てる。それ故、サイト１、すなわち、機関Ａの本社は、それ自身のグループ分け、相手方のグループ分け、およびサイト１からサイト４へのクレジット・ラインを決定するが、外国の場所である場合があるサイト５は、機関Ｂのサイト４に対して、ローカル−ローカルな関係を持つ。機関Ａのサイト５は、機関Ｂのサイト４へのクレジット・ラインを決定する。
【表５】
ローカル−グローバルな関係は、同じグローバルな相手方へのその各立会場に対して、異なるクレジット・ライン場を持つことができる。厳密にいえば、これは、組合わせではなく、それを下記表６に示す。サイト１、すなわち、本社は、それ自身のグループ分け、相手方のグループ分けを決定するが、各サイトは、クレジット・ラインを管理する（ラインそれ自身は、本社で決定することができる）。
【表６】
図８は、グローバル・クレジットにおける取引実行の際のクレジット・メッセージの流れを示す。
【０１０３】
クレジット配分プロセスは、クレジット情報がこの場合もすべての仲介業者に配布されるという点でローカル・クレジットの例と同じである。どの仲介業者も情報の発信元を知っており、クレジット認可権限を持った取引エージェントにメッセージを送り返すことができる。
【０１０４】
図８の例では、メーカー取引エージェント１００および購入者取引エージェント１０２は自らの立会場のクレジット認可権限を持たない。したがって、認可権限を持った２人の取引エージェント１２０、１３０によってクレジットは確認されなくてはならない。これらエージェントは、メーカー・クレジット・エージェントおよび購入者クレジット・エージェントと称されることもある。
【０１０５】
メーカー取引エージェント１００が取引を処理する際、まずは上記の説明と同じやりかたで相場（付け値）が依然として利用可能であることを調べ、ディーラーにこれから行う取引について通知する。ただし、クレジット・ポジションそのものを調べることはできないため、取引き状態メーカー・メッセージそのものを送ることはしない。その代わり、取引きクレジット・メーカー・メッセージ１４０が取引エージェントが付いている仲介業者１５０に送られる。仲介業者１５０は取引きクレジット・メーカー・メッセージ１４０を、取引エージェント１００が取引活動を行っている立会場のクレジット情報の発信元であるメーカー・クレジット・エージェント１２０に送る。メーカー・クレジット・エージェント１２０は上記説明の通りにクレジット調査を実施した後に、仲介業者１７０に取引き状態メーカー・メッセージ１６０を送る。
【０１０６】
取引き状態メーカー・メッセージ１６０は仲介業者１７０によって、購入者取引エージェントにではなく、購入者のクレジットの発信元に送られる。この場合、この２つは同一ではなく、取引き状態メーカー・メッセージは購入者クレジット・エージェント１３０に送られる。続いて購入者クレジット・エージェント１３０が上記説明の通りにクレジット調査を行い、購入者クレジット・エージェントが接続される仲介業者１９０に取引きクレジット購入者メッセージ１８０を送る。購入者取引エージェントが立会場のクレジット情報を持っている場合、取引きクレジット購入者メッセージ１８０は不要である。
【０１０７】
取引きクレジット購入者メッセージ１８０は、上記説明の経路指定規則を使用して、仲介業者の手によって最初のヒットの発信元に送られる。
【０１０８】
取引を最初に提案した取引エージェント１１０が取引きクレジット購入者メッセージ１８０を受け取ると、取引は成立し、購入者取引エージェントで記録され、取引実行処理は上記図６の際に説明したのと同じように実施される。
【０１０９】
メーカー・クレジット・エージェント１２０および購入者クレジット・エージェント１３０は、ローカル・クレジットの例で説明したのと同様にクレジット予約を実施する。メーカー・クレジット・エージェントは取引きクレジット・メーカー・メッセージを受け取るとクレジットを予約し、購入者クレジット・エージェントは取引き状態メーカー・メッセージ１６０を受け取るとクレジットを予約する。クレジットの消費は、メーカー・クレジット・エージェント１２０および購入者クレジット・エージェント１３０とが取引き状態購入者メッセージ１８０を購入者取引エージェント１０２から受け取った後に実施される。
【０１１０】
信頼性およびパフォーマンスを向上するためには、２人以上の取引エージェントが立会場のクレジット認可権限を持つことが望ましい。このような場合、これらクレジット・エージェントであれば誰でも取引を確認することができる。相互に情報をやりとりし、互いにクレジットのプールを適正に保つのはこれらエージェントの責任である。このプロセスは証券や機関に特化したものである。各仲介業者は同じ立会場から複数のクレジット更新メッセージを受け取る。仲介業者はどのメッセージを受け入れるかを決定しなければならない。仲介業者は発信元の最も近いメッセージを決定するために「ホップカウント」を調べる。ホップカウントの高いメッセージは処理されず、送られない。
【０１１１】
立会場や機関のクレジット・エージェントは利用可能なクレジットのプールを維持し、クレジットが利用されたり、回復した際にクレジット情報を調整する。これを行う方法は機関、および取り引きされる商品の両方に特化されたものである。
【０１１２】
銀行がクレジットに関してグローバルな取り組みをするのは、取引の柔軟性を増すためである。銀行が、様々な当事者に対してあらかじめ割り当てられたクレジット量を持つ複数の立会場からなる場合、一部の立会場ではクレジット限度まで取引が進む一方、その他はそこまで進んでいないという状況も考えられる。クレジット限度までいった立会場は、所定の当事者との銀行の全体取引限度内で取引を最大化するために、他の立会場の未利用のクレジットを利用できるのが望ましい。この全体取引限度は１つの取引商品に限られるのではなく、銀行の活動の全体を網羅し、匿名電子システム上で取り引きできるものと、そうでないものとが含まれることも考えられる。
【０１１３】
ここで説明するシステムが、ローカル−グローバル型のクレジット関係をどのようにも組み合わせることができるということを理解されたい。これによって、機関は他の取引作業同様に匿名取引システムを利用して取引作業にクレジットを割り当てられるようになる。これによって適当とされる場合には、先行技術に基づくシステムに比べてクレジットの扱いをより柔軟にすることができる。また、これによって機関はそのクレジット限度まで取引を進める機会を増やし、したがって、取引活動による利益を最大化することができる。
【０１１４】
クレジット限度関係は、特に仲介業者ノードからなるネットワークを利用するシステムに関して解説した。本発明のこの態様は、当事者間で双務的クレジット限度を割り当てるどのようなシステムにも同じように適応できることを理解されたい。このようなシステムには上記ＥＰ−Ａ−０，３９９，８５０号、ＥＰ−Ａ−０，４０６，０２６号、ＥＰ−Ａ−０，４１１，７４８号、およびＷＯ９３／１５４６７号が含まれる。
【０１１５】
図９−図１１は、本発明の第２の実施形態を示す。上記実施形態では、クレジットをグローバルに取り扱う場合に、各立会場はクレジット限度を扱うためにクレジット・エージェントを利用する。この方法では、クレジット予約を可能にするために追加メッセージングや別々のコンピュータが必要となるため、パフォーマンス面で不利になる可能性がある。取引を成立させるには、情報のやりとりに少なくとも４台のコンピュータ、取引エージェントおよびクレジット・エージェントがそれぞれ２人必要となり、完了時間を大幅に長引かせることが考えられる。
【０１１６】
この状況は、合致するエンジンを持った１人または複数のクレジット仲介業者を割り当てることで回避することができる。クレジット仲介業者はグローバルなクレジットを扱えるように構成された機関のためにクレジット予約を実施し、上記実施形態とは異なり、取引の両側のクレジット調査を行うことができる。
【０１１７】
図９は、当申請者の既存の旧来システムを変更してクレジット仲介業者を盛り込む方法を示す。既存システムは、ＷＯ９３／１５４６７号でのその全容が解説されており、これを参照することが望ましい。照合および取引の実行は、世界各地にいる３人の調停者２００のうち１人が行う。調停者２００はニューヨークに１人、ロンドンに１人、東京に１人いる。調停者２００は、銀行ノードを介して立会場２２０に配布するための市況概況を作成する市場配給業者２１０に接続される。ある立会場の実際の市況概況は、システム内に相場（付け値）を持つ様々な当事者とのクレジット限度によって異なる。
【０１１８】
クレジット仲介業者２３０は調停者の横に置かれ、１人の調停者２００に対してクレジット仲介業者２３０が１人いる。取引完了時間への影響を最小限にとどめるために、クレジット仲介業者は高速ＬＡＮによって調停者に接続される。
【０１１９】
ＷＯ９３／１５４６７号で解説する現在のシステムでは、取引を完了させるうえで３人の調停者のうち誰が活動状態にあっても構わない。特定の銀行のクレジット情報を持つクレジット仲介業者が、取引を開始する調停者に最も近いことが望ましい。これは最も活動の多い調停者にクレジット情報を移動させる予測アルゴリズムによって実現することができる。それ故、クレジットの詳細は１人のクレジット仲介業者内の特定機関について固定されるのではなく、動き回ることになる。実際には、一日の活動を通じて、各国の市場が開始、終了することによって最も活動の多い調停者の位置は変化していく。
【０１２０】
各クレジット仲介業者は、ＷＯ９３／１５４６７号のシステム内の立会場の銀行ノードが提供するのと同じクレジット情報を、ローカルの調停者に提供する。クレジット仲介業者はグローバル・クレジットに参加するすべての立会場のためにクレジット情報を提供する。クレジット割り当てが完全に利用されたり、クレジット管理者によって変更される都度、調停者には新しいクレジット情報が提供される。
【０１２１】
図９は、取引完了、およびクレジット予約プロセスにおける各種メッセージの流れを示す。まずクレジット予約を見ると、メーカー・ワークステーション２４０が入札またはオファーを行うと、そのワークステーションは相場（付け値）提出ＷＳメッセージ３００をその銀行ノード２２０に送る。このメッセージはメーカーによる匿名取引システムへの相場（付け値）の提出である。銀行ノードはこの相場（付け値）を認証し、相場（付け値）リストの中で相場（付け値）コンテキストを作成し、相場（付け値）を相場（付け値）提出メッセージ３０２に入れて調停者に送る。
【０１２２】
メーカー調停者２００はこの相場（付け値）を認証し、メーカーの銀行ノードに受取通知メッセージ相場（付け値）提出受信通知３０４を送る。銀行ノードはこの相場（付け値）を受け入れるか、拒絶する。例えば、相場（付け値）額などのような詳細が欠落している場合、相場（付け値）が拒絶される場合がある。
【０１２３】
メーカーの銀行ノードが相場（付け値）提出受信通知メッセージ３０２を受信すると、そのノードは相場（付け値）が拒絶されたかどうかを調べる。拒絶されている場合、メーカー・ワークステーションに相場（付け値）ＣｘｒｅｄＷＳメッセージ（図示せず）を、調停者に相場（付け値）割込みメッセージを送る。次に相場（付け値）リストから相場（付け値）コンテキストを取り除く。
【０１２４】
相場（付け値）が調停者に受け入れられた場合、メーカー調停者は使用可能な相場（付け値）メッセージ３０６をすべてのローカル・市場配給業者（図示せず）、およびその他すべての調停者に送る。この時点で、相場（付け値）はローカル・メーカーからの売り要求、他の調停者からのヒットの標的となり、もしくは調停者がシステム内の他の相場（付け値）との照合を自動的に行うａｕｔｏｍａｔｃｈに参加することもできる。
【０１２５】
購入者がワークステーション画面に表示されるメーカーの相場（付け値）をヒットする場合、そのワークステーションはＷＮ＿ヒット提出ＷＳメッセージ３０８をその銀行ノードに送る。銀行ノードはそれに応えてＮＡ＿ヒット提出メッセージ３１０をその調停者２００に送る。受け手調停者はこのヒット提出メッセージをメーカー調停者にヒット相場（付け値）メッセージ３０９として流し、調停者はヒット相場（付け値）受信通知メッセージ３１１でその受け取りを通知する。
【０１２６】
次に調停者は適合する相場（付け値）を選び、固有の取引識別名を作成し、ＡＮ＿ヒット通知メッセージ３１２をメーカーの銀行ノードに送る。これは購入者によるそのヒットに対する応答である場合と、購入者が提出した相場（付け値）のａｕｔｏｍａｔｃｈの結果である場合とがある。同時に、メーカー調停者２００はメーカーと受け手の銀行ノードの両方に成り代わりクレジット仲介業者に対してクレジット予約を開始する。クレジット仲介業者は、上記実施形態のクレジット・エージェントとは違って取引の双方のクレジットを取り扱うということを理解することが重要である。
【０１２７】
メーカーの銀行ノードがＮＷ＿ヒット金額３１４メッセージをメーカー・ワークステーションに送り、その取引に関わる相場（付け値）の存在を確認する。その相場（付け値）が取引業者によって割込みされていない場合、取引業者はこれから行おうとする取引について通知を受け、これから行おうとするこの取引に関係する相場（付け値）の部分をもはや割込みすることはできない。メーカー・ワークステーションはＷＮ＿ヒット金額受信通知メッセージ３１６を銀行ノードに送り返し、ヒット金額メッセージの受け取りを通知する。相場（付け値）が割込みされた場合、銀行ノードは取引を取り消し、ＮＡ＿取引不成功メッセージ（図示せず）を調停者に送り返す。
【０１２８】
相場（付け値）が割込みされていないことを前提にすると、メーカーの銀行ノードはこれから行おうとする取引を割り当てレコードとして取引業者データベースに記録し、取引状態を「不確か」として表示する。次に、取引を確認するために、銀行ノードは取引き確認メッセージ３２０をその調停者２００に送る。
【０１２９】
その前にクレジット予約を開始している調停者は、クレジット予約の結果を待つ。それをクレジット仲介業者２３０から受け取ると、取引き確認メッセージ３２０が取引金額を伴って受け手調停者２００に送られる。この額は、取引の一部だけを完了するクレジットしかない場合と、取引金額全額に満たない場合とがある。取引確認メッセージは受け手銀行ノードに送られ、受け手銀行ノードは、これから行おうとする取引のリスト中に取引のためのコンテキストを作成する。次にこの取引を取引データベースに記録し、取引状態が確認された状態での取引レコードを作成する。取引には固有のチケット番号が割り当てられ、取引の取引監査が作成される。次に受け手銀行ノードはＮＡ＿取引き状態購入者メッセージ３２２を受け手調停者に送り、最終取引金額を伴ってＮＷ＿取引き状態ＷＳ＿購入者メッセージ３２４を受け手ワークステーションに送る。
【０１３０】
次に、受け手調停者は、取引き確認メッセージ３２０の受け取りを通知するために取引き確認受信通知メッセージ３２６をメーカー調停者に送る。メーカー調停者は受取通知メッセージをメーカー銀行ノードに流す。このメッセージを受け取ると、メーカーの銀行ノードはその取引データベース内の取引状態を「コミットしている」に変更し、取引にチケット番号を割り当てる。次に、調停者にＮＡ＿取引き状態メーカー・メッセージ３２８、メーカー・ワークステーションに最終取引金額を伴ってＮＷ＿取引き状態ＷＳメーカー・メッセージ３３０を送る。これら２つのメッセージはメーカー・ワークステーションと調停者に対して取引状態の変更を確認するものである。
【０１３１】
メーカーの銀行ノードは次に商品メーカー・メッセージ３３２をその調停者に送る。このメッセージには決済に関する指示が含まれている。このメッセージは受け手調停者に、次いで受け手の銀行ノードに送られ、ここで決済に関する指示が取引データベースに記録される。取引状態は「決済済み」に変更される。取引に順番号が割り当てられ、取引チケットが印刷される。次に受け手の銀行ノードが、受け手の決済に関する指示を含んだ商品購入者メッセージ３３４をその調停者に送る。このメッセージは、２人の調停者を介してメーカーの銀行ノードに送られる。また、受け手の銀行ノードも、取引の完了作業を実施し、取引業者に取引が記録されたことを通知している受け手ワークステーションにＮＷ−ＬｏｇｇｅｄＷＳ購入者メッセージ３３６を送る。
【０１３２】
メーカー銀行ノードで商品購入者メッセージが受領されると、決済に関する指示が取引データベースに記録され、取引状態が「決済済み」に変更される。受け手銀行ノード同様、順番号が割り当てられ、取引チケットが印刷される。次にメーカー銀行ノードがＮＷ＿商品のログＷＳメーカー・メッセージ３３８を、メーカー・ワークステーションに送り取引を完了させる。
【０１３３】
以下の説明は、上記の取引実行プロセスにおけるクレジット仲介業者の作業に関する。
【０１３４】
上記説明では、メーカーの調停者が、ＡＮ＿ヒット通知メッセージがメーカー銀行ノードに送られたときにクレジット予約を開始する。このクレジット予約は取引の当事者の一方だけがグローバル・クレジットに参加している場合に実施される。その場合、メーカー調停者はＡＣ＿クレジットの留保メッセージ３４０をクレジット仲介業者２１０に送る。この予約クレジット・メッセージには取引識別名、これから行おうとする取引の金額、取引がＦＸスポットの場合は通貨対識別名、そうでない場合はこれ以外の商品識別名、ならびにメーカーと購入者の立会場の名称が含まれる。後者は「フロアキー」と呼ばれるものである。
【０１３５】
メーカーの立会場がグローバル・クレジットに参加している場合、クレジット仲介業者でのクレジット調査は継続され、さもなくばメーカーのクレジット予約はメーカー側のクレジット調査を完了させるために状態は「メーカーが不確か」となり、購入者のクレジット調査が継続される。
【０１３６】
メーカーがグローバル・クレジットに参加しているものとすると、クレジット仲介業者はまずメーカーの立会場を含む授与者グループを解散する。被授与者はフロアキーを使用して授与者グループから解散される。これにより、これから行おうとする取引のために利用する割り当て分が提供される。取引金額は割り当て分に関連するクレジット限度通貨という点でクレジット利用に換算される。
【０１３７】
ある割り当て内で利用可能な総クレジットは、取引に必要な額と比較される。最少規模の取引に必要なクレジットが得られない場合、予約プロセスは中断され、ＣＡ＿クレジット受信通知の留保メッセージ３４２が調停者に送られ、利用可能なクレジットが使い果たされたことを知らせる。
【０１３８】
クレジット仲介業者が購入者の予約も処理している場合、つまり購入者の機関がグローバル・クレジットに参加している場合、市場のクレジットはメッセージを送る前に振り出される。充分なクレジットがあるものの、その額が提案されている取引の金額に満たない場合、取引金額と予約額が減額される。
【０１３９】
総クレジット額が充分である場合、仲介業者が、予約を完了するのに物理的に充分なクレジットをローカル・クレジット仲介業者のところに持っているかどうかを特定する。そうである場合、仲介業者は利用額を、その割り当てに対する総利用に加算し、ＣＡ＿クレジット受信通知の留保メッセージ３４２にメーカーが取引金額で予約しているものとしてマークを付ける。次に、そのクレジット仲介業者が購入者クレジットを同様に処理する。
【０１４０】
総クレジット額が充分なものの、仲介業者が、予約を完了するのに物理的に充分なクレジットをローカル・クレジット仲介業者のところに持たない場合、遠隔の適切なクレジット仲介業者に予約の完了を依頼しなければならない。これは物理的な割り当てを持っていると思われるクレジット仲介業者にＣＣ＿遠隔クレジットの留保メッセージ３４４を送ることで実施する。このメッセージには依頼番号、授与者と被授与者のフロアキー、割り当て識別名、および予約額が含まれる。図１０は、２人のクレジット仲介業者が関与する状況を示す。ここではメーカー調停者が２００、発信元クレジット仲介業者、つまり図９のクレジット仲介業者は２３０（ａ）となっている。第２のクレジット仲介業者は２３０（ｂ）となっており、それに関連する調停者は示されていない。
【０１４１】
ＣＣ＿遠隔クレジットの留保メッセージ３４４を受け取ったクレジット仲介業者は自分のローカル割り当てを調べる。その予約に対応できる場合はその額が予約される。対応できない場合、受け取り側のクレジット仲介業者が利用可能な総クレジット額を調べ、依頼が不成功に終わったことを知らせるＣＣ＿遠隔クレジット受信通知の留保メッセージ３４６でその依頼を拒否するか、依頼を第３のクレジット仲介業者に転送する。ＷＯ９３／１５４６７号のアーキテクチャに基づくシステムでは、クレジット仲介業者は３人、各調停者につき１人いることを思い返されたい。
【０１４２】
発信元のクレジット仲介業者が受け取ったＣＣ＿遠隔クレジット受信通知の留保メッセージ３４６がクレジットが予約されたことを示していれば、購入者側の予約処理を行う。これが成功裏に完了すると、これから行おうとする取引のための額が成功裏に予約されたことを知らせるＣＡ＿遠隔クレジットの留保メッセージ３４２が依頼調停者２００に送られる。
【０１４３】
調停者は、いつ取引が確認されたかをクレジット仲介業者２１０に知らせる必要がある。これによってクレジット仲介業者は予約額を最終決定することができ、遠隔クレジット仲介業者が関与している場合、割り当てが利用されたことを遠隔クレジット仲介業者に通知することができる。これは調停者からクレジット仲介業者に宛てたＡＣ＿取引き状態メッセージ３４８で行う。クレジット仲介業者は、取引状態メッセージで取引の最終状態を知る。取引が不成功の場合、クレジット予約は元通りに戻される。成功の場合、遠隔クレジット仲介業者が関与していれば、遠隔クレジット仲介業者はＣＣ＿留保の完了メッセージ３５０によってクレジットが利用された旨の通知を受ける。このメッセージには割り当て識別名、および割り当てに対して確認された額が含まれる。これによってクレジット仲介業者は総割り当ての運用可能残高を正確に把握することができる。
【０１４４】
遠隔クレジット仲介業者２３０（ｂ）は予約完了メッセージ３５０を受け取ると、ローカルで持つ割り当てのどれかを他のクレジット仲介業者に転送するべきかどうかを判断する。この判断は各クレジット仲介業者によって最近処理された予約依頼の数、利用可能な総割り当て、および各クレジット仲介業者において利用可能なローカル割り当てに基づく。１人の仲介業者が他の仲介業者に割り当てを転送する場合、すべてのクレジット仲介業者にＣＦＣ＿割当て転送メッセージ３５２を送る。このメッセージには譲渡と受取仲介業者の両方の名称、ならびに転送額が含まれる。このメッセージによって割り当ては最も必要とされる場所に転送されると同時に、仲介業者は利用可能な割り当てがどこにあるかを正確に把握することができる。クレジット調査を実施する際のメッセージの数が減り、取引を取りまとめる調停者の近くでクレジット調査が行われるようになることであることを理解されたい。いずれの要素も取引完了プロセスの迅速化に貢献する。
【０１４５】
図９および図１０に関する上記解説は、ＷＯ９３／１５４６７号のアーキテクチャへのグローバル・クレジット、またはグローバル／ローカル、ローカル／グローバル・クレジット制度の導入方法を示したものである。ただし、ここで説明する原理はクレジット調査を必要とするどのような匿名取引システムにも応用することができる。例えば、図１から図７の仲介業者ノード型分散システムから、調停者と仲介業者ノードを組み合わせたハイブリッド・システムにも同様に応用することができる。
【０１４６】
図１１は、調停者２００が市場配給業者４０、およびそれぞれがローカル・クレジット制度ＬＣ２５０を運用する相互接続されたいくつかの銀行ノードによって保持されているハイブリッド・モデルを示す。
【０１４７】
取引業者ワークステーションＷＳと立会場管理者ワークステーションＴＦＡ ＷＳは、仲介業者のプラットフォームＡＰＩを介して銀行ノードと通信する。これによって立会場管理者がクレジット仲介業者のところに保存されるクレジット限度を変更することができる。図１から図７で説明する種類の仲介業者も調停者と組を成す。仲介業者は以前は銀行ノード、および市場配給業者が取り扱っていた機能を果たし、この中には取引業者ワークステーションに配分クレジットでフィルターをかけて市況概況を取引業者ワークステーションに配布する機能が含まれる。仲介業者ノードはゲートウェイを介して調停者を通信し、ワークステーションは仲介業者のプラットフォームＡＰを介して仲介業者ノードを通信する。仲介業者ノードには、取引の一方がグローバル・クレジットを、もう一方がローカル・クレジットを利用している取引が行われているクレジット仲介業者と通信するローカル・クレジット・モジュールが含まれることもある。ローカル・クレジット・モジュールは、管理者が保存されているクレジット限度を変更できるように、立会場管理者ワークステーションＴＦＡ ＷＳでアクセスすることができる。
【０１４８】
純粋な仲介業者ノード実行の場合には、クレジット仲介業者の機能が、各仲介業者ノードに内蔵されるということを除いて、アーキテクチャは、図１−図７に示すようになる。それ故、ＷＯ９３／１５４６７号の類推により、各仲介業者ノードは、取引の照合および実行を含む、銀行ノード、市場配給業者、調停者の機能、およびグローバル・クレジット仲介業者の機能を行う。仲介業者は、上記のクリーク・ツリー構造体により、相互に接続していて、取引業者のワークステーションは、仲介業者のプラットフォームを通して、仲介業者ノードに接続している。
【０１４９】
上記説明において、ローカル・クレジットは、１つの立会場に割り当てられたクレジットを単に参照する必要はなく、例えば、１つの地理的領域をカバーしている多数の立会場にクレジットが割り当てられる地域的クレジットを含むことができる。同様に、グローバル・クレジットの概念は、厳密に、機関の階層内の最高の点を意味する必要はなく、地域的なものであってもよい。一例を挙げると、グローバルなクレジットは、ローカル・クレジット・レベルとして処理されている各国内の個々の立会場と取引きをしているある機関のヨーロッパの立会場を意味することもできる。
【０１５０】
上記の配置に対する他の種々の修正および別の配置が可能であり、当業者であれば、それらに思い付くことができるだろう。そのような変更および修正は、すべて添付の特許請求の範囲によってだけ定義される、本発明の精神および範囲内に含まれる。
【図面の簡単な説明】
【図１】本発明の第１の機能を実行する取引システムの全体図である。
【図２】システムで新しい相場（付け値）が提出された場合の、図１のシステムでのメッセージの流れを示す。
【図３】図１のシステムでの取引業者に対する市場展望の作成を示す。
【図４】取引業者が買い注文または売り注文を出した場合の、図１のシステムでのメッセージの流れを示す。
【図５】買い注文または売り注文を出した後での、仲介業者ノードを更新するためのメッセージの流れを示す。
【図６】仲介業者が相場（付け値）を修正した場合の、メッセージの流れを示す。
【図７】取引実行プロセスを示す。
【図８】グローバル・クレジット・モデルでのメッセージの流れを示す。
【図９】本発明の第２の機能を実行する取引システムの一部の簡単なアーキテクチャである。
【図１０】図９のシステム内のもう１人のクレジット仲介業者の使用を示す。
【図１１】仲介業者、仲介ノード、グローバルおよびローカル・クレジットの組合わせを使用するハイブリッド・システムである。
Claims (33)
- 取引者間で商品を取引きするための匿名取引システムであって、
電子メッセージを送信するための通信ネットワークと、
前記通信ネットワークに接続している複数の注文入力デバイスであって、そのそれぞれが、入札注文および／またはオファー注文を含む、電子注文メッセージを作成し、前記ネットワークを通して、前記複数の注文入力デバイスの他のデバイスから受信した取引者の注文情報を通信する複数の注文入力デバイスと、
前記ネットワークに接続しており、取引者端末から前記システムに入力した入札注文およびオファー注文を照合し、注文が一致した場合に、取引きの実行を助ける少なくとも１つの照合エンジンと、
前記取引者端末に注文メッセージを配布するために、前記ネットワークを接続していて、前記注文メッセージおよび前記照合エンジンに応答する市場配給手段と、
取引フロアまたは取引フロアのグループ、および可能な相手方の取引フロアまたは取引フロアのグループの間の取引きに対して、使用することができるクレジット限度を記憶するためのものであって、論理的に別々の取引フロアのグループに対するクレジットを記憶するための、少なくとも１つのクレジット・エージェント・ノードを備えるクレジット限度記憶手段とを備える匿名取引システム。 - 請求項１記載の匿名取引システムにおいて、所定の取引フロアに対する前記注文入力デバイスが、前記通信ネットワークに接続している取引エージェント・ノードに接続していて、クレジット・エージェント・ノードが、複数の取引エージェントに接続している取引フロアに対するクレジット限度を記憶する匿名取引システム。
- 請求項２記載の匿名取引システムにおいて、前記取引エージェント・ノードが、接続している取引フロアを持ち、そのクレジット限度が、前記クレジット・エージェント・ノードに記憶されていて、各取引エージェント・ノードが、前記接続している注文入力デバイスの中の１つからの入札または他の入力が一致したというメッセージを受信した場合に、前記クレジット・エージェント・ノードに、クレジット問合わせメッセージを送るための手段を備え、前記クレジット・エージェント・ノードが、それがクレジット限度を記憶している、その接続している取引フロアに対する前記各取引エージェント・ノードからのクレジット問合わせメッセージを記憶するための手段と、クレジット問合わせメッセージを受信した場合に、記憶しているクレジット限度に対して、提案の取引き金額をチェックするための手段と、前記取引きを進めることができるかどうかを示すメッセージを送るための手段とを備える匿名取引システム。
- 請求項３記載の匿名取引システムにおいて、前記クレジット・エージェント・ノードに対する前記クレジット問合わせメッセージが、前記複数の照合エンジンの中の少なくとも１つを経由する匿名取引システム。
- 請求項３または請求項４記載の匿名取引システムにおいて、前記クレジット・エージェント・ノードが、前記照合エンジンの中の１つに取引き進行インジケータ・メッセージを送り、前記複数の照合エンジンが、それに対して前記相手方の取引フロアが接続している前記取引エージェント・ノードに、前記インジケータ・メッセージを転送する匿名取引システム。
- 請求項３、請求項４または請求項５のいずれか１項に記載の匿名取引システムにおいて、取引き進行インジケータ・メッセージを送信するための前記手段が、ある取引きを前記提案の金額の一部に対してだけ、進行することができることを示すための手段を含む匿名取引システム。
- 請求項１記載の匿名取引システムにおいて、所定の当事者の前記クレジット限度記憶手段を、その当事者の外部クレジット限度記憶手段にインターフェースするため手段を備える匿名取引システム。
- 請求項１記載の匿名商取引システムにおいて、複数の前記クレジット・エージェント・ノードを備え、各クレジット・エージェント・ノードが、取引フロアのグループに対するクレジット限度を記憶する匿名取引システム。
- 請求項１記載の匿名取引システムにおいて、各取引フロアまたは取引フロアのグループに対する前記クレジット限度記憶手段が、個々の相手方の取引フロア、相手方の取引フロアのグループ、または個々の相手方の取引フロアまたは相手方の取引フロアのグループの組合わせに対するクレジット限度を記憶する匿名取引システム。
- 請求項１記載の匿名取引システムにおいて、複数の相互に接続している仲介者ノードを備え、各仲介者ノードが、前記複数の照合エンジンおよび前記市場配給手段の中の一方を備える匿名取引システム。
- 請求項１記載のシステムにおいて、前記入札注文およびオファー注文が、価格取引きメッセージとして前記システムに入力され、前記市場配給手段が、前記価格取引きメッセージおよび前記照合エンジンに応じて、価格メッセージを配布する匿名取引システム。
- 請求項１記載のシステムにおいて、前記注文入力デバイスが、取引者端末を備える匿名取引システム。
- 商品の匿名取引用の自動取引きシステムであって、複数の相互に接続している仲介者ノード、および１つまたはそれ以上の端末の取引フロア内で、グループ分けされている複数の注文入力デバイスを有する、コンピュータ通信ネットワークを備え、各取引フロアが、取引エージェント・ノードを通して、１つの仲介者ノードに接続していて、各仲介者ノードが、注文入力デバイスから前記システムに入力された入札注文およびオファー注文を照合するための照合エンジンと、注文が一致した場合に、取引きを実行するための手段と、入力入札注文および入力オファー注文および前記照合エンジンに応じて、前記注文入力デバイスに、注文価格メッセージを配布するための手段とを備え、前記システムが、さらに、可能な相手方の取引フロアまたは取引フロアのグループとの取引きのための、複数の取引エージェント・ノードに接続している取引フロアに対するクレジット限度を記憶するための、少なくとも１つのクレジット・エージェント・ノードを備える自動取引きシステム。
- 請求項１３記載の自動取引きシステムにおいて、前記入札注文およびオファー注文が、価格取引きメッセージとして前記システムに入力され、前記市場配給手段が、前記価格取引きメッセージおよび前記照合エンジンに応じて、価格メッセージを配布する自動取引きシステム。
- 請求項１３記載の自動取引きシステムにおいて、前記注文入力デバイスが、取引者端末を備える自動取引きシステム。
- 商品の匿名取引用の自動取引きシステムであって、複数の相互に接続している仲介者ノード、および１つまたはそれ以上の端末の取引フロア内で、グループ分けされている複数の注文入力デバイスを有する、コンピュータ通信ネットワークを備え、各取引フロアが、取引エージェント・ノードを通して、１つの仲介者ノードに接続していて、各仲介者ノードが、注文入力デバイスから前記システムに入力された入札注文およびオファー注文を照合するための照合エンジンと、注文が一致した場合に、取引きを実行するための手段と、入力入札注文および入力オファー注文および前記照合エンジンに応じて、前記注文入力デバイスに、注文価格メッセージを配布するための手段とを備え、前記システムが、さらに、可能な相手方の取引フロアまたは取引フロアのグループとの取引きのための、複数の取引エージェント・ノードに接続している取引フロアに対するクレジット限度を記憶するための、クレジット限度記憶手段を備える自動取引きシステム。
- 請求項１６記載のシステムにおいて、複数の前記クレジット限度記憶手段を備え、各クレジット限度記憶手段が、可能な相手方の取引フロアまたは取引フロアのグループとの取引きのための、複数の取引エージェント・ノードに接続している取引フロアに対するクレジット限度を記憶する匿名取引システム。
- 請求項１６記載の自動取引きシステムにおいて、前記入札注文およびオファー注文が、価格取引きメッセージとして前記システムに入力され、前記市場配給手段が、前記価格取引きメッセージおよび前記照合エンジンに応じて、価格メッセージを配布する自動取引きシステム。
- 請求項１６記載の自動的取引きシステムにおいて、前記注文入力デバイスが、取引者端末を備える自動取引きシステム。
- 取引者間で商品を取引きするための匿名取引システムであって、
電子メッセージを送信するための通信ネットワークと、
前記通信ネットワークに接続している複数の注文入力デバイスであって、各注文入力デバイスが、入札注文および／またはオファー注文を含む、電子注文メッセージを作成し、前記ネットワークを通して、前記複数の注文入力デバイスの他のデバイスから受信した取引者の注文情報を通信する複数の注文入力デバイスと、
前記取引者端末から、前記システムに入力された入札注文およびオファー注文を照合し、注文が一致した場合に、取引きの実行を助けるための、前記ネットワークに接続している少なくとも１つの照合エンジンと、
前記取引者端末に注文メッセージを配布するために、前記ネットワークを接続していて、前記注文メッセージおよび前記照合エンジンに応答する市場配給手段と、
前記照合エンジンに関連していて、複数の機関に対するクレジット限度を記憶するクレジット仲介者とを備え、記憶している各クレジット限度が、機関または前記機関の取引フロアのグループ、または相手方の機関または相手方の機関の選択した取引フロアまたは取引フロアのグループの取引き、に対して使用することができるクレジットを表す匿名取引システム。 - 請求項２０記載の匿名取引システムにおいて、複数の照合エンジンを備え、各照合エンジンが、関連するクレジット仲介者を含む匿名取引システム。
- 請求項２１記載の匿名取引システムにおいて、、前記照合エンジンおよび関連するクレジット仲介者が、ローカル・エリア・ネットワーク（ＬＡＮ）により接続している匿名取引システム。
- 請求項２０記載の匿名取引システムにおいて、前記照合エンジン、前記市場の配給手段、および前記クレジット仲介者が、１つの仲介ノードを備える匿名取引システム。
- 請求項２３記載の匿名取引システムにおいて、複数の仲介ノードを備える匿名取引システム。
- 請求項２０から請求項２４の何れか１つに記載の匿名取引システムにおいて、前記クレジット仲介者が、前記照合エンジンからクレジット留保メッセージを受信し、前記クレジット留保メッセージ内で識別された提案の取引きに対する当事者の識別をチェックし、前記提案の取引きに対する前記当事者が、前記取引きを完了するために、相互に効率的なクレジットを持っているかどうかをチェックするための手段を備える匿名取引システム。
- 請求項２５記載の匿名取引システムにおいて、前記クレジット・チェック手段が、取引き金額を、クレジット限度を表している通貨でクレジット利用に変換するための手段を含む匿名取引システム。
- 請求項２５または請求項２６記載の匿名取引システムにおいて、前記クレジット仲介者が、１人またはそれ以上の別のクレジット仲介者に、これら仲介者が、前記クレジット仲介者が、提案の取引きに対して十分な全クレジットを持っているが、前記クレジット仲介者に、前記クレジットの中の不十分な金額が割り当てられたと判断した場合に、所定の当事者に割り当てられたクレジットを持っているかどうかを問い合わせるための手段と、前記遠隔の１人のクレジット仲介者または複数のクレジット仲介者に、それが存在するかどうかをたずねるための手段を備える匿名取引システム。
- 請求項２７記載の匿名取引システムにおいて、前記クレジット仲介者が、所定の当事者に割り当てられたクレジットの少なくとも一部を前記他のクレジット仲介者に移転させるための手段を備える匿名取引システム。
- 請求項２７または請求項２８記載の匿名取引システムにおいて、前記クレジット仲介者が、前記照合エンジンに前記取引きを完了するのに十分なクレジットが、留保されたことを示すための手段を含む匿名取引システム。
- 請求項２０から請求項２９の何れか１つに記載の匿名取引システムにおいて、前記クレジット仲介者が、前記全取引き金額に対して、前記当事者の一方または両方のクレジットが不足しているが、使用できる前記クレジットが、予め定めた最低値以上である場合に、ある取引きの金額を低減するための手段を備える匿名取引システム。
- 商品の匿名取引用の自動取引きシステムであって、複数の相互に接続している仲介ノード、および１つまたはそれ以上の端末の取引フロア内で、グループ分けされている複数の注文入力デバイスを含むコンピュータ通信ネットワークを備え、各取引フロアが、１つの仲介者ノードに接続していて、各仲介者ノードが、注文入力デバイスから前記システムに入力された入札注文およびオファー注文を照合するための照合エンジンと、注文が一致した場合に、取引きを実行するための手段と、入力入札注文および入力オファー注文および前記照合エンジンに応じて、前記注文入力デバイスに、注文価格メッセージを配布するための市場配給手段とを備え、前記システムが、さらに、複数の可能な相手方の機関に、複数の各機関が割り当てたクレジット限度を記憶するための少なくとも１つの照合エンジンに関連するクレジット仲介者を備える自動取引きシステム。
- 請求項３１記載の匿名取引システムにおいて、複数の照合エンジンを備え、各照合エンジンが、関連するクレジット仲介者を含む匿名取引システム。
- 商品の匿名取引用の自動取引きシステムであって、複数の相互に接続している仲介ノード、および１つまたはそれ以上の端末の取引フロア内で、グループ分けされている複数の注文入力デバイスを含む、コンピュータ通信ネットワークを備え、各取引フロアが、１つの仲介者ノードに接続していて、各仲介者ノードが、注文入力デバイスから前記システムに入力された入札注文およびオファー注文を照合するための照合エンジンと、注文が一致した場合に、取引きを実行するための手段と、入力入札注文および入力オファー注文および前記照合エンジンに応じて、前記注文入力デバイスに、注文価格メッセージを配布するための市場配給手段とを備え、前記システムが、さらに、複数の可能な相手方の機関、または可能な相手方の機関の特定の取引フロアまたは取引フロアのグループに、複数の各機関が割り当てたクレジット限度を記憶するための少なくとも１つの照合エンジンに関連するクレジット仲介者を備える自動取引きシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US60249600A | 2000-06-23 | 2000-06-23 | |
| PCT/IB2001/001468 WO2002001437A2 (en) | 2000-06-23 | 2001-06-22 | Credit limit storage in an anonymous trading system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004502243A true JP2004502243A (ja) | 2004-01-22 |
| JP2004502243A5 JP2004502243A5 (ja) | 2005-07-21 |
Family
ID=24411581
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002506499A Pending JP2004502243A (ja) | 2000-06-23 | 2001-06-22 | 匿名取引システムでのクレジット限度記憶 |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7693774B2 (ja) |
| EP (1) | EP1295234A1 (ja) |
| JP (1) | JP2004502243A (ja) |
| AU (1) | AU7663401A (ja) |
| CA (1) | CA2383125A1 (ja) |
| GB (1) | GB2366023B (ja) |
| WO (1) | WO2002001437A2 (ja) |
| ZA (1) | ZA200202217B (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006024221A (ja) * | 2004-07-09 | 2006-01-26 | Ebs Group Ltd | 電子取引システム、および電子取引システム上で取引する方法 |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2366642A (en) * | 1999-06-15 | 2002-03-13 | Cfph Llc | Systems and methods for electronic trading that provide incentives and linked auctions |
| US7379909B1 (en) | 2000-10-04 | 2008-05-27 | Tradestation Technologies, Inc. | System, method and apparatus for monitoring and execution of entry and exit orders |
| US7366693B2 (en) * | 2001-10-31 | 2008-04-29 | Accenture Global Services Gmbh | Dynamic credit management |
| US8332292B2 (en) * | 2002-10-04 | 2012-12-11 | The Bank Of New York Mellon Corporation | Method and system for securitizing a currency related commodity |
| WO2004040422A2 (en) | 2002-10-29 | 2004-05-13 | Electronic Broking Services Limited | Trading system |
| US7792735B1 (en) | 2002-11-26 | 2010-09-07 | Trading Technologies International, Inc. | System and method for risk management using average expiration times |
| US7603303B1 (en) | 2002-11-26 | 2009-10-13 | Trading Technologies International, Inc. | System and method for risk management |
| US7752117B2 (en) | 2003-01-31 | 2010-07-06 | Trading Technologies International, Inc. | System and method for money management in electronic trading environment |
| US8676679B2 (en) * | 2003-06-30 | 2014-03-18 | Bloomberg L.P. | Counterparty credit limits in computerized trading |
| US20050114258A1 (en) * | 2003-10-08 | 2005-05-26 | Neill Penney | Fix-enabled order management method and apparatus |
| EP1605384A1 (en) * | 2004-05-11 | 2005-12-14 | EBS Group limited | Price display in an anonymous trading system |
| US7827093B1 (en) | 2005-03-02 | 2010-11-02 | Icap Services North America Llc | Call for quote/price system and methods for use in a wholesale financial market |
| US8898080B1 (en) * | 2005-08-25 | 2014-11-25 | Patshare Limited | Counterparty credit in electronic trading systems |
| US8583534B1 (en) | 2005-09-30 | 2013-11-12 | Trading Technologies International Inc. | System and method for multi-market risk control in a distributed electronic trading environment |
| US7711644B2 (en) | 2005-12-20 | 2010-05-04 | Bgc Partners, Inc. | Apparatus and methods for processing composite trading orders |
| US20070156568A1 (en) * | 2006-01-05 | 2007-07-05 | Jovanovic Vladan D | Method and system for distributed trading limit enforcement |
| US20070250437A1 (en) * | 2006-04-06 | 2007-10-25 | Omx Technology Ab | Securities settlement system |
| US7848997B2 (en) * | 2006-04-06 | 2010-12-07 | Omx Technology Ab | Securities settlement system |
| CA2597014C (en) | 2006-04-27 | 2016-06-28 | Espeed, Inc. | Systems and methods for maintaining anonymity in a gaming or other environment |
| US7606759B2 (en) * | 2006-05-16 | 2009-10-20 | Automated Trading Desk, Llc | System and method for implementing an anonymous trading method |
| US7996301B2 (en) | 2007-08-20 | 2011-08-09 | Chicago Mercantile Exchange, Inc. | Out of band credit control |
| US8762252B2 (en) | 2007-08-20 | 2014-06-24 | Chicago Mercantile Exchange Inc. | Out of band credit control |
| US8756146B2 (en) | 2007-08-20 | 2014-06-17 | Chicago Mercantile Exchange Inc. | Out of band credit control |
| US11100577B1 (en) | 2010-08-20 | 2021-08-24 | Nex Services North America Llc | Anonymous trading system |
| US20140278582A1 (en) * | 2013-03-15 | 2014-09-18 | Oferta, Inc. | Systems and methods for facilitating requests and quotations for insurance |
| US20120303507A1 (en) * | 2011-05-26 | 2012-11-29 | Rosenthal Collins Group, Llc | Interface for Electronic Trading Platform |
| US8706610B2 (en) | 2011-08-16 | 2014-04-22 | Sl-X Technology Uk Ltd. | Systems and methods for electronically initiating and executing securities lending transactions |
| US8682780B2 (en) | 2011-08-16 | 2014-03-25 | Sl-X Technology Uk Ltd. | Systems and methods for electronically initiating and executing securities lending transactions |
| US8533104B2 (en) | 2011-10-07 | 2013-09-10 | Trading Technologies International, Inc | Multi-broker order routing based on net position |
| WO2013166164A1 (en) * | 2012-05-01 | 2013-11-07 | Chicago Mercantile Exchange Inc. | Out of band credit control |
| WO2013165829A1 (en) * | 2012-05-01 | 2013-11-07 | Chicago Mercantile Exchange Inc. | Out of band credit control |
| US10453133B1 (en) * | 2013-10-11 | 2019-10-22 | Chicago Mercantile Exchange Inc. | Computer system and a computerized method for central counterparty limit management |
| US11488040B2 (en) | 2014-05-22 | 2022-11-01 | The Bank Of New York Mellon | System and methods for prediction communication performance in networked systems |
| US9741074B2 (en) * | 2015-03-09 | 2017-08-22 | Paypal, Inc. | Dynamic handling for resource sharing requests |
| US10628768B2 (en) * | 2016-05-09 | 2020-04-21 | Fidessa Trading Uk Limited | Systems and methods for risk management in a geographically distributed trading system |
| US10453136B2 (en) * | 2016-05-25 | 2019-10-22 | StreamingEdge Inc. | Shared memory-based transaction processing |
| CA2994767A1 (en) * | 2017-02-10 | 2018-08-10 | Thomson Reuters Global Resources Unlimited Company | Apparatuses, methods and systems for electronic trading distribution |
| US11449936B2 (en) * | 2019-06-18 | 2022-09-20 | Chicago Mercantile Exchange Inc. | Distributed credit control with centralized allocation |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07506916A (ja) * | 1992-02-03 | 1995-07-27 | チェース・マンハッタン・インターナショナル・リミテッド | 電子仲買システムのクレジット管理 |
| JP2000501864A (ja) * | 1995-12-12 | 2000-02-15 | リューターズ リミテッド | 自動裁定機能または名義切換機能を含む電子取引システム |
| WO2000016224A1 (en) * | 1998-09-11 | 2000-03-23 | Ebs Dealing Resources, Inc. | Communication of credit filtered prices in an electronic brokerage system |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0512702A3 (en) * | 1991-05-03 | 1993-09-15 | Reuters Limited | Automated currency trade matching system with integral credit checking |
| US6421653B1 (en) * | 1997-10-14 | 2002-07-16 | Blackbird Holdings, Inc. | Systems, methods and computer program products for electronic trading of financial instruments |
-
2001
- 2001-01-19 GB GB0101435A patent/GB2366023B/en not_active Expired - Lifetime
- 2001-06-22 EP EP01954294A patent/EP1295234A1/en not_active Ceased
- 2001-06-22 AU AU76634/01A patent/AU7663401A/en not_active Abandoned
- 2001-06-22 WO PCT/IB2001/001468 patent/WO2002001437A2/en active Application Filing
- 2001-06-22 CA CA002383125A patent/CA2383125A1/en not_active Abandoned
- 2001-06-22 JP JP2002506499A patent/JP2004502243A/ja active Pending
- 2001-06-29 US US09/896,220 patent/US7693774B2/en not_active Expired - Lifetime
-
2002
- 2002-03-19 ZA ZA200202217A patent/ZA200202217B/en unknown
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07506916A (ja) * | 1992-02-03 | 1995-07-27 | チェース・マンハッタン・インターナショナル・リミテッド | 電子仲買システムのクレジット管理 |
| JP2000501864A (ja) * | 1995-12-12 | 2000-02-15 | リューターズ リミテッド | 自動裁定機能または名義切換機能を含む電子取引システム |
| WO2000016224A1 (en) * | 1998-09-11 | 2000-03-23 | Ebs Dealing Resources, Inc. | Communication of credit filtered prices in an electronic brokerage system |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006024221A (ja) * | 2004-07-09 | 2006-01-26 | Ebs Group Ltd | 電子取引システム、および電子取引システム上で取引する方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU7663401A (en) | 2002-01-08 |
| ZA200202217B (en) | 2003-06-09 |
| WO2002001437A2 (en) | 2002-01-03 |
| GB2366023B (en) | 2004-08-11 |
| US20020133455A1 (en) | 2002-09-19 |
| GB0101435D0 (en) | 2001-03-07 |
| CA2383125A1 (en) | 2002-01-03 |
| US7693774B2 (en) | 2010-04-06 |
| GB2366023A (en) | 2002-02-27 |
| EP1295234A1 (en) | 2003-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004502243A (ja) | 匿名取引システムでのクレジット限度記憶 | |
| US7024386B1 (en) | Credit handling in an anonymous trading system | |
| US8639607B2 (en) | Conversational dealing in an anonymous trading system | |
| AU765590B2 (en) | Deal matching in an anonymous trading system | |
| JP4911859B2 (ja) | 複合的注文を処理するための匿名式取引システム | |
| US8131633B2 (en) | Liquidity and fill optimization for crossing institutional orders | |
| US20060136318A1 (en) | Automated system for routing orders for financial instruments | |
| EP1629342A2 (en) | Automated system for routing orders for financial instruments | |
| AU8434201A (en) | Architecture for anonymous trading system | |
| JP2004501452A (ja) | 匿名取引システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20031015 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20031015 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20031015 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051101 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060131 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060207 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060501 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060501 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060711 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061108 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070216 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20070316 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20091124 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20091130 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100225 |