以下に本発明の一実施形態について図面を参照して説明する。図1には、本実施形態のファンドラップシステム10およびその周辺システムの全体構成が示されている。図2は、顧客識別情報および運用口識別情報の説明図である。図3〜図14には、記憶手段40に含まれる各記憶手段41〜61の構成が示されている。また、図15は、注文データ作成タイミングの変更、図16および図17は、各日付の算出対象銘柄の変更の説明図である。図18には、スタイル変更の申込があった場合の処理の流れがフローチャートで示されている。さらに、図19〜図21は、金銭振替明細の作成処理の説明図であり、図22および図23には、金銭振替明細の作成処理の流れがフローチャートで示されている。
<ファンドラップシステム10およびその周辺システムの全体構成>
図1において、顧客に対してファンドラップサービスを提供する証券会社等の金融機関が運営・管理するファンドラップシステム10が設けられ、その周辺システムとして、ファンドラップシステム10と通信回線2を介して接続された金融商品(本実施形態では、ファンドラップサービスを行うので、投資信託となる。)の売買システム70が設けられている。
また、売買システム70には、通信回線3を介して金融商品情報提供システム90が接続されている。なお、金融商品情報提供システム90は、通信回線4を介してファンドラップシステム10と直接に接続されていてもよい。
さらに、ファンドラップシステム10には、通信回線であるネットワーク1を介して、顧客またはその入力代行者(証券会社等の金融機関の営業員やオペレータ等)が操作する1台または複数台(通常は、多数)の端末装置100が接続されるとともに、通信回線5またはネットワーク1を介して証券会社等の金融機関のシステム担当者が操作する1台または複数台の端末装置110が接続されている。
ここで、ネットワーク1は、本実施形態では、主としてインターネットを中心に構成され、有線であるか、無線であるか、有線・無線の混在型であるかは問わない。通信回線2は、LANやイントラネット等の社内ネットワークであるが、ネットワーク1としてもよく、専用線としてもよい。通信回線3,4は、ネットワーク1や社内ネットワークにより構成してもよく、専用線により構成してもよい。通信回線5は、LANやイントラネット等の社内ネットワークである。
ファンドラップシステム10は、1台または複数台のコンピュータにより構成され、ファンドラップサービスに関する各種処理を実行する処理手段20と、この処理手段20で使用する各種データを記憶する記憶手段40とを備えている。
このうち、処理手段20は、設定受付手段21と、イベント準備手段22と、リバランス手段23と、イベント反映手段24と、注文作成手段25と、日付算出手段26と、手数料算出手段27と、注文データ連携手段28と、約定処理手段29と、資産管理手段30と、金銭振替手段31と、帳票作成用データ連携手段32とを含んで構成されている。
これらの処理手段20に含まれる各手段21〜32は、ファンドラップシステム10を構成するコンピュータ本体の内部に設けられた中央演算処理装置(CPU)、およびこのCPUの動作手順を規定する1つまたは複数のプログラム、並びに、主メモリやキャッシュメモリ等の作業用メモリ等により実現される。なお、これらの各手段21〜32の詳細は、後述する。
また、記憶手段40は、主口座記憶手段41と、契約記憶手段42と、運用口記憶手段43と、金銭残高記憶手段44と、単価情報記憶手段45と、運用スタイル記憶手段46と、運用スタイル・資産クラス構成記憶手段47と、資産クラス銘柄構成記憶手段48と、イベント記憶手段49と、リバランス記憶手段50と、四半期フィー徴収記憶手段51と、注文管理記憶手段52と、注文明細記憶手段53と、注文データ記憶手段54と、定期受取明細記憶手段55と、金銭振替明細記憶手段56と、注文可否日記憶手段57と、約定・受渡日数記憶手段58と、運用口銘柄構成記憶手段59と、残高記憶手段60と、算出日付記憶手段61とを含んで構成されている。また、算出日付記憶手段61は、銘柄単位算出日付記憶手段61Aと、資産クラス単位算出日付記憶手段61Bと、運用口単位算出日付記憶手段61Cとを含んで構成されている。
これらの記憶手段40に含まれる各記憶手段41〜61は、例えばハードディスクドライブ(HDD)やソリッドステートドライブ(SSD)等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、例えば、DVD、CD、MO、磁気テープ等の他の記録媒体を採用してもよい。また、各記憶手段41〜61のデータ保存形式は、データベースでもよく、フラットファイル等のファイル形式でもよい。データベースとする場合には、各記憶手段41〜61をそれぞれ別々のデータベースとしてもよく、1つまたは幾つかのデータベース内の異なるテーブルとしてもよい。なお、これらの各記憶手段41〜61の詳細は、後述する。
売買システム70は、金融商品の売買取引の取次を行う証券会社等の金融機関の基幹システムであり、金融商品の注文受付、顧客の買付余力判断、注文作成、市場等への発注、約定処理、顧客の保有資産の残高管理等のような金融商品の売買に関する各種の処理を実行するが、本実施形態では、ファンドラップサービスを行うので、これらの各種機能のうちの投資信託の売買処理に関する機能を利用する。
この売買システム70は、1台または複数台のコンピュータにより構成され、売買処理手段71と、約定データ連携手段72と、売買システム側金銭振替手段73と、帳票作成手段74とを備えている。
これらの各手段71〜74は、売買システム70を構成するコンピュータ本体の内部に設けられた中央演算処理装置(CPU)、およびこのCPUの動作手順を規定する1つまたは複数のプログラム、並びに、主メモリやキャッシュメモリ等の作業用メモリ等により実現される。なお、これらの各手段71〜74の詳細は、後述する。
また、売買システム70は、注文データ記憶手段81と、約定データ記憶手段82と、帳票作成用データ記憶手段83と、帳票記憶手段84とを備えている。
これらの各記憶手段81〜84は、例えばハードディスクドライブ(HDD)やソリッドステートドライブ(SSD)等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、例えば、DVD、CD、MO、磁気テープ等の他の記録媒体を採用してもよい。また、各記憶手段81〜84のデータ保存形式は、データベースでもよく、フラットファイル等のファイル形式でもよい。なお、これらの各記憶手段81〜84の詳細は、後述する。
金融商品情報提供システム90は、本実施形態では、ファンドラップサービスを行うために必要となる金融商品の情報(例えば、投資信託の各銘柄の基準価額等)を提供するシステムの総称として用いており、具体的には、例えば、投資信託の運用会社のシステム、ファンドラップシステム10や売買システム50を運営・管理する会社(証券会社等の金融機関)内の他のシステム(例えば、ファンドラップサービス以外のサービスに関するデータ処理を実行するシステム等)、情報ベンダーのシステム等であり、これらのシステムは、それぞれ1台または複数台のコンピュータにより構成されている。
従って、例えば、投資信託の基準価額については、金融商品情報提供システム90としての投資信託の運用会社のシステムで計算され、その計算結果が、通信回線3を介して売買システム70へ送信され、さらに売買システム70を経由して通信回線2を介してファンドラップシステム10へ送信されるか、あるいは、通信回線4を介してファンドラップシステム10へ直接に送信されるようになっている。そして、投資信託の基準価額は、ファンドラップシステム10の単価情報記憶手段45(図5参照)に記憶され、顧客の保有資産の評価金額(残高金額)の算出に用いられる。また、株式や債券等の単価、あるいは、例えば、日経平均、NYダウ、原油価格等の各種の金融指標についての指標値については、AI等による注文回避期間(例えば、急激な相場変動があったとき等に注文を回避すべき期間であり、注文可否日記憶手段57に反映される期間)の判断材料や、顧客の保有資産のポートフォリオのリバランスを行う際の判断材料となる場合があるので、金融商品情報提供システム90としての情報ベンダーのシステムまたは自社内の他のシステムから提供され、ファンドラップシステム10の単価情報記憶手段45(図5参照)に記憶されるようになっている。
端末装置100,110は、コンピュータにより構成され、例えばマウスやキーボード等の入力手段と、例えば液晶ディスプレイ等の表示手段とを備えている。これらの端末装置100,110は、例えば、スマートフォン、タブレット端末、携帯情報端末(PDA)等の携帯機器でもよい。
<ファンドラップシステム10で取り扱う各種イベントの内容および処理の概略>
ファンドラップシステム10では、新規契約、増額、減額、運用口追加、運用口削除、スタイル変更、投資対象銘柄変更、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、定期受取、寄附申込、寄附先変更、寄附金額変更、寄附、定期積立申込、定期積立変更(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等の変更)、定期積立、リバランス判定基準乖離率変更、リバランス、四半期フィー徴収等の各種イベントを取り扱う。これらのイベントの内容および処理の概略は、以下の通りである。
新規契約は、顧客が運用口を1つまたは複数個設定し、各運用口についての運用スタイルおよび設定金額(運用する金額)を定め、これらの情報をシステムに登録するイベントである。各運用口についての設定金額の合計金額が、新規契約金額である。また、リバランス判定基準乖離率も設定する。なお、リバランス判定基準乖離率の設定は、本実施形態では、運用口単位の設定ではないが、運用口単位の設定としてもよい。この新規契約のイベントでは、新規契約の申込が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に新規契約のレコード(新規設定した各運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、新規運用開始日、新規契約時の設定金額(運用口単位)等を含む)が作成されるとともに、設定受付手段21により、主口座記憶手段41、契約記憶手段42、および運用口記憶手段43(図3参照)にレコードが作成され、設定した情報が登録される。その後、顧客により申込時に指定されてイベント記憶手段49(図7参照)に記憶されている新規運用開始日の前営業日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(新規契約なので、買注文である。)が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている各運用口の新規契約時の設定金額を用いて各運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、一部の金額は、契約時フィーとして徴収されるので、その金額分だけ、新規契約イベントでの買付金額は少なくなる。
増額は、新規契約後に運用口単位での設定金額の増額を行うイベントである。この増額の申込は、任意の時期に行うことができ、申込時に指定した運用開始日から、増額した状態での運用が開始される。この増額のイベントでは、増額の申込が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に増額のレコード(増額対象の運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、運用開始日、増額金額等を含む)が作成され、その後、そのレコードの情報を用いて、運用開始日の前営業日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(増額なので、買注文である。)が記憶される。また、イベント反映手段24により、運用口記憶手段43(図3参照)の増額対象の運用口のレコードにおける設定金額を、増額金額の分だけ増額させる更新処理を行う。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている増額金額を用いて増額対象の運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、増額の場合にも、一部の金額を、契約時フィーとして徴収してもよく、その場合には、その金額分だけ、増額イベントでの買付金額は少なくなる。
減額は、新規契約後に運用口単位での設定金額の減額を行うイベントである。この減額の申込は、任意の時期に行うことができ、申込日の翌営業日から、減額した状態での運用が開始される。この減額のイベントでは、減額の申込が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に減額のレコード(減額対象の運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、減額金額等を含む)が作成され、その後、そのレコードの情報を用いて、申込日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(減額なので、売注文である。)が記憶される。また、イベント反映手段24により、運用口記憶手段43(図3参照)の減額対象の運用口のレコードにおける設定金額を、減額金額の分だけ減額させる更新処理を行う。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている減額金額を用いて減額対象の運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
運用口追加は、新規契約後に運用口を追加し、追加する運用口についての運用スタイルおよび設定金額(運用する金額)を定め、これらの情報をシステムに登録するイベントである。この運用口追加の申込は、任意の時期に行うことができ、申込時に指定した運用開始日から、追加した運用口での運用が開始される。この運用口追加のイベントでは、運用口追加の申込が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に運用口追加のレコード(追加した運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、運用口追加時の設定金額、運用開始日等を含む)が作成されるとともに、設定受付手段21により、運用口記憶手段43(図3参照)に追加された運用口のレコードが作成され、設定した情報が登録される。その後、申込時に指定されてイベント記憶手段49(図7参照)に記憶されている運用開始日の前営業日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(運用口追加なので、買注文である。)が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている追加された運用口の設定金額を用いてその運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、一部の金額は、契約時フィーとして徴収されるので、その金額分だけ、運用口追加イベントでの買付金額は少なくなる。
運用口削除は、運用口を削除し、その運用口で運用されている投資信託を売却するイベントである。この運用口削除の申込は、任意の時期に行うことができる。この運用口削除のイベントでは、運用口削除の申込が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に運用口削除のレコード(削除対象の運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分等を含む)が作成され、その後、そのレコードの情報を用いて、申込日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(運用口削除なので、売注文である。)が記憶される。また、イベント反映手段24により、その時点で注文データ作成待機中の別のイベントがある場合には、当該別のイベントを抹消扱いとするため、当該別のイベントについて注文管理記憶手段52(図10参照)に記憶されているレコードにおける抹消フラグを「抹消」にする。さらに、イベント反映手段24により、運用口記憶手段43(図3参照)の削除対象の運用口のレコードにおける運用口ステータスを「運用終了」に変更する。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている運用口削除のレコードにおける注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、削除対象の運用口で運用されている全銘柄の全数量を売却する注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
スタイル変更は、運用口に設定された運用スタイルを変更するサービスのイベントである。このスタイル変更の申込は、任意の時期に行うことができ、申込みの翌月から適用される。このスタイル変更のイベントでは、スタイル変更の申込が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)にスタイル変更のレコード(スタイル変更対象の運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、変更前および変更後の運用スタイルコード(運用スタイル識別情報)等を含む)が作成され、その後、そのレコードの情報を用いて、申込が行われた月の月末営業日の夜間バッチ処理で、イベント反映手段24により、運用口銘柄構成記憶手段59(図14参照)にスタイル変更による銘柄構成の変更が反映されるとともに、注文管理記憶手段52(図10参照)に先ず売注文の注文日が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている売注文の注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている変更前後の運用スタイルコードを用いて売注文の注文データを作成し、注文データ作成日の翌営業日に、売注文の注文データを用いて注文する。続いて、全ての銘柄の売注文が約定したら、スタイル変更の売注文によるホールド期間が終了するので、その最遅約定日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に買注文の注文日が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている買注文の注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている変更前後の運用スタイルコードを用いて買注文の注文データを作成し、注文データ作成日の翌営業日に、買注文の注文データを用いて注文する。
投資対象銘柄変更は、運用口単位で、運用口を構成する資産クラス内の銘柄を変更するサービスのイベントである。運用スタイルと、資産クラスとの関係は、次の通りである。1つの運用口には、顧客が選択した1つの運用スタイルが設定されているが、その運用スタイルは、例えば、国内株式型の投資信託の資産クラスの配分比率が10%、海外株式型の投資信託の資産クラスの配分比率が30%、国内債券型の投資信託の資産クラスの配分比率が20%、海外債券型の投資信託の資産クラスの配分比率が40%等のように、複数の資産クラスにより構成されている。この運用スタイル内の設定構成比率は、図6に示すように、運用スタイルコードに紐付く資産クラスの配分比率として運用スタイル・資産クラス構成記憶手段47に記憶されている。
また、資産クラスは、例えば、銘柄Aの配分比率が50%、銘柄Bの配分比率が50%等のように、複数の銘柄により構成されている。この資産クラス内の設定構成比率は、図14に示すように、対象銘柄の資産クラス内での配分比率として運用口銘柄構成記憶手段59に記憶されている。従って、投資対象銘柄変更のイベントは、この資産クラス内の銘柄を変更するサービスであり、例えば、銘柄A,B(銘柄Aの配分比率50%、銘柄Bの配分比率50%)から、銘柄A,B,C(銘柄Aの配分比率40%、銘柄Bの配分比率30%、銘柄Cの配分比率30%)への乗換等を行うことができ、この場合には、銘柄A,Bを少しずつ売却して銘柄Cの買付を行うことになる。変更申込受付月の月末に売却注文を行い、売却注文の約定後に買付注文を行う。
この投資対象銘柄変更のイベントでは、投資対象銘柄変更の申込が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に投資対象銘柄変更のレコード(投資対象銘柄変更を行う運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、変更前および変更後の資産クラスコード等を含む)が作成され、その後、そのレコードの情報を用いて、申込が行われた月の月末営業日の夜間バッチ処理で、イベント反映手段24により、運用口銘柄構成記憶手段59(図14参照)に投資対象銘柄変更による銘柄構成の変更が反映されるとともに、注文管理記憶手段52(図10参照)に先ず売注文の注文日が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている売注文の注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている変更前後の資産クラスコードを用いて売注文の注文データを作成し、注文データ作成日の翌営業日に、売注文の注文データを用いて注文する。続いて、全ての銘柄の売注文が約定したら、投資対象銘柄変更の売注文によるホールド期間が終了するので、その最遅約定日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に買注文の注文日が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている買注文の注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段49(図7参照)に記憶されている変更前後の資産クラスコードを用いて買注文の注文データを作成し、注文データ作成日の翌営業日に、買注文の注文データを用いて注文する。
定期受取は、顧客が指定した月(定期受取月)に、投資信託を売却し、売却で得られた資金を顧客が受け取るイベントであり、より詳細には、この定期受取に関するイベントには、例えば、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、定期受取等の各イベントがある。ここでいう定期受取申込と、定期受取とは、発生時期および趣旨の異なるイベントであり、定期受取申込は、定期受取の内容を登録するための申込のイベントであるのに対し、定期受取は、登録情報に基づき定期受取を所定の時期(本実施形態では、定期受取月の前月の月末)に発生させるためのイベントであり、また、定期受取タイミング変更や、定期受取指定金額変更は、登録した内容を変更するイベントである。なお、本願の説明では、特にこれらを区別することなく、まとめて定期受取のイベント(広義)と呼ぶことがある。定期受取のイベント(狭義)は、本実施形態では、売注文を伴う月末イベントである。
定期受取申込のイベントでは、定期受取申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に定期受取申込のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、定期受取タイミング、定期受取指定金額等を含む:これらの定期受取タイミング、定期受取指定金額は、申込当初における初期設定の値であるが、変更前または変更後の値のカラムに代用記憶させてもよい)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に既に作成されている対象運用口のレコードに、定期受取の登録情報(定期受取タイミング、定期受取指定金額等)が記憶される。
定期受取のイベント(狭義)では、イベント準備手段22により、運用口記憶手段43(図3参照)に記憶されている定期受取の登録情報を用いて、所定の時期(少なくとも、運用口記憶手段43(図3参照)に記憶されている定期受取タイミングで定まる定期受取月の前月の月末営業日またはそれよりも前の日)に、イベント記憶手段49(図7参照)に定期受取のイベント(狭義)のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、定期受取判定年月日等を含む:本実施形態では、この定期受取判定年月日には、定期受取月の前月の月末営業日が設定される)が作成される。さらに、イベント記憶手段49(図7参照)に記憶されている定期受取判定年月日の夜間バッチ処理で、イベント準備手段22により、当月に定期受取を実施するか否かの判定処理(受取自体は、翌月となるので、当月にそのための注文データ作成処理を行うか否かの判定処理)が行われ、その定期受取判定結果が、イベント記憶手段49(図7参照)に既に作成されている定期受取のレコードに記憶される。続いて、イベント記憶手段49(図7参照)に記憶されている定期受取判定結果が、定期受取を実施する(当月に定期受取に伴う売却注文データを「作成する」)という結果である場合には、定期受取判定年月日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(定期受取なので、売注文である。)が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、運用口記憶手段43(図3参照)またはイベント記憶手段49(図7参照)に記憶されている定期受取指定金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
定期受取タイミング変更のイベントでは、定期受取タイミング変更の申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に定期受取タイミング変更のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、変更前および変更後の定期受取タイミング等を含む)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取タイミングについての変更処理が行われる。定期受取タイミングは、各運用口の定期受取タイミングが、例えば、毎月、隔月(奇数月)、隔月(偶数月)、3ヶ月毎、6ヶ月毎、12ヶ月毎等であることを示す情報である。
定期受取指定金額変更のイベントでは、定期受取指定金額変更の申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に定期受取指定金額変更のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、変更前および変更後の定期受取指定金額等を含む)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取指定金額についての変更処理が行われる。
寄附は、投資信託を売却し、売却で得られた資金を、顧客により指定された寄附先へ寄付するイベントであり、より詳細には、この寄附に関するイベントには、例えば、寄附申込、寄附先変更、寄附金額変更、寄附等の各イベントがある。ここでいう寄附申込と、寄附とは、発生時期および趣旨の異なるイベントであり、寄附申込は、寄附の内容を登録するための申込のイベントであるのに対し、寄附は、登録情報に基づき寄附を所定の時期(本実施形態では、月末)に発生させるためのイベントであり、また、寄附先変更や、寄附金額変更は、登録した内容を変更するイベントである。なお、本願の説明では、特にこれらを区別することなく、まとめて寄附のイベント(広義)と呼ぶことがある。寄附のイベント(狭義)は、本実施形態では、売注文を伴う月末イベントである。
寄附申込のイベントでは、寄附申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に寄附申込のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、寄附先、寄附金額等を含む:これらの寄附先、寄附金額は、申込当初における初期設定の値であるが、変更前または変更後の値のカラムに代用記憶させてもよい)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に既に作成されている対象運用口のレコードに、寄附の登録情報(寄附先、寄附金額等)が記憶される。
寄附のイベント(狭義)では、イベント準備手段22により、運用口記憶手段43(図3参照)に記憶されている寄附の登録情報を用いて、所定の時期(少なくとも、寄附月の前月の月末営業日またはそれよりも前の日)に、イベント記憶手段49(図7参照)に寄附のイベント(狭義)のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、寄附計算処理年月日等を含む:この寄附計算処理年月日には、本実施形態では、寄附月の前月の月末営業日が設定される)が作成される。続いて、イベント記憶手段49(図7参照)に記憶されている寄附計算処理年月日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(寄附なので、売注文である。)が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、運用口記憶手段43(図3参照)またはイベント記憶手段49(図7参照)に記憶されている寄附金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
寄附先変更のイベントでは、寄附先変更の申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に寄附先変更のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、変更前および変更後の寄附先等を含む)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける寄附の登録情報のうちの寄附先についての変更処理が行われる。寄附先は、各運用口の寄附先(寄附のテーマ)が、例えば、食料支援、医療、環境、子供支援、災害復興等であることを示す情報である。
寄附金額変更のイベントでは、寄附金額変更の申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に寄附金額変更のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、変更前および変更後の寄附金額等を含む)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける寄附の登録情報のうちの寄附金額についての変更処理が行われる。
定期積立は、顧客が指定した月の指定した日に、定期的に投資信託の買付を行い、運用口単位での設定金額の増額を行うイベントであり、増額のイベントを定期的に繰り返すことに相当する。より詳細には、この定期積立に関するイベントには、例えば、定期積立申込、定期積立変更(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等の変更)、定期積立等の各イベントがある。ここでいう定期積立申込と、定期積立とは、発生時期および趣旨の異なるイベントであり、定期積立申込は、定期積立の内容を登録するための申込のイベントであるのに対し、定期積立は、登録情報に基づき定期積立を所定の時期(指定月の定期積立設定日の前営業日)に発生させるためのイベントであり、また、定期積立変更は、登録した内容(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等)を変更するイベントである。なお、本願の説明では、特にこれらを区別することなく、まとめて定期積立のイベント(広義)と呼ぶことがある。
定期積立申込のイベントでは、定期積立申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に定期積立申込のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等を含む:これらの定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額は、申込当初における初期設定の値であるが、変更前または変更後の値のカラムに代用記憶させてもよい)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に既に作成されている対象運用口のレコードに、定期積立の登録情報(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等)が記憶される。
定期積立のイベント(狭義)では、イベント準備手段22により、運用口記憶手段43(図3参照)に記憶されている定期積立の登録情報を用いて、所定の時期(少なくとも、指定月の定期積立設定日の前営業日またはそれよりも前の日)に、イベント記憶手段49(図7参照)に定期積立のイベント(狭義)のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、定期積立設定日等を含む:この定期積立設定日は、定期積立変更のイベントではないが、変更前または変更後の定期積立設定日のカラムに代用記憶させてもよい)が作成される。続いて、イベント記憶手段49(図7参照)に記憶されている定期積立設定日の前営業日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(定期積立なので、買注文である。)が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、運用口記憶手段43(図3参照)またはイベント記憶手段49(図7参照)に記憶されている毎月の定期積立金額やボーナス月の定期積立加算金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
定期積立変更のイベントでは、定期積立変更の申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)に定期積立変更のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分等を含むとともに、変更する項目に応じ、変更前および変更後の定期積立タイミング、変更前および変更後の定期積立設定日、変更前および変更後の毎月の定期積立金額、あるいは、変更前および変更後のボーナス月の定期積立加算金額等を含む)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける定期積立の登録情報のうちの変更項目(定期積立タイミング、定期積立設定日、毎月の定期積立金額、あるいは、ボーナス月の定期積立加算金額等)についての変更処理が行われる。定期積立タイミングは、積立のための買付を毎月行うのか、あるいはそれ以外のパターン(例えば、隔月等)で行うのか等を示す情報である。定期積立設定日は、毎月(指定月)の投資信託の買付日である。定期積立金額は、毎月(指定月)の投資信託の買付金額であり、定期積立加算金額は、ボーナス月に毎月(指定月)の定期積立金額に加算する買付金額である。
リバランス判定基準乖離率変更は、リバランスで使用するリバランス判定基準乖離率を変更するイベントである。このリバランス判定基準乖離率変更の申込(申込時期は任意)が行われると、設定受付手段21により、その申込が受け付けられてイベント記憶手段49(図7参照)にリバランス判定基準乖離率変更のレコード(対象運用口についての運用口ファンドコード(運用口識別情報)、自動付与したイベント番号、イベント区分、変更前および変更後のリバランス判定基準乖離率等を含む)が作成され、その後、そのレコードの情報を用いて、イベント反映手段24により、契約記憶手段42(図3参照)に記憶されているリバランス判定基準乖離率(従って、リバランス判定基準乖離率は、本実施形態では、運用口単位ではないが、運用口単位としてもよい。)についての変更処理が行われる。
リバランスは、運用口を構成する投資信託の各銘柄によるポートフォリオ(各銘柄の構成比率)が、顧客との契約に基づく運用スタイルに沿った配分比率と乖離しているときに、そのときの乖離率が、リバランス判定基準乖離率の範囲内に収まっていない場合に、運用口を構成する投資信託の各銘柄の売買を行い、運用口のポートフォリオを、運用スタイルに沿った配分比率に修正するイベントである。すなわち、運用スタイルに沿った配分比率よりも構成比率(保有比率)が大きくなっている銘柄を売却し、その売却で得られた金額を用いて、運用スタイルに沿った配分比率よりも構成比率が小さくなっている銘柄を買い付けるイベントである。
リバランスのイベントでは、リバランス手段23により、所定の時期(少なくとも、毎月の月末営業日またはそれよりも前の日)に、リバランス記憶手段50(図8参照)にレコード(自動付与したリバランス番号(リバランスイベントの識別情報)、対象運用口についての運用口ファンドコード(運用口識別情報)、リバランス実施判定年月日等を含む:本実施形態では、このリバランス実施判定年月日には、月末営業日が設定される)が作成される。さらに、リバランス記憶手段50(図8参照)に記憶されているリバランス実施判定年月日の夜間バッチ処理で、リバランス手段23により、当月にリバランスを実施するか否かの判定処理が行われ、そのリバランス実施判定結果が、リバランス記憶手段50(図8参照)に既に作成されているレコードに記憶される。続いて、リバランス記憶手段50(図8参照)に記憶されているリバランス実施判定結果が、リバランス要という結果である場合には、リバランス実施判定年月日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に先ず売注文の注文日が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている売注文の注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、注文作成手段25により、残高記憶手段60(図14参照)に記憶された運用口の各保有銘柄の残高数量についての売注文の注文データ作成タイミング判断時点での基準価額による評価金額、並びに、運用口銘柄構成記憶手段59(図14参照)および運用スタイル・資産クラス構成記憶手段47(図6参照)に記憶されている設定構成比率を用いて、リバランスの売注文の注文データを作成し、注文データ作成日の翌営業日に、売注文の注文データを用いて注文する。続いて、全ての銘柄の売注文が約定したら、リバランスの売注文によるホールド期間が終了するので、その最遅約定日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に買注文の注文日が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている買注文の注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、注文作成手段25により、残高記憶手段60(図14参照)に記憶された運用口の各保有銘柄の残高数量についての買注文の注文データ作成タイミング判断時点での基準価額による評価金額、並びに、運用口銘柄構成記憶手段59(図14参照)および運用スタイル・資産クラス構成記憶手段47(図6参照)に記憶されている設定構成比率を用いて、リバランスの買注文の注文データを作成し、注文データ作成日の翌営業日に、買注文の注文データを用いて注文する。
四半期フィー徴収は、新規契約時や運用口追加時に徴収する契約時フィーとは別に、運用期間の経過に伴って四半期毎に徴収する四半期フィーを確保するために、投資信託の売却を行うイベントである。より一般には、区切りの期間長は、四半期に限らず、例えば半年等でもよいので、期間フィー徴収のイベントである。契約時フィーおよび四半期フィー(より一般には、期間フィー)は、いずれもファンドラップサービスを提供する証券会社等の金融機関が顧客から徴収するフィーであるが、契約時フィーの場合は、新規契約時や運用口追加時(増額時も同様)に顧客からの入金があるので、その一部をフィー徴収に当てるのに対し、四半期フィー(期間フィー)の場合は、入金があるわけではないので、顧客が保有している運用中の投資信託を売却してフィー徴収に当てる。四半期フィー徴収(期間フィー徴収)のイベントは、本実施形態では、売注文を伴う月末イベントである。
四半期フィー徴収のイベントでは、イベント準備手段22により、所定の時期(少なくとも、四半期フィー徴収月の月末営業日またはそれよりも前の日)に、四半期フィー徴収記憶手段51(図9参照)にレコード(自動付与した四半期フィー徴収番号(四半期フィー徴収イベントの識別情報)、対象運用口についての運用口ファンドコード(運用口識別情報)、四半期フィー計算処理年月日等を含む:本実施形態では、この四半期フィー計算処理年月日には、四半期フィー徴収月の月末営業日が設定される)が作成される。さらに、四半期フィー徴収記憶手段51(図9参照)に記憶されている四半期フィー計算処理年月日の夜間バッチ処理で、手数料算出手段27により、四半期フィーの算出処理が行われ、算出された四半期フィーの金額が、算出手数料記憶手段(不図示)に記憶される。続いて、四半期フィー計算処理年月日の夜間バッチ処理で、イベント反映手段24により、注文管理記憶手段52(図10参照)に注文日(四半期フィー徴収なので、売注文である。)が記憶される。そして、注文作成手段25により、注文管理記憶手段52(図10参照)に記憶されている注文日(海外休場日を考慮)を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、算出手数料記憶手段(不図示)に記憶されている四半期フィーの金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、四半期フィーの金額は小さいので、運用スタイルに沿ったポートフォリオから最も大きく乖離している銘柄の売却だけでよい。
<ファンドラップシステム10の詳細構成>
<ファンドラップシステム10/処理手段20/設定受付手段21の構成>
設定受付手段21は、顧客またはその入力代行者(証券会社等の金融機関の営業員やオペレータ等)により入力されて端末装置100からネットワーク1を介して送信されてくる顧客の設定情報(各種イベントの申込を含む)を受け付け、記憶手段40に登録する処理を実行するものである。
また、設定受付手段21は、日中のオンライン入力で各種イベント(減額系イベント)の申込を受け付ける際に、前営業日の夜間バッチ処理で算出されて算出日付記憶手段61(図14参照)に記憶されている注文日、最遅約定日、および最遅受渡日を、端末装置100に画面表示する処理を実行する。なお、これらの注文日、最遅約定日、および最遅受渡日は、詳細は後述するが、海外休場日を考慮した日付である。
具体的には、設定受付手段21は、新規契約の申込を受け付けた場合には、受け付けた情報をイベント記憶手段49(図7参照)に記憶させる(レコードの作成を含む)とともに、新規契約に伴う各種の設定情報を、主口座記憶手段41、契約記憶手段42、運用口記憶手段43(図3参照)に記憶させる(レコードの作成を含む)。より詳細には、設定受付手段21は、例えば、自動付与した口座ファンドコード、ログイン時に入力された顧客の口座番号(顧客識別情報)を、主口座記憶手段41(図3参照)に記憶させる(レコードの作成を含む)。また、設定受付手段21は、例えば、自動付与した契約ファンドコード、顧客の口座番号、顧客が選択したサービスについてのサービス種類区分、新規契約年月日、新規契約金額(新規契約時における各運用口の設定金額の合計金額)、契約ファンドコードに紐付く口座ファンドコード、リバランス判定基準乖離率(リバランス判定の基準となる乖離率:%単位)等を、契約記憶手段42(図3参照)に記憶させる(レコードの作成を含む)。
さらに、設定受付手段21は、例えば、自動付与した運用口ファンドコード(運用口識別情報)、顧客の口座番号、サービス種類区分、自動付与した運用口1,2,…を識別するための連続番号である運用口番号、顧客が命名した運用口の愛称等を示すテキストデータである運用口名称、顧客が選択した運用スタイル区分、顧客が選択した運用スタイル(安定型、やや安定型、バランス型、やや積極型、積極型、…等のうちのいずれか)を識別するための運用スタイルコード(運用スタイル識別情報)、運用口ステータス、運用口単位の設定金額(運用口で運用する金額:各時点での金額であり、更新される金額)、運用口ファンドコードに紐付く契約ファンドコード、当初設定金額(新規契約時または運用口追加時の設定金額)等を、運用口記憶手段43(図3参照)に記憶させる(レコードの作成を含む)。複数の運用口を設定する場合には、運用口記憶手段43(図3参照)へのレコード作成は、運用口毎に行われる。
なお、新規契約時ではなく、運用開始後に運用口追加の申込を受け付けた場合にも、設定受付手段21は、受け付けた情報をイベント記憶手段49(図7参照)に記憶させる(レコードの作成を含む)とともに、追加した運用口についての上記の各種の設定情報を、運用口記憶手段43(図3参照)に記憶させる(レコードの作成を含む)。従って、運用口追加を行った場合には、追加した運用口の個数分だけ、運用口記憶手段43(図3参照)のレコードが追加される。
また、設定受付手段21は、新規契約や運用口追加の申込を受け付けるだけではなく、増額、減額、運用口削除、スタイル変更、投資対象銘柄変更、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、寄附申込、寄附先変更、寄附金額変更、定期積立申込、定期積立変更(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等の変更)、リバランス判定基準乖離率変更(本実施形態では、リバランス判定基準乖離率は、運用口単位の設定ではない)等の各種イベントの申込を受け付け、受け付けたイベントのレコードをイベント記憶手段49(図7参照)に作成し、当該イベントに対して付与したイベント番号、イベント区分、イベントステータス(申請中、成立、不成立、取消済、…)、運用口ファンドコード(運用口識別情報)、顧客の口座番号(顧客識別情報)、契約ファンドコード、運用開始日、イベントに関する各種金額(新規契約時や運用口追加時の運用口単位の設定金額、運用口単位の増額金額、運用口単位の減額金額等)、変更前後の内容(金額、タイミング、コード、乖離率、日付等の変更内容)等を記憶させる。
設定受付手段21により各種イベントの申込の受付処理を行ってイベント記憶手段49(図7参照)に記憶された情報は、イベント反映手段24によりバッチ処理(本実施形態では、夜間に実行する夜間バッチ処理)で反映される情報が多いが、本実施形態では、前述したように、主口座記憶手段41および契約記憶手段42(図3参照)へのレコード作成、並びに、新規契約時および運用口追加時の運用口記憶手段43(図3参照)へのレコード作成については、イベント反映手段24ではなく、設定受付手段21により実行するものとしている。なお、運用口記憶手段43(図3参照)に既に作成されている対象運用口のレコードへの各種設定情報の登録処理については、設定受付手段21ではなく、イベント反映手段24により実行するものとするので、例えば、定期受取申込のイベントにおいて運用口記憶手段43(図3参照)のレコードに定期受取の登録情報(定期受取タイミング、定期受取指定金額等)を記憶させる処理、寄附申込のイベントにおいて運用口記憶手段43(図3参照)のレコードに寄附の登録情報(寄附先、寄附金額等)を記憶させる処理、定期積立申込のイベントにおいて運用口記憶手段43(図3参照)のレコードに定期積立の登録情報(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等)を記憶させる処理は、イベント反映手段24により実行する。
また、設定受付手段21は、前述したように、定期受取申込、寄附申込、定期積立申込のイベントについての申込を受け付け、これらのイベントのレコードを作成してイベント記憶手段49(図7参照)に記憶させるが、定期受取(狭義)、寄附(狭義)、定期積立(狭義)のイベントについては、既に詳述したように、顧客またはその入力代行者からのオンライン入力での申込を受け付けるのではなく、所定の時期(月末またはその前)が到来したときに、既に登録されている情報に基づきイベントの準備処理を行うので、設定受付手段21ではなく、イベント準備手段22により、これらのイベントのレコードを作成してイベント記憶手段49(図7参照)に記憶させる。また、四半期フィー徴収(より一般には、期間フィー徴収)のイベントについても、顧客またはその入力代行者からのオンライン入力での申込を受け付けるのではなく、所定のフィー徴収時期が到来したときにイベントの準備処理を行うので、同様であり、設定受付手段21ではなく、イベント準備手段22により、イベント記憶手段49(図7参照)へのレコード作成を行う。
さらに、運用口記憶手段43(図3参照)には、運用口における月末ホールド期間の設定情報(期間の設定年月日等)が記憶されるが、この月末ホールド期間は、特定のイベントに基づき設定される期間ではないため、月末が近づいた際に、設定受付手段21が設定する。また、運用口記憶手段43(図3参照)には、運用口について注文データの作成を行うことができない期間である約定ベースホールド期間の設定情報(期間の終了年月日等)が記憶されるが、この約定ベースホールド期間は、注文データの作成が行われた際に、その注文が約定するまで(複数の注文データの作成が行われた場合には、それらの注文が全て約定するまで)、別の注文データの作成を制限する期間であるため、注文作成手段25が設定する。
図2に示すように、設定受付手段21により自動付与される口座ファンドコード、契約ファンドコード、運用口ファンドコードは、互いに紐付けられ、この順で上位層から下位層へと向かう階層構造を形成する。但し、口座ファンドコード、契約ファンドコード、運用口ファンドコードは、互いに重ならないように、3つのコードを合わせた状態で連続番号となるように自動付与される。なお、これらのコードは、実際には、例えば10桁程度のコードであるが、以下では、説明の便宜上、3桁で説明する。
具体的には、例えば、顧客である大和太郎が、ファンドラップサービスについて新規契約をし、幾つか用意されたファンドラップサービスのうちの「ファンドラッププレミアム」というサービスを選択し、2つの運用口1,2を設定し、運用口1については、運用スタイルAを選択し、運用口2については、運用スタイルBを選択したとする。このとき、設定受付手段21は、口座ファンドコード=001を自動付与し、大和太郎の主口座の口座番号(例えば、証券会社に開設された証券総合口座の口座番号)とともに、主口座記憶手段41(図3参照)に記憶させる。また、契約ファンドコード=002を自動付与し、既に自動付与した口座ファンドコード=001とともに、契約記憶手段42(図3参照)に記憶させる。さらに、運用スタイルAを選択した運用口1に対し、運用口ファンドコード=003を自動付与し、運用スタイルBを選択した運用口2に対し、運用口ファンドコード=004を自動付与し、既に自動付与した契約ファンドコード=002とともに、運用口記憶手段43(図3参照)に記憶させる。
続いて、例えば、別の顧客である大和花子が、ファンドラップサービスについて新規契約をし、幾つか用意されたファンドラップサービスのうちの「ファンドラッププレミアム」というサービスを選択し、2つの運用口1,2を設定し、運用口1については、運用スタイルCを選択し、運用口2については、運用スタイルDを選択したとする。このとき、設定受付手段21は、口座ファンドコード=005を自動付与し、大和花子の主口座の口座番号とともに、主口座記憶手段41(図3参照)に記憶させる。また、契約ファンドコード=006を自動付与し、既に自動付与した口座ファンドコード=005とともに、契約記憶手段42(図3参照)に記憶させる。さらに、運用スタイルCを選択した運用口1に対し、運用口ファンドコード=007を自動付与し、運用スタイルDを選択した運用口2に対し、運用口ファンドコード=008を自動付与し、既に自動付与した契約ファンドコード=006とともに、運用口記憶手段43(図3参照)に記憶させる。
その後、最初の顧客である大和太郎が、幾つか用意されたファンドラップサービスのうちの別のサービスである「ファンドラップオンライン」というサービスを選択し、運用口1を設定し、運用スタイルEを選択したとする。このとき、設定受付手段21は、契約ファンドコード=009を自動付与し、既に自動付与した口座ファンドコード=001とともに、契約記憶手段42(図3参照)に記憶させる。さらに、運用スタイルEを選択した運用口1に対し、運用口ファンドコード=010を自動付与し、既に自動付与した契約ファンドコード=009とともに、運用口記憶手段43(図3参照)に記憶させる。なお、ファンドラップサービスには、幾つかの種類があり、例えば、「ファンドラッププレミアム」サービス(サービス種類区分=01)は、契約金額が大きく(例えば3,000万円以上1万円単位)、運用口を最大5つまで設定することができ、「ファンドラップオンライン」サービス(サービス種類区分=02)は、契約金額が小さく(1万円以上1円単位)、運用口は1つしか設定できない等の相違がある。但し、これらは、一例であり、例えば、運用口の最大設定数は5つに限らず、それ以上またはそれ以下の個数としてもよく、全てのファンドラップサービスについて、複数の運用口を設定できるようにしてもよく、契約金額の大小も任意である。大和太郎という1人の顧客が、複数種類のファンドラップサービスを同時期に利用することは、稀ではあるが、現実に存在するケースである。
さらに、その後に、最初の顧客である大和太郎が、既に契約している「ファンドラッププレミアム」サービスについて、運用口3を追加して設定し、運用口3について、運用スタイルFを選択したとする。このとき、設定受付手段21は、運用スタイルFを選択した運用口3に対し、運用口ファンドコード=011を自動付与し、既に自動付与した契約ファンドコード=002とともに、運用口記憶手段43(図3参照)に記憶させる。
従って、運用口ファンドコードは、全ての顧客の全ての契約の全ての運用口に対し、重ならないように自動付与されているので、運用口識別情報として機能する。また、口座ファンドコード、契約ファンドコード、運用口ファンドコードは、階層化されているので、運用口記憶手段43、契約記憶手段42、主口座記憶手段41という順で、運用口ファンドコードから契約ファンドコードを辿り、契約ファンドコードから口座ファンドコードを辿り、口座ファンドコードから主口座の口座番号(顧客識別情報)を辿ることができるので、これらの3つのファンドコードは、3つ合わせて顧客識別情報として機能するといえるか、あるいは、3つ合わせて顧客識別情報を特定することができる識別情報であるといえる。従って、本発明(請求項)における「顧客識別情報に関連付けて記憶する」という記載については、これらの3つのファンドコードから顧客識別情報に辿り着くことができるように記憶されているという意味を含んでいるため、必ずしも同じレコード内に、顧客識別情報(本実施形態では、主口座の口座番号)自体が存在することを意味しない。このため、あるレコードに、運用口ファンドコードが記憶されていれば、それは運用口識別情報として機能し、かつ、その運用口ファンドコードは、別のレコードに記憶されている顧客識別情報(本実施形態では、主口座の口座番号)を特定するための識別情報としても機能することになり、この状態をもって、本発明(請求項)において「顧客識別情報および運用口識別情報に関連付けて記憶する」という記載となっている。
また、設定受付手段21は、証券会社等の金融機関のシステム担当者により入力されて端末装置110から通信回線5またはネットワーク1を介して送信されてくるシステム設定情報を受け付け、記憶手段40に登録する処理も実行する。
具体的には、設定受付手段21は、運用スタイルに関する設定情報として、例えば、サービス種類区分(「ファンドラッププレミアム」サービス=01、「ファンドラップオンライン」サービス=02、…)、運用スタイル区分(共通スタイル=1、個別スタイル(1)=2、個別スタイル(2)=3、…)、運用スタイルコード(運用スタイル識別情報)、当該運用スタイルに対してシステム担当者が命名したテキストデータである運用スタイル名称(安定型、やや安定型、バランス型、やや積極型、積極型、…)、当該運用スタイルに適用される手数料率を識別するための手数料コード(手数料率識別情報)等を、運用スタイル記憶手段46(図6参照)に記憶させる(レコードの作成を含む)。
なお、運用スタイル区分は、全ての顧客に適用可能なデフォルトの共通スタイル(運用スタイル区分=1)と、特定の顧客に適用する個別スタイル(1),(2)…(運用スタイル区分=2,3,…)とがあるが、特にこのような区分を設けなくてもよい。また、運用スタイルには、例えば、安定型、やや安定型、バランス型、やや積極型、積極型等の各種名称の運用スタイルがあり、実際には、非常に多数(例えば、400個程度)の運用スタイルが用意されているが、システムとして用意する運用スタイルの個数は任意であり、顧客は、運用口毎に異なる運用スタイルを選択するので、少なくとも顧客1人当たりの運用口の最大設定数(例えば5つ)と同数の運用スタイルが用意されていればよい。
また、設定受付手段21は、運用スタイルと資産クラスとの関係を示す設定情報として、例えば、運用スタイルコード(運用スタイル識別情報)と、資産クラスコード(資産クラス識別情報)と、設定構成比率(運用スタイルコードに紐付く資産クラスの配分比率:%単位)とを関連付けて、運用スタイル・資産クラス構成記憶手段47(図6参照)に記憶させる(レコードの作成を含む)。
さらに、設定受付手段21は、資産クラスに関する設定情報として、例えば、資産クラスコード(資産クラス識別情報)と、資産クラスを構成する投資信託の銘柄コード(銘柄識別情報)とを関連付けて、資産クラス銘柄構成記憶手段48(図6参照)に記憶させる(レコードの作成を含む)。
また、設定受付手段21は、手数料率に関する設定情報として、例えば、手数料コード(手数料率識別情報)と、手数料率(投資顧問料率、取引等管理手数料率)とを関連付けて、手数料率記憶手段(不図示)に記憶させる(レコードの作成を含む)。
<ファンドラップシステム10/処理手段20/イベント準備手段22の構成>
イベント準備手段22は、イベント毎の所定の時期が到来したときに、既に登録されている情報に基づき、各イベントのレコードを作成してイベント記憶手段49(図7参照)に記憶させるイベント準備処理を実行するものである。前述した設定受付手段21が、顧客またはその入力代行者からのオンライン入力での申込を受け付けて処理を実行するのに対し、このイベント準備手段22は、申込に基づくのではなく、登録情報に基づき所定の時期の到来をシステムで判断して処理を実行する点が異なっている。
具体的には、イベント準備手段22は、定期受取(狭義)、寄附(狭義)、定期積立(狭義)、四半期フィー徴収のイベントについてのレコードを作成してイベント記憶手段49(図7参照)に記憶させる。このうち、定期受取(狭義)、寄附(狭義)、四半期フィー徴収は、売注文を伴う月末イベント(本実施形態では、月末に処理を実行するイベント)であり、定期積立(狭義)は、買注文を伴うイベントである。イベント記憶手段49(図7参照)に作成した各イベントのレコードに記憶させる情報は、イベント毎に異なるが、各イベントの内容説明で既に述べているため、ここでは個々のイベント毎の説明は省略する。
なお、既に詳述したように、定期受取(狭義)、寄附(狭義)、定期積立(狭義)のイベントは、設定受付手段21により申込を受け付ける定期受取申込、寄附申込、定期積立申込のイベントとは発生時期および趣旨の異なるイベントである。
また、イベント準備手段22は、定期受取(狭義)のイベントでは、イベント記憶手段49(図7参照)に記憶されている定期受取のレコードにおける定期受取判定年月日になったか否かを判断し、定期受取判定年月日になったと判断した場合にその日の夜間バッチ処理で、当月に定期受取を実施するか否かの判定処理(受取自体は、翌月となるので、当月にそのための注文データ作成処理を行うか否かの判定処理)を実行し、その定期受取判定結果を、イベント記憶手段49(図7参照)に既に作成されている定期受取のレコードに記憶させる処理を実行する。
この際、定期受取判定年月日は、イベント準備手段22により、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取タイミング(例えば、毎月、隔月(奇数月)、隔月(偶数月)、3ヶ月毎、6ヶ月毎、12ヶ月毎等の別を示す情報)を参照して決定し、イベント記憶手段49(図7参照)の定期受取のレコードに記憶させた情報である。また、イベント準備手段22による当月に定期受取を実施するか否かの判定処理は、残高記憶手段60(図14参照)に記憶された保有資産の状況(運用状況)や、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取指定金額等を用いて実行される。
<ファンドラップシステム10/処理手段20/リバランス手段23の構成>
リバランス手段23は、所定の時期(少なくとも、毎月の月末営業日またはそれよりも前の日)に、リバランス記憶手段50(図8参照)に各運用口のリバランスイベントのレコードを作成するリバランスイベント準備処理を実行するものである。このレコードには、自動付与したリバランス番号(リバランスイベントの識別情報)、対象運用口についての運用口ファンドコード(運用口識別情報)、リバランス実施判定年月日等を記憶させる。本実施形態では、リバランス実施判定年月日には、月末営業日を設定する。
また、リバランス手段23は、リバランス記憶手段50(図8参照)に記憶されているリバランス実施判定年月日になったか否かを判断し、リバランス実施判定年月日になったと判断した場合にその日の夜間バッチ処理で、当月にリバランスを実施するか否かのリバランス判定処理を実行し、そのリバランス実施判定結果(要・不要の別)を、リバランス記憶手段50(図8参照)に既に作成されているレコードに記憶する処理を実行する。
この際、リバランス手段23によるリバランス判定処理では、運用口を構成する投資信託の各銘柄による運用中のポートフォリオ(各銘柄の構成比率)と、顧客との契約に基づく運用スタイルに沿った目標(所望)のポートフォリオにおける各銘柄の配分比率との乖離率のうち、乖離率が最も大きい銘柄の乖離率が、契約記憶手段42(図3参照)に記憶されているリバランス判定基準乖離率の範囲内に収まっているか否かを判断し、収まっていない場合には、リバランス要と判定し、収まっている場合には、リバランス不要と判定する。
ここで、前者の運用中のポートフォリオ(各銘柄の構成比率)は、残高記憶手段60(図14参照)に記憶されている各銘柄の残高数量(保有口数)と、単価情報記憶手段45(図5参照)に記憶されている各銘柄の最新の基準価額とを乗じることにより得られた各銘柄の評価金額を用いて算出するか、または、各銘柄の評価金額が残高記憶手段60(図14参照)に記憶されている場合には、それらの評価金額を用いて算出する。
また、後者の顧客との契約に基づく運用スタイルに沿った目標(所望)のポートフォリオにおける各銘柄の配分比率は、運用スタイル・資産クラス構成記憶手段47(図6参照)に記憶されている運用スタイル内の設定構成比率(運用スタイルコードに紐付く資産クラスの配分比率)と、運用口銘柄構成記憶手段59(図14参照)に記憶されている資産クラス内の設定構成比率(各銘柄の資産クラス内での配分比率)とを乗じて算出する。
なお、従来システムでは、リバランス実施判定年月日にリバランス要と判定されたら、その日に、リバランスのための注文データを作成していたので、リバランス判定処理で使用した各銘柄の評価金額と、注文データを作成する際に使用する各銘柄の評価金額とは一致していたが、本発明では、リバランス実施判定年月日が、注文データ作成日になるとは限らないので、リバランス手段23によるリバランス判定処理で使用した各銘柄の評価金額と、注文作成手段25により注文データを作成する際に使用する各銘柄の評価金額とが一致するとは限らない。
<ファンドラップシステム10/処理手段20/イベント反映手段24の構成>
イベント反映手段24は、売買注文の作成を要するイベントが発生した場合に、当該イベントの発生時点で算出日付記憶手段61(図14参照)に記憶されている注文日、最遅約定日、および最遅受渡日、並びに、売買ステータス(注文データ作成の状態:最初は、売却または買付のいずれかの注文データの作成が必要な状態とする)を、当該イベントについてのイベント番号(注文データ作成対象となるイベントの識別情報)、対象運用口についての運用口ファンドコード(運用口識別情報)と関連付けて、注文管理記憶手段52(図10参照)に記憶させる注文管理処理を実行するものである。
この際、売買注文の作成を要するイベントが発生した場合というのは、イベントにおいて注文を行うこと(注文データを作成すること)が決定した場合のことであり、これが、イベント反映手段24による注文管理処理の実行の条件となる。従って、定期受取のイベント(狭義)の場合には、イベント準備手段22によりイベント記憶手段49(図7参照)に定期受取のイベント(狭義)のレコードを作成しただけの段階や、イベント準備手段22により当月に定期受取を実施するか否かの判定処理を実行し、その定期受取判定結果が、売却注文データを作成しないという結果となった場合は、ここでいうイベントが発生(成立)したことにはならず、定期受取判定結果が、売却注文データを作成するという結果となることを条件として、ここでいうイベントが発生(成立)したことになる。また、リバランスイベントの場合には、リバランス手段23によりリバランス記憶手段50(図8参照)にリバランスイベントのレコードを作成しただけの段階や、リバランス手段23によりリバランス判定処理を実行し、そのリバランス実施判定結果が、リバランス不要となった場合は、ここでいうイベントが発生(成立)したことにはならず、リバランス実施判定結果が、リバランス要となることを条件として、ここでいうイベントが発生(成立)したことになる。
イベント反映手段24による注文管理処理で、注文管理記憶手段52(図10参照)に記憶させる注文日、最遅約定日、および最遅受渡日は、算出日付記憶手段61(図14参照)に記憶されている情報であるが、これらは、日付算出手段26により前営業日に算出された日付である。
このうち、注文日は、銘柄単位算出日付記憶手段61A(図14参照)に記憶されている日付であるが、この日付は、注文可否日記憶手段57(図14参照)に記憶されている情報(海外休場日を考慮した、注文が可能か否かの情報)を用いて、運用口を構成する全銘柄が注文可能な日として決定された日付である。
また、最遅約定日および最遅受渡日は、運用口単位算出日付記憶手段61C(図14参照)に記憶されている運用口全体の最遅約定日および最遅受渡日を示す日付であるが、これらの日付は、約定・受渡日数記憶手段58(図14参照)に記憶されている情報(各銘柄についての注文日から約定日や受渡日までの日数)を用いて決定された日付である。なお、投資対象銘柄変更のイベントは、資産クラス内の銘柄を変更するサービスであるが、変更対象となる資産クラス内の銘柄の売買だけを行う場合には、資産クラス単位算出日付記憶手段61B(図14参照)に記憶されている資産クラス内の最遅約定日および最遅受渡日を、注文管理記憶手段52(図10参照)に記憶させる最遅約定日および最遅受渡日としてもよく、変更対象となる資産クラス内の銘柄を含めて運用口全体の構成銘柄で目標のポートフォリオにするための売買を行う場合には、運用口単位算出日付記憶手段61C(図14参照)に記憶されている運用口全体の最遅約定日および最遅受渡日を、注文管理記憶手段52(図10参照)に記憶させる最遅約定日および最遅受渡日とすればよい。
また、イベント反映手段24は、増額のイベントでは、運用口記憶手段43(図3参照)の増額対象の運用口のレコードにおける設定金額を、増額金額の分だけ増額させる更新処理を実行する。さらに、減額のイベントでは、運用口記憶手段43(図3参照)の減額対象の運用口のレコードにおける設定金額を、減額金額の分だけ減額させる更新処理を実行する。
また、イベント反映手段24は、運用口削除のイベントでは、運用口削除の申込が行われた時点で注文データ作成待機中の別のイベントがある場合には、当該別のイベントを抹消扱いとするため、当該別のイベントについて注文管理記憶手段52(図10参照)に記憶されているレコードにおける抹消フラグを「抹消」にするイベント抹消処理を実行する。さらに、イベント反映手段24は、運用口記憶手段43(図3参照)の削除対象の運用口のレコードにおける運用口ステータスを「運用終了」に変更する処理を実行する。
さらに、イベント反映手段24は、スタイル変更や投資対象銘柄変更のイベントでは、運用口銘柄構成記憶手段59(図14参照)にスタイル変更や投資対象銘柄変更による銘柄構成の変更を反映させる銘柄変更処理を実行する。この際、スタイル変更のイベントでは、イベント記憶手段49(図7参照)に変更前および変更後の運用スタイルコード(運用スタイル識別情報)が記憶されているので、運用スタイル・資産クラス構成記憶手段47および資産クラス銘柄構成記憶手段48(図6参照)に記憶された情報を用いて変更前後の銘柄を特定する。投資対象銘柄変更のイベントでは、イベント記憶手段49(図7参照)に変更前および変更後の資産クラスコード(資産クラス識別情報)が記憶されているので、資産クラス銘柄構成記憶手段48(図6参照)に記憶された情報を用いて変更前後の銘柄を特定する。そして、イベント反映手段24は、スタイル変更のイベントでは、運用口記憶手段43(図3参照)に記憶されている運用スタイルコード(運用スタイル識別情報)を変更後の状態にする処理を実行し、投資対象銘柄変更のイベントでも、資産クラスコード(資産クラス識別情報)の変更によりその資産クラスを含む運用スタイルについての運用スタイルコード(運用スタイル識別情報)の変更があるので、運用口記憶手段43(図3参照)に記憶されている運用スタイルコード(運用スタイル識別情報)を変更後の状態にする処理を実行する。
また、イベント反映手段24は、定期受取申込のイベントでは、イベント記憶手段49(図7参照)に記憶されている定期受取申込のレコードの情報を用いて、運用口記憶手段43(図3参照)に既に作成されている対象運用口のレコードに、定期受取の登録情報(定期受取タイミング、定期受取指定金額等)を記憶させる設定登録処理を実行する。さらに、イベント反映手段24は、定期受取タイミング変更や定期受取指定金額変更のイベントでは、イベント記憶手段49(図7参照)に記憶されている定期受取タイミング変更や定期受取指定金額変更のレコードの情報を用いて、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取タイミングや定期受取指定金額についての変更処理を実行する。
同様に、イベント反映手段24は、寄附申込のイベントでは、イベント記憶手段49(図7参照)に記憶されている寄附申込のレコードの情報を用いて、運用口記憶手段43(図3参照)に既に作成されている対象運用口のレコードに、寄附の登録情報(寄附先、寄附金額等)を記憶させる設定登録処理を実行する。さらに、イベント反映手段24は、寄附先変更や寄附金額変更のイベントでは、イベント記憶手段49(図7参照)に記憶されている寄附先変更や寄附金額変更のレコードの情報を用いて、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける寄附の登録情報のうちの寄附先や寄附金額についての変更処理を実行する。
また、イベント反映手段24は、定期積立申込のイベントでは、イベント記憶手段49(図7参照)に記憶されている定期積立申込のレコードの情報を用いて、運用口記憶手段43(図3参照)に既に作成されている対象運用口のレコードに、定期積立の登録情報(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等)を記憶させる設定登録処理を実行する。さらに、イベント反映手段24は、定期積立変更のイベントでは、イベント記憶手段49(図7参照)に記憶されている定期積立変更のレコードの情報を用いて、運用口記憶手段43(図3参照)に記憶されている対象運用口のレコードにおける定期積立の登録情報のうちの定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等についての変更処理を実行する。
さらに、イベント反映手段24は、リバランス判定基準乖離率変更のイベントでは、イベント記憶手段49(図7参照)に記憶されているリバランス判定基準乖離率変更のレコードの情報を用いて、契約記憶手段42(図3参照)に記憶されているリバランス判定基準乖離率についての変更処理を実行する。
また、イベント反映手段24は、定期受取(狭義)や寄附(狭義)のイベントでは、定期受取明細や寄附明細を作成し、定期受取明細記憶手段55(図12参照)や寄附明細記憶手段(不図示)に記憶させる月末イベント明細作成処理を実行する。
<ファンドラップシステム10/処理手段20/注文作成手段25の構成>
注文作成手段25は、注文管理記憶手段52(図10参照)に作成された各種イベントのレコードに記憶されている売買ステータス(注文データ作成の状態)が、「売却の注文データの作成が必要な状態」または「買付の注文データの作成が必要な状態」となっているレコードについて、そのレコードに記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件(本実施形態では、判断時点の日の翌営業日が、注文日に該当するという注文作成条件)を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、イベント発生以降の毎営業日に実行するものである。ここで、イベント発生以降の毎営業日というのは、イベント反映手段24による注文管理処理が実行されて注文管理記憶手段52(図10参照)に注文日が記憶された日以降、注文管理記憶手段52(図10参照)の売買ステータスが「注文データ作成済の状態」になるまでである。
また、注文作成手段25は、注文データを作成すると判断した場合に、当該判断時点で算出日付記憶手段61(図14参照)に記憶されている注文日、約定日、および受渡日を用いて、これらの日付および注文データの内容を含む注文明細を作成し、作成した注文明細を、顧客の口座番号(顧客識別情報)および運用口ファンドコード(運用口識別情報)と関連付けて注文明細記憶手段53(図11参照)に記憶させる注文明細作成処理を実行する。
さらに、注文作成手段25は、上記の注文明細作成処理と併せて、データ連携用の注文データ(注文のために翌営業日に売買システム70へ送信する注文データ)を作成し、注文データ記憶手段54(図11参照)に記憶させる処理を実行する。
そして、注文作成手段25は、注文明細作成処理や、データ連携用の注文データ作成処理を行った後、注文管理記憶手段52(図10参照)の売買ステータスを、注文データ作成済の状態に変更する。
注文作成手段25による注文データの作成の際には、原則的に、注文の約定後におけるポートフォリオ(各銘柄の構成比率)の状態が、顧客との契約に基づく運用スタイルに沿った目標のポートフォリオ(各銘柄の配分比率)になるように、各銘柄の売買金額または売買数量(口数)を決定する。但し、四半期フィー徴収のイベントでは、フィー徴収に当てる売却金額が小さいため、運用スタイルに沿った目標のポートフォリオから最も大きく乖離している銘柄の売却だけでよい。個々のイベントにおける注文データの作成は、以下の通りである。
新規契約のイベントでは、注文作成手段25は、各運用口の設定金額(但し、契約時フィーの徴収分を指し引いた金額)が、運用口追加のイベントでは、追加する運用口の設定金額(但し、契約時フィーの徴収分を指し引いた金額)が、それぞれ運用口全体の買付金額となるので、その買付金額を、各運用口の運用スタイルに沿った目標(所望)のポートフォリオの各銘柄の配分比率に配分して各銘柄の買付金額を算出決定し、各銘柄の買注文の注文データを作成する。
ここで、目標(所望)のポートフォリオの各銘柄の配分比率は、運用スタイル・資産クラス構成記憶手段47(図6参照)に記憶されている運用スタイル内の設定構成比率(運用スタイルコードに紐付く資産クラスの配分比率)と、運用口銘柄構成記憶手段59(図14参照)に記憶されている資産クラス内の設定構成比率(各銘柄の資産クラス内での配分比率)とを乗じて算出する。
増額のイベントでは、注文作成手段25は、既に保有銘柄で構成されている運用中のポートフォリオがあるので、その時点(注文データ作成時点)における各保有銘柄の評価金額の合計金額に、増額金額(但し、増額時にも、契約時フィーを徴収する場合には、その徴収分を指し引いた金額)を加えた金額を、目標(所望)のポートフォリオになるように配分し、得られた各銘柄への配分金額から、その時点(注文データ作成時点)における各保有銘柄の評価金額を差し引くことにより各銘柄の買付金額を算出決定し、各銘柄の買注文の注文データを作成する。
この際、運用中のポートフォリオの注文データ作成時点での各銘柄の評価金額は、残高記憶手段60(図14参照)に記憶されている各銘柄の残高数量(保有口数)と、単価情報記憶手段45(図5参照)に記憶されている各銘柄の最新の基準価額とを乗じることにより算出するか、または、基準価額の更新の際に各銘柄の評価金額が算出されて残高記憶手段60(図14参照)に記憶されている場合には、それらの評価金額を用いる。
図15には、増額時の注文データ作成の具体例が示されている。3月14日〜3月16日が海外休場日となる銘柄(銘柄A,B,C,Dのうちの少なくとも1つの銘柄)を保有し、その状態で運用開始日が3月14日(入金日:3月13日)の増額(1,000,000円)を行った場合の例である。各銘柄A,B,C,Dの目標保有比率は、それぞれ25%とする。また、各銘柄A,B,C,Dの約定日は、注文日の翌営業日とする。
従来システムでは、3月14日(火)を運用開始日として指定して増額の申込を行うと、指定された運用開始日が注文予定日となり、その運用開始日が注文できる日であるか否かにかかわらず、その運用開始日の前営業日である3月13日(月)に注文データを作成していた。そして、注文データ作成日の翌営業日(指定された運用開始日)に注文を行うが、翌営業日が海外休場日に該当する銘柄を有している等の理由により、翌営業日に注文できない場合があった。すなわち、注文予定日が、実際の注文日にならない場合があった。図15の例では、3月14日(火)〜3月16日(木)が海外休場日となる銘柄を保有しているので、実際の注文日は、3月17日(金)となるため、注文データ作成日である3月13日(月)と、実際の注文日である3月17日(金)とが離れてしまう状態となっていた。そして、この間、運用口のポートフォリオを構成する各銘柄A,B,C,Dの評価金額は、基準価額の変動により変化している(図15の上部に記載された前提事項の表を参照)。
これに対し、本発明のファンドラップシステム10では、注文作成手段25により注文データ作成タイミング判断処理を実行するので、従来システムの場合とは異なり、注文データ作成日は、3月13日(月)にならない。図15の例では、イベント反映手段24により注文管理記憶手段52(図10参照)に記憶される注文日は、海外休場日を考慮した3月17日(金)となるので、注文作成手段25は、この注文日(3月17日(金))を毎営業日に参照し、判断時点の日の翌営業日が、注文日(3月17日(金))に該当するという注文作成条件を満たしているか否かを判断する。注文作成条件が満たされるのは、3月16日(木)であるから、3月16日(木)が注文データ作成日となり、3月13日(月)〜3月15日(水)は、注文データ作成待機の状態となる。従って、注文データ作成日である3月16日(木)と、実際の注文日である3月17日(金)とは、最も近い状態に置かれることになり、従来システムのように離れることはない。このことは、次のように、運用中のポートフォリオを、目標のポートフォリオに対し、より近づけることに寄与する。
先ず、従来システムの場合には、3月13日(月)の時点で、各銘柄A,B,C,Dの評価金額がそれぞれ1,000,000円であり、目標のポートフォリオの通りであったとすると、その日(3月13日(月))に注文データを作成するので、各銘柄A,B,C,Dの評価金額の合計金額4,000,000円に、増額金額の1,000,000円を加えた金額5,000,000円を、25%ずつに配分し、各銘柄A,B,C,Dへの目標の配分金額は、それぞれ5,000,000円×25%=1,250,000円となる。従って、この1,250,000円から、各銘柄の評価金額の1,000,000円をそれぞれ差し引くことにより各銘柄の買付金額を250,000円と算出決定し、各銘柄の買注文の注文データを作成する。しかし、実際の注文日である3月17日(金)までに基準価額の変動により各銘柄の評価金額が変化し、銘柄Aの評価金額=950,000円となっているので、3月17日(金)から約定日の3月20日(月)まで基準価額の変動がなかったとすると、この950,000円に、買付金額の250,000円を加え、約定日の3月20日(月)には、銘柄Aの評価金額=950,000円+250,000円=1,200,000円となる。他の銘柄B,C,Dも同様であり、銘柄Bの評価金額=1,100,000円+250,000円=1,350,000円となり、銘柄Cの評価金額=1,000,000円+250,000円=1,250,000円となり、銘柄Dの評価金額=1,100,000円+250,000円=1,350,000円となるので、約定日の3月20日(月)における各銘柄の評価金額の合計金額は、5,150,000円となる。従って、銘柄Aの保有比率は、1,200,000円÷5,150,000円=23.30%となり、銘柄Bの保有比率は、1,350,000円÷5,150,000円=26.21%となり、銘柄Cの保有比率は、1,250,000円÷5,150,000円=24.28%となり、銘柄Dの保有比率は、1,350,000円÷5,150,000円=26.21%となり、結局、約定日の3月20日(月)における銘柄保有比率は、それぞれ目標の25%から、ずれた数値となっている。
これに対し、本発明のファンドラップシステム10では、注文データ作成日は、3月16日(木)であるから、その時点での各銘柄の評価金額を用いて注文データを作成する。3月16日(木)の時点で、銘柄Aの評価金額は、950,000円に変化し、他の銘柄B,C,Dの評価金額も変化し、各銘柄A,B,C,Dの評価金額の合計金額は、4,100,000円となっているので、これに増額金額の1,000,000円を加えた金額5,100,000円を、25%ずつに配分し、各銘柄A,B,C,Dへの目標の配分金額は、それぞれ5,100,000円×25%=1,275,000円となる。従って、この1,275,000円から、銘柄Aの評価金額の950,000円を差し引くことにより銘柄Aの買付金額を325,000円と算出決定し、銘柄Aの買注文の注文データを作成する。同様に、1,275,000円から銘柄Bの評価金額の1,050,000円を差し引くことにより銘柄Bの買付金額を225,000円と算出決定し、1,275,000円から銘柄Cの評価金額の1,000,000円を差し引くことにより銘柄Cの買付金額を275,000円と算出決定し、1,275,000円から銘柄Dの評価金額の1,100,000円を差し引くことにより銘柄Dの買付金額を175,000円と算出決定し、各銘柄B,C,Dの買注文の注文データを作成する。そして、注文日である3月17日(金)には、銘柄Aの評価金額=950,000円となっているので、3月17日(金)から約定日の3月20日(月)まで基準価額の変動がなかったとすると、この950,000円に、買付金額の325,000円を加え、約定日の3月20日(月)には、銘柄Aの評価金額=950,000円+325,000円=1,275,000円となる。他の銘柄B,C,Dも同様であり、銘柄Bの評価金額=1,100,000円+225,000円=1,325,000円となり、銘柄Cの評価金額=1,000,000円+275,000円=1,275,000円となり、銘柄Dの評価金額=1,100,000円+175,000円=1,275,000円となるので、約定日の3月20日(月)における各銘柄の評価金額の合計金額は、5,150,000円となる。従って、銘柄Aの保有比率は、1,275,000円÷5,150,000円=24.76%となり、同様に、各銘柄B,C,Dの保有比率は、25.72%、24.76%、24.76%となり、従来システムの場合に比べ、目標の25%に近い比率となっている。
定期積立のイベントは、増額のイベントの繰り返しと考えることができるので、増額金額を、毎月(指定月)の定期積立金額に置き換え、あるいは、ボーナス月の場合には、毎月(指定月)の定期積立金額にボーナス月の定期積立加算金額を加算した金額に置き換えて考えればよい。
減額のイベントでは、注文作成手段25は、既に保有銘柄で構成されているポートフォリオがあるので、その時点(注文データ作成時点)における各保有銘柄の評価金額の合計金額から、減額金額を差し引いた金額を、目標のポートフォリオになるように配分し、得られた各銘柄への配分金額を、その時点(注文データ作成時点)における各保有銘柄の評価金額から差し引くことにより各銘柄の売却金額を算出決定し、各銘柄の売注文の注文データを作成する。
運用口削除のイベントでは、注文作成手段25は、削除対象の運用口の全ての保有銘柄を全口数売却するように、各銘柄の売注文の注文データを作成する。また、注文作成手段25は、運用口削除のイベントの申込があり、定期受取、寄附、またはその他の売注文を伴う月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文の注文データを作成する際には、抹消扱いとした月末イベントの売注文の分を含めた状態の数量または金額を、運用口削除の売注文の注文数量または注文金額とする処理を実行する。この処理の詳細については、図19〜図23を用いて後述するので、ここでは詳しい説明を省略する。
スタイル変更や、投資対象銘柄変更のイベントでは、注文作成手段25は、変更前の銘柄から変更後の銘柄への入替を行うために、先ず、売注文の注文データを作成し、次に、買注文の注文データを作成する。詳細については、図16〜図18を用いて後述するので、ここでは概略を説明する。例えば、銘柄A,B,Cから銘柄A,B,Dに構成銘柄を変更する場合には、銘柄Cの売却、および銘柄Dの買付が行われることになるが、銘柄A,Bについても、変更の前後で、設定構成比率が異なっていれば、変更後の設定構成比率(変更後の目標のポートフォリオ)にするために、差額分についての売買を行う。この際、スタイル変更や、投資対象銘柄変更のイベントでは、イベント反映手段24により運用口銘柄構成記憶手段59(図14参照)への銘柄変更処理が実行され、運用口銘柄構成記憶手段59には、変更後の銘柄構成(銘柄A,B,D)が記憶されているので、注文作成手段25は、変更後の設定構成比率が0%となる銘柄Cについては、全口数売却する売注文の注文データを作成することになる。また、銘柄Dについては、保有口数はゼロであるので、変更後の設定構成比率に相当する全金額分の買付を行う。一方、銘柄A,Bについては、既に保有している口数があるので、変更後の設定構成比率に相当する全金額分の買付を行うのではなく、変更後の設定構成比率を超えている金額分について売却を行い、変更後の設定構成比率に足りていない金額分について買付を行う。
なお、投資対象銘柄変更のイベントは、資産クラス内の銘柄を入れ替えるサービスであるので、変更対象の資産クラス内の銘柄の売買を行うが、それ以外の銘柄を含めて運用口全体の構成銘柄で目標のポートフォリオにするための売買を行ってもよい。例えば、対象運用口の運用スタイルが資産クラスα,β,γ,δで構成されているとすると、資産クラスαについて、銘柄A,B,Cから銘柄A,B,Dへの変更を行う投資対象銘柄変更のイベントである場合に、併せて、他の資産クラスβ,γ,δの銘柄E,F,G,…の売買を行ってもよく、この場合は、他の資産クラスβ,γ,δの銘柄構成が変化するわけではなく、各銘柄E,F,G,…の保有数量(口数)の増減調整が行われるだけである。
リバランスのイベント(リバランス要と判定された場合)では、注文作成手段25は、運用中のポートフォリオ(各銘柄の構成比率)を、顧客との契約に基づく運用スタイルに沿った目標のポートフォリオ(各銘柄の配分比率)に修正するための売買注文の注文データを作成する。すなわち、目標のポートフォリオの配分比率よりも構成比率(保有比率)が大きくなっている銘柄については、超えている金額分について売却を行い、その売却で得られた資金を用いて、目標のポートフォリオの配分比率よりも構成比率が小さくなっている銘柄について、不足している金額分について買付を行う。
定期受取や寄附のイベントでは、注文作成手段25は、売注文の注文データを作成するが、減額のイベントにおける減額金額を、定期受取指定金額や寄附金額に置き換えて考えればよい。
四半期フィー徴収のイベントでは、注文作成手段25は、フィー徴収に当てる売却金額が小さいため、例外的に、運用スタイルに沿った目標のポートフォリオから最も大きく乖離している銘柄だけの売注文の注文データを作成する。この際、最も大きく乖離している銘柄の判断は、注文データ作成時点で行うので、注文作成手段25による注文データ作成タイミング判断処理は、他のイベントと同様に行う。従って、イベント反映手段24により注文管理記憶手段52(図10参照)に注文日を記憶させる注文管理処理も、他のイベントと同様に行われる。なお、四半期フィー徴収でも、複数の銘柄を売却するようにしてもよい。
<ファンドラップシステム10/処理手段20/日付算出手段26の構成>
日付算出手段26は、翌営業日のシステム処理で用いる各種の日付(翌営業日用の日付)を算出し、算出日付記憶手段61(図14参照)に記憶させる処理を、毎営業日に実行するものである。この日付算出手段26による処理は、本実施形態では、毎営業日の夜間バッチ処理で実行するので、翌営業日用の日付を、夜間バッチ処理(日付を使用する日から見ると、前営業日の夜間バッチ処理となる。)で算出していることになる。
例えば、減額や運用口削除等のような売却を伴う売却系イベント(減額系イベント)の申込では、顧客またはその入力代行者による端末装置100からの日中オンライン入力時に、顧客またはその入力代行者に対し、画面表示で通知する日付(支払日(最遅受渡日))があるが、その日付の算出を、その日中オンライン入力(画面表示による通知)が行われる日の前営業日の夜間バッチ処理で実行する。また、売却系イベントで売注文の注文データを作成する際に、併せてその注文データを含む注文明細を作成するが、この注文明細に記載する日付(注文日、売却銘柄の注文についての約定日や受渡日、あるいは同時並行して実行される他の売却銘柄の注文を含めた最遅約定日や最遅受渡日)の算出を、その注文データ作成日の前営業日の夜間バッチ処理で実行する。この際、日付の算出は、原則として、運用口銘柄構成記憶手段59(図14参照)に記憶されている各運用口の各構成銘柄を対象として行われるが、この原則およびその例外については、後述する。
具体的には、日付算出手段26は、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄、または残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄のいずれかから選択した日付の算出対象銘柄について、当該運用口の全ての銘柄について注文可能な日として注文可否日記憶手段57(図14参照)に記憶されている日(注文可否日記憶手段57において、当該運用口の全ての銘柄が「1(注文可)」となっている日)を、当該運用口の各銘柄に共通する注文日として決定し、決定した注文日に対応する約定日および受渡日を約定・受渡日数記憶手段58(図14参照)に記憶された日数から算出するとともに、当該運用口の運用スタイルを構成する資産クラス内の全ての算出対象銘柄についての約定日および受渡日から資産クラス内の最遅約定日および最遅受渡日を求め、さらに、当該運用口の全ての算出対象銘柄についての約定日および受渡日から運用口全体の最遅約定日および最遅受渡日を求める処理を、毎営業日に実行する。
そして、日付算出手段26は、得られた注文日、約定日、および受渡日を、銘柄コード(銘柄識別情報)および運用口ファンドコード(運用口識別情報)と関連付けて算出日付記憶手段61の銘柄単位算出日付記憶手段61A(図14参照)に記憶させるとともに、得られた資産クラス内の最遅約定日および最遅受渡日を、運用口ファンドコード(運用口識別情報)および資産クラスコード(資産クラス識別情報)と関連付けて算出日付記憶手段61の資産クラス単位算出日付記憶手段61B(図14参照)に記憶させ、さらに、得られた運用口全体の最遅約定日および最遅受渡日を、運用口ファンドコード(運用口識別情報)と関連付けて算出日付記憶手段61の運用口単位算出日付記憶手段61C(図14参照)に記憶させる処理を、毎営業日に実行する。
ここで、「日付の算出対象銘柄」は、運用口を構成する銘柄が複数あり、スタイル変更や、投資対象銘柄変更のイベントがあると、運用口の銘柄構成が変化するので、いずれの銘柄構成の状態における銘柄を対象として、日付を算出するのかを示すものである。ファンドラップサービスでは、各銘柄の注文日を揃えたいという顧客の要望があるため、注文日を、運用口の全ての銘柄が注文可能な日とすることから(但し、投資対象銘柄変更のイベントについては、資産クラス内の銘柄の売買だけを行う場合には、資産クラス内の全ての銘柄が注文可能な日としてもよく、その場合には、資産クラス毎の全ての銘柄が注文可能な日となる。)、日付の算出対象銘柄が変化すると、決定される注文日は、その影響を受ける。また、運用口全体の最遅約定日は、運用口の複数の銘柄についての各約定日のうちの最も遅い約定日であり、運用口全体の最遅受渡日は、運用口の複数の銘柄についての各受渡日のうちの最も遅い受渡日であるため、日付の算出対象銘柄が変化すると、決定される運用口全体の最遅約定日や最遅受渡日は、その影響を受ける。同様に、資産クラス内の最遅約定日は、運用口を構成する資産クラス内の複数の銘柄についての各約定日のうちの最も遅い約定日であり、資産クラス内の最遅受渡日は、運用口を構成する資産クラス内の複数の銘柄についての各受渡日のうちの最も遅い受渡日であるため、日付の算出対象銘柄が変化すると、決定される資産クラス内の最遅約定日や最遅受渡日は、その影響を受ける。従って、日付の算出対象銘柄を、いずれの銘柄構成の状態における銘柄とするかを決めることが重要となる。
この際、日付算出手段26は、スタイル変更や、投資対象銘柄変更のイベントが無ければ、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄に変化はないので、原則通り、運用口銘柄構成記憶手段59に記憶されている運用口の各構成銘柄だけを参照して日付の算出対象銘柄を決定すればよいが、スタイル変更や、投資対象銘柄変更のイベントが発生した場合は、次のような日付の算出対象銘柄の選択処理を実行する。
すなわち、日付算出手段26は、注文管理記憶手段52(図10参照)に記憶されているイベント番号(イベント番号により、イベント記憶手段49(図7参照)のイベント区分を特定することができる。)および最遅約定日を用いて、スタイル変更のイベントまたは投資対象銘柄変更のイベントが発生し、かつ、スタイル変更または投資対象銘柄変更による売注文の最遅約定日よりも前の日であると判断した場合には、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄を、算出対象銘柄として選択し、それ以外の場合には、運用口銘柄構成記憶手段59(図14参照)に記憶されている当該運用口の各構成銘柄を、算出対象銘柄として選択する処理を実行する。この算出対象銘柄の選択処理についての詳細は、図16〜図18を用いて後述する。
<ファンドラップシステム10/処理手段20/手数料算出手段27の構成>
手数料算出手段27は、運用する資産額に応じて顧客から徴収する手数料(投資顧問料、取引等管理手数料)を算出し、その算出結果を、運用口ファンドコード(運用口識別情報)と関連付けて算出手数料記憶手段(不図示)に記憶させる処理を実行するものである。徴収する手数料には、契約時フィー(新規契約、運用口追加、あるいは増額の場合の手数料)と、四半期毎に徴収する四半期フィー(より一般には、運用期間の経過に伴って徴収する期間フィー)とがある。この手数料算出手段27は、残高記憶手段60(図14参照)に記憶されている各運用口の各保有銘柄の残高数量に単価情報記憶手段45(図5参照)に記憶されている基準価額を乗じて得られる手数料算出時点の評価金額(または、基準価額の更新に伴って算出されて残高記憶手段60(図14参照)に記憶されている各運用口の各保有銘柄の評価金額)と、手数料率記憶手段(不図示)に記憶された手数料率とを用いて、手数料を算出する。
<ファンドラップシステム10/処理手段20/注文データ連携手段28の構成>
注文データ連携手段28は、注文データ記憶手段54(図11参照)に記憶されている注文データを、通信回線2を介して売買システム70へ送信する処理を実行するものである。
<ファンドラップシステム10/処理手段20/約定処理手段29の構成>
約定処理手段29は、通信回線2を介して売買システム70から送信されてきてファンドラップシステム10の約定データ記憶手段(不図示)に記憶されている約定データ(注文番号、銘柄コード(銘柄識別情報)、約定数量(口数)、売買区分(売・買の別)、約定時の基準価額、顧客の口座番号(顧客識別情報)等を含む)を取得し、注文データ記憶手段54(図11参照)に記憶されている注文データ(約定データと同一の注文番号の注文データ)のステータスを「約定済」に更新する処理を実行するものである。
<ファンドラップシステム10/処理手段20/資産管理手段30の構成>
資産管理手段30は、四半期フィー等の期間フィーの徴収の場合には、約定データ記憶手段(不図示)から、売注文の約定データを取得し、約定した銘柄(本実施形態では、投資信託の銘柄)についての約定数量の分だけ、残高記憶手段60(図14参照)に記憶された当該銘柄の残高数量を減少させる更新処理を実行するとともに、売却で得られた金額(受渡金額)の分だけ、金銭残高記憶手段44(図4参照)に記憶された金銭残高を増加させる更新処理を実行するものである。
また、契約時フィーを徴収する際には、金銭残高記憶手段32(図4参照)に記憶された金銭残高に、新規契約、運用口追加、あるいは増額のイベントにおける入金額があるので、その入金額から契約時フィー(入金額に対して僅かな割合の金額)を徴収するとともに、入金額のうちの残りの金額(入金額のうちの大部分の金額)を、投資信託の買付に充当する。従って、資産管理手段30は、約定データ記憶手段(不図示)から、買注文の約定データを取得し、約定した銘柄(本実施形態では、投資信託の銘柄)についての約定数量の分だけ、残高記憶手段60(図14参照)に記憶された当該銘柄の残高数量を増加させる更新処理を実行するとともに、買付に充当された金額の分だけ、金銭残高記憶手段44(図4参照)に記憶された金銭残高を減少させる更新処理を実行する。なお、買付に充当された金額を減じた後でも、金銭残高記憶手段44(図4参照)に記憶された金銭残高には、入金額のうちの手数料徴収に充当する分の金額、すなわち、算出手数料記憶手段(不図示)に記憶された手数料の金額(投資顧問料金額+取引等管理手数料金額)は残っている。
<ファンドラップシステム10/処理手段20/金銭振替手段31の構成>
金銭振替手段31は、金銭残高記憶手段44(図4参照)に記憶された金銭残高について通信回線2で接続された売買システム70との間で金銭振替処理を実行するとともに、金銭振替明細(金銭振替明細番号、金銭振替発生元イベント番号、顧客の口座番号(顧客識別情報)、運用口ファンドコード(運用口識別情報)、金銭振替金額等を含む)を作成し、金銭振替明細記憶手段56(図13参照)に記憶させる金銭振替明細作成処理を実行するものである。
具体的には、金銭振替手段31は、例えば、定期受取のイベント(狭義)では、金銭残高記憶手段44(図4参照)に記憶された金銭残高から、売却を行って得られた金額(定期受取指定金額)を減少させる更新処理を実行するとともに、その金額データを、通信回線2を介して売買システム70へ送信する処理を実行する。この金額データ(定期受取指定金額)は、売買システム70へ送信されると、売買システム側金銭振替手段73により、顧客の主口座に振り替えられ、主口座の残高金額が増加する。
また、金銭振替手段31は、四半期フィー徴収のイベント等の手数料の徴収の際には、金銭残高記憶手段44(図4参照)に記憶された金銭残高から、手数料として徴収する金額、すなわち、手数料算出手段27により算出されて算出手数料記憶手段(不図示)に記憶された手数料の金額を減少させる更新処理を実行するとともに、手数料の金額データを、通信回線2を介して売買システム70へ送信する処理を実行する。この金額データ(手数料の金額)は、売買システム70へ送信されると、売買システム側金銭振替手段73により、証券会社等の金融機関の勘定に振り替えられ、証券会社等の金融機関の勘定が増加する。
さらに、金銭振替手段31は、運用口削除のイベントの申込があり、定期受取のイベント(狭義)や寄附のイベント(狭義)等の売注文を伴う月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文(抹消扱いとした月末イベントの売注文の分を含む)の約定に伴って金銭残高記憶手段44(図4参照)に記憶された金銭残高の全額を金銭振替金額とする金銭振替処理を実行するとともに、抹消扱いとした月末イベントの売注文により得られるはずであった売却金額を含む定期受取や寄附等の月末イベントの金銭振替明細、および、金銭振替金額から月末イベントの売注文により得られるはずであった売却金額を差し引いた金額を含む運用口削除の金銭振替明細を作成する処理を実行する。この処理の詳細については、図19〜図23を用いて後述するので、ここでは詳しい説明を省略する。
<ファンドラップシステム10/処理手段20/帳票作成用データ連携手段32の構成>
帳票作成用データ連携手段32は、定期受取明細記憶手段55(図12参照)に記憶された定期受取明細データ、寄附明細記憶手段(不図示)に記憶された寄附明細データ、金銭振替明細記憶手段56(図13参照)に記憶された金銭振替明細データ、算出手数料記憶手段(不図示)に記憶された手数料の金額(投資顧問料金額+取引等管理手数料金額)データ等を取得し、取得したデータを、帳票作成用データとして、通信回線2を介して売買システム70へ送信する処理を実行するものである。
<ファンドラップシステム10/記憶手段40の構成>
主口座記憶手段41は、図3に示すように、主口座の口座番号(顧客識別情報)、口座ファンドコードを関連付けて記憶するものである。
契約記憶手段42は、図3に示すように、契約ファンドコード、主口座の口座番号(顧客識別情報)、サービス種類区分(「ファンドラッププレミアム」サービス=01、「ファンドラップオンライン」サービス=02、…)、新規契約年月日、新規契約金額、口座ファンドコード、リバランス判定基準乖離率(リバランス判定の基準となる乖離率:%単位)等を関連付けて記憶するものである。
運用口記憶手段43は、図3に示すように、運用口ファンドコード(運用口識別情報)、主口座の口座番号(顧客識別情報)、サービス種類区分(「ファンドラッププレミアム」サービス=01、「ファンドラップオンライン」サービス=02、…)、運用口番号(1,2,3,4,5)、運用口名称(運用口の愛称等)、運用スタイル区分(共通スタイル=1、個別スタイル(1)=2、個別スタイル(2)=3、…)、運用スタイルコード(運用スタイル識別情報)、運用口ステータス(新規申請中=1、追加申請中=2、運用中=3、運用終了=4、取消済=5)、設定金額(運用口で運用する金額:各時点での金額であり、更新される金額)、契約ファンドコード、当初設定金額(新規契約時または運用口追加時の設定金額)、定期受取の登録情報(定期受取タイミング、定期受取指定金額等)、寄附の登録情報(食料支援、医療、環境、子供支援、災害復興等の寄附のテーマ(寄附先)、寄附金額等)、定期積立の登録情報(定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等)、約定ベースホールド期間の設定情報(期間の終了年月日等)、月末ホールド期間の設定情報(期間の設定年月日等)などを関連付けて記憶するものである。
金銭残高記憶手段44は、図4に示すように、顧客の保有する金銭残高、主口座の口座番号(顧客識別情報)等を関連付けて記憶するものである。
単価情報記憶手段45は、図5に示すように、投資信託の銘柄コード、基準価額等を関連付けて記憶するものである。また、単価情報記憶手段45は、株式や債券等の銘柄コード、単価等も関連付けて記憶し、さらに、例えば、日経平均、NYダウ、原油価格等の各種の金融指標についての指標値も記憶している。
運用スタイル記憶手段46は、図6に示すように、サービス種類区分(「ファンドラッププレミアム」サービス=01、「ファンドラップオンライン」サービス=02、…)、運用スタイル区分(共通スタイル=1、個別スタイル(1)=2、個別スタイル(2)=3、…)、運用スタイルコード(運用スタイル識別情報)、運用スタイル名称(安定型、やや安定型、バランス型、やや積極型、積極型、…)、手数料コード(手数料率識別情報)等を関連付けて記憶するものである。
運用スタイル・資産クラス構成記憶手段47は、図6に示すように、運用スタイルコード(運用スタイル識別情報)、資産クラスコード(資産クラス識別情報)、設定構成比率(運用スタイルコードに紐付く資産クラスの配分比率:%単位)等を関連付けて記憶するものである。
資産クラス銘柄構成記憶手段48は、図6に示すように、資産クラスコード(資産クラス識別情報)、投資信託の銘柄コード(銘柄識別情報)等を関連付けて記憶するものである。
イベント記憶手段49は、図7に示すように、イベント番号(各イベントの識別情報)、イベント区分(新規契約、増額、減額、運用口追加、運用口削除、スタイル変更、投資対象銘柄変更、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、定期受取、寄附申込、寄附先変更、寄附金額変更、寄附、定期積立申込、定期積立変更、定期積立、リバランス判定基準乖離率変更(運用口単位ではない)等のイベント種別の識別情報)、イベントステータス(申請中、成立、不成立、取消済、…)、運用口ファンドコード(運用口識別情報)、主口座の口座番号(顧客識別情報)、契約ファンドコード、運用開始日、新規契約時の設定金額、運用口追加時の設定金額、増額金額、減額金額、変更前および変更後の運用スタイルコード(運用スタイル識別情報)、変更前および変更後の資産クラスコード、変更前および変更後の定期受取タイミング、変更前および変更後の定期受取指定金額、変更前および変更後の寄附先、変更前および変更後の寄附金額、変更前および変更後の定期積立タイミング、変更前および変更後の定期積立設定日、変更前および変更後の毎月の定期積立金額、変更前および変更後のボーナス月の定期積立加算金額、変更前および変更後のリバランス判定基準乖離率(運用口単位ではない)、定期受取判定年月日(定期受取の自動継続判定を行う年月日:定期受取月の前月の月末営業日)、定期受取判定結果(当月に定期受取に伴う売却注文データを作成しない=0、作成する=1)、寄附計算処理年月日等を関連付けて記憶するものである。
リバランス記憶手段50は、図8に示すように、リバランス番号(リバランスイベントの識別情報)、運用口ファンドコード(運用口識別情報)、主口座の口座番号(顧客識別情報)、リバランス実施判定年月日(リバランス実施判定処理を行う年月日:月末営業日)、リバランス実施判定結果(要・不要の別)等を関連付けて記憶するものである。
四半期フィー徴収記憶手段51は、図9に示すように、四半期フィー徴収番号(四半期フィー徴収イベントの識別情報)、運用口ファンドコード(運用口識別情報)、主口座の口座番号(顧客識別情報)、四半期フィー計算処理年月日等を関連付けて記憶するものである。
注文管理記憶手段52は、図10に示すように、運用口ファンドコード(運用口識別情報)、注文データ作成イベント番号(注文データ作成対象となるイベント、例えば、スタイル変更、投資対象銘柄変更等の各イベントの識別情報)、売買ステータス(注文データ作成の状態であり、売却または買付のいずれかの注文データの作成が必要な状態、注文データ作成済の状態、売買不要の状態)、注文日、最遅約定日、最遅受渡日、抹消フラグ(レコードの論理抹消の有無:非抹消=0、抹消=1)等を関連付けて記憶するものである。
注文明細記憶手段53は、図11に示すように、注文明細番号、売買する投資信託の銘柄コード(銘柄識別情報)、注文数量(口数指定で注文する場合の口数)、注文金額(金額指定で注文する場合の金額)、売買区分(売・買の別)、主口座の口座番号(顧客識別情報)、運用口ファンドコード(運用口識別情報)、注文日、約定日(注文に対して約定成立可能要件を満たす年月日)、受渡日(顧客と受渡を行う年月日)等を関連付けて記憶するものである。
注文データ記憶手段54は、図11に示すように、注文番号(=注文明細番号)、売買する投資信託の銘柄コード(銘柄識別情報)、注文数量(口数指定で注文する場合の口数)、注文金額(金額指定で注文する場合の金額)、売買区分(売・買の別)、主口座の口座番号(顧客識別情報)、ステータス(注文中、約定済、…)等を関連付けて記憶するものである。
定期受取明細記憶手段55は、図12に示すように、定期受取明細番号、定期受取イベント番号(定期受取のイベントの識別情報)、主口座の口座番号(顧客識別情報)、運用口ファンドコード(運用口識別情報)、定期受取金額等を関連付けて記憶するものである。
金銭振替明細記憶手段56は、図13に示すように、金銭振替明細番号、金銭振替発生元イベント番号(金銭振替の発生要因となったイベント、例えば、定期受取、新規契約、運用口追加、増額、定期積立、減額、運用口削除等の各イベントの識別情報)、主口座の口座番号(顧客識別情報)、運用口ファンドコード(運用口識別情報)、金銭振替金額等を関連付けて記憶するものである。
注文可否日記憶手段57は、図14に示すように、カレンダー形式で、投資信託の各銘柄についての銘柄コード(銘柄識別情報)と、各日における注文の可否の情報(注文不可=0、注文可=1)とを関連付けて記憶するものである。各日における注文の可否の情報は、営業日(国内の営業日)であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報であり、例えば、海外休場日を考慮した情報である。図14の例では、営業日(国内の営業日)であるか否かの要素と、海外休場日であるか否かの要素との双方を加味した状態の注文の可否の情報となっているが、営業日(国内の営業日)であるか否かによる注文の可否の情報と、海外休場日であるか否かによる注文の可否の情報とを、別々に用意してもよい(別のテーブル等で用意してもよい)。すなわち、別々に用意された双方の情報を参照することにより、最終的に、海外休場日を考慮した状態での各日における注文の可否の情報が得られるようになっていてもよい。また、営業日(国内の営業日)であるか否か以外の要素としては、海外休場日に該当するか否かの他に、例えば、急激な相場変動に伴う注文回避期間やその他のルールによる注文回避期間に該当するか否か等がある。これらの各要素の場合も、注文の可否の情報は、別々に用意してもよく、全部の要素または複数の要素を加味した状態の注文の可否の情報を用意してもよい。
約定・受渡日数記憶手段58は、図14に示すように、注文日から約定日までの日数、および注文日から受渡日までの日数を、投資信託の銘柄コード(銘柄識別情報)と関連付けて記憶するものである。
運用口銘柄構成記憶手段59は、図14に示すように、主口座の口座番号(顧客識別情報)、運用口ファンドコード(運用口識別情報)、投資信託の銘柄コード(銘柄識別情報)、設定構成比率(対象銘柄の資産クラス内での配分比率:%単位)等を関連付けて記憶するものである。
残高記憶手段60は、図14に示すように、主口座の口座番号(顧客識別情報)、運用口ファンドコード(運用口識別情報)、顧客の保有資産である投資信託の銘柄コード(銘柄識別情報)、残高数量(保有する投資信託の口数)、評価金額等を関連付けて記憶するものである。
算出日付記憶手段61は、図14に示すように、銘柄単位算出日付記憶手段61Aと、資産クラス単位算出日付記憶手段61Bと、運用口単位算出日付記憶手段61Cとを含んで構成されている。
銘柄単位算出日付記憶手段61Aは、図14に示すように、運用口ファンドコード(運用口識別情報)、資産クラスコード(資産クラス識別情報)、投資信託の銘柄コード(銘柄識別情報)、注文日(但し、全銘柄が注文可能な日)、約定日、受渡日等を関連付けて記憶するものである。
資産クラス単位算出日付記憶手段61Bは、図14に示すように、運用口ファンドコード(運用口識別情報)、資産クラスコード(資産クラス識別情報)、資産クラス内の最遅約定日、資産クラス内の最遅受渡日等を関連付けて記憶するものである。
運用口単位算出日付記憶手段61Cは、図14に示すように、運用口ファンドコード(運用口識別情報)、運用口全体の最遅約定日、運用口全体の最遅受渡日等を関連付けて記憶するものである。
<売買システム70の詳細構成>
<売買システム70/売買処理手段71、約定データ連携手段72、売買システム側金銭振替手段73、帳票作成手段74の構成>
売買処理手段71は、ファンドラップシステム10から通信回線2を介して送信されてきて注文データ記憶手段81(図1参照)に記憶されている注文データ(注文番号、売買銘柄についての銘柄コード、注文数量(口数)または注文金額、売買区分、口座番号を含む。)を用いて、金融商品(本実施形態では、投資信託)の売買処理を実行するとともに、その約定データ(注文番号、売買銘柄についての銘柄コード、約定数量(口数)、売買区分、約定時の基準価額、口座番号を含む。)を約定データ記憶手段82(図1参照)に記憶させる処理を実行するものである。
約定データ連携手段72は、約定データ記憶手段82(図1参照)に記憶されている約定データを、通信回線2を介してファンドラップシステム10へ送信する処理を実行するものである。
売買システム側金銭振替手段73は、通信回線2で接続されたファンドラップシステム10との間で金銭振替処理を実行するものである。この売買システム側金銭振替手段73は、金銭振替手段31によりファンドラップシステム10から通信回線2を介して送信されてくる金銭振替に係る金額データを受信し、金銭振替処理を実行する。例えば、定期受取のイベント(狭義)では、ファンドラップシステム10から受信する金額データは、定期受取指定金額であり、この金額を顧客の主口座に振り替えて主口座の残高金額を増加させる。また、四半期フィー徴収のイベント等の手数料の徴収の際には、ファンドラップシステム10から受信する金額データは、手数料として徴収する金額、すなわち、手数料算出手段27により算出されて算出手数料記憶手段(不図示)に記憶された手数料の金額であり、この金額を証券会社等の金融機関の勘定に振り替えることにより、手数料の徴収処理を実行する。
帳票作成手段74は、ファンドラップシステム10から通信回線2を介して送信されてきて帳票作成用データ記憶手段83(図1参照)に記憶されている帳票作成用データ(例えば、定期受取明細データ、寄附明細データ、金銭振替明細データ、手数料の金額データ等)を用いて、四半期の運用報告書等の各種の帳票を作成し、帳票記憶手段84(図1参照)に記憶させる処理を実行するものである。帳票記憶手段84に記憶された帳票データは、帳票の印刷処理や、端末装置100,110からの閲覧要求に応じた帳票の表示処理等の出力処理に使用される。なお、売買システム70には、これらの出力処理(印刷処理や表示処理等)を行うための図示されない帳票出力手段が設けられている。
<売買システム70/注文データ記憶手段81、約定データ記憶手段82、帳票作成用データ記憶手段83、帳票記憶手段84の構成>
注文データ記憶手段81は、ファンドラップシステム10から通信回線2を介して送信されてきた注文データ(注文番号、売買銘柄についての銘柄コード、注文数量(口数)または注文金額、売買区分、口座番号を含む。)を記憶するものである。
約定データ記憶手段82は、売買処理手段71による売買処理で取引が成立した注文の約定データ(注文番号、売買銘柄についての銘柄コード、約定数量(口数)、売買区分、約定時の基準価額、口座番号を含む。)を記憶するものである。
帳票作成用データ記憶手段83は、ファンドラップシステム10から通信回線2を介して送信されてきた帳票作成用データ(例えば、定期受取明細データ、寄附明細データ、金銭振替明細データ、手数料の金額データ等)を記憶するものである。
帳票記憶手段84は、帳票作成手段74により作成された帳票データ(四半期の運用報告書データ等の各種の帳票データ)を記憶するものである。
<各日付(注文日、最遅約定日、最遅受渡日)の算出対象銘柄の変更:図16〜図19>
図16には、4月中にスタイル変更(銘柄A,B,Cから銘柄A,B,Dへの変更)のイベントが申し込まれた場合の4月の月末前後の処理内容が示されている。前提として、銘柄A,B,C,Dは、注文日の翌営業日を約定日とする。また、5月1日(月)は、銘柄A,B,Cのうちのいずれかが海外休場日に該当し、5月3日(水)〜5月7日(日)は、ゴールデンウィークの非営業日(国内の非営業日)である。
図18において、4月中(例えば、4月25日(火))に、端末装置100からの日中のオンライン入力で、顧客またはその入力代行者によるスタイル変更の申込があった場合には、設定受付手段21により、その申込を受け付け、イベント記憶手段49(図7参照)にスタイル変更のイベントのレコード(申込受付日、イベントのバッチ処理反映日である申込月の月末営業日、変更前後の運用スタイルコード(運用スタイル識別情報)を含む:イベントステータスは「申請中」とする)が作成される(ステップS1)。
そして、日付算出手段26による日付算出処理は、毎営業日の夜間バッチ処理で実行されるので、4月27日(木)の夜間バッチ処理でも実行され、スタイル変更の対象運用口を含めて全ての運用口について、翌営業日(4月28日(金))に使用される各日付(注文日、各銘柄の約定日や受渡日、あるいは最遅約定日や最遅受渡日)が算出され、算出日付記憶手段61(図14参照)に記憶される(ステップS2)。この際、日付算出手段26は、スタイル変更の対象運用口については、未だスタイル変更が発生していない状態(申込は受け付けているが、月末の実施タイミングが到来していない状態)であるから、原則通り、運用口銘柄構成記憶手段59(図14参照)に記憶されている対象運用口の各構成銘柄(銘柄A,B,C)を算出対象銘柄として日付の算出処理を実行する(図16の4月27日(木)参照)。
その後、月末営業日(4月28日(金))の夜間バッチ処理では、イベント反映手段24によるイベント反映処理が実行される(図18のステップS3)。このイベント反映処理では、運用口銘柄構成記憶手段59(図14参照)に、スタイル変更による銘柄構成の変更を反映させる。すなわち、銘柄A,B,Cから銘柄A,B,Dへ変更する。また、運用口記憶手段43(図3参照)に記憶されている運用スタイルコード(運用スタイル識別情報)を変更後の状態にする。
また、イベント反映手段24によるイベント反映処理(図18のステップS3)では、イベント記憶手段49(図7参照)のスタイル変更イベントのレコードのイベントステータスを「申請中」から「成立」に更新する。
さらに、イベント反映手段24によるイベント反映処理(図18のステップS3)では、注文管理記憶手段52(図10参照)に、スタイル変更イベントのレコードを作成する注文管理処理を実行する。この際、翌営業日(5月1日(月))ではなく、海外休業日を考慮した売注文の注文日(5月2日(火))、およびその注文日に対応する最遅約定日、最遅受渡日を記憶させる。ここで用いる海外休業日を考慮した売注文の注文日(5月2日(火))、およびその注文日に対応する最遅約定日、最遅受渡日は、前述したステップS2で、日付算出手段26により前営業日(4月27日(木))の夜間バッチ処理で算出されて算出日付記憶手段61(図14参照)に記憶されている日付(算出対象銘柄は、銘柄A,B,C)である。
続いて、月末営業日(4月28日(金))の夜間バッチ処理では、注文作成手段25による処理(ここでは、スタイル変更の売注文)を実行する(図18のステップS4)。先ず、売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する。
この注文データ作成タイミング判断処理では、注文作成手段25は、注文管理記憶手段52(図10参照)に記憶されている売買ステータス(注文データ作成の状態)が「売却の注文データの作成が必要な状態」となっているレコードについて、翌営業日(ここでは5月1日(月))が、そのレコードに記憶されている注文日(5月2日(火))と一致するか否かを判断する。従って、本実施形態では、判断時点の日の翌営業日が、注文管理記憶手段52(図10参照)に記憶されている注文日(5月2日(火))と一致することが注文作成条件である。
そして、翌営業日(ここでは5月1日(月))が注文日(5月2日(火))と一致した場合には(従って、図16の例では一致しない。)、売注文の注文明細のレコードを作成して注文明細記憶手段53(図11参照)に記憶させるとともに、売注文の注文データを作成して注文データ記憶手段54(図11参照)に記憶させる。この際、注文明細に記憶させる日付(注文日、約定日、受渡日、あるいは同時並行して実行される他の注文を含めた最遅約定日、最遅受渡日)は、前述したステップS2で、日付算出手段26により前営業日(4月27日(木))の夜間バッチ処理で算出されて算出日付記憶手段61(図14参照)に記憶されている日付(算出対象銘柄は、銘柄A,B,C)を用いる。また、注文作成手段25は、売却の注文データを作成したら、注文管理記憶手段52(図10参照)に記憶されている売買ステータスを「注文データ作成済の状態」に更新する。
一方、翌営業日(ここでは5月1日(月))が、注文管理記憶手段52に記憶されている注文日(5月2日(火))と一致しなかった場合には、売注文の注文データの作成を待機する。つまり、注文管理記憶手段52(図10参照)に記憶されている売買ステータスは、「売却の注文データの作成が必要な状態」のままとする。従って、図16の例では、月末営業日(4月28日(金))の夜間バッチ処理では、注文データ作成待機の状態となる。
それから、月末営業日(4月28日(金))の夜間バッチ処理でも、毎営業日に行われる日付算出手段26による日付算出処理が実行され、スタイル変更の対象運用口を含めて全ての運用口について、翌営業日(5月1日(月))に使用される各日付(注文日、各銘柄の約定日や受渡日、あるいは最遅約定日や最遅受渡日)が算出され、算出日付記憶手段61(図14参照)に記憶される(ステップS5)。スタイル変更に伴う売注文については、既に注文管理記憶手段52(図10参照)にスタイル変更イベントのレコードが作成され、注文管理が開始されている状態であるが、スタイル変更のバッチ処理反映日(月末営業日)以降の日においても、同じ運用口について、スタイル変更とは別の売却系イベント(減額のイベント等)の申込が行われる場合があることと、スタイル変更に伴う売注文の注文データ作成が待機状態となり、注文データおよび注文明細の作成日が後ろの日にずれることがあるので、スタイル変更の対象運用口についても日付の算出処理が行われる。
この際、図16の例では、日付算出手段26は、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄(銘柄A,B,D)ではなく、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄(銘柄A,B,C)を、日付の算出対象銘柄として選択する(図16の4月28日(金)参照)。運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄は、前述したステップS3で、イベント反映手段24により、既に銘柄A,B,Cから銘柄A,B,Dへ変更されているが(同日の先行する夜間バッチ処理での変更)、前述したステップS4で、スタイル変更に伴う売注文の注文データは作成待機状態となり、翌営業日以降に作成されることになったので、ステップS5での翌営業日用の日付の算出は、変更前の銘柄A,B,Cを算出対象銘柄とする必要があるからである。仮に、原則通りに、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄を算出対象銘柄として日付の算出処理を行ってしまうと、変更後の銘柄A,B,Dを算出対象銘柄とすることになり、翌営業日に銘柄Cの日付が算出されていない状態となり、不都合が生じる。
その後、5月1日(月)の夜間バッチ処理でも、注文作成手段25により、前述したステップS4の場合と同様にして、売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する(図18のステップS6)。すなわち、注文作成手段25は、注文管理記憶手段52(図10参照)に記憶されている売買ステータス(注文データ作成の状態)が「売却の注文データの作成が必要な状態」となっているレコードについて、翌営業日(ここでは5月2日(火))が、そのレコードに記憶されている注文日(5月2日(火))と一致するか否かを判断する。従って、図16の例では、この日(5月1日(月))に初めて注文作成条件を満たすことになる。
そして、図16の例では、5月1日(月)に注文作成条件が満たされるので、売注文の注文明細のレコードを作成して注文明細記憶手段53(図11参照)に記憶させるとともに、売注文の注文データを作成して注文データ記憶手段54(図11参照)に記憶させる。この際、注文明細に記憶させる日付(注文日、約定日、受渡日、あるいは同時並行して実行される他の注文を含めた最遅約定日、最遅受渡日)は、前述したステップS5で、日付算出手段26により前営業日(4月28日(金))の夜間バッチ処理で算出されて算出日付記憶手段61(図14参照)に記憶されている日付(算出対象銘柄は、銘柄A,B,C)を用いる(図16の4月28日(金)参照)。前述した通り、日付算出手段26による算出処理での算出対象銘柄は、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄(銘柄A,B,D)ではなく、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄(銘柄A,B,C)をとされているので、銘柄Cの日付が算出されていることになる。また、注文作成手段25は、売却の注文データを作成したら、注文管理記憶手段52(図10参照)に記憶されている売買ステータスを「注文データ作成済の状態」に更新する。
続いて、5月1日(月)の夜間バッチ処理でも、毎営業日に行われる日付算出手段26による日付算出処理が実行され、スタイル変更の対象運用口を含めて全ての運用口について、翌営業日(5月2日(火))に使用される各日付(注文日、各銘柄の約定日や受渡日、あるいは最遅約定日や最遅受渡日)が算出され、算出日付記憶手段61(図14参照)に記憶される(図18のステップS7)。この際、日付算出手段26は、前述したステップS5の場合と同様に、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄(銘柄A,B,D)ではなく、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄(銘柄A,B,C)を、日付の算出対象銘柄として選択する(図16の5月1日(月)参照)。
その後、5月2日(火)の夜間バッチ処理で、注文データ連携手段28により、注文データ記憶手段54(図11参照)に記憶されている注文データを、通信回線2を介して売買システム70へ送信して注文を行う。売買システム70では、売買処理手段71により、ファンドラップシステム10から通信回線2を介して送信されてきて注文データ記憶手段81(図1参照)に記憶されている注文データ(注文番号、売買銘柄についての銘柄コード、注文数量(口数)または注文金額、売買区分、口座番号を含む。)を用いて、投資信託の売買処理(ここでは、スタイル変更に伴う売注文の処理)を実行する。
さらに、5月8日(月)に、売買処理手段71により、スタイル変更に伴う売注文の約定データ(注文番号、売買銘柄についての銘柄コード、約定数量(口数)、売買区分、約定時の基準価額、口座番号を含む。)を約定データ記憶手段82(図1参照)に記憶させる。そして、5月8日(月)の夜間バッチ処理で、約定データ連携手段72により、約定データ記憶手段82(図1参照)に記憶されている約定データを、通信回線2を介してファンドラップシステム10へ送信する。
それから、売買システム70では、5月8日(月)の夜間バッチ処理で、約定処理手段29により、通信回線2を介して売買システム70から送信されてきてファンドラップシステム10の約定データ記憶手段(不図示)に記憶されている約定データ(注文番号、銘柄コード(銘柄識別情報)、約定数量(口数)、売買区分(売・買の別)、約定時の基準価額、顧客の口座番号(顧客識別情報)等を含む)を取得し、注文データ記憶手段54(図11参照)に記憶されている注文データ(約定データと同一の注文番号の注文データ)のステータスを「約定済」に更新する処理を実行する。
なお、図18での図示は省略されているが、5月2日(火)以降においても、前述したステップS4,S6の注文作成手段25による処理と同様な処理、および前述したステップS5,S7の日付算出手段26による処理と同様な処理は、全ての運用口について、毎営業日に行われる。また、スタイル変更以外のイベントにも着目すれば、前述したステップS3のイベント反映手段24による処理に相当する処理も、全ての運用口について、毎営業日に行われる。
この際、スタイル変更に伴う売注文については、5月2日(火)以降は、注文管理記憶手段52(図10参照)に記憶されている売買ステータスが「注文データ作成済の状態」になっているので、注文作成手段25による注文データ作成タイミング判断処理の対象外となる。
また、スタイル変更に伴う売注文の最遅約定日である5月8日(月)以降における日付算出手段26による処理では、日付の算出対象銘柄は、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄ではなく、原則通り、運用口銘柄構成記憶手段59(図14参照)に記憶されている当該運用口の各構成銘柄とする。従って、図16の例で、日付の算出対象銘柄を、例外的に、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄とするのは、スタイル変更のバッチ反映日である月末営業日(4月28日(金))から、スタイル変更に伴う売注文の最遅約定日の前営業日(5月2日(火))までである。
図17には、4月中にスタイル変更(銘柄A,B,Cから銘柄A,B,Dへの変更)のイベントが申し込まれ、その後、スタイル変更の買注文の注文データ作成後のホールド期間中の5月9日(木)に、減額のイベントが申し込まれた場合の4月の月末前後の処理内容が示されている。この例は、日付算出手段26による処理において、日付の算出対象銘柄を、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄だけとすると、不都合が生じることを示すものである。すなわち、原則通り、運用口銘柄構成記憶手段59(図14参照)に記憶されている当該運用口の各構成銘柄を選択する場合と、例外的に、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄を選択する場合とを組み合わせる必要があることを示している。
この図17の例は、図16の例とは異なり、申込月の月末営業日(4月28日(金))の翌営業日(5月1日(月))が海外休場日に該当する銘柄はないという前提であるため、スタイル変更の売注文の注文データの作成待機はないものとし、月末営業日(4月28日(金))に、売注文の注文データが作成されるものとする。従って、図18のステップS3の月末営業日(4月28日(金))の夜間バッチ処理では、イベント反映手段24により、注文管理記憶手段52(図10参照)のスタイル変更イベントのレコードに、売注文の注文日として、翌営業日(5月1日(月))が記憶される。
月末営業日(4月28日(金))の夜間バッチ処理で、注文作成手段25により、売注文の注文データが作成されると、この売注文による約定ベースホールド期間が設定され、この売注文が約定するまで(複数銘柄の売注文がある場合には、最遅約定日まで)、同一銘柄についての売買注文の注文データ作成が制限される。このスタイル変更に伴う売注文による約定ベースホールド期間は、注文作成手段25により設定され、運用口記憶手段43(図3参照)にその設定情報が記憶される。
注文データ作成日の翌営業日(5月1日(月))の夜間バッチ処理で、注文データ連携手段28により、注文データ記憶手段54(図11参照)に記憶されている売注文の注文データが、通信回線2を介して売買システム70へ送信されて売注文が行われ、5月2日(火)に、通信回線2を介して売買システム70から売注文の約定データ(注文番号、銘柄コード(銘柄識別情報)、約定数量(口数)、売買区分(売・買の別)、約定時の基準価額、顧客の口座番号(顧客識別情報)等を含む)が送信されてくるので、約定処理手段29により、この売注文の約定データを取得して約定処理を行う。従って、5月2日(火)が売注文の最遅約定日となる。
5月2日(火)に売注文の約定データを取得して約定処理を行うと、売注文による約定ベースホールド期間が終了するので、翌営業日(5月8日(月))が海外休場日に該当する銘柄を有していなければ、5月2日(火)の夜間バッチ処理で、注文作成手段25により、買注文の注文データが作成される。そして、注文作成手段25により、買注文による約定ベースホールド期間が設定され、運用口記憶手段43(図3参照)にその設定情報が記憶される。
続いて、5月8日(月)の夜間バッチ処理で、注文データ連携手段28により、注文データ記憶手段54(図11参照)に記憶されている買注文の注文データが、通信回線2を介して売買システム70へ送信されて買注文が行われる。その後、5月9日(火)の夜間バッチ処理で、通信回線2を介して売買システム70から買注文の約定データ(注文番号、銘柄コード(銘柄識別情報)、約定数量(口数)、売買区分(売・買の別)、約定時の基準価額、顧客の口座番号(顧客識別情報)等を含む)が送信されてくるので、約定処理手段29により、この買注文の約定データを取得して約定処理を行う。従って、5月9日(火)が買注文の最遅約定日となる。
また、スタイル変更に伴う買注文による約定ベースホールド期間中、例えば、5月9日(火)の日中に、減額イベントの申込があると、スタイル変更に伴う買注文による約定ベースホールド期間の終了後に、減額イベントの売注文の注文データ作成が可能となるので、翌営業日(5月10日(水))が海外休場日に該当する銘柄を有していなければ、5月9日(火)の夜間バッチ処理で、注文作成手段25により、減額イベントの売注文の注文データが作成される。また、減額イベントの売注文の注文データを含む注文明細も作成される。
この際、減額イベントの申込は、スタイル変更に伴う買注文による約定ベースホールド期間中である5月9日(火)の日中に行われているので、5月9日(火)の夜間バッチ処理で、減額イベントの売注文の注文明細に記載される日付は、スタイル変更後の銘柄構成状態である銘柄A,B,Dを算出対象銘柄として算出された日付であるべきである。そして、この日付は、減額イベントの売注文の注文データおよび注文明細の作成日の前営業日(5月8日(月))の夜間バッチ処理で、日付算出手段26により算出されて算出日付記憶手段61(図14参照)に記憶されている日付である。
しかし、5月8日(月)において、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄は、銘柄A,B,Dではなく、銘柄A,Bの状態(銘柄A,B,Cの状態から、銘柄Cの全口数が売却されて約定した状態)であるため、これを算出対象銘柄とすることは不適切である。5月9日(火)に、注文明細の作成に必要な銘柄Dの日付が存在しない状態となってしまうからである。
そこで、日付算出手段26は、5月8日(月)における算出対象銘柄は、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄(銘柄A,B)ではなく、原則通り、運用口銘柄構成記憶手段59(図14参照)に記憶されている当該運用口の各構成銘柄(銘柄A,B,D)とする。この状態は、5月2日(火)に、スタイル変更の売注文の約定で、残高記憶手段60(図14参照)の保有銘柄が、銘柄A,B,Cの状態から、銘柄A,Bの状態になることにより生じるので、日付の算出対象銘柄を、例外的に、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄とするのは、スタイル変更の売注文の最遅約定日の前営業日(5月1日(月))までとし、スタイル変更の売注文の最遅約定日(5月2日(火))からは、原則通り、運用口銘柄構成記憶手段59(図14参照)に記憶されている当該運用口の各構成銘柄とする。
なお、従来システムでは、図24を用いて既に詳述したように、スタイル変更の売注文について、本発明のような注文データ作成待機という状態がなく、翌営業日に注文できるか否かにかかわらず、月末営業日に売注文の注文データが作成されていたので、運用口銘柄構成記憶手段に記憶されている構成銘柄を日付の算出対象銘柄としていればよかったことから、そもそも上記のような問題は生じなかった。
<金銭振替明細の作成:図19〜図23/本実施形態の説明(図19、図22、図23参照)>
図19には、5月31日(水)に定期受取イベント(狭義)が発生し(ここでいう発生とは、定期受取判定結果が、当月に定期受取に伴う売却注文データを作成するという結果となった場合を意味する。)、6月1日(木)に運用口削除の申込を行なった場合の処理内容が示されている。6月1日(木)が海外休場日となる銘柄を保有している前提である。なお、図20および図21は、比較参照のために記載した処理内容であり、本発明のファンドラップシステム10による処理ではない。
図22において、イベント記憶手段49(図7参照)に定期受取イベント(狭義)のレコードが作成されているものとすると、月末営業日(5月31日(水))には、イベント準備手段22によるイベント準備処理が実行される(ステップS11)。すなわち、イベント記憶手段49(図7参照)に記憶された定期受取判定年月日(本実施形態では、月末営業日が設定される)になった場合に、イベント準備手段22により、定期受取の実施判定を実行し、定期受取を実施すると判定した場合には、イベント記憶手段49の定期受取のレコードに、定期受取判定結果として、売注文の注文データを「作成する」という判定結果を記憶させる。
続いて、イベント反映手段24によるイベント反映処理を実行する(図22のステップS12)。すなわち、イベント反映手段24により、イベント記憶手段49(図7参照)の定期受取のレコードに記憶された定期受取判定結果が売注文の注文データを「作成する」になっている場合には、そのレコードのイベントステータスを「申請中」から「成立」に更新する。
また、イベント反映手段24により、注文管理記憶手段52(図10参照)に、定期受取のレコードを作成する。この際、作成したレコードには、翌営業日(6月1日(木))ではなく、海外休業日を考慮して決定された注文日(6月2日(金))を記憶させる。さらに、イベント反映手段24により、定期受取明細を作成し、定期受取明細記憶手段55(図12参照)に記憶させる。
それから、注文作成手段25による処理(ここでは、定期受取の売注文に関する処理)を実行する(図22のステップS13)。先ず、注文作成手段25により、定期受取の売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する。この際、翌営業日(ここでは6月1日(木))が、注文管理記憶手段52(図10参照)に記憶されている注文日(6月2日(金))と一致するか否かを判断する。
ここで、翌営業日(ここでは6月1日(木))が注文日(6月2日(金))と一致した場合(注文作成条件を満たした場合)には、注文明細記憶手段53(図11参照)に定期受取の売注文の注文明細のレコードを作成するとともに、定期受取の売注文の注文データを作成して注文データ記憶手段54(図11参照)に記憶させる。この際、注文明細に記憶させる日付(注文日、約定日、受渡日、あるいは最遅約定日や最遅受渡日)は、前営業日(5月30日(火))に日付算出手段26により算出されて算出日付記憶手段61(図14参照)に記憶されている日付を用いる。
一方、翌営業日(ここでは6月1日(木))が注文日(6月2日(金))と一致しなかった場合(注文作成条件を満たさなかった場合)には、定期受取に伴う売注文の注文データの作成を待機する。従って、図19の例では、一致しないので、注文データ作成待機となる。但し、定期受取判定結果は、当月に定期受取に伴う売却注文データを作成するという判定結果となっているので、定期受取明細は作成し、定期受取明細記憶手段55(図12参照)に記憶させる。
その後、6月1日(木)の日中に、運用口削除の申込があった場合には、設定受付手段21により、この運用口削除イベントの申込を受け付け、イベント記憶手段49(図7参照)に運用口削除イベントのレコードを作成する(図22のステップS14)。
それから、6月1日(木)の夜間バッチ処理で、イベント反映手段24によるイベント反映処理を実行する(図23のステップS15)。すなわち、イベント反映手段24により、イベント記憶手段49(図7参照)の運用口削除イベントのレコードのイベントステータスを「申請中」から「成立」に更新する。
また、イベント反映手段24により、注文管理記憶手段52(図10参照)に、運用口削除のレコードを作成する。この際、作成したレコードには、注文日(6月2日(金))を記憶させる。
さらに、イベント反映手段24により、注文管理記憶手段52(図10参照)の定期受取のレコードの抹消フラグを「抹消」に更新して抹消扱いとする。定期受取の売注文は、注文管理記憶手段52(図10参照)の定期受取のレコードに記憶されている売買ステータス(注文データ作成の状態)が「売却の注文データの作成が必要な状態」となっているので、注文データ作成待機中の状態であるが、その状態において、運用口削除イベントが発生しているので、抹消扱いとする。従って、定期受取の売注文の注文データの作成は行わない。運用口削除イベントは、削除対象の運用口の全保有銘柄の全残高数量(全口数)を売却する処理であるため、運用口削除の売注文で、まとめて売却するためである。なお、注文管理記憶手段52(図10参照)において売買ステータス(注文データ作成の状態)が「売却の注文データの作成が必要な状態」となっているレコードが、定期受取等のような売注文を伴う月末イベントのレコードであるか否かは、注文管理記憶手段52の当該レコードに記憶されている注文データ作成イベント番号を用いて、イベント記憶手段49(図7参照)において同じイベント番号のレコードに記憶されているイベント区分を参照することにより判別することができる。
続いて、6月1日(木)の夜間バッチ処理では、注文作成手段25による処理(ここでは、運用口削除の売注文に関する処理)を実行する(図23のステップS16)。先ず、注文作成手段25により、運用口削除の売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する。この際、翌営業日(ここでは6月2日(金))が、注文管理記憶手段52(図10参照)に記憶されている注文日(6月2日(金))と一致するか否かを判断する。図19の例では、一致する。
ここで、翌営業日(ここでは6月2日(金))が注文日(6月2日(金))と一致した場合(注文作成条件を満たした場合)には、注文明細記憶手段53(図11参照)に運用口削除の売注文の注文明細のレコードを作成するとともに、運用口削除の売注文の注文データを作成して注文データ記憶手段54(図11参照)に記憶させる。この際、注文明細に記憶させる日付(注文日、約定日、受渡日、あるいは最遅約定日や最遅受渡日)は、前営業日(5月31日(水))に日付算出手段26により算出されて算出日付記憶手段61(図14参照)に記憶されている日付を用いる。また、運用口削除イベントは、削除対象の運用口の全保有銘柄の全残高数量(全口数)を売却する処理であるため、運用口削除の売注文の注文データにおける売却数量(売却金額)は、全数量(全口数)とする。図19の例では、注文データ作成時点(6月1日(木)の時点)で残高記憶手段60(図14参照)に記憶されている残高数量(口数)の評価金額は、1,000万円であるので、その全数量(全金額)が、運用口削除の売注文の注文データにおける売却数量(売却金額)となる。従って、この売注文の注文データには、抹消扱いとした定期受取の分、すなわち運用口削除の申込が無ければ定期受取の売注文で売却するはずであった数量分(金額分)も含まれることになる。
一方、翌営業日(ここでは6月2日(金))が注文日(6月2日(金))と一致しなかった場合(注文作成条件を満たさなかった場合)には、運用口削除の売注文の注文データの作成を待機する。
それから、6月2日(金)の夜間バッチ処理で、注文データ連携手段28により、注文データ記憶手段54(図11参照)に記憶されている運用口削除の売注文の注文データが、通信回線2を介して売買システム70へ送信されて売注文が行われ(図23のステップS17)、6月5日(月)に、通信回線2を介して売買システム70から運用口削除の売注文の約定データ(注文番号、銘柄コード(銘柄識別情報)、約定数量(口数)、売買区分(売・買の別)、約定時の基準価額、顧客の口座番号(顧客識別情報)等を含む)が送信されてくるので、約定処理手段29により、この運用口削除の売注文の約定データを取得して約定処理を行う。
従って、6月5日(月)が運用口削除の売注文の最遅約定日となるので、この約定を受けて、残高記憶手段60(図14参照)に記憶されていた各保有銘柄の残高数量(口数)の評価金額の1,000万円は、6月5日(月)の夜間バッチ処理で0円となる。一方、金銭残高記憶手段44(図4参照)に記憶されている金銭残高は、1,000万円となる。この1,000万円の内訳は、抹消扱いとした定期受取により得られるはずであった売却金額分の100万円と、運用口削除による売却金額分の900万円とである。つまり、運用口削除の売注文の約定金額には、抹消扱いとした定期受取により得られるはずであった売却金額分が含まれており、運用口削除の売注文は、本来の定期受取の売注文(運用口削除の申込が無かったとした場合の定期受取の売注文)と、本来の運用口削除の売注文(定期受取の売注文を行ったとした場合におけるその後の運用口削除の売注文)とを、まとめた状態となっている。なお、100万円は、運用口記憶手段43(図3参照)に記憶されている定期受取指定金額である。
さらに、6月5日(月)の夜間バッチ処理では、金銭振替手段31による金銭振替処理を実行する(図23のステップS18)。すなわち、金銭振替手段31により、売買システム70との間で、定期受取の分を含めた運用口削除の金額(1,000万円)の金銭振替を行う。運用口削除の売注文の約定時には、約定金額の全額を、売買システム70へ送金するようになっているからである。これにより、1,000万円の金銭振替金額データが、通信回線2を介して売買システム70へ送信される。売買システム70では、売買システム側金銭振替手段73により、この1,000万円の金銭振替金額データを受信して顧客の主口座への振替が行われ、主口座の金銭残高が1,000万円増加する。
また、金銭振替手段31により、定期受取の金銭振替明細(金銭振替金額=100万円)を作成するとともに、運用口削除の金銭振替明細(金銭振替金額=900万円)を作成する。従って、運用口削除の金銭振替明細に記載する金額は、運用口削除の売注文の約定に伴って売買システム70へ送信した金銭振替金額1,000万円から、定期受取(売注文を伴う月末イベント)の金銭振替明細に記載する金額100万円を差し引いた金額とする。
この処理により、定期受取は、抹消扱いとされ、定期受取の売注文の注文データは作成されず、運用口削除の売注文の注文データに、まとめられた状態となるのに対し、金銭振替明細については、定期受取と、運用口削除とで別々のものが作成されることになる。換言すれば、売注文の注文データ作成については、定期受取と運用口削除とが1本化されて金額が1,000万円とされ、売買システム70との間の金銭振替処理(基幹システム側の主口座への入金処理)についても、1本化されて金額が1,000万円とされるのに対し、金銭振替明細については、別々に作成されて金額が100万円と900万円になる。従って、通常は、金銭振替処理と、その金銭振替明細の作成処理とが、1対1の関係となるのに対し、1対2の関係となっている。このため、抹消扱いとされた定期受取についても金銭振替明細が作成されるので、顧客との契約に基づき行った定期受取判定処理で、一旦、当月に定期受取の売却注文データを作成するという判定結果が出たにもかかわらず、定期受取が実施されたことになっていないという事態を回避することができる。
<金銭振替明細の作成:図19〜図23/従来システムとの比較(図25参照)および課題の説明(図20、図21参照)>
なお、従来システムでは、図25を用いて既に詳述したように、定期受取の売注文の注文データは、翌営業日(6月1日(木))が注文できる日であるか否かにかかわらず、月末営業日(5月31日(水))に作成していたので、そもそも注文データ作成待機中という状態がないことから、定期受取の売注文の注文データ作成待機中に、運用口削除の申込が行われるという事態は生じなかった。換言すれば、定期受取の売注文の注文データは、月末営業日(5月31日(水))に作成され、それによるホールド期間が設定されるので、その後に、運用口削除の申込があっても、運用口削除の売注文の注文データは、ホールド期間の終了後に作成されるため、定期受取と運用口削除との間で、売注文の注文データ、金銭振替処理、および金銭振替明細の作成処理が交錯するような事態は生じなかった。従って、上述したような本実施形態のファンドラップシステム10で生じる課題は、従来システムでは発生する余地がなかった。本発明では、顧客と契約した運用スタイルに沿った目的(所望)のポートフォリオに、より一層近づけるために、注文データ作成待機を行う構成としたので、それに伴って生じる課題を解決していることになる。以下では、図20および図21を用いて、その課題を説明する。
図20に示された比較参照用処理(1)は、[A]翌営業日が実際に注文することができない日である場合に、注文データの作成を待機する処理と、[B]運用口削除が申し込まれたタイミングで、注文データ作成待機中のイベントが存在した場合に、待機中のイベントを抹消扱いとする処理とを適用した場合である。上述したように、[A]は、目的のポートフォリオに近づけるために採用した処理であるが、[A]の処理を行うことを前提として、[B]の処理を行うようにした結果、次のような課題が生じる。
図20において、5月31日(水)の夜間バッチ処理では、翌営業日(6月1日(木))が海外休場日の銘柄があるため、定期受取の売注文の注文データ作成が待機となり、ホールド期間は設定されない。[A]の処理を採用したためであり、この点が、前述した図25の従来システムの場合と異なる。そして、ホールド期間未設定のため、運用口削除の申込の当日(6月1日(木))に、運用口削除の売注文の注文データが作成される。
運用口削除イベントでは、削除対象の運用口の全保有銘柄の全数量(全口数)を売却する。従って、運用口削除の申込があり、かつ、定期受取の売注文の注文データが未だ作成されていない状態である場合には、[B]の処理を採用するので、定期受取のイベントは抹消扱いとなり、定期受取の売注文の注文データ作成は行われない。運用口削除の売注文として、まとめて売注文の注文データを作成することになる。
これにより、定期受取は、顧客との契約に基づき実施判定を行い、一旦、実施するという判定結果が出ているにもかかわらず、運用口削除の申込により定期受取のイベントが抹消扱いとなり、定期受取の売注文の注文データ作成が行われず、定期受取の金銭振替処理やその金銭振替明細の作成処理も行われなくなってしまう。このため、顧客との契約内容を忠実に履行するという観点では好ましくない。
図21に示された比較参照用処理(2)は、上述した[A]および[B]の処理に対し、さらに、[C]注文データ作成待機中のイベントは抹消扱いとするが、金銭振替は行う処理を適用した場合であり、次のような課題が生じる。
図21において、6月5日(月)の夜間バッチ処理では、運用口削除の売注文の最遅約定日になったので、約定処理が行われ、投資信託の各保有銘柄の残高数量(口数)についての評価金額1,000万円は、0円となり、一方、金銭残高は、1,000万円になる。そして、売買システム(基幹システム)の主口座への金銭振替処理が行われ、運用口削除の金銭振替明細が作成されるが、運用口削除の売注文の約定金額の全額の金銭振替となるため、この金銭振替明細に記載される金銭振替金額は、1,000万円である。
一方、[C]の処理を採用したので、定期受取(売注文を伴う月末イベント)の注文データ作成は行わないが、金銭振替は行うことになるため、100万円(運用口記憶手段43(図3参照)に記憶されている定期受取指定金額)について、売買システム(基幹システム)の主口座への金銭振替処理が行われ、定期受取の金銭振替明細が作成される。この金銭振替明細に記載される金銭振替金額は、100万円である。
従って、6月5日(月)の運用口削除の売注文の約定により金銭残高が1,000万円となっているが、この金銭残高1,000万円に対し、合計で1,100万円の金銭振替処理(内訳:定期受取の金銭振替金額100万円、運用口削除の金銭振替金額1,000万円)が行われるので、6月6日(火)以降の金銭残高は、マイナス100万円となってしまう。
以上のような図20および図21で示した課題を解消するために、本実施形態のファンドラップシステム10では、前述した図19で示される処理を実行する。
<本実施形態の効果>
このような本実施形態によれば、次のような効果がある。すなわち、ファンドラップシステム10では、営業日(国内営業日)であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報が、注文可否日記憶手段57(図14参照)に記憶され、この情報を用いて決定された注文日が、イベント反映手段24による注文管理処理で、注文管理記憶手段52(図10参照)に記憶され、注文作成手段25による注文データ作成タイミング判断処理で、注文管理記憶手段52に記憶されている注文日を用いて、判断時点の日に注文データを作成するか、または作成を待機するかを判断するので、注文データ作成日と注文日とを近づけることができる。このため、注文データ作成時の評価金額と、注文約定時の評価金額との差異を小さくすることができ、適切な売買金額を含む注文データを作成することができるので、従来システムに比べ、運用スタイルに沿ったポートフォリオを、より一層適切に維持することができる。
また、上記のように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、注文明細を作成することができなくなる事態が生じる。すなわち、注文明細の作成には、売買金額を含む注文データの他に、注文管理上の日付(注文日、約定日、受渡日)が必要となるが、スタイル変更のイベントまたは投資対象銘柄変更のイベントが発生し、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口(イベントの対象となる運用口)の各構成銘柄が変更されてしまうと、日付算出手段26により、注文明細の作成に必要な日付が算出されていないという事態が生じる。この事態の発生状況の詳細については、図16を用いて既に詳述しているので、ここでは詳しい説明を省略する。
これに対し、ファンドラップシステム10では、スタイル変更や投資対象銘柄変更のイベントの発生状況や注文の進行状況に応じ、日付算出手段26による日付の算出対象銘柄を、運用口銘柄構成記憶手段59(図14参照)に記憶されている運用口の各構成銘柄、または、残高記憶手段60(図14参照)に記憶されている当該運用口の残高数量がゼロでない各保有銘柄のいずれかから選択するようにしたので、上述したような注文明細の作成に必要な日付が算出されていないという事態を回避することができる。
さらに、前述したように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、顧客との契約上、必要となる金銭振替明細を作成することができなくなる事態が生じる場合がある。すなわち、定期受取や寄附等の月末イベントは、顧客との契約に基づき、条件を満たしたら実施し、売注文を行うべきイベントであるが、ファンドラップシステム10では、このような月末イベントが発生し、注文データの作成が待機状態となっている最中に、運用口削除が申し込まれる場合が考えられ、この場合に、運用口削除の申込により、定期受取等の月末イベントを抹消扱いとし、それ以降の処理を行わないことにすると、注文データの作成、注文、金銭振替明細の作成の各処理が行われないことになってしまう。定期受取や寄附等は、顧客との契約に従って実施されるものであるので、一旦、実施するという判定結果が出て、これらの月末イベントが発生したら、売注文を行い、金銭振替明細の作成も行うべきものであるため、好ましくない事態が生じることになる。運用口削除の申込は、定期受取や寄附等を実施するという判定結果が出た後に行われているからである。このような事態の発生の詳細については、図20および図21を用いて、既に詳述しているので、ここでは詳しい説明を省略する。
これに対し、ファンドラップシステム10では、図19に示すように、定期受取等の月末イベントについては、抹消扱いとし、売注文の注文データの作成は行わないようにするが、金銭振替明細は、運用口削除の申込が無ければ、本来得られるはずであった売却金額を含む状態で作成するようにする。一方、運用口削除のイベントについては、抹消扱いとした定期受取等の月末イベントの売注文の分を含めた状態の注文数量または注文金額を含む売注文の注文データを作成し、金銭振替明細の作成では、抹消扱いとした定期受取等の月末イベントの売注文により得られるはずであった売却金額を差し引いた金額を含む金銭振替明細を作成するようにする。このため、顧客との契約上、必要となる金銭振替明細を作成することができなくなるという問題を解消することができる。
また、前述したように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、リバランスについて従来通りの考え方を踏襲すると、不都合が生じる可能性がある。すなわち、予め定められた日(例えば、月末営業日)にリバランス判定処理を行い、リバランスの実施が必要であると判定されても、その日にリバランスのための注文データが作成されず、作成を待機する状態となる場合(例えば、翌月の月初営業日が海外休場日となる銘柄がある場合)があるので、従来通りの考え方を踏襲すると、それ以降で注文が可能になる日の前営業日(例えば、海外休場日となっている翌月の月初営業日、または翌月の月初営業日から海外休場日が2日以上連続している場合には、連続する海外休場日の最後の日)にリバランス判定処理を再度実行し、リバランス要の判定結果が出たときに、リバランスのための注文データの作成を行うことになる。しかし、リバランス判定処理は、顧客との契約で、予め定められた日(例えば、月末営業日)に運用スタイルに沿ったポートフォリオとなっているか否かを確認する処理であるため、リバランス判定処理の実行日が、予め定められた日(例えば、月末営業日)よりも後の日になってしまうことは好ましくない。
これに対し、ファンドラップシステム10では、注文作成手段25によるリバランスのための注文データの作成を、リバランス手段23によるリバランスの実施の要否判定と切り離して行うので、注文データ作成待機に伴ってリバランス判定処理の実行日も、予め定められた日(例えば、月末営業日)よりも後の日になってしまうという事態を回避することができる。このため、予め定められた日におけるリバランス判定処理の実行を確保できるので、契約の忠実な履行を実現することができる。すなわち、ファンドラップシステム10では、リバランス手段23によるリバランス判定処理は、再実行することはなく、予め定められた日(例えば、月末営業日)に実行するだけとし、そのときのリバランス要の判定結果を受けて、注文作成手段25による注文データ作成タイミング判断処理で注文作成条件を満たした場合に、リバランス実施の要否判定時点ではなく、注文データ作成タイミング判断時点での基準価額による評価金額を用いて注文データを作成する。なお、リバランス実施の要否判定時点からの基準価額の変動の大きさによっては、注文データ作成タイミング判断時点では、既にリバランスを実施しなくてもよい程に、ポートフォリオが所望の状態になっている場合もあり得るが、この場合でも、一旦、リバランス手段23による判定処理でリバランスを実施するという判定結果が出ている以上、顧客との契約を忠実に履行するという観点で、注文作成手段25により注文データを作成し、注文を行う。
また、従来システムでは、予め定められた日(例えば、月末営業日)にリバランス判定処理を行い、リバランス要の判定結果が出たら、その日に注文データを作成していたので、海外休場日等の介在により、注文データ作成日と実際の注文日とが離れてしまう場合があり、作成した注文データを用いて注文を行ったとしても、注文約定後の状態が、所望のポートフォリオまたはそれに近い状態になっていない場合も生じ得ることから、リバランス実施の効果が十分に得られない可能性もあった。つまり、注文に使用する注文データが、時間の経過により、リバランスの役に立たない状態になっている可能性もあった。これに対し、ファンドラップシステム10では、注文データ作成日と注文日とを近づけることができるので、リバランス実施の効果が適切に得られる注文データを作成して注文を行うことができる。
<変形の形態>
なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。
例えば、前記実施形態では、図16〜図18を用いた各日付の算出対象銘柄の変更の説明は、スタイル変更イベントで説明されていたが、投資対象銘柄変更イベントでも同様である。
また、前記実施形態では、図19〜図23を用いた金銭振替明細の作成の説明は、定期受取イベント(狭義)と運用口削除イベントとが同時期に発生したケースで説明されていたが、寄附イベント(狭義)等の売注文を伴う月末イベントと運用口削除イベントとが同時期に発生したケースでも同様である。