JP2012238303A - 金銭信託販売支援システム及び金銭信託販売支援方法 - Google Patents

Abstract

【課題】登録金融機関等において金銭信託の販売を支援するための金銭信託販売支援システム及び金銭信託販売支援方法を提供する。
【解決手段】販売銀行において、銀行顧客に対して金銭信託の受益権販売を行ない、信託銀行はこの金銭信託を原資として販売銀行に対して劣後ローンを実行する。この受益権販売時に、ポータルシステム２０の制御部２１は、顧客情報、申込情報の登録処理を行なう。契約管理システム３０は、ポータルシステム２０から顧客データ、申込データを取得し、データ更新処理、残高確定処理を行なう。更に、販社閲覧データを生成し、ポータルシステム２０に還元する。決算日において、契約管理システム３０は、決算対象を抽出し、決済処理を行なう。そして、販売銀行に対して収益金等の送金を行なうとともに、顧客宛振込データ、顧客向け収益金通知を作成し、販売銀行に提供する。
【選択図】図１

Description

本発明は、普通銀行等の登録金融機関や証券会社等の金融商品取引業者（以下、登録金融機関等という）において金銭信託の販売を支援するための金銭信託販売支援システム及び方法に関する。

今日、金融機関において、多様な金融商品が販売されており、信託会社や信託銀行では貸付信託、投資信託、年金信託などの業務を実施している。このうち、金銭で受け入れ、信託終了時に元本と収益を金銭で返還するものを金銭信託という。この金銭信託においては、運用方法を委託者が具体的に指図する「特定金銭信託」、運用方法の種類だけを指示する「指定金銭信託」、運用方法の指示がない「無指定の金銭信託」がある。

また、管理上の分類には、信託財産毎に分別して管理する「単独運用の金銭信託」や、他の信託財産と合わせて運用する「合同運用の金銭信託」があり、合同運用指定金銭信託は多数の投資家から受け入れた資金を合同して運用するため、少額からでも投資が可能な運用形態の一つである。

この金銭信託を管理するためのシステムが検討されている。例えば、複数の独立したローンファンドにおいてそれぞれのファンドに発生する貸倒れの影響を平準化し、安定したリターンを確保した複数ファンドを管理するための金銭信託運用管理方法が検討されている（例えば、特許文献１を参照。）。この文献に記載されたファンド管理システムでは、オートローンファンドの回収金処理を実行する。回収金額が予定金額に不足する場合、ファンド管理システムはオートローンファンドや金銭引当ファンドに対して破綻時処理を実行し、ローンの貸倒れに相当する現金準備金を取り崩す。次に、ファンド管理システムはオートローンファンド決算処理において必要現金準備金を計算する。そして、現金準備金に不足が生じている場合には、オートローンファンドは金銭引当ファンドに対して追加信託の請求処理を行なう。金銭引当ファンドの留保金銭残高で追加信託できない場合は、信販会社に金銭引当ファンドへの追加信託を請求する。

また、従来、機関投資家が投資家層の中心であった金銭債権等の信託受益権を含む運用資産を、個人を含む幅広い投資家層に対して、オープンエンド型合同運用金銭信託等、の信託商品として提供するための金銭信託も検討されている（例えば、特許文献２を参照。）。この文献に記載された金銭信託運用管理システムでは、所定の金利シナリオを用いて資産に関する資産キャッシュフローデータ、信託元本キャッシュフローデータを生成する。次に、生成した資産キャッシュフローデータと信託元本キャッシュフローデータとから信託収支を算出する。算出した信託収支が信託収支許容範囲にある場合は、予定配当率を出力する。信託収支が予め設定された信託収支許容範囲にない場合は、予定配当率許容範囲で予定配当率を変更して信託収支を算出する。そして、信託収支許容範囲にある信託収支を算出できない場合は、アラームを出力する。

一方、投資信託については、複数の投資信託運用会社が提供する複数の投資信託情報を、インターネット回線を介して配信する投信情報の一元管理システムが検討されている（例えば、特許文献３を参照。）。この文献に記載された一元管理システムでは、サーバに投信情報を登録する際、サーバにはその投信情報の配信先を予め登録する。配信先として登録された販売会社や投資家に対して、その投信情報の配信や、投信情報の到着通知を行なう。

また、個々の金融機関の実情に合った銘柄分類を登録することにより、それぞれの金融機関で扱う銘柄分類ごとに証券情報の検索・集計するためのシステムも検討されている（例えば、特許文献４を参照。）。この文献に記載された銘柄分類登録・検索システムでは、投資信託の売買状況や取引履歴などを検索・表示することにより、投資信託の販売管理や顧客毎の収益管理を支援する。

特開２００４−３０３０４号公報（第１頁、図１） 特開２００２−２４５２４１号公報（第１頁、図１） 特開２００２−１４９９７４号公報（第１頁、図１） 特開２００５−３１９８５号公報（第１頁、図１）

２００７年に金融商品取引法が施行され、合同運用指定金銭信託が「みなし有価証券」として扱われることになったため、登録金融機関等の店頭での募集が法的に可能となった。

しかしながら、法律改正以降も、登録金融機関等の多くでは、契約管理システム上の制約から合同運用指定金銭信託の募集が行なわれていない。これは、投資信託の銀行窓口販売が解禁されて以降、投資信託契約管理システムへの投資が大きくなったことに由来する。更に、合同運用指定金銭信託と投資信託とは税制が異なり、投信契約管理システムでは、実務上、合同運用指定金銭信託の販売管理ができない。

一方、銀行や生命保険会社等は経営の健全性の維持・向上に向け、劣後債発行や劣後ローン借入、基金の積み増し等を実施しているところであるが、資金調達先の投資家拡大を図ることで、より安定した資本調達を目指したいとのニーズがある。

本発明は、上記問題点を解決するためになされたものであり、登録金融機関等において金銭信託の販売を支援するための金銭信託販売支援システム及び金銭信託販売支援方法を提供することにある。

上記問題点を解決するために、請求項１に記載の発明は、販売会社において販売された金銭信託を原資として金融機関の健全性維持・向上のための資金調達に資する資産への運用を行ない、この金銭信託の契約管理を行なう金銭信託販売支援システムであって、前記金銭信託販売支援システムは、販売会社端末に接続されるとともに、前記販売会社において販売された商品について、顧客情報又は商品の申込情報からなる商品販売情報を登録する第１データベースを備えたポータルシステムと、前記第１データベースに記録された前記商品販売情報を登録する第２データベースを備えた契約管理システムとから構成され、前記ポータルシステムは、販売会社端末から新規の商品販売情報を取得した場合、前記第１データベースに、更新日をセットした商品販売情報を登録し、前記契約管理システムは、前記第１データベースに登録された商品販売情報を前記第２データベースに登録し、前記ポータルシステムは、販売会社端末から商品販売情報の修正情報を取得した場合、前記第１データベースに記録された商品販売情報の更新日をリセットし、前記契約管理システムは、前記更新日がリセットされた商品販売情報を抽出して、前記第２データベースに修正情報を登録し、前記契約管理システムは、前記第２データベースを用いて、決算時に前記販売会社において販売された商品の元本に基づいて振込金額を算出し、前記商品の各販売顧客に対して振込金額を振り込むための振込情報を作成することを要旨とする。

請求項２に記載の発明は、請求項１に記載の金銭信託販売支援システムにおいて、前記振込金額を振り込むために、前記販売会社に対して、前記振込情報を提供することを要旨とする。

請求項３に記載の発明は請求項１又は２に記載の金銭信託販売支援システムにおいて、前記金銭信託販売支援システムにより販売された金銭信託についてのファンドを管理するファンド管理システムにおいて、前記金融機関の経営の健全性維持・向上のための資金調達に資する資産の実行・返済・利払管理を行なうことを要旨とする。

請求項４に記載の発明は、請求項１〜３のいずれか一つに記載の金銭信託販売支援システムにおいて、前記契約管理システムにおいて、収益金を算出した場合には、前記商品を購入した顧客への振込データを作成し、前記販売会社端末に送信することを要旨とする。

請求項５に記載の発明は、請求項１〜４のいずれか一つに記載の金銭信託販売支援システムにおいて、前記契約管理システムにおいて、収益金を算出した場合には、前記商品を購入した顧客への収益金通知を作成し、送付することを要旨とする。

請求項６に記載の発明は、請求項１〜５のいずれか一つに記載の金銭信託販売支援システムにおいて、商品についての情報種別が設定されたテンプレートが記録されたテンプレート記憶手段を更に備え、前記ポータルシステムは、前記販売会社端末において、テンプレートが指定された場合、前記テンプレートの情報種別について、前記販売会社端末の販売会社において販売された商品販売情報を前記第１データベースから取得し、前記情報種別の消費販売情報をテンプレートに設定して、前記販売会社端末に提供することを要旨とする。

請求項７に記載の発明は、請求項１〜６のいずれか一つに記載の金銭信託販売支援システムにおいて、販売会社において金銭信託を管理するイベントにおいて用いられる帳票のテンプレートが記録された帳票記憶手段を更に備え、前記契約管理システムは、前記販売会社において販売された商品のイベントを特定し、前記イベントで用いられる帳票の作成時期に応じて、前記帳票記憶手段において、帳票のテンプレートを特定し、前記テンプレートに含まれる情報種別について、前記販売会社端末の販売会社において販売された商品販売情報を前記第２データベースから取得し、前記情報種別の消費販売情報をテンプレートに設定して、前記販売会社端末に提供することを要旨とする。

請求項８に記載の発明は、販売会社において販売された金銭信託を原資として金融機関の健全性維持・向上のための資金調達に資する資産への運用を行ない、この金銭信託の契約管理を行なう金銭信託販売支援システムを用いて、金銭信託の販売を支援する方法であって、前記金銭信託販売支援システムは、販売会社端末に接続されるとともに、前記販売会社において販売された商品について、顧客情報又は商品の申込情報からなる商品販売情報を登録する第１データベースを備えたポータルシステムと、前記第１データベースに記録された前記商品販売情報を登録する第２データベースを備えた契約管理システムとから構成され、前記ポータルシステムは、販売会社端末から新規の商品販売情報を取得した場合、前記第１データベースに、更新日をセットした商品販売情報を登録し、前記契約管理システムは、前記第１データベースに登録された商品販売情報を前記第２データベースに登録し、前記ポータルシステムは、販売会社端末から商品販売情報の修正情報を取得した場合、前記第１データベースに記録された商品販売情報の更新日をリセットし、前記契約管理システムは、前記更新日がリセットされた商品販売情報を抽出して、前記第２データベースに修正情報を登録し、前記契約管理システムは、前記第２データベースを用いて、決算時に前記販売会社において販売された商品の元本に基づいて振込金額を算出し、前記商品の各販売顧客に対して振込金額を振り込むための振込情報を作成することを要旨とする。

（作用）
請求項１、８に記載の発明によれば、ポータルシステムは、販売会社端末から新規の商品販売情報を取得した場合、第１データベースに、更新日をセットした商品販売情報を登録する。そして、契約管理システムは、第１データベースに登録された商品販売情報を第２データベースに登録する。また、ポータルシステムは、販売会社端末から商品販売情報の修正情報を取得した場合、第１データベースに記録された商品販売情報の更新日をリセットし、契約管理システムは、更新日がリセットされた商品販売情報を抽出して、第２データベースに修正情報を登録する。そして、契約管理システムは、第２データベースを用いて、決算時に販売会社において販売された商品の元本に基づいて振込金額を算出し、前記商品の各販売顧客に対して振込金額を振り込むための振込情報を作成する。これにより、販売会社は、ポータルシステムに商品販売情報を登録することにより、金銭信託の募集を行なうことができる。

請求項２に記載の発明によれば、契約管理システムは、振込金額を振り込むために、販売会社に対して、振込情報を提供する。これにより、販売会社は、顧客への振込金額を把握することができる。そして、販売会社は、販売顧客の口座に振込金額を振り込むことができる。

請求項３に記載の発明によれば、ファンド管理システムを用いて、資金調達に資する資産の実行・返済・利払管理を行なう。これにより、金融機関は、経営の健全性の維持・向上に資する資金調達ができる。

請求項４に記載の発明によれば、収益金を算出した場合には、商品を購入した顧客への振込データを作成し、販売会社端末に送信する。これにより、販売会社は、収益金の送金負担を軽減することができる。

請求項５に記載の発明によれば、収益金を算出した場合には、商品を購入した顧客への収益金通知を作成し、送付する。これにより、販売会社は、収益金の通知負担を軽減することができる。

請求項６に記載の発明によれば、ポータルシステムは、販売会社端末において、テンプレートが指定された場合、テンプレートの情報種別について、販売会社端末の販売会社において販売された商品販売情報を第１データベースから取得し、情報種別の消費販売情報をテンプレートに設定して、販売会社端末に提供する。これにより、販売者に対して、所望の情報を提供することができる。

請求項７に記載の発明によれば、契約管理システムは、販売会社において販売された商品のイベントを特定し、イベントで用いられる帳票の作成時期に応じて、帳票記憶手段において、帳票のテンプレートを特定する。次に、テンプレートに含まれる情報種別について、販売会社端末の販売会社において販売された商品販売情報を第２データベースから取得する。そして、情報種別の消費販売情報をテンプレートに設定して、販売会社端末に提供する。これにより、販売者に対して、金銭信託を管理する場合も用いる帳票を提供することができる。

本発明によれば、登録金融機関等において金銭信託の販売を支援するための金銭信託販売支援システム及び金銭信託販売支援方法を提供することができる。

本発明の実施形態のシステム概略図。 各データ記憶部に記録されたデータの説明図であって、（ａ）は販社ＤＢ、（ｂ）は商品属性ＤＢ、（ｃ）は利用者ＤＢ、（ｄ）は顧客属性ＤＢ、（ｅ）は申込ＤＢ、（ｆ）は閲覧ＤＢに記録されたデータの説明図。 各データ記憶部に記録されたデータの説明図であって、（ａ）は顧客属性ＤＢ、（ｂ）は取引ＤＢ、（ｃ）は残高ＤＢに記録されたデータの説明図。 本発明の実施形態の処理手順の説明図。 本発明の実施形態の処理手順の説明図。 本発明の実施形態の処理手順の説明図。 本発明の実施形態の処理手順の説明図。 本発明のビジネススキームの説明図。 本発明の他の実施形態の説明図であって、（ａ）はテンプレートＤＢ、（ｂ）は情報提供実績ＤＢ、（ｃ）は処理手順の説明図。 本発明の他の実施形態の説明図であって、（ａ）は時期情報ＤＢ、（ｂ）は必要書類情報ＤＢ、（ｃ）は帳票ＤＢ、（ｄ）は処理手順の説明図。

以下、本発明を具体化した実施形態を図１〜図８に従って説明する。本実施形態では、販売会社である販売銀行（例えば、地方銀行）において、金銭信託の販売を支援する場合に用いる金銭信託販売支援システム及び金銭信託販売支援方法として説明する。

ここでは、図８に示すように、信託銀行Ａと、フィナンシャルグループＢ０との間で、金銭消費貸借契約を締結する。そして、フィナンシャルグループＢ０に属する販売銀行（Ｂ１、Ｂ２）において、銀行顧客に対して金銭信託の受益権販売を行なう。この場合、信託銀行Ａと銀行顧客との間で信託契約を行ない、販売銀行（Ｂ１、Ｂ２）の顧客に対する契約管理（例えば、受益権の配当金管理）を行なう。また、販売銀行（Ｂ１、Ｂ２）は、信託銀行Ａに対して、信託金総額の引渡を行なう。この場合、この信託金の引渡により、合同運用指定金銭信託の設定が行なわれ、信託銀行Ａと銀行顧客との間の信託契約が成立する。この合同運用指定金銭信託においては、フィナンシャルグループＢ０に対して劣後ローンを実行する。すなわち、この劣後ローンが合同運用指定金銭信託の主たる運用資産となる。そして、フィナンシャルグループＢ０においては、この劣後ローンを、自己資本（Ｔｉｅｒ２）調達に利用する。

本実施形態では、図１に示すように、金銭信託販売支援システムとして、ポータルシステム２０、契約管理システム３０を用いる。このネットワークには、信託銀行のクライアント端末１５が接続される。このポータルシステム２０は、契約管理システム３０に接続される。更に、契約管理システム３０は、ファンド管理システム４０に接続される。

クライアント端末１０は、販売銀行の管理者や担当者が用いるコンピュータ端末（販売会社端末）であり、クライアント端末１５は、信託銀行の担当者が用いるコンピュータ端末（信託銀行端末）である。このクライアント端末（１０、１５）は、各利用者がポータルシステム２０にアクセスする場合に用いられる。クライアント端末（１０、１５）は、ネットワークを介してデータを送信する機能や、受信したデータを表示する機能等を有する。このため、このクライアント端末（１０、１５）は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭの他、キーボード、マウス等の入力手段、ディスプレイ等の出力手段、通信手段等を有する。

ポータルシステム２０は、クライアント端末１０から受信したデータに基づいて、販売銀行において取引された金銭信託に関する情報を管理するコンピュータシステムである。ポータルシステム２０は、図１に示すように、制御部２１、販社ＤＢ２２、商品属性ＤＢ２３、利用者ＤＢ２４、顧客属性ＤＢ２５、申込ＤＢ２６、閲覧ＤＢ２７を備える。本実施形態では、顧客属性ＤＢ２５、申込ＤＢ２６が、商品販売情報が記録される第１データベースとして機能する。

制御部２１は、販売銀行における金銭信託の販売を支援するための各種データ処理を行なう制御手段として機能する。この制御部２１は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ等を有し、後述する処理（認証段階、販売支援段階、更新段階の各処理等）を行なう。そのための金銭信託販売支援プログラムを実行することにより、制御部２１は、図１に示すように認証手段２１１、販売支援手段２１２、更新手段２１３として機能する。

認証手段２１１は、ポータルシステム２０へのアクセス者を認証する処理を実行する。
販売支援手段２１２は、金銭信託の受益権に関する商品の販売を支援する処理を実行する。
更新手段２１３は、金銭信託の受益権を購入した顧客の顧客情報や、販売された金銭信託の商品情報を更新する処理を実行する。

販社ＤＢ２２には、図２（ａ）に示すように、金銭信託を販売する販社（ここでは、販売銀行）を管理するための販社管理レコード２２０が記録される。この販社管理レコード２２０は、金銭信託を販売する販社が登録された場合に記録される。販社管理レコード２２０は、グループコード、販社コード、販社名、ドメインに関するデータを含んで構成される。

グループコードデータ領域には、販売銀行が属するフィナンシャルグループを特定するための識別子に関するデータが記録されている。
販社コードデータ領域には、金銭信託を販売する販売銀行を特定するための識別子に関するデータが記録されている。

販社名データ領域には、この販売銀行の金融機関名に関するデータが記録されている。
ドメインデータ領域には、この販売銀行において用いられるクライアント端末１０を特定するための識別子に関するデータが記録されている。本実施形態では、ドメインとしてＩＰアドレスを用いる。

商品属性ＤＢ２３には、図２（ｂ）に示すように、金銭信託の受益権について販売される商品を管理するための商品属性管理レコード２３０が記録される。この商品属性管理レコード２３０は、販売される商品が登録された場合に記録される。商品属性管理レコード２３０は、商品コード、商品名、銘柄属性、販社コードに関するデータを含んで構成される。

商品コードデータ領域には、金銭信託についての商品を特定するための識別子に関するデータが記録されている。
商品名データ領域には、この商品の商品名に関するデータが記録されている。
銘柄属性データ領域には、金銭信託において運用される運用資産に関するデータが記録されている。本実施形態では、フィナンシャルグループに対する劣後ローンを運用資産として用いるため、劣後ローンを提供しているフィナンシャルグループの銘柄コードが記録される。更に、銘柄属性データ領域には、決算日（最終の決算日についての情報を含む。以下同様。）、精算日、顧客支払日、予定利率に関するデータが記録される。ここで、決算日は、この金銭信託の決算日である。精算日は、信託銀行から販売銀行に対して、顧客に支払う償還金総額の送金日（決算日＋Ｎ日）である。顧客支払日は、販売銀行から各顧客に対して配当金を支払う送金日である。予定利率は、この合同運用指定金銭信託の運用により、各顧客の配当金を分配するための利率である。
販社コードデータ領域には、この商品を販売する販売銀行を特定するための識別子に関するデータが記録されている。

利用者ＤＢ２４には、図２（ｃ）に示すように、ポータルシステム２０の利用者を認証するための利用者管理レコード２４０が記録される。この利用者管理レコード２４０は、利用者登録が行なわれた場合に記録される。利用者管理レコード２４０は、利用者コード、パスワード、ドメイン、会社コード、権限、最終使用日時に関するデータを含んで構成される。

利用者コードデータ領域には、各利用者を特定するための識別子に関するデータが記録されている。なお、信託銀行の担当者の利用者コードは、予め登録されている。
パスワードデータ領域には、各利用者を認証するためのデータが記録されている。
ドメインデータ領域には、この利用者がアクセスする場合のドメインを特定するための識別子に関するデータが記録されている。本実施形態では、アクセス者が利用するクライアント端末（１０、１５）のＩＰアドレスが記録されている。

会社コードデータ領域には、この利用者が属する会社（信託銀行、販売銀行）を特定するための識別子に関するデータが記録されている。
権限データ領域には、この利用者の権限を特定するための識別子に関するデータが記録されている。本実施形態では、信託銀行の担当者、販売銀行の管理者、担当者により権限が異なる。信託銀行の担当者は、販社情報や商品属性情報の登録、販売銀行の管理者の登録等を行なうことができる権限が設定される。販売銀行の管理者は、販売銀行の担当者の登録、閲覧ＤＢ２７の閲覧等を行なうことができる権限が設定される。販売銀行の担当者は、顧客属性や申込情報の登録、閲覧ＤＢ２７の閲覧等を行なうことができる権限が設定される。
最終使用日時データ領域には、この利用者が最後にアクセスした年月日及び時刻に関するデータが記録されている。

顧客属性ＤＢ２５には、図２（ｄ）に示すように、販売銀行において金銭信託の受益権を購入した顧客を管理するための顧客属性管理レコード２５０が記録される。この顧客属性管理レコード２５０は、顧客登録が行なわれた場合に記録される。顧客属性管理レコード２５０は、顧客コード、作成日、更新日、削除日、削除区分、顧客属性、確認区分に関するデータを含んで構成される。

顧客コードデータ領域には、各顧客を特定するための識別子に関するデータが記録されている。この顧客コードは、販社コード、支店コード、ＣＩＦコード、販社顧客番号から構成される。販社コード、支店コードは、それぞれ、この顧客を担当する販売銀行や支店を特定するための識別子である。ＣＩＦコードは、この顧客を特定するために、顧客属性を管理する顧客情報ファイル（ＣＩＦ：Customers' Information Files）において用いられる識別子である。販社顧客番号は、販売銀行において、この顧客を特定するために用いられている識別子である。

作成日データ領域には、この顧客属性が登録された年月日に関するデータが記録されている。
更新日データ領域には、この顧客属性が更新された年月日に関するデータが記録されている。

削除日データ領域には、この顧客属性の削除登録が行なわれた年月日に関するデータが記録されている。
削除区分データ領域には、削除処理の要否を特定するための識別子に関するデータが記録されている。

顧客属性データ領域には、この顧客の属性情報（氏名、住所、顧客口座等）に関するデータが記録されている。
確認区分データ領域には、販売銀行における確認の有無を特定するフラグが記録されている。

申込ＤＢ２６には、図２（ｅ）に示すように、金銭信託の受益権に関する商品についての購入申込を管理するための申込管理レコード２６０が記録される。この申込管理レコード２６０は、商品の購入申込の登録が行なわれた場合に記録される。申込管理レコード２６０は、顧客コード、商品コード、受付番号、取引区分、申込日、販社締日、信託締日、申込内容に関するデータを含んで構成される。

顧客コードデータ領域には、金銭信託の受益権の購入を申し込んだ顧客を特定するための識別子に関するデータが記録されている。
商品コードデータ領域には、金銭信託の受益権に関する商品の購入申込があった商品を特定するための識別子に関するデータが記録されている。

受付番号データ領域には、この購入申込を特定するための識別子に関するデータが記録されている。
取引区分データ領域には、この申込についての取引の種別（新規、取消・解約）を特定するための識別子に関するデータが記録されている。ここで、「新規」は、募集期間中における受益権の新規購入を示す。「取消」は、募集期間中における受益権の新規購入の取消を示す。「解約」は、信託設定後における受益権の中途解約を示す。

申込日データ領域には、この商品についての売買契約の申込日（年月日）に関するデータが記録されている。
販社締日データ領域には、販売銀行における締め日（年月日）に関するデータが記録されている。

信託締日データ領域には、信託銀行における締め日（年月日）に関するデータが記録されている。
申込内容データ領域には、受益権の売買契約の内容に関するデータが記録されている。

閲覧ＤＢ２７には、図２（ｆ）に示すように、販売銀行において商品の販売状況を閲覧するための閲覧用データが記録されている。この閲覧用データは、契約管理システム３０から更新情報を取得した場合に記録される。この閲覧用データは、残高管理レコード２７１と異動管理レコード２７２とから構成されている。

残高管理レコード２７１は、顧客コード、商品コード、契約番号、処理基準日、残高に関するデータを含んで構成される。
顧客コードデータ領域には、各顧客を特定するための識別子に関するデータが記録されている。

商品コードデータ領域には、この顧客が購入した商品（金銭信託の受益権に関する商品）を特定するための識別子に関するデータが記録されている。
契約番号データ領域には、この顧客との契約を特定するための識別子に関するデータが記録されている。

処理基準日データ領域には、この商品について発生する異動（中途解約や償還）による残高の変動処理が行われた年月日に関するデータが記録されている。
残高データ領域には、金銭信託の残高に関するデータが記録されている。

異動管理レコード２７２は、顧客コード、商品コード、契約番号、受付番号、取引区分、異動日、異動金額に関するデータを含んで構成される。
顧客コードデータ領域には、各顧客を特定するための識別子に関するデータが記録されている。
商品コードデータ領域には、内容の異動があった商品を特定するための識別子に関するデータが記録されている。

契約番号データ領域には、この顧客との契約を特定するための識別子に関するデータが記録されている。
受付番号データ領域には、この購入申込を特定するための識別子に関するデータが記録されている。
取引区分データ領域には、各取引の種別を特定するための識別子に関するデータが記録されている。
異動日データ領域には、異動が行なわれた年月日に関するデータが記録されている。
異動金額データ領域には、異動された金額に関するデータが記録されている。

契約管理システム３０は、各販売銀行において販売された金銭信託についての契約管理を行なうコンピュータシステムである。この契約管理システム３０は、図１に示すように、制御部３１、顧客属性ＤＢ３２、取引ＤＢ３３、残高ＤＢ３４を備える。本実施形態では、顧客属性ＤＢ３２、取引ＤＢ３３が、商品販売情報が記録される第２データベースとして機能する。

制御部３１は、金銭信託における契約管理のための各種データ処理を行なう制御手段として機能する。この制御部３１は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ等を有し、後述する処理（情報更新段階、取引管理段階、閲覧管理段階、決算管理段階の各処理等）を行なう。そのための金銭信託管理プログラムを実行することにより、制御部３１は、図１に示すように情報更新手段３１１、取引管理手段３１２、閲覧管理手段３１３、決算管理手段３１４として機能する。

情報更新手段３１１は、ポータルシステム２０から顧客情報や申込情報を取得し、顧客情報や取引情報を更新する処理を実行する。
取引管理手段３１２は、取引情報に基づいて残高等を更新する処理を実行する。
閲覧管理手段３１３は、閲覧用データを生成し、ポータルシステム２０に供給する処理を実行する。
決算管理手段３１４は、金銭信託の決算処理を実行する。

顧客属性ＤＢ３２には、図３（ａ）に示すように、販売銀行において金銭信託の受益権を購入した顧客を管理するための顧客属性管理レコード３２０が記録される。この顧客属性管理レコード３２０は、顧客登録が行なわれた場合に記録される。顧客属性管理レコード３２０は、顧客属性管理レコード２５０に記録された顧客コード、作成日、更新日、削除日、削除区分、顧客属性に関するデータを含んで構成される。

取引ＤＢ３３には、図３（ｂ）に示すように、金銭信託の受益権に関する商品についての購入申込を管理するための取引管理レコード３３０が記録される。この取引管理レコード３３０は、商品の購入申込の登録が行なわれた場合に記録される。取引管理レコード３３０は、申込管理レコード２６０に記録された顧客コード、商品コード、取引区分、申込内容の他に、販社コード、申込日、入力日、取引日に関するデータを含んで構成される。

販社コードデータ領域には、この商品を販売する販売銀行を特定するための識別子に関するデータが記録されている。
申込日、入力日、取引日の各データ領域には、この商品について購入申込日、取引情報の入力日、取引日（年月日）に関するデータが記録されている。

残高ＤＢ３４には、図３（ｃ）に示すように、販売銀行において販売された受益権の残高を管理するための残高管理レコード３４０が記録される。この残高管理レコード３４０は、商品の購入申込の登録が行なわれた場合に記録される。残高管理レコード３４０は、残高管理レコード２７１に記録された顧客コード、商品コード、契約番号、処理基準日、残高に関するデータを含んで構成される。

ファンド管理システム４０は、金銭信託されたファンドの資産運用を管理するコンピュータシステムである。このファンド管理システム４０は、後述するように、劣後ローンの実行、利払い、元本返済の管理や、銀行顧客に対する配当金、償還金の管理処理を行なう。

次に、本願発明のビジネススキームにける金銭信託の管理を、図４〜図７を用いて説明する。
まず、信託銀行とフィナンシャルグループとの間でファンドの組成条件決定が行なわれる。この場合、後述するように、ファンド管理システム４０においてファンドに係る諸条件の登録処理を実行する（ステップＳ０−１）。

次に、ファンド管理システム４０において、フィナンシャルグループに対して劣後ローンの提供処理を実行する（ステップＳ０−２）。この劣後ローンは、合同運用指定金銭信託の主な運用資産となる。
このような合同運用指定金銭信託の受益権販売のために、以下の情報処理を行なう。

（信託銀行における登録処理）
次に、信託銀行における登録処理について説明する。
まず、信託銀行の担当者は、クライアント端末１５を用いて、ポータルシステム２０にアクセスする（ステップＳ１−１）。

この場合、ポータルシステム２０の制御部２１は、ログイン認証処理を実行する（ステップＳ１−２）。具体的には、制御部２１の認証手段２１１は、クライアント端末１５のディスプレイにログイン画面を出力する。このログイン画面には、利用者の利用者コード及びパスワードを入力する入力欄が設けられている。入力欄に利用者コードを入力して、ログイン実行ボタンが選択された場合、認証手段２１１は、クライアント端末１５から、ＩＰアドレス及びログイン画面に入力された利用者コードを取得する。そして、認証手段２１１は、取得した利用者コード及びＩＰアドレスが登録された利用者管理レコード２４０を、利用者ＤＢ２４を用いて検索する。

クライアント端末１５から取得した利用者コード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できなかった場合にはアクセスを拒否する。一方、利用者コード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できた場合には、アクセスを許可する。ここでは、利用者管理レコード２４０において、信託銀行の担当者の権限を特定する。

次に、ポータルシステム２０の制御部２１は、販社登録処理を実行する（ステップＳ１−３）。具体的には、制御部２１の販売支援手段２１２は、クライアント端末１０のディスプレイに信託銀行メニュー画面を出力する。この信託銀行メニュー画面には、販社登録ボタンや、商品登録ボタンが含まれる。販社登録ボタンが選択された場合、クライアント端末１５のディスプレイに、金銭信託に関する商品を販売する販社情報登録画面を出力する。この販社情報登録画面には、金銭信託に関する商品を販売する販売銀行に関する情報（グループコード、販社コード、販社名）や、この販売銀行において利用者情報（クライアント端末１０のドメイン、管理者の利用者コード、権限）の入力欄が設けられている。

そして、販社情報登録画面において、各入力欄における入力を完了した場合、販売支援手段２１２は、販社管理レコード２２０を生成し、販社ＤＢ２２に記録する。更に、販売支援手段２１２は、利用者管理レコード２４０を生成し、利用者ＤＢ２４に登録する。

次に、ポータルシステム２０の制御部２１は、商品登録処理を実行する（ステップＳ１−４）。登録支援画面において、商品登録ボタンが選択された場合、クライアント端末１５のディスプレイに、金銭信託に関する商品の商品情報登録画面を出力する。この商品情報登録画面には、金銭信託に関する商品に関する情報（商品コード、商品名、銘柄属性、商品コード）の入力欄が設けられている。商品情報登録画面において、各入力欄における入力を完了した場合、販売支援手段２１２は、商品属性管理レコード２３０を生成し、商品属性ＤＢ２３に記録する。

（販売銀行における登録処理）
次に、販売銀行における登録処理について説明する。
まず、販売銀行の管理者は、クライアント端末１０を用いて、ポータルシステム２０にアクセスする（ステップＳ２−１）。

この場合、ポータルシステム２０の制御部２１は、ステップＳ１−２と同様に、ログイン認証処理を実行する（ステップＳ２−２）。ここで、クライアント端末１０から取得した利用者コード、パスワード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できなかった場合にはアクセスを拒否する。一方、利用者コード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できた場合には、アクセスを許可する。ここでは、利用者管理レコード２４０において、販売銀行の管理者の権限を特定する。

次に、ポータルシステム２０の制御部２１は、利用者登録処理を実行する（ステップＳ２−３）。具体的には、制御部２１の販売支援手段２１２は、クライアント端末１０のディスプレイに、販社管理者メニュー画面を出力する。この販社管理者メニュー画面には、利用者登録ボタンや、締め入力ボタンが含まれる。利用者登録ボタンが選択された場合、クライアント端末１０のディスプレイに、利用者登録画面を出力する。この利用者登録画面には、販売銀行において受益権の購入者の顧客属性および申込内容の登録を行なう担当者に関する情報や、この販売銀行において利用されるクライアント端末１０のドメインの入力欄が設けられている。そして、利用者登録画面において、各入力欄における入力を完了した場合、販売支援手段２１２は、利用者管理レコード２４０を生成し、利用者ＤＢ２４に登録する。

（受益権販売処理）
次に、図５を用いて受益権販売処理について説明する。販売銀行において、金銭信託の受益権を販売する場合、購入者（銀行顧客）の顧客属性の登録及び申込内容の登録を行なう。

販売銀行の担当者が顧客属性情報を登録する場合、クライアント端末１０を用いて、ポータルシステム２０にアクセスする（ステップＳ３−１）。
この場合、ポータルシステム２０の制御部２１は、ステップＳ１−２と同様に、ログイン認証処理を実行する（ステップＳ３−２）。ここでは、クライアント端末１０から取得した利用者コード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できなかった場合にはアクセスを拒否する。一方、利用者コード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できた場合には、アクセスを許可する。ここでは、利用者管理レコード２４０において、販売銀行の担当者の権限を特定する。

次に、ポータルシステム２０の制御部２１は、顧客情報登録処理を実行する（ステップＳ３−３）。具体的には、制御部２１の販売支援手段２１２は、クライアント端末１０のディスプレイに販社担当者メニュー画面を出力する。この販社担当者メニュー画面には、顧客情報登録ボタンや、申込登録ボタンが含まれる。顧客情報登録ボタンが選択された場合、クライアント端末１０のディスプレイに、顧客情報登録画面を出力する。この場合、販売銀行の担当者は、金銭信託の受益権に関する商品を購入する顧客の情報を入力する。入力を完了した場合、販売支援手段２１２は、クライアント端末１０から顧客情報を取得し、顧客属性管理レコード２５０を生成し、顧客属性ＤＢ２５に登録する。この場合、販売支援手段２１２は、顧客属性管理レコード２５０において、作成日、更新日＝「ＮＵＬＬ」、削除区分＝「ＯＦＦ」に設定する。

なお、ここで、顧客属性情報の更新や削除も可能である。顧客属性情報の更新の場合には、顧客コードを用いて、顧客属性管理レコード２５０を特定し、顧客属性を修正する。この場合、販売支援手段２１２は、顧客属性管理レコード２５０において更新日＝「ＮＵＬＬ」に設定する。顧客属性情報の削除の場合には、顧客コードを用いて、顧客属性管理レコード２５０を特定し、削除区分＝「ＯＮ」に設定する。

次に、ポータルシステム２０の制御部２１は、申込登録処理を実行する（ステップＳ３−４）。具体的には、クライアント端末１０において、申込登録ボタンが選択された場合、制御部２１の販売支援手段２１２は、商品属性ＤＢ２３から、この販売銀行の販社コードが記録された商品属性管理レコード２３０を抽出する。そして、販売支援手段２１２は、申込登録画面をクライアント端末１０のディスプレイに出力する。この申込登録画面には、取得した商品属性管理レコード２３０に記録された商品コードの選択欄及び申込金額の入力欄が設けられている。申込登録画面において、この顧客に対して販売した商品（金銭信託）について各入力欄における入力を完了した場合、販売支援手段２１２は、顧客コード、商品コードに対して受付番号を付与した申込管理レコード２６０を生成し、申込ＤＢ２６に記録する。この場合、販売支援手段２１２は、システムタイマから本日日付を取得し、申込管理レコード２６０の申込日データ領域に本日日付を記録する。この場合、販社締日及び信託締日は「ＮＵＬＬ」に設定する。新規購入の場合には、取引区分データ領域に「新規」を特定するための識別子を記録する。なお、顧客との取引においては、受付番号や契約番号を指定して、新規購入の取消や解約の登録を行なうことも可能である。新規購入の取消を行なう場合には「取消」、中途解約の場合には「解約」を特定するための識別子を取引区分データ領域に記録する。

（契約管理システムへの反映処理）
次に、図６を用いて契約管理システムへの反映処理について説明する。
販売銀行において、締め時刻になった場合、クライアント端末１０を用いて、ポータルシステム２０にアクセスする（ステップＳ４−１）。

この場合、ポータルシステム２０の制御部２１は、ステップＳ１−２と同様に、ログイン認証処理を実行する（ステップＳ４−２）。ここで、クライアント端末１０から取得した利用者コード、パスワード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できなかった場合にはアクセスを拒否する。一方、利用者コード及びＩＰアドレスが登録された利用者管理レコード２４０を抽出できた場合には、アクセスを許可する。ここでは、利用者管理レコード２４０において、販売銀行の管理者の権限を特定する。

そして、販売銀行の管理者は、クライアント端末１０を用いて締め入力処理を実行する。具体的には、制御部２１の販売支援手段２１２は、クライアント端末１５のディスプレイに、販社管理者メニュー画面を出力する。ここで、締め入力ボタンが選択された場合、クライアント端末１０は、ポータルシステム２０は、締め要求を送信する。

この場合、ポータルシステム２０の制御部２１は、未完情報の取得処理を実行する（ステップＳ４−３）。具体的には、制御部２１の販売支援手段２１２は、顧客属性ＤＢ２５から、顧客属性管理レコード２５０の確認区分データ領域に完了フラグが記録されていない顧客属性管理レコード２５０を抽出する。

更に、販売支援手段２１２は、申込ＤＢ２６から、以下の申込管理レコード２６０を抽出する。
・新規レコード、取消レコード：販社締日＝「ＮＵＬＬ」

そして、ポータルシステム２０の制御部２１は、申込一覧確認処理を実行する（ステップＳ４−４）。具体的には、制御部２１の販売支援手段２１２は、取得した未完情報を一覧表示させた申込確認画面を生成し、クライアント端末１０のディスプレイに、申込確認画面を出力する。販売銀行の管理者は、申込確認画面の内容を確認する。クライアント端末１０において確認入力が行なわれた場合、販売支援手段２１２は、確認された顧客属性管理レコード２５０の確認区分データ領域に完了フラグを記録する。更に、販売支援手段２１２は、システムタイマから本日日付を取得し、確認された申込管理レコード２６０の販社締日データ領域に本日日付を記録する。
申込確認画面において、申込内容の確認入力が行なわれた場合、ポータルシステム２０の制御部２１は、通知処理を実行する（ステップＳ４−５）。具体的には、制御部２１の販売支援手段２１２は、申込内容の通知書を作成し、クライアント端末１５に送信する。この通知書には、申込ＤＢ２６から抽出した申込管理レコード２６０の情報を含める。

ポータルシステム２０の制御部２１は、完了記録処理を実行する（ステップＳ４−６）。具体的には、信託銀行の締め入力が行なわれた場合、制御部２１の販売支援手段２１２は、顧客属性ＤＢ２５から、以下の顧客属性管理レコード２５０を抽出する。
・新規レコード：削除区分＝「ＯＦＦ」、作成日＝「ＮＵＬＬ」、更新日＝「ＮＵＬＬ」
・更新レコード：削除区分＝「ＯＦＦ」、作成日≠「ＮＵＬＬ」、更新日＝「ＮＵＬＬ」
・削除レコード：削除区分＝「ＯＮ」、削除日＝「ＮＵＬＬ」

そして、販売支援手段２１２は、システムタイマから本日日付を取得する。そして、販売支援手段２１２は、新規レコードについては、顧客属性管理レコード２５０の作成日、更新日の各データ領域に本日日付を設定する。また、新規レコードについては、顧客属性管理レコード２５０の更新日データ領域に本日日付を設定する。削除レコードについては、顧客属性管理レコード２５０の削除日データ領域に本日日付を設定する。

更に、販売支援手段２１２は、申込ＤＢ２６から、以下の申込管理レコード２６０を抽出する。
・新規レコード、取消レコード：販社締日≠「ＮＵＬＬ」、信託締日＝「ＮＵＬＬ」
そして、販売支援手段２１２は、抽出した申込管理レコード２６０の信託締日データ領域に本日日付を記録する。

次に、契約管理システム３０における処理を説明する。この処理は、信託銀行の締め入力後の業後にかけて行なわれる。
ここでは、契約管理システム３０の制御部３１は、顧客データ取得処理を実行する（ステップＳ５−１）。具体的には、制御部３１の情報更新手段３１１は、ポータルシステム２０の顧客属性ＤＢ２５にアクセスする。そして、情報更新手段３１１は、顧客属性ＤＢ２５から、以下の顧客属性管理レコード２５０を抽出する。
・新規レコード：作成日＝本日日付
・更新レコード：更新日＝本日日付
・削除レコード：削除日＝本日日付

次に、契約管理システム３０の制御部３１は、申込データ取得処理を実行する（ステップＳ５−２）。具体的には、制御部３１の情報更新手段３１１は、ポータルシステム２０の申込ＤＢ２６にアクセスする。そして、情報更新手段３１１は、申込ＤＢ２６から、以下の申込管理レコード２６０を抽出する。
・新規レコード、取消レコード：信託締日＝本日日付

次に、契約管理システム３０の制御部３１は、顧客データ更新処理を実行する（ステップＳ５−３）。具体的には、制御部３１の情報更新手段３１１は、新規及び更新の顧客属性管理レコード２５０に基づいて、顧客属性管理レコード３２０の作成または更新を行う。削除レコードについては、更新処理を行なわず処理結果明細に出力のみ行ない、オペレータ作業で対応する。

次に、契約管理システム３０の制御部３１は、取引データ更新処理を実行する（ステップＳ５−４）。具体的には、制御部３１の情報更新手段３１１は、取得した申込管理レコード２６０に基づいて、取引管理レコード３３０の更新を行なう。

次に、契約管理システム３０の制御部３１は、残高確定処理を実行する（ステップＳ５−５）。具体的には、制御部３１の取引管理手段３１２は、更新された取引管理レコード３３０の取引日が当日に該当するレコードに基づいて、顧客コード、商品コード、契約番号が一致する残高管理レコード３４０を残高ＤＢ３４において特定し、この残高管理レコード３４０に記録された残高を更新する。

次に、契約管理システム３０の制御部３１は、販社閲覧データ生成処理を実行する（ステップＳ５−６）。具体的には、制御部３１の閲覧管理手段３１３は、更新された取引管理レコード３３０に基づいて、閲覧用データ（残高管理レコード２７１、異動管理レコード２７２）を生成する。

次に、契約管理システム３０の制御部３１は、データ還元処理を実行する（ステップＳ５−７）。具体的には、制御部３１の閲覧管理手段３１３は、ポータルシステム２０にアクセスし、閲覧ＤＢ２７に、生成した残高管理レコード２７１、異動管理レコード２７２を登録する。

（決算関連の処理）
次に、図７を用いて、決算関連の処理を説明する。ここでは、通常の決算日においては収益金、最終の決算日においては、収益金の他に償還された元本についての処理が行なわれる。

まず、決算日において、契約管理システム３０の制御部３１は、決算対象抽出処理を実行する（ステップＳ６−１）。具体的には、制御部３１の決算管理手段３１４は、商品属性ＤＢ２３に記録された銘柄属性に基づいて、当日が決算日に該当する商品属性管理レコード２３０を抽出する。この商品属性管理レコード２３０により決算対象商品が特定される。

次に、契約管理システム３０の制御部３１は、決算処理を実行する（ステップＳ６−２）。具体的には、制御部３１の決算管理手段３１４は、特定した決算対象商品の商品コードが記録された取引管理レコード３３０を取引ＤＢ３３から抽出する。次に、決算管理手段３１４は、この顧客における金銭信託の残高を残高ＤＢ３４から取得する。そして、決算管理手段３１４は、商品属性ＤＢ２３からこの金銭信託の予定利率を取得し、銀行顧客毎に、残高と予定利率とを用いて配当金を算出する。

次に、契約管理システム３０の制御部３１は、異動連絡表作成処理を実行する（ステップＳ６−３）。具体的には、制御部３１の決算管理手段３１４は、販売銀行毎に決算対象商品の金銭信託の総計を記録した異動連絡表を作成する。そして、決算管理手段３１４は、作成した異動連絡表をファンド管理システム４０に供給する。この異動連絡表は、後述するように、ファンド管理システム４０において実行されるファンド管理処理において用いられる。

次に、契約管理システム３０の制御部３１は、販社向け収益金通知の作成処理を実行する（ステップＳ６−４）。具体的には、制御部３１の決算管理手段３１４は、販売銀行毎に、販社向け収益金通知を作成する。ここでは、この販売銀行において決算対象商品を購入した銀行顧客に分配する配当・償還金の総額を算出する。そして、この総額に関する情報を販社向け収益金通知に含める。

次に、契約管理システム３０の制御部３１は、顧客宛振込データ、顧客向け収益金通知の作成処理を実行する（ステップＳ６−５）。具体的には、制御部３１の決算管理手段３１４は、販売銀行毎に、顧客の口座に配当金を振り込むための振込データを生成する。この場合、決算管理手段３１４は、顧客属性ＤＢ３２から、決算対象商品を購入した顧客の顧客口座情報を取得する。そして、決算管理手段３１４は、販売銀行毎に、各顧客口座に、配当・償還金額を振り込むための振込データを生成する。更に、決算管理手段３１４は、各顧客に対する収益金通知書を作成する。

次に、契約管理システム３０の制御部３１は、顧客宛振込データ、顧客向け収益金通知の提供処理を実行する（ステップＳ６−６）。具体的には、制御部３１の決算管理手段３１４は、作成した振込データを、販売銀行のクライアント端末１０に提供するために、ポータルシステム２０に格納する。そして、販売会社が振込金額を振り込む場合には、販売銀行の担当者は、ポータルシステム２０から取得した顧客宛振込データを用いて各顧客口座に送金する。

（ファンド管理）
次に、図７を用いて、ファンド管理について説明する。このファンド管理は、劣後ローン単位で実行されるが、その方法は公知の金銭信託ファンドの管理と同様である。

まず、信託銀行とフィナンシャルグループとの間でファンドの組成条件が決定した後、ファンド管理システム４０は、ファンド登録処理を実行する（ステップＳ７−１）。具体的には、ファンド管理システム４０は、劣後ローンのファンドの管理するための情報（信託期間、予定利率、償還金の取扱等の情報）を登録する。

次に、ファンド管理システム４０は、運用資産登録処理を実行する（ステップＳ７−２）。具体的には、ファンド管理システム４０は、金銭信託の運用資産の情報（劣後ローンを提供するフィナンシャルグループ、劣後ローンの条件等の情報）を登録する。

次に、ファンド管理システム４０は、元本登録処理を実行する（ステップＳ７−３）。具体的には、ファンド管理システム４０は、販売された受益権の金額に基づいて、金銭信託ファンドの元本を登録する。

次に、ファンド管理システム４０は、劣後ローンの実行（購入）処理を実行する（ステップＳ７−４）。具体的には、ファンド管理システム４０は、販売銀行に対して劣後ローンを実行する。

次に、ファンド管理システム４０は、利金入金処理を実行する（ステップＳ７−５）。具体的には、ファンド管理システム４０は、劣後ローンの利払い、元本返済の管理を実行する。

そして、決算日に到達した場合には、ファンド管理システム４０は、ファンド決算処理を実行する（ステップＳ７−６）。具体的には、ファンド管理システム４０は、信託報酬の計算処理、収益金の計算処理を実行する。

次に、決算日からＮ日経過後の精算日が到来した場合には、ファンド管理システム４０は、配当金払出処理を実行する（ステップＳ７−７）。具体的には、ファンド管理システム４０は、契約管理システム３０から取得した異動連絡表に基づいて、配当金の払い出しを行なう。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）上記実施形態では、販売銀行において、銀行顧客に対して金銭信託の受益権販売を行なう。この場合、信託銀行Ａは、この信託金により、合同運用指定金銭信託の設定を行なう。この合同運用指定金銭信託においては、フィナンシャルグループに対して劣後ローンを実行する。すなわち、この劣後ローンが合同運用指定金銭信託の主たる運用資産となる。フィナンシャルグループにおいては、この劣後ローンを、金融機関の経営の健全性維持・向上のために、自己資本（Ｔｉｅｒ２）調達に利用することができる。関与者が多く高コスト（クーポン、引受手数料、社管手数料、諸経費）になりがちな劣後債発行に対して、金銭信託からの劣後ローン調達という単純な形態を取ることにより、コストを低減できる可能性がある。

（２）上記実施形態では、ポータルシステム２０において、販売銀行のクライアント端末１０から、受益権の購入者（銀行顧客）や、受益権購入の申込情報を取得する。そして、ポータルシステム２０に記録された顧客属性情報や申込情報を、契約管理システム３０が取り込んで、各顧客との金銭信託契約を管理する。これにより、ポータルシステム２０に、受益権の販売情報を登録することで、販売銀行は、金銭信託の募集を行なうことができる。従って、販売銀行において、信託商品の管理システムを構築する必要がない。

（３）上記実施形態では、顧客属性ＤＢ２５には、販売銀行において金銭信託の受益権を購入した顧客を管理するための顧客属性管理レコード２５０が記録される。顧客属性管理レコード２５０は、顧客コード、作成日、更新日、削除日、削除区分、顧客属性、確認区分に関するデータを含んで構成される。更に、申込ＤＢ２６には、金銭信託の受益権に関する商品についての購入申込を管理するための申込管理レコード２６０が記録される。申込管理レコード２６０は、顧客コード、商品コード、受付番号、取引区分、申込日、販社締日、信託締日、申込内容に関するデータを含んで構成される。これにより、契約管理システム３０は、新に登録された顧客属性情報や申込情報を特定し、取引ＤＢ３３に反映させることができる。そして、この取引ＤＢ３３を用いて、契約管理システム３０において契約管理を行なうことができる。

なお、上記実施形態は、以下の態様に変更してもよい。
・ 上記実施形態では、販売会社である販売銀行（例えば、地方銀行）において、金銭信託の販売を支援する場合を想定したが、販売会社は地方銀行に限定されるものではない。

・ 上記実施形態では、信託銀行と、フィナンシャルグループとの間で、金銭消費貸借契約を締結する。この場合、金銭消費貸借契約を締結先はフィナンシャルグループに限定されるものではない。例えば、単独の販売会社と金銭消費貸借契約を締結するようにしてもよい。

・ 上記実施形態では、金銭信託の資産運用を劣後ローンと想定したが、金融機関の経営の健全性維持・向上のための資産運用は劣後ローンに限定されるものではない。例えば、生命保険会社への基金拠出等も考えられる。

・ 上記実施形態では、顧客属性ＤＢ２５に記録された顧客属性管理レコード２５０の作成日、更新日、削除日、削除区分を用いて、契約管理システム３０に取り込む顧客データを特定する。また、申込ＤＢ２６に記録されている申込管理レコード２６０の信託締日を用いて、契約管理システム３０に取り込む申込データを特定する。取り込むデータの特定方法は、作成日、更新日、削除日、削除区分を用いる場合に限定されるものではない。

・ 上記実施形態では、販売銀行のクライアント端末１０から顧客属性情報や申込情報を取得する。ここで、クライアント端末１０に代えて、販売銀行の販売管理サーバから取得するようにしてもよい。この場合には、販売銀行の担当者は、クライアント端末１０を用いて顧客属性情報や申込情報を販売管理サーバに登録する。そして、販売管理サーバはポータルシステム２０に顧客属性情報や申込情報を定期的に送信する。

・ 上記実施形態では、契約管理システム３０は、ファンド管理システム４０に接続される。これに代えて、契約管理システム３０により、販売された金銭信託についてのファンドを管理することができれば、手入力や所定の記録媒体を用いて入力することも可能である。

・ 上記実施形態では、ポータルシステム２０に閲覧ＤＢ２７を設ける。この閲覧ＤＢ２７は、販売銀行において商品の販売状況を閲覧するための閲覧用データが記録されている。これに加えて、各販売銀行において、金銭信託を管理するために用いる多様な情報を提供するようにしてもよい。この場合には、ポータルシステム２０に、テンプレートＤＢ（テンプレート記憶手段）や情報提供実績ＤＢを設ける。

図９（ａ）に示すように、テンプレートＤＢには、テンプレート識別子に関連付けて各種テンプレートを登録しておく。
テンプレート識別子データ領域には、各テンプレートを特定するための識別子に関するデータを記録する。

テンプレートデータ領域には、販売銀行が希望する情報を含めたレポートを作成するためのテンプレートが記録される。このテンプレートには、販売銀行に対して提供する各種情報を特定するための情報種別に関するデータを記録しておく。

図９（ｂ）に示すように、情報提供実績ＤＢには、テンプレートの利用実績に関する情報を記録する。このテンプレート利用実績情報は、販売銀行に対してテンプレートを利用して情報を提供した場合に記録される。テンプレート利用実績情報は、販社コード、利用時期、テンプレート識別子に関するデータを含める。

販社コードデータ領域には、テンプレートを利用した販売銀行を特定するための識別子（販社コード）に関するデータを記録する。
利用時期データ領域には、このテンプレートが利用された年月日に関するデータを記録する。
テンプレート識別子データ領域には、利用されたテンプレートを特定するための識別子に関するデータを記録する。

そして、ポータルシステム２０の制御部２１は、図９（ｃ）に示す情報出力処理を実行する。ここでは、販売銀行が情報をダウンロードする場合には、クライアント端末１０を用いて、ポータルシステム２０にアクセスする。

この場合、ポータルシステム２０の制御部２１は、ステップＳ３−２と同様に、ログイン認証処理を実行する（ステップＳ８−１）。このログイン認証により、アクセス者の販社コードを特定する。

次に、ポータルシステム２０の制御部２１は、テンプレート利用状況の特定処理を実行する（ステップＳ８−２）。具体的には、制御部２１の情報提供手段は、特定した販社コードが記録されたテンプレート利用実績情報を情報提供実績ＤＢから取得する。更に、制御部２１の情報提供手段は、テンプレート利用実績情報を用いて、テンプレートの利用頻度（所定期間の利用回数）を算出する。例えば、直近から予め定められた基準期間に利用時期が含まれる利用実績の回数を算出する。

次に、ポータルシステム２０の制御部２１は、利用状況に応じてテンプレートの並び替え処理を実行する（ステップＳ８−３）。具体的には、制御部２１の情報提供手段は、利用頻度が高い順番にテンプレート識別子を並べたテンプレート一覧リストを作成する。

次に、ポータルシステム２０の制御部２１は、テンプレート候補の出力処理を実行する（ステップＳ８−４）。具体的には、制御部２１の情報提供手段は、クライアント端末１０のディスプレイに、テンプレート一覧リストを含めて情報ダウンロード画面を出力する。この場合、担当者は、クライアント端末１０において、ディスプレイに表示されたテンプレート一覧リストの中で所望のテンプレートを選択する。更に、情報ダウンロード画面において、このテンプレートを用いて情報取得を希望する金銭信託のキー項目を入力する。このキー項目には、商品コード、顧客コード、申込日等の日付基準、残高・申込額等の金額基準等や、これらの組み合わせを用いることができる。

そして、情報ダウンロード画面において完了入力が行なわれた場合、ポータルシステム２０の制御部２１は、テンプレートの指定情報の取得処理を実行する（ステップＳ８−５）。具体的には、制御部２１の情報提供手段は、クライアント端末１０において選択されたテンプレート識別子やキー項目に関するデータを取得する。

次に、ポータルシステム２０の制御部２１は、テンプレートを用いてレポート作成処理を実行する（ステップＳ８−６）。具体的には、制御部２１の情報提供手段は、指定されたテンプレートをテンプレートＤＢから取得する。そして、制御部２１の情報提供手段は、ログイン認証により特定した販社コードに関連付けられ、指定されたキー項目によって抽出した金銭信託の管理情報であって、このテンプレートにおいて設定されている情報種別に対応した情報を、ポータルシステム２０の各ＤＢから取得する。そして、制御部２１の情報提供手段は、取得した情報をテンプレートにインポートすることにより、販売銀行に情報を提供するためのレポートを作成する。

次に、ポータルシステム２０の制御部２１は、レポートの出力処理を実行する（ステップＳ８−７）。具体的には、制御部２１の情報提供手段は、作成したレポートをクライアント端末１０に送信する。これにより、販売銀行は、テンプレートを用いて各種情報を、効率的にダウンロードすることができる。

・ 上記実施形態では、ポータルシステム２０に、商品の販売状況を提供するための閲覧ＤＢ２７を設ける。これに加えて、各販売銀行において、金銭信託を管理するための必要な各種帳票を提供するようにしてもよい。この場合には、契約管理システム３０に、時期情報ＤＢ、必要書類情報ＤＢ（帳票記憶手段）、帳票ＤＢを設ける。

図１０（ａ）に示すように、時期情報ＤＢには、各販売銀行で販売された金銭信託のイベント時期を特定するためのイベント時期管理レコードが記録されている。このイベント時期管理レコードには、販社コード、商品コード、イベント種別、帳票作成時期に関するデータが記録される。

販社コードデータ領域には、各販売銀行を特定するための識別子に関するデータが記録される。
商品コードデータ領域には、この販売銀行において販売された金銭信託を特定するための識別子（商品コード）に関するデータが記録される。

イベント種別データ領域には、この販売銀行において販売した金銭信託についてのイベントの種類（決算期や償還期）を特定するための識別子に関するデータが記録される。
帳票作成時期データ領域には、このイベントの時期に対応して帳票を作成する時期を特定するための年月日に関するデータが記録される。例えば、決算日に対して、所定日数だけ前後の日付を登録しておく。

図１０（ｂ）に示すように、必要書類情報ＤＢには、各イベントにおいて必要な帳票に関する必要書類管理レコードが記録される。この必要書類管理レコードには、イベント種別、帳票種別、テンプレートに関するデータが記録される。

イベント種別データ領域には、各販売銀行において販売された金銭信託のイベントの種類を特定するための識別子に関するデータが記録される。
帳票種別データ領域には、このイベントにおいて必要な書類を特定するための識別子に関するデータが記録される。

テンプレートデータ領域には、販売銀行が使用する各種帳票のテンプレートが記録される。このテンプレートには、帳票作成に必要な各種情報を特定するための情報種別に関するデータを記録しておく。

図１０（ｃ）に示すように、帳票ＤＢには、各販売銀行において使用される帳票データが記録される。この帳票データには、販社コード、承認ステータス、帳票に関するデータが含まれる。

販社コードデータ領域には、帳票を提供する販売銀行を特定するための識別子に関するデータが記録される。
承認ステータスデータ領域には、この帳票の提供可否を判定するためのフラグが記録される。

帳票データ領域には、各販売銀行に提供される帳票ファイル（例えば、事務帳票ファイルや法定帳簿ファイル）が記録される。
そして、販売銀行に帳票を提供する場合には、図１０（ｄ）に示す必要書類出力処理を実行する。この処理は、販売銀行毎に処理対象を特定して繰り返して実行される。

まず、契約管理システム３０の制御部３１は、イベント時期の特定処理を実行する（ステップＳ９−１）。具体的には、制御部３１の帳票作成手段は、処理対象の販社コードに関連付けられ、販売されている金銭信託について、帳票を作成する時期をイベント時期情報ＤＢから取得する。

次に、契約管理システム３０の制御部３１は、帳票作成時期に該当するかどうかについての判定処理を実行する（ステップＳ９−２）。具体的には、制御部３１の帳票作成手段は、システムタイマから本日日付を取得し、帳票作成時期と比較する。

イベント時期に対応した帳票作成時期に該当しないと判定した場合（ステップＳ９−２において「ＮＯ」の場合）、契約管理システム３０の制御部３１は、この処理対象の販売銀行についての処理を終了する。

一方、イベント時期に対応した帳票作成時期に該当すると判定した場合（ステップＳ９−２において「ＹＥＳ」の場合）、契約管理システム３０の制御部３１は、帳票の特定処理を実行する（ステップＳ９−３）。具体的には、制御部３１の帳票作成手段は、イベント時期情報ＤＢにおいて、各金銭信託のイベント種別（決算期や償還期等）を特定する。

次に、契約管理システム３０の制御部３１は、帳票の作成処理を実行する（ステップＳ９−４）。具体的には、制御部３１の帳票作成手段は、特定したイベント種別のテンプレートを必要書類情報ＤＢから取得する。次に、帳票作成手段は、テンプレートに含まれる情報種別を特定し、処理対象の販社コード、商品コードの金銭信託について、この情報種別の各種情報を各ＤＢ（契約管理システム３０等）から取得する。そして、帳票作成手段は、取得した情報をテンプレートにインポートすることにより、販売銀行に情報を提供するためのレポートを作成する。

次に、契約管理システム３０の制御部３１は、帳票の仮登録処理を実行する（ステップＳ９−５）。具体的には、制御部３１の帳票作成手段は、作成した帳票を販社コードに関連付けて帳票ＤＢに登録する。この場合、承認ステータスデータ領域には、未承認フラグを記録しておく。

次に、契約管理システム３０の制御部３１は、仮登録の通知処理を実行する（ステップＳ９−６）。具体的には、制御部３１の帳票作成手段は、信託銀行の担当者のクライアント端末１５に対して帳票を登録したことを示すメッセージを含めた通知を送信する。この場合、担当者は、クライアント端末１５を用いて登録された帳票を確認し、問題がなければ承認入力を行なう。

次に、契約管理システム３０の制御部３１は、仮登録された帳票の承認情報の取得処理を実行する（ステップＳ９−７）。具体的には、制御部３１の帳票作成手段は、クライアント端末１５において承認入力を検知した場合、帳票管理データの承認ステータスデータ領域に承認済みフラグを記録する。

次に、契約管理システム３０の制御部３１は、販売銀行に対して帳票のリリース処理を実行する（ステップＳ９−８）。具体的には、制御部３１の帳票作成手段は、承認済みフラグが記録された帳票をポータルシステム２０に提供する。そして、すべての販売銀行について処理を終了するまで上記処理を繰り返す。

この場合、ポータルシステム２０は、販社コードに関連付けて帳票を閲覧ＤＢ２７に登録する。そして、ポータルシステム２０の制御部２１は、販売銀行の担当者からの要求に応じて、閲覧ＤＢ２７に登録された各種帳票を提供する。

・ 上記実施形態では、契約管理システム３０の制御部３１は、顧客宛振込データ、顧客向け収益金通知の作成処理を実行する（ステップＳ６−５）。顧客宛振込データにおいて、販売銀行毎に、フォーマットを変更することも可能である。この場合、販社コードに関連付けて、顧客宛振込データのヘッダレコードに含める情報種別（例えばファンド情報）を記録したヘッダ情報テーブルを準備しておく。そして、契約管理システム３０の制御部３１が、振込データを生成する場合には、ヘッダ情報テーブルにおいて販社コードに応じた情報種別を特定し、この情報種別に応じて特定した情報をヘッダレコードに設定する。

・ 上記実施形態では、契約管理システム３０の制御部３１は、顧客宛振込データ、顧客向け収益金通知の提供処理を実行する（ステップＳ６−６）。これに代えて、契約管理システム３０の制御部３１が、振込データを勘定系システムに提供し、信託銀行から、直接、顧客口座に収益金を振り込むようにしてもよい。この場合には、販売会社が提供する総合振込サービスやネットバンキングサービスを利用して、販売顧客の口座に、直接、振込金額を振り込む。

１０，１５…クライアント端末、２０…ポータルシステム、２１…制御部、２１１…認証手段、２１２…販売支援手段、２１３…更新手段、２２…販社ＤＢ、２３…商品属性ＤＢ、２４…利用者ＤＢ、２５…顧客属性ＤＢ、２６…申込ＤＢ、２７…閲覧ＤＢ、３０…契約管理システム、３１…制御部、３１１…情報更新手段、３１２…取引管理手段、３１３…閲覧管理手段、３１４…決算管理手段、３２…顧客属性ＤＢ、３３…取引ＤＢ、３４…残高ＤＢ、４０…ファンド管理システム。

Claims (8)

1. 販売会社において販売された金銭信託を原資として金融機関の経営の健全性維持・向上のための資金調達に資する資産への運用を行ない、この金銭信託の契約管理を行なう金銭信託販売支援システムであって、
   前記金銭信託販売支援システムは、
   販売会社端末に接続されるとともに、前記販売会社において販売された商品について、顧客情報又は商品の申込情報からなる商品販売情報を登録する第１データベースを備えたポータルシステムと、
   前記第１データベースに記録された前記商品販売情報を登録する第２データベースを備えた契約管理システムとから構成され、
   前記ポータルシステムは、販売会社端末から新規の商品販売情報を取得した場合、前記第１データベースに、更新日をセットした商品販売情報を登録し、
   前記契約管理システムは、前記第１データベースに登録された商品販売情報を前記第２データベースに登録し、
   前記ポータルシステムは、販売会社端末から商品販売情報の修正情報を取得した場合、前記第１データベースに記録された商品販売情報の更新日をリセットし、
   前記契約管理システムは、前記更新日がリセットされた商品販売情報を抽出して、前記第２データベースに修正情報を登録し、
   前記契約管理システムは、前記第２データベースを用いて、決算時に前記販売会社において販売された商品の元本に基づいて振込金額を算出し、前記商品の各販売顧客に対して振込金額を振り込むための振込情報を作成することを特徴とする金銭信託販売支援システム。
2. 前記振込金額を振り込むために、前記販売会社に対して、前記振込情報を提供することを特徴とする請求項１に記載の金銭信託販売支援システム。
3. 前記金銭信託販売支援システムにより販売された金銭信託についてのファンドを管理するファンド管理システムにおいて、前記金融機関の経営の健全性維持・向上のための資金調達に資する資産の実行・返済・利払管理を行なうことを特徴とする請求項１又は２に記載の金銭信託販売支援システム。
4. 前記契約管理システムにおいて、収益金を算出した場合には、前記商品を購入した顧客への振込データを作成し、前記販売会社端末に送信することを特徴とする請求項１〜３のいずれか一つに記載の金銭信託販売支援システム。
5. 前記契約管理システムにおいて、収益金を算出した場合には、前記商品を購入した顧客への収益金通知を作成し、送付することを特徴とする請求項１〜４のいずれか一つに記載の金銭信託販売支援システム。
6. 商品についての情報種別が設定されたテンプレートが記録されたテンプレート記憶手段を更に備え、
   前記ポータルシステムは、前記販売会社端末において、テンプレートが指定された場合、前記テンプレートの情報種別について、前記販売会社端末の販売会社において販売された商品販売情報を前記第１データベースから取得し、
   前記情報種別の消費販売情報をテンプレートに設定して、前記販売会社端末に提供することを特徴とする請求項１〜５のいずれか一つに記載の金銭信託販売支援システム。
7. 販売会社において金銭信託を管理するイベントにおいて用いられる帳票のテンプレートが記録された帳票記憶手段を更に備え、
   前記契約管理システムは、
   前記販売会社において販売された商品のイベントを特定し、
   前記イベントで用いられる帳票の作成時期に応じて、前記帳票記憶手段において、帳票のテンプレートを特定し、
   前記テンプレートに含まれる情報種別について、前記販売会社端末の販売会社において販売された商品販売情報を前記第２データベースから取得し、
   前記情報種別の消費販売情報をテンプレートに設定して、前記販売会社端末に提供することを特徴とする請求項１〜６のいずれか一つに記載の金銭信託販売支援システム。
8. 販売会社において販売された金銭信託を原資として金融機関の経営の健全性維持・向上のための資金調達に資する資産への運用を行ない、この金銭信託の契約管理を行なう金銭信託販売支援システムを用いて、金銭信託の販売を支援する方法であって、
   前記金銭信託販売支援システムは、
   販売会社端末に接続されるとともに、前記販売会社において販売された商品について、顧客情報又は商品の申込情報からなる商品販売情報を登録する第１データベースを備えたポータルシステムと、
   前記第１データベースに記録された前記商品販売情報を登録する第２データベースを備えた契約管理システムとから構成され、
   前記ポータルシステムは、販売会社端末から新規の商品販売情報を取得した場合、前記第１データベースに、更新日をセットした商品販売情報を登録し、
   前記契約管理システムは、前記第１データベースに登録された商品販売情報を前記第２データベースに登録し、
   前記ポータルシステムは、販売会社端末から商品販売情報の修正情報を取得した場合、前記第１データベースに記録された商品販売情報の更新日をリセットし、
   前記契約管理システムは、前記更新日がリセットされた商品販売情報を抽出して、前記第２データベースに修正情報を登録し、
   前記契約管理システムは、前記第２データベースを用いて、決算時に前記販売会社において販売された商品の元本に基づいて振込金額を算出し、前記商品の各販売顧客に対して振込金額を振り込むための振込情報を作成することを特徴とする金銭信託販売支援方法。

Images