JP2018060543A - 金融商品管理システムおよび金融商品管理プログラム - Google Patents

Abstract

【課題】外国籍投資信託に対するファンドルックスルーを効率的、効果的に実現する。
【解決手段】他のファンドを組み入れているものを含むファンドの運用状況を管理する金融商品管理システム１であって、各ファンドの属性情報を記録するファンド管理部１１と、クライアント端末からアップロードされた、もしくは他システムから取得した各ファンドの残高データを含むデータを記録するデータ連携部１２と、１つ以上の第１のファンドに組み入れられている第２のファンドに係る残高を、前記各第１のファンドの前記第２のファンドに対する持分により按分して、前記第１のファンドおよび前記第２のファンドに係るルックスルー残高を計算して記録する按分処理部１４と、を有する。
【選択図】図１

Description

本発明は、資産運用業務を支援する技術に関し、特に、資産運用会社や信託銀行等におけるフロント／ミドルオフィスシステムを構成する金融商品管理システムおよび金融商品管理プログラムに適用して有効な技術に関するものである。

非特許文献１等に記載されているように、日本の資産運用会社にとって、外国籍投資信託（以下では「外投」と省略記載する場合がある）は、ファンドオブファンズ（Fund of Funds：ＦｏＦ）型の投資信託ファンドや、投資一任の顧客口座で組み入れることも多い重要な投資対象資産である。

一方で、外投の管理状況は、ＮＡＶ（Net Asset Value：純資産総額）や分配金、設定解約情報等についてのみ、外投の運用会社やファンドアドミニストレータ（以下では「アドミ」と省略記載する場合がある）から取得するというのが一般的であった。そして、外投の中身の銘柄レベルの情報については、運用会社の外部委託運用担当者やレポート作成担当者等が必要に応じてファイル等により個別に受領する程度であった。しかし、「投資信託及び投資法人に関する法律」の改正において規定された「信用リスク集中回避のための投資制限（以下では「信用リスク集中規制」と記載する場合がある）」への対応や、銀行のバーゼル規制への対応等を起因として、ファンド内の資産構成の把握（ルックスルー）のニーズが急速に高まっており、より高度なデータ管理が必要になっている。

信用リスク集中規制では、発行体毎のエクスポージャーを一定水準以下に保つことが求められる。ＦｏＦについては、投資ガイドラインを設けて管理する方法も認められるが、外投運用会社やファンドアドミからの投資ガイドライン順守を報告するレポートだけでは管理不十分と考える運用会社が増えてきている。また運用会社が運用を外部委託する場合、受託者責任としてファンドの中身の管理に対して求められる水準が高まっており、ルックスルーデータを定期的に取得し、モニタリングすることが必要となってきている。近年は銀行によるファンド投資も活発化しており、バーゼル規制対応のため銀行が投資ファンドのデータ管理を強化する中で、運用会社に正確なルックスルーデータの提供を求め始めていることも、運用会社のルックスルーのニーズを高める要因となっている。

蒲谷俊介、"重要度が高まる外国籍投信ルックスルー管理の課題とその解決に向けて"、［online］、平成２７年７月、株式会社野村総合研究所、［平成２８年５月２７日検索］、インターネット＜URL：http://fis.nri.co.jp/ja-JP/publication/kinyu_itf/backnumber/2015/07/201507_04.html＞

しかし、外投に対するルックスルー管理を実現するためには、以下の様な課題がある。例えば、外投データの取得は、現在では多くても月次程度が一般的であり、それをより頻繁に、かつ所望のフォーマットで求めることは難しい。これは、取引や残高などのデータ受渡用の標準フォーマットがグローバルに存在しないことに起因する。そのため、現状では、各外投運用会社がファンドアドミからそれぞれ個別のフォーマットでデータを取得しなければならないという課題を有する。

また、外投データでは、運用会社やファンドアドミ毎に管理する銘柄属性が異なるため、ルックスルーデータを単純に取得するだけではそのデータは利用できない。例えば、同一銘柄でも、運用会社やアドミによって「野村総合研究所」、「NRI」、「Nomura Research」等の異なる名称で管理されている場合がある。同一銘柄を認識できなければ、銘柄別保有比率等の必要な情報を算出することもできない。

そこで本発明の目的は、外国籍投資信託に対するファンドルックスルーを効率的、効果的に実現する金融商品管理システムおよび金融商品管理プログラムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による金融商品管理システムは、他のファンドを組み入れているものを含むファンドの運用状況を管理する金融商品管理システムであって、各ファンドの属性情報を記録するファンド管理部と、クライアント端末からアップロードされた、もしくは他システムから取得した各ファンドの残高データを含むデータを記録するデータ連携部と、１つ以上の第１のファンドに組み入れられている第２のファンドに係る残高を、前記各第１のファンドの前記第２のファンドに対する持分により按分して、前記第１のファンドおよび前記第２のファンドに係るルックスルー残高を計算して記録する按分処理部と、を有するものである。

また、本発明は、上記のような金融商品管理システムとして機能するよう、コンピュータに処理を実行させる金融商品管理プログラムにも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、外国籍投資信託に対するファンドルックスルーを効率的、効果的に実現することが可能となる。

本発明の実施の形態１である金融商品管理システムの構成例について概要を示した図である。 本発明の実施の形態１におけるファンドルックスルーの概要について説明する図である。 （ａ）〜（ｃ）は、本発明の実施の形態１におけるファンド管理機能の例について概要を示した図である。 本発明の実施の形態１における残高データフォーマット変換機能の例について概要を示した図である。 （ａ）、（ｂ）は、本発明の実施の形態１におけるクラスファンドの残高データを算出する例について概要を示した図である。 （ａ）〜（ｃ）は、本発明の実施の形態１における銘柄コード変換機能の例について概要を示した図である。 本発明の実施の形態１におけるルックスルー後の残高データを参照する結果確認画面の例を示した図である。 本発明の実施の形態１におけるルックスルーデータを取り込む日常の業務フローの例について概要を示した図である。 本発明の実施の形態２である金融商品管理システムの構成例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

（実施の形態１）
＜システム構成＞
図１は、本発明の実施の形態１である金融商品管理システムの構成例について概要を示した図である。金融商品管理システム１は、例えば、外投を組み入れる国内の資産運用会社４や信託銀行等におけるフロント／ミドルオフィスシステムとして機能する情報処理システムである。

金融商品管理システム１は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等により実装されたサーバシステムであり、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェア上で稼働するソフトウェアとして実装された、ファンド管理部１１、データ連携部１２、銘柄コード変換部１３、按分処理部１４、および業務処理部１５等の各部を有する。また、データベースやファイル等により実装されるファンド属性１６ａ、組み入れファンド属性１６ｂ、外国籍ファンド残高１７ａ、他社国内ファンド残高１７ｂ、自社国内ファンド残高１７ｃ、およびルックスルー後残高１８等の各データストアを有する。

ファンド管理部１１は、一般的なファンドの管理のため、さらにはルックスルーを行うために必要となる、ファンドおよびこれに組み入れられるファンドの属性を、それぞれファンド属性１６ａおよび組み入れファンド属性１６ｂに保持して管理するファンド管理機能を有する。ファンド属性１６ａには、例えば、資産運用会社４が保有するファンドの属性情報、および各ファンドについてのルックスルーの要否の情報等を保持する。また、組み入れファンド属性１６ｂには、組み入れられるファンドの属性情報や、これを取り扱う外投運用会社２や海外アドミ３のアドミ（会社）コード、当該外投運用会社２や海外アドミ３からの残高情報に基づいて帳票を作成する頻度（例えば、日次、月次等）の情報等を保持する。

データ連携部１２は、資産運用会社４が保有するファンドの残高データを自動もしくは手動のアップロードにより取得する機能を有する。例えば、国内投資信託（投信）等に係る処理を行うバックオフィスシステムから、自社の国内ファンドに係る残高の情報の送付を日次で自動的に受け、自社国内ファンド残高１７ｃに登録する機能を有する。

また、資産運用会社４の担当者による、外国籍ファンドや他社の国内ファンドの残高の情報についての日次や月次のアップロードを受け、外国籍ファンド残高１７ａや他社国内ファンド残高１７ｂにそれぞれ登録する機能を有する。外国籍ファンドの残高の情報は、例えば、これを取り扱う外投運用会社２や海外アドミ３から提供される。ここで、外国籍ファンドや他社のファンドでは、残高データについてそれぞれ異なる個別のフォーマットを有する場合がある。そこで本実施の形態では、残高データについて、予めこれらを自社のフォーマット（金融商品管理システム１で取り扱えるフォーマット）やデータ体系に変換する残高データフォーマット変換機能を有する。

このフォーマット変換は、アップロード等により残高データを取得したデータ連携部１２自体が行う構成としてもよいが、本実施の形態では、資産運用会社４の担当者が使用するクライアント端末上で行ない、自社のフォーマットによるアップロードデータを作成する構成とする。そのため、例えば、クライアント端末上には、変換用のマッピングテーブル２１と、これを用いてフォーマット変換の処理を行うソフトウェアであるフォーマット変換部２０を有する。さらに、マッピングテーブル２１を作成・更新する機能をクライアント端末上に有していてもよい。マッピングテーブル２１が金融商品管理システム１上に保持され、資産運用会社４の各担当者のクライアント端末から共有される構成であってもよい。

銘柄コード変換部１３は、外投運用会社２や海外アドミ３が開示する残高データにおけるオリジナルの銘柄コードを、残高データにおける外部コード（例えば、ＩＳＩＮ（ International Securities Identification Number）コードやＳＥＤＯＬ（Stock Exchange Daily Official List）コード等の国際的に広く用いられている標準コード）を利用して、自社の銘柄コード体系（バックオフィスシステムや金融商品管理システム１で利用している既存のコード体系）に変換する機能を有する。

按分処理部１４は、ファンドを組み入れているファンドの残高等からなる残高按分情報の登録を受け付けて、組み入れられている外投のファンドの持分相当の銘柄残高を算出する、すなわち当該ファンドに対するルックスルーを行う機能を有する。本実施の形態では、外国籍ファンド残高１７ａおよび他社国内ファンド残高１７ｂに保持されているファンドの残高等からなる残高按分情報に基づいて、各銘柄の残高の持分に応じた按分により銘柄毎の残高を算出する機能を有する。算出した銘柄情報は、ルックスルー後残高１８に自社国内ファンドの銘柄毎の残高の情報と併せて記録する。

業務処理部１５は、自動もしくは資産運用会社４の担当者等からの要求に基づく手動により、ルックスルー後残高１８に記録された内容を利用した各種の業務処理を行なって結果を出力する機能を有する。例えば、対象のファンドについての投資ガイドラインの遵守状況のチェックや、外投に対する信用リスクのモニタリング等を行う。

＜ファンドルックスルーの概要＞
図２は、ファンドルックスルーの概要について説明する図である。従来技術では、上段の図に示すように、顧客の投資対象である自社国内ファンドに組み入れられているマザーファンド（ファミリーファンド方式において顧客の投資対象とならないファンド）のみがルックスルーの対象であるのが一般的であった。

これに対し、下段の図に示すように、本実施の形態では、自社国内ファンドに組み入れられたマザーファンドに限らず、外投や他社国内ファンド、マザーファンド以外の自社国内ファンドについてもルックスルーの対象とする。さらに、ルックスルーを複数階層に渡って行うことも可能である。なお、このとき、通貨選択型等のトータルクラスファンドは１階層として取り扱うものとする。

＜ファンド管理機能＞
図３は、ファンド管理部１１が有するファンド管理機能の例について概要を示した図である。図３（ａ）は、ファンド管理機能の１つとして、国内ファンドに組み入れている銘柄と、組み入れられるファンド（外国籍ファンド等）を関連付ける例を示している。ここでは、「国内ファンドＡ」が組み入れて保有する「Ｂ銘柄（ファンド）」および「Ｃ銘柄（ファンド）」について、その実体がそれぞれ「外国籍ファンドＢ」および「他社国内ファンドＣ」である場合に、これらを関連付けていることを示している。この関連付けに係る情報は、例えば、ファンド属性１６ａ、および組み入れファンド属性１６ｂのテーブル等に保持して適宜参照することができる。

図３（ｂ）は、ファンド管理機能の１つとして、組み入れられるファンド（外国籍ファンド等）とアドミのオリジナルのコードを、金融商品管理システム１のコード体系におけるファンドコードと関連付ける例を示している。ここでは、組み入れられるファンドを取り扱うアドミのアドミ（会社）コードが「ＡＢＣ Ａｄｍｉｎ」であり、また、組み入れられる外国籍ファンドが２つあり、それぞれのオリジナルのファンドコードが「ＡＡＡ０１」および「ＡＡＡ０２」であることを示している。そして、これらのオリジナルのファンドコードを、金融商品管理システム１のコード体系における「Ｆ００１−１２３４」および「Ｆ００１−２３４５」というファンドコードにそれぞれ関連付けていることを示している。この関連付けに係る情報は、例えば、組み入れファンド属性１６ｂのテーブル等に保持して適宜参照することができる。

図３（ｃ）は、ルックスルーの要否をファンド毎に登録する例を示している。ここでは、「外国籍ファンドＶ」および「外国籍ファンドＷ」を組み入れている「自社国内ファンドＡ」についてはルックスルーを行い、「外国籍ファンドＹ」および「外国籍ファンドＺ」を組み入れている「外国籍ファンドＣ」についてはルックスルーを行わないよう設定していることを示している。この設定に係る情報は、例えば、ファンド属性１６ａのテーブル等に保持して適宜参照することができる。

＜残高データフォーマット変換機能＞
図４は、データ連携部１２が有する残高データフォーマット変換機能の例について概要を示した図である。ここでは、資産運用会社４等が、外投運用会社２や海外アドミ３から開示された外投の残高データ等について、マッピングテーブル２１を用いてフォーマット変換を行なって、金融商品管理システム１に入力するためのアップロードデータを作成することを示している。当然ながら外投運用会社２や海外アドミ３からフォーマット変換がされた残高データ等を取得できる場合には当該フォーマット変換処理は不要である。

図の左側に示す資産運用会社４が用意する変換前のデータには、アドミの残高データやＮＡＶデータが含まれる。また、後述するように、トータルクラスファンド構成の場合に、クラスファンド毎の残高を算出できるようにするためのトータルファンド按分データやクラス分類識別データについても用意する。

そして、マッピングテーブル２１としては、例えば、項目毎のマッピング表や証券種別の変換表等を登録しておく。項目毎のマッピング表には、例えば、アドミデータとアップロードデータのそれぞれの項目間の単純な関連付けに加えて、四則演算や文字列結合等を使った設定を行えるようにしてもよい。これらのマッピングテーブル２１を用いて、フォーマット変換部２０がアドミの残高データ等の各項目を入力としてこれらの値を変換する。その結果、図の右側に示す変換後のアップロードデータとして、残高データ（クラスファンド毎に按分したものを含む）やＮＡＶデータを得ることができる。アップロードデータには、さらに、残高データ等の対象の銘柄に係るＩＳＩＮコード等の外部コードの情報が含まれ得る。

また、後述するように、マッピングテーブル２１には、入力の残高データにおけるオリジナルの銘柄コードが、金融商品管理システム１でのデータ体系における銘柄コードと、実体は異なるファンドであるにも関わらず重複する場合に、これを変換する銘柄コード変換表も有する。これにより、入力の残高データ等の中に該当する（重複する）銘柄コードがある場合、フォーマット変換部２０によって予めアドミの残高データにおける銘柄コードが変換される。

マッピングテーブル２１は、例えば、アドミデータとアップロードデータの項目間の関連付け等の情報をユーザがファイル等に登録することにより作成される。マッピングテーブル２１における関連付けの登録・変更や、現在の登録状況の参照・確認等の作業は、例えば、ユーザが使用するクライアント端末上で稼働するソフトウェアとして上記作業のためのユーザインタフェースが実装された支援ツール等を用いて行うようにしてもよい。これにより、マッピングテーブル２１の作成や管理を、ユーザが独自にクライアント端末上で効率的に行うことができる。

ここで、例えば、自社ファンドがクラスファンドを保有している場合、ファンドのルックスルーを行うには、通常はクラスファンドの残高データが必要となる。しかしながら、このようなクラスファンドの残高データは、その他の一般的なファンドの残高データと比べて一部不足等が生じる場合が多い。この場合、トータルファンドの残高を按分してクラスファンドの残高データを作り出す必要がある。そこで、本実施の形態では、トータルファンド按分データやクラス分類識別データを入力データとすることで、クラスファンド毎の残高を算出できるようにする。

図５は、トータルファンドの残高データから按分によりクラスファンドの残高データを算出する例について概要を示した図である。図５（ａ）では、トータルファンドに複数のクラスファンド（図５の例では「クラスファンドＡ」〜「クラスファンドＣ」の３つ）が含まれる場合において、自社ファンドがそのうちの「クラスファンドＣ」を保有している状況を示している。ここで、自社ファンドについてルックスルーを行う場合、「クラスファンドＣ」の残高データが必要となる。しかしながら、「クラスファンドＣ」の残高データの一部をトータルファンドの残高データから按分（図５（ａ）の例では按分比率Ｘ％）して作成することが必要となる場合がある。

図５（ｂ）は、通貨選択型ファンドを例として、トータルファンドの一部の残高データを按分してクラスファンドの残高データを作成する例について概要を示している。上段の図に示すように、右側のクラスファンドの残高データには、該当の通貨に対応するクラスファンド固有の残高として為替データしか開示されていない場合がある。本実施の形態では、クラスファンドとしての全残高データが必要であるため、不足する残高データをトータルファンドの残高データから按分して作成する。この場合、下段の図に示すように、右側のクラスファンドにおける有価証券の残高データについて、左側のトータルファンドにおける有価証券の残高データを、持分（図５（ｂ）の例では、「クラスＥＵＲ」は２０％、「クラスＢＲＬ」は３０％、「クラスＡＵＤ」は５０％）に応じて按分して算出する。

このように、自社ファンドがクラスファンドを保有している場合でも、トータルファンドにおけるクラスファンドの持分から按分により残高データの一部を自動的に算出することができる。

＜銘柄コード変換機能＞
図６は、銘柄コード変換部１３が有する銘柄コード変換機能の例について概要を示した図である。各外投運用会社２や海外アドミ３から取得した残高データは、それぞれで銘柄コード体系が異なる場合があり得る。そこで、銘柄コード変換部１３は、クライアント端末から残高データ等がアップロードされた際に、業務的に同一と判断される銘柄コードを、自社の銘柄コード体系（バックオフィスシステムや金融商品管理システム１で利用している既存のコード体系）に変換して統一する。

複数の銘柄が業務的に同一なものか否かの判断は、本実施の形態では、それぞれの銘柄に設定されているＩＳＩＮコードやＳＥＤＯＬコード等の外部コードを用いて行う。そして、自社の銘柄コード体系に変換する際に、ユーザが使用する接続元のバックオフィスシステムが複数種類あり（例えば、機関投資家対象のシステムと個人投資家対象のシステム等）、その双方に対象の銘柄属性が保有されている場合、いずれのバックオフィスシステムの銘柄コードを採用するかを優先度の設定によって制御する。

図６（ａ）では、外部コードと銘柄コードとの間の変換ルールを定めた変換テーブル１３ａの例を示している。このテーブルを参照し、入力の残高データに該当する外部コード（図中の例では外部コード「ＪＰ１２３４５」）のエントリがある場合に、その銘柄コードを書き換えて変換する（図中の例では銘柄コードを「２２２２Ｂ」に書き換える）。なお、図中の変換テーブル１３ａの例では、外部コード「ＪＰ１２３４５」に対して優先する接続元のバックオフィスシステムの種類が異なる（図中の例では「システムＡ」および「システムＢ」）２つのエントリを有している。そして、図中の例では、「システムＢ」の種類のバックオフィスシステムを優先する旨が指定されていた場合を示しており、その結果、優先するバックオフィスシステムが「システムＢ」である銘柄コード「２２２２Ｂ」に変換されたことを示している。

これにより、複数種類のバックオフィスシステムを有する場合でも銘柄コードを統一的に管理することができる。また、対象のバックオフィスシステムで管理している銘柄属性を、外投のアドミデータに対して適用することも可能となる。

図６（ｂ）は、入力の残高データにおける外部コード（図中の例では外部コード「ＪＰ１２３４７）に該当するエントリが変換テーブル１３ａに存在せず、銘柄コードの変換が行われなかった場合の例を示している。この場合、銘柄コード変換部１３は、入力の残高データにおける銘柄コード（図中の例では銘柄コード「１１１１Ａ」）について既存の銘柄コードとの重複がないかをチェックする。既存の銘柄コードは、例えば、図示するように変換テーブル１３ａに登録されているエントリの銘柄コードを参照してもよいし、図１に示したファンド属性１６ａや組み入れファンド属性１６ｂのテーブルに登録されている銘柄コードを参照してもよい。

ここで重複がなければ、当該銘柄コードをそのまま用いることができる。このとき、外部コードと銘柄コードとの組み合わせからなるエントリを新たに変換テーブル１３ａ等に登録するようにしてもよい。一方、図６（ｂ）の例のように重複がある場合には、例えば、ユーザのクライアント端末に対してその旨の警告を出力する。ユーザは、処理完了後に別途処理結果の詳細な内容を確認し、重複があったエントリを確認することができる。
なお、重複がある場合にどのように取り扱うか（警告を出力してスキップする、上書き更新する、等）を予め設定しておいて、設定内容に従って自動的に処理するようにしてもよい。

重複する旨の警告を受けたユーザは、例えば、入力の残高データにおける外部コードが正しいものであることを確認した上で、クライアント端末上のマッピングテーブル２１における変換表に、対象の銘柄コードを別の銘柄コードに変換するエントリを定義しておく。そして、フォーマット変換部２０がアドミからの残高データに対するフォーマット変換処理を行う際に、変換表の定義内容に従って、アップロードデータにおける対象の銘柄コードを重複しないものに予め変換しておく。

図６（ｃ）は、マッピングテーブル２１における銘柄コードの変換表の例を示している。ここでは、例えば、変換前の旧銘柄コード（図中の例では「１１１１Ａ」）と、これに対する変換後の新銘柄コード（図中の例では「１１１２Ａ」）の組み合わせからなるエントリが登録されていることを示している。なお、新銘柄コードについては、既存の銘柄コードと重複しないものであればユーザが適当なものを設定することができる。

このように、銘柄コードを統一することで、例えば、金融商品管理システム１のファンド属性１６ａや組み入れファンド属性１６ｂにおいて統一先の銘柄コードによって管理している様々な銘柄属性を、各外投運用会社２や海外アドミ３からの残高データに対してもそのまま利用することが可能となる。

さらに、例えば、対象の銘柄コードが金融商品管理システム１に初めて入力された日付、および金融商品管理システム１において対象の銘柄コードの統一化が初めて行われた日付を保持して管理するようにしてもよい。これにより、金融商品管理システム１における対象の銘柄コードについての銘柄属性のメンテナンスの要否を判断する際の基準とすることができる。

＜残高按分計算機能＞
按分処理部１４が有する残高按分計算機能では、上述したように、ファンドに組み入れられているファンドの残高等からなる残高按分情報の登録を受け付けて、組み入れられている外投のファンドの持分相当の銘柄残高を算出する、すなわち当該ファンドに対するルックスルーを行う。

具体的には、例えば、複数の国内ファンドに組み入れられる外投ファンドの残高を、組み入れている各国内ファンド等の「口数」または「時価総額」を持分としてこれに応じて按分することで、ルックスルー残高を算出し、ルックスルー後残高１８に登録する。

また、組み入れられるファンド毎に、ルックスルー後の残高を作成する頻度をユーザが日次／月次から選択できるようにしてもよい。例えば、頻度として日次が指定された場合、ファンドの休日や国内籍投信に対する相対日付等の属性情報を組み入れファンド属性１６ｂに予め登録しておき、相対日付を基準日としてルックスルー後の残高データを作成するようにしてもよい。相対日付は「○日前」のように登録する。例えば、外国籍ファンドの相対日付を「１日前」と設定した場合、これを組み入れている国内ファンドの基準日が６月６日（月）であった場合は、当該外国籍ファンドの基準日は６月３日（金）となる。一方、頻度として月次が指定された場合、例えば、国内籍投信の月末営業日に対して、既に登録されている直近までの残高データを利用して、ルックスルー後の残高データを作成するようにしてもよい。

＜結果出力機能＞
業務処理部１５が有する結果出力機能では、ユーザからの要求に対して、ルックスルー後残高１８の内容に対して適宜業務処理を行い、結果を出力する。例えば、ルックスルーの実行状況の確認、およびルックスルー後の残高データの参照に加えて、対象のファンドについての投資ガイドラインの遵守状況のチェックや、外投に対する信用リスクのモニタリング等の処理を行う。

図７は、ルックスルー後の残高データを参照する結果確認画面の例を示した図である。ここでは、確認・分析したい基準日のルックスルー按分ポートフォリオ（按分の対象となるファンドからなるポートフォリオ）について、ルックスルー階層が想定通りに計算されているか否かを確認することができる。具体的には、ルックスルー階層毎に、ルックスルーに用いたポートフォリオコードや残高の基準日、按分比率等を確認することができる。また、直近にアップロードされた残高データを利用したルックスルー後残高が作成されているか否かを確認することができる。また、残高データのアップロードの実施有無についても確認することができる。

表中の「ＣＨＫ」の列（「更新時刻比較」および「ルックスルー結果」）がともに「○」となっている明細行は、ルックスルー計算が完了しているポートフォリオを示す。ここで、ルックスルーに用いられた残高日付や按分比率等に問題がなければ、当該明細行はその後の各種の分析業務の対象とすることができる。一方、「ＣＨＫ」の列に「×」が存在する明細行は、ルックスルー計算が完了していないことを示す。この場合、例えば、直近の残高データのアップロードデータを用いて再計算する等により、ルックスルー計算を完了させることになる。

＜業務フロー＞
図８は、ルックスルーデータを取り込む日常の業務フローの例について概要を示した図である。まず、Ｔ＋１（国内ファンドの基準日の翌営業日）の日中において、各外投運用会社２や海外アドミ３が外投ファンドに係る残高データ等を資産運用会社４に提供し、資産運用会社４はこれを取得する（Ｓ０１）。資産運用会社４の担当者等のユーザは、各外投運用会社２や海外アドミ３から取得した外投データを、上述した残高データフォーマット変換機能により、金融商品管理システム１で利用可能なフォーマットに変換する（Ｓ０２）。そして、フォーマット変換後の残高データ等を金融商品管理システム１にアップロードする（Ｓ０３）。金融商品管理システム１は、アップロードされたデータを登録する（Ｓ０４）。

なお、本実施の形態では、資産運用会社４の担当者等のユーザが、取得した外投データをフォーマット変換してアップロードデータを作成した上で、金融商品管理システム１にアップロードする構成としているが、外投データの取得方法はこれに限られない。例えば、可能な場合には、データ連携部１２により外投運用会社２や海外アドミ３のサーバからネットワークを介して直接外投データを取得し、データ連携部１２においてフォーマット変換を行う構成としてもよい。この場合、外投データの取得はＴ＋１の日中ではなく、Ｔ（国内ファンドの基準日の当日）の日中に行うことが可能となる場合がある。

また、ユーザは、必要に応じて、上述したファンド管理機能により、ファンドの銘柄属性情報やマスタデータ等を指定して金融商品管理システム１に登録しておく（Ｓ０５、Ｓ０６）。その後、金融商品管理システム１は、上述した銘柄コード変換機能により、アップロードされたデータの銘柄コードを変換し、銘柄属性との間で重複等の整合性チェックを行うことで、アップロードデータを取り込む（Ｓ０７）。

ここで銘柄コードの重複等の不整合があった場合にはユーザに対してこれを通知・警告する（Ｓ０８）。通知・警告を受けたユーザは、必要に応じてマッピングテーブル２１の内容を修正し、銘柄属性情報が修正されたアップロードデータを再作成してアップロードする（Ｓ０９）。金融商品管理システム１では、修正された内容のアップロードデータや銘柄属性情報等に基づいて残高データ等を修正する（Ｓ１０）。

その後、Ｔ＋１の夜間において、バッチ処理による上述した残高按分計算機能により、残高データ等に基づいてルックスルー計算を行い、ルックスルー後残高データ１８を得る（Ｓ１１）。ルックスルー後残高データ１８に対して、予め、コンプライアンスチェックや信用リスク計算等の各種業務処理を可能な限り実施しておいてもよい（Ｓ１２）。

その後、Ｔ＋２（Ｔ＋１の翌営業日）の日中において、外投運用会社２のユーザは、金融商品管理システム１が保持するルックスルー後残高データ１８や、各種業務処理の結果を参照することができる（Ｓ１３、Ｓ１４）。金融商品管理システム１は、ユーザからの要求に応じてアドホックに、ルックスルー後残高データ１８を参照し、各種業務処理を行って結果を応答するようにしてもよい。

以上に説明したように、本発明の実施の形態１である金融商品管理システム１によれば、資産運用会社４が外投運用会社２や海外アドミ３から取得した外投データのフォーマット変換を容易に行ってフォーマットを統一することができる。また、銘柄コードについても、ＩＳＩＮコードやＳＥＤＯＬコード等の標準的な外部コードを利用してマッチングすることにより、統一的な銘柄コードに変換することができ、銘柄属性の一元的な管理が可能となる。そして、さらに残高按分機能を有することにより、外投に対するルックスルーを管理する基盤としての機能を効率的・効果的に実現することができる。

（実施の形態２）
上述した実施の形態１によれば、資産運用会社が外投も含むファンドについてルックスルーを行うことが可能である。一方で、近年は銀行によるファンド投資も活発化しており、銀行についても、自己資本比率算出業務や、他の規制対応、内部リスク管理等の観点で、ファンドの中身に対するルックスルーを行うことへのニーズは高まっている。

これに対して、各資産運用会社が各銀行に対してルックスルー後の銘柄残高等のデータを提供することが考えられる。しかし、例えば、資産運用会社が各銀行から要求されるデータの項目やフォーマット、ファイル形式等は区々であり、また、銀行が各資産運用会社から提供されるデータの項目やフォーマット、ファイル形式等も区々であるのが現状である。

そこで、本発明の実施の形態２である金融商品管理システムは、各資産運用会社および各銀行の間で統一されたフォーマットで、資産運用会社が各銀行に対して、ファンドのルックスルー後の銘柄残高等のデータを提供することを可能とするものである。

＜システム構成＞
図９は、本発明の実施の形態２である金融商品管理システムの構成例について概要を示した図である。本実施の形態の金融商品管理システム１は、例えば、大きく３つのサブシステムにより構成される。１つは、各資産運用会社４側の金融商品管理システム１ａであり、他の１つは、センター側の金融商品管理システム１ｂであり、他の１つは、銀行５等の金融機関側の金融商品管理システム１ｃである。これら各サブシステムの区分は論理的・機能的なものであり、例えば、各サブシステムがクラウドコンピューティングサービス上に構築された仮想サーバによりセンターシステムとして構成されてＩＴ事業者等により一括で運用され、複数の資産運用会社４や銀行５等に対してサービスとして提供される構成であってもよい。いずれの構成をとる場合であっても、各サブシステム間はセキュアなネットワークで接続されるものとする。

各資産運用会社４側の金融商品管理システム１ａは、概ね、上述の実施の形態１の図１に示した金融商品管理システム１の構成と同様の構成と機能を有するものとすることができるため、説明の便宜上、主に本実施の形態において追加される特徴的な構成要素についてのみ記載している。金融商品管理システム１ａは、追加の構成要素として、例えば、ソフトウェアとして実装された銀行用データ抽出部３１、および送信処理部３２等の各部を有する。また、データベースやファイル等により実装された銀行用属性３３、銀行用残高１９ａ、および開示属性３４ａ等の各データを有する。

銀行用データ抽出部３１は、資産運用会社４側において上述の実施の形態１に示した仕組みにより得られた、当該資産運用会社４が運用するファンドのルックスルー後の銘柄別残高であるルックスルー後残高１８から、顧客の銀行５毎に、各銀行５に係るデータを抽出し、銀行用残高１９ａとして記録する機能を有する。ここでのファンドには、国内ファンドに加えて外投等を含んでいてもよい。ルックスルー後の銘柄別残高に加えて、例えば、銀行５向けに、ＮＡＶ、リスクアセット表や内訳表等のＢＩＳデータ、リスク感応度データ等を取得するようにしてもよい。

提供対象の各銀行５が要求するデータの項目や形式等の情報、すなわち対象の銀行５に係るデータを抽出するための条件等の情報は、資産運用会社４の担当者等により予め銀行用属性３３に登録されているものとする。抽出された銀行用残高１９ａの内容に対して、資産運用会社４の担当者等が手動で修正を加えることができるようにしてもよい。

送信処理部３２は、銀行用残高１９ａの内容を、センター側の金融商品管理システム１ｂに送信する機能を有する。その際、各ファンドの開示先の銀行５の情報、および各銀行５に対する開示対象のファンドの情報を開示属性３４ａから取得して、合わせて金融商品管理システム１ｂに送信する。なお、開示属性３４ａの内容についても、資産運用会社４の担当者等により予め手動で登録されているものとする。

センター側の金融商品管理システム１ｂは、資産運用会社４側の金融商品管理システム１ａと、銀行５側の金融商品管理システム１ｃとの間を中継するサブシステムであり、例えば、ソフトウェアとして実装された取込処理部４１、およびダウンロード制御部４２等の各部を有する。また、データベースやファイル等により実装された銀行用残高１９ｂ、および開示属性３４ｂ等の各データを有する。

取込処理部４１は、各資産運用会社４側の金融商品管理システム１ａからそれぞれ送信された各銀行用の銘柄別残高等のデータを受信して、その内容を銀行用残高１９ｂに記録する機能を有する。必要に応じて、各データについて所定の共通フォーマット・統一フォーマットに変換するようにしてもよい。

ダウンロード制御部４２は、開示属性３４ｂの内容に基づいて、銀行用残高１９ｂに記録された銘柄別残高等のデータのうち開示可能なものを、対象の銀行５側の金融商品管理システム１ｃに送信する機能を有する。ダウンロードは、銀行５側の金融商品管理システム１ｃからの要求に応じて随時行ってもよいし、日次やその他の時間間隔で定期的・自動的に行うようにしてもよい。また、複数の銀行５の金融商品管理システム１ｃに対して同時並行的に送信することで、これらの銀行５に対して銘柄別残高等のデータを一括で開示することも可能である。

各銀行５側の金融商品管理システム１ｃは、例えば、ソフトウェアとして実装された取込処理部５１、按分処理部５２、および業務処理部５３等の各部を有する。また、データベースやファイル等により実装された銀行用残高１９ｃ、およびファンド残高５４等の各データを有する。

取込処理部５１は、センター側の金融商品管理システム１ｂから送信された対象の銀行用の銘柄別残高等のデータをダウンロードする機能を有する。上述したように、金融商品管理システム１ｂのダウンロード制御部４２に対してダウンロードの要求を行ってもよいし、日次等のタイミングで定期的にダウンロード制御部４２から送信されるデータを受け取るようにしてもよい。

按分処理部５２は、取込処理部５１によってダウンロードされた銘柄別残高等の情報に基づいて、対象の銀行５の持分を算出して銀行用残高１９ｃとして記録する機能を有する。すなわち、銀行５は、銀行側の金融商品管理システム１ｃ上で自身のファンドの保有残高の情報をファンド残高５４に保持し（もしくは他のシステムから取得し）、センター側の金融商品管理システム１ｂを介して資産運用会社４から受領した銘柄別残高等のデータを、ファンド全体に対する保有割合で按分・合成して、自身の銘柄別残高等のデータを得る。また、リスクアセット額の計算も行う。

業務処理部５３は、自動もしくは銀行５の担当者等からの要求に基づく手動により、銀行用残高１９ｃに記録された内容を利用した各種の業務処理を行なって結果を出力する機能を有する。例えば、各種帳票の出力や、銀行用残高１９ｃのデータに係るＶｉｅｗの出力等を行うことができる。業務処理を行う際に、銀行５が有する図示しない他の情報系システム等と連携して処理を行うようにしてもよい。例えば、資産運用会社４から受領した各銘柄の外部格付の情報に対して、銀行５側のシステムが有する内部格付の情報を取得して反映させる等の処理を行うことができる。

以上に説明したような構成を有する本発明の実施の形態２である金融商品管理システム１によれば、各資産運用会社４が、顧客である各銀行５に対してルックスルー後のファンドの残高情報等を開示し、各銀行５において、それぞれ自身が保有するファンドの内容をルックスルーして、リスク管理等の業務を適切かつ柔軟に行うことが可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、上記の実施の形態では、複数の銘柄を組み合わせたファンドを対象に、ファンドの中身に対するルックスルーを効率的、効果的に実現することを可能とするが、ファンドに限らず、銘柄の中身に対するルックスルーにも適用することが可能である。例えば、仕組債の中身の金融商品に対するルックスルーを行うことも可能である。すなわち、複数の金融商品を組み合わせて構成された金融商品一般に対するルックスルーに適用することが可能である。

本発明は、資産運用会社や信託銀行等におけるフロント／ミドルオフィスシステムを構成する金融商品管理システムおよび金融商品管理プログラムに利用可能である。

１、１ａ〜ｃ…金融商品管理システム、２…外投運用会社、３…海外アドミ、４…資産運用会社、５…銀行、
１１…ファンド管理部、１２…データ連携部、１３…銘柄コード変換部、１３ａ…変換テーブル、１４…按分処理部、１５…業務処理部、１６ａ…ファンド属性、１６ｂ…組み入れファンド属性、１７ａ…外国籍ファンド残高、１７ｂ…他社国内ファンド残高、１７ｃ…自社国内ファンド残高、１８…ルックスルー後残高、１９ａ〜ｃ…銀行用残高、
２０…フォーマット変換部、２１…マッピングテーブル、
３１…銀行用データ抽出部、３２…送信処理部、３３…銀行用属性、３４ａ、ｂ…開示属性、
４１…取込処理部、４２…ダウンロード制御部、
５１…取込処理部、５２…按分処理部、５３…業務処理部、５４…ファンド残高

Claims (8)

1. 他のファンドを組み入れているものを含むファンドの運用状況を管理する金融商品管理システムであって、
   各ファンドの属性情報を記録するファンド管理部と、
   クライアント端末からアップロードされた、もしくは他システムから取得した各ファンドの残高データを含むデータを記録するデータ連携部と、
   １つ以上の第１のファンドに組み入れられている第２のファンドに係る残高を、前記各第１のファンドの前記第２のファンドに対する持分により按分して、前記第１のファンドおよび前記第２のファンドに係るルックスルー残高を計算して記録する按分処理部と、を有する、金融商品管理システム。
2. 請求項１に記載の金融商品管理システムにおいて、
   前記クライアント端末もしくは前記データ連携部は、各ファンドアドミニストレータから取得した各ファンドの残高データを含むデータについて、前記金融商品管理システムにおいて取り扱うことができるフォーマットに変換するフォーマット変換部を有する、金融商品管理システム。
3. 請求項１または２に記載の金融商品管理システムにおいて、
   さらに、各ファンドの残高データを含むデータについて、各ファンドアドミニストレータが設定した第１の銘柄コードを、前記金融商品管理システムにおけるコード体系に沿った第２の銘柄コードに変換する銘柄コード変換部を有する、金融商品管理システム。
4. 請求項３に記載の金融商品管理システムにおいて、
   前記銘柄コード変換部は、銘柄に係る標準的な外部コードと前記第２の銘柄コードとの対応関係を保持するテーブルを有し、各ファンドの残高データを含むデータについて、前記テーブルに、各ファンドアドミニストレータが設定した前記外部コードと合致するものがある場合に、合致した前記外部コードに対応する前記第２の銘柄コードによって、前記第１の銘柄コードを書き換える、金融商品管理システム。
5. 請求項３に記載の金融商品管理システムにおいて、
   前記銘柄コード変換部は、銘柄に係る標準的な外部コードと前記第２の銘柄コードとの対応関係を保持するテーブルを有し、各ファンドの残高データを含むデータについて、前記テーブルに、各ファンドアドミニストレータが設定した前記外部コードと合致するものがない場合に、対応する前記第１の銘柄コードについて、前記第２の銘柄コードの中で重複するものがあるか否かを判定し、重複するものがある場合にはその旨を出力する、金融商品管理システム。
6. 他のファンドを組み入れているものを含むファンドの運用状況を管理する金融商品管理システムとして機能するよう、コンピュータに処理を実行させる金融商品管理プログラムであって、
   各ファンドの属性情報を記録するファンド管理処理と、
   クライアント端末からアップロードされた、もしくは他システムから取得した各ファンドの残高データを含むデータを記録するデータ連携処理と、
   １つ以上の第１のファンドに組み入れられている第２のファンドに係る残高を、前記各第１のファンドの前記第２のファンドに対する持分により按分して、前記第１のファンドおよび前記第２のファンドに係るルックスルー残高を計算して記録する按分処理と、を前記コンピュータに実行させる、金融商品管理プログラム。
7. 他の金融商品を組み入れているものを含む金融商品の運用状況を管理する金融商品管理システムであって、
   各金融商品の属性情報を記録する金融商品管理部と、
   クライアント端末からアップロードされた、もしくは他システムから取得した各金融商品の残高データを含むデータを記録するデータ連携部と、
   １つ以上の第１の金融商品に組み入れられている第２の金融商品に係る残高を、前記各第１の金融商品の前記第２の金融商品に対する持分により按分して、前記第１の金融商品および前記第２の金融商品に係るルックスルー残高を計算して記録する按分処理部と、を有する、金融商品管理システム。
8. 他の金融商品を組み入れているものを含む金融商品の運用状況を管理する金融商品管理システムであって、
   前記金融商品を運用する運用会社が使用する第１のサブシステムと、
   前記金融商品を保有する金融機関が使用する第２のサブシステムと、
   前記第１のサブシステムと前記第２のサブシステムとの間を中継する第３のサブシステムと、を有し、
   前記第１のサブシステムは、
   １つ以上の第１の金融商品に組み入れられている第２の金融商品に係る残高を、前記各第１の金融商品の前記第２の金融商品に対する持分により按分して計算された、前記第１の金融商品および前記第２の金融商品に係るルックスルー後残高から、前記金融機関に係るデータである金融機関用残高を抽出する金融機関用データ抽出部と、
   前記金融機関用残高と、前記金融商品および前記金融機関に係る開示可否の情報を含む開示属性と、を前記第３のサブシステムに送信する送信処理部と、を有し、
   前記第３のサブシステムは、前記第１のサブシステムから送信された前記金融機関用残高を、前記開示属性の内容に基づいて、対象となる１つ以上の前記第２のサブシステムに送信するダウンロード制御部を有し、
   前記第２のサブシステムは、前記第３のサブシステムから送信された前記金融機関残高を、前記金融機関が保有する金融商品全体の残高に対する割合で按分して、前記金融機関に係るリスク資産の残高を算出する按分処理部と、を有する、金融商品管理システム。
   
   
   

Images