(57)【要約】トレーダー、マーケットメーカー、ディーラー及びプライムブローカが多数の流動性プロバイダと同時に交渉し、かつ実時間で取引処理用指令及び決済命令を受信し応答できるようにする、多数の契約相手のための金融取引を管理するための方法及び装置。標準ウェブブラウザを用いてならびにプロプラエタリーユーザーインターフェースを介して、インターネットといったような相互接続されたデータ通信網上でアクセス可能である本発明は、顧客、トレーダー、実行銀行、資金調達銀行、プライムブローカ、及び、以前に実行された金融取引について流動性割当の詳細を、受信するに従って自動的に提供する。
2005530281.tif 000002
【特許請求の範囲】
【請求項１】
以前に実行された金融取引を処理するためのコンピュータシステムにおいて、
−  データ通信網に対するインタフェース；
−  メッセージデータベース；
−  前記インタフェースに結合され、
・  データ通信網を介して遠隔コンピュータに対するオンライン接続を確立する、
・  以前に実行された金融取引に関する詳細セットを含む入メッセージを、オンライン接続を介して遠隔コンピュータから受信する、
・  前記データベース内に入メッセージを記憶する、
ように構成されている決済用プロセッサ；及び
−・  前記データベースから前記入メッセージを検索する、及び
・  入メッセージ内の詳細セットと前記データベース内に記憶された第２のメッセージ内の第２の詳細セットの間にマッチが存在するか否かを決定する、
ように構成されているマッチングサブシステム；
を含んで構成され、
マッチが存在する場合には、決済用プロセッサはさらに以前に実行された金融取引を計上するように構成されている、コンピュータシステム。
【請求項２】
決済用プロセッサがさらに、以前に実行された金融取引を計上する前に前記オンライン接続を介して遠隔コンピュータに対しマッチ状況を提供するように構成されている、請求項１に記載のコンピュータシステム。
【請求項３】
・  もう１つのオンライン接続を介して、以前に実行された金融取引に参加するための当初の要請を受信する、及び
・  マッチングサブシステムがマッチが存在するか否かを決定する前に、以前に実行された金融取引を条件付きで計上する、
ように構成された取引実行ステージプロセッサ、をさらに含む、請求項１に記載のコンピュータシステム。
【請求項４】
−  前記詳細セットが以前に実行された金融取引のための契約相手を識別するフィールドを含み、かつ
−  前記決済用プロセッサがさらに、
・  該契約相手に対する第２のオンライン接続を確立する、及び
・  前記第２のオンライン接続を介して該契約相手からの確認を前記決済用プロセッサが受信するまで、以前に実行された金融取引の計上を回避する、
ように構成されている、請求項１に記載のコンピュータシステム。
【請求項５】
決済用プロセッサがさらに、
・  以前に実行された金融取引が計上されたという通知を含む、以前に実行された金融取引に関する出メッセージを生成する、及び
・  データ通信網を介して遠隔コンピュータに対して出メッセージを伝送する、
ように構成されている、請求項１に記載のコンピュータシステム。
【請求項６】
前記決済用プロセッサと連動して遠隔コンピュータ上で実行するように構成されたアダプタプログラムをさらに含み、該アダプタプログラムがさらに、
・  遠隔コンピュータ上でラン中のユーザーアプリケーションから入メッセージを受信する、及び
・  前記データ通信網を介して前記遠隔コンピュータから前記決済用プロセッサまで入メッセージを伝送する、
ように構成されている、請求項５に記載のコンピュータシステム。
【請求項７】
アダプタプログラムがさらに、決済用プロセッサと互換性のあるフォーマットへ入メッセージを翻訳するように構成されている、請求項６に記載のコンピュータシステム。
【請求項８】
アダプタプログラムがさらに、
・  前記データ通信網を介して前記決済用プロセッサから出メッセージを受信する、及び
・  前記出メッセージをユーザーアプリケーションに送る、
ように構成されている、請求項６に記載のコンピュータシステム。
【請求項９】
アダプタプログラムがさらに、ユーザーアプリケーションと互換性のあるフォーマットへ出メッセージを翻訳するように構成されている、請求項８に記載のコンピュータシステム。
【請求項１０】
マッチングサブシステムが、
−  ワークフロープロセッサ、及び
−  ワークフロープロセッサの制御下で、前記詳細セットと第２の詳細セットとを比較するように構成されているマッチングエンジン
を含んで構成される、請求項１に記載のコンピュータシステム。
【請求項１１】
決済用プロセッサが、
・  オンライン接続を制御するように構成されたセッションマネージャ、及び
・  遠隔コンピュータとのデータ通信を制御するように構成されたユーザーインターフェースマネージャ、
を含んで構成される、請求項１に記載のコンピュータシステム。
【請求項１２】
ユーザーインターフェースマネージャがさらに、遠隔コンピュータ上でラン中のアダプタプログラムとのデータ通信を制御するように構成されている、請求項１１に記載のコンピュータシステム。
【請求項１３】
前記決済用プロセッサがさらに、前記メッセージデータベース内に入メッセージを記憶する前に、前記マッチングサブシステムと互換性のあるフォーマットに入メッセージを翻訳するように構成されている、請求項１に記載のコンピュータシステム。
【請求項１４】
フォーマットがＳＷＩＦＴ  ＭＴ３００フォーマットである、請求項１３に記載のコンピュータシステム。
【請求項１５】
データ通信網がインターネットである、請求項１に記載のコンピュータシステム。
【請求項１６】
データ通信網がＳＷＩＦＴネットワークである、請求項１に記載のコンピュータシステム。
【請求項１７】
データ通信網が仮想プライベートネットワークである、請求項１に記載のコンピュータシステム。
【請求項１８】
以前に実行された金融取引を決済するためのコンピュータ援用方法において、
−  以前に実行された金融取引についての当事者Ａパースペクティブ詳細セットを当事者Ａから受信する段階；
−  以前に実行された金融取引についての当事者Ｂパースペクティブ詳細セットを当事者Ｂから受信する段階；
−  当事者Ａパースペクティブ詳細セットが当事者Ｂパースペクティブ詳細セットとマッチするか否かを決定する段階；
−  当事者Ａに対し以前に実行された金融取引に関する情報を伝達するように構成されたオンライン接続を、データ通信網を介して当事者Ａのために確立する段階；
−  当事者Ａパースペクティブ詳細セット及び当事者Ｂパースペクティブ詳細セットを前記オンライン接続を介して当事者Ａに伝送する段階；及び
−  当事者Ａパースペクティブ詳細セットと当事者Ｂパースペクティブ詳細セットの間にマッチがある場合には、以前に実行された金融取引を計上する段階、
を含んで構成される、方法。
【請求項１９】
前記以前に実行された金融取引を計上する段階に先立ち、前記オンライン接続を介して当事者Ａに対しマッチ状況を提供する段階をさらに含む、請求項１８に記載の方法。
【請求項２０】
−  当事者Ｂとの以前に実行された金融取引に参加するべく当事者Ａからの当初の要請をもう１つのオンライン接続を介して受信する段階；及び
−  マッチが存在するか否かを決定する段階に先立ち、以前に実行された金融取引を条件付きで計上する段階、
をさらに含んで構成される、請求項１８に記載の方法。
【請求項２１】
−  当事者Ｂに対し以前に実行された金融取引に関する情報を伝達するように構成された第２のオンライン接続を当事者Ｂのために確立する段階；
−  当事者Ａパースペクティブ詳細セット及び当事者Ｂパースペクティブ詳細セットを前記第２のオンライン接続を介して当事者Ｂに伝送する段階、及び
−  前記第２のオンライン接続を介して当事者Ｂにマッチ状況を提供する段階、
をさらに含んで構成される、請求項１８に記載の方法。
【請求項２２】
−  前記オンライン接続を介して前記マッチ状況に応答して当事者Ａから処理用指令を受信する段階；
−  前記第２のオンライン接続を介して当事者Ｂから前記処理用指令についての確認を受信する段階；及び
−  前記処理用指令及び前記確認に応答して、以前に実行された金融取引を計上する段階、
をさらに含んで構成される、請求項１９に記載の方法。
【請求項２３】
以前に実行された金融取引が外国為替取引を含む、請求項１８に記載の方法。
【請求項２４】
前記受信段階の各々がＳＷＩＦＴ  ＭＴ３００確認メッセージを受信する段階を含む、請求項１８に記載の方法。
【請求項２５】
当事者Ａパースペクティブ詳細セットが以前に実行された金融取引についての経済的詳細セットを含む、請求項１８に記載の方法。
【請求項２６】
当事者Ｂパースペクティブ詳細セットが以前に実行された金融取引についての経済的詳細セットを含む、請求項２５に記載の方法。
【請求項２７】
当事者Ａパースペクティブ詳細セットが以前に実行された金融取引についての勘定識別子を含む、請求項１８に記載の方法。
【請求項２８】
当事者Ｂパースペクティブ詳細セットが以前に実行された金融取引についての勘定識別子を含む、請求項２７に記載の方法。
【請求項２９】
当事者Ａパースペクティブ詳細セットが以前に実行された金融取引についての契約相手識別子を含む、請求項１８に記載の方法。
【請求項３０】
当事者Ｂパースペクティブ詳細セットが以前に実行された金融取引についての契約相手識別子を含む、請求項２９に記載の方法。
【請求項３１】
以前に実行された金融取引がコンピュータ化されたオンライン金融取引ネットワークを介して開始される、請求項１８に記載の方法。
【請求項３２】
コンピュータ化−オンライン金融取引ネットワークが外国為替トレーディングポータルを含む、請求項３１に記載の方法。
【請求項３３】
以前に実行された金融取引が公衆交換電話網（ＰＳＴＮ）を介して開始される、請求項１８に記載の方法。
【請求項３４】
以前に実行された金融取引が当事者Ａと当事者Ｂの間の対面会談を介して開始される、請求項１８に記載の方法。
【請求項３５】
前記受信段階の各々が、データベース内に以前に実行された金融取引についての詳細セットを記憶する段階を含んで構成される、請求項１８に記載の方法。
【請求項３６】
複数の以前に実行された金融取引を処理するためのコンピュータ援用方法において、
−  複数の以前に実行された金融取引のうちの一つの以前に実行された金融取引と結びつけられた入メッセージを受信する段階であって、前記一つの以前に実行された金融取引は当事者Ａ及び当事者Ｂが関与するものであり；
−  当事者Ａ又は当事者Ｂから以前に受信したメッセージの中に含まれた第２の詳細セットとマッチする詳細セットを入メッセージが含んでいるか否かを決定する段階；
−  当事者Ａに対し以前に実行された金融取引に関する情報を伝達するように構成されたオンライン接続を当事者Ａと確立する段階；
−  前記詳細セット及び前記第２の詳細セットを、前記オンライン接続を介して当事者Ａに伝送する段階；及び
−  前記詳細セット及び前記第２の詳細セットの間にマッチがある場合には、以前に実行された金融取引を計上する段階
を含んで構成される、方法。
【請求項３７】
以前に実行された金融取引を計上する段階に先立ち、前記オンライン接続を介して当事者Ａに対しマッチ状況を提供する段階をさらに含んで構成される、請求項３６に記載の方法。
【請求項３８】
−  マッチが存在するか否かを決定する前記段階に先立ち、以前に実行された金融取引を条件付きで計上する段階、
をさらに含んで構成される、請求項３６に記載の方法。
【請求項３９】
前記計上段階は、
−  当事者Ｂに対し以前に実行された金融取引に関する情報を伝達するように構成された第２のオンライン接続を当事者Ｂのために確立する段階；
−  前記オンライン接続を介して、マッチ状況に応答して処理用指令を当事者Ａから受信する段階；
−  前記第２のオンライン接続を介して、当事者Ｂに対し処理用指令を伝送する段階；及び
−  前記第２のオンライン接続を介して、処理用指令に応答する確認を当事者Ｂから受信する段階、
を含んで構成される、請求項３６に記載の方法。
【請求項４０】
前記処理用指令が、
−  前記マッチを中断するための指令、
−  前記詳細セットと前記第２の詳細セットの間の強制マッチングを作成するための指令、
−  前記詳細セットにマッチする第３の詳細セットを含む新しいメッセージを作成するための指令、
−  入メッセージを取消すための指令、
−  入メッセージに関する通知を当事者Ｂに送るための指令、
−  入メッセージに関する通知を当事者Ｃに送るための指令、
−  メッセージマッチングキューから入メッセージを除去するための指令、及び
−  繰延べのために入メッセージをマークするための指令、
のうちの少なくとも１つを含んで構成される、請求項３９に記載の方法。
【請求項４１】
前記受信段階がメッセージデータベース内に入メッセージを記憶する段階を含んで構成され、請求項３６に記載の方法。
【請求項４２】
前記受信段階が、前記入メッセージが当事者Ａから以前に受信したメッセージについての補正要請を含んでいるか否かを決定する段階を含んで構成される、請求項３６に記載の方法。
【請求項４３】
前記受信段階が、前記入メッセージが当事者Ａから以前に受信したメッセージについての取消し要請を含んでいるか否かを決定する段階を含んで構成される、請求項３６に記載の方法。
【請求項４４】
前記入メッセージが、決済命令セットを含むか否かを決定する段階をさらに含んで構成される、請求項３６に記載の方法。
【請求項４５】
入メッセージに対し決済命令セットを付加する段階をさらに含んで構成される、請求項４４に記載の方法。
【請求項４６】
前記受信段階が、メッセージマッチングキュー内に入メッセージを置く段階を含んで構成される、請求項３６に記載の方法。
【請求項４７】
前記受信段階は、前記入メッセージが受信されたことを示す通知を当事者Ｂに送る段階を含んで構成される、請求項３６に記載の方法。
【請求項４８】
前記受信段階は、前記入メッセージが受信されたことを示す通知を当事者Ｃに送る段階を含んで構成される、請求項３６に記載の方法。
【請求項４９】
さらに、入メッセージをＳＷＩＦＴ  ＭＴ３００フォーマットに転換する段階を含んで構成される、請求項３６に記載の方法。
【請求項５０】
前記決定段階は、入メッセージにメッセージ状況を割当てる段階を含んで構成される、請求項３６に記載の方法。
【請求項５１】
前記決定段階は、入メッセージにマッチ状況を割当てる段階を含んで構成される、請求項３６に記載の方法。
【請求項５２】
前記決定段階は、前記第２の詳細セットがマッチしたことを示す通知を当事者Ｂに送る段階を含んで構成される、請求項３６に記載の方法。
【請求項５３】
前記決定段階は、前記第２の詳細セットがマッチしたことを示す通知を当事者Ｃに送る段階を含んで構成される、請求項３６に記載の方法。
【請求項５４】
前記オンライン接続を介して当事者Ａから決済命令選定を受信する段階をさらに含んで構成される、請求項３６に記載の方法。
【請求項５５】
前記決済命令選定は、予め定義された決済命令セットを使用する要請を含んで構成される、請求項５４に記載の方法。
【請求項５６】
前記決済命令選定は、新しい決済命令セットを使用する要請を含んで構成される、請求項５４に記載の方法。
【請求項５７】
前記決済命令選定は、予め定義された決済命令セットを修正する要請を含んで構成される、請求項５４に記載の方法。
【請求項５８】
複数の以前に実行された金融取引について当事者Ａに対しネット決済支払いセットを提示する段階をさらに含んで構成される、請求項３６に記載の方法。
【請求項５９】
前記提示段階は、
−  当事者Ａから前記オンライン接続を介して、複数の以前に実行された金融取引内の以前に実行された金融取引のサブセットについて、選択された勘定決済日、及び勘定と契約相手の選択された組合せを受信する段階；
−  選択された勘定決済日及び選択された組合せに基づいて、以前に実行された金融取引のサブセットについてのネット支払いセットを計算する段階；及び
−  前記オンライン接続を介して当事者Ａに対し該ネット支払いセットを伝送する段階、
を含んで構成される、請求項５８に記載の方法。
【請求項６０】
承認のため、選択された組合せの中の各契約相手に対しネット支払いセットを伝送する段階をさらに含んで構成される、請求項５９に記載の方法。
【請求項６１】
計算段階が、規定のネッティング方式を用いて実施される、請求項５９に記載の方法。
【請求項６２】
ネッティング方式には、以前に実行された金融取引のサブセットの中で、各々の通貨対について、ネット支払いを生成することが必要とされる、請求項６１に記載の方法。
【請求項６３】
ネッティング方式には、以前に実行された金融取引のサブセットの中で、各通貨についてのネット支払いを生成することが必要とされる、請求項６１に記載の方法。
【請求項６４】
ネッティング方式には、当事者Ａが支払うべき決済支払い数を低減させるべく当事者Ａ以外の２者以上の契約相手の間で直接支払われるべきネット支払いセットを生成することが必要とされる、請求項６１に記載の方法。
【請求項６５】
ネット支払いセット内の各々のネット支払いについての決済命令を当事者Ａから受信する段階をさらに含んで構成される、請求項５９に記載の方法。
【請求項６６】
以前に実行された金融取引が外国為替取引を含んで構成される、請求項３６に記載の方法。
【請求項６７】
前記受信段階がＳＷＩＦＴ  ＭＴ３００確認メッセージを受信する段階を含んで構成される、請求項３６に記載の方法。
【請求項６８】
前記詳細セットが以前に実行された金融取引についての経済的詳細セットを含んで構成される、請求項３６に記載の方法。
【請求項６９】
前記詳細セットが以前に実行された金融取引についての勘定識別子を含んで構成される、請求項３６に記載の方法。
【請求項７０】
前記詳細セットが以前に実行された金融取引についての契約相手識別子を含んで構成される、請求項３６に記載の方法。
【請求項７１】
以前に実行された金融取引がコンピュータ化されたオンライン金融取引ネットワークを介して開始される、請求項３６に記載の方法。
【請求項７２】
コンピュータ化−オンライン金融取引ネットワークが外国為替トレーディングポータルを含んで構成される、請求項７１に記載の方法。
【請求項７３】
以前に実行された金融取引が公衆交換電話網（ＰＳＴＮ）を介して開始される、請求項３６に記載の方法。
【請求項７４】
以前に実行された金融取引が対面会談を介して開始される、請求項３６に記載の方法。
【請求項７５】
金融取引を処理するためのコンピュータシステムにおいて、
−  決済サーバープログラム；及び
−  以前に実行された金融取引に関する２つの金融取引詳細セットについてのマッチ状況を生成するように構成された、前記決済サーバープログラムの制御下で動作するマッチングサブシステム；
を含んで構成され、決済サーバープログラムが、
−  第１のデータ通信チャンネルを介してブローカークライアントプログラムに２つの取引詳細セット及びマッチ状況を伝送する、
−  マッチ状況に応答して処理用指令をブローカークライアントプログラムから受諾する、
−  第２の通信チャンネルを介してプロバイダクライアントプログラムに、そして第３の通信チャンネルを介してカスタマークライアントプログラムに、処理用指令を伝送する、及び
−  入力に応答して、以前に実行された金融取引を計上する、ように構成されているコンピュータシステム。
【請求項７６】
処理用指令が、
−  以前に実行された金融取引を変更するための要請、
−  以前に実行された金融取引についての決済日を修正するための要請、
−  以前に実行された金融取引に結びつけられたレートを修正するための要請、
−  以前に実行された金融取引を決済するのに特定の勘定を使用するための要請、
−  以前に実行された取引を多数の金融取引に分割するための要請、
−  ２つの金融取引詳細セットの間のマッチを強制するための要請、
−  ２つの金融取引詳細セット間のマッチを中断させるための要請、
−  ２つの金融取引詳細セット間のマッチを作成するための要請、及び
−  ２つの取引詳細セット内の１つ以上の詳細に関する通知を伝送するための要請、
のうちの少なくとも１つを含んで構成される、請求項７５に記載のコンピュータシステム。
【請求項７７】
当事者Ａ及び当事者Ｂが関与する、以前に実行された金融取引、を処理するためのコンピュータシステムにおいて、
−  データ通信網に対するインタフェース；
−  前記インタフェースに結合され、
・  データ通信網を介して当事者Ａのための第１のオンライン接続を確立する、
・  データ通信網を介して当事者Ｂのための第２のオンライン接続を確立する、
・  当事者Ａと当事者Ｃの間の第１の金融取引に関する当事者Ａギブアップ詳細セットを第１のオンライン接続を介して当事者Ａから受信する、及び
・  当事者Ｂと当事者Ｃの間の第２の金融取引に関する当事者Ｂギブアップ詳細セットを第２のオンライン接続を介して当事者Ｂから受信する、
ように構成された決済用プロセッサ、
−  当事者Ａギブアップ詳細と当事者Ｂギブアップ詳細の間にマッチが存在するか否かを決定するように構成されたマッチングサブシステム
を含んで構成され、
マッチが存在する場合、決済用プロセッサはさらに、
・  当事者Ａと当事者Ｂの間の第１の金融取引を計上し、
・  当事者Ｂと当事者Ｃの間の第２の金融取引を計上するように構成されているコンピュータシステム。
【請求項７８】
決済用プロセッサがさらに、第１の金融取引を計上する前に、前記第１のオンライン接続を介して当事者Ａに対しマッチ状況を提供するように構成されている、請求項７７に記載のコンピュータシステム。
【請求項７９】
決済用プロセッサがさらに、第２の金融取引を計上する前に、前記第１のオンライン接続を介して当事者Ｂに対しマッチ状況を提供するように構成されている、請求項７７に記載のコンピュータシステム。
【請求項８０】
・  もう１つのオンライン接続を介して、当事者Ｂとの以前に実行された金融取引に参加するための当事者Ａからの当初の要請を受信する、
・  マッチングサブシステムがマッチが存在するか否かを決定する前に、第１の金融取引を条件付きで計上する、及び
・  マッチングサブシステムがマッチが存在するか否かを決定する前に、第２の金融取引を条件付きで計上する、
ように構成された取引実行ステージプロセッサをさらに含んで構成される、請求項７７に記載のコンピュータシステム。
【請求項８１】
−  当事者Ｂとの以前に実行された金融取引に参加するための当事者Ａからの当初の要請が、当事者Ａと当事者Ｃの間の取決めに基づいており、
−  当事者Ｂに対し当初の要請を伝送する前に、前記取引実行ステージプロセッサは、前記取決めが当事者Ａに前記当初の要請を行なうことを許可しているか否かを確認する、
請求項８０に記載のコンピュータシステム。
【請求項８２】
取決めは、
−  信用限度、
−  通貨ペア制約、
−  先日付制限、
−  特定勘定の使用要件、
−  実行日付制約、及び
−  決済日付制約、
のうちの少なくとも１つを含んで構成される、請求項８１に記載のコンピュータシステム。
【請求項８３】
前記決済用プロセッサがさらに、
−  当事者Ｃのための第３のオンライン接続を確立する；
−  当事者Ａに代って当事者Ｃに対し当事者Ａのギブアップ詳細を伝送する、及び
−  当事者Ｂに代って、当事者Ｃに対し当事者Ｂのギブアップ詳細を伝送する
ように構成されている、請求項７７に記載のコンピュータシステム。
【請求項８４】
決済用プロセッサがさらに、当事者Ａのギブアップ詳細が当事者Ｃに伝送されたという通知を当事者Ａに伝送するように構成されている、請求項８３に記載のコンピュータシステム。
【請求項８５】
決済用プロセッサがさらに、当事者Ｂのギブアップ詳細が当事者Ｃに伝送されたという通知を当事者Ｂに伝送するように構成されている、請求項８３に記載のコンピュータシステム。
【請求項８６】
決済用プロセッサがさらに、
−  当事者Ａのギブアップ詳細及び当事者Ｂのギブアップ詳細の当事者Ｃに対する伝送に応答して、当事者Ｃから当事者Ｃのギブアップ受諾を受理する；及び
−  当事者Ｃに代って当事者Ａ及び当事者Ｂに対し当事者Ｃのギブアップ受諾を伝送する、
ように構成されている、請求項８３に記載のコンピュータシステム。
【請求項８７】
第１の金融取引が第２の金融取引よりも高いレートで計上される、請求項７７に記載のコンピュータシステム。
【請求項８８】
決済用プロセッサがさらに、第１及び第２の金融取引が計上されたことの通知を当事者Ａ及び当事者Ｂに伝送するように構成されている、請求項７７に記載のコンピュータシステム。
【請求項８９】
−  決済用プロセッサがさらに、
・  当事者Ａから第１のオンライン接続を介して、当事者Ａと当事者Ｂの間の第３の金融取引に関する当事者Ａの詳細セットを受信する段階であって、かかる第３の金融取引は、当事者Ｃにギブアップされていない、以前に実行された金融取引の一部分を含んでおり；及び
・  第３の金融取引に関する当事者Ｂの詳細セットを当事者Ｂから第２のオンライン接続を介して受信する、
ように構成されており、
−  マッチングサブシステムがさらに当事者Ａの詳細と当事者Ｂの詳細の間に第２のマッチが存在するか否かを決定するように構成されており、
−  第２のマッチが存在する場合、決済用プロセッサはさらに第３の金融取引を計上するように構成されている、
請求項７７に記載のコンピュータシステム。
【請求項９０】
決済用プロセッサがさらに、第３の金融取引を計上する前に、前記第１のオンライン接続を介して当事者Ａに対し、当事者Ａの詳細及び当事者Ｂの詳細についてのマッチ状況を提供するように構成されている、請求項８９に記載のコンピュータシステム。
【請求項９１】
決済用プロセッサがさらに、第３の金融取引を計上する前に、前記第２のオンライン接続を介して当事者Ｂに対し、当事者Ａの詳細及び当事者Ｂの詳細についてのマッチ状況を提供するように構成されている、請求項８９に記載のコンピュータシステム。
【請求項９２】
決済用プロセッサがさらに、第３の金融取引が計上されたことの通知を当事者Ａ及び当事者Ｂに伝送するように構成されている、請求項８９に記載のコンピュータシステム。
【請求項９３】
・  もう１つのオンライン接続を介して、当事者Ｂとの第３の金融取引に参加するための当事者Ａからの当初の要請を受信する、及び
・  マッチングサブシステムが第２のマッチが存在するか否かを決定する前に、第３の金融取引を条件付きで計上する、
ように構成された取引実行ステージプロセッサをさらに含んで構成される、請求項８９に記載のコンピュータシステム。
【請求項９４】
決済用プロセッサがさらに、
−  当事者Ａより当事者Ｃに提供された資金割当に基づいて決済詳細セットを当事者Ｃから受信する；
−  当事者Ｄのための第４のオンライン接続を確立する；及び
−  前記第４のオンライン接続を介して当事者Ｄに対し決済詳細セットを伝送する
ように構成されている、請求項７７に記載のコンピュータシステム。
【請求項９５】
前記決済詳細セットが、
−  資金調達勘定、
−  資金調達金額、
−  勘定決済日、
のうちの１つ以上のものを表わすデータを含んで構成される、請求項９４に記載のコンピュータシステム。
【請求項９６】
決済用プロセッサがさらに、
−  決済詳細セットに応答した当事者Ｄの決済確認メッセージを当事者Ｄから受信する；
−  当事者Ｄに代って当事者Ｃに対し前記当事者Ｄ決済確認メッセージを伝送する；
−  前記当事者Ｄ決済確認メッセージに応答した当事者Ｃ確認メッセージを当事者Ｃから受信する；及び
−  当事者Ａに対し前記当事者Ｃ決済確認メッセージを伝送する、
ように構成されている、請求項９４に記載のコンピュータシステム。
【請求項９７】
前記マッチングサブシステムがさらに、当事者Ｃ決済確認メッセージと決済詳細セットの間にマッチが存在するか否かを決定するように構成されている、請求項９６に記載のコンピュータシステム。
【請求項９８】
当事者Ａにより操作される遠隔コンピュータ上で前記決済用プロセッサと連動して実行するように構成されたアダプタプログラムをさらに含んで構成され、該アダプタプログラムがさらに、
−  遠隔コンピュータ上でラン中のユーザーアプリケーションから当事者Ａギブアップ詳細を含んで構成される当事者Ａギブアップメッセージを受信する；及び
−  前記データ通信網を介して前記決済用プロセッサへ前記遠隔コンピュータから当事者Ａギブアップメッセージを伝送する、
ように構成されている、請求項７７に記載のコンピュータシステム。
【請求項９９】
アダプタプログラムはさらに、マッチングサブシステムと互換性のあるフォーマットへ当事者Ａギブアップメッセージを翻訳するように構成されている、請求項９８に記載のコンピュータシステム。
【請求項１００】
当事者Ｂにより操作される遠隔コンピュータ上で前記決済用プロセッサと連動して実行するように構成されたアダプタプログラムをさらに含んで構成され、該アダプタプログラムがさらに、
−  遠隔コンピュータ上でラン中のユーザーアプリケーションから当事者Ｂギブアップメッセージを受信する；及び
−  前記データ通信網を介して前記決済用プロセッサへ前記遠隔コンピュータから当事者Ｂギブアップメッセージを伝送する、
ように構成されている、請求項９８に記載のコンピュータシステム。
【請求項１０１】
アダプタプログラムはさらに、マッチングサブシステムと互換性のあるフォーマットへ当事者Ｂギブアップメッセージを翻訳するように構成されている、請求項１００に記載のコンピュータシステム。
【請求項１０２】
マッチングサブシステムが
−  ワークフロープロセッサ；及び
−  ワークフロープロセッサの制御下で第１の詳細セットと第２の詳細セットを比較するように構成されたマッチングエンジン、
を含んで構成される、請求項７７に記載のコンピュータシステム。
【請求項１０３】
決済用プロセッサが
−  オンライン接続を制御するように構成されたセッションマネージャ；及び
−  当事者Ａ、当事者Ｂ、当事者Ｃ又は当事者Ｄとのデータ通信網上でのデータ通信を制御するように構成されたユーザーインターフェースマネージャ、
を含んで構成される、請求項７７に記載のコンピュータシステム。
【請求項１０４】
ユーザーインターフェースマネージャがさらに、当事者Ａ又は当事者Ｂにより操作されている遠隔コンピュータ上でラン中のアダプタプログラムとのデータ通信を制御するように構成されている、請求項１０３に記載のコンピュータシステム。
【請求項１０５】
第１及び第２の入メッセージを記憶するように構成されたメッセージデータベースをさらに含んで構成される、請求項１０３に記載のコンピュータシステム。
【請求項１０６】
前記決済用プロセッサがさらに、前記メッセージデータベース内に当事者Ａのギブアップ詳細及び当事者Ｂのギブアップ詳細を記憶するように構成されている、請求項１０５に記載のコンピュータシステム。
【請求項１０７】
データ通信網がインターネットである、請求項７７に記載のコンピュータシステム。
【請求項１０８】
データ通信網がＳＷＩＦＴネットワークである、請求項７７に記載のコンピュータシステム。
【請求項１０９】
データ通信網が仮想プライベートネットワークである、請求項７７に記載のコンピュータシステム。
【請求項１１０】
当事者Ａ及び当事者Ｂが関与する、以前に実行された金融取引、を処理するためのコンピュータ援用方法において、
−  データ通信網を介して当事者Ａのための第１のオンライン接続を確立する段階、
−  データ通信網を介して当事者Ｂのための第２のオンライン接続を確立する段階、
−  当事者Ａと当事者Ｃの間の第１の金融取引に関する当事者Ａギブアップ詳細セットを第１のオンライン接続を介して当事者Ａから受信する段階、及び
−  当事者Ｂと当事者Ｃの間の第２の金融取引に関する当事者Ｂギブアップ詳細セットを第２のオンライン接続を介して当事者Ｂから受信する段階、
−  当事者Ａギブアップ詳細と当事者Ｂギブアップ詳細の間にマッチが存在するか否かを決定する段階、及び
マッチが存在する場合、
−  当事者Ａと当事者Ｃの間の第１の金融取引を計上する段階、及び
−  当事者Ｂと当事者Ｃの間の第２の金融取引を計上する段階、を含んで構成される方法。
【請求項１１１】
以前に実行された金融取引を計上する前に、前記第１のオンライン接続を介して当事者Ａに対しマッチ状況を提供する段階をさらに含んで構成される、請求項１１０に記載の方法。
【請求項１１２】
−  もう１つのオンライン接続を介して、当事者Ｂとの以前に実行された金融取引に参加するための当事者Ａからの当初の要請を受信する段階、
−  マッチングサブシステムがマッチが存在するか否かを決定する前に、第１の金融取引を条件付きで計上する段階、及び
−  マッチングサブシステムがマッチが存在するか否かを決定する前に、第２の金融取引を条件付きで計上する段階、をさらに含んで構成される、請求項１１０に記載の方法。
【請求項１１３】
当事者Ｂに対し当初の要請を伝送する前に、当事者Ａと当事者Ｃの間の取決めが当事者Ａに前記当初の要請を行なうことを許可しているか否かを確認する段階をさらに含んで構成される、
請求項１１２に記載の方法。
【請求項１１４】
取決めは、
−  信用限度、
−  通貨ペア制約、
−  先日付制限、
−  特定勘定の使用要件、
−  実行日付制約、及び
−  決済日付制約
のうちの少なくとも１つを含んで構成される、請求項１１３に記載の方法。
【請求項１１５】
−  当事者Ｃのための第３のオンライン接続を確立する段階；
−  当事者Ａに代って、当事者Ｃに対し当事者Ａのギブアップ詳細を伝送する段階；及び
−  当事者Ｂに代って、当事者Ｃに対し当事者Ｂのギブアップ詳細を伝送する段階、
をさらに含んで構成される、請求項１１０に記載の方法。
【請求項１１６】
当事者Ａのギブアップ詳細が当事者Ｃに伝送されたという通知を当事者Ａに伝送する段階をさらに含んで構成される、請求項１１５に記載の方法。
【請求項１１７】
当事者Ｂのギブアップ詳細が当事者Ｃに伝送されたという通知を当事者Ｂに伝送する段階をさらに含んで構成される、請求項１１５に記載の方法。
【請求項１１８】
−  当事者Ａのギブアップ詳細及び当事者Ｂのギブアップ詳細の当事者Ｃに対する伝送に応答して、当事者Ｃから当事者Ｃのギブアップ受諾を受理する段階；及び
−  当事者Ｃに代って当事者Ａ及び当事者Ｂに対し当事者Ｃのギブアップ受諾を伝送する段階、
をさらに含んで構成される、請求項１１５に記載の方法。
【請求項１１９】
第１の金融取引を計上する段階には、第２の金融取引よりも高いレートで第１の金融取引が計上されることが含まれる、請求項１１５に記載の方法。
【請求項１２０】
第１及び第２の金融取引が計上されたことの通知を当事者Ａ及び当事者Ｂに送る段階をさらに含んで構成される、請求項１１５に記載の方法。
【請求項１２１】
−  当事者Ａから第１のオンライン接続を介して、当事者Ａと当事者Ｂの間の第３の金融取引に関する当事者Ａの詳細セットを受信する段階であって、かかる第３の金融取引は、当事者Ｃにギブアップされていない、以前に実行された金融取引の一部分を含んでおり；及び
−  第３の金融取引に関する当事者Ｂの詳細セットを当事者Ｂから第２のオンライン接続を介して受信する段階、
−  当事者Ａの詳細と当事者Ｂの詳細の間に第２のマッチが存在するか否かを決定する段階、
−  第２のマッチが存在する場合、第３の金融取引を計上する段階、
をさらに含んで構成される、請求項１１５に記載の方法。
【請求項１２２】
第３の金融取引を計上する前に、前記第１のオンライン接続を介して当事者Ａに対し、当事者Ａの詳細及び当事者Ｂの詳細についてのマッチ状況を提供する段階をさらに含んで構成される、請求項１２１に記載の方法。
【請求項１２３】
決済用プロセッサがさらに、第３の金融取引を計上する前に、前記第２のオンライン接続を介して当事者Ｂに対し、当事者Ａの詳細及び当事者Ｂの詳細についてのマッチ状況を提供するように構成されている、請求項１２１に記載の方法。
【請求項１２４】
第３の金融取引が計上されたことの通知を当事者Ａ及び当事者Ｂに送る段階をさらに含んで構成される、請求項１２１に記載の方法。
【請求項１２５】
−  もう１つのオンライン接続を介して、当事者Ｂとの第３の金融取引に参加するための当事者Ａからの当初の要請を受信する段階、及び
−  第２のマッチが存在するか否かを決定する前に、第３の金融取引を条件付きで計上する段階、をさらに含んで構成される、請求項１２１に記載の方法。
【請求項１２６】
−  当事者Ａより当事者Ｃに提供された資金割当に基づいて決済詳細セットを当事者Ｃから受信する段階；
−  当事者Ｄのための第４のオンライン接続を確立する段階；及び
−  前記第４のオンライン接続を介して当事者Ｄに対し決済詳細セットを伝送する段階、
をさらに含んで構成される、請求項１１０に記載の方法。
【請求項１２７】
前記決済詳細セットが、
−  資金調達勘定、
−  資金調達金額、
−  勘定決済日、
のうちの１つ以上のものを表わすデータを含んで構成される、請求項１２６に記載の方法。
【請求項１２８】
−  決済詳細セットに応答した当事者Ｄの決済確認メッセージを当事者Ｄから受信する段階；
−  当事者Ｄに代って当事者Ｃに対し前記当事者Ｄ決済確認メッセージを伝送する段階；
−  前記当事者Ｄ決済確認メッセージに応答した当事者Ｃ確認メッセージを当事者Ｃから受信する段階；及び
−  当事者Ａに対し前記当事者Ｃ決済確認メッセージを伝送する段階、
をさらに含んで構成される、請求項１２６に記載の方法。
【請求項１２９】
当事者Ｃ決済確認メッセージと決済詳細セットの間にマッチが存在するか否かを決定する段階をさらに含んで構成される、請求項１２８に記載の方法。
【請求項１３０】
金融取引を処理するためのコンピュータ援用方法において、
−  当初の取引のための当初の商取引要請を当事者Ａから受信する段階であって、かかる商取引要請は当事者Ｂに向けられたものであり；
−  当初の商取引要請に基づいて二次商取引要請を生成する段階；
−  アウトソーシング規則セットに基づいて選択されているプロバイダセットに対し、当事者Ｂに代って前記２次商取引要請を提出する段階；
−  二次商取引要請に応答した当初の応答ストリームを前記プロバイダセットのサブセットから受信する段階；
−  二次応答ストリームを形成するべく当初の応答ストリームから１つ以上の応答を選択する段階；
−  当事者Ｂに代って当事者Ａに対して前記二次応答ストリームを伝送する段階；及び
−  二次応答ストリームに応答した当事者Ａからの受諾を受信する段階；及び
−  受諾に応答して、
・  前記当初の応答ストリーム及び仲裁規則セットに基づいて被選択プロバイダを選ぶ段階、
・  当事者Ｂに代わって、選択されたプロバイダに対し受諾を転送する段階、
・  前記受諾に応答して選択されたプロバイダからの確認を受信する段階、及び
・  前記確認の受信と実質的に同時に、当初の金融取引に基づいて一対の金融取引を計上する段階、
を含んで構成され、
該金融取引ペアは、当事者Ａと選択されたプロバイダの間の第１の金融取引、及び当事者Ｂと選択されたプロバイダの間の第２の金融取引を含んで構成される、方法。
【請求項１３１】
当初の商取引要請が、指し値要請を含んで構成され、そして
応答ストリームが指し値ストリームを含んで構成される、請求項１３０に記載の方法。
【請求項１３２】
当初の金融取引が外国為替取引である、請求項１３０に記載の方法。
【請求項１３３】
前記プロバイダサブセット及び前記プロバイダセットが同じである、請求項１３０に記載の方法。
【請求項１３４】
当事者Ｂからのアウトソーシング規則セットを受信する段階をさらに含んで、構成される、請求項１３０に記載の方法。
【請求項１３５】
当事者Ｂからの仲裁規則セットを受信する段階をさらに含んで構成される、請求項１３０に記載の方法。
【請求項１３６】
確認を受信し、実時間ベースで金融取引ペアを計上する段階を含んで構成される、請求項１３０に記載の方法。
【請求項１３７】
当初の応答ストリームから選択された前記１つ以上の応答に対しスプレッドを付加する段階をさらに含んで構成される、請求項１３０に記載の方法。
【請求項１３８】
アウトソーシング規則セットが、
−  当初の商取引要請に結びつけられた通貨指定、
−  当初の商取引要請に結びつけられた時間帯、
−  当事者Ａに結びつけられた信用リスク、
−  当初の商取引要請に結びつけられた市場リスク、
−  当初の商取引要請に結びつけられた資金調達金額、
−  前記プロバイダセット内の１つ以上のプロバイダに結びつけられた可用性状況、
−  前記プロバイダセット内の１つ以上のプロバイダに結びつけられた事業目標百分率、
−  前記プロバイダセット内の１つ以上のプロバイダに結びつけられた当事者Ｂについての可用信用状況、
−  前記プロバイダセット内の１つ以上のプロバイダについてのサービス品質保証（ＳＬＡ）、及び
−  前記プロバイダセット内の１つ以上のプロバイダについてのパフォーマンスメトリック、
のうちの１つ以上のものに基づいている、請求項１３０に記載の方法。
【請求項１３９】
−  プロバイダセットについての履歴パフォーマンスレコードを形成するために、前記プロバイダセット内の各々の流動性プロバイダについてのパフォーマンスメトリックセットを追跡する段階；及び
−  履歴パフォーマンスレコードに基づいて前記仲裁規則セットを自動的に調整する段階、
をさらに含んで構成される、請求項１３０に記載の方法。
【請求項１４０】
パフォーマンスメトリックセットが、
−  受信した確認の数、
−  平均応答時間、
−  平均価格差、
−  平均価格安定性等級、
−  平均呼値スプレッド、
−  プロバイダの百分位数等級、及び
−  確認済み受諾率、
のうちの１つ以上のものを含んで構成される、請求項１３９に記載の方法。
【請求項１４１】
第２のプロバイダセットに対して前記２次商取引要請を提出する段階をさらに含んで構成される、請求項１３０に記載の方法。
【請求項１４２】
金融取引を処理するためのコンピュータシステムにおいて、
−  当事者Ｂに向けられた当初の商取引要請を当事者Ａから受信するための手段；
−  前記当初の要請受信手段に基づいて２次商取引要請を生成する手段；
−  アウトソーシング規則セットに基づいて選択されているプロバイダセットに対し、当事者Ｂに代って前記２次商取引要請を提出する手段；
−  ２次商取引要請に応答して、当初の応答ストリームを前記プロバイダセットのサブセットから受信する手段；
−  ２次応答ストリームを形成するべく当初の応答ストリームから１つ以上の応答を選択する手段；
−  当事者Ｂに代って当事者Ａに対して前記２次応答ストリームを伝送する手段；及び
−  ２次応答ストリームに応答して当事者Ａからの受諾を受信する手段；及び
−  受諾に応答して、
・  前記当初の応答ストリーム及び仲裁規則セットに基づいて被選択プロバイダを選び、
・  当事者Ｂに代わって、選択されたプロバイダに対し受諾を転送し、
・  前記受諾に応答して選択されたプロバイダからの確認を受信し、及び
・  前記確認の受信と実質的に同時に、当初の金融取引に基づいて一対の金融取引を計上するための手段、
を含んで構成され、
該金融取引ペアは、当事者Ａと選択されたプロバイダの間の第１の金融取引、及び当事者Ｂと選択されたプロバイダの間の第２の金融取引を含んで構成される、コンピュータシステム。
【請求項１４３】
アウトソーシング規則セットが当事者Ｂにより規定されている、請求項１４２に記載のコンピュータシステム。
【請求項１４４】
仲裁規則セットが当事者Ｂにより規定されている、請求項１４２に記載のコンピュータシステム。
【請求項１４５】
実時間ベースで確認を受信し、かつ金融取引ペアを計上するための手段を含んで構成される、請求項１４２に記載のコンピュータシステム。
【請求項１４６】
当初の応答ストリームから選択された前記１つ以上の応答に対しスプレッドを付加する手段をさらに含んで構成される、請求項１４２に記載のコンピュータシステム。
【請求項１４７】
アウトソーシング規則セットが、
−  当初の商取引要請に結びつけられた通貨指定、
−  当初の商取引要請に結びつけられた時間帯、
−  当事者Ａに結びつけられた信用リスク、
−  当初の商取引要請に結びつけられた市場リスク、
−  当初の商取引要請に結びつけられた資金調達金額、
−  前記プロバイダセット内の１つ以上のプロバイダに結びつけられた可用性状況、
−  前記プロバイダセット内の１つ以上のプロバイダに結びつけられた事業目標百分率、
−  前記プロバイダセット内の１つ以上のプロバイダに結びつけられた当事者Ｂについての可用信用状況、
−  前記プロバイダセット内の１つ以上のプロバイダについてのサービス品質保証（ＳＬＡ）及び
−  前記プロバイダセット内の１つ以上のプロバイダについてのパフォーマンスメトリック、
のうちの１つ以上のものに基づいている、請求項１４２に記載の方法。
【請求項１４８】
−  プロバイダセットについての履歴パフォーマンスレコードを形成するために、前記プロバイダセット内の各々の流動性プロバイダについてのパフォーマンスメトリックセットを追跡する手段；及び
−  履歴パフォーマンスレコードに基づいて前記仲裁規則セットを自動的に調整するための手段、
をさらに含んで構成される、請求項１４２に記載のコンピュータシステム。
【請求項１４９】
パフォーマンスメトリックセットが、
−  受信した確認の数、
−  平均応答時間、
−  平均価格差、
−  平均価格安定性等級、
−  平均呼値スプレッド、
−  プロバイダの百分位数等級、及び
−  確認済み受諾率、
のうちの１つ以上のものを含んで構成される、請求項１４８に記載のコンピュータシステム。
【請求項１５０】
当事者Ｂに対して商取引要請を提出する前に、当事者Ａについての信用情報を提供するように構成されたクレジットエンジンをさらに含んで構成される、請求項１４２に記載のコンピュータシステム。
【請求項１５１】
前記被選択プロバイダを選ぶための手段が、関係ルーターを含んで構成される、請求項１４２に記載のコンピュータシステム。
【請求項１５２】
前記２次商取引要請を提出するための前記手段が、関係ルーターを含んで構成される、請求項１４２に記載のコンピュータシステム。
【発明の詳細な説明】
【発明の開示】
【０００１】
関連出願
本出願は、２００２年６月１９日付けの米国仮特許出願第６０／３８９，４８１号明細書、２００２年７月１２日付けの米国仮特許出願第６０／３９５，３４８号明細書、及び２００３年４月９日付け米国仮特許出願第６０／４６１，１４５号明細書に関連し、かつこれらの明細書に対し３５Ｕ．Ｓ．Ｃ．§１１９に基づく優先権を請求するものであり、これらの仮出願は全て本出願中にその全体が参考として内含されている。
【０００２】
技術の分野
本発明は、一般に、金融取引システム、そしてより特定的にはインターネットといったような相互接続されたデータ通信網上で取引の少なくとも１部分が実施される金融取引システムに関する。
【０００３】
関連技術
今日の世界市場においては、金銭は、投資家と借手の間及び買手と売手の間で国際的境界を横断して自由に流れている。例えば、金融市場は、市場参入者が金銭を貸借りすることを可能にする。金融市場取引においては、一方の契約相手（借手）はもう一方の契約相手（貸手）から、特定の時限にわたり特定のレートで金銭を借用する。金融市場取引資産（Money market instruments）としては、譲渡性預金証書（ＣＤ）及び現先取引といったような利付き商品、短期国債（Ｔ−ビル）及びコマーシャルペーパーといった割引商品及び、金利先渡し契約、金利先物及び金利オプションといったような金融派生商品が含まれる。
【０００４】
もう１つの例においては、外国為替（「ＦＸ」）市場は、市場参入者が１つの通貨をもう１つの通貨に交換する（又は「トレーディングする」）ことを可能にする。ＦＸ取引では、１人の契約相手は、もう１つの通貨と交換して、もう一方の契約相手から特定の通貨を購入する。ＦＸ市場商品には例えば、スポット、先物及びスワップ契約（以下で定義されている）が含まれる。
【０００５】
投資として、大部分の金融市場取引及びＦＸ資産（FX instruments）は、「流動性をもつ（liquid）」すなわち売買可能であり、従って、迅速に現金化できる。この流動性を理由として、数多くの企業財務担当者は、財務的決定を下す前の短期低リスク投資ビークルに余分の現金を一時的に「パーキング」させる方法として、銀行に余分な現金を貸し借りするために、これらの市場を使用する。銀行は、短期資金を必要とする借手に対するローンを行なうために、この余分の現金を用いる。これらの借手には、例えばその他の銀行、法人及び政府ならびに世界銀行といったような超国家的組織が含まれる。
【０００６】
これらの市場の中で借手、貸手、売手及び買手は、金融市場取引資産を貸借りしＦＸ資産を売買する「トレーダー」とも呼ばれるディーラーを通して自らの取引を行なう。「マーケットメーカー」又は「流動性プロバイダ（liquidity providers）」と呼ばれるディーラー及びトレーダーは、自らがディーリングする商品を買いたい（又は借りたい）価格ならびに自らがその商品を売りたい（貸したい）価格を指し値（quote）する。借入又は購入価格は、「ビッド」として知られ、貸出又は売却価格は「オファー」として知られている。これら２つの価格の間の差は、「呼値スプレッド（bid-offerspread）」と呼ばれ、マーケットメーカーは、つねに自ら売却及び貸出するよりもわずかに安く購入及び借入れすることから、マーケットメーカーにとっての利益を生み出すのはこのスプレッドである。
【０００７】
長年にわたり、流動性プロバイダ及びその顧客（流動性プロバイダと事業を行なう買手、売手、貸手及び借手）は、（株式又は商品取引の場合のように）直接会ったり又は電話又はファクシミリを用いて、最初から最後まで手作業システムのみを用いて往々にして「ディール」と呼ばれる取引を、交渉、実行、確認そして決済しようとしてきた。しかしながら、市場が成長し、トレーディング及びディーリング活動が拡大して一日２４時間を網羅するようになるにつれて、手作業システムは、市場の要件に追いつくには、あまりに緩慢で効率が悪すぎることが判明してきた。例えば手作業システムは、今日の市場の速いペースそしてさらに大きい量に対処するため又はこれらの取引に関与することに付随する財務的リスクを取扱うために、必要とされる人物、価格及び取引記録に対する適切なアクセスをつねに提供してくれるとは言えない。手作業システムは同様に、標準的に、現行の市場ニュース、市場レート、市場調査及び、市場参入者が自らのディールを行なう間利用可能な状態に置きワンタッチで入手する必要があるその他の情報、に適切かつタイミング良くアクセスできるようにしてくれるものではない。
【０００８】
確認マッチング（confirmationmatching）は、２人の契約相手が取引詳細について合意することを確認する自動化された検査である。長年にわたり、銀行及びその他の売却側の組織は、この自動化プロセスを実施するための技術及びインフラストラクチャに多大な投資を行なった。確認送達のために用いられる標準的な伝達手段は、ＳＷＩＦＴ、特定的にはＳＷＩＦＴ  ＭＴ３００メッセージである。これらのメッセージは、既存の実行済みディールに対し入メッセージ（incomingmessages）を対合させようとする精巧なマッチングエンジンへとアップロードされる。トレード詳細をマッチさせるための精巧なマッチングシステムは、ストレートスルー処理（Straight-Through-Processing）を可能にする。各々の対合された（又はマッチされた）ディールは、手作業による介入なく自動的に更新され支払われる。対合されない項目は、エラー解決のため手作業で調査される。
【０００９】
しかしながら、買入側の顧客にとっては、確認マッチングのためのオプションはきわめて制限されている。標準的に、彼らは、高価なセットアップ費用及びメンバシップ手数料のためにＳＷＩＦＴの使用を回避してきた。かくして、買入側の顧客は通常、各々のディールを手作業でファクシミリ、Ｅメール及び音声（電話）を介して確認しなければならない。場合によって自動化された確認マッチングシステムにアクセスできたこれらの買入側顧客は、通常、非常に高価で拡張不能でかつ信頼性の低いサービスに遭遇する。
【００１０】
手作業システムの場合のもう１つの問題点は、それが、顧客、ディーラー及びプロバイダが一度に一人の契約相手としか通信できないようになっており、これは、最良の価格を得る上できわめて時間のかかるかつ信頼性の低い方法でありうるという点にある。手作業システムのさらにもう１つの問題点は、総額としてはきわめて大きな資金移転となることの多い（従って大きい財務的露出を作り出す）これらの取引についての記録が、往々にして、財務監査中といったように最も必要とされるときに時として喪失したり、汚れたり、判読できなかったり又はその他の形で利用不可能となる、あわてて作成された手書きのメモやファックスで構成されている、という点にある。これらの及びその他の問題点のため、手作業システムを使用して交渉され完了された非常に大規模又は非常に複雑な取引の間に起こったことを正確に再検討、理解及び／又は再構築することがきわめて困難になっていた。
【００１１】
これらの問題点の一部に対処しようとして、顧客及び流動性プロバイダのための自動化されたオンライン取引システムが導入されてきた、しかし、既存の自動システムは、これまでのところ、旧式の手作業システムの最も厄介な側面の多くを解決できていない。例えば、手作業システムと同様に、既存のオンライン取引システムは、標準的に顧客を多数の銀行及びプロバイダに同時に接続せず、このことはすなわち、顧客が、むしろ自らの事業に関して競合する数多くの銀行及びプロバイダを有する場合に、最良の価格のために提案された取引をあれこれ検討するのになおも受入れ難いほどの時間を費さなくてはならない、ということを意味している。その上、既存のオンライントレーディングシステムは、提案されている取引の状況についての実時間でコンテクストに応じたフィードバック（context-sensitive feedback）を顧客に対し提供していない。既存のオンライン取引システムがもつもう１つの問題点は、それらが、顧客及びプロバイダに対して、以前に実行されたディールをオンラインで確認し決済する方法を提供していないということにある。その結果、ユーザーは、なおも、確認マッチング及び決済を目的として電話及びファクシミリ機などのさらに旧式の手作業システムに頼らざるを得ない。
【００１２】
既存の自動オンライン取引システムに付随して、投資及び拡張可能性に関わる多大な問題も存在している。その取引コストを削減し、その他の市場参入者と足並をそろえるために、銀行は、実時間又はほぼ実時間の応答を提供できるように（電子ディーリングとして知られているサービス）電子手段を通して外国為替取引についての競合力ある指し値（建値）をその顧客にオファーする必要がある。可能な場合、銀行は、その業務パッケージのブランド部分として顧客に対して直接電子ディーリングサービスを提供することによる多大な利点を選好しこれを達成する。
【００１３】
しかし、電子ディーリングサービスを提供するためにフルレートのストリーミング能力を構築することには、多大な技術投資と価格監視のためのマーケットメーカーの雇用という支出が必要となる。しかしながら、数多くの状況において、小規模銀行によって実行される金融取引は少量であるために、この大きな投資は正当化されない。一方で、大規模銀行は、電子ディーリングに必要とされる大きい技術投資を行なうことによりその価格形成効率を改善してきた。その結果、業界は、整理統合に向かう著しい傾向を経験し、それにより、増々数少なくなるより大規模な銀行により増々多くの外国為替取引が実行されることになる。２００２年にユーロマネー（Ｅｕｒｏｍｏｎｅｙ）が行なった世論調査によると、例えば、全外国為替取引の４５％が上位５行の銀行により扱われている。２年前のこの数字は３６％にすぎなかった。
【００１４】
さほど大きな投資をすることなく電子ディーリングを提供しようとして、小規模銀行は、自らの流動資産取引をより大規模な銀行にアウトソーシングすることを試みてきた。しかしながら大規模及び小規模の両方の銀行による流動性アウトソーシング主導権を設定しようとする従来の試みは、標準的に１つの大規模銀行のみを相手にするための小規模銀行側による多大なコミットメントが関与することから、業界内での牽引能力は得られなかった。例えば、小規模銀行は、標準的に、小規模銀行のコンピュータシステムを大規模銀行のプロプライエタリ指値ストリーミングシステム（proprietary quote-streaming system）に連携させるカスタマイズされた技術的統合に投資しなくてはならない。コミットメントを実施し、大規模銀行がシステムを切換えるか又は約定通りの業務を提供するのに失敗した場合に発生しうる損失から小規模銀行を保護するために、２つの銀行は通常、業務レベル契約を交渉しなければならず、アウトソーシング主導権の複雑さはさらに増大する。
【００１５】
従って、顧客、ディーラー、トレーダー及び流動性プロバイダが、手作業システムに頼る必要なく、以前に実行されたディールを確認し決済することができるようにする自動化されたオンライン取引システムに対するニーズが存在する。さらに、小規模なマーケットメーカー、ディーラー及び流動性プロバイダに対して、流動資産取引アウトソーシング能力を提供する自動オンライン取引システムに対するニーズが存在する。これにより、彼らは、（小規模の借手とのディーリングに付随する市場リスクを引受けて、市場の小規模銀行の顧客に到達することを、標準的にできない又はしたくない）大規模なマーケットメーカー及び大規模な組織と競合力ある価格をオファーすることが可能となる。
【００１６】
本発明は、従来のオンライン取引システムがもつこれらの問題点の全てならびに長い間感じられてきたもののこれまで満たされていないその他の数多くのニーズを対処するものである。
【００１７】
発明の概要
一般に本発明は、以前に実行された金融取引（previously-executed financial transaction）を処理するためのコンピュータシステムにおいて、データ通信網に対するインタフェース；メッセージデータベース；インタフェースに結合され、かつデータ通信網を介して遠隔コンピュータに対するオンライン接続を確立し、以前に実行された金融取引に関する詳細セット（aset of details）を含んで構成される入メッセージをオンライン接続を介して遠隔コンピュータから受信し、データベース内に入メッセージを記憶する、ように構成されている決済用プロセッサ、を含んで構成されるコンピュータシステムを含む。
【００１８】
好ましい実施形態においては、決済用プロセッサはさらに、以前に実行された金融取引を計上（booking）する前に（オンライン接続を介して）遠隔コンピュータに対しマッチ状況（match status）を提供するように構成されている。マッチ状況は、マッチが発見されたか否かを遠隔コンピュータ（ひいては遠隔ユーザー）に示す。遠隔ユーザーはこのとき、決済詳細（settlementdetails）に関してどんな動作を行なうべきかを契約相手に知らせるように構成されている決済用プロセッサに対し送り戻される、処理及び決済命令を提供するように促され得る。一部のケースでは、マッチ状況は、１つのマッチが発見されたという事実を示し、単に遠隔ユーザーに対しその取引を進めるべく確認するよう促す可能性がある。さらにその他のケースでは、マッチ状況は例えば、多数のマッチが発見されたこと、詳細に関する取引が契約相手により取消されたことなどを表わすことができる。
【００１９】
決済用プロセッサは同様に、オンライン接続を制御するように構成されたセッションマネージャ及び遠隔コンピュータとのデータ通信を制御するように構成されたユーザーインターフェースマネージャを含むこともできる。好ましい実施形態においては、ユーザーインターフェースマネージャはさらに、遠隔コンピュータ上でラン中であり得るアダプタプログラム（以下で記述）でデータ通信を制御する又は容易にするように構成されている。
【００２０】
本発明の実施形態と一貫性あるコンピュータシステムは同様に、入メッセージ内の詳細セットと第２のメッセージ内の第２の詳細セットの間にマッチが存在するか否かを決定するように構成されているマッチングサブシステムをも含んで構成される。好ましい実施形態においては、マッチングサブシステムは、ワークフロープロセッサコンポーネント及びこのワークフロープロセッサの制御下で第１の詳細セットを第２の詳細セットに比較するように構成されたマッチングエンジンを含む。決定を行なう前に、マッチングサブシステムは、メッセージデータベースからの両方のメッセージを検索するように構成されていてよい。マッチが発見された場合、マッチングサブシステム（又代替的には決済用プロセッサ）はさらに、以前に実行された金融取引を永久的に計上する（かくして条件付きで計上された状況を除去する）ように構成され得る。
【００２１】
コンピュータシステムは、取引詳細を含むメッセージを記憶するように構成されたメッセージデータベースをさらに内含できる。このようなメッセージデータベースが提供されている場合、ワークフロープロセッサ（又、代替的には、決済用プロセッサ）は、さらに、メッセージデータベースへ及びメッセージデータベースからのメッセージを記憶し検索するように、かつ、メッセージデータベース内に記憶されたマッチングメッセージと結びつけられたワークフローを制御するように構成されていてよい。
【００２２】
一部の実施形態においては、コンピュータシステムはさらに、（指値を受信することなどによって）以前に実行された金融取引に参加するため、（顧客といったような）一方の当事者からのＲＦＱといった当初の要請（original request）を、もう１つのオンライン接続を介して受信し、マッチングサブシステムがマッチが存在するか否かを決定する前に、以前に実行された金融取引を条件付きで計上するように構成された取引実行ステージプロセッサ、をさらに含むことができる。例えば、本発明は、有利には、共に２００２年９月１０日付けで提出され本出願の譲受人に譲渡されている「金融取引を行なうための方法及び装置」（「ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＣＯＮＤＵＣＴＩＮＧ  ＦＩＮＡＮＣＩＡＬ  ＴＲＡＮＳＡＣＴＩＯＮＳ」）という題の同時係属出願第１０／２３７，９７２号明細書及び「金融取引を補正するための方法及び装置」（「ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＡＭＥＮＤＩＧ  ＦＩＮＡＮＣＩＡＬ  ＴＲＡＮＳＡＣＴＩＯＮＳ」）という題の米国特許出願第１０／２３７，９８０号明細書に記述されている実行段及び実行後段の発明と組合わせることができる。これらの同時係属出願は両方共、本書にその全体が参考として内含されている。
【００２３】
金融取引詳細セットは標準的に、以前に実行された金融取引についての契約相手を識別する少なくとも１つのフィールドを含む。かくして、決済用プロセッサはさらに、好ましい実施形態においては、該フィールド内で名前が挙げられている契約相手に対し第２のオンライン接続を確立し、かつ第２のオンライン接続を介して該契約相手からの確認を受信した後に初めて以前に実行された金融取引を計上するように構成されている。さらに、決済用プロセッサは、以前に実行された金融取引が計上されたことを示す通知書を生成し関係当事者に送るように構成されていてよい。
【００２４】
一部の実施形態においては、本発明は、決済用プロセッサと共に又は決済用プロセッサの制御下で、遠隔コンピュータ上で実行するように構成されているアダプタプログラムを内含する。アダプタプログラムは、遠隔コンピュータ上でラン中のユーザーアプリケーションから入メッセージを受信し、データ通信網上で遠隔コンピュータから決済用プロセッサへ入メッセージを伝送する。遠隔コンピュータ上でラン中のユーザーアプリケーションが、決済用プロセッサ又はマッチングサブシステムと互換性のないフォーマットでメッセージデータを提供する場合には（通常は、ユーザーアプリケーションがプロプラエタリソフトウェアプログラムであることを理由として）、アダプタプログラムはさらに、決済用プロセッサに対しメッセージを送達する前に互換性のあるフォーマットへと入メッセージを翻訳するように構成され得る。アダプタプログラムは同様に、データ通信網を介して決済用プロセッサから出メッセージを受信し、ユーザーアプリケーションに対して出メッセージを送るように構成されてもよい。必要な場合、アダプタプログラムは同様に、ユーザーアプリケーションと互換性のあるフォーマットへと出メッセージを翻訳するようにも構成され得る。
【００２５】
メッセージ翻訳の機能は又、本発明のコンピュータシステム内の他の場所に常駐することもできる。例えば、（アダプタプログラムではなくむしろ）決済用プロセッサは、メッセージデータベース内に入メッセージを記憶することによってメッセージをマッチングサブシステムにとって利用可能なものにする前に、マッチングサブシステムと互換性のあるフォーマットへと入メッセージを翻訳するように構成されていてもよい。例えばＸＭＬハイパーテキストトランスポートマークアップ言語（ＨＴＭＬ）又はＳＷＩＦＴ  ＭＴ３００フォーマットを含めた当業者にとって既知のさまざまな異なるフォーマットをメッセージデータのために使用することができる。
【００２６】
データ通信網及びオンライン接続は、任意のローカルエリア又は広域ネットワーク、又は例えば法人用イントラネット、インターネット、仮想プライベートネットワーク又は金融取引を取扱うために世界金融市場で使用されているネットワークであるＳＷＩＦＴネットワークを含めた任意の相互接続されたコンピュータネットワークのコンポーネントを含むことができる。
【００２７】
本発明は同様に、以前に実行された金融取引を決済するためのコンピュータ援用方法において、以前に実行された金融取引についての当事者Ａパースペクティブ詳細セットを当事者Ａから受信する段階；以前に実行された金融取引についての当事者Ｂパースペクティブ詳細セットを当事者Ｂから受信する段階；当事者Ａパースペクティブ詳細セットが当事者Ｂパースペクティブ詳細セットとマッチするか否かを決定する段階；当事者Ａに対し、以前に実行された金融取引に関する情報を伝達するように構成されたオンライン接続をデータ通信網を介して当事者Ａのために確立する段階；当事者Ａパースペクティブ詳細セット及び当事者Ｂパースペクティブ詳細セットをオンライン接続を介して当事者Ａに伝送する段階を含む方法をも提供する。当事者Ａパースペクティブ詳細セットと当事者Ｂパースペクティブ詳細セットの間にマッチが発見された場合には、以前に実行された金融取引を計上するか、又は代替的に、当事者Ａからの確認又は受諾の受理の間に計上のためにフラグすることができる。
【００２８】
必ずしも全てではないものの大部分のコンテクストにおいて、当事者Ａは、金融商品を購入又は売却しようとする顧客であり、当事者Ｂは、顧客が獲得したいと思っている金融商品をディーリングする銀行又はその他の機関といったディーラー、トレーダー、マーケットメーカー又は流動性プロバイダである。
【００２９】
該方法はさらに、以前に実行された金融取引を計上する段階に先立ち、オンライン接続を介して当事者Ａに対しマッチ状況を提供する段階そしてさらには、それぞれ当事者Ａ及び当事者Ｂから取引詳細の受諾及び確認が受理されてしまうまで取引を計上することを回避する段階、を含むことができる。一部の実施形態においては、本発明は同様に、実行ステージ自動トレーディングシステム（execution-stage automatic trading system）を通して記入される当初のＲＦＱなどを通して、以前に実行された金融取引に参加するべく一方の当事者からの当初の要請をもう１つのオンライン接続を介して受信する段階；及びマッチが存在するか否かを決定する段階に先立ち、以前に実行された金融取引を条件付きで計上する段階、といった任意の段階をさらに含んで構成される。
【００３０】
本発明の方法はさらに、当事者Ｂに対し、以前に実行された金融取引に関する情報を伝達するように構成された第２のオンライン接続を当事者Ｂのために確立する段階、及び当事者Ａパースペクティブ詳細セット及び当事者Ｂパースペクティブ詳細セットを第２のオンライン接続を介して当事者Ｂに伝送する段階を含むことができる。当事者Ａパースペクティブ詳細セットと当事者Ｂパースペクティブ詳細セットの間にマッチが発見された場合、第２のオンライン接続を介して当事者Ｂに対し、該マッチを示すマッチ状況も同様に供給され得る。一方、いかなるマッチも発見されない場合、マッチ状況は、無マッチ状況を指示するように構成され得る。
【００３１】
好ましい実施形態においては、該方法はさらに、当事者Ａのためのオンライン接続を介して該マッチ状況に応答して当事者Ａから処理用指令（processing directive）を受信する段階；及び第２のオンライン接続を介して当事者Ｂから該処理用指令についての確認を受信する段階、を含んで構成される。このような実施形態においては、取引を計上するという次の段階は、処理用指令及び確認を受理することをその条件とすることができる。
【００３２】
以前に実行された金融取引は、外国為替取引を含むことができるが、これを含む必要はない。換言すると、取引は同様に、株式又は金融市場取引を含む（ただしこれに制限されるわけではない）さまざまなその他のタイプの金融取引を含むこともできる。
【００３３】
好ましい実施形態においては、受信段階の各々は、ＳＷＩＦＴ  ＭＴ３００確認メッセージを受信する段階を含んで構成される。その上、当事者Ａパースペクティブ詳細セット及び当事者Ｂパースペクティブ詳細セットは標準的に、なかでも、以前に実行された金融取引についての経済的詳細（economic details）、勘定識別子（account identifiers）及び契約相手識別子（counterpartyidentifiers）を内含する。好ましくは、必ずしも必要というわけではないが、メッセージ送信データベースが、以前に実行された金融取引についてのメッセージ及び取引詳細を記憶するために使用される。
【００３４】
上述した通り、本発明の好ましい実施形態は、以前に実行された金融取引を交渉し作成するために、Ｆｘａｌｌトレジャリーセンター（Ｆｘａｌｌ  Ｔｒｅａｓｕｒｙ  Ｃｅｎｔｅｒ）として知られているニューヨーク州、ニューヨークのＦＸアライアンス社（ＦＸ  Ａｌｌｉａｎｃｅ，Ｉｎｃ．）（ｗｗｗ．ｆｘａｌｌ．ｃｏｍ）により操作されている外国為替トレーディングポータルといったようなディール実行段コンピュータ化オンライン取引処理システムを使用する段階を内含する。しかしながら、以前に実行された金融取引は、同様に、トレーディング交換において発生することになるような電話、ファクシミリ又は直接会合といったようなさまざまな手作業方法を通して開始、交渉、作成され得る。
【００３５】
本発明のさらにもう１つの態様においては、複数の以前に実行された金融取引を処理するためのコンピュータ援用方法が提供されている。この態様においては、該方法は、複数の以前に実行された金融取引内の、当事者Ａ及び当事者Ｂが関与する、１つの以前に実行された金融取引と結びつけられた入メッセージを受信する段階；当事者Ａ又は当事者Ｂから以前に受信したメッセージの中に含まれた第２の詳細セットとマッチする詳細セットを入メッセージが含んでいるか否かを決定する段階；当事者Ａに対し、以前に実行された金融取引に関する情報を伝達するように構成されたオンライン接続を当事者Ａと確立する段階；詳細セット及び第２の詳細セットをオンライン接続を介して当事者Ａに伝送する段階を含む。詳細セット及び第２の詳細セットの間にマッチがある場合には、以前に実行された金融取引を計上することができる。
【００３６】
前述の態様の場合と同様に、本方法はさらに、以前に実行された金融取引を計上する段階に先立ち、オンライン接続を介して当事者Ａに対しマッチ状況を提供する段階、及びマッチが存在するか否かを決定する段階に先立ち、以前に実行された金融取引を条件付きで計上する段階、をさらに内含することができる。計上段階は、当事者Ｂに対し、以前に実行された金融取引に関する情報を伝達するように構成された第２のオンライン接続を当事者Ｂのために確立する段階；オンライン接続を介して、マッチ状況に応答する処理用指令を当事者Ａから受信する段階；第２のオンライン接続を介して、当事者Ｂに対し処理用指令を伝送する段階；及び処理用指令に応答する確認を第２のオンライン接続を介して当事者Ｂから受信する段階、を含んで構成される可能性がある。
【００３７】
受信段階は、メッセージデータベース内に入メッセージを記憶する段階；入メッセージが当事者Ａから以前に受信したメッセージについての補正要請を含んでいるか否かを決定する段階；入メッセージが当事者Ａから以前に受信したメッセージについての取消し要請を含んでいるか否かを決定する段階；及び／又は入メッセージが決済命令セットを含むか否かを決定する段階を含むことができる。入メッセージが決済命令を含まない場合、本発明は任意には、入メッセージに対し決済命令セットを付加する段階を実施する。
【００３８】
受信段階は、メッセージマッチングキュー内に入メッセージを置く段階；及び、入メッセージが受信されたことを示す通知を当事者Ｂに送る段階を含むことができる。好ましい実施携帯においては、入メッセージが受信されたことを示す通知を第三者（例えばプライムブローカ又は資金調達銀行）に送ることもできる。さらに、一部の実施形態においては、受信段階は、入メッセージをＳＷＩＦＴ  ＭＴ３００フォーマットに転換させる段階を含んで構成される。
【００３９】
さらに、決定段階には、１つのメッセージ状況を入メッセージに割当てる段階及び第２の詳細セットがマッチングされたことを示す通知を関係当事者及び参加者に送る段階が含まれていてよい。
【００４０】
メッセージがひとたびマッチングされた時点で、本発明は、マッチングしたセットに関する金融取引を決済するための命令について当事者Ａからの決済命令選定（settlement instruction election）を受諾するように構成され得る。かくして、当事者Ａユーザーは、標準の決済命令の予め定義されたセットを使用すること、又は全く新しい決済命令セットを提供すること又は予め定義された命令セットを編集することを選定できる。
【００４１】
該方法はさらに、ユーザー（通常は当事者Ａ又は顧客）に対し、複数の以前に実行された金融取引についてのネット決済支払いセット（a set of netted settlement payments）を提示する段階を含むことができる。標準的には、必ずしも必要ではないものの、ネット決済支払の計算段階には、複数の以前に実行された金融取引内の、１つの以前に実行された金融取引サブセットについての、選択された勘定決済日（selectedvalue date）及び勘定と契約相手の選択された組合せ（selected combination of accounts andcounterparties）をオンライン接続を介して当事者Ａから受信する段階、及び選択された勘定決済日及び選択された組合せに基づいて該サブセットについてのネット支払いセットを計算する段階が含まれる。次に該ネット決済支払いセットは、確認命令のためオンライン接続を介して当事者Ａに対して、そして承認のため選択された組合せの中の各々の契約相手に対して伝送される。
【００４２】
さらに、ネッティング計算段階は、規定のネッティング方式（netting mode）を用いて実施することができる。規定のネッティング方式には、例えば、以前に実行された金融取引のサブセットの中の各々の通貨ペアについてのネット支払いを生成することが必要とされ得る。代替的には、規定のネッティング方式には、以前に実行された金融取引のサブセット内の各通貨についてのネット支払いを生成することが必要とされ得る。これらのモードは「双方向ネッティング」と呼ばれる。しかしながら、規定のネッティング方式は、当事者Ａが支払うべき決済支払いを減少させるか又は削除するべく当事者Ａ以外の２者以上の契約相手の間で直接支払われるべきネット支払いセットを生成するプロセスである「多方向」ネッティングをも必要とする可能性がある。ネッティング方式については、「ネッティング」という表題の項で以下にさらに記述されている。
【００４３】
本発明のさらにもう１つの態様においては、金融取引を処理するためのクライアントサーバーモデルのコンピュータシステムが提供される。クライアントサーバーコンピュータシステムは、以前に実行された金融取引に関する２つの金融取引詳細セットについてのマッチ状況を生成するように構成された、決済サーバープログラムの制御下で動作するマッチングサブシステムを含んで構成される。該決済サーバープログラムは、第１のデータ通信チャンネルを介してブローカークライアントプログラムに２つの取引詳細セット及びマッチ状況を伝送し、マッチ状況に応答して処理用指令をブローカークライアントプログラムから受諾するように構成されている。決済サーバープログラムは次に、第２の通信チャンネルを介してプロバイダクライアントプログラムに、そして第２の通信チャンネルを介してカスタマークライアントプログラムに該処理用指令を伝送し、入力に応答して、以前に実行された金融取引を計上する。とりわけ、プロバイダ入力は、処理用指令の前にも到着してもよい。
【００４４】
本発明のさらにもう１つの態様においては、当事者Ａ（標準的には顧客）、当事者Ｂ（実行銀行）及び当事者Ｃ（プライムブローカー）の間の金融取引のプライムブローカ業務を行なうという概念を実施するためのコンピュータシステムが提供されている。プライムブローカ取引においては、当事者Ａ及び当事者Ｂは、各々がそのディール内での仲介人として当事者Ｃを使用するという了解の下で１つの取引を実行することに同意する。従って、当事者双方は、当事者Ｃに対し取引を「ギブアップする」ことに同意する。
【００４５】
この態様に従うと、コンピュータシステムは、データ通信網に対するインタフェース；該インタフェースに結合され、かつデータ通信網を介して当事者Ａのための第１のオンライン接続を確立し、データ通信網を介して当事者Ｂのための第２のオンライン接続を確立し、当事者Ａと当事者Ｃの間の第１の金融取引に関する当事者Ａギブアップ詳細セットを第１のオンライン接続を介して当事者Ａから受信し、及び当事者Ｂと当事者Ｃの間の第２の金融取引に関する当事者Ｂギブアップ詳細セットを第２のオンライン接続を介して当事者Ｂから受信するように構成された決済用プロセッサを含んで構成される。
【００４６】
、
同様に、当事者Ａギブアップ詳細と当事者Ｂギブアップ詳細の間にマッチが存在するか否かを決定するように構成されたマッチングサブシステムも含まれており、マッチが存在する場合、決済用プロセッサはさらに、当事者Ａと当事者Ｃの間の第１の金融取引を計上し、当事者Ｂと当事者Ｃの間の第２の金融取引を計上するように構成されている。好ましい一実施形態においては、決済用プロセッサは、さらに、第１の金融取引を計上する前に第１のオンライン接続を介して当事者Ａに対しマッチ状況を提供し、かつ、第２の金融取引を計上する前に当事者Ｂに対しマッチ状況を提供するように構成されている。
【００４７】
本発明の前述の態様の場合と同様に、好ましい実施形態は、もう１つのオンライン接続を介して、当事者Ｂとの以前に実行された金融取引に参加するための当事者Ａからの当初の要請を受信し；マッチングサブシステムが、マッチング決済詳細が発見されたか否かを決定する前に、第１及び第２の金融取引を条件付きで計上するように構成された取引実行ステージプロセッサを内含する。
【００４８】
標準的には、当事者Ｂとの以前に実行された金融取引に参加するための当事者Ａからの当初の要請は、当事者Ａと当事者Ｃの間の先行する取決め（及び書面による契約又は口頭での合意）に基づくＲＦＱである。該取決めには、例えば、信用限度（credit limit）、通貨ペア制約（currency pair restriction）、先日付制限（forward datelimitation）、特定勘定又は勘定グループの使用要件、実行日付制約（execution date restriction）、及び決済日付制約（settlementdate restriction）、又は以上のものの全てのうちの１つ以上のものの何らかの組合せといったような、当事者Ａが着手した取引に対し当事者Ｃが課したある種の制約を規定することができる。
【００４９】
以前の取引を実行するために例えばＦｘａｌｌトレジャリーセンターなどの取引実行ステージプロセッサを使用することの１つの利点は、ＲＦＱが当事者Ｂに送られる前でさえ当事者Ａと当事者Ｃの間の取決めをチェックするように取引実行ステージプロセッサを構成することができるという点にある。この機能は、当事者Ｃ及び当事者Ｂが、当事者Ａとのディーリングに付随する市場及び信用リスクに対する自らの露呈を管理し、当事者Ａが特定的に許可されていないディールを実行しないようにする方法を提供する。
【００５０】
本発明のこの態様における決済用プロセッサは、さらに、当事者Ｃのための第３のオンライン接続を確立し、当事者Ａに代って、当事者Ｃに対し当事者Ａのギブアップ詳細を伝送し、当事者Ｂに代って、当事者Ｃに対し当事者Ｂのギブアップ詳細を伝送するように構成されていてよい。好ましくは、当事者Ａのギブアップ詳細及び当事者Ｂのギブアップ詳細が当事者Ｃに伝送されたという通知書が、当事者Ａ及び当事者Ｂに送られる。
【００５１】
さらに、好ましい一実施形態においては、決済用プロセッサは、当事者Ａのギブアップ詳細及び当事者Ｂのギブアップ詳細を当事者Ｃに対する伝送に応答して、当事者Ｃから当事者Ｃのギブアップ受諾を管理し、当事者Ｃに代って当事者Ａ及び当事者Ｂに対し当事者Ｃのギブアップ受諾を伝送し、受諾に基づいて金融取引を計上する。とりわけ、当事者Ａと当事者Ｃの間の第１の金融取引は、当事者Ｂと当事者Ｃの間の第２の金融取引よりもわずかに高いレートで計上され、かくして当事者Ｃに取引に参加するための１取引あたりの手数料を提供することが可能である。代替的には、当事者Ｃは、定期的に当事者Ａに対しかかる参加について請求書を送付することができる。
【００５２】
好ましい実施形態においては、決済用プロセッサはさらに、第１及び第２の金融取引が計上されたことの通知を当事者Ａ及び当事者Ｂに伝送するように構成されている。
【００５３】
或る種の状況においては、当事者Ａ及び当事者Ｂは、当事者Ｃに対し取引全体をギブアップしないことを選択するかもしれない。本発明に従って動作するシステムは、この状況をも取扱うように構成され得る。かくして、決済用プロセッサはさらに、当事者Ａから第１のオンライン接続を介して、当事者Ａと当事者Ｂの間の、当事者Ｃにギブアップされていない以前に実行された金融取引の一部分を含む第３の金融取引に関する当事者Ａの詳細セットを受信するように構成されていてよい。このようなケースでは、決済用プロセッサは、さらに第３の金融取引に関する当事者Ｂの詳細セットを当事者Ｂから第２のオンライン接続を介して受信するように構成されていてよい。マッチングサブシステムはさらに、当事者Ａの詳細と当事者Ｂの詳細の間に第２のマッチが存在するか否かを決定するべく構成されており、第２のマッチが存在する場合、決済用プロセッサはさらに第３の金融取引を計上するように構成されている。
【００５４】
その他の実施形態及び態様の場合と同様に、決済用プロセッサはさらに、第３の金融取引を計上する前に当事者Ａの詳細及び当事者Ｂの詳細についてのマッチ状況を提供し、かつマッチングサブシステムが、第２のマッチが存在することを決定する前に、第３の金融取引を条件付で計上するように構成されていてよい。
【００５５】
好ましくは、決済用プロセッサはさらに、当事者Ａより提供された資金割当（fund allocation）（「スプリット」セット）に基づく決済詳細セットを当事者Ｃから受信し、当事者Ｄ（標準的には資金調達銀行）のための第４のオンライン接続を確立し、かつ第４のオンライン接続を介して当事者Ｄに対し決済詳細セットを伝送するように構成されている。なかでも、前記決済詳細セットは、資金調達勘定（fundingaccount）、資金調達金額（funding amount）、勘定決済日又は以上のもの全てのうちの１つ以上のものの何らかの組み合わせを表わすデータを含むことができる。その上、決済用プロセッサは、さらに、決済詳細セットに応答して当事者Ｄの決済確認メッセージを当事者Ｄから受信し、当事者Ｄに代って当事者Ｃに対し当事者Ｄ決済確認メッセージを伝送し、当事者Ｄ決済確認メッセージに応答して当事者Ｃ確認メッセージを当事者Ｃから受信し、かつ当事者Ａに対し当事者Ｃ決済確認メッセージを伝送するように構成されている。マッチングサブシステムは、次に、当事者Ｃ決済確認メッセージと当事者Ａが当初に提供した決済詳細セットの間にマッチが存在するか否かを決定するように構成されていてよい。
【００５６】
本発明のさらにもう１つの態様においては、当事者Ａ及び当事者Ｂが関与するプライムブローカ取引を処理するためのコンピュータ援用方法が提供されている。該方法は、データ通信網を介して当事者Ａのための第１のオンライン接続を確立する段階、データ通信網を介して当事者Ｂのための第２のオンライン接続を確立する段階、当事者Ａと当事者Ｃの間の第１の金融取引に関する当事者Ａギブアップ詳細セットを第１のオンライン接続を介して当事者Ａから受信する段階、及び当事者Ｂと当事者Ｃの間の第２の金融取引に関する当事者Ｂギブアップ詳細セットを第２のオンライン接続を介して当事者Ｂから受信する段階、当事者Ａギブアップ詳細と当事者Ｂギブアップ詳細の間にマッチが存在するか否かを決定する段階、及びマッチが発見された場合、当事者Ａと当事者Ｃの間の第１の金融取引を計上し、当事者Ｂと当事者Ｃの間の第２の金融取引を計上する段階を含んで構成される。
【００５７】
任意には、該方法は、もう１つのオンライン接続を介して、当事者Ｂとの以前に実行された金融取引に参加するための当事者Ａからの当初の要請を受信する段階；マッチングサブシステムが、マッチが存在するか否かを決定する前に、第１の金融取引を条件付きで計上する段階、及びマッチングサブシステムが、マッチを発見する前に、第２の金融取引を条件付きで計上する段階を内含する。好ましい実施形態においては、当事者Ｂに対し当初の要請を伝送する前に、当事者Ａに前記当初の要請を行なうことを許可する当事者Ａと当事者Ｃの間の取決めがチェックされる。
【００５８】
さらにもう１つの態様においては、本発明は、流動資産取引（liquidity transactions）をアウトソーシングすることによって金融取引を処理するためのコンピュータ援用方法を提供している。この方法は、（１）顧客と関係をもつ実行銀行に向けられた、顧客からの当初の金融取引のための当初の商取引要請を受信する段階；（２）当初の商取引要請に基づいて２次商取引要請を生成する段階；（３）アウトソーシング規則セット（aset of outsourcing rules）に基づいて選択されているプロバイダセット（a set of providers）に対し、関係銀行に代って２次商取引要請を提出する段階；（４）２次商取引要請に応答して、当初の応答ストリームをプロバイダセットのサブセットから受信する段階；（５）２次応答ストリームを形成するべく当初の応答ストリームから１つ以上の応答を選択する段階；（６）当事者Ｂに代って当事者Ａに対して前記２次応答ストリームを伝送する段階；及び（７）２次応答ストリームに応答して当事者Ａからの受諾を受信する段階；及び（８）受諾に応答して、（ｉ）前記当初の応答ストリーム及び仲裁規則セット（aset of arbitration rules）に基づいて被選択プロバイダを選ぶ（choosing a selected provider）段階、（ｉｉ）関係銀行に代わって、選択されたプロバイダに対し受諾を転送する段階、（ｉｉｉ）受諾に応答して選択されたプロバイダからの確認を受信する段階、及び（ｉｖ）確認の受信と実質的に同時に、当初の金融取引に基づいて一対の金融取引を計上する段階、を含んで構成され、該金融取引ペアは、顧客と関係銀行の間の第１の金融取引及び関係銀行と選択されたプロバイダの間の第２の金融取引を含んで構成される。
【００５９】
当初の及び２次商取引要請は、応答要請（ＲＦＱ）を含むことができ、当初の及び２次応答ストリームは、価格応答ストリーム（streams of price responses）を含むことができる。例えば、外国為替市場においては、顧客及びプロバイダは、取引を開始するためにＲＦＱプロトコルを使用する慣習を確立している。しかしながら、ＲＦＱプロトコルには、「アットベスト」プロトコル、「キルオアフィル」プロトコル、「レスティングオーダー」及び「アットフィックス」プロトコルといったような数多くの代替物が存在し、これらについては以下でさらに詳しく記述する。
【００６０】
好ましくは、必ずしも必要というわけではないが、関係銀行により、アウトソーシング規則セット及び仲裁規則セットが規定され、当初の応答ストリームから１つ以上の応答を選択する段階は実時間ベースで行なわれる。その上、好ましい実施形態においては、該方法は、当初の応答ストリームから選択された１つ以上の応答に対しスプレッドを付加する段階を内含する。この態様では、アウトソーシング規則セット及び仲裁規則セットは、当事者双方及び市場全般に結びつけられたさまざまな要因に基づいている可能性がある。例えば、これらの規則は、当初の商取引要請に結びつけられた通貨指定（currency designation）、当初の商取引要請に結びつけられた時間帯、当事者Ａに結びつけられた信用リスク、当初の商取引要請に結びつけられた市場リスク、当初の商取引要請に結びつけられた資金調達金額、プロバイダセット内の１つ以上のプロバイダに結びつけられた可用性状況（availabilitystatus）、プロバイダセット内の１つ以上のプロバイダに結びつけられた事業目標百分率（target percentage of business）、プロバイダセット内の１つ以上のプロバイダに結びつけられた関係銀行についての可用信用状況（availablecredit status）、プロバイダセット内の１つ以上のプロバイダについてのパフォーマンス判定基準又はサービス品質保証（performancemetric or service level agreement）に基づいている。アウトソーシング及び仲裁規則は同様に、以上で挙げた要因の全てのうちの１つ以上のものの組合せに基づく可能性もある。アウトソーシング及び仲裁規則は、好ましい実施形態において、関係ルータープログラム又はプロセッサ（relationshiprouter program or processor）を用いて実施され得る。
【００６１】
本発明は同様に、プロバイダセット内の各々の流動性プロバイダについてのパフォーマンスメトリックセットを追跡して、プロバイダセットについての履歴パフォーマンスレコードを形成する段階；及び履歴パフォーマンスレコードに基づいて規則セットを自動的に調整する段階をも内含しうる。これらの測定基準は、例えば、受信した確認の数、平均応答時間、平均価格差、平均価格安定性等級（average price stability rating）、平均呼値スプレッド、又は確認されたディールに対するオファーの百分率（percentageof offers to deal confirmed）を内含し得る。該測定基準は同様に、以上で挙げたカテゴリのうちの１つのカテゴリの中の１つ以上のプロバイダについてのパーセンタイル等級（percentileranking）に基づくものであってもよい。
【００６２】
該システムは、２次商取引要請を受信するプロバイダの一部が、所要時限内に該商取引要請に応答することになるという事実を考慮している。プロバイダの一部は全く応答しないかもしれない。このような場合には、充分なプロバイダが応答を提供しなかった場合、２次商取引要請が第２のプロバイダセットに送られる（又は第１のプロバイダセットに再送される）ことになるように、仲裁規則セットを適合させることができる。該システムを、例えば最初に１人のプロバイダのみに対し２次要請を送るように構成することさえできる。そのプロバイダが所要時限（例えば１０秒）以内に応答できなかった場合には、もう１つの２次商取引要請をもう一人のプロバイダ（又はプロバイダセット）に送ることができる。このとき第１のプロバイダが応答したならば、仲裁規則は同様にその応答を受諾すべきか又は無視すべきかを指示することもできる。
【００６３】
一部の実施形態においては、本発明は、ウェブベースのレートエンジン（web-based rage engine）として実現可能である。該システムは、Ｆｘａｌｌ，Ｉｎｃ．又はもう１つのトレーディングプラットフォームにより中央でホスティングされ得る。好ましい実施形態においては、レートエンジンはＦｘａｌｌトレーディングセンターアプリケーションをラン中のサーバーに接続する。顧客が送った各々のトレード要請は、関係銀行によって確立された規則を用いて１つ以上の流動性プロバイダに対して透明な形で導かれる。リダイレクションプロセスに気づいているか又は気づいていない顧客は、数秒以内にワールドクラスの価格を受信する。関係銀行は、任意には、ＲＦＱ自体を取扱うことを選択でき、こうしてそれは採算のとれるニッチマーケットに参入することができ、又は、ＲＦＱは流動性プロバイダにより取扱われることができる。
【００６４】
特徴及び利点
買手側と売手側の両方の参入者に対し自動化されたオンライン確認マッチングシステムを提供することが、本発明の特徴である。
【００６５】
本発明のもう１つの特徴は、さまざまな当事者に対する取引詳細の自動送達、ストレートスルー処理及び自動クレジットリスク管理機能を含め、完全に自動化された実時間プライムブローカ業務を実現する方法を、銀行及び流動性プロバイダに提供することにある。
【００６６】
本発明のさらにもう１つの特徴は、流動性アウトソーシング業務を提供するために使用できること及びこのような流動性アウトソーシング業務が文字通りかなりの数のプロバイダからの指値に対する同時アクセスを提供できることにある。本発明のもう１つの特徴は、それが、数多くの異なる目標に合うように適合可能なアウトソーシング及び仲裁規則を通して数多くのプロバイダとの流動資産ルーティング関係を規定、管理及び変更する能力を仲介銀行に提供するという点にある。
【００６７】
さらに、実行は、（ファクシミリ又は電話などによる手作業方法とは異なり）電子手段によって行なわれていることから、確認及び決済メッセージを、多数の当事者まで実質的に同時に流すことができる。実時間又はほぼ実時間の取引処理は、３名以上の当事者間での「アトミック」トレード（“atomic” trades）を達成することを可能にし、かくして、全ての当事者はその参加を実質的に同時に確認する。従って、流動性アウトソーシングのために本発明を使用する利点は、（「関係銀行」と呼ばれる）顧客と関係をもつ銀行が、クライアントからのディールに対するオファーを実際に受諾するか又は拒否する必要がないという点にある。かくして、関係銀行は、市場リスクを引受けることを強制されない。
【００６８】
本発明によると、関係銀行が多数の流動性プロバイダを使用することのみならず、ニーズが生じるにつれて流動性プロバイダの間での切換えを行なうことが容易である。本発明はさらには、切換えを自動的に提供するように構成することさえできる。例えば、関係銀行は、その入顧客ＲＦＱ（incoming customer RFQs）の７５％を関係銀行の１次流動性プロバイダに送り、残りの２５％を関係銀行の２次プロバイダに送ることを選定することができる。さらに、関係銀行に送られた商取引要請を、その後そのディールを実行する機会について競合することになる多数の流動性プロバイダに送ることができる。
【００６９】
顧客にとっての利点としては、関係銀行を通してのトレーディングの利便性ならびにプロダクトの対象範囲の改善及びより一貫性あるプライシングが含まれる。小規模銀行（標準的には関係銀行）は、アウトソーシングコストを低下させ、直接流動資産を提供することに付随する市場リスクを無くする一方で、自らの顧客に対しより質の高いサービスを提供できる点で、恩恵に浴する。又、大規模銀行は、本発明が、信用関係を作り上げることなく新しい顧客に流動資産業務を提供できるようにしながら、プライシング技術に対する投資を開発利用する能力を提供する点で、恩恵をこうむる。
【００７０】
好ましい実施形態においては、本発明は同様に、電子ディーリングサービスをセットアップするのに必要とされる時間及び投資を最小限におさえるように設計されたその他の設備をも提供している。この実施形態には、銀行自体のクレジットエンジンに実時間インタフェースを組込む必要なくトレード前にクレジットをチェックできるようにする形で、一体型クレジットエンジンを提供する又は内含させることが含まれる。チケット処理コストを削減するべく両方の銀行に対し完全なストレートスルー処理を提供するために、オプションの実時間ディールフィードを内含させることも可能である。
【００７１】
本発明は、本明細書の一部を成し、本発明のさまざまな形態のうちの一部の形態の実施例を内含する添付図面を参照することによってより良く理解されることであろう。
【００７２】
好ましい実施形態の詳細な説明
ここで提供されている好ましい実施形態の詳細な説明は、第１に外国外為（ＦＸ）ディールを参考としているが、これらの参考は、本発明をその特定の状況の中でいかに応用できるかをより明確な形で詳しく例示することのみを目的とするものであり、その他の状況における本発明の応用可能性に対する制限となるわけではない。従って、かかる参考は、本発明の範囲から、固定収入、株主資本及び金融市場取引といったような、その応用から恩恵を享受しうるその他の種類の金融取引を除外するものとみなされるべきではない。
【００７３】
用語の定義
本明細書において使用されているように、文脈上その他の意味が指示される場合を除き、以下の用語は、以下で記されている定義を基準にして理解することができる。
【００７４】
ＦＸ用語
「外国為替」又は「ＦＸ」取引（又は「ディール」）とは、「勘定決済日」とも呼ばれる規定された引渡し日の合意されたレートで１つの通貨をもう１つの通貨と交換するための契約である。
【００７５】
「勘定決済日」又は「決済日」というのは、通貨の交換が行なわれることになる日付である。
【００７６】
「ＦＸスポットディール」、「スポットトレード」及び「スポット契約」というのは、ＦＸスポット日において単一の外貨をもう１つの外貨と交換する「すなわち１つの通貨をＸ単位買い、もう１つの通貨をＹ単位売る」ための取引又は契約を意味する。
【００７７】
「ＦＸスポット日」というのは通常、契約が作成される日付から営業日で２日目であり、一定の与えられたトレーディング日において通貨を買売するための最も流動性の高い（すなわち最も安い）日付である。
【００７８】
「スワップ」又は「スワップ契約」という語は、２つの異なる勘定決済日についての特定された額の１つの通貨のもう１つの通貨に対する同時の買入れ及び売却、又は売却及び買入れが関与するディールを意味する。スワップは、単一の契約相手との単一の取引であるものの、この取引は資金の交換が発生する２つの勘定決済日（又は「レッグ」）を有する。
【００７９】
「直物レート」は、マーケットメーカーが基本通貨をもう１つの通貨に対して買入及び売却することになる（ビッド（買値）及びオファー（売値）の組合せとして表現される）レートである。
【００８０】
「オールインレート」というのは標準的に、直売りの状況において、交換が発生する予定の全体的レートを意味する。オールインレートは、直物レート及びＦＸポイント（価格調整）を加算することによって計算される。
【００８１】
「単一直物ポートフォリオ」（ＳＳＰ）というのは、任意の勘定決済日組合せに対する単一の通貨ペア内の１つ以上のレッグが関与するＦＸディールである。ディーリングされる通貨は、全てのレッグについて同じでなくてはならない。ＳＳＰ指値は標準的に、直物レート、非直物勘定決済日の各々についてのＦＸポイント、及び非直物勘定決済日の各々についてのオールインレートという４つの構成要素を有する。
【００８２】
「多重直物ポートフォリオ」又は「マルチ直物ポートフォリオ」（ＭＳＰ）は、任意の勘定決済日組合せにおける多数の通貨ペア内の１つ以上のレッグが関与するＦＸディールである。ディーリングされる通貨は、全てのレッグについて同じではない。
【００８３】
当事者
「プロバイダ」という語は標準的に「流動性プロバイダ」の省略表現である。「流動性プロバイダ」というのは、標準的には、トレーディングシステムにおいてマーケットメーカーの役割を果たす銀行といったような金融機関である。流動性プロバイダは、「顧客」からの要請に応えて指値を行なう。
【００８４】
本書で使用する「銀行」という用語は、標準的に「プロバイダ」と互換的に使用される。
【００８５】
「ディーラー」又は「トレーダ」という語は標準的に、プロバイダ側からシステムを監視し、指値に対する顧客の要請に応える銀行又は流動性プロバイダの１従業員を意味する。
【００８６】
「顧客」という語は標準的に、銀行、プロバイダ、ディーラー又はトレーダでない、システムのユーザーを意味する。顧客は、スワップ、先物又は直物取引といったような特定のＦＸ資産上の価格について１つ以上のプロバイダにたずねることによりディーリングプロセスを開始する。「顧客」は、標準的に、状況に応じて一部のケースでは「ユーザー」と基本的に互換性があるものの、「顧客」は同じく、例えば１つの会社内のようなユーザーの１集団を意味することもできる。
【００８７】
「プライムブローカ」という語は、顧客と１つの関係をもち、顧客が実行銀行（以下に定義する）との取引に携わることができるような形で、外国為替取引の中で顧客の信用リスクを引受けることに同意する中間当事者を意味する。
【００８８】
「実行銀行」という語は、顧客に対し（プライムブローカを通して）流動資産を提供し、従って取引のための市場リスクを引受けるものの顧客とのディーリングに付随するいかなる信用リスクも引受けない銀行又はその他の機関を意味する。
【００８９】
「資金調達銀行」という語は、金融取引において使用されるべき資金及び勘定を物理的に制御する銀行又はその他の機関である。
【００９０】
特徴
「プロバイダプライシングツール」又はＰＰＴという語は、顧客によって提出される価格及び補正要請をプロバイダが受理しこれに応えることができるようにする、本発明に従って構成されたシステムを意味する。ＰＰＴは同様に、本発明の一部実施形態において、「トレジャリーセンター」又は「トレジャリーディスク」プログラム又は「トレジャリーディスク」アプリケーションとも呼ばれる可能性がある。
【００９１】
その他の概念
「ストレートスルー処理」という語は、注文から決済に至るまでのトレーディングプロセスのエンド−ツー−エンド自動化を意味する。これには、トレーディングサイクル内に関与する全ての当業者に対する、できるかぎり早期の、トレード情報のとぎれのない自動化された電子的転送が関与している。
【００９２】
頭文字
ＡＰＩ−アプリケーションプログラマーインターフェース（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｅｒ  Ｉｎｔｅｒｆａｃｅ）。コンピュータ間のインタフェースを表わすために拡張無く、口語的に用いられる。
【００９３】
ＯＭＳ−注文管理システム（Ｏｒｄｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）。注文管理システムは、顧客により、どのＦＸディールがその市場内で実行される必要があるか、それらを誰が実行すべきかなどといったことの記録を維持するために用いられる。１つのディールがひとたび実行されたならば、ＯＭＳは、各ディールについての実行レートで更新される。
【００９４】
ＳＳＰ−単一直物ポートフォリオ（Ｓｉｎｇｌｅ  Ｓｐｏｔ  Ｐｏｒｔｆｏｌｉｏ）。単一の通貨ペアについて多数の勘定決済日が関与する外国為替取引又は「ディール」。プロバイダは、各勘定決済日についてのＦＸポイントと共に単一直物レート（ここからこの名が付いた）を指値する。
【００９５】
ＭＳＰ−多重直物ポートフォリオ（Ｍｕｌｔｉｐｌｅ  Ｓｐｏｔ  Ｐｏｒｔｆｏｌｉｏ）。多数の通貨ペアについての多数の勘定決済日が関与する外国為替取引又は「ディール」。
【００９６】
ＲＦＱ−指値要請（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｑｕｏｔｅ）。特定の通貨ペアについての価格、勘定決済日及び金額に関して問い合わせを行うことにより顧客が１つのトレードを開始する１つのトレーディングプロトコル。銀行は価格を送ることで応答する。その価格を受諾するためには、顧客はプロバイダに「ディールに対するオファー」を送る。
【００９７】
ＵＳＤ−米ドル（Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ  Ｄｏｌｌａｒｓ）。
【００９８】
ＧＢＰ−英国スターリングポンド（Ｕｎｉｔｅｄ  Ｋｉｎｇｄｏｍ  Ｓｔｅｒｌｉｎｇ）。
【００９９】
ＪＰＹ−日本円（Ｊａｐａｎｅｓｅ  Ｙｅｎ）。
【０１００】
ＣＨＦ−スイスフラン（Ｓｗｉｓｓ  Ｆｒａｎｃ。）
【０１０１】
ＥＵＲ−欧州ユーロ（Ｅｕｒｏｐｅａｎ  Ｅｕｒｏ。）
【０１０２】
ＣＡＤ−カナダドル（Ｃａｎａｄｉａｎ  Ｄｏｌｌａｒｓ）。
【０１０３】
ＮＯＫ−ノルウェークローネ（Ｎｏｒｗｅｇｉａｎ  Ｋｒｏｎｅｒ）。
【０１０４】
発明の概要
本発明は、顧客、銀行、流動性プロバイダ、ブローカー、及びマーケットメーカーといったような金融取引契約相手が、多数の契約相手を横断して金融取引を管理し、かつかかる金融取引についての付加的な決済命令及び詳細を自動的かつ効率良く監視し、補正し、確認し提供する有効な低コスト方法を提供する。実行された取引は、電子トレーディングコンピュータシステム又はプラットフォーム上で行なわれている可能性もあれば、又、電話又はファックスといったような１つ以上の手作業システムを介して行なわれている可能性もある。
【０１０５】
高レベルアーキテクチャ説明
本発明のアーキテクチャ全体についての高レベルの説明及びそれに続くその構成要素（例えばマッチング及びプライムブローカ業務アプリケーションなど）のいくつかのより詳細な説明がここで提供されている。
【０１０６】
図１は、本発明に従って動作するように構成されたコンピュータシステムの高レベルブロック図を示している。図１に示されているように、本発明の原理に従ったコンピュータシステム１００は、任意には、ネットワークインタフェース１３８、メッセージデータベース１５０、インタフェース１３８に結合された決済用プロセッサ１１０、マッチングサブシステム１４０を含む。ネットワークインタフェース１３８は、任意には、インターネット、法人インターネット、仮想プライベートネットワーク又はＳＷＩＦＴネットワークといったようなさまざまなタイプのデータ通信網に対するインタフェースを内含することができる。従って、図１に示されているように、ネットワークインタフェース１３８は、これらの種類のデータ通信網に接続するための別々のネットワークインタフェース（Ｓｗｉｆｔ１３２、インターネット１３４及びＶＰＮ１３６といったような図１に示されているもの）を内含しうる。
【０１０７】
好ましい実施形態においては、決済用プロセッサ１１０は、データ通信網１６０を介して遠隔コンピュータ１７０に対するオンライン接続１６２を確立し、かつ、以前に実行された金融取引に関係する取引詳細を含む入メッセージを遠隔コンピュータ１７０から受信するように構成されている。
【０１０８】
一部の実施形態においては、本発明は、オンライン接続１６２を介して決済用プロセッサ１１０に結合され、決済用プロセッサと連動して決済用プロセッサの制御下で遠隔コンピュータ１７０上で実行するように構成されているアダプタプログラム１７２を内含する。ストレートスルー処理用アダプタとして、アダプタプログラム１７２は、金融取引のストレートスルー処理のためのプロプライエタリメッセージ送信フォーマットを利用している可能性のある、遠隔コンピュータ１７０上で走行中の任意のユーザーアプリケーション（図１では１７４と呼称されている）に対するリンクを提供している。好ましくは、アダプタプログラム１７２は、市場における主要なメッセージ送信フォーマットの大部分又は全てとの統合を提供するように構成されている。かくして、遠隔コンピュータ上のユーザーが基本的スプレッドシート又は複雑なトレジャリ管理システムを用いて金融取引を行なう場合、アダプタプログラム１７２は、決済用プロセッサ１１０との通信のための適切なフォーマットに取引メッセージを翻訳するように構成されている。クイックコネクト（ＱｕｉｃｋＣｏｎｎｅｃｔ）として知られる１つのこのような包括的アダプタプログラムは、ニューヨーク州ニューヨークのＦｘａｌｌ社（Ｆｘａｌｌ，Ｉｎｃ．）（ｗｗｗ．ｆｘａｌｌ．ｃｏｍ）から入手可能である。図１に示されているように決済用プロセッサ１１０が多数のタイプのネットワークと動作するように構成されている場合、フォーマット翻訳エンジン１３０として示されているフォーマット翻訳機が、メッセージを（以下で記述する）マッチングサブシステムと互換性のある一般的フォーマットへと転換するために提供される。
【０１０９】
とりわけ、アダプタプログラム１７２は、好ましい実施形態においては、データ通信網１６０を通してオンライン接続１６０を介して決済用プロセッサ１１０からメッセージを受信しかつユーザーアプリケーションにこれらのメッセージを送るためにも構成されている。必要な場合、アダプタプログラムは同様に、出メッセージ（outgoing message）をウェブ又はアプリケーションベースのユーザーインターフェースと互換性のあるフォーマットへと翻訳するようにも構成されている。
【０１１０】
決済用プロセッサ１１０は同様に、オンライン接続１６２を制御するように構成されたセッションマネージャ１１４、及び遠隔コンピュータ１７０とのデータ通信を制御するように構成されたユーザーインターフェースマネージャ１１２をも含んで構成される。メッセージがデータ通信網１６０及びオンライン接続１６２を介して遠隔コンピュータ１７０から入ってくるにつれて、決済用プロセッサ１１０はそのメッセージをメッセージデータベース１５０内に記憶する。
【０１１１】
マッチングサブシステム１４０は、入メッセージ内の詳細セットと第２のメッセージ内の第２の詳細セットの間にマッチが存在するか否かを決定する。かくして、マッチングサブシステム１４０はさらに、ワークフロー処理エンジン１４２及びマッチングエンジン１４４を含む。マッチングエンジン１４４は、ワークフロー処理エンジン１４２の制御下でメッセージ対の詳細を比較するように構成されている。ワークフロー処理エンジン１４２は、マッチング目的のためのメッセージデータベース１５０からメッセージを除去するタスクを管理する。
【０１１２】
任意には、コンピュータシステム１００はさらに、遠隔コンピュータ１７０からのＲＦＱといった当初の商取引要請を受信し、マッチが存在するか否かをマッチングサブシステム１４０が決定する前に、取引を条件付きで計上する（provisionally book）ように構成されている取引実行ステージプロセッサ１８０をさらに内含している。好ましくは、必ずしも必要ではないものの、コンピュータシステム１００はさらに、クレジットマネージャ１８２、又は少なくとも信用データベース（図１には示さず）に対するアクセスを含み、ディール実行プロセッサ１８０はさらに、顧客に代って或る種の取引を計上するに先立ち顧客の信用状況をチェックするように構成されている。好ましい実施形態においては、取引実行ステージプロセッサ（dealexecution stage processor）１８４は、同様に、関係銀行により提供されたアウトソーシング及び仲裁規則に従って流動性プロバイダに対するアウトソーシングを制御するように構成されている関係ルーター１８４も内含している。
【０１１３】
プロセスの高レベルの要約
一般的に言って、本発明は、金融取引及び決済詳細の管理に関する６つの分野を網羅している。これら７つの分野は、確認マッチング、ネッティング、決済命令、第３者通知、プライムブローカ業務、流動性アウトソーシング及び関係ルーティングを内含する。
【０１１４】
図２は、本発明の実践に付随する主要プロセスを例示する高レベルの流れ図を描いている。ステップ２０５で図２に示されているように、メッセージは、図１を参考にして上述した通り、好ましくはデータ通信網上でオンライン接続を介してシステム内に到着するにつれて処理される。マッチングサブシステム（又はマッチングエンジン）が、潜在的マッチについて、システムに到着するアンマッチングメッセージ対を連続的にチェックする。ステップ２１０を参照のこと。マッチングされつつある入メッセージは、さまざまな顧客、プロバイダ、ブローカー又は資金調達機関からの決済命令、確認、ギブアップ詳細、逆ギブアップ詳細などを含む。これらのメッセージは全て、マッチングサブシステムによって処理される。次に、ステップ２１５では、メッセージに対し新しい決済命令を付加し、メッセージ内にすでに含まれている既存の決済命令を変更し、又は標準的決済命令セットを用いてオプションを選択する機会が、顧客に対して与えられている。顧客が新しい決済命令を付加するか又は既存の決済命令を変更する場合、システムは自動的にその取引について契約相手に通知する。このことは従来のシステムに比べ多大な利点がある。
【０１１５】
ステップ２２０に示されているように、本発明を用いて顧客は、予め定義された又は「標準的な」決済命令のセット（ＳＳＩ）を編集することもでき、その場合、システムは自動的に、その決済命令セットを用いて既存のディールを更新する。システムのユーザーは、同様に、システムに対して、マッチング及びアンマッチングの両方のディールについて、（以下で記述する）その他のさまざまな動作を実施するよう命令することもできる。ステップ２２５を参照のこと。そして最後にステップ２３０で、システムのユーザーは、以前に実行された取引を決済するために利用可能なさまざまな異なるタイプのネッティング方式を特定し交渉することができる。かくして、各々のディールを総額で決済する代りに、顧客はその銀行に対し、同じ通貨ペア又は同じ通貨でのディールのために単一回の支払い交換を行なうように命令することができる。とりわけ、システムは、顧客の証券保管機関（カストディアン）に対し、ネット支払いの通知及び受領証を送るように構成され得る。
【０１１６】
確認マッチング
本発明では、買手側顧客及び売手側顧客が差別なく、精巧な確認マッチングサービスを利用する能力を有することになる。好ましい実施形態では、該発明は、電子トレーディングプラットフォーム上及び外で実行されたトレードについて、顧客に代ってＳＷＩＦＴ  ＭＴ３００確認を送受する。しかしながら、当業者にとって既知の確認メッセージのためのその他のフォーマットも同様に、請求対象の本発明の範囲及び精神から逸脱することなく使用可能である。本発明は、マッチング及びアンマッチングメッセージのための集中的ハブとして活動する。かくして、顧客は、該発明に対しディールをアップロードし、係属中の金融取引の状況の変化をダウンロードすることができる。
【０１１７】
該発明は同様に、基本的マッチングプロセスに基づいていくつかの変形形態を実施するように構成することもできる。例えば、顧客は、プロバイダのディール記録をオンラインで確認する代りに手作業でこれを確認することを選択することができる。かくして、顧客は、オンラインシステムがマッチングするディール記録を識別しなかった場合でさえ、ディール記録をマッチングしたものとしてフラグすることができる。
【０１１８】
該発明を通して、顧客は又、予め定義されたセットから又は自発的に各ディールについて決済命令を付加する能力を有する。付加的な決済命令は、プロバイダのための確認メッセージを生成する。トレードがファンドについてのものであった場合、そのファンドについての証券保管機関に通知が行なわれる。この通知は、例えばＳＷＩＦＴネットワーク上で、又はファイルダウンロードを通して送られたＳＷＩＦＴ  ＭＴ３０４メッセージを用いて達成される。
【０１１９】
マッチングサブシステムの概要
マッチングサブシステム内のマッチングエンジンは、実行されたＦＸトレードについての２人の当事者の間で経済的及び非経済的詳細がマッチするメッセージ（確認）についてチェックする。標準的には、任意の時点でマッチングエンジン内に存在することになるメッセージには、Ａ側及びＢ側メッセージという複数のタイプが存在する。Ａ側メッセージは、当事者Ａから発信されたメッセージである。Ｂ側メッセージは、当事者Ｂから発信されたメッセージを意味する。標準的には、当事者Ａは、顧客又はクライアントであり、当事者Ｂはプロバイダ銀行である。しかしながら、マッチングサブシステムは同様に、プロバイダが互いの間での確認をマッチできるようにもする。マッチングエンジンは同様に、プライムブローカといったような中間当事者が発信するＣ側メッセージをも内含しうる。基本的に、マッチングエンジンは、全ての当事者のためのメッセージについての「ワークホース（work-horse）」である。それは、確認マッチングのための全ての入及び出メッセージの保管所である。
【０１２０】
データ構造
好ましい実施形態においては、メッセージは、リレーショナルデータベース内にその当初のフォーマットでマッチングエンジンの外部に記憶される。リレーショナルデータベースは、メッセージの状態及び状況を記憶するための中心的場所である。Ａ側メッセージは、ＸＭＬ（ｈｔｔｐを経由して）、ＳＷＩＦＴ（ＦＩＸを含む）、又はユーザーインターフェースを介したコンマ又はタブで分離されたファイルのアップロード又はペーストを介して、リレーショナルデータベースにアップロードできる。Ｂ側メッセージは通常、ＳＷＩＦＴネットワークインタフェース上でプロバイダから送られたＳＷＩＦＴメッセージを介してリレーショナルデータベースに入る。
【０１２１】
好ましい実施形態では、データベース内に記憶される前に、全てのメッセージが、ＭＴ３００フォーマットに転換される。標準的には、全ＭＴ３００フィールドのサブセットのみがマッチングエンジンによって必要とされる。下表１は、本発明の一実施形態の中で、いくつかのＭＴ３００フィールドをいかに使用できるかを示している。
【０１２２】
【表１】
2005530281.tif 000003
【０１２３】
マッチングアプリケーションワークフロー
好ましい実施形態においては、システムはリレーショナルデータベースからのメッセージを読取り、ワークフロープロセッサ（図１に示されているワークフロー処理エンジン１４２）による使用のため各メッセージにメッセージ状態（message state）を割当てる。メッセージ状態には、例えば以下の状態が含まれる可能性がある：アンマッチング、据え置き、マッチング済み、外部的にマッチング済み、仮想マッチング済み、片側マッチング済み、中断、及び取消し。
【０１２４】
アンマッチング：「アンマッチング」メッセージというのは、マッチングエンジンが適切なマッチを発見できない場合の新しいメッセージである。リレーショナルデータベースは、エンジンがマッチ状況を変えるまで更新されない。かくしてマッチングエンジンは、データベース内の全てのアンマッチングメッセージのために受諾可能なマッチを連続的に探し求めることになる。
【０１２５】
据え置き：該発明の実施形態においては、システムは、ユーザーがマッチングしないメッセージを合わせて手作業でリンクさせ、マッチングしない状況を結果としてもたらす正しくない詳細を送ったのは、どの当事者であると自ら考えるかを指示することができるようにする。誤ったと考えられる当事者は、マッチを完成するためにその詳細を矯正するか又は要請されたマッチを拒絶することができる。
【０１２６】
マッチング済み：「マッチング済みメッセージ」というのは、マッチングエンジンによってか又はエンドユーザーによって「マッチング済み」とマークされたメッセージのことである。アプリケーション及び特定のインプリメンテーションの設定に応じて、２つのメッセージの詳細の全てがマッチングしない場合でさえマッチが発生する可能性はある。マッチング済みメッセージは、決済を目的として直ちに使用することもできるし、又将来の参考としてアーカイブ内に入れることもできる。
【０１２７】
外部的にマッチング済み：個々のメッセージは、公式のマッチング基準に合わない場合でさえ、外部的にマッチングされたものとしてマークされ得る。標準的には、ユーザーは、電話、Ｅメール及び／又はファックスといったような手作業方法を用いて決済をオフラインで取扱うことを望む場合、外部的にマッチングされたものとしてメッセージをマークすることになる。
【０１２８】
仮想マッチング済み：ディールメッセージを送る代りに、一方の当事者は、電話といったようないくつかのその他の手段を通してもう一方の当事者が送ったディールメッセージに肯定応答を行なう。好ましい実施形態においては、ユーザーはＢ側メッセージの確認応答を自動化することができる。
【０１２９】
片側マッチング済み：ユーザーが片側マッチングオプションを選択した場合、ユーザーはメッセージをそれ自体に対してマッチングする。これは、Ａ側又はＢ側メッセージのいずれかに対して行なうことができる。
【０１３０】
中断：２つのメッセージ間のマッチが、当事者のいずれかからの該ディールの補正又は取消しに起因して中断された場合、マッチングされたメッセージは、該取引に関する全てのメッセージが更新されてしまうまで中断されたマッチとして一緒に保持されることになる。
【０１３１】
取消し：ディールがリレーショナルデータベース内で取消しされた状態にあるとみなされることを意味している。取消しされたディールに関連するメッセージはもはや、手作業であれ自動的であれマッチングに利用できない。
【０１３２】
標準決済命令（ＳＳＩ）
決済命令は、どの銀行勘定を通して金銭の支払いや引出しを行うべきかの詳細を提供することにより、トレードの経済的詳細を補足する。契約相手は、取引が決済できるようになる前に決済命令に同意しなければならない。
【０１３３】
買手側顧客は一般に、各々の通貨について多数の決済命令セットを有することから、本発明は、決済に先立つ任意の時点で個々のトレードに追加できる多数の予め定義された決済命令をユーザーが維持できるようにする。本発明に従って動作するシステムは、これらの命令をプロバイダに伝達することになる。顧客は同様にプロバイダに対し臨時の命令を送る能力をも有する。
【０１３４】
経済的詳細とは異なり、決済命令は、取引期間中に変化し得る。例えば、１年の先物取引の実行と決済の間の時間に、ファンドマネージャは、新しいファンド証券保管機関の使用を決定することができる。決済命令は、１つの銀行からもう１つの銀行への金銭の直接的動きに関係する。従って、本発明は、金銭がどこで送受されることになるかを契約相手に通知する新しい決済命令を顧客が提供できるようにする。
【０１３５】
図３〜７は、確認マッチング及び決済命令機能を実現するように、本発明に従って動作するシステムによって実施されるステップを例示する流れ図を含んでいる。ステップ３０５から始めて、システムは通常データ通信網上でオンライン接続を通して入メッセージを受信する。ステップ３１０で、システムは、メッセージをチェックし、システム内の既存のメッセージに対する補正としてマークされているか否かを決定する。システムが、ステップ３２０及び３２５に示されているように、参考指示された当初のメッセージがまだ受信されていなかったと決定した場合、該入メッセージは「シーケンス外」としてマークされ、メッセージはそれ以上処理されないことになる。
【０１３６】
一方、システムが（ステップ３３０で）、参照指示された当初のメッセージがすでにマッチングされていると決定した場合には、入メッセージの状況は「アンマッチング」にセットされ、「アンマッチング」メッセージが、以前にマッチングされたことを表わすべく、フラグがセットされる。図３のステップ３３５及び３４０を参照のこと。この時点で（ステップ３４５）、基準メッセージがアーカイブされ（入メッセージは基準メッセージに対する補正であるため）、データベース内の活動状態のメッセージセットから除去される。
【０１３７】
ここでステップ３１０に戻ると、入メッセージが補正としてマークされていない場合、システムは次に、ステップ３１５において、入メッセージが既存のメッセージの取消しとしてマークされたか否かを決定する。答えが「はい」である場合には、システムは、ステップ３２０で、参照指示されたメッセージが受信されたか否かを決定する。参照指示された当初のメッセージがなおも受信されなかった場合、メッセージは「シーケンス外」としてマークされ、それ以上処理されない、ステップ３２５を参照のこと。一方、参照指示された当初のメッセージがすでにマッチングされている場合（ステップ３３０）には、入メッセージの状況は「アンマッチング」にセットされ、「アンマッチング」メッセージが、以前にマッチングされたことを表わすべく、フラグがセットされる。図３のステップ３３５及び３４０を参照のこと。ここでも又ステップ３４５で、入メッセージがアーカイブされ、データベース内の活動状態のメッセージセットから除去される。
【０１３８】
ステップ３５０で、システムは、メッセージが決済命令を含むか否かを決定する。メッセージが決済命令を含まない場合には、システムは、この契約相手、通貨ペア、勘定及び支払期間（tenor）のためのディールがネット決済のために（for net settlement）命令されるべきであるような形でユーザーがシステムを構成したか否かをチェックする。そうである場合には、メッセージは、ネット決済のための支払い及び受領命令で充実させられる（enriched）。ステップ３６０を参照のこと。ディールがネッティングされた状態で進んでいない場合、システムは、ステップ３５５で、受領通貨及び勘定についてのデフォールトの標準決済命令（ＳＳＩ）セットをユーザーが定義したか否かをチェックする。そうである場合、メッセージは、受領代理人、仲介人及び受領通貨についてのその他の情報で充実させられる（ステップ３６０）。
【０１３９】
契約相手が新しいメッセージの到着時点で直ちに通知を受けることを望む場合、契約相手に対してＭＴ３００通知が送られる。ステップ３６５。好ましい実施形態においては、メッセージタイプは同様にこの時点でマッチングされ（新規、補正、取消し）、メッセージ内に決済情報を内含させることができる。メッセージ送信者の第３者が、新規メッセージが到着した時点でつねに直ちに通知を受けることを望む場合、又はこれが取消しである場合、ＭＴ３０４通知が送られる（ステップ３７０を参照のこと）。受信されたメッセージのメッセージタイプ（新規、補正、取消し）はマッチングさせられる。新規及び補正メッセージについては、出メッセージは、可能な場合、以下の命令で充実させられる：
・支払い通貨についての契約相手の受領代理人及び仲介人、
・支払い通貨についての契約相手の引渡し代理人、
・受領通貨についての契約相手の引渡し代理人。
【０１４０】
この時点で、流れ図コネクタＦＣ４を経由して図４内に示された流れ図のステップ４０５で、処理が続行する。ステップ４０５では、システムは、入メッセージが、シーケンス外で以前に受信したメッセージについての当初のメッセージであるか否かを決定する。回答が「はい」である場合、参照指示メッセージからシーケンス外フラグは除去される。ステップ４１０を参照のこと、そしてステップ４１５では、メッセージがあたかも新規メッセージであるかのように処理され得るような形で、処理が、図３の「スタート」に戻る。
【０１４１】
次に、ステップ４２０では、マッチングエンジンは、契約相手、勘定及び経済的詳細が一致するか否かを決定するべく、アンマッチングメッセージの対をチェックする。好ましい実施形態においては、システムはマッチングすることが許されていないメッセージ対のリストを維持しているという点に留意されたい。ステップ４２５でマッチが発見された場合、ＭＴ３００通知が契約相手及び通知を受けることを望む第三者に対して送られ（ステップ４３０）、マッチング済み対及びアンマッチング対が表示される、ステップ４３５。マッチが発見されない場合、通知ステップ４３０は省略され、システムは直接ステップ４３５まで進む。
【０１４２】
流れ図コネクタＦＣ５を経由して、処理は、図５のステップ５０５で継続し、ここでシステムは、ユーザーから、決済命令選定（settlement instruction selection）（ステップ５１０）を受信する。実際には、顧客は、マッチング済みか又はアンマッチングのいずれかのディールを選択し、次に決済命令を追加／変更すべきか否かを選択する。顧客が臨時の命令を提供する場合（ステップ５１５）、スーパーバイザ承認が得られ（ステップ５２０）、補正メッセージが作成され（ステップ５２５）、ステップ５３０により例示されているように、処理はプロセスの最初に戻る（図３の「スタート」ポイント）。ステップ５３５中に、標準決済命令が選択されることをシステムが決定した場合、トレードと決済命令選定の間のリンクが作成される（ステップ５４５）。このようにして、決済命令がその後編集された場合、トレードを自動的に更新することが可能である。ステップ５３５でＳＳＩが選択されない場合には、ステップ５４０でエラーメッセージが表示される。
【０１４３】
流れ図コネクタＦＣ６を経由して図６のステップ６０５で処理が継続し、ここでシステムは、ユーザーがＳＳＩ編集を選択したことを示す命令が受信されたか否かを決定する。受信された場合、決済命令編集は、ステップ６１０で顧客から受信される。次にステップ６１５で、スーパーバイザ承認が得られる。いずれかの既存のディールがＳＳＩにリンクされている場合、システムは既存のディールを表示し、さらなる命令のためのユーザーを促す（ステップ６２０及び６２５）。標準的にはユーザーは３つのオプションを有している。すなわち
・ディール記録を更新し、契約相手（そして該勘定について設定されている場合には証券保管機関）に対して補正メッセージを送る。
・ディールを更新するもののいかなる補正メッセージも送らない。この場合、顧客はシステムの外側で契約相手及び証券保管機関に通知することになることが予想される。
・ディールを更新しない。これは、ＳＳＩ内の変更が新しいディールのみに影響するような状況のために意図されているが、既存のディールは以前に合意された通りに決済することになる。
【０１４４】
その他のユーザーアクション
処理は、流れ図コネクタＦＣ７を経由して、図７に示されているユーザーアクションのうちのいずれか１つまで続行する。図７に示されているようにユーザーがこの時点で行なうことのできるその他のアクションがいくつか存在する。ユーザーはステップ７０５に示されているようにマッチを受諾できる。しかしながらユーザーは同様に、マッチング済みディールを選択し該マッチングを手作業で「中断」することもできる。図７の７１５を参照のこと。マッチング済みメッセージは、アンマッチング状態まで逆行し、従って、マッチングエンジンによって再度マッチングされ得る。しかしながら、メッセージ対は、マッチングエンジンがその後これらのメッセージを互いにマッチングすることがないような形で、マッチングエンジンの例外リストに付加される。
【０１４５】
マッチ強制。ステップ７２５では、ユーザーは、契約相手及び勘定について一致するものの１つ以上の経済的詳細及び／又は決済詳細については一致しない２つのアンマッチングメッセージを手作業で選択することができる。このとき、ユーザーは、システムに対し、メッセージを互いに「マッチングさせる」べきであることを手作業で命令することができる。このときメッセージ対は、あたかもマッチングエンジンがそれらを自動的に処理したかのように処理される。
【０１４６】
外部的確認。ステップ７３０では、ユーザーはアンマッチングメッセージがシステムの外側で確認されたことを指示することができる。メッセージは、マッチング済みとしてフラグ付けされ、従ってマッチングエンジンはその後該メッセージをマッチングさせようと試みないことになる。その後、単一メッセージは、あたかもマッチングエンジンがそれをもう１つのメッセージとマッチングさせたかのように処理される。
【０１４７】
高速マッチング。ステップ７３５では、ユーザーはアンマッチングメッセージを選択し、あたかも契約相手が確認メッセージを送付したかのように、システムにミラーメッセージを作成させることができる。システムは次に、ミラーメッセージと該メッセージを「マッチ強制」し、それを上述したように処理する。
【０１４８】
メッセージ取消し。ステップ７４５では、ユーザーはユーザーインターフェースを用いてメッセージを取消すことができる。これは、システムに取消しメッセージを送ることと等価である。
【０１４９】
ＭＴ３００強制。顧客メッセージのためにＭＴ３００がまだ未送付の状況においては、顧客は、ステップ７５５において、ＭＴ３００メッセージを直ちに送るようにシステムに命令することができる。
【０１５０】
ＭＴ３０４強制。顧客メッセージのためにＭＴ３０４メッセージがまだ未送付の状況においては、顧客はステップ７６０においてメッセージを直ちに送るようにシステムに命令することができる。
【０１５１】
メッセージ据え置き。ステップ７７０で、システムが「メッセージ据え置き」信号を受信した場合、メッセージはその後の補正又は取消しのためにフラグ付けされる。これは単純に情報フラグであり、マッチングエンジン内のメッセージの挙動に対しいかなる影響も有するものではない。
【０１５２】
これらのユーザーアクションのいずれかが完了した時点で、次にシステムはデータベースを更新し、このとき処理は、図４のステップ４２０であるマッチングステップに戻る。
【０１５３】
ネッティング
ネッティングは、契約相手が異なる取引から生じる多数の支払いを単一の等価の支払いに組合せることを可能にする。これは、決済プロセスを単純化し、コストを削減する。ネッティングは通常、決済のすぐ前、標準的には決済日の一日前に実施される。
【０１５４】
ネッティングのメカニズムは、標準的には、２つの契約相手の間でのネッティング契約によって定義づけされる。標準的なプロセスは、２人の契約相手が同一日の同じ銀行勘定についてのキャッシュフローを再検討し、ネット支払いのみを交換するよう合意する、というものである。予定された支払いを生成した基礎を成すディールが異なる日付で実行されたものであってよいという点に留意されたい。支払い額についてひとたび合意をみた時点で、あらゆる新規トレードは別々に決済されなくてはならず、そうでなければ初期ネット（initial net）を取り消さなくてはならない。このようなトレードが複数存在する場合、これらを同様に単一の支払いへと合わせてネッティングされ得るが、当初のネッティングされた支払いは不変のまま残る。
【０１５５】
既存のシステムにおいては、ネッティング契約は通常電話か又はファックスによって手配される。しかしながら、本発明を使用することにより、顧客は勘定決済日及び勘定セットを特定し、選択された通貨又は通貨ペアに基づいてその勘定決済日について計算されたネッティングされた支払いセットを検分する（view）ことができる。ひとたび顧客が計算された決済勘定に満足した時点で、本発明に従って動作するシステムが、承認のため契約相手の銀行に対しネッティングされた支払いを提出する。
【０１５６】
以上で述べた通り、本発明では双方向及び多方向ネッティングという少なくとも２つのタイプのネッティングが利用可能である。双方向ネッティングでは、通貨は、２人の当事者間で同じ通貨でネッティングされる。多方向ネッティングでは、全ての通貨ペアは、単一の通貨にネッティングされる。例えば、下表３に示したトレードが実行されたと仮定する。
【０１５７】
【表２】
2005530281.tif 000004
【０１５８】
ＥＲＵ通貨に対する双方向ネッティングは以下の結果を生み出すことになる；
【０１５９】
【表３】
2005530281.tif 000005
【０１６０】
多方向ネッティングは以下の結果を生み出すことになる：
【０１６１】
【表４】
2005530281.tif 000006
【０１６２】
ネッティングされた支払いのセットがひとたび計算された場合、ユーザーには、承認のためプロバイダに対して結果を送る機会が与えられることになる。承認時点で、プロバイダは標準的に、提案されたネッティングされた決済支払いの受諾を確認するメッセージをユーザーに対して送り戻すことになる。任意の時点で、プロバイダが要請を受諾するかぎり、顧客は、ネッティングされた支払い契約を中断することができる。
【０１６３】
図８は、通貨ペアネッティングを実現するべく本発明の一実施形態において実施される可能性のあるステップを例示している。通貨ペアネッティングにおいては、目的は、同じ通貨ペアでの全てのディールを、トレーディング対象の各銀行及び勘定についての単一の支払い交換（single exchange of payments）へと組合わせることにある。通貨ペアネッティングは、自らが受領する予定の各通貨についての精算命令を顧客が識別できるようにする。
【０１６４】
第１に、ステップ８０５に示されているように、顧客は、ネット決済を計算すべき勘定決済日を提供し、システムはこれを受理する。次にステップ８１０において、顧客は、ネット決済を計算すべき銀行及び勘定の１つ以上の組合せを選択し、システムはそれを受信する。かくして、顧客は、ネッティングプロセスを管理する上で融通性を有する。一方の極端なケースでは、顧客は全ての銀行及び勘定についてのネット決済を単一ステップで処理することができる。もう一方の極端では、顧客は、単一の銀行及び口座組合せだけについてネット決済を処理することができる。銀行及び勘定についての詳細がひとたび同意されたならば、顧客は連続するステップで付加的な組合せを処理することができる。顧客は、単一の銀行とトレーディングした全ての勘定を処理し、その後次の銀行まで移動することができ、そうでなければ、顧客は支払いを口座毎に処理することを選定することができる。
【０１６５】
本発明は、選択された勘定決済日、銀行及び勘定基準をマッチングさせるメッセージを識別する。ステップ８１５を参照のこと。トレード対象の各々の通貨ペアについて、システムは、各通貨についての支払及び受領を合わせてネッテイングし、２つの通貨の各々においてネット支払い／受領金額を生成する。各々の通貨ペアについて、システムは、ステップ８２５に示されているように、各通貨についてネッティングされた合計支払い／受領を表示するように構成され得る。システムは同様に、ネット金額（net amount）に寄与するディールのリストを提供することもできる。顧客は、ネットからディールを除外する（すなわちネット合計内に含めるのではなく、総額でそれらを決済させる）ことができる。この場合、システムは調整された合計を提供し、ネットから除外されたディール及びネット内に含まれるものの両方を列挙する。
【０１６６】
ネット合計が正しいという命令を顧客に出すための一助として、顧客は、銀行、勘定又はその両方を横断してシステムがさらに通貨ペアをネッティングすることを要請することができる。この付加的な機能は、例えば、一定の与えられた勘定についての全ての銀行を横断したネットキャッシュフローがゼロであることを顧客が知った場合に、きわめて有用であり得る。換言すると、個々の銀行に対する支払い又は受領（その各々が多数の取引のネットである）が存在しうる一方で、全体としてネット合計はゼロである。銀行及び／又は勘定を横断したネット通貨ペアに対して本発明を使用することにより、契約相手は、金額が正しいことの再保証を受けることができる。
【０１６７】
顧客が資金を受理する予定の各々のネッティングされた通貨ペア内の各々の通貨について、顧客は、その通貨及び勘定のための予め定義された決済命令セットから選択を行なうことができる。該選択は、ステップ８３０においてシステムにより受信される。代替的には、顧客は、ファックス又は電話又はもう１つのオンライン取引システムなどによる代替的方法を通して銀行に対し命令を提供するために決済命令を空白に残すことができる。
【０１６８】
顧客が資金を受領する予定の各々の除外されたディール内の各通貨について、顧客は、その通貨及び勘定のための予め定義された決済命令から選択を行なうことができる。代替的には、顧客は、決済命令を空白に残すこともできる。この場合、顧客は、（１）ネッティングプロセスに続いて総額決済されたディールに決済命令を添付するために本発明の非ネッティング機能を使用することによってか、又は（２）代替的手作業方法を介して外部的に、銀行に対し決済命令を提供することができる。
【０１６９】
顧客が金額をチェックし任意の望ましい決済命令を付加した後、ステップ８３５で銀行に対して要請が提出される。標準的には、必ずそうであるわけではないが、要請は以下のように銀行に対して提出される。すなわち、ネッティングされるべきディールを含む各々の銀行及び勘定組合せについて、別々のネッティング要請が送られる。各々の要請は、各々の通貨ペアについてネッティングされた金額及びネッティングされた金額に寄与する基底となるディールを含む。ネットから除外され顧客により添付された決済命令を有していた各々のディールは、総額決済されたディールに関する決済命令を変更するために本発明の手順を用いて処理される。換言すると、変更は、ディール補正として処理される（新規メッセージ参照）。ネットから除外され決済命令が添付されなかったディールについては、いかなるアクションも講じられない。
【０１７０】
各銀行が提出された情報を再検討している一方で、顧客は、いずれかの残った勘定／銀行についてネッティングプロセスを続行することができる。これは、該システムが、全てのネッティングを１回のプロセスで実施するか又はそれを多数のプロセスに分割する可能性を顧客に与えているからである。通常、各々のネッティング要請は、受領銀行によって別々に再検討されることになる。銀行は、ネット合計を見て、さらに掘り下げて基底となるディールを再検討することができる。
【０１７１】
流れ図コネクタＦＣ９を経由して図９内のステップ９０５に続行すると、各々のネッティング要請は、銀行によってその全体が受諾されるか又は拒絶されなくてはならない。銀行がネッティング要請を受諾したことをステップ９１０でシステムが決定した場合、システムは、基底にあるディールが今やネッティングにより決済されようとしていることを示すべく、更新される（ステップ９２０）。好ましくは、各々のネッティングされた通貨ペアは、合意された決済金額を示すべく「完成されたネット（completed nets）」表の中でユーザーに対し表示される。任意には、システムは、合意された決済金額のファンドの証券保管機関を通知するように構成され得る（ステップ９２５）。かくして、本発明は、業界標準ＳＷＩＦＴメッセージ送信を用いて証券保管機関に対し通知メッセージを送るように構成され得る。個々のＦＸディールについて、証券保管機関に対しＭＴ３０４メッセージが送信されるのに対して、支払い／受領のためには、２つの付加的なメッセージが使用される。すなわち、銀行に対して１つの支払いを行なうよう証券保管機関に通知するようにＭＴ２０２メッセージが送られる。銀行から予想すべき受領について証券保管機関に通知するために、ＭＴ２１０メッセージが送られる。
【０１７２】
ステップ９１０において、銀行がネッティング要請を拒絶したことが決定された場合、システムは、拒絶されたものとしてネッティング要請を顧客に戻し、エラーメッセージを表示する。ステップ９１５を参照のこと。２人の当事者は電話又は代替的方法を用いて問題を解決することになると予想される。顧客はその後、銀行がそれに合意することを条件としてネッティング要請を再度開きそれを調整することができる。標準的には、３つの変更が考えられる。すなわち、顧客は、総額決済されうるように、ネットの中に以前に含まれていたディールを除去するか、又は、総額決済のために以前にマークされたディールをネットの中に付加し戻すか、又は、ネッティングされた受領勘定について決済命令を変更することができる。これらの変更がひとたび行なわれた時点で、顧客は、ネッティング要請を銀行に再提出することができる。
【０１７３】
通貨ネッティング
通貨ネッティングにおいては、最終目的は、同じ通貨での全ての支払いを、トレード対象の各々の銀行及び勘定について単一のネット支払いの形に組合わせ、顧客が自ら受領する予定の各々の通貨について銀行に対するその決済命令を識別できるようにすることにある。通貨ネッティングを実現するためのプロセスは、各々のＦＸディールが、１つは顧客から銀行へもう１つは銀行から顧客への２つの独立した支払いとして、処理されるという点を除いて、通貨ペアネッティングとほぼ同一である。特定の銀行及び勘定の組合せの内部で、これらの支払いは、たとえ当初のディールが異なる通貨ペアのためのものであったとしても、次に合わせてネッティングされる。例えば、顧客が３つのＥＵＲ−ＵＳＤディールと３つのＵＳＤ−ＪＰＹディールを有していた場合には、通貨ペアネッティングで、システムは単一のＥＵＲ−ＵＳＤ決済支払い及び単一のＵＳＤ−ＪＰＹ決済を生成したであろう。しかしながら、システムが通貨ネッティングを使用するように命令されている場合、システムは単一のＵＳＤ決済（６つのディールを横断して）、単一のＥＵＲ決済及び単一のＪＰＹ決済を生成することになる。
【０１７４】
多方向通貨ネッティング
多方向通貨ネッティングの最終目的は、以下のように述べることができる。すなわち、一定の与えられた通貨及び勘定の組合せについて、顧客がそこからの支払われることを予定している銀行が直接、顧客が支払うこと予定している銀行に対して支払いを行なうようにさせること、である。顧客は、自らのトレーディング政策上ゼロという差引残高を得ることが指示されている通貨についてこの決済技術を使用すること（そして残りの通貨については当初のつまり双方向の通貨ネッティングを使用すること）ができる。例えば、顧客が事業の支出及び収益をカバーするためにＮＯＫを売買する必要があるものの、ＮＯＫ残高勘定を全く持っていない場合がある。従って、該顧客のためのネットＮＯＫキャッシュフローはつねにゼロでなくてはならない。
【０１７５】
まず第１に、顧客は、ネット決済を計算すべきである勘定決済日を選択する。顧客は同様に、ネット決済を計算すべきである１つ以上の勘定をも選択する。以前のネッティング技術とは異なり、多方向ネッティングには多数の銀行が同時に関与するという点に留意されたい。従って、一定の与えられた勘定について、銀行承認は同時に処理されなくてはならない。
【０１７６】
好ましい実施形態においては、システムは、例えば多方向通貨ネッティングを用いてどの通貨が決済されるべきかそしてどの通貨が双方向ネッティングを用いて決済されるべきかをシステムに指示するユーザープロファイルなどを通して、管理上の設定を維持するように構成される。これらの通貨が多方向にネッティングされるためには、システムは、全ての銀行を横断したネット合計、関与する銀行の数及び関与するディール数を提供する。これらの通貨が双方向にネッティングされるため、システムは、各銀行について支払われるべき金額及び各々のネット支払いの基底となるディールの数を提供する。
【０１７７】
その他のネッティング技術の場合と同様に、顧客は、ネッティングプロセスからディールを除外することができる。又、その他のネッティング技術の場合と同様に、システムはディールが除外されるにつれて、ネット合計を調整し、除外されたディールを列挙する。顧客は、同様に、双方向及び多方向ネッティングの間で個々の通貨を切換えることもできる。双方向ネッティングから多方向ネッティングへの通貨の切換えの結果として、銀行により列挙されたネット金額は上述の通り全ての銀行を横断したネット金額により置換されることになる。同様にして、多方向ネッティングから双方向ネッティングへの通貨の切換えの結果、全ての銀行を横断したネット金額は各銀行についてのネット金額により置換されることになる。
【０１７８】
プライムブローカ業務機能
本発明のプライムブローカ業務機能について、ここでさらに詳細に説明する。以下の記述及び例においては、顧客は、プライムブローカの業務を使用して流動性プロバイダとの金融取引に携わることを望む買入側の参入者である。標準的には銀行又はその他の金融機関であるプライムブローカは、顧客の信用リスクを引受ける仲介人である。実行銀行は、ディールに対する市場リスクを担う銀行である。資金調達銀行は、顧客によりトレーディングされるファンドのうちの１つについての物理的勘定を保持する銀行である。
【０１７９】
プライムブローカ業務機能に付随する段階としては、実行、ギブアップ及び逆ギブアップの３つがある。
【０１８０】
実行段階
実行段階においては、顧客及び実行銀行は、プライムブローカがトレードをプライムブローカ処理することになるということを了解した上でＦＸ取引を完成させる。実行銀行は、プライムブローカを契約相手として該トレードを条件付きで計上する。顧客は、プライムブローカを契約相手として、条件付きで該トレードを計上する。プライムブローカの請求書作成モデルに応じて、顧客は、顧客と実行銀行の間で合意されたものとは少し異なるレートでディールを計上することができる。顧客及び実行銀行は両方共詳細をプライムブローカに送付する。
【０１８１】
図１０、１１及び１２は、本発明のこの態様を実行するために実施可能なステップを例示する流れ図を含んでいる。この例においては、当事者Ａは顧客、当事者Ｂは実行銀行そして当事者Ｃはプライムブローカである。図１０のステップ１００５で始めて、システムは当事者ＡからＲＦＱを受信する。ＲＦＱは、プライムブローカとしてＣを用いるためにマーキングされている。システムは取引を開始するため多数のディーリングプロトコルをサポートしており、トレード実行システムに応じてそれらのうちのいずれか１つを使用することができる。以下のリストは、使用可能なさまざまなプロトコルのいくつかの例を提供する：
【０１８２】
指値要請（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｑｕｏｔｅ）：このプロトコルを用いて、実行銀行は１つ以上の価格を顧客に戻し、顧客は、実行銀行の現行価格を受諾するか否かを選択する。
【０１８３】
アットベスト（Ａｔ  Ｂｅｓｔ）：このプロトコルの下で、実行銀行は、現行市場レベルで顧客の要請を実行し、実行レートについて顧客のポストトレード（the Customer post-trade）に知らせる。
【０１８４】
キルオアフィル（Ｋｉｌｌ  ｏｒ  Ｆｉｌｌ）：このプロトコルでは、顧客は実行銀行に最悪の受諾可能なレートを提供する。実行銀行は、直ちに、このレート（又はそれより優れたレート）でディールを完成するか又は、いかなる実行も可能でないことを顧客に知らせる。
【０１８５】
指値注文（Ｒｅｓｔｉｎｇ  Ｏｒｄｅｒ）：ここで、顧客は受諾可能な最低のレートを実行銀行に提供する。実行銀行が、このレート（又はそれより高いレート）でトレーディングしている場合直ちにディールを完了する。顧客は、実行前のいつでも注文を取消すことができる。
【０１８６】
アットフィックス（Ａｔ  Ｆｉｘ）：このプロトコルでは、顧客及び実行銀行は、実行のために使用するべく第３者の基準レートで合意する（例えば午後５時のＦｘａｌｌ  Ｉｎｃ．の表示指値）。
【０１８７】
これらのプロトコルのうちのいずれかならびにその他のプロトコルについては、契約相手間で合意できる。
【０１８８】
本発明では、顧客は、プライムブローカ業務ディール及び非プライムブローカ業務ディールを単一の実行へと組合わせることができる。とりわけ、ＲＦＱが実行銀行に送られる前に（信用限度（credit limit）、許容された通貨ペア（currency pairs allowed）、許容された最大先物日（maximumforward date allowed）などについて）顧客の要請を、顧客とプライムブローカの間の契約に対してチェックすることができる。通常、顧客の名前及びプライムブローカの名前の両方がディール要請時点で実行銀行に対して提示されることになる。しかしながら、顧客は自分のアイデンティティをかくすことを選定することもできる。
【０１８９】
プライムブローカは、全ての実行が値上げされることになるということ（すなわち、顧客が、顧客と実行銀行の間よりもわずかに悪いレートでプライムブローカと実行すること）について顧客と合意する可能性がある。これにより、プライムブローカのためのディールあたり手数料が提供される。本発明は、顧客の実行レートを自動的に計算することになる。１変形形態としては、プライムブローカは、個々のインボイスを清算せずに定期的インボイスを送ることを決定できる。この場合、本発明は、トレードされるディールを追跡し、その通貨ペア、量及び支払日に基づいて定期的勘定（periodic bill）を計算することができる。
【０１９０】
図１０に戻ると、当事者Ｂ（実行銀行）にＲＦＱを提出する前に、システムはステップ１０１０において、当事者Ａ（顧客）が当事者Ｃ（プライムブローカ）と要請された取引を開始するのに充分なクレジットを有するか否かを決定する。通常、これは、当事者Ｃによって提供されるクレジット規則セットをチェックすることが関与する。ステップ１０１０でＡのクレジットが大丈夫であることが決定された場合には、Ａのクレジットは、要請された取引のための勘定に調整される（ステップ１０２５参照）。一方、Ａに適用可能なクレジット規則が取引を開始することをＡに許可しない場合、システムは取引を進める許可をＣに求めるメッセージをＣに対して送る（ステップ１０１５）。Ｃが許可を与えた場合（ステップ１０２０）には、Ａのクレジットが調整され（ステップ１０２５）、ＲＦＱはステップ１０３０で当事者Ｂ（実行銀行）に送られる。しかし、Ｃが許可を拒否した場合、ＲＦＱは終結され（ステップ１０５５）、処理は終る。
【０１９１】
次に、ステップ１０３５では、システムはＢに代って指値ストリームをＡに送る。Ａがディールに対するオファーを提供することによって指値ストリームに応答した場合、システムはディールに対するそのオファーをＢに転送する（ステップ１０４０）。ステップ１０４５では、システムは、確認メッセージを送ることによりディールに対する受諾されたＡのオファーをＢが受諾したか否かを決定する。システムがＢから確認を受理していないか又はＢからの拒絶を受信した場合には、ステップ１０２５でＡの勘定に対して適用された信用レベル調整はリバースされ（ステップ１０５０）、ＲＦＱは終結され（ステップ１０５５）、処理は停止する。
【０１９２】
ギブアップ段階
ギブアップ段階においては、プライムブローカは、受信した詳細が一貫性あるものであることをチェックする。プライムブローカは、１つは顧客と及びもう１つは実行銀行との実行段階１で識別された２つのディールを計上する。プライムブローカは、実行銀行及び顧客に対して、ギブアップが受諾されたことを通知し、条件付き計上を最終決定する。
【０１９３】
ひき続き例を参照すると、システムが図１０のステップ１０４５でＢからの確認を受けた場合、処理は、流れ図コネクタＦＣ１１を経由してステップ１１０５に続行し、ここで新しい又は補正されたギブアップ詳細を当事者Ａから受信したか否かをシステムがチェックする。回答が「はい」である場合には、ステップ１１１０で、システムは、Ａのギブアップ詳細をＣまで転送し、ＡとＣの間のディールを条件付きで計上する。その後、システムは、当事者Ｂから新しい又は補正されたギブアップ詳細が受信されたか否かをチェックする（ステップ１１１５）。当事者Ａのギブアップ詳細がステップ１１０５において受信されなかった場合、システムは、直接、当事者Ｂのギブアップ詳細が受信されたか否かについてチェックする作業に進む（ステップ１１１５参照）。当事者Ｂのギブアップ詳細がステップ１１１５で受信された場合、当事者Ｂのギブアップ詳細は、当事者Ｃまで転送され、システムはＢとＣの間のディールを条件付きで計上する。とりわけ、当事者Ａと当事者Ｃの間のディールは、ＢとＣの間のディールについてのレートよりも高いレートであり得る。
【０１９４】
次に、ステップ１１２５では、システムは、Ａ及びＢの両方からギブアップ詳細が受信されたか否かを決定する。そうでなければ、システムは、両方の詳細セットが受信されるまで（ステップ１１０５、１１１０、１１１５、１１２０及び１１２５を含む）ループ内に進む。両方の詳細セットが受信されると、システムは、ギブアップ詳細についてのマッチ状況を全ての当事者に知らせる（ステップ１１３０）。マッチ状況は、バックグラウンドでマッチについてメッセージデータベース内のメッセージ対をつねに連続してチェックしているマッチングエンジンにより提供される。
【０１９５】
次に、システムは、ギブアップを受諾するためＣからメッセージが受信されたか否かを決定する（ステップ１１４０）。受信されていない場合には、システムは、Ｃがギブアップの拒絶を送ったか否かをチェックする（ステップ１１４５）。Ｃからの受諾も拒絶もなかった場合、システムは、ステップ１１０５に戻ることにより再び、Ａ又はＢがギブアップ詳細についての何らかの補正を送ったか否かチェックする。いかなる受諾も拒絶もなかった場合、そして補正も全くない場合、システムはステップ１１３０までループバックし、ここでシステムは再び当事者双方にマッチ状況を知らせる。換言すると、システムは、Ｃがギブアップを受諾又は拒絶するまでループし、こうしてＡ及びＢには任意の補正を提供する機会が与えられる。
【０１９６】
ステップ１１４０でＣが受諾を送ったことが決定された場合には、処理は、流れ図コネクタＦＣ１２Ａを経由して図１２のステップ１２１０に続行し、ここでシステムは、Ｃがギブアップを受諾したというメッセージを、Ａ及びＢに送る。その後、システムはＡとＣの間のディールならびにＢとＣの間のディールを、無条件ベースで（on a non-provisional basis）計上する（ステップ１２１５）。この時点で、ＲＦＱの処理は完了する。図１１のステップ１１４５で、Ｃが受諾の代りに拒絶を送ったことが決定された場合には、処理は、流れ図コネクタＦＣ１２Ｂを経由して図１２のステップ１２０５に続行する。ここで、システムは、Ａ及びＢに拒絶通知を送り、条件付き計上を終結し、図１０のステップ１０２５で実施された信用レベル調整をリバースし、処理を終結させる。
【０１９７】
顧客の裁量で、対応するメッセージがＣから受信されるまで、実行銀行からのメッセージはプライムブローカへの引渡しを「差し控えられる」可能性がある。こうして、顧客は、いつその実行詳細がプライムブローカに引き渡されるかを制御できるようになる。本発明を使用すると、顧客は、プライムブローカに対して実行銀行によって送られる顧客と実行銀行の間のディールに関するメッセージを検分することができる。同様にして、実行銀行は、顧客と実行銀行の間のディールに関し顧客によって送られたメッセージを検分することができる。
【０１９８】
上述のように、本発明は任意には、プライムブローカに対し一貫した経済詳細が送られた場合に、顧客と実行銀行に自動的に通知を行なうことができる。プライムブローカは、ディールが（信用限度、許容される通貨ペア、最大先物日などについての）プライムブローカと顧客の契約の範囲内にあることをチェックする。上述のように、本発明は、ＲＦＱ又は実行プロセスの一部としてこのステップを実施するように構成されていてもよい。
【０１９９】
逆ギブアップ段階
顧客は、複数の資金にわたる取引へとディールを分割するようプライムブローカに依頼することができる。これは逆ギブアップ段階と呼ばれる。これらの取引は、ネットされ、プライムブローカにギブアップされた額となる。各々の取引について顧客は、プライムブローカに対し、勘定決済日を調整するように依頼し、その結果、その取引について価格が変化することになる。プライムブローカは、顧客とのその当初のディールを取消す。各々の取引について、プライムブローカは、適切な資金調達銀行とのトレードを計上する。顧客は、これらの取引の決済において役割を果たさないものの、各取引の詳細を記録する。各々の逆ギブアップについて、資金調達銀行は詳細の通知を受ける。各々の逆ギブアップについて、資金調達銀行は取引詳細を計上し、これらの詳細を確認して顧客に戻す。各々の逆ギブアップについて、顧客は、資金調達銀行により確認された詳細が正しいことをチェックする。
【０２００】
プライムブローカにギブアップされた金額は、複数の異なる銀行口座を横断して分割される必要があるかもしれない。これらの勘定は、多数の第３者銀行で保持されてよい。各々の分割（split）について、顧客は、顧客とプライムブローカの間のディールの勘定決済日の変更を望むかもしれない。一般的な実践方法は、ＦＸ先物を必要とする顧客が実行銀行とのＦＸ直物ディールで実行し、該ディールをプライムブローカにギブアップし、次にプライムブローカとＦＸ先物ポイントを合意することである。
【０２０１】
Ｆｘａｌｌ  Ｉｎｃのオペレーションズセンターといったオンラインポストエグゼキューションシステムを用いてか又はその他の要領で、顧客はプライムブローカに、Ｃによりトレーディングされた勘定セットへのギブアップされた「ブロック」金額の内訳について知らせる。各分割について、顧客はファンド、金額、必要な勘定決済日を識別する。勘定決済日の変更を必要とするあらゆる分割について、オペレーションズセンターを用いてか又はその他の要領で、プライムブローカは顧客にその勘定決済日についてのＦＸ先物ポイントを指値する（先物ポイントは第２営業日から所望の先物日までディールが移行するにつれての価格の変化である）。顧客は各分割について先物ポイントに合意する。
【０２０２】
顧客及びプライムブローカは次に各々当初の「ブロック」ディールを取消す。各々の分割について、プライムブローカは、勘定、金額、勘定決済日及び新しい価格を反映する適切な資金調達銀行との別途ディールを計上する。顧客は、これらのディールの決済に全く役割を果たさないものの、各分割のノートを作成する。次に本発明を用いて又はその他の形で、各々の資金についてプライムブローカはディール詳細を識別する通知を、資金調達銀行に対して送る。本発明を用いて、このステップを自動化することが可能である。ファンドブレークアウトが顧客とプライムブローカの間で合意されると直ちに、本発明は資金調達銀行に対し通知を送ることになる。
【０２０３】
資金調達銀行は、プライムブローカにより指示された通りに取引を計上する。本発明を用いて、又はその他の形で、資金調達銀行は、顧客に対して計上詳細と共に確認メッセージを送る。顧客は、自らプライムブローカと合意した計上詳細を、資金調達銀行により送付されたものに照らしてチェックする。
【０２０４】
図１３はプライムブローカ業務機能を実行するべく、本発明に従って構成された取引システム内のメッセージフローを例示する高レベルブロック図を含む。図１３に示されているように、メッセージの送信、受信及びマッチのハブ又はコンジットとして本発明の決済用プロセッサ１３０５を用いて、顧客及び実行銀行はプライムブローカに金融取引のためのギブアップ詳細を提供する（図１３中の矢印１及び２を参照のこと）。プライムブローカは次に、実行銀行に対して受諾を送り（矢印３）、マッチングエンジン１３１０は全ての当事者に対してマッチ状況を提供する（矢印４、５及び６）。プライムブローカは同様に本発明を通して顧客に対し、プライムブローカがギブアップを受諾したことを通知する（矢印７）。
【０２０５】
受諾を受信した時点で、顧客はプライムブローカに、ファンドのブレークアウト、使用すべき勘定（矢印８）といった決済詳細を提供し、これをシステムはプライムブローカに代って自動的に勘定銀行に転送する（矢印９）。次に、勘定銀行は、決済詳細の受諾を確認するメッセージを送る（矢印１０）。最後に、プライムブローカは顧客に決済詳細及びトレードを確認する確認メッセージを提供する（矢印１１）。とりわけ本発明は、当事者（複数）が設定した選好性（preferences set by the parties）及び構成可能なプロトコルに従って、全てのメッセージを受信し転送する。
【０２０６】
メッセージの定義
メッセージハブとして動作している場合、本発明は、４つの全く異なるエンティティの間で７つのメッセージを通過させることができる。以下で各々のメッセージについて記述する。
【０２０７】
ギブアップメッセージ送り
ギブアップメッセージ送りは、プライムブローカに対して完了したディールについて通知し、完了したディールを確認するために使用される。３名の当事者のためにメッセージを通信すべく、多数のフォーマットがサポートされる。
【０２０８】
実行銀行ギブアップメッセージ
・ヘッダー
送信者：実行銀行
受信者：プライムブローカ
その他の当事者：顧客
メッセージのＩＤ−ハブ内のメッセージを追跡する。
トレードのＩＤ−トレードの期間を追跡するために用いられるＩＤ
・トレード情報
トレード日
通貨ペア
・レッグ情報
レッグ金額（LegAmount）
レッグ通貨（LegCurrency）
勘定決済日
・割当情報
割当通貨
割当金額
勘定
直物（スポット）
先物ポイント
包括（オールイン）
【０２０９】
顧客ギブアップメッセージ
・ヘッダー
送信者：顧客
受信者：プライムブローカ
その他の当事者：実行銀行
メッセージのＩＤ−ハブ内のメッセージを追跡する。
トレードのＩＤ−トレードの期間を追跡するために用いられるＩＤ
・トレード情報
トレード日
通貨ペア
・レッグ情報
レッグ勘定
レッグ通貨
勘定決済日
・割当情報
割当通貨
割当金額
・勘定
直物
先物ポイント
包括
【０２１０】
プライムブローカ業務ギブアップ確認メッセージ
・ヘッダー
送信者：プライムブローカ
受信者：実行銀行
その他の当事者：顧客
メッセージのＩＤ−ハブ内のメッセージを追跡する。
トレードのＩＤ−トレードの期間を追跡するために用いられるＩＤ
・コンテンツ
受諾又は拒絶
【０２１１】
決済メッセージ送り
決済メッセージ送りは、顧客又はプライムブローカが適切な勘定銀行に決済勘定詳細を提供するために用いられる。
【０２１２】
顧客決済詳細メッセージ
・ヘッダー
送信者：顧客
受信者：プライムブローカ
その他の当事者：勘定銀行
メッセージのＩＤ−ハブ内のメッセージを追跡する。
トレードのＩＤ−トレードの期間を追跡するために用いられるＩＤ
・決済詳細
トレード日
割当通貨
割当金額
勘定
・勘定決済日
直物
先物ポイント
包括
決済命令
【０２１３】
勘定銀行決済詳細通知メッセージ
・ヘッダー
送信者：プライムブローカ
受信者：勘定銀行
その他の当事者：顧客
メッセージのＩＤ−ハブ内のメッセージを追跡する。
トレードのＩＤ−トレードの期間を追跡するために用いられるＩＤ
・決済詳細
トレード日
割当通貨
割当金額
勘定
・勘定決済日
直物
先物ポイント
包括
決済命令
【０２１４】
勘定銀行決済詳細確認済みメッセージ
・ヘッダー
送信者：勘定銀行
受信者：プライムブローカ
その他の当事者：無し
メッセージのＩＤ−ハブ内のメッセージを追跡する。
トレードのＩＤ−トレードの期間を追跡するために用いられるＩＤ
・コンテンツ
確認済み
【０２１５】
プライムブローカ業務決済詳細確認済みメッセージ
・ヘッダー
送信者：プライムブローカ
受信者：顧客
その他の当事者：勘定銀行
メッセージのＩＤ−ハブ内のメッセージを追跡する。
トレードのＩＤ−トレードの期間を追跡するために用いられるＩＤ
・コンテンツ
確認済み
【０２１６】
流動性アウトソーシング
流動性アウトソーシングプロセスについてのさらに詳細な論述がここで提供される。
【０２１７】
好ましい実施形態では、流動性アウトソーシングプロセスは、顧客により実行された各々のディールについて少なくとも２つ（場合によってはそれ以上）のディールを生成し、関係銀行に信用リスクを残し、流動性プロバイダに市場リスクを残す。図１４に示されているように、ディール１は、関係銀行に対し顧客により提供されたＲＦＱである。ディール２は、関係銀行の代りにＦｘａｌｌが生成した２次ＲＦＱである。
【０２１８】
一部の実施形態においては、ディーリングプロトコルは、４段階プロセスで実現され得る。４段階は、以下の通りである：
顧客がプロバイダを選択し、ＲＦＱを提供する。
プロバイダが顧客に対し指値をストリーミングする。
顧客が価格を受諾する。
流動性プロバイダが実行を確認する。
【０２１９】
このプロトコルの１つの利点は、実行がつねにアトミックであることを保証してくれるという点にある。換言すると、両方のディールが実行されるか、又はいずれも実行されないかのいずれかである。このことはすなわち、関係銀行にディールのうちの１つが残され、それに望ましくない市場リスクが与えられる見込みは全くないということを意味する。ひとたび顧客が価格を受諾した時点で（ステップ３）流動性プロバイダが実行を受諾又は拒絶する唯一の権限を有する（ステップ４）ことを理由として、アトミックであることが保証される。そうでなければ、いずれのディールも計上されない。
【０２２０】
ステップ１：顧客はプロバイダを選択しＲＦＱを提出する。
図１５は、段階１をより詳細に示している。図１５に示されているように、ステップ１では、顧客は、特定の指値要請（ＲＦＱ）についての流動性プロバイダとしてその関係銀行を選択し、ＲＦＱ内で送る。図１５にオンライン取引処理ハブ１５０５として図１５に識別されているシステムは、顧客に対するクレジットをチェックし予備割当てする（ステップ２）。次に、ＨＵＢは、ＲＦＱを取扱う能力をもつ１つ以上の２次流動性プロバイダを識別し、２次ＲＦＱを生成し、Ｒ  ｂａｎｋの名前で１つ以上の潜在的２次流動性プロバイダに２次ＲＦＱを提供するように構成される（ステップ３及び４）。
【０２２１】
ステップ２：プロバイダが顧客に指値をストリーミングする。
図１６に示されているように、２次流動性プロバイダは、その価格をオンライン取引処理ハブ１５０５に好ましくは（ただし必ずしも必要なわけではないが）実時間でストリーミング（ステップ５）する。ハブは、最良の価格を選択し、任意には、関係銀行によって決定されるようにスプレッドを適用することができる（ステップ６）。ステップ７では、ハブ１５０５は次に最良の価格を顧客に転送する（一部のケースでは適切なスプレッドと共に）。顧客のパースペクティブから、価格ストリームは、関係銀行（ＲＢＡＮＫ）によって送られている。
【０２２２】
ステップ３：顧客が価格を選択する。
図１７は、第３のステップを例示している。ディールに対する顧客のオファーが次に関係銀行に送られる（ステップ８）。オンライン取引ハブ１５０５は、関係銀行の代りにウィンニング２次流動性プロバイダ（ＬＰＲＯＶ）に、２次ＲＦＱのためのディールに対するオファー（Offer to Deal）を送る（ステップ９）。一部の実施形態では、ウィンニング２次流動性プロバイダは、顧客のディールに対するオファーがオンライン取引ハブに到達した時点で最良の価格をもつプロバイダである。その他の実施形態では、関係銀行によって定義された規則が、ウィンニング流動性プロバイダを選択するために用いられることになる。
【０２２３】
ステップ４：流動性プロバイダが実行を確認する。
図１８に、ステップ４が例示されている。ディールは、オンライン取引ハブ１５０５（ステップ１０に例示されている）でのその実行を２次流動性プロバイダが確認した時点で、正式に完了する。この例では、オンライン取引ハブ１５０５はこの時点で２つのディールすなわち（１）顧客と関係銀行の間での実行ディール；及び（２）関係銀行と２次流動性プロバイダの間のディールを計上（記録）することになる（ステップ１１及び１２）。顧客は、関係銀行との自らの実行が成功したことの通知を受ける（ステップ１３）。関係銀行は両方のディールについて通知される（ステップ１４）。
【０２２４】
アウトソーシングロジック
好ましい実施形態においては、本発明は、ＲＦＱをアウトソーシングすべきか否か、そしてすべきであるのならばどの流動性プロバイダに対してかを自動的に決定するように構成される。或る種の規則が適用される場合、発明は非常に細分された決断プロセスを提供する。
【０２２５】
例えば、関係銀行は、次の作業を行なうことができる。すなわち
全ての電子市場メーキング（electronic market making）をアウトソーシングする
特定の通貨をアウトソーシングする
特定の時間帯をアウトソーシングする（例えば、顧客に夜間のカバレッジを提供するため）又は
所望の市場リスクポジションを達成する上で一助となったディールをキープする。
【０２２６】
関係銀行における個々のディーラーは、同様に、ディーラーが
大きな注文の作業で忙しい場合、
全てのプライシング要請に直接サービス提供するには市場があまりに不安定でありすぎると考える場合、
ＦＸクロスの半分をアウトソーシングしたい場合
自らのデスクから離れている場合、
その他の形でＲＦＱを受信できない状態
にある場合、
入顧客ＲＦＱのためのバックストップとして選択的に流動性アウトソーシングを使用することもできる。
【０２２７】
アウトソーシングされたＲＦＱのためにどの流動性プロバイダを考慮すべきかを選択するように本発明を構成するアビリティのため、第２の融通性レベルが得られる。かくして、本発明は、以下のものを含む（ただしこれらに制限されるわけではない）いくつかのパラメータに基づいて各ＲＦＱのための潜在的流動性プロバイダセットを決定するべく、関係銀行により設定された第２レベルの規則を適用するように構成可能である。すなわち
各々の流動性プロバイダとの事業目標百分率；
各プロバイダについて可用信用状況、
以前に合意されたサービスレベルに関するプロバイダのパフォーマンス；
通貨ペア及びディールのサイズ、又は
時間帯。
【０２２８】
第３レベルの融通性は、ＲＦＱ内に、選択された流動性プロバイダをいかに含めるかを選ぶように該発明を構成することによって、達成可能である。かくして、以下の便宜を提供するために第３の規則セットを適用することができる：
ＲＦＱ内に選択された全てのプロバイダを含めること；
ＲＦＱ内に最良のプロバイダのみを含めること；又は
ＲＦＱ内の最良のプロバイダのみを含め、第１のプロバイダが或る時限内に応答しなかった場合には２番目の最良プロバイダをＲＦＱさせること。
【０２２９】
流動性プロバイダのパフォーマンスを監視する
アウトソーシング規則セット及び仲裁規則セットは、当事者及び市場全般に付随するさまざまな要因に基づく可能性がある。例えば、これらの規則は、当初の商取引要請に付随する通貨指定、当初の商取引要請に付随する時間帯、顧客に付随する信用リスク、当初の商取引要請に付随する市場リスク、当初の商取引要請に付随する資本調達金額、プロバイダセットの中の１つ以上のプロバイダに付随する可用性状況、プロバイダセット内の１つ以上のプロバイダに付随する事業目標百分率、プロバイダセット内の１つ以上のプロバイダと関係銀行のための可用信用状況、プロバイダセットの中の１つ以上のプロバイダのためのサービス品質保証に対するパフォーマンスメトリック又はサービス品質保証の一致に基づいている可能性がある。アウトソーシング及び仲裁規則は同様に、上述の要因全てのうちの１つ以上のものの組合せに基づいていてもよい。
【０２３０】
本発明の有意な利点は、それが、関係銀行に、その顧客のための最良の価格を得るための、そして、その流動性プロバイダの各々によって引渡された業務及び価格の質及びパフォーマンスを監視するための手段を、提供するという点にある。
【０２３１】
本発明により関係銀行が利用できるようになる１つの手段は、例えば競争である。各々のＲＦＱを２つ以上の流動性プロバイダに同時にアウトソーシングすることによって、このときプロバイダはＲＦＱを勝ちとるため価格上で競争する。これには、関係銀行側の努力がほとんど必要でないが、これは、その価格安定性を犠牲にして最安値を引渡すことに流動性プロバイダが焦点を合わせるという結果を招く可能性がある。トレーディングプラットフォームによる統計的監視は、この点において、全てのプライシング構成要素に焦点をおく流動性プロバイダにその見返りを与える一助となり得る。例えばシステムは、各銀行により受諾されたディール要請の百分率を監視するように構成され得る。流動性プロバイダ間の価格提携の場合には、例えば歴史的に最高の引受レートをもつ銀行がＲＦＱに勝利するものとして選択され得る。
【０２３２】
本発明で提供され得るもう１つの手段は、一度に１人のプロバイダに対してのみ各ＲＦＱをアウトソーシングし、例えば次のものに基づいて各銀行により引渡された品質を評価するために統計的方法を使用するアビリティにある：
取上げられたＲＦＱ百分率；
価格安定性（価格更新頻度）；
顧客がディールを申し出たときの引受レート又は指値された呼値スプレッド。
【０２３３】
関係銀行は、定期的にこれらの統計を分析し、各々の流動性プロバイダとの将来の交渉において結果を使用することができる。本発明は同様に、将来においてより良い流動性プロバイダにより多くのＲＦＱを送ることによりこれらのプロバイダに自動的に見返りを与えるための機能を含むようにも構成可能である。例えば、選択された流動性プロバイダが１０秒以内に価格を戻さない場合、そのＲＦＱを自動的に取消し、バックアップ流動性プロバイダに対し新しいＲＦＱを自動的に送るように本発明を構成することができると思われる。又、関係銀行のオプションで、非応答流動性に対し付与される将来の事業の百分率を低減するように本発明を構成することもできる。
【０２３４】
１０％といったような低いＲＦＱ百分率は、最初のケースにおけるバックアッププロバイダにルーティングされ得る。このとき、関係銀行は、主要流動性プロバイダからの指値品質を監視するために、これらの価格を使用することができる。定期的な間隔で、バックアッププロバイダにルーティングされるＲＦＱ百分率を、２人のプロバイダの相対的パフォーマンスに基づいて自動的に変更することが可能である。
【０２３５】
図１９は、本発明の原理に従って、流動性アウトソーシングを実行するために１つのプロセッサ又はプロセッサセットが実施できるステップを例示する流れ図を含んでいる。図１９に示されているように、プロセスはステップ１９０５で、システムが当事者Ａ（顧客）から当初のＲＦＱを受信したときに始まる。ＲＦＱは当事者Ｂ（銀行又は当事者Ａと関係のあるその他の機関）に導かれる。好ましい実施形態においては、必然的にではないものの、システムは、当事者Ｂ（図１９では示さず）にＲＦＱを転送する前に、当事者Ａのクレジットをチェックする。ステップ１９１０で、システムは、当事者Ａから受信した当初のＲＦＱに基づいて２次ＲＦＱを生成する。当事者Ｂにより提供されたアウトソーシング規則セットを用いて、当事者Ｂに代って、２次ＲＦＱが１つ以上の流動性プロバイダに対し提出される（ステップ１９１５）。
【０２３６】
次に、ステップ１９２０において、システムは流動性プロバイダのうちの１つ以上の者から当初の指値ストリームを受信し、これらの指値を当事者Ｂに転送する。次にシステムは、選択された数の指値を、プロバイダから受信した当初の指値ストリームに基づいて２次指値ストリームに転換する（ステップ１９２５）。例えば、２次ストリームを生成するために当初の指値ストリームに対して１スプレッドを追加することができる。ステップ１９３０では、当事者Ｂに代って、２次ストリームが当事者Ａに伝送される。システムが２次指値ストリームに応えて当事者Ａからの受諾を受信したならば（ステップ１９３５）、ここでも又当事者Ｂにより提供された規則に基づいて１人のプロバイダが選択され、そのプロバイダに対して受諾が転送される（ステップ１９４０及び１９４５）。
【０２３７】
システムはこのとき当事者Ｂからの確認又は拒絶を受信するのを待つ。ステップ１９５０で確認が受信されたならば、システムは、当事者Ａと流動性プロバイダの間の第１のディール及び当事者Ｂと流動性プロバイダの間の第２のディールを計上する（ステップ１９５５及び１９６０）。この時点で、処理は終了する。
【０２３８】
本発明は、その最も好ましい実施形態であるとみなされているものにおいて、本書で開示され記述されてきた。本開示を読んだ時点で当業者には変形形態及び等価物が明らかになる可能性があり、かかる変形形態及び等価物は本発明及び添付クレームの範囲内に入るものとして意図されている、という点に留意すべきである。従って、例えば、当業者であれば、本発明が外国為替取引に制限されるものではなく、上述のようなその他のタイプの取引にも有利に適用されうるものであるということを理解するはずである。
【図面の簡単な説明】
【０２３９】
図面の簡単な説明
【図１】本発明に従って動作するように構成されたコンピュータシステムの高レベルブロック図である。
【図２】本発明の一実施形態に従って動作するように構成されたコンピュータシステム又はコンピュータプロセッサによって実施され得るステップを示す高レベル流れ図である。
【図３】本発明の一実施形態に従って動作するように構成されたコンピュータシステム又はプロセッサの中で実施され得るステップをより詳細に例示する流れ図を含む。
【図４】本発明の一実施形態に従って動作するように構成されたコンピュータシステム又はプロセッサの中で実施され得るステップをより詳細に例示する流れ図を含む。
【図５】本発明の一実施形態に従って動作するように構成されたコンピュータシステム又はプロセッサの中で実施され得るステップをより詳細に例示する流れ図を含む。
【図６】本発明の一実施形態に従って動作するように構成されたコンピュータシステム又はプロセッサの中で実施され得るステップをより詳細に例示する流れ図を含む。
【図７】本発明の一実施形態に従って動作するように構成されたコンピュータシステム又はプロセッサの中で実施され得るステップをより詳細に例示する流れ図を含む。
【図８】決済ネッティング機能を実行するために本発明の実施形態に従って動作するコンピュータシステム又はプロセッサにより実施され得るステップを例示する流れ図を含む。
【図９】決済ネッティング機能を実行するために本発明の実施形態に従って動作するコンピュータシステム又はプロセッサにより実施され得るステップを例示する流れ図を含む。
【図１０】決済機能及びプライムブローカ業務機能を実現するために本発明の実施形態に従って動作するコンピュータシステム又はプロセッサにより実施され得るステップを例示する流れ図を含む。
【図１１】決済機能及びプライムブローカ業務機能を実現するために本発明の実施形態に従って動作するコンピュータシステム又はプロセッサにより実施され得るステップを例示する流れ図を含む。
【図１２】決済機能及びプライムブローカ業務機能を実現するために本発明の実施形態に従って動作するコンピュータシステム又はプロセッサにより実施され得るステップを例示する流れ図を含む。
【図１３】プライムブローカ業務機能のために使用されるメッセージプロトコル全体を例示するブロック図を含む。
【図１４】流動性アウトソーシングプロセスのオペレーションを例示する付加的なさらに詳細な流れ図である。
【図１５】流動性アウトソーシングプロセスのオペレーションを例示する付加的なさらに詳細な流れ図である。
【図１６】流動性アウトソーシングプロセスのオペレーションを例示する付加的なさらに詳細な流れ図である。
【図１７】流動性アウトソーシングプロセスのオペレーションを例示する付加的なさらに詳細な流れ図である。
【図１８】流動性アウトソーシングプロセスのオペレーションを例示する付加的なさらに詳細な流れ図である。
【図１９】流動性アウトソーシング機能を実施するために本発明の実施形態に従って動作するコンピュータシステム又はプロセッサによって実施され得るプロセスステップ全体を例示する流れ図を含む。
【図１】
2005530281.tif 000007
【図２】
2005530281.tif 000008
【図３】
2005530281.tif 000009
【図４】
2005530281.tif 000010
【図５】
2005530281.tif 000011
【図６】
2005530281.tif 000012
【図７】
2005530281.tif 000013
【図８】
2005530281.tif 000014
【図９】
2005530281.tif 000015
【図１０】
2005530281.tif 000016
【図１１】
2005530281.tif 000017
【図１２】
2005530281.tif 000018
【図１３】
2005530281.tif 000019
【図１４】
2005530281.tif 000020
【図１５】
2005530281.tif 000021
【図１６】
2005530281.tif 000022
【図１７】
2005530281.tif 000023
【図１８】
2005530281.tif 000024
【図１９】
2005530281.tif 000025
【国際調査報告】
2005530281.tif 000026