JP2004523836A

JP2004523836A - 金融口座情報を管理するためのシステムと方法

Info

Publication number: JP2004523836A
Application number: JP2002566891A
Authority: JP
Inventors: キャスパーロバート; マクミランジェフリー
Original assignee: モルガン・スタンレー
Priority date: 2001-02-16
Filing date: 2002-01-16
Publication date: 2004-08-05
Also published as: AU2002236789A1; US7685060B2; EP1364480A2; WO2002067485A3; US20020116304A1; WO2002067485A2; EP1364480A4; US20070136188A1; US7966253B2

Abstract

システムは、複数の団体の一つに関係する団体情報を有する複数の団体レコードの各々を持つ複数の団体レコードを有する団体ファイル（３）を含むことを提供する。同様に、複数の口座の一つに関係する口座情報を有する複数の口座レコードの各々を持つ複数の口座レコードを有する口座ファイル（３）を含んでいる。複数の口座レコードの各々は、複数のレコードの少なくとも一つへのリンクを含んでいる。複数の取引の一つに関係する取引情報を有する複数の取引レコードの各々を持つ複数の取引レコードを有する取引ファイル（７）を含んでいる。複数の取引ファイルの各々は、複数の口座レコードの一つへのリンクを含んでいる。

Description

【技術分野】
【０００１】
本発明は金融、特に、金融情報を管理するためのシステムと方法に関する。
【背景技術】
【０００２】
金融機関によって提供されるサービスの１つは、顧客とのまたは顧客の代わりに取引に従事することである。例えば、顧客が特定の株券の１００株を購入したいならば、金融機関は顧客の代わりにその購入を行い、顧客の口座に手数料を含んだ担保としての購入価格を請求するであろう。これらの取引を実行した結果として得られた料金は、金融機関の収入の重要な部分を示している。更に、金融機関を横断的に集めた時、これらに関連した情報はリスク管理、顧客サービス、マーケティングおよび操作処理の領域で、経営上の決定にとって重要な情報源となっている。
【０００３】
成功した取引事業を確立するには、顧客情報を適切に管理することが必要である。顧客情報を管理するプロセスは、開設される各顧客の口座に関して新しい口座書類を記入することを通常含んでおり、その開設される各口座書類は、顧客の名前、住所、法的な身分、顧客の代わりに注文をする権限を与えられたアドバイザ、前記口座を管理する販売員およびその口座の中に実行された取引の保証人の名前等の情報を必要とする。その上、顧客口座情報は、決済指示、源泉徴収税情報および口座収支報告、確認および他の書簡をどこに送るべきかのような顧客の選択を備えている。一旦顧客情報が集められたならば、その情報はコンピュータ化された顧客口座管理システムに通常取り込まれる。
【０００４】
特定の顧客は金融機関を通じて携わっているかまたは従事している全ての取引またはポジションのリストは、各顧客と同様に関連付けられており、そこで、例えば、顧客がＸＹＺ株式会社の１００株を購入するならば、取引日、投資タイプ、量、価格および代理手数料のようなその取引の詳細が、取引データベースに格納され、特定の顧客口座と関連付けられるであろう。このように、金融機関は、取引事業を追跡および管理するための顧客口座管理システムに格納されている顧客および取引情報を利用することができる。
【０００５】
顧客口座管理システムの利点は、金融機関が特定の取引または一連の取引に対するその開示（ｅｘｐｏｓｕｒｅ）を評価できるようにするということである。もし金融機関が顧客の一人であるＡｃｍｅ株式会社が流動的な（ｌｉｑｕｉｄｉｔｙ）問題を持っていることを学んだならば、顧客口座管理システムは、金融機関がＡｃｍｅ株式会社に従事しているまたは代わりに従事している、全ての取引を特定するために調べることができる。この情報に基づいて、金融機関は（ａ）こうむった負債を回復する十分な資産を持っているかどうか、（ｂ）Ａｃｍｅ株式会社の取引の制限は金融機関のリスクを制限するために減らすべきかどうかに対する事業の決定をすることができる。かくして、顧客口座管理システムは、金融機関が各顧客の取引に関連付けられているリスクを管理するのを援助するのに重要な役割を果たしている。
【０００６】
顧客口座管理システムの他の利点は、金融機関が取引事業の収益性を分析し、ビジネスチャンスの新領域を特定するのを援助することである。各顧客が係わっている全ての取引を追跡することによって、金融機関はどの顧客がもっとも有益であるか、どの取引が成功しているか、およびどの領域の事業が金融機関の総合的な収益性を増やすために続けるべきであるかを決定することができる。
【０００７】
有効な顧客口座管理システムは、収益性のある取引事業を運営するのに重要なものであるが、従来技術の顧客口座管理システムは、金融機関に信頼でき、維持可能で容易にアクセス可能な情報を提供することができない。リスクを評価し、販売および貿易事業の収益性を決定するのを援助するのにこの情報は必要である。従来技術の顧客口座管理システムの非収益性は、多数のファクターの結果である。
【０００８】
最初に、従来技術のシステムは、データ保全を実施および維持することに一般的に劣っている。例えば、Ａｃｍｅ株式会社がある一つの金融機関に３つの異なった口座の新設を望んだとすると（例えば、異なった口座で異なった投資機関に係わる取引を分けたいために、Ａｃｍｅ株式会社は同じ金融機関に多数の口座を持つことができる。）、従来技術のシステムでは、Ａｃｍｅ株式会社の情報がシステムに３回別々に（各新口座を開設する度ごとに）取り入れられることを一般的に必要とした。その複数のデータエントリのために、各回ごと実際に取り入れられた会社の情報は、エラーまたは矛盾した句読点および簡略によってわずかに変わるかもしれない。例えば、一つの口座入力はＡｃｍｅＣｏｒｐ．の名前を使用し、一方、他の入力はＡｃｍｅＣｏ．を用いているかもしれない。先行技術の顧客口座管理システムが分析され、システムに取り込まれた６００以上の口座を持っている特定の顧客の名前の矛盾した句読点および簡略によって、システムは顧客の名前に関して３０の独自のスペルを維持していることが分かった。もし、特定の顧客と関連した各口座に対するスペルが異なっているならば、システムはどの口座が特定の顧客に関係しているかを決定することができない。結果として、システムは関係した口座を通じて特定の顧客によって実行された全ての取引、ステップを特定できないであろう。ステップは各顧客の取引から得られるリスクおよび収益性を適切に評価するために必要なものである。
【０００９】
従来技術の顧客口座管理システムの他の欠点は、これらのシステムが異なるがしかし関連した主体の複数の口座を効果的に管理することができないことである。しばしば、顧客は商取引するためにいくつかの口座を用いている。その各々の口座は、例えば、子会社または親会社のような顧客に関連した異なった法的主体と関連付けられている。各口座上に表れる名前は異なっているが、これらの関連した口座に関連付けられたリスクは、顧客ファミリー（即ち、最後の親会社（ｕｌｔｉｍａｔｅｐａｒｅｎｔ））の取引信用度に関連している。したがって、リスク管理の目的のために、もし特定の顧客と関連付けられた異なった口座で実行された全ての取引を集めて、その顧客への全体の開示を決定するならば、それは有益であろう。しかしながら、先行技術のシステムは、ある所定の顧客と関連付けられた口座のなかの、関連した口座および関係の階層構造を容易に管理できない。結果として、これらのシステムはリスク管理の目的のために、関連した取引を容易に特定することができない。
【００１０】
前記先行技術システムの他の欠陥は、特定の顧客口座の中で種々な法的主体が果たす役割を特定するのに精度が不足していることである。現実の本人（ｐｒｉｎｃｉｐａｌ）（例えばＸＹＺ基金に対する受益株主）、その本人に対するオーダープレーサー（ｏｒｄｅｒｐｌａｃｅｒ）（例えばＸＹＺ管理会社）、顧客の代理で取引を行う金融機関の法的主体、顧客口座を管理している販売員、および、必要であれば、顧客の取引の保証人として実行する主体のような種々な法的主体は、所定の口座に関連付けられている。従来技術のシステムにおいて通常起こることは、データエントリ者が顧客口座記録にこれらの関連した団体の名前を入力するかもしれないということであり、前記顧客および彼等が果たす役割に対する彼等の関係を特定する方法で、前記システムはこれらの団体に自動的にタグ付けを行わないということである。そこで、例えば、もしＡＢＣ会社がＡｃｍｅ会社の保証人としての役割を果たしているならば、ＡＢＣ会社の名前は、データエントリ者によってＡｃｍｅ会社の口座レコードに入力されるかもしれない。しかしながら、前記システムは、ＡＢＣ会社がリスク管理の目的に対するＡｃｍｅ会社の保証人であると認識する必要はない。その結果、ボブスミスの自分の取引のリスク分析が実行されたとき、前記システムはＡｃｍｅ会社の取引のＡＢＣ会社の保険から生じる前記開示を、リスク計算に含めないであろう。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
先行技術の顧客口座管理システムは、有効に顧客口座情報および口座関係を管理することができないために、顧客口座および取引情報は、リスクを管理し、金融機関の販売および貿易事業の収益性を評価するのを援助するために容易に投機することができない。
【課題を解決するための手段】
【００１２】
本発明は前記先行技術の欠陥を改善するためのシステムおよび方法に対するものである。本発明によって、複数の団体の一つに関係した団体情報を有する、各複数の団体レコードに対する複数の団体レコードを持つ団体（ｐａｒｔｙ）（例えば、法的主体）ファイルを備えることを、システムは提供している。同様に、複数の口座の一つに関係した口座情報を有する、各複数の口座レコードに対する複数の口座の有する口座ファイルを備えている。各前記複数の口座レコードは、複数の団体レコードの少なくとも一つにリンクを含んでいる。結局、複数の取引の一つに関係した取引情報を有する、各複数の取引レコードに対する複数の取引レコードを有する取引ファイルが含まれている。各複数の取引レコードは複数の口座レコードの一つに対してリンクを含んでいる。
【００１３】
本発明の実施形態において、複数の団体は少なくとも一つの本人の団体を含み、各複数の口座レコードは少なくとも一つの本人の団体に対する情報を有する複数の団体レコードの一つに対してリンクを含んでいる。
【００１４】
本発明の実施形態において、複数の団体は少なくとも一つのオーダープレーサーの団体を含み、各複数の口座レコードは少なくとも一つのオーダープレーサーの団体に対する情報を有する複数の団体レコードの一つに対してリンクを含んでいる。
【００１５】
本発明の実施形態において、複数の団体は少なくとも一つの販売員の団体を含み、各複数の口座レコードは少なくとも一つの販売員の団体に対する情報を有する複数の団体レコードの一つに対してリンクを含んでいる。
【００１６】
本発明の実施形態において、複数の団体は少なくとも一つのブッキング会社（ｂｏｏｋｉｎｇｃｏｍｐａｎｙ）の団体を含み、各複数の口座レコードは少なくとも一つのブッキング会社の団体に対する情報を有する複数の団体レコードの一つに対するリンクを含んでいる。
【００１７】
本発明の実施形態において、複数の団体は少なくとも一つの保証人の団体を含み、各複数の口座レコードは少なくとも一つの保証人の団体に対する情報を有する複数の団体レコードの一つに対するリンクを含んでいる。
【００１８】
本発明の実施形態において、各複数の団体レコードは、階層関係のフィールドを有している。第１の複数の団体レコードは第１の団体に関係した団体情報を格納し、第２の複数の団体は第１の団体の中の第２の団体に対する団体情報を格納し、第２の団体は階層構造関係を有している。第１の複数の団体レコードおよび第２の複数の団体レコードの構造的関係フィールドは、第１の団体および第２の団体間の構造関係を示唆している。
【００１９】
本発明の実施形態において、各複数の団体レコードは団体関係のフィールドを有している。第１の複数の団体レコードは第１の団体に対する団体情報を記録し、第２の複数の団体レコードは第２の団体に対する団体情報を格納する。前記第１の団体および前記第２の団体は団体の関係を有している。第１の複数の団体レコードの団体関係のフィールドおよび第２の複数の団体レコードの団体関係のフィールドは、第１の団体および第２の団体間の団体関係を示唆している。第１の団体および第２の団体間の団体関係は、保証人と被保証人（ｇｕａｒａｎｔｏｒ−ｇｕａｒａｎｔｅｅ）の関係である。
【００２０】
実施形態において、複数の団体の一つの団体と関連している複数の取引と関連しているリスクを決定する方法が含まれている。最初に、一つの団体に関係した複数の団体を特定する。次に、一つの団体または関連した団体は、それらの口座レコードの中の本人であることが口座ファイルから検索される。次に、これらの口座レコードにリンクしている全ての取引レコードが特定される。結局、特定された取引レコードの全ての取引に対する集約されたリスク開示は、リスク経営システムにより決定される。
【００２１】
実施形態において、一つの団体と関連付けられた複数の取引から得られるリスクを決定する方法は、検索された口座レコードと関係した全ての保証人を特定するステップを備えている。次に、一つの団体の全ての保証人が特定され、全部の被保証人の数が決定される。結局、集約されたリスク開示は全部の被保証人の数を考えて評価される。
【００２２】
一つの団体と関連付けられ、複数の取引と関連付けられたリスクを決定する方法の実施形態において、一つの団体に関連した複数の団体は、階層的関係のフィールドによって特定される。
【００２３】
本発明は、他のものそれぞれに関するそれぞれのステップおよび一つ以上の関係をから成り、構造の特徴を具体化する装置、要素の組合せおよび部分の配置は、このステップ、以下の詳細な説明の実例で示された全てのものを効果あるものにするために採用され、および本発明の範囲は特許請求の範囲に示されている。
【発明の効果】
【００２４】
本発明のシステムを用いて、異なる団体のグループを利用してクレジット、法的（ｌｅｇａｌ）及びマーケティングのような異なる目的に対する団体の階層構造（例えば、複合の法的主体間の関係）を生成することにより、金融機関は顧客口座情報を管理できる。本発明は、多くの定義された目的に対する他の団体に団体の連結を許すことにより、この要求を適応させている。システムを用いて、「法的目的」または「クレジット目的」に対するある階層構造の中に一緒にリンク付けられた全ての団体を配置すること、本人または本人の保証人のような利益の役割を選択すること、および、これらの団体がその役割を果たしている全ての口座を検索することにより、金融機関はリスクを管理することができる。これらの口座の中の取引は、リスクへの開示を計るための目的に対して特定される。金融機関はシステムを用いて、「マーケッティング目的」に対してるある階層構造中に一緒にリンク付けられた全ての団体を配置すること、オーダープレーサーのような利益の役割を選択すること、および、これらの団体がその役割を果たしている全ての口座を検索することにより、金融機関はリスクを管理することができる。
【００２５】
従って、本発明は、情報がリスクを管理するのを援助するのに用いられる顧客の口座情報および口座関係を効率的に管理するためのシステムおよび方法を提供し、金融機関の販売および貿易事業の収益性を評価する。
【００２６】
本発明はそれぞれの他のものに関する種々のステップ及び一つ以上のステップの関係を備えており、実施形態の構造、要素の組み合わせ及び部分の配置は、このステップを効果あるように適用される。以下の詳細な説明で具体例の全て及び発明の範囲が特許請求の範囲で指示されるであろう。
【発明を実施するための最良の形態】
【００２７】
「口座」の概念は、本発明の顧客口座管理システムに重要である。口座は複数の関連した取引が設置されるバケットである。各口座はその口座の役割を果たす多数の団体と関連付けられている。例えば、各口座は本人、例えば、口座の実質所有者の役割を果たす団体を有している。各口座と関連付けられている他の団体はオーダープレーサーである。その団体は、口座の取引を開始する口座の本人によって権限を与えられている。口座と関連付けられている他のタイプの団体は、次のものに限定されないが、ブッキング会社（オーダープレーサーと取引する金融機関と関連付けられた主体）、口座販売員および保証人を備えている。かくして、各口座はその口座に対する役割を定義付けられた特定の団体のグループを備えている。
【００２８】
顧客が団体の組み合わせ用いて取引を結ぶことを望むならば、システムは最初に現存の口座をサーチして、望まれている団体の組み合わせが現存の口座のいずれかに見出されるかどうか、または、団体の組み合わせがユニークなものであるかどうかを決定する。もし、望まれている団体の組み合わせが現存の口座に見出されるならば、その口座は取引に用いられる。望まれている団体の組み合わせがユニークなものであるならば、新しい口座がその団体のグループに設けられる。例えば顧客は、本人Ａｃｍｅ、オーダープレーサーＡＢＣ投資アドバイザ、ブッキング会社ＤＢＦ＆Ｃｏ．および販売員ボブを含む現存する口座番号０００１を有していると仮定する。顧客は販売員テッドと事業を行いたい場合、新しい口座０００２番が本人Ａｃｍｅ、オーダープレーサーＡＢＣ投資アドバイザ、ブッキング会社ＤＢＦ＆Ｃｏ．および販売員ボブの団体として有しているものとして作成されるであろう。この団体のグループに対する新しい口座を作成することによって、システムは、主要なＡｃｍｅを伴う取引に対する販売員ボブおよび販売員テッドの実行を別々に追跡することができる。口座を介して取引高を、ネティンググバケット（ｎｅｔｔｉｎｇｂａｃｋｅｔｓ）に適切にグループ化するために、もし異なる操作上の同意によって取引を管理するならば、新しい口座が作成される。一般的に、取引が発生した時はいつでも、新しい口座は作成され、その取引は本人、オーダープレーサー、販売員ブッキング会社および営業同意のユニークな組み合わせと関連付けられている。
【００２９】
各口座はその口座の下で実行される取引をそれにリンクする。そこで、例えば、もしオーダープレーサーＡＢＣ投資アドバイザが口座番号０００１の主要なＡｃｍｅ関してＩＢＭの１００株を買うように、販売員ボブに注文を出すならば、その取引は口座番号０００１にリンクされる。この方法で口座および取引を編成することにより、システムは、取引をその口座にリンク付けられた特定の団体のグループと関連付けることができる。この団体と取引の関係は、本発明のシステムに膨大な他の計算と同様に、対本人のリスク開示の決定、対販売員の利益性を決定するような種々の分析を実行させる。
【００３０】
これらの利点を達成するために、本発明の顧客口座管理システムは、図１に示されているデータ構造を用いている。本発明に従って、顧客データは３つのデータファイル、即ち、団体ファイル３、口座ファイル５および取引ファイル７に分割されている。
【００３１】
図２を参照して、団体ファイル３のレコードフォーマットを示すブロック図が示されている。図３Ａを参照して、団体ファイル３のレコードフォーマットが示めされており、それはシステムに含まれる一つの団体の情報を記録するためのフィールドを備えている各レコード３（ｘ）で示す複数のレコード３（１）、３（２）…３（Ｎ）を含む団体ファイル３のブロック図が示されている。例えば、団体ファイル３の各レコード３（ｘ）は、団体の名前２１、法的名前２２、住所２３、仲介人２４、電話番号２５、ＦＡＸ番号２０１、電子メールアドレス２０２、法的様式２５、配偶者の有無（団体が個人であるならば）２８および機関の管轄権（団体が団体であるならば）２６に対するフィールドを備えている。当業者であれば、これらのフィールドに加えて、レコード３（ｘ）は維持したい特定の団体に対する他の情報に対するフィールドを含むこともできることは理解できるであろう。
【００３２】
あるレコード３（ｘ）のフィールドは、全ての団体と関連しない情報を要求するかもしれないので、そのために、特定の団体を利用しない。例えば、特定の団体が株式会社のような法人であるならば、配偶者の有無のフィールド２８は関連性を持っていないので、その特定のレコードを無視する。このような場合に、データがその特定の団体の団体レコードに取り入れられた時に、システムは団体の配偶者の有無に対するデータを要求しないであろう。システムが特定のフィールドを受け付ける値は、関連したフィールドを以前に申し込んだ値によるかもしれない。例えば、スペインが機関の管轄権のフィールド２６で選ばれる値があるならば、そのときには、システムがフィールド２５に法的に示した可能性のある値は、スペインに特定される。このようにして、団体レコード３（ｘ）はフィールドを含み、システムは更にストリームラインデータエントリ処理を維持する間、幅広い団体タイプを収容するフィールドに対する可能な価値を示している。
【００３３】
図４を参照して、特定の団体レコード３（ｘ）間の関係を示す団体ファイル３のブロック図を示している。各団体レコード３（ｘ）は、団体ファイル３に格納されている異なる団体間の関係の生成を促進する団体関係フィールド２９を備えている。例えば、ＸＹＺ（株）が団体レコード３（５）およびスミス氏に格納された団体であるならば、広範な数のＸＹＺ（株）は団体レコード３（７）に格納された団体である。ＸＹＺ（株）の株の販売／購入に対する契約が違反されないために、ＸＹＺ（株）の協会メンバー（ａｂｏａｒｄｍｅｍｂｅｒ）としてスミス氏を特定することは役に立つ。ＸＹＺ（株）およびスミス氏間のこのような関係を生成するために、団体レコード３（５）の団体関係フィールド２９（５）は、団体レコード３（５）に含まれる団体の協会メンバーとして、知られたデータベースプログラミング技術を用いて、その団体を特定する団体レコード３（７）へのリンクを含むであろう。同様に、団体レコード３（７）の団体関係フィールド２９（７）は、団体レコード３（７）に含まれる団体が、協会メンバーである会社としてその団体を特定する団体レコード３（５）へのリンクを含むであろう。
【００３４】
このようにして、団体関係フィールド２９は、団体間の要求される関係を生成するために団体ファイル３の団体間にリンクを確立するために用いることができる。例えば、もし団体レコード３（３）の団体が、団体レコード３（１）の団体によって実行された全ての取引に対する保証人であるならば、そのとき、適切なリンクは、団体関係フィールド２９（３）および２９（１）に格納されて、この保証人と被保証人の関係を構築するであろう。同様な方法で、他の要求される団体が構築される。
【００３５】
上述した団体関係を構築することに加えて、団体レコード３は、階層構造で相互に関連している団体を特定するための階層関係フィールド２７を備えている。階層関係フィールド２７は、ＨＱ１フィールド２７ＡおよびＨＱ２フィールド２７Ｂから構成されている。階層関係フィールド２７は以下のように用いられている。団体レコード３（６）の団体は、株式会社であり、その株式会社は団体レコード３（４）に格納されている団体である子会社を所有していると仮定する。更に、団体レコード３（４）の株式会社は、団体レコード３（１）に格納された団体である子会社を所有していると仮定する。これらの三つの団体は、全て関連のある団体（それらは団体名から明らかでないかもしれない）である。リンクは団体レコード３（４）のＨＱ２フィールド２７Ｂ（４）を指している団体レコード３（１）のＨＱ１フィールド２７Ａ（１）に置かれていて、団体レコード３（４）の団体は、団体レコード３（１）の団体の親であることを示している。同様に、リンクは団体レコード３（６）のＨＱ２フィールド２７Ｂ（６）を指している団体レコード３（４）のＨＱ１フィールド２７Ａ（４）に置かれていて、団体レコード３（６）の団体は、団体レコード３（４）の団体の親であることを示している。階層関係フィールド２７（１）、２７（４）および２７（６）に格納されているリンクによって定義されている三つの構造が遷移されたとき、三つの法人間の階層関係は、図３Ｂに示されているように決定される。後に示すように、団体間の階層関係を決定することは、リスク管理および有益性分析を効果的に実行するために必要である。
【００３６】
団体関係および階層関係の生成が団体関係フィールド２９および階層関係フィールド２７に置かれているリンクを用いることが示され、要求されている関係を特定するために三つの構造を生成しているけれど、団体間の団体および階層関係を特定するのに他の技術が利用できることは、当業者であれば理解されるであろう。加えて、システムは多重の階層構造を維持する能力を有している。
【００３７】
図５に示すように、口座ファイルのフォーマットが示されている。口座ファイル５は、システムに加えられている一つの口座の情報を格納するためのフィールドを含むレコード５（ｘ）で示す複数のレコード５（１）、５（２）…５（Ｎ）を備えている。例えば、口座ファイル５の各口座レコード５（ｘ）は、口座番号のフィールド５１、口座タイプのフィールド５４（例えば、現金、利益）、口座手数料率のフィールド５８、および、顧客対金融機関の関係を管理する効力のある契約を参考にする契約のフィールド５６を備えている。更に、各口座レコード５（ｘ）は口座５（ｘ）に役割を果たしている団体に対するリンクを含むフィールドを包含しており、個人リンクフィールド５３、オーダープレーサーフィールド５５、ブッキング会社リンクフィールド５７、販売員リンクフィールド５９、および保障リンクフィールド５２を備えている。当業者は、これらの分野に加えて、各レコード５（ｘ）は、維持したい特定の口座に関係したいかなる他の情報と同様に、他の役割を持っている追加の団体へのリンクへのフィールドを含むことを認識するであろう。
【００３８】
図６を参照して、それは特定の口座レコードおよび種々の団体レコード間の連結を示すブロック図を示している。例えば、口座レコード５５（６）は主要なリンクフィールド５３（６）を有しており、それは口座５（６）と関連付けられた個人である団体に関係した情報を格納する団体ファイル３の団体レコード３（４）へのリンクを含んでいる。同様に、口座レコード５（６）は、それぞれ団体レコード３（８）、３（１８）、および３（９）へのリンクを支持している、オーダープレーサーリンクフィールド５５（６）、ブッキング会社リンクフィールド５７（６）および販売員リンクフィールド５９（６）を有している。これらの団体レコードは口座に対するオーダープレーサー、ブッキング会社および販売員である団体に関係した情報を格納している。
【００３９】
団体ファイル３の団体情報を格納し、適切な団体を特定の口座に関連つけるレコード５（ｘ）およびレコード３（ｘ）間にリンクを張ることから得られる利点は膨大なものである。最初に、団体ファイル３の中の必要な団体レコードへのリンクを用いて、ユーザはその団体が新しい口座と関連つけられるたびに、繰り返して団体情報を入力する必要はなく、それは重要な時間の節約をもたらす。また、団体情報が一度（それが団体ファイル３の中に入力されるとき）入力されるだけであるので、同じ団体情報が再入力されるたびにしばしば起こるデータエントリの錯誤と矛盾は排除される。さらに、団体が口座に関連付けるプロセスは、団体ファイル３の特定の団体レコードにリンク付けることによるので、その特定の団体が利用する団体情報は、その特定の団体が役割を果たす全ての口座全体に渡って必然的に一貫しているであろう。さらに、本願発明のデータ構造は団体ファイル３の中に格納された団体情報が変更されているならば、それらの変更が、その特定の団体レコードを示す全ての口座レコード５（ｘ）適応するので、団体情報を変える過程を簡素化する。以下に示すように、これらの利点は、団体ファイル３の中に格納された団体情報の精度と一貫性をかなり改良するので、リスク分析および収益性分析などのようなデータ分析の信頼性を大いに増加させるだろう。その分析は正確で一貫した情報を必要とする。
【００４０】
本願発明の方法による団体情報を格納する別の利点は、各口座と関連付けられている団体によって実行される役割が明確に定義されるということである。図７を参照して、それは本願発明の実施形態によって口座エントリ画面７１を示している。エントリ画面７１はで口座と関連付けられている各団体よって実行される役割に対応する多数のエントリフィールドを備えている。例えば、本人エントリフィールド７３はエントリ画面７１に含まれており、特定の口座に対する本人が画面に入力する。同様に、エントリ画面７１はオーダープレーサーエントリフィールド７５、販売員エントリフィールド７７、およびブッキング会社のエントリフィールド７９を備えている。さらに、エントリ画面７１は、口座の中の他の役割を果たす複数の団体を入力するために、追加のエントリフィールド７８を供給する。団体情報は特定のエントリフィールドに入力されるので、特定の団体が口座で果たす役割はシステムにおいて明確に定義される。その上、特定の口座レコードにリンクされる団体レコードが、団体関係および階層関係情報を含むので、上述したように、団体レコードレベルで維持された追加の関係情報は、複数の団体の役割に更なる定義を付加することにより、特定の口座レコードと合体される。
【００４１】
エントリ画面７１はサーチ団体ボタン７２を含んでおり、起動されると団体ファイル３の中に格納された団体のリストをユーザに提示する。団体を口座に入力するために、ユーザはこの団体リストをサーチし、必要な団体を選択する。代わりに、サーチ団体ボタン７２が起動されると、ユーザが検索用語を入れることができる検索画面が提供される。検索用語に基づいて、団体のあいまいな検索が、ユーザに提供される検索用語により実行され、一致される。選択のときに、選択された団体に対する特定の団体情報は、団体ファイル３から検索されて、適切なエントリフィールドに表示される。かくして、団体情報は、入力錯誤を減少させ、データ保全を改良することにより再入力される必要はない。さらに、「あいまいな検索」の能力が団体ファイル３の中の団体の場所を探すために備えられている。当業者によりあいまいな検索アルゴリズムを用いることによって、ユーザがいったん団体名の部分に入ると、システムは、音声および／またはパターン・マッチングに基づく団体と一致するリストを潜在的にユーザに提示するだろう。
【００４２】
図８を参照して、取引ファイル７の書式が示されている。取引ファイル７は多数のレコード７（１）（各レコード７（ｘ）が特定の取引に関係した情報を格納するためのフィールドを備えている７（２）．．．７（Ｎ））を備えている。例えば、取引ファイル７の各取引レコード７（ｘ）は口座番号フィールド８１、取引数のフィールド８２、取引日付／時間のフィールド８３、取引タイプフィールド８５（例えば、購入または販売）、投資タイプフィールド８７（例えば、ストックまたは債券）、購入数のフィールド８９、購入価格フィールド８８、および手数料フィールド８６を含むかもしれない。当業者は、また、各レコード７（ｘ）がこれらのフィールドに加えて維持するのにおいて望ましい特定の取引に関係したいかなる他の情報のためのフィールドも含むかもしれないと認めるだろう。
【００４３】
図９を参照して、特定の口座レコードおよびその特定の口座と関連付けられている種々な取引レコードの間の連結を示すブロック図が示されている。上述したように、各口座レコード５（ｘ）は口座を唯一特定する口座番号フィールド５１（ｘ）に格納されている。取引が特定の口座、例えば、口座5(6)の下で実行されるとき、口座番号フィールド５１（６）に格納されている口座番号は、取引レコードの７（１）、７（２）、および７（８）の口座番号フィールドの８１（１）、８１（２）、および８１（８）にそれぞれ格納されている。したがって、口座レコード５（６）は口座番号フィールド５１（６）のユニークな口座番号によって関連取引レコードの７（１）、７（２）、および７（８）にリンクされる。
【００４４】
図１０を参照して、本願発明に従って関係した口座間の連結を描写するブロック図が示されている。図１０の例は特定の顧客に対する情報を格納する口座レコード５（１）を備えている。口座レコード５（１）は特定の顧客口座と関連付けられている種々な団体に対する団体情報を格納する団体レコード３（１）、３（２）、３（３）、３（４）、および３（１５）へのリンクを含んでいる。この例では、団体レコード３（１）は口座に本人の団体情報を格納しており、団体レコード３（２）はオーダープレーサーの、団体レコード３（３）は販売員の、団体レコード３（４）はブッキング会社の、および団体レコード３（１５）は保証人の、団体情報を格納している。口座レコード５（１）は取引レコード７（ｌ）−７（４）にリンクされており、それはそれぞれ口座レコード５（１）の本人に代わって実行される取引に対する情報を格納する。同様に、口座レコード５（２）は、団体レコード３（１）、３（５）、３（６）、３（７）に格納された、および、それぞれ本人、オーダープレーサー、販売員、およびブッキング会社に関係する情報を提示する関連した団体情報へのリンクを含んでいる。更に、団体レコード３（１）は、団体関係が２つの団体間に存在するのを示す団体レコード３（１７）にリンクされている。この例の目的のために、この団体関係の本質は保証人−被保証人のそれであり、即ち、団体レコード３（１７）の団体が団体レコード３（１）の団体によって実行されるすべての取引の保証人であるということである（即ち、取引レコード７（１）−７（９）、団体レコード５（１）の口座と関連付けられた取引を保証するだけの団体レコード３（１５）の保証人団体と比べて）。口座レコード５（２）は取引レコード７（５）−７（９）にリンクされている。最終的に、口座レコード５（３）はそれぞれ本人、オーダープレーサー、販売員、およびブッキング会社を特定する団体レコードの３（８）、３（９）、３（６）、および３（１１）にリンクされている。口座レコード５（３）は、取引レコード７（１０）−７（１３）にリンクされている。
【００４５】
この例では、各これらの口座に関して本人が関係しているので、口座レコードの５（１）、５（２）、及び５（３）の口座は関係している。口座レコード５（１）と５（２）の口座の本人は同じで、団体レコード３（１）の団体である。口座レコードの５（２）および５（３）の口座の本人であり、団体レコード３（１）および３（８）の団体はそれぞれ階層的に関係している。これらの口座が関係しているので、両方の口座で実行された取引（例えば、取引レコード７（１）−７（１３）の取引）は、団体レコード３（１）および関係した団体の本人に代わって実行された取引から生じる全体の開示または収益性を決定するときには一緒に見られる。
【００４６】
口座レコード５（２）及び５（３）の口座は、共通の販売員を共有しているので（団体レコード３（６）の団体）、他の方法で同様に関係している。それゆえ、団体レコード３（６）の販売員によって実行された取引の収益性を分析するとき、両口座（例えば、取引レコード７（５）−７（１３））において実行された取引は、一緒に調べられる。
【００４７】
図１１を参照して、本願発明のシステムの口座管理および取引集積能力を用いる、リスク管理分析を実行するのに必要なステップのフローチャートが示されている。この例の目的には、口座の本人として団体Ａに代わって実行されたすべての取引のリスク分析が要求されている。ステップ１で定義される第１のステップは、団体Ａが関係した全ての団体を特定することである。団体Ａに関係した団体を特定するプロセスは、前述したように、団体Ａが一部である階層関係および団体関係を調査することを含んでいる。団体Ａに関係した全ての団体が一旦特定されたならば、ステップ２において、団体Ａまたは団体Ａに関係した団体の１つのどちらかを本人として有している全ての口座が特定される。次に、ステップ３では、ステップ２で特定された全ての口座の全ての取引の取引数が、総取引数を形成するために集められる。次に、ステップ４、団体Ａまたは団体Ａに関係した団体のいずれかを保証人として有する全ての口座が特定される。次に、ステップ５では、ステップ４で特定された全ての口座の取引数は、全ての保証人数を形成するために集められる。
【００４８】
次に、ステップ６では、団体Ａの団体レコードおよび団体Ａに関係した全ての団体のレコードは、団体Ａまたは団体Ａに関係した団体のいずれかに保証人としてどの団体に存在するどんな団体関係でも特定するために調べられる。ステップ７において、団体Ａまたは団体Ａに関係した団体のどちらの全ての口座は、口座レベルで保証人として機能しているどんな団体も特定するために調べられる。被保証人数は決定されている。次に、ステップ８では、ステップ６および７で特定された全ての被保証人数が総被保証人数を形成するために集められる。最終的に、ステップ９では、団体Ａに関連関連付けられた総リスク開示が、総保証人数に総取引数を加えること、および総被保証人数を合計したものから引き算することによって決定される。
【００４９】
上述した例は、本願発明のシステムが特定の本人に関連付けられている取引に関してリスク分析を実行するのにどう用いられるのかを説明している。当業者が、どんな特定の団体に関連付けられたリスクの計算が、他の要素と同様に考慮して取引のタイプによってより複雑であるかもしれないと、当業者であれば認めるだろう。データ構造および本願発明の方法を用いて、リスク分析に関係する取引および団体の関係は、リスク管理計算の精度を増加させることによって容易に特定することができる。
【００５０】
同様に、上述した方法は、特定の本人または販売員に関連付けられる取引の収益性を決定するのに使用されるかもしれない。また、当業者は団体、口座およびシステムで維持された取引情報のいかなる他の分析を実行するのに、この方法を適合させることができる。例えば、本願発明のシステムおよび方法は、現存のマーケティングの目的に対する金融機関の顧客、または金融機関の顧客ベースへの新しい金融商品によって、どの金融商品が用いられるかを特定する用いることができる。
【００５１】
したがって、本願発明のデータ構造および方法を用いることによって、システムは口座データの品質が大いに改良されて提供される。また、異なった団体間の関係と同様に特定の口座に関して果たす各団体の役割をシステムは追跡するので、顧客口座および取引情報は、リスクを管理し、金融機関の取引事業の収益性を評価するのを援助して容易にてこ入れすることができる。
【００５２】
上述した記載に基づいて、データおよび命令形式を受信するよう、およびデータおよび指示を送信するように結合された少なくとも１つのプログラマブルプロセッサ、データ記憶システム、少なくとも１つの入力装置、および少なくとも１つの出力装置を含むプログラマブル・システム上で実行可能な少なくとも１つ以上のコンピュータプログラムで、本発明のシステムおよび方法を実行することは、当業者であれば明らかであろう。各コンピュータプログラムは、高級言語である手続形言語またはオブジェクト指向プログラミング言語、アセンブリまたは機械語で実行されているかもしれない。どの場合でも、言語はコンパイルされたまたは解釈された言語であるかもしれない。適切なプロセッサは一例として一般的なおよび特殊な目的のマイクロプロセッサを備えている。その上、ハードウェア、ファームウェアまたはハードウェアおよびファームウェアの組合せ、同様に、異なった形式での分散化モジュールおよび／またはデータを用いて、システムを実行する他の実施形態は、当業者にとって自明なことであり、実施形態は本発明の範囲内のものである。更に、非制限の例として、本発明を実行するためのプラットホームとしてサイベース、オラクルおよびＤＢ２のような従来のデータベース管理システムを用いることは、当業者にとって自明なことであろう。
【００５３】
対象物は上に詳しく述べているので理解されるであろう。前述の記載から明らかであるそれらのものは効率的に実施できる。同様に、本発明の精神および範囲から離れることなく、上記方法および詳述した構成を実行するのに代替物が上の記述に含まれ、および説明図で示した全ての事項は、実例として解釈されるべきであり、制限して解釈すべきでない。
【００５４】
ここで記述した本発明の一般的および特定の特徴の全てを、および言葉の問題としてそこに落ち込むといわれるかもしれない、本発明の範囲の全ての陳述をカバーすることを意図している。
【図面の簡単な説明】
【００５５】
本発明を十分理解するために、以下に添付図面の説明をする。
【図１】本発明の団体ファイル、口座ファイルおよび取引ファイルデータ構造のブロック図である。
【図２】図１の団体ファイルの団体レコードのフォーマットを示すブロック図である。
【図３Ａ】団体レコード間の階層関係を示す図１の団体ファイルのブロック図である。
【図３Ｂ】図３Ａの階層関係のブロック図である。
【図４】団体レコード間の団体関係を示す図１の団体ファイルのブロック図である。
【図５】図１の口座ファイルの口座レコードのフォーマットを示すブロック図である。
【図６】本発明に従って口座レコードおよび複数の団体レコード間の連結を示す図である。
【図７】本発明実施形態に従った口座レコードのエントリ画面の１画面である。
【図８】図１の取引ファイルの取引レコードのフォーマットを示すブロック図である。
【図９】本発明に従った団体レコードおよび複数の取引レコード間の連結を示すブロック図である。
【図１０】本発明に従った関係した口座間の連結を示す図である。
【図１１】本発明に従った取引のグループに関連付けられたリスクを評価する方法の流れ図である。

Claims

取引情報を管理するためのシステムにおいて、
複数の団体レコードを有する団体ファイルであって、各前記複数の団体レコードは複数の団体の一つに関係する団体情報を有する団体ファイルと、
複数の口座レコードを有する口座ファイルであって、各前記複数の口座レコードは複数の口座の一つに関係する口座情報を有し、前記複数の団体レコードの少なくとも一つにリンクを備えた口座ファイルと、
複数の取引レコードを有する取引ファイルであって、各前記複数の取引レコードは複数の取引の一つに関係する取引情報を有し、前記複数の口座レコードの一つにリンクを含んだ取引ファイルを備えることを特徴とするシステム。
前記複数の団体は少なくとも一つの本人の団体を含み、各前記複数の口座レコードは、前記少なくとも一つの本人の団体に関係する情報を有する前記複数の団体レコードの一つへのリンクを含むことを特徴とする請求項１に記載のシステム。
前記複数の団体は少なくとも一つのオーダープレーサーの団体を含み、各前記複数の口座レコードは、前記少なくとも一つのオーダープレーサーの団体に関係する情報を有する前記複数の団体レコードの一つへのリンクを含むことを特徴とする請求項１に記載のシステム。
前記複数の団体は少なくとも一つの販売員の団体を含み、各前記複数の口座レコードは、前記少なくとも一つの販売員の団体に関係する情報を有する前記複数の団体レコードの一つへのリンクを含むことを特徴とする請求項１に記載のシステム。
前記複数の団体は少なくとも一つのブッキング会社団体を含み、各前記複数の口座レコードは、前記少なくとも一つのブッキング会社団体に関係する情報を有する前記複数の団体レコードの一つへのリンクを含むことを特徴とする請求項１に記載のシステム。
前記複数の団体の中に保証人団体を含むことを特徴とする請求項５に記載のシステム。
少なくとも一つの前記複数の団体レコードは、階層関係フィールド、第１の団体に関係する団体情報を有する第１の前記複数の団体レコード、および第２の団体に関係する団体情報を有する第２の前記複数の団体レコードを有し、前記第１の団体および前記第２の団体は、階層関係を有し、前記第１の複数の団体レコードの前記階層関係フィールド、および前記第２の複数の団体レコードの前記階層関係フィールドは、前記階層関係を指示することを特徴とする請求項１に記載のシステム。
前記階層関係は、前記第１の団体が前記第２の団体の親であることを指示することを特徴とする請求項７に記載のシステム。
少なくとも一つの前記複数の団体レコードは、団体関係フィールド、第１の団体に関係する団体情報を有する第１の前記複数の団体レコード、および第２の団体に関係する団体情報を有する第２の前記複数の団体レコードを有し、前記第１の団体および前記第２の団体は、団体関係を有し、前記第１の複数の団体レコードの前記団体関係フィールド、および前記第２の複数の団体レコードの前記団体関係フィールドは、前記団体関係を指示することを特徴とする請求項１に記載のシステム。
前記団体関係は、保証人との保証関係であることを特徴とする請求項９に記載のシステム。
取引情報を管理する方法において、
複数の団体レコードを有する団体ファイルを形成するステップであって、各前記複数の団体レコードは複数の団体の一つに関係する団体情報を有する団体ファイルを形成するステップと、
複数の口座レコードを有する口座ファイルを形成するステップであって、各前記複数の口座レコードは、複数の口座の一つに関係する口座情報を有する口座ファイルを形成するステップと、
各前記複数の口座レコードを前記複数の団体レコードの一つへリンクするステップと、
複数の取引レコードを有する取引ファイルを形成するステップであって、各前記複数の取引レコードは、複数の取引の一つに関係する取引情報を有する取引ファイルを形成するステップと、
各前記複数の口座レコードを前記複数の口座レコードの一つへリンクするステップを備えることを特徴とする方法。
前記複数の団体は、少なくとも一つの本人の団体を含み、前記複数の団体レコードの少なくとも一つは、前記少なくとも一つの本人の団体に関係する情報を有することを特徴とする請求項１１に記載の方法。
前記複数の団体は、少なくとも一つのオーダープレーサーの団体を含み、前記複数の団体レコードの少なくとも一つは、前記少なくとも一つのオーダープレーサーの団体に関係する情報を有することを特徴とする請求項１２に記載の方法。
前記複数の団体は、少なくとも一つの販売員の団体を含み、前記複数の団体レコードの少なくとも一つは、前記少なくとも一つの販売員の団体に関係する情報を有することを特徴とする請求項１３に記載の方法。
前記複数の団体は、少なくとも一つのブッキング会社団体を含み、前記複数の団体レコードの少なくとも一つは、前記少なくとも一つのブッキング会社団体に関係する情報を有することを特徴とする請求項１４に記載の方法。
前記複数の団体は、少なくとも一つの保証人団体を含み、前記方法は、前記複数の団体レコードの少なくとも一つは、前記少なくとも一つの保証人団体に関係する情報を有する前記複数の団体レコードを前記複数の口座レコードの一つにリンクするステップを更に備えたことを特徴とする請求項１５に記載の方法。
システムに格納された複数の取引に関連付けられたリスクを決定する方法であって、
前記システムは複数の団体レコードを有し、各前記複数の口座レコードは複数の団体の一つに関係する団体情報を有し、前記システムは、複数の口座レコードを有する口座ファイルを有し、各前記複数の団体レコードは複数の口座の一つに関係する団体情報を有し、各前記複数の口座レコードは複数の口座の一つに関係する口座情報を有し、各前記複数の口座レコードは前記複数の団体レコードの少なくとも一つへのリンクを含み、前記システムは、前記システムは、複数の取引レコードを有する取引ファイルを有し、前記複数の取引レコードは複数の取引の一つと関係する取引情報を有し、各前記複数の取引レコードは前記複数の口座レコードの一つへのリンクを含み、前記方法は、
前記複数の団体からある団体を選択するステップと、
前記団体に関係した全ての団体を特定するステップと、
これらの前記口座レコードを前記口座ファイルから検索し、どこに前記団体または前記関係した団体が本人であるかを検索するステップと、
前記これらの口座レコードにリンクを張った全ての取引レコードを特定するステップと、前記全ての取引レコードの全ての取引対して総計のリスク開示を決定するステップを備えることを特徴とする方法。
前記これらの口座レコードに関連付けられた全ての保証人を特定するステップと、
前記団体の全ての保証人を特定するステップと、
総計保証人数を決定するステップを更に備え、前記決定するステップは、総計保証人数を考慮して総計のリスク開示を評価するステップを含むことを特徴とする請求項１７に記載の方法。
各前記複数の団体レコードは、他の前記複数の団体レコードで階層関係の存在を指示するために構造関係のフィールドを有し、前記関係した団体は、前記階層関係のフィールドによって特定されることを特徴とする請求項１７に記載の方法。
各前記複数の団体レコードは、他の前記複数の団体レコードで団体関係の存在を指示するための団体関係のフィールドを有し、前記団体関係は、保証人と保証の関係を含み、前記全ての団体の保証人は、前記団体関係のフィールドによって特定されることを特徴とする請求項１８に記載の方法。
取引情報を管理するためにコンピュータを用いる方法であって、
前記コンピュータ上に複数の団体レコードを有する口座ファイルを形成するステップであって、各前記複数の団体レコードは複数の団体の一つに関係する団体情報を有する団体ファイルを形成するステップと、
前記コンピュータ上に複数の口座レコードを有する口座ファイルを形成するステップであって、各前記複数の口座レコードは複数の口座の一つに関係する口座情報を有する口座ファイルを形成するステップと、
各前記複数の口座レコードを前記複数の団体レコードの少なくとも一つにリンクするステップと、
前記コンピュータ上に複数の取引レコードを有する取引ファイルを形成するステップであって、各前記複数の取引レコードは複数の取引の一つに関係する取引情報を有する取引ファイルを形成するステップと、
前記複数の口座レコードの少なくとも一つに各前記複数の取引レコードをリンクするステップを備えることを特徴とする方法。