JP2004528654A - 金融取引システムのユニバーサルインタフェース - Google Patents

Abstract

金融サービスプロバイダ１４で、機能的に売買するリモートアクセスを提供する方法及びシステムが開示されている。通信プロトコルは、前記プロバイダからパーティリモート１６が価格を付けて、プロバイダと取引を始めることを許可するのを提供する。前記通信プロトコルは、インターネットのような国境のない通信ネットワーク１２で用いるのに適しており、実施するリモートサイトで最小の支援機能だけを必要としている。したがって、前記システムをリモートシステムの幅広い様々なタイプによって用いることを容易にしている。

Description

【技術分野】
【０００１】
本発明は、ネットワークを介して金融サービスプロバイダの価格及び商品取引（ｔｒａｄｉｎｇ）機能へのアクセスを供給するネットワーク通信プロトコル、方法及びシステムに関する。
【背景技術】
【０００２】
多くの機関投資家は、電子的に両替のような取引（ｔｒａｎｓａｃｔｉｏｎｓ）を実行する能力を必要としている。この「電子流動性」がいくつかの理由で必要とされている。例えば、電子両替サービスが多様な通貨でＢ２Ｂ又はＢ２Ｃの市場において、機関投資家に商品及びサービスの提供をすることができるように要求するかもしれない。他の理由は、リスク管理システムの実行を統合する又は「ブラックボックス」の価格を実施する機関投資家による要求を含んでいる。
【０００３】
様々な仕組みは、機関投資家が金融サービスプロバイダに電子的に接続することができるように提供されている。しかしながら、従来の実装は、メッセージ通信インフラストラクチャのかなりの部分が、機関投資家のシステム上で実行するよう要求している。更に、機関投資家及び金融サービスプロバイダ間の通信プロトコルは、専用のネットワーク上で用いるように設定されており、インターネットのようなオープンネットワークシステム上で用いるのには一般的に適していない。このインターネット通信は「無国籍」であり、多数の段階的な商品取引を更に複雑にしている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従って、インターネットのようなネットワークを介して供給する金融サービスを、機関投資家によって実行されるのに必要とされる最小の処理だけでもって、機関投資家によるアクセスが容易にできる改良された通信フレームワークを提供する必要性がある。
【課題を解決するための手段】
【０００５】
本発明はこれらの及び他の要求を取扱っており、本発明はインターネットのようなネットワーク間で結合された１つ又は２つ以上のサーバに、ユーザが価格及び商品取引要求を送ることができる単純でメッセージを基本としたフレームワークを提供し、それによって金融機関のホストマシンに送られる。前記サーバは、電子取引アプリケーション及びサービスプロバイダの建値（ｑｕｏｔｅ）、実行及び確認するシステムの間の連絡係として運用できる。前記フレームワークは、実装することが簡単であり、現存のソフトウェア及び機能を向上するために金融サービスプロバイダの流動性の能力をクライアント機関が利用することができる。比較的簡単な統一コードをシステムに加えることによって、前記システムは建値を検索でき、商品取引を実行でき、過去の取引の分析を実行することができる。
【０００６】
本発明の特定の使用は、適切な金融サービスプロバイダと外国為替取引をすぐに携わる機能を有する機関投資家に提供することである。金融投資又は製品の、購入又は販売のような付加的な取引も同様にサポートされている。ここでは外国為替関連取引に関して本発明を特に記述するつもりである。しかしながら、開示された原則は、他の金融取引の様々なものにも適応できる。
【０００７】
特定の実装に応じて、金融サービスプロバイダにアクセスを提供するシステムは、通信ネットワークへのインタフェースを有しており、例えば、適切なデータインタフェースを介して、金融サービスプロバイダシステムの適切な部分に同様に接続されている。前記システムは、事業体から価格要求のメッセージを受信するように、金融サービスプロバイダから価格を得て、その価格を受信するに際して、取引のタイプを特定し、取引の詳細を指定し、価格要求が受け付けられ又は拒否されたことを指示し、もし、受け付けられたら、取引及び取引ＩＤに対する価格を特定し、データを含んでいる事業体に価格応答のメッセージをフォーマット化して送信するように、プログラム化されている。取引ＩＤを含む商品取引要求のメッセージを受信するに際して、サーバは、金融サービスプロバイダから取引を始めるための承認を得て、取引ＩＤを含む事業体に商品取引応答のメッセージを送信し、商品取引要求が承認されるか又は拒否されたかどうかを指示する。商品取引要求が承認されたならば、システムは、取引をブックに加えるために金融サービスプロバイダに命令する前に、事業体から商品取引承認のメッセージを受信するまで待機している。
本発明はコンピュータ読み取り可能媒体上にあるコンピュータ実行可能プログラムコード、デジタルデータストリーム中に実施化されたコンピュータデータ信号、又は、ユーザが本発明の機能をそれらのシステムと合体するのを援助するように設計されたネットワークアクセス装置と相互に作用する方法として実施化することができる。更に、様々な機能及び実施形態が図及び特許請求の範囲中に記述されている。
【発明を実施するための最良の形態】
【０００８】
図１は本発明が実行できる環境のブロック図を示している。商品取引インタフェースサーバ１０は、インターネットのようなネットワーク１２及び１つ又は２つ以上の金融サービス商品取引システム１４．１〜１４．ｎ．間に接続されている。商品取引システム１４．１…１４．ｎ．は、異なった金融サービスプロバイダであり、又は、同じプロバイダーと関連する多種の異なるシステムを表すことができる。例えば、一つのシステム１４．１は、第１のサービスプロバイダからの外国為替取引システムである。それ自身の建値、実行及び承認のサブシステムを有しており、他の商品取引システム１４．２（図示せず）は、米国有価証券用であり、第１のサービスプロバイダ又は多分異なるサービスプロバイダと関連しているかもしれない。
【０００９】
以下に詳述するように、商品取引インタフェースサーバ１０は、ネットワーク１２を介して金融商品取引システムにアクセツ権を有する投資家のクライアント１６．ｌ〜１６．ｍに提供する通信プロトコルを実行する。投資家のクライアントは、機関投資家又は他の事業体であり、彼らは商品取引システム１４．１〜１４．ｎ．により利用可能な金融サ〜ビスへのアクセス権を有するユーザ自身１８にアクセスすること、又は、提供することを望んでいる。特定の実装では、商品取引インタフェースサーバ１０は、機関投資家１６及び接続された金融サービス商品取引システム１４内の適切なシステム間の価格及び商品取引要求を処理して送信する。インターネット、専用回線、仮想私設ネットワーク及び／又は他の安全な形式、管理された帯域幅を含む多種の方法により、クライアント１６によるシステムへのアクセスができる。通信に対して、実時間価格ストリーミング、専用回線、仮想私設ネットワークのような、保証された高速アクセス及び安全通信を必要とし、又は、他の安全な接続方法が選択される。一旦機関投資家又は他のシステムが商品取引インタフェースサーバ１０に接続されたならば、ここに記述されたプロトコルを用いて多様な外国為替契約書中の、例えば、建値及び保証にメッセージを送り始めることができる。特定の実装では、投資家クライアント（ユーザ自身が直接又はユーザ自身の代わりに）は、スポット、フォワード、スワップ及びオプション取引を含む建値及び商品取引を要求することができる。他のサポートされているメッセージ要求は、通貨リストに関する商品取引控帳（blotter）及び商品取引詳細の要求、前後の商品取引割合及び表示するスポット価格の要求を含んでいる。
【００１０】
図２は図１の商品取引インタフェースサーバ１０の主要なシステムの構成要素を示すブロック図である。サーバ１０は、ネットワークから受信したメッセージを処理し、金融サービスシステム１４と接続し、クライアントにメッセージを返信するように設定されている。実施形態においては、サーバ１０は、むしろ受信したメッセージが権限のあるユーザからのものであり、該メッセージが正確なフォーマット内にあるものであることを確実にする認証及び確認モジュール２２から成っている。もし要求されるならば、処理するために受信されたデータパケットからメッセージデータを抽出するために、メッセージ構文解析モジュール２４を供給することができる。
【００１１】
要求処理モジュール２６は、受信したメッセージを調べ、該要求を処理する適切なサブモジュールを決定するように設定されている。通常、各要求のタイプは、関連したサブモジュールを持つであろう。例えば、サブモジュール２８、３０及び３２を、価格の獲得、商品取引の実行、命令要求の注文を処理するよう供給することができる。各サブモジュールは、金融サービスシステム中の適切なコンポーネントにデータを送り、応答を受信するための機能を含んでいる。要求処理モジュール２６は、更にサブモジュール２８〜３２からの応答を受信し、クライアント１６に送信する応答メッセージを調整するように設定されている。金融サービスシステム１４との通信は、１つ又は２つ以上のインタフェース及びファイヤーウォール３６を介して、通常、確立されるであろう。同様に、適切なインタフェース３８は、商品取引インタフェースサーバ１０をネットワーク１２と接続するために供給される。インタフェースの詳細は、システムの実行と独立しており、適切なインタフェース及びインタフェース技術は、当業者によく知られたことである。
【００１２】
メッセージ取引のフローは、金融機関及び投資家の間で送信及び受信されるように示され、取引タイプのリストによって提示されることができる。三つの典型的な取引シナリオがある。図４ａに集約されている第１のシナリオにおいては、取引は十分に達成される。図４ｂに集約されている第２のシナリオにおいては、投資家によって成された価格要求は、例えば、ユーザが認識されない、不十分なマーケットデータが利用されているなどの理由により、拒否される。図４ｃに集約されている第３のシナリオにおいては、取引が価格付けられたが十分な商品取引要求が、例えば、クレジット制限、無効の建値ＩＤ等のために、拒否される。
【００１３】
本発明のプロトコルを用いる典型的な相互作用は、次のように行われる。
（１）機関投資家は、特定の量の１つの通貨を他の通貨に交換する価格を要請する。
（２）商品取引インタフェースサーバは、価格要求を受信し、金融サービス商品取引システム中の適切なコンポーネントから建値を獲得し、該建値を含むクライアントにメッセージを返信する。
（３）クライアントは前記建値を受信し、受信可能であるならば、前記商品取引を要請しているメッセージを返す。
（４）商品取引要求が商品取引インタフェースサーバによって受信され、「商品取引の完了」メッセージがクライアントに返信される。
（５）クライアントは商品取引完了のメッセージのメッセージ承認のレセプトを返信する。
（６）取引は金融機関ブックに記録される。
【００１４】
一連の通信は、本発明に従って取引通信プロトコルに関して、より詳細に述べられるであろう。該通信プロトコルは、商品取引インタフェースサーバにアクセスする遠隔サイトによって実行されなければならない大量の処理を、最小化するように設定されている。その結果、商品取引インタフェースサーバへのアクセスを許可する機能は、遠隔システムに容易に付加することができる。
【００１５】
ここでＸＭＬフォーマットの例によって前記プロトコルを述べる。しかしながら、該プロトコルは、ＸＭＬフォーマットインプリメンテーションにだけに限定されないし、他の択一的なフォーマットを通信媒体及びデータフォーマット仕様に適切なものとして用いることができる。様々な選択できる分野と同様に、この特定の実施形態に対する要求される分野を含む、通信プロトコルに対する最も最適なデータタイプの定義は、以下の表１に示されている。最適な実施形態において、ＸＭＬ要求は、一般的なウェッブサービス構造及びありきたりのＨＴＴＰＳ ＰＯＳＴメッセージを用いて転送される。応答は、内容種別ｔｅｘｔ／ｈｔｍｌを有する標準ＨＴＴＰ／１．１ヘッダーを含み、その応答の本体は、返答メッセージを含んでいる。
【００１６】
最適なＸＭＬフォーマットにおいて、全てのメッセージは「Ｍｅｓｓａｇｅ」タグで始まり、それで終わる。Ｍｅｓｓａｇｅタグ間にはヘッダー及び本体がある。ヘッダーは商品取引に伴うパーティについての識別情報を含み、メッセージ追跡識別コードも含むことができる。メッセージのヘッダーは、正しいユーザの名前及びパスワードを含むことができるし、好ましくは含まなければならない。サーバ１０は、メッセージを受信した時、ヘッダーから名前パスワードを自動的に抽出し、それらを用いて要求を識別する。当業者に知られたメッセージ及び識別技術で名前及びパスワードを暗号化する様々な方法を用いることができる。
【００１７】
識別情報をヘッダーに存在している他の情報から分離することができるように、とうしかか分離するＮｏｄｅＩｎｆｏタグを用いることができる。投資家からのメッセージに対するヘッダーのサンプルが以下に示されている。
【００１８】
【表１】

【００１９】
このヘッダーは、投資機関又は他の事業体（ここでは「投資家」）の名前を特定する。事業体の役割を具体的に述べることができる。この例では、具体的な事業体は、問題の商品取引の要求者の役割を担っている。タイムスタンプ分野が同様に含まれる。要求と関連する投資家とのコンタクト、商品取引が要求されている投資家のクライアント（以下、「投資家ユーザ」という）及び投資家によって特定されたメッセージＩＤのような、更なる情報をヘッダー中に含むことができる。事業体と関連したサーバに対するＨＴＴＰアドレスのような付加的な分野を、利用するのに要求されるものとして、含むことができる。更に、タイプ分野は、望ましくは、メッセージタグと関連付けられて、管理及び診断メッセージが通常のメッセージから容易に分離される。上の実例では、メッセージタイプは「ノーマル」である。
【００２０】
メッセージの本体は、価格が要請されている１つ又は２つ以上の金融の詳細事項を含んでいる。属性のタイプは、要求されている取引のタイプを特定するのに用いられており、製品詳細タグは、取引の事業体である製品を特定するため、及び製品―特定取引の詳細を供給するために用いられている。好ましい実装では、５つの取引タイプ、ＰｒｉｃｅＲｅｑ（価格要求）、ＰｒｉｃｅＲｅｓ（価格応答）、ＴｒａｄｅＲｅｑ（商品取引要求）、ＴｒａｄｅＲｅｓ（商品取引応答）及びＴｒａｄｅＡｃｋ（商品取引知識）が定義されている。外国為替取引に関して、通常の取引製品は、スポット、フォワード、スワップ及びオプションを含んでいる。取引及び製品のタイプは、商品取引インタフェースサーバ１０によって用いられることにより、メッセージがどの様に処理されるべきか、特に、要求は、どのサブモジュールに送る経路を取るべきか、及び、金融サービスプロバイダのシステムのどのアスペックトが、該要求を処理するためにアクセスされなければならないかを決定することができる。望ましくは、多様な価格要求及び応答は、単一のメッセージで供給することができ、商品取引要求、応答及び知識だけを含むメッセージが、単一の取引に関連付けられている間に、取引リストタグの基に一緒にグループ化することができる。
外国為替取引のような取引を開始する時、第１のステップは、該取引自身についての価格及び詳細に対する取引の製品タイプを特定している商品取引インタフェースサーバに、価格要求を送信することである。理解されるように、取引の詳細は、問題の取引のタイプに依存している。一方、特定の取引タイプは、以下に実施形態が説明されており、当業者が付加的な取引タイプに開示された概念をどの様に拡張すればよいか理解できるであろう。
望ましくは、取引の詳細は「生産詳細」タグの間で特定される。先物取引のために、該取引の詳細は、2つの商品数量要素を含んでいる。１つは、ＱｕａｎｔｉｔｙＣｃｙであり、それは販売される通貨の量、通貨のタイプ、購入者及び販売者を特定する。第２の商品要素、ＯｔｈｅｒＣｃｙは、交換で得るための通貨のタイプの型を特定するのに用いられる。ここでは、購入者及び販売者を一致させるために特定することができる。
【００２１】
望ましい実施形態では、取引の詳細を以下に示されたテンプレートに従って特定することができる。
【００２２】
【表２】

【００２３】
ＱｕａｎｔｉｔｙＣｃｙ及びＯｔｈｅｒＣｃｙは通貨タイプであり、望ましくはｔｈｒｅｅ−ｌｅｔｔｅｒＩＳＯの通貨コードを用いて特定される。この取引のタイプに対する初期の価格要求に関して、ＱｕａｎｔｉｔｙＣｃｙの関連した数量は、ＯｔｈｅｒＣｃｙの数量が空白なままであり、為替レートに基づく金融サービスプロバイダによって記入される間に、特定されるべきである。両サイドの商品取引（多分、前記取引は２つ以上のパーティ及び適宜に拡張されたプロトコルを含むように構造化されているけれども）に対して一致する購入者及び販売者を含まなければならない。
データの設定は、上で示したように年―月―日のフォーマットで特定することができる。「ＴＯＭ」（ｔｏｍｏｒｒｏｗ）、スポット、Ｉｗ、１ｍ、２ｍ、３ｍ、６ｍ及び１ｙのような、価格要求における択一的なデータも望ましくはサポートされている。しかしながら、データが金融サービスプロバイダから送られた応答メッセージ中に特定されるとき、該データはＹＹＹＹ−ＭＭ−ＤＤフォーマット中にだけ示されている。
【００２４】
外国為替先物の価格要求に対するサンプルメッセージ本体は、以下に示されている。
【００２５】
【表３】

【００２６】
取引の詳細は、始め及び終りの取引タグ間で特定されている。この例においては、前記機関は、為替レートに従って、外国為替先物コンタクトに対する価格要求を、百万ＵＳドルをユーロと交換するようにしている。前記取引は２００２年９月１５日に設定されるであろう。
付加的な分野をメッセージ本体中に含むことができる。例えば、クライアント取引ＩＤを特定することができる。要求者によって自由に定義付けられるこの値（例えば、機関投資家）は、前記要求者が要求を応答に一致することができるように、商品取引インタフェースサーバによって生成された応答メッセージ中にコピーされるであろう。更に、取引行動の分野を特定して、例えば、取引要求が新しい取引に対するものであるか、前記メッセージが前の取引要求を更新することを求めているのかどうかを指示することができる。システムがテストする目的を無視して、管理メッセージに対する取引要求「ａｄｍｉｎ」をキャンセルするような更なる値を、取引行動の分野中に望ましくは特定することができる。多様な価格要求を望むならば、それらを取引リストタグ間の分離取引要素としてメッセージ中に含むことができる。
当業者が理解するように、先物価格の外国為替に関して説明された原則は、いかなる商品取引のタイプにでも適応することができる。これらのメッセージ中に利用するのに適している他の好ましいタグは、以下のテーブル１に示されるデータタイプの定義で示されている。価格要求の受信後に、商品取引インタフェースサーバ１０は、メッセージを認証して許可し、必要に応じて該メッセージを構文解析する。価格要求メッセージタイプに基づいて、要求処理モジュール２６は、少なくとも適切なメッセージデータ、望ましくは、完全なメッセージを、獲得した価格モジュール２８にパスする。このモジュールは、外国為替の価格要求を付与する金融サービスシステム中の適切な機能と通信中であり、それを取引の詳細にパスしている。獲得した価格モジュール２８は、金融サービスシステム１４から、ここで交換レート及び貨幣の対応する量の形式で、サービスプロバイダが支払う予定の価格を受信する。この値はその時にメッセージ中に組み入れられて、要求を行っている機関投資家に返信される。
本発明の好ましい実施形態で特定されるプロトコルに従って、この応答メッセージ中のＴｒａｎｓａｃｔｉｏｎＬｉｓｔのタイプは、価格応答を指示するように設定されており、メッセージの本体は価格情報を付加するように更新される。更に、ＱｕｏｔｅＩＤの値は、金融サービスプロバイダによって特定される。この分野は既述した価格が「取引可能（ｄｅａｌａｂｌｅ）」であることを示している。ＱｕｏｔｅＩＤ特定された建値の商品取引を要求する一連のメッセージで用いられる。
建値有効期限の分野は、建値が有効性を維持している間の時期を指示するように供給されるかもしれない。もしクライアントが消滅した建値を取り扱おうと試みるならば、その商品取引は拒否されるであろう。タイムアウトの期間はマーケットの状況しだいで変化できる。タイムアウト期間は１つの建値から次の建値に変化するかもしれない。望ましくは、建値消滅はデフォルトによって６秒に設定されている。
【００２７】
同様に、いくつかの実例において、サービスプロバイダは価格を特定することができないか、又は、特定したくないかもしれない。例えば、提案された取引は、特定された商品取引の制限を越えているかもしれない。この状況が許されるならば、取引ステータスタグは、価格要求が受諾されるか拒否されるかどうかを示すためにある値を与えることができるように供給されている。付加的な詳細は、受諾された取引又は何故要求が拒否されたかの説明について、詳細を与える取引ステータスタグに基づくメッセージのような、要求される該メッセージに加えることができる。先物価格要求へのサンプル応答メッセージの例が、参考として太字体で示された加えられた分野と一緒に以下に示されている。
【００２８】
【表４】

【００２９】
この例において、取引ステータスのタイプは、金融サービスプロバイダが取引に対する価格を設定できることを「ａｃｃｅｐｔｅｄ」が示している。外国為替先物取引の「ｐｒｉｃｅ」は、金融サービスプロバイダが提案した通貨に対して払うつもりのある通貨量として「ＯｔｈｅｒＣｃｙ」セクション中に示されている。前記メッセージは価格建値が３０秒間有効であることを示している。適用される交換レートの急行のステートメント、取引に適用される参考レート及びポイントを示すデータ及び価格付けされている取引のテキストサマリーのような、付加的取引情報データを提供できる。返信されたメッセージを処理するときに、要求しているパーティがこのデータを調べる機能を実行する必要がないために、要求はされていないけれど、望ましくは、完全な全取引情報が前記メッセージ中に提供される。
【００３０】
前記取引が価格を付けることができなかったならば、価格応答のメッセージは、前記要求が「ｒｅｊｅｃｔｅｄ」であるという指示を返信する。拒否に対するグランドを与えるメッセージも含むことができる。価格要求を拒否する価格応答のメッセージの例の一部が以下に示されている。
【００３１】
【表５】

【００３２】
一旦機関投資家（又は、他の要求パーティ）が受諾した価格応答を受信したならば、前記メッセージが商品取引要求である指示を含んでいる、及び、更に価格要求中に提供された建値ＩＤを含んでいる商品取引要求のメッセージを送信することによって、例えば、取引リストのタイプの分野中のこれを特定することによって、その取引に対する商品取引を要求できる。投資家によって特定された取引ＩＤのような他の分野も同様に含むことができる。好ましい実装において、多様な取引に対する価格要求のメッセージと異なって、商品取引要求は、１つの取引を含むことができる。商品取引要求のメッセージの例が以下に示されている。
【００３３】
【表６】

【００３４】
商品取引要求のメッセージが商品取引インタフェースサーバによって受信された時、商品取引要求の金融サービスプロバイダに通知して、適切なものとし関連した詳細を提供する適切なサブモジュールに該メッセージをパスしている。金融サービルプロバイダ−は、商品取引要求を処理し、要求された取引に取り込んだほうが良いかどうかを示している。商品取引インタフェースサーバは、許諾又は拒否に等しいタイプを有する取引状況要素を含んでいる商品取引の応答のメッセージを組み立てて送信している。もし受信されたならば、前記メッセージは建値ＩＤも含んでいる。もし商品取引が拒否されたならば、テキストメッセージを提供して、上で示したような価格要求の拒否のような、失敗の種類を説明することができる。他の詳細と同様に取引を集約するテキストメッセージを受諾要求中に含むことができる。商品取引要求が受諾された商品取引応答のメッセージの例が以下に示されている。
【００３５】
【表７】

【００３６】
メッセージストリーム中のこの点に、金融サービスプロバイダによって、機関投資家及び受諾によるオファーがある。しかしながら、本発明の概念に従って、前記取引は、少なくとも建値ＩＤを含む商品取引知識のメッセージのレセプトの後までサービスプロバイダのブック上に公式には載せていない。このメッセージは受信された商品取引応答のメッセージが投資家により受信されたことを示している。知識メッセージの例が以下に示されている。
【００３７】
【表８】

【００３８】
いったん商品取引インタフェースサーバは商品取引知識のメッセージを受信すると、金融サービスプロバイダのブックに加えられている含まれた建値ＩＤに対応した金融サービスプロバイダ及び取引を知らせる。
【００３９】
受信された商品取引応答への承認が30秒などのような特定の時間内に、商品取引インタフェースサーバによって受けられないならば、電話、電子メール、または他の手段などによって、要請者が手動で連絡されるべきであるのを示しながら、エラー条件を合図することができる。望ましくは、メッセージヘッダーに提供される連絡データは、問題で商品取引について議論するのに接触の指示として使用される。
【００４０】
最終的に、ユーザは商品取引応答のメッセージの領収書を受け取ったことを知らせることができる。これは、商品取引の別々の部分を結びつける建値ＩDがキーとして使用されるというメッセージを送ることを伴う商品取引承認応答の例が以下に示されている。
【００４１】
【表９】

【００４２】
当業者に理解されるように、上述したメッセージフォーマット及び方法論は、リモートサイトで必要とされる最小の機能的なサポートで実行するのが容易なフレキシブルなインフラストラクチャを提供している。前記プロトコルは、インターネットのような、国籍のない通信ネットワークによく適合する。それは、商品取引価格及び牽引の要求が、金融実体によって割り当てられた建値ＩＤ（要請者の割り当てられた取引ＩＤ）によって相互に関係している、事前に定義された順番及びメッセージに従っているからである。
【００４３】
更に、商品取引インタフェースサーバの操作は、アクセスを提供している金融サービスシステムの商品取引から比較的独立しており、従って、金融サービスシステムにおける（通常、事前に存在する）自動化された機能は、価格が与えられるか、又は、取引が始まるかどうか決定するのに使用されている。商品取引インタフェースサーバの需要は、金融サービスシステムの適切な機能で通信を行っている、図２で示されるサブモジュール28、30、32の価格の獲得、商品取引の実行及び注文命令のような、適切なサブモジュールでもって単に供給される。受信したメッセージから該金融サービスシステムにデータを伝え、商品取引インタフェースサーバによって生成された応答メッセージに含まれるようにデータを返信することができる。付加的取引のタイプをサポートするために、付加的サブモジュールを容易に加えることができる。システムが、特定のモジュール及びサブモジュールに分割された様々な機能を持って示されているにも拘らず、様々な機能間の分割しているラインは多少恣意的なものであり、サーバに対する異なる機能的構成が利用すること可能である。
【００４４】
更に、上述したように、異なる取引のタイプは、各取引のタイプに対する取引の詳細を定義付けることによって容易に適応させることができる。特定の実装において、上述した外国為替の先物商品取引に加えて、スポット、スワップ及びオプションの商品取引可能な価格及び商品取引要求がサポートされている。これらの取引に対するメッセージの基本フォーマットは、上に示されたそれに類似している。しかしながら、取引の詳細は製品の細部（ｐｒｏｄｕｃｔ−ｓｐｅｃｉｆｉｃ）である。
【００４５】
例えば、「スポット」として特定された製品の価格要求に応じて、応答メッセージは金融サービスプロバイダによって決定されるものとして、例えば、適切な休日スケジュール関する設定スポット日を含んでいる。好ましい実施形態において、スポット日は、＜Ｄａｔｅ ｔｙｐｅ＝”ＳｅｔｔｌｅＤａｔｅ”＞ＹＹＹＹＭＭＤＤ＜／Ｄａｔｅ＞としてメッセージ本体中に示されており、ＹＹＹＹＭＭＤＤは、リスト化された通貨に対する適切なスポット日である。
【００４６】
スワップの価格要求は、近隣及び遠方の両区間を含んでいる。その各々はスポット又は先物に大変似ている。先物要求のように、スワップの価格要求への価格応答のメッセージは、上述したような設定日及び交換レート要素を含んでいる。更に、スワップの価格応答は、参考スポットレート及びポイントスプレッドのような、参考情報を含んでいる。これらの一部のデータは、与えられたスワップの遠方の区間中に含まれている。このデータに対する好ましいメッセージフォーマットが以下に示されている。
【００４７】
【表１０】

【００４８】
この例では、値の要素は参考スポットレートを含んでいる。しかしながら、先物と異なって、スワップの価格応答は、ポイント要素を用いて近隣及び遠方の区間のポイントスプレッドを示している。スワップ要求に対する通信プロトコルの好ましい実装において、スワップの近距離区間はＸＭＬ価格要求において最初に現れなければならない。更に、スポットの先物価格要求を生成することは、近隣区間及び先物に対する製品タイプを遠方区間の製品タイプと同じものとして、スポットを特定することである。同様に、外国為替スワップを供給された価格は、近隣及び遠方区間のポイントスプレッドを含んでいる。
本発明の更なる観点に従って、通信プロトコルは、金融サービスプロバイダによって供給される過去の商品取引処理データ及び関連した機能にアクセスするのを拡張することができる。特定の実施形態において、商品取引サーバインターフェースは、要求を処理するために設定して、電子的に記録された過去の取引に関連した金融サービスプロバイダからデータを検索し、各これらの商品取引の詳細をアクセスし、割当額（前及び過去の）を課金するための要求を処理するために設定されている。
【００４９】
様々な環境下で、機関投資家（又は他のパーティ）は、金融サービスプロバイダのところで多数の口座に割り当てして商品取引を行う。現在の方法論は、電子的に商品取引が登録されたその時（前の商品取引）か、商品取引が登録された後（過去の商品取引）の何れかの自動化手法でこれを成すことができる。
【００５０】
前の商品取引割当のメッセージは、上述した商品取引要求のメッセージに類似している。有効価格およびその関連した建値ＩＤが一旦、受信されると、付加情報は商品取引要求中に含むことにより、要求されたサブアカウントの故障を特定することができる。好ましいシンタクッス中のこのタイプのメッセージの例が以下に示されている。
【００５１】
【表１１】

【００５２】
メッセージが類似している過去の商品取引割当に対して、「TradeReq」のタイプが「AllocReq」のタイプに置換されることを除いて、その異なるタイプは、現存の商品取引に割当情報を加える代わりに、過去の商品取引割当が新しい商品取引を偶然に記録しないことを保障することは重要である。
【００５３】
取り扱い可能な価格に対し要求するのに加えて、例えば、１つ又は２つ以上の通貨交換（例えば、USD/EUR又はJPY/CHF）に対して、本発明に従ったプロトコルは、表示する建値に対する要求をサポートするように、本発明に従ったプロトコルを拡張することができる。通常、要求者は表示レートで商品取引をすることはできないであろう。しかし、要求の処理量は、取り扱い可能な建値に対するよりより高いであろう。何故ならば、金融サービスプロバイダによる唯一最小の処理は、前記要求を提供するために要求される。表示価格要求の連続シリーズが発行される時、データフローは価格データストリームに類似している。
【００５４】
特定の実施形態において、要求メッセージは、RateReq (レート要求)に設定された商品取引リスト要素のタイプ属性で構成されている。メッセージは、更に、適切な時間に設定されているExchangeRate及びモード属性のような、Eod(最後の日)又はRealtimeのような、要求されているレート情報を特定するタイプを持ったRateListを含んでいる。ExchangeRate要素のモード属性をEodに設定することは、最も最近の最後の日のレートを望んでいることを示している。
【００５５】
外国為替取引に対して、利益の異なる通貨のRate及びCross要素は、は開始及び終了のRateList要素間に置かれている。応答メッセージにおいて、レート値はメッセージに加えられる。４つの異なった通貨交換の交換レートを要求する、Eodレート要求の本体セクションを示すＸＭＬメッセージの部分の例が下に示されている。
【００５６】
【表１２】

【００５７】
「値」タグが各特定されたクロスに加えられている応答メッセージの例が、以下に示されている。
【００５８】
【表１３】

【００５９】
いくつかの実例のおいて、返信レートは多様な値を含むことができる。例えば、実時間レート要求において、以下に示されるメッセージ本体の例で示されるように、前記レートは、最も最近の勧誘及び質問値として返信されることができる。
【００６０】
【表１４】

【００６１】
上に述べられた価格付け、商品取引要求のメッセージ及び応答と同様に、商品取引情報を検索する工程は、望ましくは、ＸＭＬフォーマットで単純なメッセージ交換を伴っている。商品取引の控帳データを受信するための「Blotter Request」は、商品取引インタフェースサーバに送信される。サーバはその要求を金融サービスプロバイダに転送し、返信データを受信し、及び、控帳応答を要求者に送信する。控帳要求のメッセージの例が下に示されている。
【００６２】
【表１５】

【００６３】
BlotterRequestのメッセージの例において、data_atart_time,data_end_time及びmodeは、検索するデータの開始及び終了の期間を特定するクォールパラメータである。モード分野は、パーティ又は複数のパーティを特定するのに用いることができ、そのパーティの取引データは、特定のユーザヘッダーによって実行された商品取引にだけに対して、クライアント又はデータに対するａｌ”データのようなデータが検索されるべきである。
BlotterRequestのメッセージのレセプトに応じて、適切なデータが金融サービスプロバイダよって供給された後に、商品取引インタフェースサーバは検索されたデータを含む応答を発行する。この配置での応答の例の一部が以下に示されている。
【００６４】
【表１６】

【００６５】
BlotterRequestのメッセージは要素のリストを含み、その要素の各々は単一の取引を含む。 望ましくは、控帳応答分野は特有の接頭辞（「blotter」のような）を含んでおり、メッセージに関連した取引を容易に区別することを可能にしており、個々の商品取引に対する詳細は、開始及び終了の「BlotterRequest」タグのような、分離したタグ内に含まれている。上に示された例において、,<blotter:BlotterElement>要素の各々は、単一の商品取引の詳細を記述する多数の分野を含んでいる。
本発明の様々な概念は、好ましい実施形態に関して既に上述した。しかしながら、形式及び詳細の変更は、本発明の精神及び範囲から離れずに実施できる。
【００６６】
【表１７】

【００６７】
【表１８】

【図面の簡単な説明】
【００６８】
【図１】本発明が実施される環境を示すブロック図である。
【図２】図１の商品取引インタフェースサーバの主なシステム要素を示すハイレベルのブロック図である。
【図３】本発明を実施する外国為替に対する特定の取引システムのアーキテクチャを示すハイレベルの図である。
【図４ａ】成功した及び成功しなかった、価格及び取引要求に対するメッセージの一連の流れを説明している。
【図４ｂ】成功した及び成功しなかった、価格及び取引要求に対するメッセージの一連の流れを説明している。
【図４ｃ】成功した及び成功しなかった、価格及び取引要求に対するメッセージの一連の流れを説明している。

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