JP2010503920A - 複数当事者間取引における相手方リスク制限の方法 - Google Patents

Abstract

【課題】前の相手方当事者の決済債務を引き受ける際の中央相手方のリスクを低減すること。
【解決手段】本発明のいくつかの態様では、中央相手方システムが、相手方当事者間の売買を更改し、それによって元の取引を、元の各相手方当事者システムと中央相手方システムとの間の取引で代行する。
【選択図】図１

Description

本発明の諸態様は、複数当事者間取引における、ある特定種類のリスクを制限する、コンピュータ化された機器、システム及び方法に関する。

大部分の金融商品の売買は、一般に、取引所で売買されるものとそうでないものとの２グループに分けることができる。とはいえ、金融商品の中には取引所と取引所外の両方で売買されるものもある。上場商品は近年著しい成長を示しており、これは一部にはその売買が容易であり、取引の当事者が負う決済リスクが限定されることによるものである。

非上場商品の上場への移行を妨げる主要な要因の１つが、全関係当事者のためのリスク管理の複雑さである。金融市場における売買は様々な種類のリスクを伴い得る。「市場リスク」は、価格の変動により投資の価値が予期せずに変化するリスクである。「流動性リスク」は、投資の所持人が、売ろうとするときに買い手を見つけることができなくなるリスクである。「相手方リスク（ｃｏｕｎｔｅｒｐａｒｔｙ ｒｉｓｋ）」は、取引の相手方当事者が予期せずに取引に対する債務を履行しなくなるリスクである。

非上場金融取引（「店頭取引」又は「ＯＴＣ取引」と呼ばれる）の中には、莫大なレベルの相手方リスクを有するものがある。このような種類の取引では、一方の相手方当事者の債務の不履行が取引の他方の相手方当事者に莫大な金融エクスポージャーをもたらし得る。この高い相手方リスクのために、ＯＴＣ市場は事実上、その決済債務を履行することを保証するのに十分な信用や実績を有する当事者だけに制限されてきた。

たとえ新規参入者がＯＴＣ商品を売買しようとしたとしても、その新規参入者は、他の当事者の尊敬（及び信用格付け）を獲得し、かつ／又は、その新規参入者が相手方に、ＯＴＣ市場の慣行に従って決済することを保証する十分な担保の証拠を提供するまで、回避されるはずである。この信用のハードルの高さは、新規参入者がこれらのＯＴＣ市場に容易に参入することを妨げ、ＯＴＣ市場の成長を制限している。

上述のように、高い相手方リスクのために、ＯＴＣ市場は事実上、その決済債務を履行することを保証するのに十分な信用や実績を有する当事者だけに制限されてきた。

この概要は、以下の詳細な説明でさらに説明する一連の概念を簡略化した形で提示するためのものである。この概要は、特許請求される主題の主要な特徴又は不可欠な特徴を特定するためのものではない。

本発明の諸態様は、前述の１つ又は複数の問題に対処して、これまで非上場で売買されてきた商品の相手方リスクを最小限にし、又は解消する。

本発明のいくつかの態様では、中央相手方システム（ｃｅｎｔｒａｌ ｃｏｕｎｔｅｒｐａｒｔｙ）が、相手方当事者間の売買を更改（ｎｏｖａｔｅ）し、それによって元の取引を、元の各相手方当事者システムと中央相手方システムとの間の取引で代行する。

本発明の別の態様は、相手方当事者間の取引を更改し、前の相手方当事者の決済債務を引き受ける際の中央相手方のリスクを判定し、かつ／又は最小限にすることに関するものものある。本発明の別の態様は、取引を処理するための高速な端末間の電子経路を設けることにより、誤りの、したがってリスクの可能性を低減することに関するものである。

本開示の上記その他の態様は、以下の例示的実施形態の詳細な説明を考察すれば明らかになるであろう。

本発明のより十分な理解、及び本発明の潜在的利点は、添付の図面を考慮に入れて以下の例示的実施形態の説明を参照すれば理解される。

本発明の一態様によれば、非上場で売買されてきた商品の相手方リスクを最小限にする。

本発明の諸態様による一般的概要を示す図である。 本発明の諸態様による様々なメッセージフロー及びインターフェースを示す図である。 本発明の諸態様による、注文確認、約定、及び注文ブック更新に関する様々なメッセージフロー及びインターフェースを示す図である。 本発明の諸態様による決済限度管理を用いた約定済み売買の更改に関する様々なメッセージフローを示す図である。 本発明の諸態様による売買代行を用いた決済前売買ネッティングによる様々なメッセージフローを示す図である。 本発明の諸態様に従って使用され得るアプリケーションプログラミングインターフェース及び売買業者端末を示す図である。 本発明の諸態様による取引約定システムの様々な機能構成要素を示す図である。 本発明の諸態様による清算及びネッティング構成要素を示す図である。 本発明の諸態様による決済システムを示す図である。 本発明の諸態様による決済アプリケーションを示す図である。 図１の概要システムの計算装置の例を示す機能ブロック図である。

前述の様々な態様は様々な形で実施され得る。以下の説明では、これらの態様が実施され得る様々な組み合わせ及び構成を例として示す。説明する態様や実施形態は例にすぎず、本開示の範囲を逸脱することなく、他の態様や実施形態が使用されてもよく、構造的、機能的改変が行われてもよい。

以下の説明は、容易に理解できるように分説される。これらの小節が含まれるのは説明の便宜のためにすぎず、本発明の諸態様は、以下で説明する構成要素、プロセス、及びＡＰＩのうちの１つ又は複数を含んでいてもよい。
１．従来の売買プロセス
２．上場市場と店頭市場
３．相手方リスク
４．相手方リスクのタイミング
５．更改を用いた売買プロセス
６．売買業者ＡＰＩ
７．取引約定
８．清算及びネッティング
９．システム関連の決済システム
１０．売買業者関連の決済アプリケーション
１１．実施例

＜１．従来の売買プロセス＞
一般に金融市場の売買プロセスは、市場価格発見、取引執行、取引決済という３つの主要ステップを有する。

市場価格発見は、執行可能な買い呼び値（誰かが買おうとする価格）と執行可能な売り呼び値（誰かが売ろうとする価格）を作成し、市場参加者に流布するためのプロセスである。一般に、このプロセスは、市場において活動している全参加者からの買い呼び値及び売り呼び値のセントラル指値注文ブック（ｃｅｎｔｒａｌ ｌｉｍｉｔ ｏｒｄｅｒ ｂｏｏｋ）の収集を伴う。

「全参加者」という用語は一般に、個々の商品の売買に関心を有する者を指す。セントラル指値注文ブック（「ブック」又は「ＣＬＯＢ」ともいう）は、市場の規則に従い、「価格／時刻優先順位」の順に配列される。これは、最高の買い呼び値と最低の売り呼び値とを優先するものである。またこの優先順位付けは、時系列で配列することにより同価格の注文も解決する。

要するに、市場においては最初で最高の買い呼び値が他のあらゆる買い呼び値に優先する。ほぼすべての場合、買い呼び値と売り呼び値のブックは匿名である。すなわち、買い申込者と売り申込者の識別情報は売買の前に市場参加者に公開されない。

ＣＬＯＢ順序付けの別の変形、例えば、より大口の注文が、たとえより遅い時刻に到着したとしても、同じ価格のより小口の注文に優先する、価格／サイズ／時刻の優先順なども可能である。市場の運営者は通常、流動性を最大化し、最大数の参加者の関与を促すために、市場の要求に基づいてＣＬＯＢの優先順位付け規則を決定する。市場によっては、中央規制当局がＣＬＯＢの優先順位付け規則を決定する場合もある。

市場は多数の参加者を含み得る。各参加者は、他の市場参加者から見て必ずしも平等であるとは限らない。個々の市場の特性によっては、必ずしもすべての買い呼び値と売り呼び値を任意の個々の参加者が売買できるとは限らない。例えば、有価証券の売り手が、個人にではなく機関にだけ売ろうとすることもある。あるいは、外貨の買い手が外国機関と決済することができず、その買い手の買い呼び値が、国内の相手方当事者による利用のために制限されることもある。

所与の市場参加者の売買能力に対するこれらの制限に対応するために、市場価格発見プロセスは、買い呼び値と売り呼び値のブックをフィルタにかけて、参加者に、参加者が実際に取引することのできる注文（買い呼び値及び売り呼び値）だけが見えるようにする。フィルタリングプロセスは、買い申込者又は売り申込者によって課せられる任意の制限、及び受け手によって課せられる任意の制限を考慮しなければならない。これを相互フィルタリングという。

取引執行は、取引を完了するために仲買人が買い申込者と売り申込者（買い手と売り手）を突き合わせするためのプロセスである。約定プロセスは通常、活発な市場においてコンピュータにより行われるが、市場によっては人間（いわゆる「電話対応の仲買人（ｖｏｉｃｅ ｂｒｏｋｅｒ）」）によって行われることもある。注文が完全に約定されると、その注文は、他の参加者が誤ってその注文をまだ取引できると考えないようにブックから除外される。

場合によっては取引執行のプロセスは、目的の取引の完全な詳細が、価格発見で明らかにされた価格によるだけでは捉えられない際に、追加の折衝ステップを伴うこともある。例えば、取引当事者らが決済日、数量、基準価格などに合意することが必要とされる場合もある。これらの売買パラメータは、元の買い呼び値及び売り呼び値の条件とされていないこともあり、したがって、２当事者が組み合わされる前には突き合わせることができなかったはずである。

２当事者は、売買を執行することに合意した後で、相互に取引の決済を完了する義務を負う。決済プロセスは、当事者間で実際の価値の交換を行うのに使用される手続きである。例えば有価証券取引では、買い手と売り手とが、Ｘ社の株式１０００株を１株当たり１０ドルの価格で売買することに合意する。この取引は、約定日の３日後に決済することが予定される。決済日の当日又はその前に、売り手は買い手に１０００株受け渡すための手続きを行わなければならず、買い手は売り手に１０，０００ドルを受け渡すための手続きを行わなければならない。これらの交換が両方とも完了すると、取引は完全に決済されたといわれる。

複雑な金融取引の中には、決済が実際には複数の期日に行われるものもある。例えば金利スワップでは、当事者らは、おそらくは数年間の期間にわたり６ヵ月ごとに支払いを交換することに合意する。外国為替スワップでは、第１回の決済が取引の２日後に行われ、第２回の決済がその３日から１年後又はもっと後に行われる。

＜２．上場市場と店頭市場＞
異なる商品は異なる市場で売買される。例えば株式は通常、組織化された取引所で売買され、金利派生商品及び外貨は通常、中央取引機構を介さずに売買される。これらの区別は、本発明によって対処される主題と密接に関連している。

上場市場では、中央取引所が市場に、秩序ある商取引の実行を保証し、市場参加者から何らかの形のリスクを解消する、又は移転する多くのサービスを提供する。例えば、スペシャリストを擁する市場では流動性リスクが極めて低い。というのは、スペシャリストの役割の１つは、参加者に対して常に妥当な買い呼び値と売り呼び値が提示されるようにすることだからである。この場合、流動性リスクは市場参加者からスペシャリストに移転され、スペシャリストは、流動性リスクを市場に移転することができるようになるまで非流動性ポジションを保持する義務を負う。

ほとんどすべての為替市場では、取引所があらゆる売買での「中央相手方システム（ｃｅｎｔｒａｌ ｃｏｕｎｔｅｒｐａｒｔｙ）」として機能する。すなわち取引所は、買い手と売り手との間に入って、個々の参加者ではなく取引所自体が取引の決済を保証するようにする。この買い手と売り手の間に第三者を介在させるプロセスは、中央相手方システムへの売買更改（ｔｒａｄｅ ｎｏｖａｔｉｏｎ）、又は単に「更改」とも呼ばれる。取引所は、その保証の結果としてリスクを負うため、更改プロセスは通常、直接取引権限を、定評のある信用度の高いメンバだけに制限し、一般大衆は、取引所メンバの提供するサービスを介してのみ取引所にアクセスするものとしている。

店頭市場は取引所が提供する機能の恩恵を受けない。逆にいうと、店頭市場には取引所アクセス権限に伴う同じ制限の多くがない。通常は、任意の十分に信用度の高い（と他の市場参加者の判断により判定された）参加者が、ＯＴＣ市場においてやりとりすることができる。流動性又は決済を保証する中央相手方は存在せず、そのため、自分の売買債務を直接決済することはＯＴＣ市場参加者の義務である。これを「交換決済」に対して「直接決済」と呼ぶ。

個々の市場の慣行に応じて、約定日と予定される決済日の間には通常、数日間の期間が置かれる。例えば、外国為替市場では、大部分の通貨の売買が、週末及び休日を除いて、約定日から最短で２営業日後に決済される。

この売買から決済までの期間には、たとえその売買が実際に期待される条件で決済されるという絶対的確実性がないとしても、双方の相手方当事者に、（買い手の場合には）事実上その商品を所有しているという期待、又は（売り手の場合には）その商品を売ったという期待が生じる。

理論的には、多くの要因により売買が決済を履行できなくなるおそれもある。これらの要因の中には以下のものがある。
１．決済前の相手方当事者の破産
２．相手方当事者に決済債務に気付かせない運用誤り
３．相手方当事者が必要なときに決済に資金を割り当てられなくする流動性問題
４．相手方当事者が決済に必要な指示を出せなくするシステム誤動作
上記すべて、及びそれ以外の場合にも、決済債務を履行する当事者は大きなリスクにさらされる。このリスクは相手方当事者の行為又は無為の作用であるため、このリスクは「相手方決済リスク（ｃｏｕｎｔｅｒｐａｒｔｙ ｓｅｔｔｌｅｍｅｎｔ ｒｉｓｋ）」と総称される。すべてのＯＴＣ市場は固有の相手方決済リスクを有する。というのは、取引の正常な完了が売買の両当事者の正しい適時の行為に依存するからである。相手方リスクは（市場リスク、流動性リスク、規制リスク、及び他の形のリスクを含む）その他の種類のリスクとは異なる。

＜３．相手方リスク＞
相手方リスクとは、売買の相手方の作為又は無作為から生じる予期しない損失の可能性である。以下に３種類の相手方リスクを説明する。本発明の諸態様は、これらの種類の相手方リスクのうちの１つ又は複数を最小限に抑え、かつ／又は解消する。

１．決済に不十分な信用：場合によっては、売買が仲買人又は電子プラットフォームによって執行された後で、売買の一方の当事者が、実際にはその当事者に他方の当事者と取引するのに十分な信用限度額がなかったことに気付くことがある。事実上その売買は行われるべきでなかったものであり、この当事者は、決済することができないため、相手側当事者との売買を解消する必要がある。これはまれにしか起きないはずであるが、市場によっては発生し得る。
２．決済指示の不履行：売買後、決済前プロセスには多くの可能な運用誤りの原因がある。取引が技術的誤動作により失われることもある。取引が、誤りを持ち込む手作業のプロセスにより転記されることもある。秩序ある決済を妨げる様々な自然と人為両方の災害が発生することもある。上記その他の場合には、売買の一方の当事者が、決済日に取引銀行に資金及び資産を移転する適切な指示を出さないこともある。
３．決済の不履行：最後に、売買の一方の当事者は実際にその債務を決済し、他方の当事者はその債務を決済しない現実の可能性がある。これは、一方の当事者に別の当事者より前に決済を行うよう求める市場ではさらに悪化し得る。
決済の不履行は、「不作為」である、すなわち、意図しない誤りによって引き起こされることもあり、故意である、すなわち、ある当事者が、売買誤りであったと考える理由により決済しないことにすることもあり、単に非常に悪い売買であることもある。最も極端な場合には、決済の不履行は、甚だしい決済リスク、すなわち、一方の当事者は他方の当事者に支払いをしているが、他方の当事者はその当事者側の取引の支払いをすることができず、又は支払いをしようとしない元金の完全な損失を生じ得る。

相手方リスクは、当事者らが取引に参加するのを妨げ、それによって市場の成長を鈍化させ、又は妨げる可能性がある。本発明の少なくとも１つの態様では、当事者間に介在させて相手方リスクを吸収するために、中央相手方システムが使用される。この場合、中央相手方システムは、任意の所与の相手方当事者からの可能な損失に対応するためにその実施方法を調整することができる。

＜４．相手方リスクのタイミング＞
売買の参加者は、その売買が執行される瞬間から全債務の最終決済を含めた時点まで潜在的に相手方リスクにさらされる。売買は、その取引が１回だけの決済を伴うか、それとも複数回の決済を伴うかに応じて、２つの取引クラスに分類される。

単一決済取引とは、完了するのに買い手と売り手の間で１回だけの価値の交換で済む取引である。単一決済取引の例には、有価証券（株式及び債券）取引、大部分の商品取引、外国為替現物取引、及び金利先渡取引が含まれる。

複数決済取引とは、取引が完了するまでに複数回の、場合によっては連続した一連の決済を必要とする取引である。２決済取引の例には、先物為替スワップ、クロスカレンシー金利スワップ、及び一部の買戻契約取引が含まれる。複数決済取引の例には長期金利スワップ契約が含まれ、これは契約の複数年存続期間にわたって３ヵ月ごと又は６ヵ月ごとに決済がある。

潜在的相手方リスクには以下の３つの主要な期間がある。
１．売買執行と売買確認の間
２．売買確認と決済の間
３．決済の開始と決済の完了の間
売買は、個々の売買業者により売買端末を使って、又は売買機関に代わって売買を執行する独自のプログラムによって執行され得る。売買執行によりその直後にその売買の両当事者にメッセージが送られる。しかし、その結果生じる債務の決済に責任を負う当事者にも別のメッセージが送られなければならない。

決済当事者は、売買当事者と同じであることも多いが、同じ組織内の別の部署であることも、異なる場所であることも、全く異なる機関である場合さえもある。売買が執行されているが、決済装置が売買確認を受け取っていない場合、リスク期間が生じ、売買が期待されるように決済されない可能性が生じる。本発明の少なくとも１つの態様では、このリスク期間は、すべての執行売買が適時に適切な決済装置に通知されるようにすることによって対処される。

売買が売買装置と決済装置とに通知されている場合にも、依然として、売買確認と最終決済との間の期間に、決済装置がその銀行エージェントに売買債務の決済の指示を出すことを怠る可能性がある。これは、運用誤りが原因で生じる場合も、流動性問題が原因で生じる場合も、破産が原因で生じる場合も、企業にその未決済の債務を決済することができないと判断させ得る他の多くの理由のいずれかによる場合もある。

本発明の少なくとも１つの態様では、この形態のリスクは、決済指示の不履行から起こり得る最悪の損失が見積もられ、かつ／又は１つ又は複数の機構（担保や保険など）によって保証されるようにすることによって対処される。これを「清算」と呼ぶこともある。

最後に、企業が決済のための売買を指示するが、次いで決済取引に必要な資金又は資産を提供することを怠る可能性もある。この場合、価値の交換を構成する２つの支払いが取り消し不能でない形でリンクされていれば、一方の当事者が支払いをするが期待される価値を受け取らず、全決済価値を失う可能性が生じる。

本発明の少なくとも１つの態様では、この損失の可能性は、価値の交換の「支払い対支払い」又は「受渡し対支払い」モデルを提供する決済システムを使って対処される。かかるシステムでは、決済の半分を支払い、対応する他方の半分を受け取らないことは起こり得ない。本発明の１つ又は複数の態様は、このような種類の決済機構を使って、中央の相手方を甚だしい決済リスクから保護する。

最後に、人的過誤のリスクを最小限に抑えるために、本発明の諸態様は、人的介入を最小限にし、かつ／又は排除し得る。本発明のいくつかの態様において、本明細書で説明するシステム及び方法は、迅速化処理法を使って、売買が、人的、又は紙ベースの処理の固有のリスクを導入せずに、極めて短期の決済予定で、場合によっては当日又は翌日に決済され得るようにする。期間を狭め、人的処理を排除することにより、本発明は、リスクを導入する可能性が確実に最小限に抑えられるようにする。

＜５．更改を用いた売買プロセス＞
図１は、これまで相手方リスクによって制約されていた市場において売買と決済の両方を処理する多数のプロセスを統合するシステムに関するものである。これらのプロセスには以下のものが含まれる。
１．価格発見
２．取引執行
３．売買更改
４．売買後決済前リスク管理
５．決済前ネッティング
６．受渡し対支払い決済
ホールセール市場における外国為替取引の状況で説明しているが、本発明の原理は、他の金融市場（有価証券、債券、金利派生商品、商品、エネルギーなど）にも、他のクラスの参加者（ノンバンク金融機関、非金融企業、個人など）にも同様に当てはまる。

図１に本発明の諸態様による一般的概要を示す。図１には、中央相手方システム１００と、中央相手方システム１００と情報を交換するシステムが示されている。決済システム１０４は、中央相手方システム１００の一部としても、しなくてもよい。中央相手方システム１００は、制御システム１０１と、取引約定システム１０２と、清算及びネッティングシステム１０３とを含む。

売買業者は売買端末を使って相互に売買を行う。売買端末は、売買情報のローカル表示と、売買業者からの引受け行為及び先渡し行為を処理する売買業者アプリケーション（１０６〜１０８）を含む。

売買端末には、専用売買コンピュータ、ローカル売買アプリケーションを実行する汎用コンピュータ、コンピュータ、又はインターネットベースの他の計算システム、及びこれらの間の組み合わせが含まれる。さらに、売買業者アプリケーションは、ローカル表示も、売買業者からの行為もなしで、アルゴリズム売買を行う「ブラックボックス」とすることもできる。

本明細書では、売買業者から情報を受け取り、売買業者に情報を提供する機能を「売買業者アプリケーション」と呼び、図１に、売買業者１アプリケーション１０６、売買業者２アプリケーション１０７、及び売買業者Ｎアプリケーション１０８で表わしている。売買業者アプリケーション１０６〜１０８は、各市場参加者（売買業者）のところに位置するコンピュータ上で実行される。

売買業者アプリケーション１０６〜１０８は、売買機能を備えるグラフィカルユーザインターフェース（ＧＵＩ）を提供するプログラムとすることも、自動化プログラム売買アプリケーションとすることも、更にはこれら２つのプログラムの混成プログラムとすることもできる。

売買業者は更に、表示される注文ブックに応答して売買業者アプリケーション１０６〜１０８に売買注文メッセージを入力してもよい。また売買業者は、各売買をグロスで決済すべきかそれともネットで決済すべきかを、売買ごとに個別に指定しても、デフォルトとして指定してもよい。

各売買業者アプリケーション１０６〜１０８は、ネットワーク１０５を介して取引約定システム１０２と直接又は間接的にやり取りする。例えば、ネットワーク１０５は広域ネットワークや任意の他の種類のネットワークとすることもできる。ネットワーク１０５は、公衆インターネットや、専用ＴＣＰ／ＩＰネットワークや、売買アプリケーションに図１の取引約定システムと高速、低待ち時間で通信させる任意の他の形態の通信ネットワークとすることもできる。売買業者アプリケーション１０６〜１０８は、アプリケーションプログラミングインターフェース（ＡＰＩ）１１０〜１１２を使って取引約定システム１０２とやりとりしてもよい。

売買業者アプリケーション１０６〜１０８は、売買のサイズ、例えば名目決済金額は、グロスで決済されてもまとめて差額決済されてもよいなど、当事者のリスクを増大させる売買、及び／又はその他の売買業者にとっての問題を含む１つ又は複数の要因に基づいて、グロス決済が望ましいかそれともネット決済が望ましいかを指定する。

次に、取引約定システム１０２は売買業者からの売買を突き合わせ、売買業者アプリケーション１０６〜１０８に約定の表示を提供する。取引約定システム１０２は、売買業者アプリケーション１０６〜１０８によって提示される気配値及び注文を処理し、全市場参加者に表示するためにこれらの注文をセントラル指値注文ブックに編成する役割を果たすコンピュータシステムとすることができる。

注文をセントラル指値注文ブックに編成することにより、取引約定システム１０２は売買業者に、参加者が市場において取引することのできる最良価格のブックを提供する（本明細書で「価格発見」ともいう）。以下で説明するように、図１のシステムには相手方当事者システム（以下、相手方当事者と略することもある）との摩擦が最小限又は全く生じず、全注文を全参加者に提示させることができる。言い換えると、セントラル注文ブックからの注文のフィルタリングが行われない。

また取引約定システム１０２は、実際の約定プロセス、すなわち価格及び時刻の優先度の規則、又は個々の市場に実施されるそのような他の約定規則に従って約定させることのできる注文の対を識別する役割を果たすこともできる。

取引約定システム１０２は約定指示を清算及びネッティングシステム１０３に送り、そこでその約定が清算され、売買業者からの支払い又は受渡し商品が決定される。

売買の更改を行い、相手方当事者の責任を引き受ける中央相手方システム１００の役割は、清算及びネッティングシステム１０３によって行われる。清算及びネッティングシステム１０３は、上記取引約定システム１０２によって報告されるあらゆる売買の中央相手方システムとして働くコンピュータシステム及び／又はプログラムを含む。

取引約定システム１０２が清算及びネッティングシステム１０３に約定済みの（執行された）売買を通知すると、清算及びネッティングシステム１０３は即座に買い手と売り手の間に入り、その売買を、中央の中央相手方システム１００、又はより具体的には清算及びネッティングシステム１０３、との２つの等価の、逆向きの売買へと更改する。売買装置の間の売買を更改する清算及びネッティングシステム１０３は、売買業者らがもはや元の相手方当事者の行為に依存しなくなるため、売買業者間の相手方リスクを解消する。

次いで清算及びネッティングシステム１０３は、売買確認メッセージを生成し、売買確認メッセージは、すべての決済詳細を含めて、買い手と売り手のそれぞれの清算エージェント（決済アプリケーション１０９及び／又は清算アプリケーション１１３）に送られる。

最後に清算及びネッティングシステム１０３は、各決済装置との、グロスとネット両方の合計決済エクスポージャーを絶えず見積もり、万一いずれかの決済装置がその中央相手方システムとの債務の決済を履行しなかった場合に備えてあらゆる損失から中央相手方システム１００を保護するための適切な金融防護措置（担保など）が講じられるようにする。

各決済日に、清算及びネッティングシステム１０３は、決済システム１０４に、その決済債務の受取りと支払いを行わせる決済指示を送る。決済システム１０４は、中央相手方システム１００と市場参加者との間での資金の移動を実際に行わせる役割を果たす。決済システム１０４は、（中央相手方システム１００の代わりの）清算及びネッティングシステム１０３と、（市場参加者の代わりの）多数の清算アプリケーション１１３とから決済メッセージを受け取り、それらを突き合わせることに基づいてこの機能を果たす。

決済システム１０４は、すべての決済を、十分に資金供給された「支払い対支払い」又は「受渡し対支払い」として実行し、それによって市場参加者の甚だしい決済リスクを解消することができる。決済システム１０４は、１組の売買の資金要件をネッティング（例えば相殺決済処理）し得るが、いかなるネッティングも行わない。そうではなく決済システム１０４は、その指示に従って売買を決済する。

さらに決済システム１０４は、売買がグロスで決済されるべきかそれともネットで決済されるべきかに関して当事者の要望を尊重する。

清算アプリケーション１１３は、取引の部分を変更することができてもできなくてもよい。例えば清算アプリケーション１１３は、第三者の決済リスクを許容可能な範囲内に低減する必要がある場合には、市場参加者のグロス／ネット指示を変更してもよい。

決済アプリケーション１０９は、市場参加者の代わりに決済債務を獲得し、提供する決済装置に関連するものである。エンドユーザ組織は、そのネット決済債務の通知を受け、その決済銀行にこれらの債務の支払いを遂行するよう指示する必要がある。清算及びネッティングシステム１０３との間の通信路がこのために顧客決済アプリケーション１０９とやりとりする。

決済アプリケーション１０９は、清算及びネッティングシステム１０３から、売買通知メッセージ及びネット決済通知メッセージを受け取る。次に決済アプリケーション１０９は、決済システム１０４に決済指示を送る。実際には決済アプリケーション１０９は清算及びネッティングシステム１０３と同様の計算を行うが、これは単一装置の売買だけに限られる。

上記説明は図１に示す構成要素間の物理的接続に関するものである。以下で図１の各構成要素によって行われる様々なプロセスを説明する。

市場参加者に売買業者アプリケーション１０６〜１０８が供与される。売買業者アプリケーション１０６〜１０８を使って売買業者らは、買い呼び値及び売り呼び値を入力し、約定されないオープン注文を取り消し、市場で許容されるその他の取引を行う。

売買業者アプリケーション１０６〜１０８は、セントラル注文ブックを表示する。セントラル注文ブックは、市場で売買可能な買い呼び値及び売り呼び値で動的に更新される。表示は、新規注文が市場によって受け取られる際にリアルタイムで更新される。また売買業者アプリケーション１０６〜１０８は、単一の売買ワークステーションや単一の売買業者について中央市場によって報告されるすべての執行された取引の記録も表示し、記憶する。

取引約定システム１０２は、システムのすべての売買業者アプリケーション１０６〜１０８から注文及び取り消しを受け取り、これらの注文を市場の優先順位規則に従ってセントラル注文ブックに編成する。

ネットワーク１０５は、全市場参加者にセントラル注文ブックを提供するための媒体を提供する。ネットワーク１０５は、売買業者アプリケーション１０６〜１０８と取引約定システム１０２の間の高速で、待ち時間が短い接続を提供する。

取引約定システム１０２は多くの機能を実行する。例えば取引約定システム１０２は、市場の規則に従って買い呼び値と売り呼び値、又は買い注文と売り注文とを約定させ、そのような約定済みの買い呼び値及び売り呼び値をセントラル注文ブックから除去し、約定済みの買い呼び値及び／又は売り呼び値を出した売買業者アプリケーション１０６〜１０８に、前述のように結果として生じる売買執行を通知する。

清算及びネッティングシステム１０３は取引約定システム１０２から約定済みの売買を受け取る。取引約定システム１０２は、約定済みの売買の通知が売買業者アプリケーション１０６〜１０８に送られるのと同時に、又はその前に清算及びネッティングシステム１０３にすべての約定済み売買通知信号を送る。

清算及びネッティングシステム１０３に最初に約定済みの売買通知信号を送ることの１つの利点は、その場合清算及びネッティングシステム１０３は、取引約定システム１０２が売買業者アプリケーション１０６〜１０８に約定確認信号を送る前に、取引約定システム１０２に対して約定済みの売買通知信号の受取りを確認することができることである。加えてこれは、清算及びネッティングシステム１０３が、約定済みの売買を引き受け、それを売買業者アプリケーションに通知する前に、約定済みの売買に関して様々な制限チェックを行う機会も提供する。

売買の各側は決済のために個々の売買業者・企業（ｅｎｔｉｔｙ）、例えばその買い呼び値又は売り呼び値を出した売買業者などと関連付けられる。代替として売買の各側は、売買業者に代わって決済債務を処理する、例えば決済アプリケーション１０９など、異なる企業の装置（ｅｎｔｉｔｙ）と関連付けられてもよい。その場合決済アプリケーション１０９は、売買企業（売買業者など）に代わって相手方と売買を決済し、別個に売買企業と決済を行う役割を果たす。

売買業者や売買企業の中には、任意の所与の日に非常に活発なものもある。これらの売買企業は、未決の決済の制限により好都合な売買を行うことができないこともある。例えば、売買企業が各売買をグロスで決済する必要があった場合、その売買企業は、第１の取引が第２の取引の前に決済されたとすると第１の取引をカバーするのに十分な流動性を持たないこともある。

しかし、２つの取引が１つに「併合」された場合、それらの取引は相殺し合い、売買業者の利益を生じる可能性もある。したがって、本発明の少なくとも１つの態様では、売買業者は、グロスで決済するのではなくネットで決済することにする。代替として、また売買業者はネット決済と比べてグロスで決済することにしてもよい。

次に、清算及びネッティングシステム１０３から取引約定システム１０２に、清算及びネッティングシステム１０３が売買通知を受け取っているという確認が送られる。清算及びネッティングシステムからの売買通知を受け取っているという確認は、買い手と売り手、又はそれぞれの清算企業に、結果として生じる売買債務を通知しても大丈夫であることを意味する。清算及びネッティングシステム１０３からのメッセージは、約定済みの売買が更改されている、すなわち決済のために中央相手方システムによって引き受けられているという正式の通知である。

加えて、清算及びネッティングシステム１０３から別個のメッセージも売買業者、又はその清算エージェントの決済アプリケーション１０９に送られ、決済アプリケーション１０９に執行された売買から生じる決済債務を知らせる。本発明の少なくとも１つの態様では、清算及びネッティングシステム１０３から決済アプリケーション１０９へのメッセージは、清算及びネッティングシステム１０３が取引約定システム１０２から約定済みの売買を受け取ったことを確認する前に行われてもよい。

したがって本発明のこの態様では、売買業者は、約定成立したことを知らされる最後の企業であり、それによって、まず決済アプリケーション１０９が約定済み売買の受取りを確認したことが保証される。

さらに、清算及びネッティングシステム１０３は、中央相手方システムと市場の各参加者との間のネット決済債務を周期的に、又は絶えず計算するプロセスを含む。ネット決済債務は、各商品ごと、各決済日ごとに計算される。

清算及びネッティングシステム１０３はさらに、ネット決済債務を、市場参加者の決済アプリケーション１０９及び／又は決済システム１０４に送る。この送信は、ネット決済債務が計算された後で、商品ごとに行われる。さらに、任意の所与の決済日に売買が終了した後で、清算及びネッティングシステム１０３は、各決済装置（決済アプリケーション１０９と決済システム１０４）に最終ネット決済債務を送る。

清算及びネッティングシステム１０３は、システム上の各決済装置（決済アプリケーション１０９と決済システム１０４）ごとの決済ポジションの市場価値の変化を確認するプロセスを含んでいてもよい。このプロセスは、万一任意の決済装置が決済日にその売買債務の全部又は一部の決済を履行しなかった場合の中央相手方システムの最悪の損失を計算する。この計算は、売買装置ごと、清算装置ごと、又は決済装置ごとに行われてもよい。

さらに、清算及びネッティングシステム１０３は、中央相手方システム１００の最悪の損失が十分な担保によって裏付けられるように、各決済装置によって十分な担保が提供されていることを保証する。担保限度を超える場合には、清算及びネッティングシステム１０３は、中央相手方システム１００の残りの部分に、その装置の、又はその決済が限度を超えた装置によって保証（清算）される任意の売買装置の売買を中止させるよう指示する。

代替として中央相手方システム１００は、その決済限度を超えている装置のすべての売買を中止するのではなく、その装置の決済エクスポージャーを低減する（すなわちポジションを解消する）売買だけを引き受けてもよい。

次に決済システム１０４は、清算及びネッティングシステム１０３と個別決済アプリケーション１０９の両方からネット決済指示を受け取る。次いで決済システム１０４は、清算及びネッティングシステム１０３と決済アプリケーション１０９からのネット決済情報が一致することを確認することができる。

複数決済取引からの決済を含む、将来の期日に予定されているすべての決済について、清算及びネッティングシステム１０３と決済システム１０４の少なくとも一方が、万一これらの取引の決済が履行されなかった場合の中央相手方システム１００の可能な損失を判定する。次いで中央相手方システム１００は、そのような損失をカバーするのに十分な担保が維持されるようにする。このプロセス及び計算は決済前の期間に周期的に行われる。

図１のシステムの少なくとも１つの例示的実装形態では、システムは、コンピュータと蓄積プログラムと通信ネットワークとを含み、通常の売買処理では人的介入を必要としないように動作する。したがって、図１のシステムのこの例示的な実行は、全市場参加者からの相手方リスクを著しく小さくし、かつ／又は解消することにより、これまで著しい相手方リスクによって制限されていた市場における取引の高速で、効率のよい売買及び決済を可能にする。

図１１に、サーバ、コンピュータシステム、端末、あるいは、売買業者アプリケーション１０６〜１０９、清算アプリケーション１１３、決済システム１０４、又は、制御システム１０１、取引約定システム１０２、及び／もしくは清算及びネッティングシステム１０３を含む中央相手方システム１００のうちの１つ又は複数をホストするその他のコンピュータ化装置といった、図１のシステムのコンピュータ化装置１１００の説明例の機能ブロック図を示す。

図示のように、コンピュータ化装置１１００は、１つ又は複数のインターフェース１１０４（ネットワークインターフェース、無線通信インターフェースなど）、メモリ１１０６、及び記憶装置１１１０に接続された１つ又は複数のプロセッサ１１０２を含む。メモリ１１０６内には、コンピュータ化装置１１００が図１のシステムの各構成要素のために本明細書で説明するような様々な機能を実行することを可能にする命令をプロセッサ１１０２に提供するコンピュータアプリケーション／ソフトウェア１１０８が格納されている。

記憶装置１１１０は、コンピュータ化装置１１００の一部として図示されているが、コンピュータ化装置１１００に接続されたリモート記憶装置とすることもできる。さらに、単一の装置として図示されているが、コンピュータ化装置１１００は、一群のネットワーク接続サーバなど、一群の接続された装置とすることもできる。

全市場参加者からの相手方リスクの最小化や解消が重要である。さもなければ、既存のＯＴＣ商品を売買する際の相手方リスクは、市場の参加者によって負われることになるはずである。ＯＴＣ商品の例には、それだけに限らないが、外国為替、金利派生商品、債券、クレジットデリバティブ、その他が含まれる。相手方リスクの解消、より正確にはこのリスクの市場参加者からの移転は、市場に以下のような多くの利益を提供し得る。
１．高度の市場透明性及び公平な競争の場：市場に相手方売買リスクがないため、相手方売買制限が生じない。これはすべての買い呼び値及び売り呼び値を全参加者が売買できることを意味し、それによって高度に透明な市場及び全参加者に公平な競争の場が作り出される。
２．全員参加：市場において直接決済が生じないため、参加できる装置のクラスに対する制限が生じない。例えば、以前のＯＴＣ市場は選ばれた銀行、仲買人、及び商社のグループだけに制限されていたが、市場には、銀行、仲買人、機関、企業、ファンド、及び個人がアクセスできる。
３．完全な匿名性：買い手と売り手の間に直接の売買後の関係が生じないため、誰と売買したか知る必要が全く生じない。
４．売買の確実性：売買の一方の側が確認を怠り、それによって売買を中断させる可能性が生じないため、すべての売買に決済が予定されることが保証される。
５．決済の確実性：決済が相手方当事者の行為に依存しないため、すべての売買に、指定される１決済日又は複数の決済日に決済されることが保証される。

上記効力の１つ又は複数が、任意の市場参加者の不履行の結果として生じ得る、すべての相手方リスクが市場における参加者から移転されるときに実現される。その場合市場を運営する中央相手方システム１００は、相手方リスクを制御し、かつ／又は管理するより良いポジションを取り得る。中央相手方システム１００は、相手方リスクの規模及び重大性を管理し、相手方リスクが許容可能な限度内に収まるように適切な防護措置を講じる様々なシステムを含む。

次に上記各機能要素をより詳細に説明する。
図２に、本発明の諸態様による様々なメッセージフロー及びインターフェースを示す。図２では、取引約定システム２０４が売買アクセスＡＰＩ２０３に注文ブック更新を送る。次いで注文ブックが売買業者アプリケーション２０２に送られ、注文ブックが売買業者のために市場ＧＵＩディスプレイ２０１上に表示される。

市場ＧＵＩディスプレイ２０１上に表示された注文ブックに応答して、売買業者は売買アクセスＡＰＩ２０３を介して取引約定システム２０４に注文メッセージを送る。取引約定システム２０４は、売買アクセスＡＰＩ２０３を介して売買業者アプリケーション２０２に多数の応答を送る。

次いで取引約定システム２０４は、売買を約定させようと試みる。次いで取引約定システム２０４は、約定済み売買を清算及びネッティングシステム２０５に転送する。次いで清算及びネッティングシステム２０５は、決済アプリケーション２０６とやりとりして、決済アプリケーション２０６に、取引約定システム２０４から受け取られた約定済み売買が通知されるようにすることができる。これは一般に１決済日当たり１回又は複数回行われる。市場によっては、ネッティングなしで済ませ、決済システムに決済のための各個別売買を通知する方が望ましい場合もある。

また清算及びネッティングシステム２０５は、売買に関連付けられる相手方リスクのレベルも決定する。次いでリスクは担保管理システム２０８によって管理される。売買が売買業者の信用（又は売買業者の機関の信用）を超えている場合、清算及びネッティングシステム２０５は取引約定システム２０４に、その売買業者の信用レベルを超えていることを知らせる。

取引約定システム２０４は、（ａ）売買を引き受けない、（ｂ）売買を取り消す、（ｃ）売買業者又は売買業者と関連付けられた売買装置から自動的に追加担保を獲得する、（ｄ）その装置のすべての売買を中止し、そのオープン手持注文を取り消す、（ｅ）その売買装置に、ポジションを解消する注文だけを入力させる、又は以上の任意の組み合わせを含むいくつかの可能な措置を取る。

清算及びネッティングシステム２０５は、決済アプリケーション２０６に売買業者又は売買装置の現在のネット決済ポジション及び担保状況の更新を提供するために決済アプリケーション２０６とネット決済情報を交換する。

清算及びネッティングシステム２０５と取引約定システム２０４とは、売買業者又は売買業者と関連付けられた売買装置から追加担保を獲得する。追加担保の獲得は、例えば、直接、又は別の装置を介して間接的に行われる。売買が清算及びネッティングシステム２０５によって承認されている場合、清算及びネッティングシステム２０５は売買を更改し、相手方当事者の間に入る。

次に、清算及びネッティングシステム２０５と、取引の当事者と関連付けられた決済アプリケーション２０６の両方から決済システム２０７にネット決済指示が送られ、そこで最終的に決済が行われる。これは売買セッションの最後に、又はおそらくより何度も売買セッション中に行われる。１売買ごとの通知の方を選択し、ネッティングの機会なしで済ませてもよい。

最後に、取引約定システム２０４が、売買業者に新しい市場ポジションを知らせるために、売買アクセスＡＰＩ２０３を介して売買業者アプリケーション２０２に注文ブック更新を提供する。

図３に、本発明の諸態様による注文確認、約定、及び注文ブック更新に関する様々なメッセージフロー及びインターフェースを示す。図３には、売買業者の注文メッセージを受け取る売買業者端末表示及び入力３０１が示されている。取引約定システムはステップ３０２で新規注文を受け取る。注文は、破線で示すように監査証跡データベース３０３に記録されてもよい。

次にステップ３０４で、取引約定システムは、任意選択で、売買業者からの注文メッセージを検証しようとする。すべてのメッセージフィールドが有効である場合、そのメッセージは図示のようにステップ３０６で価格／時刻の優先順位で指値注文ブックに挿入される。

そうでない場合、取引約定システムは、図示のようにステップ３０５で売買業者に注文拒絶メッセージを送る。この注文拒絶メッセージは、売買業者に直接送られるため、売買業者直接メッセージとすることができる。注文は、関連する装置からの売買行為が制限を超えているために停止されている場合（ステップ３１８からの「売買停止制御」）には拒絶され得る。

ステップ３０６から、多数の追加ステップが行われる。これらの追加ステップは、同時に行われても、本明細書で説明するように様々な順序で行われてもよい。ステップ３０９で、取引約定システムは、約定のトリガを生成する。トリガは、フラグ又はその他の識別子又は後刻に処理するようシステムに要求するイベントとすることができる。

次いで取引約定システムは、図示のようにステップ３１４で指値注文ブック上の約定を行う。ステップ３１５で取引約定システムは売買が識別されるかどうか判定する。売買が識別される場合、ステップ３１６でシステムは約定済み売買メッセージを清算システム３１７（清算及びネッティングシステムともいう）に送る。

次に取引約定システムは清算システム３１７から、売買業者の信用レベルを超えていることを示すメッセージ３１８を受け取る。売買約定システムは信用超過メッセージ３１８を、売買停止制御メッセージと解釈する。

信用超過メッセージ３１８は、直前に注文メッセージを送った売買業者に関するものである場合も、その注文メッセージが注文限度ブックに書き込まれた売買業者に関するものである場合もある。どの売買業者が十分な信用又は担保を欠いているかに応じて、取引約定システムは、十分な信用を欠いている売買業者に指示を送る。

次いで売買約定システムは、十分な信用を有する売買業者に付随する注文メッセージのために検証ステップ３０４又は注文を指値ブックに挿入するステップ３０６に戻る。

代替として売買約定システムは、ステップ３１９で清算システム３１７から更改された売買を受け取ってもよい。次いで売買約定システムは、ステップ３２０で売買業者アプリケーションに売買確約メッセージを送る。

ステップ３０６からシステムは指値注文ブック３０８を更新し、ステップ３１４で指値注文ブック３０８の約定処理を行う。

ステップ３１５から、売買が識別されてもされなくても、システムはステップ３１０で、指値注文ブック３０８のブロードキャスト更新メッセージを生成するトリガを生成する。このトリガを後日のために保存し、取引約定システムが直接ステップ３１１に進んでもよい。その代わりに取引約定システムは、ステップ３１２で、注文メッセージが最良のブックを変更するかどうか判定してもよい。

最良のブックが変更されない場合、取引約定システムはステップ３１１で終了する。代替として取引約定システムはステップ３１３でネットワーク上の売買業者アプリケーション３０１にブック更新メッセージを送る。これはネットワークブロードキャストメッセージの形をとってもよい。ステップ３１３からのブック更新メッセージのブロードキャストにより、取引約定システムはステップ３１１で終了する。

一般には約定システムは注文ごとに処理を行う。すなわち、各注文の可能な約定及び可能な注文ブック更新の有無が評価され、よってステップ３０９及びステップ３１０は実施されないはずである。その順序は、（ａ）注文を注文ブック３０８に挿入する、（ｂ）すべての可能な売買を執行する（ステップ３１４）、（ｃ）どんなブック更新が必要か判定し（ステップ３１５）、更新メッセージを送る（ステップ３１６）になるはずである。

しかし、大口市場によっては、注文ごとの処理により計算処理及びネットワーク容量の要求が過大になる場合もあり、そのためシステムは、例えば１秒間に１回突き合わせを行い（ステップ３０９）、１秒間に２、３回ブック更新を送る（ステップ３１０）ように実施される。このような場合には、ステップ３０９とステップ３１０で周期的処理を実行させるようにトリガが設定される。

最後にステップ３０６から、取引約定システムは、ステップ３０７で売買業者３０１に売買業者の注文が引き受けられたというメッセージを送る。

図４に、本発明の諸態様による決済限度管理を用いた約定済み売買の更改に関連する様々なメッセージフローを示す。ステップ４０１で、清算システムが取引約定システムから約定済み売買メッセージを受け取る。清算システムは、約定済み売買メッセージを監査証跡データベース４０２に記録してもよい。

ステップ４０３で清算システムは、約定済み売買データを検証する。清算システムが（データフィールドの参照、フォーマット、範囲のチェック、その他のデータ検証を含めて）約定済み売買メッセージを検証できない場合、清算システムはステップ４０４で約定システムに約定済み売買拒絶メッセージを送り、次いで拒絶メッセージは約定システムのメッセージを保持するメッセージ待ち行列４０５に入れられる。

清算システムが約定システムの約定済み売買データを検証することができる場合、清算システムは約定済み売買メッセージを監査証跡データベース４０２に記録する。次に清算システムはステップ４０７で更改前の信用管理が可能であるかどうかチェックする。

そのような更改前の信用管理は商品ごと、決済日ごと、決済装置ごと、又はその他に基づいて可能とされる。例えばある一定のグロスサイズを超えるすべての売買について、又は決済が３０日より先のすべての売買について、又はある特定の国の装置によって保証されるすべての売買について更改前の信用管理チェックを行うことが望ましい。現在の売買について更改前の信用管理が可能でない場合、清算システムはステップ４０８で、約定済み売買引受けメッセージを約定システム待ち行列４０５に挿入することにより約定システムに送る。

ステップ４０７で更改前の信用管理が可能であるとチェックされた場合、清算システムは、ステップ４０９で、デフォルトリストから、又は売買約定システムからのメッセージデータから保証清算メンバを識別する。次に清算システムはステップ４１０で、現在の約定済み売買が売買業者の信用限度を超えるかどうか判定する。ステップ４１０で信用限度を超えなかった場合、清算システムはステップ４０８で約定システムに約定済み売買引受けメッセージを送る。

一方、信用レベルを超えた場合には、清算システムはステップ４１１で約定システムに約定済み売買拒絶メッセージ（信用超過メッセージなど）を送る。次いで約定済み売買拒絶メッセージは、約定システムメッセージ待ち行列４０５に挿入される。４１２の清算メンバ及び信用管理データベースは、売買業者の保証清算メンバならびに／又は売買業者及び／もしくは売買装置の信用限度のデフォルトリストを提供する。

図５に、本発明の諸態様による、売買代行を用いた決済前売買ネッティングによる様々なメッセージフローの説明例を示す。

一般に決済前ネッティングは典型的には、一部外部決済システムの要件に従って決定されるイベントの予定に従って執行される。決済システムは所与の期日の、指定された期間内だけの決済の売買を引き受ける。例えば所与の日に２つの売買が、一方はニューヨーク時間午後３時に、他方はニューヨーク時間午後８時に執行されるとする。

どちらの売買も同日に発生したが、これらの売買は、両売買の指定決済システムの決済窓口が、第１の売買では開いていたが、第２の売買では終了していて、第２の決済が翌決済日に繰り越されたために異なる日に決済される。

決済前ネッティングシステムは、決済システムの要件に従って売買を処理する。これらの要件に基づきネッティングシステムは、そのネッティング計算を行い、決済装置と外部決済システムとにメッセージを送る。

図５には、決済前売買ネッティング及び売買代行プロセスの説明例が示されている。ステップ５０１でネッティングシステムは、決済システムの決済窓口開始時刻と決済窓口終了時刻に関するメッセージを受け取る。このメッセージは規則的に送られてもよく、決済システムからの以前の情報に基づく既知の窓口期間とすることもできる。

次にステップ５０２で、ネッティングシステムは絶えず日付と時刻を監視し、決済窓口開始時刻にトリガする。次にステップ５０３でネッティングシステムは、例えば商品と、決済日と、決済装置と、（当事者がグロスではなくネットで決済することを望んだことを示す）ネット決済標識とによりすべての売買を選択する。

ここで決済前ネッティングは、商品ごと、決済日ごと、決済装置ごとに、グロス決済ではなく、ネット決済とマークされている売買についてだけ行われる。

次にステップ５０４で、各商品、期日、決済装置ごとに、ネッティングシステムは決済される各資産（資産１、資産２、…）ごとの金額の総和を計算する。中央相手方システムが受け取る正の金額と、中央相手方システムが支払う負の金額のすべての金額が差し引きされる。

次にステップ５０５で、ネッティングシステムはすべての個別の（ネット）決済を単一のネット決済で置き換える。
ステップ５０５から、ネッティングシステムはネット決済代行を行い、それによってステップ５０７で売買を更改する。次いでネッティングシステムはステップ５０８で関連する清算装置にネット決済メッセージを送る。

加えてシステムは、ステップ５０６で次の商品に対処する必要があるかどうか判定する。ＹＥＳの場合、システムはステップ５０３に戻って次の商品を処理する。そうでない場合、システムはステップ５０８に進む。ここで、ステップ５０６とステップ５０７は、同時に行われても、連続してどちらかのステップが他方の前に行われてもよい。さらに別の例では、ステップ５０６がステップ５０８の後に行われてもよい。

別の例では、１組の売買が、ステップ５０８で処理されるようなネット取引ではなく差し引きされて単一の利益又は損失値とされる。例えばこの利益又は損失は、決済システムの外部で決済されてもよい。これに関しては、ネット決済が前述の決済システムによって処理され、単一の利益又は損失金額が別のシステムで決済される。

自動化決済及びネッティングは、各商品に関する受取りメッセージその他の情報が一貫性を有するときに有用である。例えば、あらゆる商品がサンプルとしてその好ましい決済方法及び決済機関を指示しており、この情報が米ドル／日本円現物市場において以下のように表示されるとする。

ＵＳＤ／ＪＰＹ現物（商品）、決済方法（現金）、決済機関（ＡＢＣ銀行）
また、あらゆる売買が１つ又は複数の決済を有する。例えば、ある売買に付随するメッセージが以下のように表示される。

ＵＳＤ／ＪＰＹ現物は約定日＋２日に決済される（休日及び週末に左右される）
ＥＵＲ／ＵＳＤ１ヵ月は１回の現物決済及び１回の先物決済を行う
あらゆる決済は決済日、資産の明細、及び決済金額を有する。例えばある決済に付随するサンプルメッセージは以下のように表示される。

ＵＳＤ／ＪＰＹ現物決済、期日＝４／４／２００６、
資産１＝ＵＳＤ、資産２＝ＪＰＹ、
決済金額１＝１０，０００，０００、
決済金額２＝−１２０，０００，０００
正の決済金額が中央相手方システムによって受け取られ、負の決済金額が中央相手方システムによって支払われる
次に決済は、ネットで決済するかそれともグロスで決済するか指定される。
さらに各決済機関は、各決済日ごとの窓口開始時刻と窓口終了時刻を有する。
さらに、個々の商品の個々の決済日の売買終了までにネット決済処理がトリガされる。
最後に、価値期日繰延べ時刻が、個々の商品の窓口開始時刻より後にならないように指定される。

＜６．売買業者ＡＰＩ＞
図６に、本発明の諸態様に従って使用され得るアプリケーションプログラミングインターフェース及び売買業者端末を示す。例示的な売買業者端末６０７は、売買業者のためのインターフェースを提供し、ある種の１つ又は複数のハードウェアインターフェース装置６０９（キーボード、マウス、トラックボール、音声認識ソフトウェア付きマイクロホンなど）を含む処理装置とすることができる。

また、売買業者端末６０７は、ユーザインターフェースを持たず、売買業者のために自動化されたやり方で取引を処理するだけの自動化端末とすることもできる。売買業者端末６０７は従来の意味での「端末」ではなく、むしろ、そのソフトウェアとして実施される規則に基づいて自動化売買を行うソフトウェアアプリケーション（いわゆる「ブラックボックス」直接売買）とすることもできる。

売買業者端末６０７は、アプリケーションプログラミングインターフェース６０２を使用し、ネットワーク６０１を介してシステムの他の構成要素とメッセージを交換する。アプリケーションプログラミングインターフェースには、それだけに限らないが、以下のものが含まれる。まず、市場情報６０３がディスプレイ６０８に表示するために売買業者端末６０７に提供される。市場情報は、単なる個々のブックとして、あるブックの後にそのブックの増分更新が続くものとしてなど、様々なやり方で送られる。市場情報の表示は、注文ブック、市場における売買、価格履歴、商品の高値と安値、及び関連付けられる数量を含む。

次にＡＰＩ６０２は、売買業者に、ネットワーク６０１に送られる注文メッセージを作成させる注文入力機能６０４をサポートする。注文入力機能は、指値注文の入力、成行注文の入力、スプレッド注文の入力、不確定注文の入力、以前に出した注文の取り消しが含まれる。

さらにＡＰＩ６０２は、売買報告書６０５の処理も含む。売買報告書６０５の処理は、どの報告書又はどの種類の報告書が求められているか、及び／又は報告書の受渡しを指定する、売買業者端末６０７からネットワーク６０１にアップストリームで流れる情報を含む。報告書は、当分野で公知のように、静的なものとすることも動的なもの（リモートの発信元からリアルタイム情報を受け取り、それを売買業者に表示される情報に組み込むもの）とすることもできる。例えば報告書は、執行された注文と決済債務履行の概要に関する情報を含む。

最後にＡＰＩ６０２は、売買業者が新しい市場情報を理解し、システムにおいて追加の売買を執行するのを助ける追加アプリケーション６０６のサポートを含んでいてもよい。追加アプリケーションには、自動化売買プログラム及び／又はアルゴリズム売買プログラムに分析情報又はグラフを提供するアプリケーションが含まれていてもよい。さらに追加アプリケーションは売買業者のための分析ツールを提供してもよい。

＜７．取引約定＞
図７に、本発明の諸態様による取引約定システムの様々な機能構成要素を示す。取引約定システムは、取引約定システムと、おそらくは中央相手方システムの残りの部分に対してユーザを認証する任意のユーザ認証モジュール７０１を含む。ユーザ認証は、ユーザの識別情報、及びユーザが関連付けられる組織の識別情報、及びユーザと関連付けられるべき決済エージェントを検証する。

また取引約定システムは、受け取った注文メッセージを処理する注文処理モジュール７０２も含む。受取り注文の処理は、メッセージの受信のデータベースへの記録、注文の検証、及びその他のステップを含む。注文処理モジュールは、新規注文も既存の注文の取り消しも処理する。

また取引約定システムは、ブック更新構成要素７０５を含むブック管理モジュール７０４も含む。ブック管理モジュール７０４は、様々な売買業者が見る注文ブックを管理する。ブック更新構成要素７０５は、メッセージの生成及びネットワークを介した様々な売買業者へのメッセージの転送を処理する。

取引約定システムはさらに、約定済み売買と、これらの約定済み売買の交換と、それに続く清算及びネッティングシステム７０７との更改された売買を処理する取引処理モジュール７０６を含む。

＜８．清算及びネッティング＞
図８に、本発明の諸態様による、清算及びネッティング構成要素を示す。清算及びネッティングシステムは、モジュール８０２において約定システム８０１から約定済み売買通知を受け取る。また清算及びネッティングシステムは、約定システム８０１への受信確認も行う。

清算及びネッティングシステムは、すべての決済詳細８０４を決定、生成し、ネット／グロス決済金額８０５の割り当てを処理し、売買当事者の決済エージェントのための売買確認メッセージ８０６を生成する売買更改モジュール８０３を含む。清算及びネッティングシステムは、決済ポジション８１２と、例えば商品ごと期日ごとに中央相手方システムが負う最大損失の分析８１３と、売買業者に多少の信用又は担保を要求するリスク軽減８１４とに関する情報を提供するリスク管理モジュール８０７を含む。

清算及びネッティングシステムはさらに、売買業者ごとのすべての売買のネット売買への更改８０７aを提供し、最終ネット決済ポジション８１５を提供する決済前ネッティングモジュール８０８を含む。最後に決済前ネッティングモジュールは、決済アプリケーション１〜Ｎ ８０９〜８１１に決済情報を出力する。

本発明のいくつかの態様では、清算及びネッティングシステムは、ほとんどの状況において人的介入なしで清算及びネッティングを行うことができる。

＜９．システム関連の決済システム＞
図９に本発明の諸態様による決済システムを示す。決済システム９０１は、支払い１ ９０２を行い、売買当事者から支払い２ ９０３を受け取る。また決済システム９０１は、市場参加者にその資金状況を知らせる資金メッセージ９０４送る。さらに決済システム９０１は、売買装置と関連付けられた決済アプリケーションに決済メッセージ９０５も送る。

本発明のいくつかの態様では、決済システムはほとんどの場合、人的介入なしで決済を行うことができ、それによって決済プロセスが合理化される。

＜１０．売買業者関連の決済アプリケーション＞
図１０に、本発明の諸態様による決済アプリケーションを示す。決済アプリケーション１００１は、売買装置と関連付けられ、又は売買装置によってその決済を処理するように指定される。決済アプリケーション１００１は、絶えず売買確認メッセージ１００２を受け取り、既定のデフォルト及び指標に基づいてネット決済ポジションを計算する自動化システムとすることができる。各取引日の終了時には、例えば中央清算システムなどによって通知されるように、決済アプリケーション１００１はネット及び／又はグロス決済情報を決定する。

次いでこの情報は中央相手方システムと交換される。すべての関連価値が一致する場合、決済情報は決済指示１００４として清算及びネッティングシステムならびに／又は中央相手方システムと関連付けられた決済システム又は外部決済システムにさえも送られる。次いで決済アプリケーション１００１は、完了決済の受領書１００５を受け取る。最後に決済アプリケーション１００１は、中でも特に、ネット取引詳細及び支払い金額を示すネット決済メッセージ１００３を受け取る。

本発明のいくつかの態様では、売買業者関連の決済アプリケーションは、ほとんどの場合人的介入なしで上記決済システムと決済を行うことができ、それによって売買業者の決済プロセスが合理化される。

＜１１．実施例＞
以下は、中央相手方システムとのネット対グロス決済指標の説明例である。
第１の説明例の組は外国為替（ＦＸ）商品の取引に適用されるものである。具体的には、現物ＦＸ、先物ＦＸ、及びＦＸオプション市場におけるグロス対ネット決済の業務理論を説明する。

（実施例１：）
商業銀行の財務部門は企業顧客にＦＸ取引サービスを提供する。
この例では、商業銀行が中央相手方システムＦＸ売買サービスのユーザであり、その法人顧客に代わって市場に注文を出す。銀行の顧客は通常、（そうであってもよいが）銀行や金融機関自体ではない。この例では銀行の顧客は外国為替エクスポージャーを有する企業である。

例えば、完成品を外国顧客に売り、外貨で支払いを受ける企業は、それらの支払いをその国内通貨に換算する必要があり、そのためにその商業銀行のＦＸ取引サービスを利用することになる。別の例として、物品の商業生産者が外国の供給元から原材料を購入し、外貨で支払う必要がある場合もあり得る。この場合生産者は、将来の購買のためにＦＸレートを「固定」し、それによって上下するＦＸレートの変動性及びリスクを回避しようとする。

商業銀行は通常、様々な規模と売買頻度の多数の企業顧客を有する。最大規模の顧客は、ＦＸエクスポージャーを積極的にヘッジする場合には、毎日複数のＦＸ取引に参加する。より小規模の顧客は月１回程度ＦＸ取引に参加する。

企業顧客が外貨の実際の受渡しを必要とするＦＸ取引に参加することになる事例には多くの場合がある。例えば顧客は、日本円で支払いを受け取り、その日本の銀行口座に入金しており、この支払いを可能な限り速くＵＳＤに換金しようとするとする。この場合企業はその銀行に電話をかけ、現物受渡しでＪＰＹを売りＵＳＤを買うよう要求する。銀行はこの取引がネッティングの対象とされないようにしなければならならず、さもないと、必要とされる通貨が、現物受渡し日に企業顧客に供与されなくなることもある。

場合によっては、企業顧客が、決済のためにいくつかの取引をネッティングされることを望むこともある。例えば、ある米国企業が６ヵ月のうちに仏国生産者から原材料を購入し、このためにユーロを支払おうとしているとする。この企業はこの６ヵ月間にＵＳＤに対してユーロの価値が変動する可能性の影響を受けることを望まない。

変動をヘッジするために企業は、ユーロの現物買いとユーロの先物スワップ売りの２つの取引に参加する。ユーロの現物買いが本日のユーロ／ＵＳＤ為替レートに固定され、先物スワップが現物決済を清算してその購入を６ヵ月先の期日に「ロール」する。

ＦＸ先物スワップとは、金利差によってリンクされるレートを有する、同じ金額で、逆方向の現物取引と先物取引であることに留意されたい。実際には企業は、６ヵ月後の受渡しのためにユーロを購入しており、本日付の現物レートと本日付の金利差に固定している。

このヘッジが最も有効になるように、企業は２つの現物取引をネット決済し、それによってこれらを差し引きしてゼロにし、単一の先物取引だけが残るようにしようとする。以下の表にこれら２つの取引を示す。

上記表に示すように、取引１は、米ドルの売り（Ｓ）に対するユーロの現物買い（Ｂ）である。これは１．２５７０の現物レートに固定されている。取引２は、６ヵ月現物／先物スワップによりこの現物エクスポージャーを６ヵ月先に「ロール」する。このスワップはユーロを現物で売り、６ヵ月先に買い戻す。６ヵ月レートは本日の現物レートと２つの通貨の預金の６ヵ月金利差によって決まる。
これら２つの取引のネット決済により本日の現物レートに基づく単一のユーロの先物買いとＵＳＤの売りがもたらされる。

この結果を達成するために商業銀行は、２つの取引がネット決済され、それによって現物決済ポジションが中和されることを示さなければならない。実際、商業銀行は、これら２つの取引が、他のいかなるネッティング可能な取引とでもなく、これらの取引同士でネット決済されるべきであることを示すために、これら２つの取引をネット決済用の別の口座に入れようとする。

よって商業銀行は、ネット／グロス決済機関のユーザが取引ごとに、どの取引がネット決済に適格であり、どの取引がグロス決済に適格であるか指示すべきことを要求している。さらに商業銀行は、例えば単一顧客からの、他のネット決済される取引とではなく相互にネッティングされる取引の組を識別する必要もある。

（実施例２：）
この例は、複数の資産クラスの売買を行う銀行の財務部門の自己売買に関するものである。

この例では、大規模銀行の財務部門は、あたかも社内ヘッジファンドであるかのように運用する社内自己売買デスク（いわゆる「プロップ取引」）を有する。社内自己売買デスクは、外国の株式及び債券の売買、ならびに別個の資産クラスとしてのＦＸの売買に積極的に関与する。

外国有価証券の売買は一般に関連する外国為替取引を伴う。例えば、あるファンドが１億円相当の日本株を購入する場合には、その株売買の決済日当日又はそれ以前にＪＰＹを獲得することによってこの購入に資金供給することが必要になる。ＵＳＤベースのファンドがユーロ建て債券のポジションを所有し、それらの債券を売る場合、このファンドは決済日にユーロを米ドルに戻そうとする。

最後に、ユーロ債券のポジションを所有するファンドは、その債券の利子支払い（利札）を、それが１年に４回のうち２回支払われるときに定期的に本国に送金しようとする。

これらの例すべてにおいて、外国有価証券（債券又は株式）の取引は、ある通貨を別の通貨に換金するためのＦＸ市場における取引を必要とする結果を生じた。取引は実際、特に証券決済に資金供給するのに使用される場合には、必要とされる通貨を受渡ししなければならない。異なる仲買人又は取引所にまたがって支払いをネッティングすることができないことは明らかである。したがって、これらの証券売買関連のＦＸ取引の大部分はグロス決済を必要とする。

しかし、ファンドが別個の、すなわち基礎をなす他の何らかの資産の売買と関連付けられない資産クラスとしてＦＸも積極的に売買する場合、ファンドは一般に結果として生じる売買すべての決済をネッティングしようとする。例えばプロップ取引戦略には、短期売買パターンに基づいて取引日の終日にわたって買い信号と売り信号を出す「運動量取引」アルゴリズムが関与する。その場合これらの信号は、ソフトウェアプログラムを使って執行される、ＥＵＲ／ＵＳＤなど、単一の通貨対の複数の買い取引と売り取引を生じさせる。

「アルゴリズム取引」とも呼ばれるこのプロセス全体により、一日の間に何百もの取引を生じさせることができ、ほとんどの場合、これらの取引全てがネッティングされてそのファンドの単一の利益、又はおそらくは損失とされる。これらの取引はすべて単一の決済にネッティングされる。

よって自己売買デスクの例は、システムの単一ユーザが、売買によってグロスで決済させるものとネット決済させるものとを指定する必要を示している。

（実施例３：）
この例は、ネット決済を受ける非ＦＸ取引に関するものである。
この例では、外国為替の範囲外の取引に焦点を当てる。これらの取引は中央相手方（ＣＣＰ）システムを用いたグロス／ネット決済指標の利益を示すものである。具体的にはこの例では、金利先渡取引（ＦＲＡ）と金利スワップ（ＩＲＳ）を含む金利派生商品（ＩＲＤ）が使用される。

金利先渡取引とは基本的には将来のある時点から開始する期間の期間金利に関するヘッジである。例えば、ある企業が、３ヶ月後に、その企業の業務に資金供給するのに６ヵ月間にわたる１０００万ドルの借入れが必要になることが分かっているものとする。言い換えると企業は、将来の３ヶ月後のある時点に６ヵ月間の融資を受けることになる。

借入金利は、ほとんどの場合、ＬＩＢＯＲやＥＵＲＩＢＯＲといった「銀行間為替相場」との何らかの差に基づくものである。企業は、例えば、「ＬＩＢＯＲと１ポイント差」で支払うことになると知っているが、企業は、本日の時点では、３ヵ月後に６ヵ月ＬＩＢＯＲがいくらになるか知らない。そのため、このリスクを管理するために企業は、「３×９ＵＳＤ ＦＲＡ」（「３×９米ドル金利先渡取引と読む」）と呼ばれるものに参入する。３×９は、ＦＲＡが３ヵ月後に決済され、その時点における６ヵ月（９−３）のレートを見ることになるという意味である。

ＦＲＡが取引される時点において買い手と売り手は金利に同意し、この金利は、買い手と売り手とが、３ヵ月後に６ヵ月ＬＩＢＯＲが到達すると期待するレートである。３ヵ月後、取引で同意されたレートは、実際の６ヵ月ＬＩＢＯＲ（又はフェデラルファンドもしくは他の何らかの同意されたベンチマーク）と比較され、ＦＲＡのレートとベンチマークとの差が取引の当事者間で交換される。ＣＣＰとの売買の場合、価値の交換は、売買の相手側当事者システムとではなく、中央相手方システムとの間で行われる。

ＦＸ取引と異なり、ＦＲＡは、２つの通貨の交換ではなく、一方の当事者から別の当事者への単一通貨の支払いを伴う。

金利スワップとは一連のバックツーバックＦＲＡである。例えば、固定利札債券の発行者は、１年に２ないし４回その債券所持人に固定金利を支払う義務を有する。例えば、ある１０年債券が四半期ごとに支払うべき５％利札を有し、この債券発行者は１億ドル分のこれらの債券を販売しているものとする。

この例では、債券発行者は債券所持人に、向こう１０年にわたり四半期ごとに１２５万ドルを支払う必要がある。加えて、債券発行者は通常、ＬＩＢＯＲに基づく短期借入によって自社の業務に資金供給するものとする。この場合、債券発行者が変動で支払い、固定で受け取る固定／変動１０年の「単純な」金利スワップに参加することは、債券発行者の利益にかなう。

固定で受け取ることにより債券発行者にはその５％の利札支払いが十分にヘッジされることが分かる。変動で支払うことにより債券発行者は、その費用がその借入コストに連動されることが分かる。この１０年取引は、一連の４０個の３ヶ月ＦＲＡと論理的に等価である。

ＦＲＡ決済又はＩＲＳ決済は基本的には、取引時に同意されたレートと、決済時に優勢なレートの間の値洗い差の支払いになるので、これらの支払いをグロス決済する裏付けとなる業務上の必要が生じない。多くの場合、ＦＲＡ又はＩＲＳの単一通貨決済を同日の他の取引の決済債務とネッティングする機会が生じると、決済運用の複雑さが全般的に低減される。

またＦＲＡとＩＲＳはＦＸ売買戦略の構成要素としても使用され得る。外国為替レートは基本的に基礎となる金利に連動するため、関連付けられる金利が変動するとその価値が劇的に変動するＦＸポジションを取ることが可能である。これらの金利の変動をヘッジし、又はそこから利益を得るために、ＦＸ戦略の一部としてＦＲＡ又はＩＲＳポジションを取ってもよい。

例えば、低ＵＳＤ金利が米経済の成長に拍車をかけ、結果として米国株の優れた業績がもたらされると考える場合、ＵＳＤ建て投資の需要が増大するため、ユーロに対する米ドルの価値が上がると考えられる。この売買戦略は、ＵＳＤが６ヵ月間にわたり強まるに従い現物ＥＵＲ／ＵＳＤレートが弱まると見込んで、ショートＥＵＲ／ＵＳＤ６ヵ月ポジション（すなわちドルロング、ユーロショート）を保持するものである。しかし、ＵＳＤ金利の反対の動き（すなわちフェデラルファンドレートの上昇）が生じれば、このポジションは根底から揺るがされることになり得る。

これをヘッジするために、１×７ＦＲＡに参入して、ＵＳＤ金利を基本的に本日付のポイントに固定することもでき、自己のＦＸポジションの損失は、そのＦＲＡポジションの利得によって相殺されるはずである。明らかにこの例では、関連する取引のネット決済の方が、別々の部分のグロス決済よりも好ましい。

金融取引における決済での相手方リスクを制限し、又は解消するコンピュータ化された装置、システム及び方法が説明される。中央相手方システムが相手方当事者間の取引を更改し、各相手方当事者が決済を行う相手方の装置として中央相手方システム自体が間に入る。中央相手方システムは、この中央相手方システムが対処できないリスクを負うことのないように相手方当事者から追加の信用又は担保を要求してもよい。

以上、本発明の主題を構造的特徴と方法論的動作について説明した。しかし、添付の特許請求の範囲で定義される本発明の主題は、必ずしも前述の特徴又は動作だけに限定されるとは限られない。

前述の特有の特徴及び動作は、特許請求の範囲を実施する例示的形態として開示するものである。上記実施形態を考察することにより、当業者には、添付の特許請求の範囲に記載される技術思想の範囲及び精神に含まれる他の多くの実施形態、改変形態、及び変形の形態が想起される。

Claims (28)

1. コンピュータ可読命令を格納するメモリと、ネットワークインターフェースと、前記ネットワークインターフェース及び前記メモリと通信状態にあるコンピュータプロセッサとを備える仲介システムのネット決済計算装置であって、
   前記コンピュータプロセッサが、
   それぞれが金融商品の１対の相手方当事者間のものであり、それぞれが決済日、数量及び価格を有する複数の約定済み売買を識別するデータを受け取るステップと、
   各約定済み売買を、前記仲介システムと前記１対の相手方当事者の第１の相手方当事者システムとの間の第１の更改された売買と、前記仲介システムと前記１対の相手方当事者の第２の相手方当事者システムとの間の第２の更改された売買とに更改するステップであり、前記第１の更改された売買と前記第２の更改された売買がそれぞれ、前記対応する約定済み売買の前記金融商品の前記決済日、前記数量及び前記価格を維持するステップと、
   前記第１と第２の更改された売買の決済日を含む基準に基づき、現在売買後決済前ネッティングに適格である前記第１と第２の更改された売買の現在適格な売買を識別するステップと、
   前記現在適格な売買の売買後決済前ネッティングを実行するステップであり、
   前記現在適格な売買の第１の売買の第１の決済相手方当事者システム及び前記第１の現在適格な売買の第１の金融商品を含む第１の選択基準に基づき、前記現在適格な売買の中からネッティングのための第１の売買の組を選択するステップと、
   前記第１の売買の組の中から、前記第１の決済相手方当事者システムと前記第１の金融商品のネット売買を計算するステップと、
   前記第１の売買の組を前記ネット売買で代行するステップと
   を含むステップと、
   を含む各ステップを実行するように構成されてなることを特徴とするネット決済計算装置。
2. 売買後決済前ネッティングを実行する前記ステップが、
   （ａ）前記第１の基準の組の前記第１の決済相手方当事者システムによって売買される前記現在適格な売買の各金融商品、
   （ｂ）前記第１の金融商品と同じであり、又は異なる第２の金融商品の前記第１の決済相手方当事者システムに加えて前記現在適格な売買の各相手方当事者システム、及び
   （ｃ）前記第２の金融商品に加えてグループ（ｂ）の各相手方当事者システムによって売買される前記現在適格な売買の各金融商品、
   を含む追加の選択基準の組に基づいて、前記選択するステップと、前記計算するステップと、前記代行するステップを繰り返すステップを含むことを特徴とする請求項１に記載のネット決済計算装置。
3. 売買後決済前ネッティングを実行する前記ステップが、前記ネット売買の情報を清算装置送るステップを含むことを特徴する請求項１に記載のネット決済計算装置。
4. 売買後決済前ネッティングを実行する前記ステップが、前記ネット売買の情報を前記第１の決済相手方当事者システムに送るステップを含むことを特徴とする請求項１に記載のネット決済計算装置。
5. データを受け取る前記ステップについて、各約定済み売買ごとの前記データが、それぞれ前記約定済み売買の相手方当事者システムと関連付けられており、前記関連付けられた相手方当事者システムが前記約定済み売買にネット決済を望むかどうか指示する１対のネット指標を含み、
   前記更改するステップが、前記更改された売買がネット適格であるかどうか識別するために、前記第１と第２の相手方当事者システムのそれぞれと関連付けられた前記ネット指標を前記対応する更改された売買と関連付けるステップを含み、
   前記第１と第２の更改された売買の現在適格な売買を識別する前記ステップについて、前記基準が前記売買のネット指標を含むことを特徴とする請求項１に記載のネット決済計算装置。
6. 前記ネット指標を前記関連付けられた相手方当事者システムのデフォルトのネット指標とすることができることを特徴とする請求項５に記載のネット決済計算装置。
7. 前記デフォルトのネット指標が前記関連付けられた相手方当事者システムによって事前選択される金融商品と一致することを特徴とする請求項６に記載のネット決済計算装置。
8. 前記デフォルトのネット指標がネット決済のデフォルト条件を有することを特徴とする請求項６に記載のネット決済計算装置。
9. 前記デフォルトのネット指標がグロス決済のデフォルト条件を有することを特徴とする請求項６に記載のネット決済計算装置。
10. 各ネット指標が、前記ネット指標と一致する前記更改された売買の売買後決済前ネッティングを実行する前記ステップの前に、前記関連付けられた相手方当事者システムによって変更され得ることを特徴とする請求項６に記載のネット決済計算装置。
11. 各ネット指標がもう一方の相手方当事者システムから独立に前記関連付けられた相手方当事者システムによって設定され得ることを特徴とする請求項５に記載のネット決済計算装置。
12. 金融取引における相手方リスクを移転する方法であって、
    仲介システムにおいて、それぞれが金融商品の１対の相手方当事者のものであり、それぞれが決済日、数量及び価格を有する複数の約定済み売買を識別するデータを受け取るステップと、
    各約定済み売買を、前記仲介システムと前記１対の相手方当事者の第１の相手方当事者システムとの間の第１の更改された売買と、前記仲介システムと前記１対の相手方当事者の第２の相手方当事者システムとの間の第２の更改された売買とに更改するステップであり、前記第１の更改された売買と前記第２の更改された売買がそれぞれ、前記対応する約定済み売買の前記金融商品の前記決済日、前記数量及び前記価格を維持するステップと、
    前記第１と第２の更改された売買の決済日を含む基準に基づき、現在売買後決済前ネッティングに適格である前記第１と第２の更改された売買の現在適格な売買を識別するステップと、
    前記現在適格な売買の売買後決済前ネッティングを実行するステップであり、
    前記現在適格な売買の第１の売買の第１の決済相手方当事者システム及び前記第１の現在適格な売買の第１の金融商品を含む第１の選択基準に基づき、前記現在適格な売買の中からネッティングのための第１の売買の組を選択するステップと、
    前記第１の売買の組の中から、前記第１の決済相手方当事者システムと前記第１の金融商品のネット売買を計算するステップと、
    前記第１の売買の組を前記ネット売買で代行するステップと
    を含むステップと
    を含むことを特徴とする相手方リスク移転方法。
13. 売買後決済前ネッティングを実行する前記ステップが、
    （ａ）前記第１の基準の組の前記第１の決済相手方当事者システムによって売買される前記現在適格な売買の各金融商品、
    （ｂ）前記第１の金融商品と同じであり、又は異なる第２の金融商品の前記第１の決済相手方当事者システムに加えて前記現在適格な売買の各相手方当事者システム、及び
    （ｃ）前記第２の金融商品に加えてグループ（ｂ）の各相手方当事者システムによって売買される前記現在適格な売買の各金融商品
    を含む追加の選択基準の組に基づいて、前記選択するステップと、前記計算するステップと、前記代行するステップを繰り返すステップを含むことを特徴とする請求項１２に記載の相手方リスク移転方法。
14. 売買後決済前ネッティングを実行する前記ステップが、前記ネット売買の情報を清算装置に送るステップを含むことを特徴とする請求項１２に記載の相手方リスク移転方法。
15. 売買後決済前ネッティングを実行する前記ステップが、前記ネット売買の情報を前記第１の決済相手方当事者システムに送るステップを含むことを特徴とする請求項１２に記載の相手方リスク移転方法。
16. データを受け取る前記ステップについて、各約定済み売買ごとの前記データが、それぞれ前記約定済み売買の相手方当事者システムと関連付けられており、前記関連付けられた相手方当事者システムが前記約定済み売買にネット決済を望むかどうか指示する１対のネット指標を含み、
    前記更改するステップが、前記更改された売買がネット適格であるかどうか識別するために、前記第１と第２の相手方当事者システムのそれぞれと関連付けられた前記ネット指標を前記対応する更改された売買と関連付けるステップを含み、
    前記第１と第２の更改された売買の現在適格な売買を識別する前記ステップについて、前記基準が前記売買のネット指標を含むことを特徴とする請求項１２に記載の相手方リスク移転方法。
17. 前記ネット指標を前記関連付けられた相手方当事者システムのデフォルトのネット指標とすることができることを特徴とする請求項１６に記載の相手方リスク移転方法。
18. 前記デフォルトのネット指標が前記関連付けられた相手方当事者システムによって事前選択される金融商品と一致することを特徴とする請求項１７に記載の相手方リスク移転方法。
19. 前記デフォルトのネット指標がネット決済のデフォルト条件を有することを特徴とする請求項１７に記載の相手方リスク移転方法。
20. 前記デフォルトのネット指標がグロス決済のデフォルト条件を有することを特徴とする請求項１７に記載の相手方リスク移転方法。
21. 各ネット指標が、前記ネット指標と一致する前記更改された売買の売買後決済前ネッティングを実行する前記ステップの前に、前記関連付けられた相手方当事者システムによって変更され得ることを特徴とする請求項１７に記載の相手方リスク移転方法。
22. 各ネット指標がもう一方の相手方当事者システムから独立に前記関連付けられた相手方当事者システムによって設定され得ることを特徴とする請求項１６に記載の相手方リスク移転方法。
23. 金融取引における相手方リスクを移転する方法であって、
    清算及びネッティングシステムにおいて、金融商品の複数の相手方当事者システムの複数の約定済み売買を識別するデータを受け取るステップと、
    前記約定済み売買をそれぞれ、中央相手方システムと前記複数の相手方当事者システムとの間の別々の売買に更改するステップと、
    前記相手方当事者システムの決済前ネッティングを実行するステップと、
    決済システムに、少なくとも、前記中央相手方システムと前記複数の相手方当事者システムのそれぞれとの間で決済される前記別々の売買に関する情報を含む決済情報を送るステップと、
    を含むことを特徴とする相手方リスク移転方法。
24. 前記決済システムが、前記送られる決済情報に基づいて支払い対支払い決済を行うことができることを特徴とする請求項２３に記載の相手方リスク移転方法。
25. 人的介入なしで決済を行うことができることを特徴とする請求項２３に記載の相手方リスク移転方法。
26. 間に約定済みであるが未決済の売買が存在する第１の相手方当事者システムと第２の相手方当事者システムの間の売買を遂行するシステムであって、
    前記約定済みであるが未決済の売買を更改し、前記約定済み売買が、前記第１の相手方当事者システムと前記清算及びネッティングシステムの間の第１の取引と、前記第２の相手方当事者システムと前記清算及びネッティングシステムの間の第２の取引とによって置き換えられるように間に入る清算及びネッティングシステムと、
    前記第１の取引及び前記第２の取引を決済する決済システムと、
    を備えることを特徴とする売買遂行システム。
27. 前記清算及びネッティングシステムが、前記約定済みであるが未決済の売買を更改する前に、前記第１及び第２の相手方当事者システムの一方から追加信用を獲得することを特徴とする請求項２６に記載の売買遂行システム。
28. 前記決済システムが、前記相手方当事者システムの一方と前記清算及び約定システムの間の前記取引の１つを、前記相手方当事者システムの前記一方によって指定されるように他の取引を用いてグロス又はネットで決済することを特徴とする請求項２６に記載の売買遂行システム。

Images