JP6738914B2 - ファンドラップシステムおよびプログラム - Google Patents

ファンドラップシステムおよびプログラム Download PDF

Info

Publication number
JP6738914B2
JP6738914B2 JP2019000902A JP2019000902A JP6738914B2 JP 6738914 B2 JP6738914 B2 JP 6738914B2 JP 2019000902 A JP2019000902 A JP 2019000902A JP 2019000902 A JP2019000902 A JP 2019000902A JP 6738914 B2 JP6738914 B2 JP 6738914B2
Authority
JP
Japan
Prior art keywords
order
date
event
investment
storage means
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019000902A
Other languages
English (en)
Other versions
JP2020112842A (ja
Inventor
理司 瀧島
理司 瀧島
高史 鑑
高史 鑑
晃弘 川上
晃弘 川上
一浩 篠原
一浩 篠原
芳洋 田中
芳洋 田中
文蔵 横山
文蔵 横山
林　達也
林　　達也
吉田　充
充 吉田
Original Assignee
株式会社大和総研
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社大和総研 filed Critical 株式会社大和総研
Priority to JP2019000902A priority Critical patent/JP6738914B2/ja
Publication of JP2020112842A publication Critical patent/JP2020112842A/ja
Application granted granted Critical
Publication of JP6738914B2 publication Critical patent/JP6738914B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本発明は、顧客から預かった資産を顧客により選択された運用口毎の運用スタイルで運用する投資一任サービスとして、投資信託への投資を取り扱うファンドラップサービスを提供する処理を実行するコンピュータからなるファンドラップシステムおよびプログラムに係り、例えば、投資信託を含む金融商品の売買を行う既設の売買システムと連携してファンドラップサービスを提供する場合等に利用できる。
一般に、投資一任サービスとは、投資家が証券会社等の金融機関と投資一任契約を締結し、運用スタイルを選択したうえで、すなわち、運用方針を指示したうえで、投資家の保有する資産の運用・管理を証券会社等の金融機関に委ねる金融サービスである。このうち、投資信託（以下、「投信」と略記することがある。）への投資を取り扱う投資一任サービスとして、ファンドラップサービスがある。近年、多くの金融機関により様々なファンドラップサービスが提供され、その中には、顧客の資産を分割して複数の運用口に割り当て、運用口毎に顧客が運用スタイルを選択設定し、運用口単位で別々の運用・管理を行うようにしたファンドラップサービスも提供されている。
このような複数の運用口の設定を可能としたファンドラップでは、１つの運用口に対し、１つの運用スタイルが設定されることになるので、運用口単位で、異なる複数の銘柄によるポートフォリオが構成されることになる。このファンドラップでは、新規契約、運用口追加、運用口削除、増額、定期積立、減額、リバランス、四半期フィー徴収等の際に、ポートフォリオを構成する投資信託の売買を行うが、その際の注文日は、運用スタイルに紐付く全ての銘柄（運用口を構成する全ての銘柄）について注文できる日としている。これは、契約で設定した運用スタイルに基づくポートフォリオの通りに、すなわちポートフォリオを維持するように注文が行われていることを確認するために、各銘柄の注文日を揃えたいという顧客の要望があるからである。
注文を行う際には、事前に注文データを作成する必要があるが、従来、注文データ作成タイミングは、注文予定日の前営業日の夜間バッチとしていた。この注文予定日は、顧客によるオンライン画面からの入力に基づき契約イベント毎に定まる日であるが、海外休場日を考慮しない注文日であるから、実際に注文できる日であるとは限らない。
例えば、増額系のイベント（増額、運用口追加等のような投資信託の買付を行うイベント）の場合には、顧客が指定した運用開始日（例えば、明日から１０日先を運用開始日として指定する等）が、注文予定日となるので、運用開始日の前営業日の夜間バッチ処理で注文データを作成していた。しかし、この注文予定日である運用開始日は、運用口を構成する各銘柄のうちのいずれかの銘柄についての海外休場日であるかもしれず、その場合には、顧客が指定した運用開始日は、実際には注文できない日であるので、顧客は、実際に注文できるか否かにかかわらず、オンライン画面で、運用開始日（すなわち、注文予定日）を指定している状態である。
また、減額系のイベント（減額、運用口削除等のような投資信託の売却を行うイベント）の場合には、イベント申込日の翌営業日が、注文予定日となるので、イベント申込日の夜間バッチ処理で注文データを作成していた。しかし、この場合も、注文予定日であるイベント申込日の翌営業日は、運用口を構成する各銘柄のうちのいずれかの銘柄についての海外休場日であるかもしれず、その場合には、実際には注文できない日であるので、顧客は、翌営業日が注文できる日であるか否かにかかわらず、減額系のイベントの申込を行っている状態である。
さらに、運用スタイルを変更するサービスであるスタイル変更のイベントの場合には、月初営業日が、注文予定日となるので、その前の月の月末営業日の夜間バッチ処理で注文データを作成していた。しかし、この場合も、注文予定日である月初営業日は、運用口を構成する各銘柄のうちのいずれかの銘柄についての海外休場日であるかもしれず、その場合には、実際には注文できない日である。
より具体的には、従来システムでは、例えば、図２４に示すように、４月中（例えば４／２５（火））にスタイル変更（銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄへの変更）のイベントが申し込まれた場合には、スタイル変更のイベントは、申込みがあった月の月末営業日に実施されるので（この場合、本願では、申込日ではなく、月末営業日にイベントが発生（成立）したと考える。）、４月の月末営業日である４／２８（金）の夜間バッチで、運用口銘柄構成記憶手段に記憶されている運用口（スタイル変更が申し込まれた運用口）の銘柄を、銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄに変更する銘柄変更処理を実行するとともに、売注文の注文データを作成する。また、この売注文の注文データとともに作成する注文明細には、その売注文に係る日付（注文日、約定日、受渡日）が含まれるが、この注文明細の作成に使用する日付は、注文データ作成日の前営業日である４／２７（木）の夜間バッチにより、その時点で運用口銘柄構成記憶手段に記憶されている当該運用口の銘柄について算出された日付である。従って、４／２７（木）の時点では、未だ銘柄変更処理が行われていないので、変更前の銘柄Ａ，Ｂ，Ｃが運用口銘柄構成記憶手段に記憶されていることから、変更後の銘柄Ａ，Ｂ，Ｄではなく、変更前の銘柄Ａ，Ｂ，Ｃについての日付が算出される。このため、４／２８（金）における売注文の注文明細（注文データを含む）の作成の際には、その売注文の対象である変更前の銘柄Ａ，Ｂ，Ｃについての日付が算出されて存在している状態となるので、注文明細の作成に支障が生じることはない。
ところが、図２４の例では、注文データ作成日の翌営業日である５／１（月）は、海外休場日（銘柄Ａ，Ｂ，Ｃのうちのいずれかが海外休場日）であるから、注文することができず（注文日とならず）、さらにその次の営業日である５／２（火）が実際の注文日となる。このため、５／２（火）は、約定予定日であったが、実際の約定日は、５／３（水）〜５／７（日）は非営業日であるから、５／８（月）となる。以上より、従来は、月末営業日（４／２８（金））の翌営業日（５／１（月））が実際に注文できる日であるか否かにかかわらず、翌営業日（５／１（月））を注文予定日として４／２８（金）に注文データを作成していたことになる。
また、図２５には、従来システムの金銭振替明細の作成タイミングの例が示されている。この例は、５／３１（金）に月末イベントである定期受取が発生し、６／１（木）に運用口削除の申込みを行った場合の例である。なお、本願では、定期受取が「発生（成立）」したという状態は、当月の月末に定期受取を実施することが決まった状態を示すので、定期受取イベントの準備処理（イベント記憶手段へのレコード作成や、定期受取を実施するか否かの判定処理）を行っただけの状態を示すものではない。他の月末イベントも同様であり、寄附や四半期フィー徴収等の月末イベントについては、イベント「発生（成立）」という状態は、当月の月末に寄附や四半期フィー徴収等を実施することが決まった状態を示すものとする。
図２５の例では、定期受取は、月末イベントであるので、月末営業日である５／３１（水）に発生し、減額系（売却系）のイベントであるから、そのイベント発生日に売注文の注文データを作成するとともに、定期受取明細を作成する。そして、イベント発生日の翌営業日である６／１（木）が注文予定日となるが、その日は海外休場日（運用口のいずれかの銘柄の海外休場日）であるので、その次の営業日（６／２（金））が実際の注文日となり、さらにその次の営業日（６／５（月））が定期受取の売注文の最遅約定日となり、その日に定期受取の金銭振替明細を作成する。
一方、６／１（木）に運用口削除の申込が行われたとすると、運用口削除は、減額系（売却系）のイベントであるから、通常は、その申込日に売注文の注文データを作成するが、定期受取の売注文によるホールド期間中（運用口の銘柄の売買の注文データを作成することができない期間）に該当するので、運用口削除の申込日には、運用口削除の売注文の注文データを作成することができない。定期受取の売注文によるホールド期間は、定期受取の売注文の最遅約定日に終了するので（運用口の全ての銘柄の売注文の約定により終了するので）、そのホールド期間の終了する６／５（月）に、運用口削除の売注文の注文データを作成する。この際、定期受取の売注文は既に約定し、その売却分は保有残高から減じられた状態（既に保有していない状態）であるから、運用口削除の売注文の注文数量または注文金額は、定期受取の売注文による売却分の数量または口数を含まない状態となる。そして、注文データを作成した日の翌営業日（６／６（火））が実際の注文日となり、さらにその次の営業日（６／７（水））が運用口削除の売注文の最遅約定日となり、その日に運用口削除の金銭振替明細を作成する。
従って、図２５に示すように、定期受取の売注文についての実際の注文日が注文データ作成日の翌営業日にならない事態は生じ得るものの、そのことを除けば、契約に従って定期受取の実施の要否を判定し、実施が必要と判定された定期受取について売注文が行われてその金銭振替明細が作成され、かつ、申込のあった運用口削除の売注文も行われてその金銭振替明細が作成され、それらの双方のイベントの金銭振替明細には、適切な金銭振替金額が記載される状態となるので、従来システムでも、契約内容に沿った注文を行い、かつ、その注文の約定に伴う金銭振替明細の作成を行うという観点では、不都合はない。寄附や四半期フィー徴収等の他の月末イベントの発生後に運用口削除の申込があった場合も同様である。
なお、後述するように、本発明は、海外休場日等を考慮して国内外の投資信託の注文の日付管理を行うシステムであるともいえるが、このような観点から本発明に関連するシステムとしては、例えば、外国籍投資信託についてのルックスルー（ファンド内の資産構成の把握）の管理を実現する金融商品管理システムが知られている（特許文献１参照）。この金融商品管理システムでは、組み入れられるファンド毎に、ルックスルー後の残高を作成する頻度をユーザが日次／月次から選択することができる。また、投資信託の基準価額を算定する処理の日付管理を行う基準価額算定システムも知られている（特許文献２参照）。
特開２０１８−６０５４３号公報（段落［００５２］） 特開２００５−２８４７１５号公報（請求項２、段落［００１９］、［００２７］、［００３２］、［００３３］）
前述したように、従来システムでは、海外休場日を考慮することなく注文予定日を定め、その注文予定日の前営業日に注文データを作成している。従って、注文予定日が、実際の注文日にならない場合もあるので、翌営業日が注文できない日であっても、注文データを作成していることになる。
ところで、ファンドラップサービスでは、顧客と金融機関との間で締結した投資一任契約に基づき、顧客が選択した運用スタイルに沿ったポートフォリオ（顧客が保有する投資信託の各銘柄の配分比率）を維持する必要がある。従って、各種の増額系・減額系イベントの売買注文の注文データを作成する際には、このポートフォリオが維持されるように、投資信託の各銘柄の売買注文を作成する必要がある。すなわち、各銘柄の売買注文を行い、それらの注文が約定した後の状態が、所望のポートフォリオまたはそれに近い状態となるようにする必要がある。なお、近い状態という表現をしたのは、注文から約定までの基準価額の変動により、所望のポートフォリオの通りにならない場合もあるからである。
この際、注文データの売買金額の算出には、顧客が運用口（イベントの対象となる運用口）で保有する投資信託の各銘柄の評価金額が使用される。各銘柄の評価金額は、保有する各銘柄の数量残高（口数）およびそれらの各銘柄の基準価額を用いて算出されるので、注文データ作成タイミングにより、基準価額の変動の影響を受けることになり、これに伴って、算出される売買金額もその影響を受けることになる。例えば、増額イベントの場合には、注文データ作成時点での各保有銘柄の評価金額の合計金額に、増額金額を加えた金額を、所望のポートフォリオの通りに各銘柄に配分し、各銘柄の買付金額を決定する（図１５参照）。この処理の詳細については、図１５に示す具体例を用いて、本発明との比較において後述する。
従って、注文データ作成日から実際の注文日までの期間が長いと、その分だけ、当該期間中の基準価額の変動により、注文データ作成時の評価金額と、注文約定時の評価金額との差異が大きくなる可能性があるので、注文データ作成時には、運用スタイルに沿ったポートフォリオを維持するように各銘柄の売買金額を決定していたとしても、その後の基準価額の変動状況により、所望のポートフォリオからの乖離率が大きくなる場合も生じ得る。
このため、顧客との契約で設定した運用スタイルに沿った最適なポートフォリオを構築するためには、注文データ作成日と注文日とを近づける必要がある。しかし、従来システムでは、海外休場日を考慮することなく注文予定日を定め、その注文予定日の前営業日に注文データを作成するので、海外休場日が間に入ることで、注文データ作成日と注文日とが離れてしまう事態が生じ得ることから、結果的に、注文の約定後の状態について、所望のポートフォリオからの乖離率が大きくなってしまう可能性があった。
また、ファンドラップサービスでは、顧客との契約で設定した運用スタイルに沿った最適なポートフォリオを維持するためのリバランス（各銘柄の売買処理）を定期的に行うが、このリバランスの際にも、各保有銘柄の評価金額の算出が行われる。このリバランスは、従来システムでは、顧客との契約に従って、月末営業日に、リバランスの実施の要否を判定するリバランス判定処理を行い、リバランスの実施が必要であると判定された場合には、その日（月末営業日）に、リバランスのための注文データを作成していた。
しかし、リバランスの場合も、注文データ作成日（月末営業日）の翌営業日である翌月の月初営業日が、海外休場日に該当することがあり、注文データ作成日と注文日とが離れてしまう事態が生じ得るので、同様な問題が生じる。
以上より、海外休場日等のように、国内の非営業日の他にも注文できない日があることを前提とし、顧客との契約で設定した運用スタイルに沿ったポートフォリオを適切に維持することができるファンドラップシステムの開発が望まれる。一方、仮に、海外休場日等を含め、営業日（本願で営業日というときは、国内の営業日である。）であるか否か以外の要素を加味し、注文データ作成タイミングを定めたとすると、システム処理上、注文の日付管理や、顧客との契約事項の忠実な履行が困難になる場合があるので、そのような問題を解消する必要がある。
本発明の目的は、運用スタイルに沿ったポートフォリオを適切に維持することができるファンドラップシステムおよびプログラムを提供するところにある。
＜注文データ作成タイミング判断処理および日付の算出対象銘柄の選択処理を行う発明＞
本発明は、顧客から預かった資産を顧客により選択された運用口毎の運用スタイルで運用する投資一任サービスとして、投資信託への投資を取り扱うファンドラップサービスを提供する処理を実行するコンピュータからなるファンドラップシステムであって、
投資信託の売買について、営業日であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報を、投資信託の銘柄識別情報と関連付けて記憶する注文可否日記憶手段と、
注文日から約定日までの日数、および注文日から受渡日までの日数を、投資信託の銘柄識別情報と関連付けて記憶する約定・受渡日数記憶手段と、
顧客の運用口を構成する投資信託の各銘柄についての銘柄識別情報を、顧客識別情報および運用口識別情報と関連付けて記憶する運用口銘柄構成記憶手段と、
顧客の保有する投資信託の残高数量を、銘柄識別情報、顧客識別情報、および運用口識別情報と関連付けて記憶する残高記憶手段と、
運用口銘柄構成記憶手段に記憶されている運用口の各構成銘柄、または残高記憶手段に記憶されている当該運用口の残高数量がゼロでない各保有銘柄のいずれかから選択した日付の算出対象銘柄について、当該運用口の全ての銘柄について注文可能な日として注文可否日記憶手段に記憶されている日を、当該運用口の各銘柄に共通する注文日として決定し、決定した注文日に対応する約定日および受渡日を約定・受渡日数記憶手段に記憶された日数から算出するとともに、当該運用口の全ての算出対象銘柄についての約定日および受渡日から最遅約定日および最遅受渡日を求め、得られた注文日、約定日、および受渡日を、銘柄識別情報および運用口識別情報と関連付けて算出日付記憶手段に記憶させるとともに、得られた最遅約定日および最遅受渡日を、運用口識別情報と関連付けて前記算出日付記憶手段に記憶させる処理を毎営業日に実行する日付算出手段と、
売買注文の作成を要するイベントが発生した場合に、当該イベントの発生時点で算出日付記憶手段に記憶されている注文日、最遅約定日、および最遅受渡日を、当該イベントについてのイベント番号、顧客識別情報、および運用口識別情報と関連付けて注文管理記憶手段に記憶させる注文管理処理を実行するイベント反映手段と、
注文管理記憶手段に記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、イベント発生以降の毎営業日に実行し、注文データを作成すると判断した場合に、当該判断時点で算出日付記憶手段に記憶されている注文日、約定日、および受渡日を用いてこれらの日付および注文データを含む注文明細を作成し、作成した注文明細を、顧客識別情報および運用口識別情報と関連付けて注文明細記憶手段に記憶させる注文明細作成処理を実行する注文作成手段とを備え、
イベント反映手段は、
運用スタイルを変更するスタイル変更のイベント、または、運用スタイルを構成する資産クラス内の銘柄を変更する投資対象銘柄変更のイベントが発生した場合には、運用口銘柄構成記憶手段に記憶されている当該運用口の各構成銘柄を、変更後の銘柄に更新する銘柄変更処理も実行する構成とされ、
日付算出手段は、
注文管理記憶手段に記憶されているイベント番号および最遅約定日を用いて、スタイル変更のイベントまたは投資対象銘柄変更のイベントが発生し、かつ、スタイル変更または投資対象銘柄変更による売注文の最遅約定日よりも前の日であると判断した場合には、残高記憶手段に記憶されている当該運用口の残高数量がゼロでない各保有銘柄を、算出対象銘柄として選択し、それ以外の場合には、運用口銘柄構成記憶手段に記憶されている当該運用口の各構成銘柄を、算出対象銘柄として選択する処理を実行する構成とされている
ことを特徴とするものである。
ここで、「営業日であるか否か以外の要素」としては、例えば、海外休場日に該当するか否か、あるいは、急激な相場変動に伴う注文回避期間やその他のルールによる注文回避期間に該当するか否か等がある。なお、ここでいう「営業日」を含め、本願で単に「営業日」というときは、国内の営業日を指す。後者の注文回避期間は、例えば、急激な相場変動があったときには、所定日数（例えば３日間）待ってから注文日とすることができるといったルールがある場合の当該期間であり、急激な相場変動の発生の有無は、人工知能（ＡＩ）等による自動判断でもよく、担当者による判断でもよい。また、注文回避期間の長さも、予め定めた期間長としてもよく、その都度、ＡＩ等の機械または担当者が定めた期間長としてもよい。他の発明についても同様である。
また、「運用口」は、１人の顧客につき、複数設定されていてもよいが、１つだけでもよい。運用口が１つだけの場合には、システムとして複数の運用口の設定が可能となっているものの、顧客がたまたま１つか運用口を設定していないケースと、元々、システムが複数の運用口の設定を許容していないケースとが含まれる。後者のケースでは、運用口識別情報と、顧客識別情報とは、同じものとしてもよい。他の発明についても同様である。
さらに、「注文日と判断時点の日との関係が予め定められた注文作成条件を満たすか否か」における「注文作成条件」は、例えば、判断時点における翌営業日と、注文日とが一致する等の条件であり、注文日と判断時点の日との相対的な関係を定めた条件である。他の発明についても同様である。
このような本発明のファンドラップシステムにおいては、営業日であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報が、注文可否日記憶手段に記憶され、この情報を用いて決定された注文日が、イベント反映手段による注文管理処理で、注文管理記憶手段に記憶され、注文作成手段による注文データ作成タイミング判断処理で、注文管理記憶手段に記憶されている注文日を用いて、判断時点の日に注文データを作成するか、または作成を待機するかを判断するので、注文データ作成日と注文日とを近づけることが可能となる。このため、注文データ作成時の評価金額と、注文約定時の評価金額との差異を小さくすることが可能となり、適切な売買金額を含む注文データを作成することが可能となるので、従来システムに比べ、運用スタイルに沿ったポートフォリオを、より一層適切に維持することができるようになる。
また、上記のように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、注文明細を作成することができなくなる事態が生じる。すなわち、注文明細の作成には、売買金額を含む注文データの他に、注文管理上の日付（注文日、約定日、受渡日）が必要となるが、スタイル変更のイベントまたは投資対象銘柄変更のイベントが発生し、運用口銘柄構成記憶手段に記憶されている運用口（イベントの対象となる運用口）の各構成銘柄が変更されてしまうと、日付算出手段により、注文明細の作成に必要な日付が算出されていないという事態が生じる。この事態の発生状況の詳細については、図１６の具体例を用いて後述する。
これに対し、本発明では、スタイル変更や投資対象銘柄変更のイベントの発生状況や注文の進行状況に応じ、日付算出手段による日付の算出対象銘柄を、運用口銘柄構成記憶手段に記憶されている運用口の各構成銘柄、または残高記憶手段に記憶されている当該運用口の残高数量がゼロでない各保有銘柄のいずれかから選択するようにしたので、上述したような注文明細の作成に必要な日付が算出されていないという事態を回避することが可能となり、これらにより前記目的が達成される。
＜注文データ作成タイミング判断処理および金銭振替明細作成処理を行う発明＞
また、本発明は、顧客から預かった資産を顧客により選択された運用口毎の運用スタイルで運用する投資一任サービスとして、投資信託への投資を取り扱うファンドラップサービスを提供する処理を実行するコンピュータからなるファンドラップシステムであって、
投資信託の売買について、営業日であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報を、投資信託の銘柄識別情報と関連付けて記憶する注文可否日記憶手段と、
顧客の金銭残高を、顧客識別情報と関連付けて記憶する金銭残高記憶手段と、
運用口削除またはその他のイベントの申込を受け付ける処理を実行する設定受付手段と、
売買注文の作成を要するイベントが発生した場合に、注文可否日記憶手段に記憶された情報を用いて決定された当該イベントの売買注文についての注文日を、当該イベントについてのイベント番号、顧客識別情報、および運用口識別情報と関連付けて注文管理記憶手段に記憶させる注文管理処理を実行するとともに、設定受付手段により運用口削除のイベントの申込を受け付けた場合に、注文管理記憶手段に記憶されている注文日を用いて注文データ作成待機中になっている別のイベントの有無を判断し、注文データ作成待機中になっている別のイベントがあった場合に、当該別のイベントを抹消扱いとするイベント抹消処理を実行するイベント反映手段と、
抹消扱いとなっていないイベントの売買注文について、注文管理記憶手段に記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、抹消扱いとなっていないイベント発生以降の毎営業日に実行し、注文データを作成すると判断した場合に、注文データを含む注文明細を作成し、作成した注文明細を、顧客識別情報および運用口識別情報と関連付けて注文明細記憶手段に記憶させる注文明細作成処理を実行する注文作成手段と、
金銭残高記憶手段に記憶された金銭残高について通信回線で接続された売買システムまたは他のシステムとの間で金銭振替処理を実行するとともに、金銭振替金額を含む金銭振替明細を作成する金銭振替明細作成処理を実行する金銭振替手段とを備え、
注文作成手段は、
運用口削除のイベントの申込があり、定期受取、寄附、またはその他の売注文を伴う月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文の注文データを作成する際には、抹消扱いとした月末イベントの売注文の分を含めた状態の数量または金額を、運用口削除の売注文の注文数量または注文金額とする処理を実行する構成とされ、
金銭振替手段は、
運用口削除のイベントの申込があり、月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文の約定に伴って金銭残高記憶手段に記憶された金銭残高の全額を金銭振替金額とする金銭振替処理を実行するとともに、抹消扱いとした月末イベントの売注文により得られるはずであった売却金額を含む定期受取の金銭振替明細、および、金銭振替金額から月末イベントの売注文により得られるはずであった売却金額を差し引いた金額を含む運用口削除の金銭振替明細を作成する処理を実行する構成とされている
ことを特徴とするものである。
ここで、「月末イベント」の「月末」とは、必ずしも暦上の月末に限定されるものではなく、会計処理上の締日等の場合と同様に、例えば、当月の２５日や、翌月の５日等としてもよく、要するに、月と月とを仕切るために予め定められた日であればよい。
また、「売買システムまたは他のシステム」における「他のシステム」は、ファンドラップサービスを提供する金融機関が運営・管理する別のシステムでもよく、別の金融機関が運営・管理するシステムでもよい。
このような本発明のファンドラップシステムにおいては、前述した＜注文データ作成タイミング判断処理および日付の算出対象銘柄の選択処理を行う発明＞の場合と同様に、注文作成手段により注文データ作成タイミング判断処理を行うので、注文データ作成日と注文日とを近づけることが可能となる。このため、注文データ作成時の評価金額と、注文約定時の評価金額との差異を小さくすることが可能となり、適切な売買金額を含む注文データを作成することが可能となるので、従来システムに比べ、運用スタイルに沿ったポートフォリオを、より一層適切に維持することができるようになる。
また、上記のように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、顧客との契約上、必要となる金銭振替明細を作成することができなくなる事態が生じる場合がある。すなわち、定期受取や寄附等の月末イベントは、顧客との契約に基づき、条件を満たしたら実施し、売注文を行うべきイベントであるが、本発明では、このような月末イベントが発生し、注文データの作成が待機状態となっている最中に、運用口削除が申し込まれる場合が考えられ、この場合に、運用口削除の申込により、定期受取等の月末イベントを抹消扱いとし、それ以降の処理を行わないことにすると、注文データの作成、注文、金銭振替明細の作成の各処理が行われないことになってしまう。定期受取や寄附等は、顧客との契約に従って実施されるものであるので、一旦、実施するという判定結果が出て、これらの月末イベントが発生したら、売注文を行い、金銭振替明細の作成も行うべきものであるため、好ましくない事態が生じることになる。運用口削除の申込は、定期受取や寄附等を実施するという判定結果が出た後に行われているからである。このような事態の発生の詳細については、図２０および図２１に示した具体例を用いて、本発明との比較において後述する。なお、従来システムでは、注文データの作成待機は行われないので、前述した図２５で示したように、月末営業日に、定期受取等の売注文の注文データが作成され、それによるホールド期間が設定され、運用口削除の売注文の注文データの作成が制限されるので、このような事態は生じなかった。
これに対し、本発明では、定期受取等の月末イベントについては、抹消扱いとし、売注文の注文データの作成は行わないようにするが、金銭振替明細は、運用口削除の申込が無ければ、本来得られるはずであった売却金額を含む状態で作成するようにする。一方、運用口削除のイベントについては、抹消扱いとした定期受取等の月末イベントの売注文の分を含めた状態の注文数量または注文金額を含む売注文の注文データを作成し、金銭振替明細の作成では、抹消扱いとした定期受取等の月末イベントの売注文により得られるはずであった売却金額を差し引いた金額を含む金銭振替明細を作成するようにする。このため、顧客との契約上、必要となる金銭振替明細を作成することができなくなるという問題を解消することが可能となり、これらにより前記目的が達成される。
＜注文データ作成タイミング判断処理を行うとともに、リバランスのための注文データの作成をリバランスの実施の要否判定と切り離して行う発明＞
さらに、本発明は、顧客から預かった資産を顧客により選択された運用口毎の運用スタイルで運用する投資一任サービスとして、投資信託への投資を取り扱うファンドラップサービスを提供する処理を実行するコンピュータからなるファンドラップシステムであって、
投資信託の売買について、営業日であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報を、投資信託の銘柄識別情報と関連付けて記憶する注文可否日記憶手段と、
投資信託の基準価額を、投資信託の銘柄識別情報と関連付けて記憶する単価情報記憶手段と、
顧客の保有する投資信託の残高数量を、銘柄識別情報、顧客識別情報、および運用口識別情報と関連付けて記憶する残高記憶手段と、
リバランス実施判定年月日になった場合に、残高記憶手段に記憶された運用口の各保有銘柄の残高数量についてのリバランス判定時点での基準価額による評価金額、運用口銘柄構成記憶手段および運用スタイル・資産クラス構成記憶手段に記憶されている設定構成比率、並びに、契約記憶手段に記憶されているリバランス判定基準乖離率を用いて、リバランスの実施の要否を判定するリバランス判定処理を実行するリバランス手段と、
このリバランス手段によりリバランスの実施が必要であると判定された場合、または売買注文の作成を要するその他のイベントが発生した場合に、注文可否日記憶手段に記憶された情報を用いて決定された当該リバランスまたはその他のイベントの売買注文についての注文日を、当該リバランスまたはその他のイベントについてのイベント番号、顧客識別情報、および運用口識別情報と関連付けて注文管理記憶手段に記憶させる注文管理処理を実行するイベント反映手段と、
リバランスまたはその他のイベントの売買注文について、注文管理記憶手段に記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、リバランスまたはその他のイベント発生以降の毎営業日に実行し、注文データを作成すると判断した場合に、注文データを含む注文明細を作成し、作成した注文明細を、顧客識別情報および運用口識別情報と関連付けて注文明細記憶手段に記憶させる注文明細作成処理を実行する注文作成手段とを備え、
注文作成手段は、
リバランスのイベントについては、残高記憶手段に記憶された運用口の各保有銘柄の残高数量についての注文データ作成タイミング判断時点での基準価額による評価金額、並びに、運用口銘柄構成記憶手段および運用スタイル・資産クラス構成記憶手段に記憶されている設定構成比率を用いて、リバランスの売買注文の注文数量または注文金額を算出して注文データを含む注文明細を作成し、作成した注文明細を、顧客識別情報および運用口識別情報と関連付けて注文明細記憶手段に記憶させる注文明細作成処理を実行する構成とされている
ことを特徴とするものである。
ここで、「注文作成手段は、リバランスのイベントについては、・・・注文データ作成タイミング判断時点での基準価額による評価金額・・・を用いて、リバランスの売買注文の注文数量または注文金額を算出して注文データを含む注文明細を作成し」とされているのは、リバランスのための注文データを作成する際には、必ずしもリバランス判定処理を行った日における基準価額による評価金額と同じ評価金額を使用するわけではないことを示す趣旨である。すなわち、リバランス判定処理を行った日に注文データが作成されない場合において、その後日に、リバランスのための注文データを作成する際には、リバランスの実施の要否判定で使用した基準価額による評価金額と同じ評価金額を使用するのではなく、注文データ作成時点での評価金額を使用することを示す趣旨である。なお、リバランスの実施の要否判定から注文データ作成までの間に、基準価額に変動が無ければ、結果的に同じ評価金額を使用することになり、また、リバランス判定処理を行った日に注文データ作成待機にならなければ、同じ評価金額を使用することになる。従って、上記の「リバランスのイベントについては、・・・」という記載は、リバランス以外のイベントと対比する趣旨ではないので、リバランス以外のイベントの注文データの作成も、注文データ作成時点での評価金額を使用してよい。
このような本発明のファンドラップシステムにおいては、前述した＜注文データ作成タイミング判断処理および日付の算出対象銘柄の選択処理を行う発明＞の場合と同様に、注文作成手段により注文データ作成タイミング判断処理を行うので、注文データ作成日と注文日とを近づけることが可能となる。このため、注文データ作成時の評価金額と、注文約定時の評価金額との差異を小さくすることが可能となり、適切な売買金額を含む注文データを作成することが可能となるので、従来システムに比べ、運用スタイルに沿ったポートフォリオを、より一層適切に維持することができるようになる。このことは、リバランスでも、その他のイベントでも同様である。
また、上記のように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、リバランスについて従来通りの考え方を踏襲すると、不都合が生じる可能性がある。すなわち、予め定められた日（例えば、月末営業日）にリバランス判定処理を行い、リバランスの実施が必要であると判定されても、その日にリバランスのための注文データが作成されず、作成を待機する状態となる場合（例えば、翌月の月初営業日が海外休場日となる銘柄がある場合）があるので、従来通りの考え方を踏襲すると、それ以降で注文が可能になる日の前営業日（例えば、海外休場日となっている翌月の月初営業日、または翌月の月初営業日から海外休場日が２日以上連続している場合には、連続する海外休場日の最後の日）にリバランス判定処理を再度実行し、リバランス要の判定結果が出たときに、リバランスのための注文データの作成を行うことになる。しかし、リバランス判定処理は、顧客との契約で、予め定められた日（例えば、月末営業日）に運用スタイルに沿ったポートフォリオとなっているか否かを確認する処理であるため、リバランス判定処理の実行日が、予め定められた日（例えば、月末営業日）よりも後の日になってしまうことは好ましくない。
これに対し、本発明では、リバランスのための注文データの作成をリバランスの実施の要否判定と切り離して行うので、注文データ作成待機に伴ってリバランス判定処理の実行日も、予め定められた日（例えば、月末営業日）よりも後の日になってしまうという事態を回避することができる。このため、予め定められた日におけるリバランス判定処理の実行を確保できるので、契約の忠実な履行を実現することが可能となる。すなわち、本発明では、リバランス判定処理は、再実行することはなく、予め定められた日（例えば、月末営業日）に実行するだけとし、そのときのリバランス要の判定結果を受けて、注文データ作成タイミング判断処理により注文作成条件を満たした場合に、リバランス実施の要否判定時点ではなく、注文データ作成タイミング判断時点での基準価額による評価金額を用いて注文データを作成する。なお、リバランス実施の要否判定時点からの基準価額の変動の大きさによっては、注文データ作成タイミング判断時点では、既にリバランスを実施しなくてもよい程に、ポートフォリオが所望の状態になっている場合もあり得るが、この場合でも、一旦、リバランスを実施するという判定結果が出ている以上、顧客との契約を忠実に履行するという観点で、注文データを作成し、注文を行う。
また、従来システムでは、予め定められた日（例えば、月末営業日）にリバランス判定処理を行い、リバランス要の判定結果が出たら、その日に注文データを作成していたので、海外休場日等の介在により、注文データ作成日と実際の注文日とが離れてしまう場合があり、作成した注文データを用いて注文を行ったとしても、注文約定後の状態が、所望のポートフォリオまたはそれに近い状態になっていない場合も生じ得ることから、リバランス実施の効果が十分に得られない可能性もあった。つまり、注文に使用する注文データが、リバランスの役に立たない状態になっている可能性もあった。これに対し、本発明では、注文データ作成日と注文日とを近づけることが可能となるので、リバランス実施の効果が適切に得られる注文データを作成して注文を行うことが可能となり、これらにより前記目的が達成される。
＜プログラムの発明＞
また、本発明のプログラムは、以上に述べたファンドラップシステムとして、コンピュータを機能させるためのものである。
なお、上記のプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、フレキシブルディスク（ＦＤ）、磁気テープ、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、フラッシュディスク等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ＬＡＮ、ＭＡＮ、ＷＡＮ、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、上記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。
以上に述べたように本発明によれば、注文作成手段により注文データ作成タイミング判断処理を行うので、注文データ作成日と注文日とを近づけることができ、適切な売買金額を含む注文データを作成することができるため、運用スタイルに沿ったポートフォリオを適切に維持することができるとともに、注文データ作成タイミングの変更に伴う諸問題を解消することもできるという効果がある。
本発明の一実施形態のファンドラップシステムおよびその周辺システムの全体構成図。 前記実施形態の顧客識別情報および運用口識別情報の説明図。 前記実施形態の主口座記憶手段、契約記憶手段、および運用口記憶手段のレコード構成の一例を示す図。 前記実施形態の金銭残高記憶手段のレコード構成の一例を示す図。 前記実施形態の単価情報記憶手段のレコード構成の一例を示す図。 前記実施形態の運用スタイル記憶手段、運用スタイル・資産クラス構成記憶手段、および資産クラス銘柄構成記憶手段のレコード構成の一例を示す図。 前記実施形態のイベント記憶手段のレコード構成の一例を示す図。 前記実施形態のリバランス記憶手段のレコード構成の一例を示す図。 前記実施形態の四半期フィー徴収記憶手段のレコード構成の一例を示す図。 前記実施形態の注文管理記憶手段のレコード構成の一例を示す図。 前記実施形態の注文明細記憶手段および注文データ記憶手段のレコード構成の一例を示す図。 前記実施形態の定期受取明細記憶手段のレコード構成の一例を示す図。 前記実施形態の金銭振替明細記憶手段のレコード構成の一例を示す図。 前記実施形態の翌営業日用の日付の算出処理の説明図。 前記実施形態の注文データ作成タイミングの変更の説明図。 前記実施形態の各日付の算出対象銘柄の変更（その１）の説明図。 前記実施形態の各日付の算出対象銘柄の変更（その２）の説明図。 前記実施形態のスタイル変更の申込があった場合の処理の流れを示すフローチャートの図。 前記実施形態の金銭振替明細の作成処理の説明図。 前記実施形態の金銭振替明細の作成処理（比較参照用処理（１））の説明図。 前記実施形態の金銭振替明細の作成処理（比較参照用処理（２））の説明図。 前記実施形態の金銭振替明細の作成処理の流れ（その１）を示すフローチャートの図。 前記実施形態の金銭振替明細の作成処理の流れ（その２）を示すフローチャートの図。 従来システムの注文データ作成タイミングの説明図。 従来システムの金銭振替明細の作成タイミングの説明図。
以下に本発明の一実施形態について図面を参照して説明する。図１には、本実施形態のファンドラップシステム１０およびその周辺システムの全体構成が示されている。図２は、顧客識別情報および運用口識別情報の説明図である。図３〜図１４には、記憶手段４０に含まれる各記憶手段４１〜６１の構成が示されている。また、図１５は、注文データ作成タイミングの変更、図１６および図１７は、各日付の算出対象銘柄の変更の説明図である。図１８には、スタイル変更の申込があった場合の処理の流れがフローチャートで示されている。さらに、図１９〜図２１は、金銭振替明細の作成処理の説明図であり、図２２および図２３には、金銭振替明細の作成処理の流れがフローチャートで示されている。
＜ファンドラップシステム１０およびその周辺システムの全体構成＞
図１において、顧客に対してファンドラップサービスを提供する証券会社等の金融機関が運営・管理するファンドラップシステム１０が設けられ、その周辺システムとして、ファンドラップシステム１０と通信回線２を介して接続された金融商品（本実施形態では、ファンドラップサービスを行うので、投資信託となる。）の売買システム７０が設けられている。
また、売買システム７０には、通信回線３を介して金融商品情報提供システム９０が接続されている。なお、金融商品情報提供システム９０は、通信回線４を介してファンドラップシステム１０と直接に接続されていてもよい。
さらに、ファンドラップシステム１０には、通信回線であるネットワーク１を介して、顧客またはその入力代行者（証券会社等の金融機関の営業員やオペレータ等）が操作する１台または複数台（通常は、多数）の端末装置１００が接続されるとともに、通信回線５またはネットワーク１を介して証券会社等の金融機関のシステム担当者が操作する１台または複数台の端末装置１１０が接続されている。
ここで、ネットワーク１は、本実施形態では、主としてインターネットを中心に構成され、有線であるか、無線であるか、有線・無線の混在型であるかは問わない。通信回線２は、ＬＡＮやイントラネット等の社内ネットワークであるが、ネットワーク１としてもよく、専用線としてもよい。通信回線３，４は、ネットワーク１や社内ネットワークにより構成してもよく、専用線により構成してもよい。通信回線５は、ＬＡＮやイントラネット等の社内ネットワークである。
ファンドラップシステム１０は、１台または複数台のコンピュータにより構成され、ファンドラップサービスに関する各種処理を実行する処理手段２０と、この処理手段２０で使用する各種データを記憶する記憶手段４０とを備えている。
このうち、処理手段２０は、設定受付手段２１と、イベント準備手段２２と、リバランス手段２３と、イベント反映手段２４と、注文作成手段２５と、日付算出手段２６と、手数料算出手段２７と、注文データ連携手段２８と、約定処理手段２９と、資産管理手段３０と、金銭振替手段３１と、帳票作成用データ連携手段３２とを含んで構成されている。
これらの処理手段２０に含まれる各手段２１〜３２は、ファンドラップシステム１０を構成するコンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに、主メモリやキャッシュメモリ等の作業用メモリ等により実現される。なお、これらの各手段２１〜３２の詳細は、後述する。
また、記憶手段４０は、主口座記憶手段４１と、契約記憶手段４２と、運用口記憶手段４３と、金銭残高記憶手段４４と、単価情報記憶手段４５と、運用スタイル記憶手段４６と、運用スタイル・資産クラス構成記憶手段４７と、資産クラス銘柄構成記憶手段４８と、イベント記憶手段４９と、リバランス記憶手段５０と、四半期フィー徴収記憶手段５１と、注文管理記憶手段５２と、注文明細記憶手段５３と、注文データ記憶手段５４と、定期受取明細記憶手段５５と、金銭振替明細記憶手段５６と、注文可否日記憶手段５７と、約定・受渡日数記憶手段５８と、運用口銘柄構成記憶手段５９と、残高記憶手段６０と、算出日付記憶手段６１とを含んで構成されている。また、算出日付記憶手段６１は、銘柄単位算出日付記憶手段６１Ａと、資産クラス単位算出日付記憶手段６１Ｂと、運用口単位算出日付記憶手段６１Ｃとを含んで構成されている。
これらの記憶手段４０に含まれる各記憶手段４１〜６１は、例えばハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、例えば、ＤＶＤ、ＣＤ、ＭＯ、磁気テープ等の他の記録媒体を採用してもよい。また、各記憶手段４１〜６１のデータ保存形式は、データベースでもよく、フラットファイル等のファイル形式でもよい。データベースとする場合には、各記憶手段４１〜６１をそれぞれ別々のデータベースとしてもよく、１つまたは幾つかのデータベース内の異なるテーブルとしてもよい。なお、これらの各記憶手段４１〜６１の詳細は、後述する。
売買システム７０は、金融商品の売買取引の取次を行う証券会社等の金融機関の基幹システムであり、金融商品の注文受付、顧客の買付余力判断、注文作成、市場等への発注、約定処理、顧客の保有資産の残高管理等のような金融商品の売買に関する各種の処理を実行するが、本実施形態では、ファンドラップサービスを行うので、これらの各種機能のうちの投資信託の売買処理に関する機能を利用する。
この売買システム７０は、１台または複数台のコンピュータにより構成され、売買処理手段７１と、約定データ連携手段７２と、売買システム側金銭振替手段７３と、帳票作成手段７４とを備えている。
これらの各手段７１〜７４は、売買システム７０を構成するコンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに、主メモリやキャッシュメモリ等の作業用メモリ等により実現される。なお、これらの各手段７１〜７４の詳細は、後述する。
また、売買システム７０は、注文データ記憶手段８１と、約定データ記憶手段８２と、帳票作成用データ記憶手段８３と、帳票記憶手段８４とを備えている。
これらの各記憶手段８１〜８４は、例えばハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、例えば、ＤＶＤ、ＣＤ、ＭＯ、磁気テープ等の他の記録媒体を採用してもよい。また、各記憶手段８１〜８４のデータ保存形式は、データベースでもよく、フラットファイル等のファイル形式でもよい。なお、これらの各記憶手段８１〜８４の詳細は、後述する。
金融商品情報提供システム９０は、本実施形態では、ファンドラップサービスを行うために必要となる金融商品の情報（例えば、投資信託の各銘柄の基準価額等）を提供するシステムの総称として用いており、具体的には、例えば、投資信託の運用会社のシステム、ファンドラップシステム１０や売買システム５０を運営・管理する会社（証券会社等の金融機関）内の他のシステム（例えば、ファンドラップサービス以外のサービスに関するデータ処理を実行するシステム等）、情報ベンダーのシステム等であり、これらのシステムは、それぞれ１台または複数台のコンピュータにより構成されている。
従って、例えば、投資信託の基準価額については、金融商品情報提供システム９０としての投資信託の運用会社のシステムで計算され、その計算結果が、通信回線３を介して売買システム７０へ送信され、さらに売買システム７０を経由して通信回線２を介してファンドラップシステム１０へ送信されるか、あるいは、通信回線４を介してファンドラップシステム１０へ直接に送信されるようになっている。そして、投資信託の基準価額は、ファンドラップシステム１０の単価情報記憶手段４５（図５参照）に記憶され、顧客の保有資産の評価金額（残高金額）の算出に用いられる。また、株式や債券等の単価、あるいは、例えば、日経平均、ＮＹダウ、原油価格等の各種の金融指標についての指標値については、ＡＩ等による注文回避期間（例えば、急激な相場変動があったとき等に注文を回避すべき期間であり、注文可否日記憶手段５７に反映される期間）の判断材料や、顧客の保有資産のポートフォリオのリバランスを行う際の判断材料となる場合があるので、金融商品情報提供システム９０としての情報ベンダーのシステムまたは自社内の他のシステムから提供され、ファンドラップシステム１０の単価情報記憶手段４５（図５参照）に記憶されるようになっている。
端末装置１００，１１０は、コンピュータにより構成され、例えばマウスやキーボード等の入力手段と、例えば液晶ディスプレイ等の表示手段とを備えている。これらの端末装置１００，１１０は、例えば、スマートフォン、タブレット端末、携帯情報端末（ＰＤＡ）等の携帯機器でもよい。
＜ファンドラップシステム１０で取り扱う各種イベントの内容および処理の概略＞
ファンドラップシステム１０では、新規契約、増額、減額、運用口追加、運用口削除、スタイル変更、投資対象銘柄変更、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、定期受取、寄附申込、寄附先変更、寄附金額変更、寄附、定期積立申込、定期積立変更（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等の変更）、定期積立、リバランス判定基準乖離率変更、リバランス、四半期フィー徴収等の各種イベントを取り扱う。これらのイベントの内容および処理の概略は、以下の通りである。
新規契約は、顧客が運用口を１つまたは複数個設定し、各運用口についての運用スタイルおよび設定金額（運用する金額）を定め、これらの情報をシステムに登録するイベントである。各運用口についての設定金額の合計金額が、新規契約金額である。また、リバランス判定基準乖離率も設定する。なお、リバランス判定基準乖離率の設定は、本実施形態では、運用口単位の設定ではないが、運用口単位の設定としてもよい。この新規契約のイベントでは、新規契約の申込が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に新規契約のレコード（新規設定した各運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、新規運用開始日、新規契約時の設定金額（運用口単位）等を含む）が作成されるとともに、設定受付手段２１により、主口座記憶手段４１、契約記憶手段４２、および運用口記憶手段４３（図３参照）にレコードが作成され、設定した情報が登録される。その後、顧客により申込時に指定されてイベント記憶手段４９（図７参照）に記憶されている新規運用開始日の前営業日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（新規契約なので、買注文である。）が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている各運用口の新規契約時の設定金額を用いて各運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、一部の金額は、契約時フィーとして徴収されるので、その金額分だけ、新規契約イベントでの買付金額は少なくなる。
増額は、新規契約後に運用口単位での設定金額の増額を行うイベントである。この増額の申込は、任意の時期に行うことができ、申込時に指定した運用開始日から、増額した状態での運用が開始される。この増額のイベントでは、増額の申込が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に増額のレコード（増額対象の運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、運用開始日、増額金額等を含む）が作成され、その後、そのレコードの情報を用いて、運用開始日の前営業日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（増額なので、買注文である。）が記憶される。また、イベント反映手段２４により、運用口記憶手段４３（図３参照）の増額対象の運用口のレコードにおける設定金額を、増額金額の分だけ増額させる更新処理を行う。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている増額金額を用いて増額対象の運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、増額の場合にも、一部の金額を、契約時フィーとして徴収してもよく、その場合には、その金額分だけ、増額イベントでの買付金額は少なくなる。
減額は、新規契約後に運用口単位での設定金額の減額を行うイベントである。この減額の申込は、任意の時期に行うことができ、申込日の翌営業日から、減額した状態での運用が開始される。この減額のイベントでは、減額の申込が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に減額のレコード（減額対象の運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、減額金額等を含む）が作成され、その後、そのレコードの情報を用いて、申込日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（減額なので、売注文である。）が記憶される。また、イベント反映手段２４により、運用口記憶手段４３（図３参照）の減額対象の運用口のレコードにおける設定金額を、減額金額の分だけ減額させる更新処理を行う。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている減額金額を用いて減額対象の運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
運用口追加は、新規契約後に運用口を追加し、追加する運用口についての運用スタイルおよび設定金額（運用する金額）を定め、これらの情報をシステムに登録するイベントである。この運用口追加の申込は、任意の時期に行うことができ、申込時に指定した運用開始日から、追加した運用口での運用が開始される。この運用口追加のイベントでは、運用口追加の申込が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に運用口追加のレコード（追加した運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、運用口追加時の設定金額、運用開始日等を含む）が作成されるとともに、設定受付手段２１により、運用口記憶手段４３（図３参照）に追加された運用口のレコードが作成され、設定した情報が登録される。その後、申込時に指定されてイベント記憶手段４９（図７参照）に記憶されている運用開始日の前営業日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（運用口追加なので、買注文である。）が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている追加された運用口の設定金額を用いてその運用口の注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、一部の金額は、契約時フィーとして徴収されるので、その金額分だけ、運用口追加イベントでの買付金額は少なくなる。
運用口削除は、運用口を削除し、その運用口で運用されている投資信託を売却するイベントである。この運用口削除の申込は、任意の時期に行うことができる。この運用口削除のイベントでは、運用口削除の申込が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に運用口削除のレコード（削除対象の運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分等を含む）が作成され、その後、そのレコードの情報を用いて、申込日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（運用口削除なので、売注文である。）が記憶される。また、イベント反映手段２４により、その時点で注文データ作成待機中の別のイベントがある場合には、当該別のイベントを抹消扱いとするため、当該別のイベントについて注文管理記憶手段５２（図１０参照）に記憶されているレコードにおける抹消フラグを「抹消」にする。さらに、イベント反映手段２４により、運用口記憶手段４３（図３参照）の削除対象の運用口のレコードにおける運用口ステータスを「運用終了」に変更する。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている運用口削除のレコードにおける注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、削除対象の運用口で運用されている全銘柄の全数量を売却する注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
スタイル変更は、運用口に設定された運用スタイルを変更するサービスのイベントである。このスタイル変更の申込は、任意の時期に行うことができ、申込みの翌月から適用される。このスタイル変更のイベントでは、スタイル変更の申込が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）にスタイル変更のレコード（スタイル変更対象の運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、変更前および変更後の運用スタイルコード（運用スタイル識別情報）等を含む）が作成され、その後、そのレコードの情報を用いて、申込が行われた月の月末営業日の夜間バッチ処理で、イベント反映手段２４により、運用口銘柄構成記憶手段５９（図１４参照）にスタイル変更による銘柄構成の変更が反映されるとともに、注文管理記憶手段５２（図１０参照）に先ず売注文の注文日が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている売注文の注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている変更前後の運用スタイルコードを用いて売注文の注文データを作成し、注文データ作成日の翌営業日に、売注文の注文データを用いて注文する。続いて、全ての銘柄の売注文が約定したら、スタイル変更の売注文によるホールド期間が終了するので、その最遅約定日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に買注文の注文日が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている買注文の注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている変更前後の運用スタイルコードを用いて買注文の注文データを作成し、注文データ作成日の翌営業日に、買注文の注文データを用いて注文する。
投資対象銘柄変更は、運用口単位で、運用口を構成する資産クラス内の銘柄を変更するサービスのイベントである。運用スタイルと、資産クラスとの関係は、次の通りである。１つの運用口には、顧客が選択した１つの運用スタイルが設定されているが、その運用スタイルは、例えば、国内株式型の投資信託の資産クラスの配分比率が１０％、海外株式型の投資信託の資産クラスの配分比率が３０％、国内債券型の投資信託の資産クラスの配分比率が２０％、海外債券型の投資信託の資産クラスの配分比率が４０％等のように、複数の資産クラスにより構成されている。この運用スタイル内の設定構成比率は、図６に示すように、運用スタイルコードに紐付く資産クラスの配分比率として運用スタイル・資産クラス構成記憶手段４７に記憶されている。
また、資産クラスは、例えば、銘柄Ａの配分比率が５０％、銘柄Ｂの配分比率が５０％等のように、複数の銘柄により構成されている。この資産クラス内の設定構成比率は、図１４に示すように、対象銘柄の資産クラス内での配分比率として運用口銘柄構成記憶手段５９に記憶されている。従って、投資対象銘柄変更のイベントは、この資産クラス内の銘柄を変更するサービスであり、例えば、銘柄Ａ，Ｂ（銘柄Ａの配分比率５０％、銘柄Ｂの配分比率５０％）から、銘柄Ａ，Ｂ，Ｃ（銘柄Ａの配分比率４０％、銘柄Ｂの配分比率３０％、銘柄Ｃの配分比率３０％）への乗換等を行うことができ、この場合には、銘柄Ａ，Ｂを少しずつ売却して銘柄Ｃの買付を行うことになる。変更申込受付月の月末に売却注文を行い、売却注文の約定後に買付注文を行う。
この投資対象銘柄変更のイベントでは、投資対象銘柄変更の申込が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に投資対象銘柄変更のレコード（投資対象銘柄変更を行う運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、変更前および変更後の資産クラスコード等を含む）が作成され、その後、そのレコードの情報を用いて、申込が行われた月の月末営業日の夜間バッチ処理で、イベント反映手段２４により、運用口銘柄構成記憶手段５９（図１４参照）に投資対象銘柄変更による銘柄構成の変更が反映されるとともに、注文管理記憶手段５２（図１０参照）に先ず売注文の注文日が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている売注文の注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている変更前後の資産クラスコードを用いて売注文の注文データを作成し、注文データ作成日の翌営業日に、売注文の注文データを用いて注文する。続いて、全ての銘柄の売注文が約定したら、投資対象銘柄変更の売注文によるホールド期間が終了するので、その最遅約定日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に買注文の注文日が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている買注文の注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、イベント記憶手段４９（図７参照）に記憶されている変更前後の資産クラスコードを用いて買注文の注文データを作成し、注文データ作成日の翌営業日に、買注文の注文データを用いて注文する。
定期受取は、顧客が指定した月（定期受取月）に、投資信託を売却し、売却で得られた資金を顧客が受け取るイベントであり、より詳細には、この定期受取に関するイベントには、例えば、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、定期受取等の各イベントがある。ここでいう定期受取申込と、定期受取とは、発生時期および趣旨の異なるイベントであり、定期受取申込は、定期受取の内容を登録するための申込のイベントであるのに対し、定期受取は、登録情報に基づき定期受取を所定の時期（本実施形態では、定期受取月の前月の月末）に発生させるためのイベントであり、また、定期受取タイミング変更や、定期受取指定金額変更は、登録した内容を変更するイベントである。なお、本願の説明では、特にこれらを区別することなく、まとめて定期受取のイベント（広義）と呼ぶことがある。定期受取のイベント（狭義）は、本実施形態では、売注文を伴う月末イベントである。
定期受取申込のイベントでは、定期受取申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に定期受取申込のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、定期受取タイミング、定期受取指定金額等を含む：これらの定期受取タイミング、定期受取指定金額は、申込当初における初期設定の値であるが、変更前または変更後の値のカラムに代用記憶させてもよい）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に既に作成されている対象運用口のレコードに、定期受取の登録情報（定期受取タイミング、定期受取指定金額等）が記憶される。
定期受取のイベント（狭義）では、イベント準備手段２２により、運用口記憶手段４３（図３参照）に記憶されている定期受取の登録情報を用いて、所定の時期（少なくとも、運用口記憶手段４３（図３参照）に記憶されている定期受取タイミングで定まる定期受取月の前月の月末営業日またはそれよりも前の日）に、イベント記憶手段４９（図７参照）に定期受取のイベント（狭義）のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、定期受取判定年月日等を含む：本実施形態では、この定期受取判定年月日には、定期受取月の前月の月末営業日が設定される）が作成される。さらに、イベント記憶手段４９（図７参照）に記憶されている定期受取判定年月日の夜間バッチ処理で、イベント準備手段２２により、当月に定期受取を実施するか否かの判定処理（受取自体は、翌月となるので、当月にそのための注文データ作成処理を行うか否かの判定処理）が行われ、その定期受取判定結果が、イベント記憶手段４９（図７参照）に既に作成されている定期受取のレコードに記憶される。続いて、イベント記憶手段４９（図７参照）に記憶されている定期受取判定結果が、定期受取を実施する（当月に定期受取に伴う売却注文データを「作成する」）という結果である場合には、定期受取判定年月日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（定期受取なので、売注文である。）が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、運用口記憶手段４３（図３参照）またはイベント記憶手段４９（図７参照）に記憶されている定期受取指定金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
定期受取タイミング変更のイベントでは、定期受取タイミング変更の申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に定期受取タイミング変更のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、変更前および変更後の定期受取タイミング等を含む）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取タイミングについての変更処理が行われる。定期受取タイミングは、各運用口の定期受取タイミングが、例えば、毎月、隔月（奇数月）、隔月（偶数月）、３ヶ月毎、６ヶ月毎、１２ヶ月毎等であることを示す情報である。
定期受取指定金額変更のイベントでは、定期受取指定金額変更の申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に定期受取指定金額変更のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、変更前および変更後の定期受取指定金額等を含む）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取指定金額についての変更処理が行われる。
寄附は、投資信託を売却し、売却で得られた資金を、顧客により指定された寄附先へ寄付するイベントであり、より詳細には、この寄附に関するイベントには、例えば、寄附申込、寄附先変更、寄附金額変更、寄附等の各イベントがある。ここでいう寄附申込と、寄附とは、発生時期および趣旨の異なるイベントであり、寄附申込は、寄附の内容を登録するための申込のイベントであるのに対し、寄附は、登録情報に基づき寄附を所定の時期（本実施形態では、月末）に発生させるためのイベントであり、また、寄附先変更や、寄附金額変更は、登録した内容を変更するイベントである。なお、本願の説明では、特にこれらを区別することなく、まとめて寄附のイベント（広義）と呼ぶことがある。寄附のイベント（狭義）は、本実施形態では、売注文を伴う月末イベントである。
寄附申込のイベントでは、寄附申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に寄附申込のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、寄附先、寄附金額等を含む：これらの寄附先、寄附金額は、申込当初における初期設定の値であるが、変更前または変更後の値のカラムに代用記憶させてもよい）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に既に作成されている対象運用口のレコードに、寄附の登録情報（寄附先、寄附金額等）が記憶される。
寄附のイベント（狭義）では、イベント準備手段２２により、運用口記憶手段４３（図３参照）に記憶されている寄附の登録情報を用いて、所定の時期（少なくとも、寄附月の前月の月末営業日またはそれよりも前の日）に、イベント記憶手段４９（図７参照）に寄附のイベント（狭義）のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、寄附計算処理年月日等を含む：この寄附計算処理年月日には、本実施形態では、寄附月の前月の月末営業日が設定される）が作成される。続いて、イベント記憶手段４９（図７参照）に記憶されている寄附計算処理年月日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（寄附なので、売注文である。）が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、運用口記憶手段４３（図３参照）またはイベント記憶手段４９（図７参照）に記憶されている寄附金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
寄附先変更のイベントでは、寄附先変更の申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に寄附先変更のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、変更前および変更後の寄附先等を含む）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける寄附の登録情報のうちの寄附先についての変更処理が行われる。寄附先は、各運用口の寄附先（寄附のテーマ）が、例えば、食料支援、医療、環境、子供支援、災害復興等であることを示す情報である。
寄附金額変更のイベントでは、寄附金額変更の申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に寄附金額変更のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、変更前および変更後の寄附金額等を含む）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける寄附の登録情報のうちの寄附金額についての変更処理が行われる。
定期積立は、顧客が指定した月の指定した日に、定期的に投資信託の買付を行い、運用口単位での設定金額の増額を行うイベントであり、増額のイベントを定期的に繰り返すことに相当する。より詳細には、この定期積立に関するイベントには、例えば、定期積立申込、定期積立変更（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等の変更）、定期積立等の各イベントがある。ここでいう定期積立申込と、定期積立とは、発生時期および趣旨の異なるイベントであり、定期積立申込は、定期積立の内容を登録するための申込のイベントであるのに対し、定期積立は、登録情報に基づき定期積立を所定の時期（指定月の定期積立設定日の前営業日）に発生させるためのイベントであり、また、定期積立変更は、登録した内容（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等）を変更するイベントである。なお、本願の説明では、特にこれらを区別することなく、まとめて定期積立のイベント（広義）と呼ぶことがある。
定期積立申込のイベントでは、定期積立申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に定期積立申込のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等を含む：これらの定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額は、申込当初における初期設定の値であるが、変更前または変更後の値のカラムに代用記憶させてもよい）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に既に作成されている対象運用口のレコードに、定期積立の登録情報（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等）が記憶される。
定期積立のイベント（狭義）では、イベント準備手段２２により、運用口記憶手段４３（図３参照）に記憶されている定期積立の登録情報を用いて、所定の時期（少なくとも、指定月の定期積立設定日の前営業日またはそれよりも前の日）に、イベント記憶手段４９（図７参照）に定期積立のイベント（狭義）のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、定期積立設定日等を含む：この定期積立設定日は、定期積立変更のイベントではないが、変更前または変更後の定期積立設定日のカラムに代用記憶させてもよい）が作成される。続いて、イベント記憶手段４９（図７参照）に記憶されている定期積立設定日の前営業日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（定期積立なので、買注文である。）が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、運用口記憶手段４３（図３参照）またはイベント記憶手段４９（図７参照）に記憶されている毎月の定期積立金額やボーナス月の定期積立加算金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。
定期積立変更のイベントでは、定期積立変更の申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）に定期積立変更のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分等を含むとともに、変更する項目に応じ、変更前および変更後の定期積立タイミング、変更前および変更後の定期積立設定日、変更前および変更後の毎月の定期積立金額、あるいは、変更前および変更後のボーナス月の定期積立加算金額等を含む）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける定期積立の登録情報のうちの変更項目（定期積立タイミング、定期積立設定日、毎月の定期積立金額、あるいは、ボーナス月の定期積立加算金額等）についての変更処理が行われる。定期積立タイミングは、積立のための買付を毎月行うのか、あるいはそれ以外のパターン（例えば、隔月等）で行うのか等を示す情報である。定期積立設定日は、毎月（指定月）の投資信託の買付日である。定期積立金額は、毎月（指定月）の投資信託の買付金額であり、定期積立加算金額は、ボーナス月に毎月（指定月）の定期積立金額に加算する買付金額である。
リバランス判定基準乖離率変更は、リバランスで使用するリバランス判定基準乖離率を変更するイベントである。このリバランス判定基準乖離率変更の申込（申込時期は任意）が行われると、設定受付手段２１により、その申込が受け付けられてイベント記憶手段４９（図７参照）にリバランス判定基準乖離率変更のレコード（対象運用口についての運用口ファンドコード（運用口識別情報）、自動付与したイベント番号、イベント区分、変更前および変更後のリバランス判定基準乖離率等を含む）が作成され、その後、そのレコードの情報を用いて、イベント反映手段２４により、契約記憶手段４２（図３参照）に記憶されているリバランス判定基準乖離率（従って、リバランス判定基準乖離率は、本実施形態では、運用口単位ではないが、運用口単位としてもよい。）についての変更処理が行われる。
リバランスは、運用口を構成する投資信託の各銘柄によるポートフォリオ（各銘柄の構成比率）が、顧客との契約に基づく運用スタイルに沿った配分比率と乖離しているときに、そのときの乖離率が、リバランス判定基準乖離率の範囲内に収まっていない場合に、運用口を構成する投資信託の各銘柄の売買を行い、運用口のポートフォリオを、運用スタイルに沿った配分比率に修正するイベントである。すなわち、運用スタイルに沿った配分比率よりも構成比率（保有比率）が大きくなっている銘柄を売却し、その売却で得られた金額を用いて、運用スタイルに沿った配分比率よりも構成比率が小さくなっている銘柄を買い付けるイベントである。
リバランスのイベントでは、リバランス手段２３により、所定の時期（少なくとも、毎月の月末営業日またはそれよりも前の日）に、リバランス記憶手段５０（図８参照）にレコード（自動付与したリバランス番号（リバランスイベントの識別情報）、対象運用口についての運用口ファンドコード（運用口識別情報）、リバランス実施判定年月日等を含む：本実施形態では、このリバランス実施判定年月日には、月末営業日が設定される）が作成される。さらに、リバランス記憶手段５０（図８参照）に記憶されているリバランス実施判定年月日の夜間バッチ処理で、リバランス手段２３により、当月にリバランスを実施するか否かの判定処理が行われ、そのリバランス実施判定結果が、リバランス記憶手段５０（図８参照）に既に作成されているレコードに記憶される。続いて、リバランス記憶手段５０（図８参照）に記憶されているリバランス実施判定結果が、リバランス要という結果である場合には、リバランス実施判定年月日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に先ず売注文の注文日が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている売注文の注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、注文作成手段２５により、残高記憶手段６０（図１４参照）に記憶された運用口の各保有銘柄の残高数量についての売注文の注文データ作成タイミング判断時点での基準価額による評価金額、並びに、運用口銘柄構成記憶手段５９（図１４参照）および運用スタイル・資産クラス構成記憶手段４７（図６参照）に記憶されている設定構成比率を用いて、リバランスの売注文の注文データを作成し、注文データ作成日の翌営業日に、売注文の注文データを用いて注文する。続いて、全ての銘柄の売注文が約定したら、リバランスの売注文によるホールド期間が終了するので、その最遅約定日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に買注文の注文日が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている買注文の注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、注文作成手段２５により、残高記憶手段６０（図１４参照）に記憶された運用口の各保有銘柄の残高数量についての買注文の注文データ作成タイミング判断時点での基準価額による評価金額、並びに、運用口銘柄構成記憶手段５９（図１４参照）および運用スタイル・資産クラス構成記憶手段４７（図６参照）に記憶されている設定構成比率を用いて、リバランスの買注文の注文データを作成し、注文データ作成日の翌営業日に、買注文の注文データを用いて注文する。
四半期フィー徴収は、新規契約時や運用口追加時に徴収する契約時フィーとは別に、運用期間の経過に伴って四半期毎に徴収する四半期フィーを確保するために、投資信託の売却を行うイベントである。より一般には、区切りの期間長は、四半期に限らず、例えば半年等でもよいので、期間フィー徴収のイベントである。契約時フィーおよび四半期フィー（より一般には、期間フィー）は、いずれもファンドラップサービスを提供する証券会社等の金融機関が顧客から徴収するフィーであるが、契約時フィーの場合は、新規契約時や運用口追加時（増額時も同様）に顧客からの入金があるので、その一部をフィー徴収に当てるのに対し、四半期フィー（期間フィー）の場合は、入金があるわけではないので、顧客が保有している運用中の投資信託を売却してフィー徴収に当てる。四半期フィー徴収（期間フィー徴収）のイベントは、本実施形態では、売注文を伴う月末イベントである。
四半期フィー徴収のイベントでは、イベント準備手段２２により、所定の時期（少なくとも、四半期フィー徴収月の月末営業日またはそれよりも前の日）に、四半期フィー徴収記憶手段５１（図９参照）にレコード（自動付与した四半期フィー徴収番号（四半期フィー徴収イベントの識別情報）、対象運用口についての運用口ファンドコード（運用口識別情報）、四半期フィー計算処理年月日等を含む：本実施形態では、この四半期フィー計算処理年月日には、四半期フィー徴収月の月末営業日が設定される）が作成される。さらに、四半期フィー徴収記憶手段５１（図９参照）に記憶されている四半期フィー計算処理年月日の夜間バッチ処理で、手数料算出手段２７により、四半期フィーの算出処理が行われ、算出された四半期フィーの金額が、算出手数料記憶手段（不図示）に記憶される。続いて、四半期フィー計算処理年月日の夜間バッチ処理で、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に注文日（四半期フィー徴収なので、売注文である。）が記憶される。そして、注文作成手段２５により、注文管理記憶手段５２（図１０参照）に記憶されている注文日（海外休場日を考慮）を用いて、注文データ作成タイミング判断処理を行い、作成すると判断した日に、算出手数料記憶手段（不図示）に記憶されている四半期フィーの金額を用いて注文データを作成し、注文データ作成日の翌営業日に、その注文データを用いて注文する。なお、四半期フィーの金額は小さいので、運用スタイルに沿ったポートフォリオから最も大きく乖離している銘柄の売却だけでよい。
＜ファンドラップシステム１０の詳細構成＞
＜ファンドラップシステム１０／処理手段２０／設定受付手段２１の構成＞
設定受付手段２１は、顧客またはその入力代行者（証券会社等の金融機関の営業員やオペレータ等）により入力されて端末装置１００からネットワーク１を介して送信されてくる顧客の設定情報（各種イベントの申込を含む）を受け付け、記憶手段４０に登録する処理を実行するものである。
また、設定受付手段２１は、日中のオンライン入力で各種イベント（減額系イベント）の申込を受け付ける際に、前営業日の夜間バッチ処理で算出されて算出日付記憶手段６１（図１４参照）に記憶されている注文日、最遅約定日、および最遅受渡日を、端末装置１００に画面表示する処理を実行する。なお、これらの注文日、最遅約定日、および最遅受渡日は、詳細は後述するが、海外休場日を考慮した日付である。
具体的には、設定受付手段２１は、新規契約の申込を受け付けた場合には、受け付けた情報をイベント記憶手段４９（図７参照）に記憶させる（レコードの作成を含む）とともに、新規契約に伴う各種の設定情報を、主口座記憶手段４１、契約記憶手段４２、運用口記憶手段４３（図３参照）に記憶させる（レコードの作成を含む）。より詳細には、設定受付手段２１は、例えば、自動付与した口座ファンドコード、ログイン時に入力された顧客の口座番号（顧客識別情報）を、主口座記憶手段４１（図３参照）に記憶させる（レコードの作成を含む）。また、設定受付手段２１は、例えば、自動付与した契約ファンドコード、顧客の口座番号、顧客が選択したサービスについてのサービス種類区分、新規契約年月日、新規契約金額（新規契約時における各運用口の設定金額の合計金額）、契約ファンドコードに紐付く口座ファンドコード、リバランス判定基準乖離率（リバランス判定の基準となる乖離率：％単位）等を、契約記憶手段４２（図３参照）に記憶させる（レコードの作成を含む）。
さらに、設定受付手段２１は、例えば、自動付与した運用口ファンドコード（運用口識別情報）、顧客の口座番号、サービス種類区分、自動付与した運用口１，２，…を識別するための連続番号である運用口番号、顧客が命名した運用口の愛称等を示すテキストデータである運用口名称、顧客が選択した運用スタイル区分、顧客が選択した運用スタイル（安定型、やや安定型、バランス型、やや積極型、積極型、…等のうちのいずれか）を識別するための運用スタイルコード（運用スタイル識別情報）、運用口ステータス、運用口単位の設定金額（運用口で運用する金額：各時点での金額であり、更新される金額）、運用口ファンドコードに紐付く契約ファンドコード、当初設定金額（新規契約時または運用口追加時の設定金額）等を、運用口記憶手段４３（図３参照）に記憶させる（レコードの作成を含む）。複数の運用口を設定する場合には、運用口記憶手段４３（図３参照）へのレコード作成は、運用口毎に行われる。
なお、新規契約時ではなく、運用開始後に運用口追加の申込を受け付けた場合にも、設定受付手段２１は、受け付けた情報をイベント記憶手段４９（図７参照）に記憶させる（レコードの作成を含む）とともに、追加した運用口についての上記の各種の設定情報を、運用口記憶手段４３（図３参照）に記憶させる（レコードの作成を含む）。従って、運用口追加を行った場合には、追加した運用口の個数分だけ、運用口記憶手段４３（図３参照）のレコードが追加される。
また、設定受付手段２１は、新規契約や運用口追加の申込を受け付けるだけではなく、増額、減額、運用口削除、スタイル変更、投資対象銘柄変更、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、寄附申込、寄附先変更、寄附金額変更、定期積立申込、定期積立変更（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等の変更）、リバランス判定基準乖離率変更（本実施形態では、リバランス判定基準乖離率は、運用口単位の設定ではない）等の各種イベントの申込を受け付け、受け付けたイベントのレコードをイベント記憶手段４９（図７参照）に作成し、当該イベントに対して付与したイベント番号、イベント区分、イベントステータス（申請中、成立、不成立、取消済、…）、運用口ファンドコード（運用口識別情報）、顧客の口座番号（顧客識別情報）、契約ファンドコード、運用開始日、イベントに関する各種金額（新規契約時や運用口追加時の運用口単位の設定金額、運用口単位の増額金額、運用口単位の減額金額等）、変更前後の内容（金額、タイミング、コード、乖離率、日付等の変更内容）等を記憶させる。
設定受付手段２１により各種イベントの申込の受付処理を行ってイベント記憶手段４９（図７参照）に記憶された情報は、イベント反映手段２４によりバッチ処理（本実施形態では、夜間に実行する夜間バッチ処理）で反映される情報が多いが、本実施形態では、前述したように、主口座記憶手段４１および契約記憶手段４２（図３参照）へのレコード作成、並びに、新規契約時および運用口追加時の運用口記憶手段４３（図３参照）へのレコード作成については、イベント反映手段２４ではなく、設定受付手段２１により実行するものとしている。なお、運用口記憶手段４３（図３参照）に既に作成されている対象運用口のレコードへの各種設定情報の登録処理については、設定受付手段２１ではなく、イベント反映手段２４により実行するものとするので、例えば、定期受取申込のイベントにおいて運用口記憶手段４３（図３参照）のレコードに定期受取の登録情報（定期受取タイミング、定期受取指定金額等）を記憶させる処理、寄附申込のイベントにおいて運用口記憶手段４３（図３参照）のレコードに寄附の登録情報（寄附先、寄附金額等）を記憶させる処理、定期積立申込のイベントにおいて運用口記憶手段４３（図３参照）のレコードに定期積立の登録情報（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等）を記憶させる処理は、イベント反映手段２４により実行する。
また、設定受付手段２１は、前述したように、定期受取申込、寄附申込、定期積立申込のイベントについての申込を受け付け、これらのイベントのレコードを作成してイベント記憶手段４９（図７参照）に記憶させるが、定期受取（狭義）、寄附（狭義）、定期積立（狭義）のイベントについては、既に詳述したように、顧客またはその入力代行者からのオンライン入力での申込を受け付けるのではなく、所定の時期（月末またはその前）が到来したときに、既に登録されている情報に基づきイベントの準備処理を行うので、設定受付手段２１ではなく、イベント準備手段２２により、これらのイベントのレコードを作成してイベント記憶手段４９（図７参照）に記憶させる。また、四半期フィー徴収（より一般には、期間フィー徴収）のイベントについても、顧客またはその入力代行者からのオンライン入力での申込を受け付けるのではなく、所定のフィー徴収時期が到来したときにイベントの準備処理を行うので、同様であり、設定受付手段２１ではなく、イベント準備手段２２により、イベント記憶手段４９（図７参照）へのレコード作成を行う。
さらに、運用口記憶手段４３（図３参照）には、運用口における月末ホールド期間の設定情報（期間の設定年月日等）が記憶されるが、この月末ホールド期間は、特定のイベントに基づき設定される期間ではないため、月末が近づいた際に、設定受付手段２１が設定する。また、運用口記憶手段４３（図３参照）には、運用口について注文データの作成を行うことができない期間である約定ベースホールド期間の設定情報（期間の終了年月日等）が記憶されるが、この約定ベースホールド期間は、注文データの作成が行われた際に、その注文が約定するまで（複数の注文データの作成が行われた場合には、それらの注文が全て約定するまで）、別の注文データの作成を制限する期間であるため、注文作成手段２５が設定する。
図２に示すように、設定受付手段２１により自動付与される口座ファンドコード、契約ファンドコード、運用口ファンドコードは、互いに紐付けられ、この順で上位層から下位層へと向かう階層構造を形成する。但し、口座ファンドコード、契約ファンドコード、運用口ファンドコードは、互いに重ならないように、３つのコードを合わせた状態で連続番号となるように自動付与される。なお、これらのコードは、実際には、例えば１０桁程度のコードであるが、以下では、説明の便宜上、３桁で説明する。
具体的には、例えば、顧客である大和太郎が、ファンドラップサービスについて新規契約をし、幾つか用意されたファンドラップサービスのうちの「ファンドラッププレミアム」というサービスを選択し、２つの運用口１，２を設定し、運用口１については、運用スタイルＡを選択し、運用口２については、運用スタイルＢを選択したとする。このとき、設定受付手段２１は、口座ファンドコード＝００１を自動付与し、大和太郎の主口座の口座番号（例えば、証券会社に開設された証券総合口座の口座番号）とともに、主口座記憶手段４１（図３参照）に記憶させる。また、契約ファンドコード＝００２を自動付与し、既に自動付与した口座ファンドコード＝００１とともに、契約記憶手段４２（図３参照）に記憶させる。さらに、運用スタイルＡを選択した運用口１に対し、運用口ファンドコード＝００３を自動付与し、運用スタイルＢを選択した運用口２に対し、運用口ファンドコード＝００４を自動付与し、既に自動付与した契約ファンドコード＝００２とともに、運用口記憶手段４３（図３参照）に記憶させる。
続いて、例えば、別の顧客である大和花子が、ファンドラップサービスについて新規契約をし、幾つか用意されたファンドラップサービスのうちの「ファンドラッププレミアム」というサービスを選択し、２つの運用口１，２を設定し、運用口１については、運用スタイルＣを選択し、運用口２については、運用スタイルＤを選択したとする。このとき、設定受付手段２１は、口座ファンドコード＝００５を自動付与し、大和花子の主口座の口座番号とともに、主口座記憶手段４１（図３参照）に記憶させる。また、契約ファンドコード＝００６を自動付与し、既に自動付与した口座ファンドコード＝００５とともに、契約記憶手段４２（図３参照）に記憶させる。さらに、運用スタイルＣを選択した運用口１に対し、運用口ファンドコード＝００７を自動付与し、運用スタイルＤを選択した運用口２に対し、運用口ファンドコード＝００８を自動付与し、既に自動付与した契約ファンドコード＝００６とともに、運用口記憶手段４３（図３参照）に記憶させる。
その後、最初の顧客である大和太郎が、幾つか用意されたファンドラップサービスのうちの別のサービスである「ファンドラップオンライン」というサービスを選択し、運用口１を設定し、運用スタイルＥを選択したとする。このとき、設定受付手段２１は、契約ファンドコード＝００９を自動付与し、既に自動付与した口座ファンドコード＝００１とともに、契約記憶手段４２（図３参照）に記憶させる。さらに、運用スタイルＥを選択した運用口１に対し、運用口ファンドコード＝０１０を自動付与し、既に自動付与した契約ファンドコード＝００９とともに、運用口記憶手段４３（図３参照）に記憶させる。なお、ファンドラップサービスには、幾つかの種類があり、例えば、「ファンドラッププレミアム」サービス（サービス種類区分＝０１）は、契約金額が大きく（例えば３，０００万円以上１万円単位）、運用口を最大５つまで設定することができ、「ファンドラップオンライン」サービス（サービス種類区分＝０２）は、契約金額が小さく（１万円以上１円単位）、運用口は１つしか設定できない等の相違がある。但し、これらは、一例であり、例えば、運用口の最大設定数は５つに限らず、それ以上またはそれ以下の個数としてもよく、全てのファンドラップサービスについて、複数の運用口を設定できるようにしてもよく、契約金額の大小も任意である。大和太郎という１人の顧客が、複数種類のファンドラップサービスを同時期に利用することは、稀ではあるが、現実に存在するケースである。
さらに、その後に、最初の顧客である大和太郎が、既に契約している「ファンドラッププレミアム」サービスについて、運用口３を追加して設定し、運用口３について、運用スタイルＦを選択したとする。このとき、設定受付手段２１は、運用スタイルＦを選択した運用口３に対し、運用口ファンドコード＝０１１を自動付与し、既に自動付与した契約ファンドコード＝００２とともに、運用口記憶手段４３（図３参照）に記憶させる。
従って、運用口ファンドコードは、全ての顧客の全ての契約の全ての運用口に対し、重ならないように自動付与されているので、運用口識別情報として機能する。また、口座ファンドコード、契約ファンドコード、運用口ファンドコードは、階層化されているので、運用口記憶手段４３、契約記憶手段４２、主口座記憶手段４１という順で、運用口ファンドコードから契約ファンドコードを辿り、契約ファンドコードから口座ファンドコードを辿り、口座ファンドコードから主口座の口座番号（顧客識別情報）を辿ることができるので、これらの３つのファンドコードは、３つ合わせて顧客識別情報として機能するといえるか、あるいは、３つ合わせて顧客識別情報を特定することができる識別情報であるといえる。従って、本発明（請求項）における「顧客識別情報に関連付けて記憶する」という記載については、これらの３つのファンドコードから顧客識別情報に辿り着くことができるように記憶されているという意味を含んでいるため、必ずしも同じレコード内に、顧客識別情報（本実施形態では、主口座の口座番号）自体が存在することを意味しない。このため、あるレコードに、運用口ファンドコードが記憶されていれば、それは運用口識別情報として機能し、かつ、その運用口ファンドコードは、別のレコードに記憶されている顧客識別情報（本実施形態では、主口座の口座番号）を特定するための識別情報としても機能することになり、この状態をもって、本発明（請求項）において「顧客識別情報および運用口識別情報に関連付けて記憶する」という記載となっている。
また、設定受付手段２１は、証券会社等の金融機関のシステム担当者により入力されて端末装置１１０から通信回線５またはネットワーク１を介して送信されてくるシステム設定情報を受け付け、記憶手段４０に登録する処理も実行する。
具体的には、設定受付手段２１は、運用スタイルに関する設定情報として、例えば、サービス種類区分（「ファンドラッププレミアム」サービス＝０１、「ファンドラップオンライン」サービス＝０２、…）、運用スタイル区分（共通スタイル＝１、個別スタイル（１）＝２、個別スタイル（２）＝３、…）、運用スタイルコード（運用スタイル識別情報）、当該運用スタイルに対してシステム担当者が命名したテキストデータである運用スタイル名称（安定型、やや安定型、バランス型、やや積極型、積極型、…）、当該運用スタイルに適用される手数料率を識別するための手数料コード（手数料率識別情報）等を、運用スタイル記憶手段４６（図６参照）に記憶させる（レコードの作成を含む）。
なお、運用スタイル区分は、全ての顧客に適用可能なデフォルトの共通スタイル（運用スタイル区分＝１）と、特定の顧客に適用する個別スタイル（１），（２）…（運用スタイル区分＝２，３，…）とがあるが、特にこのような区分を設けなくてもよい。また、運用スタイルには、例えば、安定型、やや安定型、バランス型、やや積極型、積極型等の各種名称の運用スタイルがあり、実際には、非常に多数（例えば、４００個程度）の運用スタイルが用意されているが、システムとして用意する運用スタイルの個数は任意であり、顧客は、運用口毎に異なる運用スタイルを選択するので、少なくとも顧客１人当たりの運用口の最大設定数（例えば５つ）と同数の運用スタイルが用意されていればよい。
また、設定受付手段２１は、運用スタイルと資産クラスとの関係を示す設定情報として、例えば、運用スタイルコード（運用スタイル識別情報）と、資産クラスコード（資産クラス識別情報）と、設定構成比率（運用スタイルコードに紐付く資産クラスの配分比率：％単位）とを関連付けて、運用スタイル・資産クラス構成記憶手段４７（図６参照）に記憶させる（レコードの作成を含む）。
さらに、設定受付手段２１は、資産クラスに関する設定情報として、例えば、資産クラスコード（資産クラス識別情報）と、資産クラスを構成する投資信託の銘柄コード（銘柄識別情報）とを関連付けて、資産クラス銘柄構成記憶手段４８（図６参照）に記憶させる（レコードの作成を含む）。
また、設定受付手段２１は、手数料率に関する設定情報として、例えば、手数料コード（手数料率識別情報）と、手数料率（投資顧問料率、取引等管理手数料率）とを関連付けて、手数料率記憶手段（不図示）に記憶させる（レコードの作成を含む）。
＜ファンドラップシステム１０／処理手段２０／イベント準備手段２２の構成＞
イベント準備手段２２は、イベント毎の所定の時期が到来したときに、既に登録されている情報に基づき、各イベントのレコードを作成してイベント記憶手段４９（図７参照）に記憶させるイベント準備処理を実行するものである。前述した設定受付手段２１が、顧客またはその入力代行者からのオンライン入力での申込を受け付けて処理を実行するのに対し、このイベント準備手段２２は、申込に基づくのではなく、登録情報に基づき所定の時期の到来をシステムで判断して処理を実行する点が異なっている。
具体的には、イベント準備手段２２は、定期受取（狭義）、寄附（狭義）、定期積立（狭義）、四半期フィー徴収のイベントについてのレコードを作成してイベント記憶手段４９（図７参照）に記憶させる。このうち、定期受取（狭義）、寄附（狭義）、四半期フィー徴収は、売注文を伴う月末イベント（本実施形態では、月末に処理を実行するイベント）であり、定期積立（狭義）は、買注文を伴うイベントである。イベント記憶手段４９（図７参照）に作成した各イベントのレコードに記憶させる情報は、イベント毎に異なるが、各イベントの内容説明で既に述べているため、ここでは個々のイベント毎の説明は省略する。
なお、既に詳述したように、定期受取（狭義）、寄附（狭義）、定期積立（狭義）のイベントは、設定受付手段２１により申込を受け付ける定期受取申込、寄附申込、定期積立申込のイベントとは発生時期および趣旨の異なるイベントである。
また、イベント準備手段２２は、定期受取（狭義）のイベントでは、イベント記憶手段４９（図７参照）に記憶されている定期受取のレコードにおける定期受取判定年月日になったか否かを判断し、定期受取判定年月日になったと判断した場合にその日の夜間バッチ処理で、当月に定期受取を実施するか否かの判定処理（受取自体は、翌月となるので、当月にそのための注文データ作成処理を行うか否かの判定処理）を実行し、その定期受取判定結果を、イベント記憶手段４９（図７参照）に既に作成されている定期受取のレコードに記憶させる処理を実行する。
この際、定期受取判定年月日は、イベント準備手段２２により、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取タイミング（例えば、毎月、隔月（奇数月）、隔月（偶数月）、３ヶ月毎、６ヶ月毎、１２ヶ月毎等の別を示す情報）を参照して決定し、イベント記憶手段４９（図７参照）の定期受取のレコードに記憶させた情報である。また、イベント準備手段２２による当月に定期受取を実施するか否かの判定処理は、残高記憶手段６０（図１４参照）に記憶された保有資産の状況（運用状況）や、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取指定金額等を用いて実行される。
＜ファンドラップシステム１０／処理手段２０／リバランス手段２３の構成＞
リバランス手段２３は、所定の時期（少なくとも、毎月の月末営業日またはそれよりも前の日）に、リバランス記憶手段５０（図８参照）に各運用口のリバランスイベントのレコードを作成するリバランスイベント準備処理を実行するものである。このレコードには、自動付与したリバランス番号（リバランスイベントの識別情報）、対象運用口についての運用口ファンドコード（運用口識別情報）、リバランス実施判定年月日等を記憶させる。本実施形態では、リバランス実施判定年月日には、月末営業日を設定する。
また、リバランス手段２３は、リバランス記憶手段５０（図８参照）に記憶されているリバランス実施判定年月日になったか否かを判断し、リバランス実施判定年月日になったと判断した場合にその日の夜間バッチ処理で、当月にリバランスを実施するか否かのリバランス判定処理を実行し、そのリバランス実施判定結果（要・不要の別）を、リバランス記憶手段５０（図８参照）に既に作成されているレコードに記憶する処理を実行する。
この際、リバランス手段２３によるリバランス判定処理では、運用口を構成する投資信託の各銘柄による運用中のポートフォリオ（各銘柄の構成比率）と、顧客との契約に基づく運用スタイルに沿った目標（所望）のポートフォリオにおける各銘柄の配分比率との乖離率のうち、乖離率が最も大きい銘柄の乖離率が、契約記憶手段４２（図３参照）に記憶されているリバランス判定基準乖離率の範囲内に収まっているか否かを判断し、収まっていない場合には、リバランス要と判定し、収まっている場合には、リバランス不要と判定する。
ここで、前者の運用中のポートフォリオ（各銘柄の構成比率）は、残高記憶手段６０（図１４参照）に記憶されている各銘柄の残高数量（保有口数）と、単価情報記憶手段４５（図５参照）に記憶されている各銘柄の最新の基準価額とを乗じることにより得られた各銘柄の評価金額を用いて算出するか、または、各銘柄の評価金額が残高記憶手段６０（図１４参照）に記憶されている場合には、それらの評価金額を用いて算出する。
また、後者の顧客との契約に基づく運用スタイルに沿った目標（所望）のポートフォリオにおける各銘柄の配分比率は、運用スタイル・資産クラス構成記憶手段４７（図６参照）に記憶されている運用スタイル内の設定構成比率（運用スタイルコードに紐付く資産クラスの配分比率）と、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている資産クラス内の設定構成比率（各銘柄の資産クラス内での配分比率）とを乗じて算出する。
なお、従来システムでは、リバランス実施判定年月日にリバランス要と判定されたら、その日に、リバランスのための注文データを作成していたので、リバランス判定処理で使用した各銘柄の評価金額と、注文データを作成する際に使用する各銘柄の評価金額とは一致していたが、本発明では、リバランス実施判定年月日が、注文データ作成日になるとは限らないので、リバランス手段２３によるリバランス判定処理で使用した各銘柄の評価金額と、注文作成手段２５により注文データを作成する際に使用する各銘柄の評価金額とが一致するとは限らない。
＜ファンドラップシステム１０／処理手段２０／イベント反映手段２４の構成＞
イベント反映手段２４は、売買注文の作成を要するイベントが発生した場合に、当該イベントの発生時点で算出日付記憶手段６１（図１４参照）に記憶されている注文日、最遅約定日、および最遅受渡日、並びに、売買ステータス（注文データ作成の状態：最初は、売却または買付のいずれかの注文データの作成が必要な状態とする）を、当該イベントについてのイベント番号（注文データ作成対象となるイベントの識別情報）、対象運用口についての運用口ファンドコード（運用口識別情報）と関連付けて、注文管理記憶手段５２（図１０参照）に記憶させる注文管理処理を実行するものである。
この際、売買注文の作成を要するイベントが発生した場合というのは、イベントにおいて注文を行うこと（注文データを作成すること）が決定した場合のことであり、これが、イベント反映手段２４による注文管理処理の実行の条件となる。従って、定期受取のイベント（狭義）の場合には、イベント準備手段２２によりイベント記憶手段４９（図７参照）に定期受取のイベント（狭義）のレコードを作成しただけの段階や、イベント準備手段２２により当月に定期受取を実施するか否かの判定処理を実行し、その定期受取判定結果が、売却注文データを作成しないという結果となった場合は、ここでいうイベントが発生（成立）したことにはならず、定期受取判定結果が、売却注文データを作成するという結果となることを条件として、ここでいうイベントが発生（成立）したことになる。また、リバランスイベントの場合には、リバランス手段２３によりリバランス記憶手段５０（図８参照）にリバランスイベントのレコードを作成しただけの段階や、リバランス手段２３によりリバランス判定処理を実行し、そのリバランス実施判定結果が、リバランス不要となった場合は、ここでいうイベントが発生（成立）したことにはならず、リバランス実施判定結果が、リバランス要となることを条件として、ここでいうイベントが発生（成立）したことになる。
イベント反映手段２４による注文管理処理で、注文管理記憶手段５２（図１０参照）に記憶させる注文日、最遅約定日、および最遅受渡日は、算出日付記憶手段６１（図１４参照）に記憶されている情報であるが、これらは、日付算出手段２６により前営業日に算出された日付である。
このうち、注文日は、銘柄単位算出日付記憶手段６１Ａ（図１４参照）に記憶されている日付であるが、この日付は、注文可否日記憶手段５７（図１４参照）に記憶されている情報（海外休場日を考慮した、注文が可能か否かの情報）を用いて、運用口を構成する全銘柄が注文可能な日として決定された日付である。
また、最遅約定日および最遅受渡日は、運用口単位算出日付記憶手段６１Ｃ（図１４参照）に記憶されている運用口全体の最遅約定日および最遅受渡日を示す日付であるが、これらの日付は、約定・受渡日数記憶手段５８（図１４参照）に記憶されている情報（各銘柄についての注文日から約定日や受渡日までの日数）を用いて決定された日付である。なお、投資対象銘柄変更のイベントは、資産クラス内の銘柄を変更するサービスであるが、変更対象となる資産クラス内の銘柄の売買だけを行う場合には、資産クラス単位算出日付記憶手段６１Ｂ（図１４参照）に記憶されている資産クラス内の最遅約定日および最遅受渡日を、注文管理記憶手段５２（図１０参照）に記憶させる最遅約定日および最遅受渡日としてもよく、変更対象となる資産クラス内の銘柄を含めて運用口全体の構成銘柄で目標のポートフォリオにするための売買を行う場合には、運用口単位算出日付記憶手段６１Ｃ（図１４参照）に記憶されている運用口全体の最遅約定日および最遅受渡日を、注文管理記憶手段５２（図１０参照）に記憶させる最遅約定日および最遅受渡日とすればよい。
また、イベント反映手段２４は、増額のイベントでは、運用口記憶手段４３（図３参照）の増額対象の運用口のレコードにおける設定金額を、増額金額の分だけ増額させる更新処理を実行する。さらに、減額のイベントでは、運用口記憶手段４３（図３参照）の減額対象の運用口のレコードにおける設定金額を、減額金額の分だけ減額させる更新処理を実行する。
また、イベント反映手段２４は、運用口削除のイベントでは、運用口削除の申込が行われた時点で注文データ作成待機中の別のイベントがある場合には、当該別のイベントを抹消扱いとするため、当該別のイベントについて注文管理記憶手段５２（図１０参照）に記憶されているレコードにおける抹消フラグを「抹消」にするイベント抹消処理を実行する。さらに、イベント反映手段２４は、運用口記憶手段４３（図３参照）の削除対象の運用口のレコードにおける運用口ステータスを「運用終了」に変更する処理を実行する。
さらに、イベント反映手段２４は、スタイル変更や投資対象銘柄変更のイベントでは、運用口銘柄構成記憶手段５９（図１４参照）にスタイル変更や投資対象銘柄変更による銘柄構成の変更を反映させる銘柄変更処理を実行する。この際、スタイル変更のイベントでは、イベント記憶手段４９（図７参照）に変更前および変更後の運用スタイルコード（運用スタイル識別情報）が記憶されているので、運用スタイル・資産クラス構成記憶手段４７および資産クラス銘柄構成記憶手段４８（図６参照）に記憶された情報を用いて変更前後の銘柄を特定する。投資対象銘柄変更のイベントでは、イベント記憶手段４９（図７参照）に変更前および変更後の資産クラスコード（資産クラス識別情報）が記憶されているので、資産クラス銘柄構成記憶手段４８（図６参照）に記憶された情報を用いて変更前後の銘柄を特定する。そして、イベント反映手段２４は、スタイル変更のイベントでは、運用口記憶手段４３（図３参照）に記憶されている運用スタイルコード（運用スタイル識別情報）を変更後の状態にする処理を実行し、投資対象銘柄変更のイベントでも、資産クラスコード（資産クラス識別情報）の変更によりその資産クラスを含む運用スタイルについての運用スタイルコード（運用スタイル識別情報）の変更があるので、運用口記憶手段４３（図３参照）に記憶されている運用スタイルコード（運用スタイル識別情報）を変更後の状態にする処理を実行する。
また、イベント反映手段２４は、定期受取申込のイベントでは、イベント記憶手段４９（図７参照）に記憶されている定期受取申込のレコードの情報を用いて、運用口記憶手段４３（図３参照）に既に作成されている対象運用口のレコードに、定期受取の登録情報（定期受取タイミング、定期受取指定金額等）を記憶させる設定登録処理を実行する。さらに、イベント反映手段２４は、定期受取タイミング変更や定期受取指定金額変更のイベントでは、イベント記憶手段４９（図７参照）に記憶されている定期受取タイミング変更や定期受取指定金額変更のレコードの情報を用いて、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける定期受取の登録情報のうちの定期受取タイミングや定期受取指定金額についての変更処理を実行する。
同様に、イベント反映手段２４は、寄附申込のイベントでは、イベント記憶手段４９（図７参照）に記憶されている寄附申込のレコードの情報を用いて、運用口記憶手段４３（図３参照）に既に作成されている対象運用口のレコードに、寄附の登録情報（寄附先、寄附金額等）を記憶させる設定登録処理を実行する。さらに、イベント反映手段２４は、寄附先変更や寄附金額変更のイベントでは、イベント記憶手段４９（図７参照）に記憶されている寄附先変更や寄附金額変更のレコードの情報を用いて、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける寄附の登録情報のうちの寄附先や寄附金額についての変更処理を実行する。
また、イベント反映手段２４は、定期積立申込のイベントでは、イベント記憶手段４９（図７参照）に記憶されている定期積立申込のレコードの情報を用いて、運用口記憶手段４３（図３参照）に既に作成されている対象運用口のレコードに、定期積立の登録情報（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等）を記憶させる設定登録処理を実行する。さらに、イベント反映手段２４は、定期積立変更のイベントでは、イベント記憶手段４９（図７参照）に記憶されている定期積立変更のレコードの情報を用いて、運用口記憶手段４３（図３参照）に記憶されている対象運用口のレコードにおける定期積立の登録情報のうちの定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等についての変更処理を実行する。
さらに、イベント反映手段２４は、リバランス判定基準乖離率変更のイベントでは、イベント記憶手段４９（図７参照）に記憶されているリバランス判定基準乖離率変更のレコードの情報を用いて、契約記憶手段４２（図３参照）に記憶されているリバランス判定基準乖離率についての変更処理を実行する。
また、イベント反映手段２４は、定期受取（狭義）や寄附（狭義）のイベントでは、定期受取明細や寄附明細を作成し、定期受取明細記憶手段５５（図１２参照）や寄附明細記憶手段（不図示）に記憶させる月末イベント明細作成処理を実行する。
＜ファンドラップシステム１０／処理手段２０／注文作成手段２５の構成＞
注文作成手段２５は、注文管理記憶手段５２（図１０参照）に作成された各種イベントのレコードに記憶されている売買ステータス（注文データ作成の状態）が、「売却の注文データの作成が必要な状態」または「買付の注文データの作成が必要な状態」となっているレコードについて、そのレコードに記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件（本実施形態では、判断時点の日の翌営業日が、注文日に該当するという注文作成条件）を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、イベント発生以降の毎営業日に実行するものである。ここで、イベント発生以降の毎営業日というのは、イベント反映手段２４による注文管理処理が実行されて注文管理記憶手段５２（図１０参照）に注文日が記憶された日以降、注文管理記憶手段５２（図１０参照）の売買ステータスが「注文データ作成済の状態」になるまでである。
また、注文作成手段２５は、注文データを作成すると判断した場合に、当該判断時点で算出日付記憶手段６１（図１４参照）に記憶されている注文日、約定日、および受渡日を用いて、これらの日付および注文データの内容を含む注文明細を作成し、作成した注文明細を、顧客の口座番号（顧客識別情報）および運用口ファンドコード（運用口識別情報）と関連付けて注文明細記憶手段５３（図１１参照）に記憶させる注文明細作成処理を実行する。
さらに、注文作成手段２５は、上記の注文明細作成処理と併せて、データ連携用の注文データ（注文のために翌営業日に売買システム７０へ送信する注文データ）を作成し、注文データ記憶手段５４（図１１参照）に記憶させる処理を実行する。
そして、注文作成手段２５は、注文明細作成処理や、データ連携用の注文データ作成処理を行った後、注文管理記憶手段５２（図１０参照）の売買ステータスを、注文データ作成済の状態に変更する。
注文作成手段２５による注文データの作成の際には、原則的に、注文の約定後におけるポートフォリオ（各銘柄の構成比率）の状態が、顧客との契約に基づく運用スタイルに沿った目標のポートフォリオ（各銘柄の配分比率）になるように、各銘柄の売買金額または売買数量（口数）を決定する。但し、四半期フィー徴収のイベントでは、フィー徴収に当てる売却金額が小さいため、運用スタイルに沿った目標のポートフォリオから最も大きく乖離している銘柄の売却だけでよい。個々のイベントにおける注文データの作成は、以下の通りである。
新規契約のイベントでは、注文作成手段２５は、各運用口の設定金額（但し、契約時フィーの徴収分を指し引いた金額）が、運用口追加のイベントでは、追加する運用口の設定金額（但し、契約時フィーの徴収分を指し引いた金額）が、それぞれ運用口全体の買付金額となるので、その買付金額を、各運用口の運用スタイルに沿った目標（所望）のポートフォリオの各銘柄の配分比率に配分して各銘柄の買付金額を算出決定し、各銘柄の買注文の注文データを作成する。
ここで、目標（所望）のポートフォリオの各銘柄の配分比率は、運用スタイル・資産クラス構成記憶手段４７（図６参照）に記憶されている運用スタイル内の設定構成比率（運用スタイルコードに紐付く資産クラスの配分比率）と、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている資産クラス内の設定構成比率（各銘柄の資産クラス内での配分比率）とを乗じて算出する。
増額のイベントでは、注文作成手段２５は、既に保有銘柄で構成されている運用中のポートフォリオがあるので、その時点（注文データ作成時点）における各保有銘柄の評価金額の合計金額に、増額金額（但し、増額時にも、契約時フィーを徴収する場合には、その徴収分を指し引いた金額）を加えた金額を、目標（所望）のポートフォリオになるように配分し、得られた各銘柄への配分金額から、その時点（注文データ作成時点）における各保有銘柄の評価金額を差し引くことにより各銘柄の買付金額を算出決定し、各銘柄の買注文の注文データを作成する。
この際、運用中のポートフォリオの注文データ作成時点での各銘柄の評価金額は、残高記憶手段６０（図１４参照）に記憶されている各銘柄の残高数量（保有口数）と、単価情報記憶手段４５（図５参照）に記憶されている各銘柄の最新の基準価額とを乗じることにより算出するか、または、基準価額の更新の際に各銘柄の評価金額が算出されて残高記憶手段６０（図１４参照）に記憶されている場合には、それらの評価金額を用いる。
図１５には、増額時の注文データ作成の具体例が示されている。３月１４日〜３月１６日が海外休場日となる銘柄（銘柄Ａ，Ｂ，Ｃ，Ｄのうちの少なくとも１つの銘柄）を保有し、その状態で運用開始日が３月１４日（入金日：３月１３日）の増額（１，０００，０００円）を行った場合の例である。各銘柄Ａ，Ｂ，Ｃ，Ｄの目標保有比率は、それぞれ２５％とする。また、各銘柄Ａ，Ｂ，Ｃ，Ｄの約定日は、注文日の翌営業日とする。
従来システムでは、３月１４日（火）を運用開始日として指定して増額の申込を行うと、指定された運用開始日が注文予定日となり、その運用開始日が注文できる日であるか否かにかかわらず、その運用開始日の前営業日である３月１３日（月）に注文データを作成していた。そして、注文データ作成日の翌営業日（指定された運用開始日）に注文を行うが、翌営業日が海外休場日に該当する銘柄を有している等の理由により、翌営業日に注文できない場合があった。すなわち、注文予定日が、実際の注文日にならない場合があった。図１５の例では、３月１４日（火）〜３月１６日（木）が海外休場日となる銘柄を保有しているので、実際の注文日は、３月１７日（金）となるため、注文データ作成日である３月１３日（月）と、実際の注文日である３月１７日（金）とが離れてしまう状態となっていた。そして、この間、運用口のポートフォリオを構成する各銘柄Ａ，Ｂ，Ｃ，Ｄの評価金額は、基準価額の変動により変化している（図１５の上部に記載された前提事項の表を参照）。
これに対し、本発明のファンドラップシステム１０では、注文作成手段２５により注文データ作成タイミング判断処理を実行するので、従来システムの場合とは異なり、注文データ作成日は、３月１３日（月）にならない。図１５の例では、イベント反映手段２４により注文管理記憶手段５２（図１０参照）に記憶される注文日は、海外休場日を考慮した３月１７日（金）となるので、注文作成手段２５は、この注文日（３月１７日（金））を毎営業日に参照し、判断時点の日の翌営業日が、注文日（３月１７日（金））に該当するという注文作成条件を満たしているか否かを判断する。注文作成条件が満たされるのは、３月１６日（木）であるから、３月１６日（木）が注文データ作成日となり、３月１３日（月）〜３月１５日（水）は、注文データ作成待機の状態となる。従って、注文データ作成日である３月１６日（木）と、実際の注文日である３月１７日（金）とは、最も近い状態に置かれることになり、従来システムのように離れることはない。このことは、次のように、運用中のポートフォリオを、目標のポートフォリオに対し、より近づけることに寄与する。
先ず、従来システムの場合には、３月１３日（月）の時点で、各銘柄Ａ，Ｂ，Ｃ，Ｄの評価金額がそれぞれ１，０００，０００円であり、目標のポートフォリオの通りであったとすると、その日（３月１３日（月））に注文データを作成するので、各銘柄Ａ，Ｂ，Ｃ，Ｄの評価金額の合計金額４，０００，０００円に、増額金額の１，０００，０００円を加えた金額５，０００，０００円を、２５％ずつに配分し、各銘柄Ａ，Ｂ，Ｃ，Ｄへの目標の配分金額は、それぞれ５，０００，０００円×２５％＝１，２５０，０００円となる。従って、この１，２５０，０００円から、各銘柄の評価金額の１，０００，０００円をそれぞれ差し引くことにより各銘柄の買付金額を２５０，０００円と算出決定し、各銘柄の買注文の注文データを作成する。しかし、実際の注文日である３月１７日（金）までに基準価額の変動により各銘柄の評価金額が変化し、銘柄Ａの評価金額＝９５０，０００円となっているので、３月１７日（金）から約定日の３月２０日（月）まで基準価額の変動がなかったとすると、この９５０，０００円に、買付金額の２５０，０００円を加え、約定日の３月２０日（月）には、銘柄Ａの評価金額＝９５０，０００円＋２５０，０００円＝１，２００，０００円となる。他の銘柄Ｂ，Ｃ，Ｄも同様であり、銘柄Ｂの評価金額＝１，１００，０００円＋２５０，０００円＝１，３５０，０００円となり、銘柄Ｃの評価金額＝１，０００，０００円＋２５０，０００円＝１，２５０，０００円となり、銘柄Ｄの評価金額＝１，１００，０００円＋２５０，０００円＝１，３５０，０００円となるので、約定日の３月２０日（月）における各銘柄の評価金額の合計金額は、５，１５０，０００円となる。従って、銘柄Ａの保有比率は、１，２００，０００円÷５，１５０，０００円＝２３．３０％となり、銘柄Ｂの保有比率は、１，３５０，０００円÷５，１５０，０００円＝２６．２１％となり、銘柄Ｃの保有比率は、１，２５０，０００円÷５，１５０，０００円＝２４．２８％となり、銘柄Ｄの保有比率は、１，３５０，０００円÷５，１５０，０００円＝２６．２１％となり、結局、約定日の３月２０日（月）における銘柄保有比率は、それぞれ目標の２５％から、ずれた数値となっている。
これに対し、本発明のファンドラップシステム１０では、注文データ作成日は、３月１６日（木）であるから、その時点での各銘柄の評価金額を用いて注文データを作成する。３月１６日（木）の時点で、銘柄Ａの評価金額は、９５０，０００円に変化し、他の銘柄Ｂ，Ｃ，Ｄの評価金額も変化し、各銘柄Ａ，Ｂ，Ｃ，Ｄの評価金額の合計金額は、４，１００，０００円となっているので、これに増額金額の１，０００，０００円を加えた金額５，１００，０００円を、２５％ずつに配分し、各銘柄Ａ，Ｂ，Ｃ，Ｄへの目標の配分金額は、それぞれ５，１００，０００円×２５％＝１，２７５，０００円となる。従って、この１，２７５，０００円から、銘柄Ａの評価金額の９５０，０００円を差し引くことにより銘柄Ａの買付金額を３２５，０００円と算出決定し、銘柄Ａの買注文の注文データを作成する。同様に、１，２７５，０００円から銘柄Ｂの評価金額の１，０５０，０００円を差し引くことにより銘柄Ｂの買付金額を２２５，０００円と算出決定し、１，２７５，０００円から銘柄Ｃの評価金額の１，０００，０００円を差し引くことにより銘柄Ｃの買付金額を２７５，０００円と算出決定し、１，２７５，０００円から銘柄Ｄの評価金額の１，１００，０００円を差し引くことにより銘柄Ｄの買付金額を１７５，０００円と算出決定し、各銘柄Ｂ，Ｃ，Ｄの買注文の注文データを作成する。そして、注文日である３月１７日（金）には、銘柄Ａの評価金額＝９５０，０００円となっているので、３月１７日（金）から約定日の３月２０日（月）まで基準価額の変動がなかったとすると、この９５０，０００円に、買付金額の３２５，０００円を加え、約定日の３月２０日（月）には、銘柄Ａの評価金額＝９５０，０００円＋３２５，０００円＝１，２７５，０００円となる。他の銘柄Ｂ，Ｃ，Ｄも同様であり、銘柄Ｂの評価金額＝１，１００，０００円＋２２５，０００円＝１，３２５，０００円となり、銘柄Ｃの評価金額＝１，０００，０００円＋２７５，０００円＝１，２７５，０００円となり、銘柄Ｄの評価金額＝１，１００，０００円＋１７５，０００円＝１，２７５，０００円となるので、約定日の３月２０日（月）における各銘柄の評価金額の合計金額は、５，１５０，０００円となる。従って、銘柄Ａの保有比率は、１，２７５，０００円÷５，１５０，０００円＝２４．７６％となり、同様に、各銘柄Ｂ，Ｃ，Ｄの保有比率は、２５．７２％、２４．７６％、２４．７６％となり、従来システムの場合に比べ、目標の２５％に近い比率となっている。
定期積立のイベントは、増額のイベントの繰り返しと考えることができるので、増額金額を、毎月（指定月）の定期積立金額に置き換え、あるいは、ボーナス月の場合には、毎月（指定月）の定期積立金額にボーナス月の定期積立加算金額を加算した金額に置き換えて考えればよい。
減額のイベントでは、注文作成手段２５は、既に保有銘柄で構成されているポートフォリオがあるので、その時点（注文データ作成時点）における各保有銘柄の評価金額の合計金額から、減額金額を差し引いた金額を、目標のポートフォリオになるように配分し、得られた各銘柄への配分金額を、その時点（注文データ作成時点）における各保有銘柄の評価金額から差し引くことにより各銘柄の売却金額を算出決定し、各銘柄の売注文の注文データを作成する。
運用口削除のイベントでは、注文作成手段２５は、削除対象の運用口の全ての保有銘柄を全口数売却するように、各銘柄の売注文の注文データを作成する。また、注文作成手段２５は、運用口削除のイベントの申込があり、定期受取、寄附、またはその他の売注文を伴う月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文の注文データを作成する際には、抹消扱いとした月末イベントの売注文の分を含めた状態の数量または金額を、運用口削除の売注文の注文数量または注文金額とする処理を実行する。この処理の詳細については、図１９〜図２３を用いて後述するので、ここでは詳しい説明を省略する。
スタイル変更や、投資対象銘柄変更のイベントでは、注文作成手段２５は、変更前の銘柄から変更後の銘柄への入替を行うために、先ず、売注文の注文データを作成し、次に、買注文の注文データを作成する。詳細については、図１６〜図１８を用いて後述するので、ここでは概略を説明する。例えば、銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄに構成銘柄を変更する場合には、銘柄Ｃの売却、および銘柄Ｄの買付が行われることになるが、銘柄Ａ，Ｂについても、変更の前後で、設定構成比率が異なっていれば、変更後の設定構成比率（変更後の目標のポートフォリオ）にするために、差額分についての売買を行う。この際、スタイル変更や、投資対象銘柄変更のイベントでは、イベント反映手段２４により運用口銘柄構成記憶手段５９（図１４参照）への銘柄変更処理が実行され、運用口銘柄構成記憶手段５９には、変更後の銘柄構成（銘柄Ａ，Ｂ，Ｄ）が記憶されているので、注文作成手段２５は、変更後の設定構成比率が０％となる銘柄Ｃについては、全口数売却する売注文の注文データを作成することになる。また、銘柄Ｄについては、保有口数はゼロであるので、変更後の設定構成比率に相当する全金額分の買付を行う。一方、銘柄Ａ，Ｂについては、既に保有している口数があるので、変更後の設定構成比率に相当する全金額分の買付を行うのではなく、変更後の設定構成比率を超えている金額分について売却を行い、変更後の設定構成比率に足りていない金額分について買付を行う。
なお、投資対象銘柄変更のイベントは、資産クラス内の銘柄を入れ替えるサービスであるので、変更対象の資産クラス内の銘柄の売買を行うが、それ以外の銘柄を含めて運用口全体の構成銘柄で目標のポートフォリオにするための売買を行ってもよい。例えば、対象運用口の運用スタイルが資産クラスα，β，γ，δで構成されているとすると、資産クラスαについて、銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄへの変更を行う投資対象銘柄変更のイベントである場合に、併せて、他の資産クラスβ，γ，δの銘柄Ｅ，Ｆ，Ｇ，…の売買を行ってもよく、この場合は、他の資産クラスβ，γ，δの銘柄構成が変化するわけではなく、各銘柄Ｅ，Ｆ，Ｇ，…の保有数量（口数）の増減調整が行われるだけである。
リバランスのイベント（リバランス要と判定された場合）では、注文作成手段２５は、運用中のポートフォリオ（各銘柄の構成比率）を、顧客との契約に基づく運用スタイルに沿った目標のポートフォリオ（各銘柄の配分比率）に修正するための売買注文の注文データを作成する。すなわち、目標のポートフォリオの配分比率よりも構成比率（保有比率）が大きくなっている銘柄については、超えている金額分について売却を行い、その売却で得られた資金を用いて、目標のポートフォリオの配分比率よりも構成比率が小さくなっている銘柄について、不足している金額分について買付を行う。
定期受取や寄附のイベントでは、注文作成手段２５は、売注文の注文データを作成するが、減額のイベントにおける減額金額を、定期受取指定金額や寄附金額に置き換えて考えればよい。
四半期フィー徴収のイベントでは、注文作成手段２５は、フィー徴収に当てる売却金額が小さいため、例外的に、運用スタイルに沿った目標のポートフォリオから最も大きく乖離している銘柄だけの売注文の注文データを作成する。この際、最も大きく乖離している銘柄の判断は、注文データ作成時点で行うので、注文作成手段２５による注文データ作成タイミング判断処理は、他のイベントと同様に行う。従って、イベント反映手段２４により注文管理記憶手段５２（図１０参照）に注文日を記憶させる注文管理処理も、他のイベントと同様に行われる。なお、四半期フィー徴収でも、複数の銘柄を売却するようにしてもよい。
＜ファンドラップシステム１０／処理手段２０／日付算出手段２６の構成＞
日付算出手段２６は、翌営業日のシステム処理で用いる各種の日付（翌営業日用の日付）を算出し、算出日付記憶手段６１（図１４参照）に記憶させる処理を、毎営業日に実行するものである。この日付算出手段２６による処理は、本実施形態では、毎営業日の夜間バッチ処理で実行するので、翌営業日用の日付を、夜間バッチ処理（日付を使用する日から見ると、前営業日の夜間バッチ処理となる。）で算出していることになる。
例えば、減額や運用口削除等のような売却を伴う売却系イベント（減額系イベント）の申込では、顧客またはその入力代行者による端末装置１００からの日中オンライン入力時に、顧客またはその入力代行者に対し、画面表示で通知する日付（支払日（最遅受渡日））があるが、その日付の算出を、その日中オンライン入力（画面表示による通知）が行われる日の前営業日の夜間バッチ処理で実行する。また、売却系イベントで売注文の注文データを作成する際に、併せてその注文データを含む注文明細を作成するが、この注文明細に記載する日付（注文日、売却銘柄の注文についての約定日や受渡日、あるいは同時並行して実行される他の売却銘柄の注文を含めた最遅約定日や最遅受渡日）の算出を、その注文データ作成日の前営業日の夜間バッチ処理で実行する。この際、日付の算出は、原則として、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている各運用口の各構成銘柄を対象として行われるが、この原則およびその例外については、後述する。
具体的には、日付算出手段２６は、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄、または残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄のいずれかから選択した日付の算出対象銘柄について、当該運用口の全ての銘柄について注文可能な日として注文可否日記憶手段５７（図１４参照）に記憶されている日（注文可否日記憶手段５７において、当該運用口の全ての銘柄が「１（注文可）」となっている日）を、当該運用口の各銘柄に共通する注文日として決定し、決定した注文日に対応する約定日および受渡日を約定・受渡日数記憶手段５８（図１４参照）に記憶された日数から算出するとともに、当該運用口の運用スタイルを構成する資産クラス内の全ての算出対象銘柄についての約定日および受渡日から資産クラス内の最遅約定日および最遅受渡日を求め、さらに、当該運用口の全ての算出対象銘柄についての約定日および受渡日から運用口全体の最遅約定日および最遅受渡日を求める処理を、毎営業日に実行する。
そして、日付算出手段２６は、得られた注文日、約定日、および受渡日を、銘柄コード（銘柄識別情報）および運用口ファンドコード（運用口識別情報）と関連付けて算出日付記憶手段６１の銘柄単位算出日付記憶手段６１Ａ（図１４参照）に記憶させるとともに、得られた資産クラス内の最遅約定日および最遅受渡日を、運用口ファンドコード（運用口識別情報）および資産クラスコード（資産クラス識別情報）と関連付けて算出日付記憶手段６１の資産クラス単位算出日付記憶手段６１Ｂ（図１４参照）に記憶させ、さらに、得られた運用口全体の最遅約定日および最遅受渡日を、運用口ファンドコード（運用口識別情報）と関連付けて算出日付記憶手段６１の運用口単位算出日付記憶手段６１Ｃ（図１４参照）に記憶させる処理を、毎営業日に実行する。
ここで、「日付の算出対象銘柄」は、運用口を構成する銘柄が複数あり、スタイル変更や、投資対象銘柄変更のイベントがあると、運用口の銘柄構成が変化するので、いずれの銘柄構成の状態における銘柄を対象として、日付を算出するのかを示すものである。ファンドラップサービスでは、各銘柄の注文日を揃えたいという顧客の要望があるため、注文日を、運用口の全ての銘柄が注文可能な日とすることから（但し、投資対象銘柄変更のイベントについては、資産クラス内の銘柄の売買だけを行う場合には、資産クラス内の全ての銘柄が注文可能な日としてもよく、その場合には、資産クラス毎の全ての銘柄が注文可能な日となる。）、日付の算出対象銘柄が変化すると、決定される注文日は、その影響を受ける。また、運用口全体の最遅約定日は、運用口の複数の銘柄についての各約定日のうちの最も遅い約定日であり、運用口全体の最遅受渡日は、運用口の複数の銘柄についての各受渡日のうちの最も遅い受渡日であるため、日付の算出対象銘柄が変化すると、決定される運用口全体の最遅約定日や最遅受渡日は、その影響を受ける。同様に、資産クラス内の最遅約定日は、運用口を構成する資産クラス内の複数の銘柄についての各約定日のうちの最も遅い約定日であり、資産クラス内の最遅受渡日は、運用口を構成する資産クラス内の複数の銘柄についての各受渡日のうちの最も遅い受渡日であるため、日付の算出対象銘柄が変化すると、決定される資産クラス内の最遅約定日や最遅受渡日は、その影響を受ける。従って、日付の算出対象銘柄を、いずれの銘柄構成の状態における銘柄とするかを決めることが重要となる。
この際、日付算出手段２６は、スタイル変更や、投資対象銘柄変更のイベントが無ければ、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄に変化はないので、原則通り、運用口銘柄構成記憶手段５９に記憶されている運用口の各構成銘柄だけを参照して日付の算出対象銘柄を決定すればよいが、スタイル変更や、投資対象銘柄変更のイベントが発生した場合は、次のような日付の算出対象銘柄の選択処理を実行する。
すなわち、日付算出手段２６は、注文管理記憶手段５２（図１０参照）に記憶されているイベント番号（イベント番号により、イベント記憶手段４９（図７参照）のイベント区分を特定することができる。）および最遅約定日を用いて、スタイル変更のイベントまたは投資対象銘柄変更のイベントが発生し、かつ、スタイル変更または投資対象銘柄変更による売注文の最遅約定日よりも前の日であると判断した場合には、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄を、算出対象銘柄として選択し、それ以外の場合には、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている当該運用口の各構成銘柄を、算出対象銘柄として選択する処理を実行する。この算出対象銘柄の選択処理についての詳細は、図１６〜図１８を用いて後述する。
＜ファンドラップシステム１０／処理手段２０／手数料算出手段２７の構成＞
手数料算出手段２７は、運用する資産額に応じて顧客から徴収する手数料（投資顧問料、取引等管理手数料）を算出し、その算出結果を、運用口ファンドコード（運用口識別情報）と関連付けて算出手数料記憶手段（不図示）に記憶させる処理を実行するものである。徴収する手数料には、契約時フィー（新規契約、運用口追加、あるいは増額の場合の手数料）と、四半期毎に徴収する四半期フィー（より一般には、運用期間の経過に伴って徴収する期間フィー）とがある。この手数料算出手段２７は、残高記憶手段６０（図１４参照）に記憶されている各運用口の各保有銘柄の残高数量に単価情報記憶手段４５（図５参照）に記憶されている基準価額を乗じて得られる手数料算出時点の評価金額（または、基準価額の更新に伴って算出されて残高記憶手段６０（図１４参照）に記憶されている各運用口の各保有銘柄の評価金額）と、手数料率記憶手段（不図示）に記憶された手数料率とを用いて、手数料を算出する。
＜ファンドラップシステム１０／処理手段２０／注文データ連携手段２８の構成＞
注文データ連携手段２８は、注文データ記憶手段５４（図１１参照）に記憶されている注文データを、通信回線２を介して売買システム７０へ送信する処理を実行するものである。
＜ファンドラップシステム１０／処理手段２０／約定処理手段２９の構成＞
約定処理手段２９は、通信回線２を介して売買システム７０から送信されてきてファンドラップシステム１０の約定データ記憶手段（不図示）に記憶されている約定データ（注文番号、銘柄コード（銘柄識別情報）、約定数量（口数）、売買区分（売・買の別）、約定時の基準価額、顧客の口座番号（顧客識別情報）等を含む）を取得し、注文データ記憶手段５４（図１１参照）に記憶されている注文データ（約定データと同一の注文番号の注文データ）のステータスを「約定済」に更新する処理を実行するものである。
＜ファンドラップシステム１０／処理手段２０／資産管理手段３０の構成＞
資産管理手段３０は、四半期フィー等の期間フィーの徴収の場合には、約定データ記憶手段（不図示）から、売注文の約定データを取得し、約定した銘柄（本実施形態では、投資信託の銘柄）についての約定数量の分だけ、残高記憶手段６０（図１４参照）に記憶された当該銘柄の残高数量を減少させる更新処理を実行するとともに、売却で得られた金額（受渡金額）の分だけ、金銭残高記憶手段４４（図４参照）に記憶された金銭残高を増加させる更新処理を実行するものである。
また、契約時フィーを徴収する際には、金銭残高記憶手段３２（図４参照）に記憶された金銭残高に、新規契約、運用口追加、あるいは増額のイベントにおける入金額があるので、その入金額から契約時フィー（入金額に対して僅かな割合の金額）を徴収するとともに、入金額のうちの残りの金額（入金額のうちの大部分の金額）を、投資信託の買付に充当する。従って、資産管理手段３０は、約定データ記憶手段（不図示）から、買注文の約定データを取得し、約定した銘柄（本実施形態では、投資信託の銘柄）についての約定数量の分だけ、残高記憶手段６０（図１４参照）に記憶された当該銘柄の残高数量を増加させる更新処理を実行するとともに、買付に充当された金額の分だけ、金銭残高記憶手段４４（図４参照）に記憶された金銭残高を減少させる更新処理を実行する。なお、買付に充当された金額を減じた後でも、金銭残高記憶手段４４（図４参照）に記憶された金銭残高には、入金額のうちの手数料徴収に充当する分の金額、すなわち、算出手数料記憶手段（不図示）に記憶された手数料の金額（投資顧問料金額＋取引等管理手数料金額）は残っている。
＜ファンドラップシステム１０／処理手段２０／金銭振替手段３１の構成＞
金銭振替手段３１は、金銭残高記憶手段４４（図４参照）に記憶された金銭残高について通信回線２で接続された売買システム７０との間で金銭振替処理を実行するとともに、金銭振替明細（金銭振替明細番号、金銭振替発生元イベント番号、顧客の口座番号（顧客識別情報）、運用口ファンドコード（運用口識別情報）、金銭振替金額等を含む）を作成し、金銭振替明細記憶手段５６（図１３参照）に記憶させる金銭振替明細作成処理を実行するものである。
具体的には、金銭振替手段３１は、例えば、定期受取のイベント（狭義）では、金銭残高記憶手段４４（図４参照）に記憶された金銭残高から、売却を行って得られた金額（定期受取指定金額）を減少させる更新処理を実行するとともに、その金額データを、通信回線２を介して売買システム７０へ送信する処理を実行する。この金額データ（定期受取指定金額）は、売買システム７０へ送信されると、売買システム側金銭振替手段７３により、顧客の主口座に振り替えられ、主口座の残高金額が増加する。
また、金銭振替手段３１は、四半期フィー徴収のイベント等の手数料の徴収の際には、金銭残高記憶手段４４（図４参照）に記憶された金銭残高から、手数料として徴収する金額、すなわち、手数料算出手段２７により算出されて算出手数料記憶手段（不図示）に記憶された手数料の金額を減少させる更新処理を実行するとともに、手数料の金額データを、通信回線２を介して売買システム７０へ送信する処理を実行する。この金額データ（手数料の金額）は、売買システム７０へ送信されると、売買システム側金銭振替手段７３により、証券会社等の金融機関の勘定に振り替えられ、証券会社等の金融機関の勘定が増加する。
さらに、金銭振替手段３１は、運用口削除のイベントの申込があり、定期受取のイベント（狭義）や寄附のイベント（狭義）等の売注文を伴う月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文（抹消扱いとした月末イベントの売注文の分を含む）の約定に伴って金銭残高記憶手段４４（図４参照）に記憶された金銭残高の全額を金銭振替金額とする金銭振替処理を実行するとともに、抹消扱いとした月末イベントの売注文により得られるはずであった売却金額を含む定期受取や寄附等の月末イベントの金銭振替明細、および、金銭振替金額から月末イベントの売注文により得られるはずであった売却金額を差し引いた金額を含む運用口削除の金銭振替明細を作成する処理を実行する。この処理の詳細については、図１９〜図２３を用いて後述するので、ここでは詳しい説明を省略する。
＜ファンドラップシステム１０／処理手段２０／帳票作成用データ連携手段３２の構成＞
帳票作成用データ連携手段３２は、定期受取明細記憶手段５５（図１２参照）に記憶された定期受取明細データ、寄附明細記憶手段（不図示）に記憶された寄附明細データ、金銭振替明細記憶手段５６（図１３参照）に記憶された金銭振替明細データ、算出手数料記憶手段（不図示）に記憶された手数料の金額（投資顧問料金額＋取引等管理手数料金額）データ等を取得し、取得したデータを、帳票作成用データとして、通信回線２を介して売買システム７０へ送信する処理を実行するものである。
＜ファンドラップシステム１０／記憶手段４０の構成＞
主口座記憶手段４１は、図３に示すように、主口座の口座番号（顧客識別情報）、口座ファンドコードを関連付けて記憶するものである。
契約記憶手段４２は、図３に示すように、契約ファンドコード、主口座の口座番号（顧客識別情報）、サービス種類区分（「ファンドラッププレミアム」サービス＝０１、「ファンドラップオンライン」サービス＝０２、…）、新規契約年月日、新規契約金額、口座ファンドコード、リバランス判定基準乖離率（リバランス判定の基準となる乖離率：％単位）等を関連付けて記憶するものである。
運用口記憶手段４３は、図３に示すように、運用口ファンドコード（運用口識別情報）、主口座の口座番号（顧客識別情報）、サービス種類区分（「ファンドラッププレミアム」サービス＝０１、「ファンドラップオンライン」サービス＝０２、…）、運用口番号（１，２，３，４，５）、運用口名称（運用口の愛称等）、運用スタイル区分（共通スタイル＝１、個別スタイル（１）＝２、個別スタイル（２）＝３、…）、運用スタイルコード（運用スタイル識別情報）、運用口ステータス（新規申請中＝１、追加申請中＝２、運用中＝３、運用終了＝４、取消済＝５）、設定金額（運用口で運用する金額：各時点での金額であり、更新される金額）、契約ファンドコード、当初設定金額（新規契約時または運用口追加時の設定金額）、定期受取の登録情報（定期受取タイミング、定期受取指定金額等）、寄附の登録情報（食料支援、医療、環境、子供支援、災害復興等の寄附のテーマ（寄附先）、寄附金額等）、定期積立の登録情報（定期積立タイミング、定期積立設定日、毎月の定期積立金額、ボーナス月の定期積立加算金額等）、約定ベースホールド期間の設定情報（期間の終了年月日等）、月末ホールド期間の設定情報（期間の設定年月日等）などを関連付けて記憶するものである。
金銭残高記憶手段４４は、図４に示すように、顧客の保有する金銭残高、主口座の口座番号（顧客識別情報）等を関連付けて記憶するものである。
単価情報記憶手段４５は、図５に示すように、投資信託の銘柄コード、基準価額等を関連付けて記憶するものである。また、単価情報記憶手段４５は、株式や債券等の銘柄コード、単価等も関連付けて記憶し、さらに、例えば、日経平均、ＮＹダウ、原油価格等の各種の金融指標についての指標値も記憶している。
運用スタイル記憶手段４６は、図６に示すように、サービス種類区分（「ファンドラッププレミアム」サービス＝０１、「ファンドラップオンライン」サービス＝０２、…）、運用スタイル区分（共通スタイル＝１、個別スタイル（１）＝２、個別スタイル（２）＝３、…）、運用スタイルコード（運用スタイル識別情報）、運用スタイル名称（安定型、やや安定型、バランス型、やや積極型、積極型、…）、手数料コード（手数料率識別情報）等を関連付けて記憶するものである。
運用スタイル・資産クラス構成記憶手段４７は、図６に示すように、運用スタイルコード（運用スタイル識別情報）、資産クラスコード（資産クラス識別情報）、設定構成比率（運用スタイルコードに紐付く資産クラスの配分比率：％単位）等を関連付けて記憶するものである。
資産クラス銘柄構成記憶手段４８は、図６に示すように、資産クラスコード（資産クラス識別情報）、投資信託の銘柄コード（銘柄識別情報）等を関連付けて記憶するものである。
イベント記憶手段４９は、図７に示すように、イベント番号（各イベントの識別情報）、イベント区分（新規契約、増額、減額、運用口追加、運用口削除、スタイル変更、投資対象銘柄変更、定期受取申込、定期受取タイミング変更、定期受取指定金額変更、定期受取、寄附申込、寄附先変更、寄附金額変更、寄附、定期積立申込、定期積立変更、定期積立、リバランス判定基準乖離率変更（運用口単位ではない）等のイベント種別の識別情報）、イベントステータス（申請中、成立、不成立、取消済、…）、運用口ファンドコード（運用口識別情報）、主口座の口座番号（顧客識別情報）、契約ファンドコード、運用開始日、新規契約時の設定金額、運用口追加時の設定金額、増額金額、減額金額、変更前および変更後の運用スタイルコード（運用スタイル識別情報）、変更前および変更後の資産クラスコード、変更前および変更後の定期受取タイミング、変更前および変更後の定期受取指定金額、変更前および変更後の寄附先、変更前および変更後の寄附金額、変更前および変更後の定期積立タイミング、変更前および変更後の定期積立設定日、変更前および変更後の毎月の定期積立金額、変更前および変更後のボーナス月の定期積立加算金額、変更前および変更後のリバランス判定基準乖離率（運用口単位ではない）、定期受取判定年月日（定期受取の自動継続判定を行う年月日：定期受取月の前月の月末営業日）、定期受取判定結果（当月に定期受取に伴う売却注文データを作成しない＝０、作成する＝１）、寄附計算処理年月日等を関連付けて記憶するものである。
リバランス記憶手段５０は、図８に示すように、リバランス番号（リバランスイベントの識別情報）、運用口ファンドコード（運用口識別情報）、主口座の口座番号（顧客識別情報）、リバランス実施判定年月日（リバランス実施判定処理を行う年月日：月末営業日）、リバランス実施判定結果（要・不要の別）等を関連付けて記憶するものである。
四半期フィー徴収記憶手段５１は、図９に示すように、四半期フィー徴収番号（四半期フィー徴収イベントの識別情報）、運用口ファンドコード（運用口識別情報）、主口座の口座番号（顧客識別情報）、四半期フィー計算処理年月日等を関連付けて記憶するものである。
注文管理記憶手段５２は、図１０に示すように、運用口ファンドコード（運用口識別情報）、注文データ作成イベント番号（注文データ作成対象となるイベント、例えば、スタイル変更、投資対象銘柄変更等の各イベントの識別情報）、売買ステータス（注文データ作成の状態であり、売却または買付のいずれかの注文データの作成が必要な状態、注文データ作成済の状態、売買不要の状態）、注文日、最遅約定日、最遅受渡日、抹消フラグ（レコードの論理抹消の有無：非抹消＝０、抹消＝１）等を関連付けて記憶するものである。
注文明細記憶手段５３は、図１１に示すように、注文明細番号、売買する投資信託の銘柄コード（銘柄識別情報）、注文数量（口数指定で注文する場合の口数）、注文金額（金額指定で注文する場合の金額）、売買区分（売・買の別）、主口座の口座番号（顧客識別情報）、運用口ファンドコード（運用口識別情報）、注文日、約定日（注文に対して約定成立可能要件を満たす年月日）、受渡日（顧客と受渡を行う年月日）等を関連付けて記憶するものである。
注文データ記憶手段５４は、図１１に示すように、注文番号（＝注文明細番号）、売買する投資信託の銘柄コード（銘柄識別情報）、注文数量（口数指定で注文する場合の口数）、注文金額（金額指定で注文する場合の金額）、売買区分（売・買の別）、主口座の口座番号（顧客識別情報）、ステータス（注文中、約定済、…）等を関連付けて記憶するものである。
定期受取明細記憶手段５５は、図１２に示すように、定期受取明細番号、定期受取イベント番号（定期受取のイベントの識別情報）、主口座の口座番号（顧客識別情報）、運用口ファンドコード（運用口識別情報）、定期受取金額等を関連付けて記憶するものである。
金銭振替明細記憶手段５６は、図１３に示すように、金銭振替明細番号、金銭振替発生元イベント番号（金銭振替の発生要因となったイベント、例えば、定期受取、新規契約、運用口追加、増額、定期積立、減額、運用口削除等の各イベントの識別情報）、主口座の口座番号（顧客識別情報）、運用口ファンドコード（運用口識別情報）、金銭振替金額等を関連付けて記憶するものである。
注文可否日記憶手段５７は、図１４に示すように、カレンダー形式で、投資信託の各銘柄についての銘柄コード（銘柄識別情報）と、各日における注文の可否の情報（注文不可＝０、注文可＝１）とを関連付けて記憶するものである。各日における注文の可否の情報は、営業日（国内の営業日）であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報であり、例えば、海外休場日を考慮した情報である。図１４の例では、営業日（国内の営業日）であるか否かの要素と、海外休場日であるか否かの要素との双方を加味した状態の注文の可否の情報となっているが、営業日（国内の営業日）であるか否かによる注文の可否の情報と、海外休場日であるか否かによる注文の可否の情報とを、別々に用意してもよい（別のテーブル等で用意してもよい）。すなわち、別々に用意された双方の情報を参照することにより、最終的に、海外休場日を考慮した状態での各日における注文の可否の情報が得られるようになっていてもよい。また、営業日（国内の営業日）であるか否か以外の要素としては、海外休場日に該当するか否かの他に、例えば、急激な相場変動に伴う注文回避期間やその他のルールによる注文回避期間に該当するか否か等がある。これらの各要素の場合も、注文の可否の情報は、別々に用意してもよく、全部の要素または複数の要素を加味した状態の注文の可否の情報を用意してもよい。
約定・受渡日数記憶手段５８は、図１４に示すように、注文日から約定日までの日数、および注文日から受渡日までの日数を、投資信託の銘柄コード（銘柄識別情報）と関連付けて記憶するものである。
運用口銘柄構成記憶手段５９は、図１４に示すように、主口座の口座番号（顧客識別情報）、運用口ファンドコード（運用口識別情報）、投資信託の銘柄コード（銘柄識別情報）、設定構成比率（対象銘柄の資産クラス内での配分比率：％単位）等を関連付けて記憶するものである。
残高記憶手段６０は、図１４に示すように、主口座の口座番号（顧客識別情報）、運用口ファンドコード（運用口識別情報）、顧客の保有資産である投資信託の銘柄コード（銘柄識別情報）、残高数量（保有する投資信託の口数）、評価金額等を関連付けて記憶するものである。
算出日付記憶手段６１は、図１４に示すように、銘柄単位算出日付記憶手段６１Ａと、資産クラス単位算出日付記憶手段６１Ｂと、運用口単位算出日付記憶手段６１Ｃとを含んで構成されている。
銘柄単位算出日付記憶手段６１Ａは、図１４に示すように、運用口ファンドコード（運用口識別情報）、資産クラスコード（資産クラス識別情報）、投資信託の銘柄コード（銘柄識別情報）、注文日（但し、全銘柄が注文可能な日）、約定日、受渡日等を関連付けて記憶するものである。
資産クラス単位算出日付記憶手段６１Ｂは、図１４に示すように、運用口ファンドコード（運用口識別情報）、資産クラスコード（資産クラス識別情報）、資産クラス内の最遅約定日、資産クラス内の最遅受渡日等を関連付けて記憶するものである。
運用口単位算出日付記憶手段６１Ｃは、図１４に示すように、運用口ファンドコード（運用口識別情報）、運用口全体の最遅約定日、運用口全体の最遅受渡日等を関連付けて記憶するものである。
＜売買システム７０の詳細構成＞
＜売買システム７０／売買処理手段７１、約定データ連携手段７２、売買システム側金銭振替手段７３、帳票作成手段７４の構成＞
売買処理手段７１は、ファンドラップシステム１０から通信回線２を介して送信されてきて注文データ記憶手段８１（図１参照）に記憶されている注文データ（注文番号、売買銘柄についての銘柄コード、注文数量（口数）または注文金額、売買区分、口座番号を含む。）を用いて、金融商品（本実施形態では、投資信託）の売買処理を実行するとともに、その約定データ（注文番号、売買銘柄についての銘柄コード、約定数量（口数）、売買区分、約定時の基準価額、口座番号を含む。）を約定データ記憶手段８２（図１参照）に記憶させる処理を実行するものである。
約定データ連携手段７２は、約定データ記憶手段８２（図１参照）に記憶されている約定データを、通信回線２を介してファンドラップシステム１０へ送信する処理を実行するものである。
売買システム側金銭振替手段７３は、通信回線２で接続されたファンドラップシステム１０との間で金銭振替処理を実行するものである。この売買システム側金銭振替手段７３は、金銭振替手段３１によりファンドラップシステム１０から通信回線２を介して送信されてくる金銭振替に係る金額データを受信し、金銭振替処理を実行する。例えば、定期受取のイベント（狭義）では、ファンドラップシステム１０から受信する金額データは、定期受取指定金額であり、この金額を顧客の主口座に振り替えて主口座の残高金額を増加させる。また、四半期フィー徴収のイベント等の手数料の徴収の際には、ファンドラップシステム１０から受信する金額データは、手数料として徴収する金額、すなわち、手数料算出手段２７により算出されて算出手数料記憶手段（不図示）に記憶された手数料の金額であり、この金額を証券会社等の金融機関の勘定に振り替えることにより、手数料の徴収処理を実行する。
帳票作成手段７４は、ファンドラップシステム１０から通信回線２を介して送信されてきて帳票作成用データ記憶手段８３（図１参照）に記憶されている帳票作成用データ（例えば、定期受取明細データ、寄附明細データ、金銭振替明細データ、手数料の金額データ等）を用いて、四半期の運用報告書等の各種の帳票を作成し、帳票記憶手段８４（図１参照）に記憶させる処理を実行するものである。帳票記憶手段８４に記憶された帳票データは、帳票の印刷処理や、端末装置１００，１１０からの閲覧要求に応じた帳票の表示処理等の出力処理に使用される。なお、売買システム７０には、これらの出力処理（印刷処理や表示処理等）を行うための図示されない帳票出力手段が設けられている。
＜売買システム７０／注文データ記憶手段８１、約定データ記憶手段８２、帳票作成用データ記憶手段８３、帳票記憶手段８４の構成＞
注文データ記憶手段８１は、ファンドラップシステム１０から通信回線２を介して送信されてきた注文データ（注文番号、売買銘柄についての銘柄コード、注文数量（口数）または注文金額、売買区分、口座番号を含む。）を記憶するものである。
約定データ記憶手段８２は、売買処理手段７１による売買処理で取引が成立した注文の約定データ（注文番号、売買銘柄についての銘柄コード、約定数量（口数）、売買区分、約定時の基準価額、口座番号を含む。）を記憶するものである。
帳票作成用データ記憶手段８３は、ファンドラップシステム１０から通信回線２を介して送信されてきた帳票作成用データ（例えば、定期受取明細データ、寄附明細データ、金銭振替明細データ、手数料の金額データ等）を記憶するものである。
帳票記憶手段８４は、帳票作成手段７４により作成された帳票データ（四半期の運用報告書データ等の各種の帳票データ）を記憶するものである。
＜各日付（注文日、最遅約定日、最遅受渡日）の算出対象銘柄の変更：図１６〜図１９＞
図１６には、４月中にスタイル変更（銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄへの変更）のイベントが申し込まれた場合の４月の月末前後の処理内容が示されている。前提として、銘柄Ａ，Ｂ，Ｃ，Ｄは、注文日の翌営業日を約定日とする。また、５月１日（月）は、銘柄Ａ，Ｂ，Ｃのうちのいずれかが海外休場日に該当し、５月３日（水）〜５月７日（日）は、ゴールデンウィークの非営業日（国内の非営業日）である。
図１８において、４月中（例えば、４月２５日（火））に、端末装置１００からの日中のオンライン入力で、顧客またはその入力代行者によるスタイル変更の申込があった場合には、設定受付手段２１により、その申込を受け付け、イベント記憶手段４９（図７参照）にスタイル変更のイベントのレコード（申込受付日、イベントのバッチ処理反映日である申込月の月末営業日、変更前後の運用スタイルコード（運用スタイル識別情報）を含む：イベントステータスは「申請中」とする）が作成される（ステップＳ１）。
そして、日付算出手段２６による日付算出処理は、毎営業日の夜間バッチ処理で実行されるので、４月２７日（木）の夜間バッチ処理でも実行され、スタイル変更の対象運用口を含めて全ての運用口について、翌営業日（４月２８日（金））に使用される各日付（注文日、各銘柄の約定日や受渡日、あるいは最遅約定日や最遅受渡日）が算出され、算出日付記憶手段６１（図１４参照）に記憶される（ステップＳ２）。この際、日付算出手段２６は、スタイル変更の対象運用口については、未だスタイル変更が発生していない状態（申込は受け付けているが、月末の実施タイミングが到来していない状態）であるから、原則通り、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている対象運用口の各構成銘柄（銘柄Ａ，Ｂ，Ｃ）を算出対象銘柄として日付の算出処理を実行する（図１６の４月２７日（木）参照）。
その後、月末営業日（４月２８日（金））の夜間バッチ処理では、イベント反映手段２４によるイベント反映処理が実行される（図１８のステップＳ３）。このイベント反映処理では、運用口銘柄構成記憶手段５９（図１４参照）に、スタイル変更による銘柄構成の変更を反映させる。すなわち、銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄへ変更する。また、運用口記憶手段４３（図３参照）に記憶されている運用スタイルコード（運用スタイル識別情報）を変更後の状態にする。
また、イベント反映手段２４によるイベント反映処理（図１８のステップＳ３）では、イベント記憶手段４９（図７参照）のスタイル変更イベントのレコードのイベントステータスを「申請中」から「成立」に更新する。
さらに、イベント反映手段２４によるイベント反映処理（図１８のステップＳ３）では、注文管理記憶手段５２（図１０参照）に、スタイル変更イベントのレコードを作成する注文管理処理を実行する。この際、翌営業日（５月１日（月））ではなく、海外休業日を考慮した売注文の注文日（５月２日（火））、およびその注文日に対応する最遅約定日、最遅受渡日を記憶させる。ここで用いる海外休業日を考慮した売注文の注文日（５月２日（火））、およびその注文日に対応する最遅約定日、最遅受渡日は、前述したステップＳ２で、日付算出手段２６により前営業日（４月２７日（木））の夜間バッチ処理で算出されて算出日付記憶手段６１（図１４参照）に記憶されている日付（算出対象銘柄は、銘柄Ａ，Ｂ，Ｃ）である。
続いて、月末営業日（４月２８日（金））の夜間バッチ処理では、注文作成手段２５による処理（ここでは、スタイル変更の売注文）を実行する（図１８のステップＳ４）。先ず、売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する。
この注文データ作成タイミング判断処理では、注文作成手段２５は、注文管理記憶手段５２（図１０参照）に記憶されている売買ステータス（注文データ作成の状態）が「売却の注文データの作成が必要な状態」となっているレコードについて、翌営業日（ここでは５月１日（月））が、そのレコードに記憶されている注文日（５月２日（火））と一致するか否かを判断する。従って、本実施形態では、判断時点の日の翌営業日が、注文管理記憶手段５２（図１０参照）に記憶されている注文日（５月２日（火））と一致することが注文作成条件である。
そして、翌営業日（ここでは５月１日（月））が注文日（５月２日（火））と一致した場合には（従って、図１６の例では一致しない。）、売注文の注文明細のレコードを作成して注文明細記憶手段５３（図１１参照）に記憶させるとともに、売注文の注文データを作成して注文データ記憶手段５４（図１１参照）に記憶させる。この際、注文明細に記憶させる日付（注文日、約定日、受渡日、あるいは同時並行して実行される他の注文を含めた最遅約定日、最遅受渡日）は、前述したステップＳ２で、日付算出手段２６により前営業日（４月２７日（木））の夜間バッチ処理で算出されて算出日付記憶手段６１（図１４参照）に記憶されている日付（算出対象銘柄は、銘柄Ａ，Ｂ，Ｃ）を用いる。また、注文作成手段２５は、売却の注文データを作成したら、注文管理記憶手段５２（図１０参照）に記憶されている売買ステータスを「注文データ作成済の状態」に更新する。
一方、翌営業日（ここでは５月１日（月））が、注文管理記憶手段５２に記憶されている注文日（５月２日（火））と一致しなかった場合には、売注文の注文データの作成を待機する。つまり、注文管理記憶手段５２（図１０参照）に記憶されている売買ステータスは、「売却の注文データの作成が必要な状態」のままとする。従って、図１６の例では、月末営業日（４月２８日（金））の夜間バッチ処理では、注文データ作成待機の状態となる。
それから、月末営業日（４月２８日（金））の夜間バッチ処理でも、毎営業日に行われる日付算出手段２６による日付算出処理が実行され、スタイル変更の対象運用口を含めて全ての運用口について、翌営業日（５月１日（月））に使用される各日付（注文日、各銘柄の約定日や受渡日、あるいは最遅約定日や最遅受渡日）が算出され、算出日付記憶手段６１（図１４参照）に記憶される（ステップＳ５）。スタイル変更に伴う売注文については、既に注文管理記憶手段５２（図１０参照）にスタイル変更イベントのレコードが作成され、注文管理が開始されている状態であるが、スタイル変更のバッチ処理反映日（月末営業日）以降の日においても、同じ運用口について、スタイル変更とは別の売却系イベント（減額のイベント等）の申込が行われる場合があることと、スタイル変更に伴う売注文の注文データ作成が待機状態となり、注文データおよび注文明細の作成日が後ろの日にずれることがあるので、スタイル変更の対象運用口についても日付の算出処理が行われる。
この際、図１６の例では、日付算出手段２６は、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄（銘柄Ａ，Ｂ，Ｄ）ではなく、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄（銘柄Ａ，Ｂ，Ｃ）を、日付の算出対象銘柄として選択する（図１６の４月２８日（金）参照）。運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄は、前述したステップＳ３で、イベント反映手段２４により、既に銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄへ変更されているが（同日の先行する夜間バッチ処理での変更）、前述したステップＳ４で、スタイル変更に伴う売注文の注文データは作成待機状態となり、翌営業日以降に作成されることになったので、ステップＳ５での翌営業日用の日付の算出は、変更前の銘柄Ａ，Ｂ，Ｃを算出対象銘柄とする必要があるからである。仮に、原則通りに、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄を算出対象銘柄として日付の算出処理を行ってしまうと、変更後の銘柄Ａ，Ｂ，Ｄを算出対象銘柄とすることになり、翌営業日に銘柄Ｃの日付が算出されていない状態となり、不都合が生じる。
その後、５月１日（月）の夜間バッチ処理でも、注文作成手段２５により、前述したステップＳ４の場合と同様にして、売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する（図１８のステップＳ６）。すなわち、注文作成手段２５は、注文管理記憶手段５２（図１０参照）に記憶されている売買ステータス（注文データ作成の状態）が「売却の注文データの作成が必要な状態」となっているレコードについて、翌営業日（ここでは５月２日（火））が、そのレコードに記憶されている注文日（５月２日（火））と一致するか否かを判断する。従って、図１６の例では、この日（５月１日（月））に初めて注文作成条件を満たすことになる。
そして、図１６の例では、５月１日（月）に注文作成条件が満たされるので、売注文の注文明細のレコードを作成して注文明細記憶手段５３（図１１参照）に記憶させるとともに、売注文の注文データを作成して注文データ記憶手段５４（図１１参照）に記憶させる。この際、注文明細に記憶させる日付（注文日、約定日、受渡日、あるいは同時並行して実行される他の注文を含めた最遅約定日、最遅受渡日）は、前述したステップＳ５で、日付算出手段２６により前営業日（４月２８日（金））の夜間バッチ処理で算出されて算出日付記憶手段６１（図１４参照）に記憶されている日付（算出対象銘柄は、銘柄Ａ，Ｂ，Ｃ）を用いる（図１６の４月２８日（金）参照）。前述した通り、日付算出手段２６による算出処理での算出対象銘柄は、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄（銘柄Ａ，Ｂ，Ｄ）ではなく、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄（銘柄Ａ，Ｂ，Ｃ）をとされているので、銘柄Ｃの日付が算出されていることになる。また、注文作成手段２５は、売却の注文データを作成したら、注文管理記憶手段５２（図１０参照）に記憶されている売買ステータスを「注文データ作成済の状態」に更新する。
続いて、５月１日（月）の夜間バッチ処理でも、毎営業日に行われる日付算出手段２６による日付算出処理が実行され、スタイル変更の対象運用口を含めて全ての運用口について、翌営業日（５月２日（火））に使用される各日付（注文日、各銘柄の約定日や受渡日、あるいは最遅約定日や最遅受渡日）が算出され、算出日付記憶手段６１（図１４参照）に記憶される（図１８のステップＳ７）。この際、日付算出手段２６は、前述したステップＳ５の場合と同様に、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄（銘柄Ａ，Ｂ，Ｄ）ではなく、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄（銘柄Ａ，Ｂ，Ｃ）を、日付の算出対象銘柄として選択する（図１６の５月１日（月）参照）。
その後、５月２日（火）の夜間バッチ処理で、注文データ連携手段２８により、注文データ記憶手段５４（図１１参照）に記憶されている注文データを、通信回線２を介して売買システム７０へ送信して注文を行う。売買システム７０では、売買処理手段７１により、ファンドラップシステム１０から通信回線２を介して送信されてきて注文データ記憶手段８１（図１参照）に記憶されている注文データ（注文番号、売買銘柄についての銘柄コード、注文数量（口数）または注文金額、売買区分、口座番号を含む。）を用いて、投資信託の売買処理（ここでは、スタイル変更に伴う売注文の処理）を実行する。
さらに、５月８日（月）に、売買処理手段７１により、スタイル変更に伴う売注文の約定データ（注文番号、売買銘柄についての銘柄コード、約定数量（口数）、売買区分、約定時の基準価額、口座番号を含む。）を約定データ記憶手段８２（図１参照）に記憶させる。そして、５月８日（月）の夜間バッチ処理で、約定データ連携手段７２により、約定データ記憶手段８２（図１参照）に記憶されている約定データを、通信回線２を介してファンドラップシステム１０へ送信する。
それから、売買システム７０では、５月８日（月）の夜間バッチ処理で、約定処理手段２９により、通信回線２を介して売買システム７０から送信されてきてファンドラップシステム１０の約定データ記憶手段（不図示）に記憶されている約定データ（注文番号、銘柄コード（銘柄識別情報）、約定数量（口数）、売買区分（売・買の別）、約定時の基準価額、顧客の口座番号（顧客識別情報）等を含む）を取得し、注文データ記憶手段５４（図１１参照）に記憶されている注文データ（約定データと同一の注文番号の注文データ）のステータスを「約定済」に更新する処理を実行する。
なお、図１８での図示は省略されているが、５月２日（火）以降においても、前述したステップＳ４，Ｓ６の注文作成手段２５による処理と同様な処理、および前述したステップＳ５，Ｓ７の日付算出手段２６による処理と同様な処理は、全ての運用口について、毎営業日に行われる。また、スタイル変更以外のイベントにも着目すれば、前述したステップＳ３のイベント反映手段２４による処理に相当する処理も、全ての運用口について、毎営業日に行われる。
この際、スタイル変更に伴う売注文については、５月２日（火）以降は、注文管理記憶手段５２（図１０参照）に記憶されている売買ステータスが「注文データ作成済の状態」になっているので、注文作成手段２５による注文データ作成タイミング判断処理の対象外となる。
また、スタイル変更に伴う売注文の最遅約定日である５月８日（月）以降における日付算出手段２６による処理では、日付の算出対象銘柄は、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄ではなく、原則通り、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている当該運用口の各構成銘柄とする。従って、図１６の例で、日付の算出対象銘柄を、例外的に、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄とするのは、スタイル変更のバッチ反映日である月末営業日（４月２８日（金））から、スタイル変更に伴う売注文の最遅約定日の前営業日（５月２日（火））までである。
図１７には、４月中にスタイル変更（銘柄Ａ，Ｂ，Ｃから銘柄Ａ，Ｂ，Ｄへの変更）のイベントが申し込まれ、その後、スタイル変更の買注文の注文データ作成後のホールド期間中の５月９日（木）に、減額のイベントが申し込まれた場合の４月の月末前後の処理内容が示されている。この例は、日付算出手段２６による処理において、日付の算出対象銘柄を、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄だけとすると、不都合が生じることを示すものである。すなわち、原則通り、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている当該運用口の各構成銘柄を選択する場合と、例外的に、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄を選択する場合とを組み合わせる必要があることを示している。
この図１７の例は、図１６の例とは異なり、申込月の月末営業日（４月２８日（金））の翌営業日（５月１日（月））が海外休場日に該当する銘柄はないという前提であるため、スタイル変更の売注文の注文データの作成待機はないものとし、月末営業日（４月２８日（金））に、売注文の注文データが作成されるものとする。従って、図１８のステップＳ３の月末営業日（４月２８日（金））の夜間バッチ処理では、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）のスタイル変更イベントのレコードに、売注文の注文日として、翌営業日（５月１日（月））が記憶される。
月末営業日（４月２８日（金））の夜間バッチ処理で、注文作成手段２５により、売注文の注文データが作成されると、この売注文による約定ベースホールド期間が設定され、この売注文が約定するまで（複数銘柄の売注文がある場合には、最遅約定日まで）、同一銘柄についての売買注文の注文データ作成が制限される。このスタイル変更に伴う売注文による約定ベースホールド期間は、注文作成手段２５により設定され、運用口記憶手段４３（図３参照）にその設定情報が記憶される。
注文データ作成日の翌営業日（５月１日（月））の夜間バッチ処理で、注文データ連携手段２８により、注文データ記憶手段５４（図１１参照）に記憶されている売注文の注文データが、通信回線２を介して売買システム７０へ送信されて売注文が行われ、５月２日（火）に、通信回線２を介して売買システム７０から売注文の約定データ（注文番号、銘柄コード（銘柄識別情報）、約定数量（口数）、売買区分（売・買の別）、約定時の基準価額、顧客の口座番号（顧客識別情報）等を含む）が送信されてくるので、約定処理手段２９により、この売注文の約定データを取得して約定処理を行う。従って、５月２日（火）が売注文の最遅約定日となる。
５月２日（火）に売注文の約定データを取得して約定処理を行うと、売注文による約定ベースホールド期間が終了するので、翌営業日（５月８日（月））が海外休場日に該当する銘柄を有していなければ、５月２日（火）の夜間バッチ処理で、注文作成手段２５により、買注文の注文データが作成される。そして、注文作成手段２５により、買注文による約定ベースホールド期間が設定され、運用口記憶手段４３（図３参照）にその設定情報が記憶される。
続いて、５月８日（月）の夜間バッチ処理で、注文データ連携手段２８により、注文データ記憶手段５４（図１１参照）に記憶されている買注文の注文データが、通信回線２を介して売買システム７０へ送信されて買注文が行われる。その後、５月９日（火）の夜間バッチ処理で、通信回線２を介して売買システム７０から買注文の約定データ（注文番号、銘柄コード（銘柄識別情報）、約定数量（口数）、売買区分（売・買の別）、約定時の基準価額、顧客の口座番号（顧客識別情報）等を含む）が送信されてくるので、約定処理手段２９により、この買注文の約定データを取得して約定処理を行う。従って、５月９日（火）が買注文の最遅約定日となる。
また、スタイル変更に伴う買注文による約定ベースホールド期間中、例えば、５月９日（火）の日中に、減額イベントの申込があると、スタイル変更に伴う買注文による約定ベースホールド期間の終了後に、減額イベントの売注文の注文データ作成が可能となるので、翌営業日（５月１０日（水））が海外休場日に該当する銘柄を有していなければ、５月９日（火）の夜間バッチ処理で、注文作成手段２５により、減額イベントの売注文の注文データが作成される。また、減額イベントの売注文の注文データを含む注文明細も作成される。
この際、減額イベントの申込は、スタイル変更に伴う買注文による約定ベースホールド期間中である５月９日（火）の日中に行われているので、５月９日（火）の夜間バッチ処理で、減額イベントの売注文の注文明細に記載される日付は、スタイル変更後の銘柄構成状態である銘柄Ａ，Ｂ，Ｄを算出対象銘柄として算出された日付であるべきである。そして、この日付は、減額イベントの売注文の注文データおよび注文明細の作成日の前営業日（５月８日（月））の夜間バッチ処理で、日付算出手段２６により算出されて算出日付記憶手段６１（図１４参照）に記憶されている日付である。
しかし、５月８日（月）において、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄は、銘柄Ａ，Ｂ，Ｄではなく、銘柄Ａ，Ｂの状態（銘柄Ａ，Ｂ，Ｃの状態から、銘柄Ｃの全口数が売却されて約定した状態）であるため、これを算出対象銘柄とすることは不適切である。５月９日（火）に、注文明細の作成に必要な銘柄Ｄの日付が存在しない状態となってしまうからである。
そこで、日付算出手段２６は、５月８日（月）における算出対象銘柄は、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄（銘柄Ａ，Ｂ）ではなく、原則通り、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている当該運用口の各構成銘柄（銘柄Ａ，Ｂ，Ｄ）とする。この状態は、５月２日（火）に、スタイル変更の売注文の約定で、残高記憶手段６０（図１４参照）の保有銘柄が、銘柄Ａ，Ｂ，Ｃの状態から、銘柄Ａ，Ｂの状態になることにより生じるので、日付の算出対象銘柄を、例外的に、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄とするのは、スタイル変更の売注文の最遅約定日の前営業日（５月１日（月））までとし、スタイル変更の売注文の最遅約定日（５月２日（火））からは、原則通り、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている当該運用口の各構成銘柄とする。
なお、従来システムでは、図２４を用いて既に詳述したように、スタイル変更の売注文について、本発明のような注文データ作成待機という状態がなく、翌営業日に注文できるか否かにかかわらず、月末営業日に売注文の注文データが作成されていたので、運用口銘柄構成記憶手段に記憶されている構成銘柄を日付の算出対象銘柄としていればよかったことから、そもそも上記のような問題は生じなかった。
＜金銭振替明細の作成：図１９〜図２３／本実施形態の説明（図１９、図２２、図２３参照）＞
図１９には、５月３１日（水）に定期受取イベント（狭義）が発生し（ここでいう発生とは、定期受取判定結果が、当月に定期受取に伴う売却注文データを作成するという結果となった場合を意味する。）、６月１日（木）に運用口削除の申込を行なった場合の処理内容が示されている。６月１日（木）が海外休場日となる銘柄を保有している前提である。なお、図２０および図２１は、比較参照のために記載した処理内容であり、本発明のファンドラップシステム１０による処理ではない。
図２２において、イベント記憶手段４９（図７参照）に定期受取イベント（狭義）のレコードが作成されているものとすると、月末営業日（５月３１日（水））には、イベント準備手段２２によるイベント準備処理が実行される（ステップＳ１１）。すなわち、イベント記憶手段４９（図７参照）に記憶された定期受取判定年月日（本実施形態では、月末営業日が設定される）になった場合に、イベント準備手段２２により、定期受取の実施判定を実行し、定期受取を実施すると判定した場合には、イベント記憶手段４９の定期受取のレコードに、定期受取判定結果として、売注文の注文データを「作成する」という判定結果を記憶させる。
続いて、イベント反映手段２４によるイベント反映処理を実行する（図２２のステップＳ１２）。すなわち、イベント反映手段２４により、イベント記憶手段４９（図７参照）の定期受取のレコードに記憶された定期受取判定結果が売注文の注文データを「作成する」になっている場合には、そのレコードのイベントステータスを「申請中」から「成立」に更新する。
また、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に、定期受取のレコードを作成する。この際、作成したレコードには、翌営業日（６月１日（木））ではなく、海外休業日を考慮して決定された注文日（６月２日（金））を記憶させる。さらに、イベント反映手段２４により、定期受取明細を作成し、定期受取明細記憶手段５５（図１２参照）に記憶させる。
それから、注文作成手段２５による処理（ここでは、定期受取の売注文に関する処理）を実行する（図２２のステップＳ１３）。先ず、注文作成手段２５により、定期受取の売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する。この際、翌営業日（ここでは６月１日（木））が、注文管理記憶手段５２（図１０参照）に記憶されている注文日（６月２日（金））と一致するか否かを判断する。
ここで、翌営業日（ここでは６月１日（木））が注文日（６月２日（金））と一致した場合（注文作成条件を満たした場合）には、注文明細記憶手段５３（図１１参照）に定期受取の売注文の注文明細のレコードを作成するとともに、定期受取の売注文の注文データを作成して注文データ記憶手段５４（図１１参照）に記憶させる。この際、注文明細に記憶させる日付（注文日、約定日、受渡日、あるいは最遅約定日や最遅受渡日）は、前営業日（５月３０日（火））に日付算出手段２６により算出されて算出日付記憶手段６１（図１４参照）に記憶されている日付を用いる。
一方、翌営業日（ここでは６月１日（木））が注文日（６月２日（金））と一致しなかった場合（注文作成条件を満たさなかった場合）には、定期受取に伴う売注文の注文データの作成を待機する。従って、図１９の例では、一致しないので、注文データ作成待機となる。但し、定期受取判定結果は、当月に定期受取に伴う売却注文データを作成するという判定結果となっているので、定期受取明細は作成し、定期受取明細記憶手段５５（図１２参照）に記憶させる。
その後、６月１日（木）の日中に、運用口削除の申込があった場合には、設定受付手段２１により、この運用口削除イベントの申込を受け付け、イベント記憶手段４９（図７参照）に運用口削除イベントのレコードを作成する（図２２のステップＳ１４）。
それから、６月１日（木）の夜間バッチ処理で、イベント反映手段２４によるイベント反映処理を実行する（図２３のステップＳ１５）。すなわち、イベント反映手段２４により、イベント記憶手段４９（図７参照）の運用口削除イベントのレコードのイベントステータスを「申請中」から「成立」に更新する。
また、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）に、運用口削除のレコードを作成する。この際、作成したレコードには、注文日（６月２日（金））を記憶させる。
さらに、イベント反映手段２４により、注文管理記憶手段５２（図１０参照）の定期受取のレコードの抹消フラグを「抹消」に更新して抹消扱いとする。定期受取の売注文は、注文管理記憶手段５２（図１０参照）の定期受取のレコードに記憶されている売買ステータス（注文データ作成の状態）が「売却の注文データの作成が必要な状態」となっているので、注文データ作成待機中の状態であるが、その状態において、運用口削除イベントが発生しているので、抹消扱いとする。従って、定期受取の売注文の注文データの作成は行わない。運用口削除イベントは、削除対象の運用口の全保有銘柄の全残高数量（全口数）を売却する処理であるため、運用口削除の売注文で、まとめて売却するためである。なお、注文管理記憶手段５２（図１０参照）において売買ステータス（注文データ作成の状態）が「売却の注文データの作成が必要な状態」となっているレコードが、定期受取等のような売注文を伴う月末イベントのレコードであるか否かは、注文管理記憶手段５２の当該レコードに記憶されている注文データ作成イベント番号を用いて、イベント記憶手段４９（図７参照）において同じイベント番号のレコードに記憶されているイベント区分を参照することにより判別することができる。
続いて、６月１日（木）の夜間バッチ処理では、注文作成手段２５による処理（ここでは、運用口削除の売注文に関する処理）を実行する（図２３のステップＳ１６）。先ず、注文作成手段２５により、運用口削除の売注文の注文データを作成するか、作成を待機するかを判断する注文データ作成タイミング判断処理を実行する。この際、翌営業日（ここでは６月２日（金））が、注文管理記憶手段５２（図１０参照）に記憶されている注文日（６月２日（金））と一致するか否かを判断する。図１９の例では、一致する。
ここで、翌営業日（ここでは６月２日（金））が注文日（６月２日（金））と一致した場合（注文作成条件を満たした場合）には、注文明細記憶手段５３（図１１参照）に運用口削除の売注文の注文明細のレコードを作成するとともに、運用口削除の売注文の注文データを作成して注文データ記憶手段５４（図１１参照）に記憶させる。この際、注文明細に記憶させる日付（注文日、約定日、受渡日、あるいは最遅約定日や最遅受渡日）は、前営業日（５月３１日（水））に日付算出手段２６により算出されて算出日付記憶手段６１（図１４参照）に記憶されている日付を用いる。また、運用口削除イベントは、削除対象の運用口の全保有銘柄の全残高数量（全口数）を売却する処理であるため、運用口削除の売注文の注文データにおける売却数量（売却金額）は、全数量（全口数）とする。図１９の例では、注文データ作成時点（６月１日（木）の時点）で残高記憶手段６０（図１４参照）に記憶されている残高数量（口数）の評価金額は、１，０００万円であるので、その全数量（全金額）が、運用口削除の売注文の注文データにおける売却数量（売却金額）となる。従って、この売注文の注文データには、抹消扱いとした定期受取の分、すなわち運用口削除の申込が無ければ定期受取の売注文で売却するはずであった数量分（金額分）も含まれることになる。
一方、翌営業日（ここでは６月２日（金））が注文日（６月２日（金））と一致しなかった場合（注文作成条件を満たさなかった場合）には、運用口削除の売注文の注文データの作成を待機する。
それから、６月２日（金）の夜間バッチ処理で、注文データ連携手段２８により、注文データ記憶手段５４（図１１参照）に記憶されている運用口削除の売注文の注文データが、通信回線２を介して売買システム７０へ送信されて売注文が行われ（図２３のステップＳ１７）、６月５日（月）に、通信回線２を介して売買システム７０から運用口削除の売注文の約定データ（注文番号、銘柄コード（銘柄識別情報）、約定数量（口数）、売買区分（売・買の別）、約定時の基準価額、顧客の口座番号（顧客識別情報）等を含む）が送信されてくるので、約定処理手段２９により、この運用口削除の売注文の約定データを取得して約定処理を行う。
従って、６月５日（月）が運用口削除の売注文の最遅約定日となるので、この約定を受けて、残高記憶手段６０（図１４参照）に記憶されていた各保有銘柄の残高数量（口数）の評価金額の１，０００万円は、６月５日（月）の夜間バッチ処理で０円となる。一方、金銭残高記憶手段４４（図４参照）に記憶されている金銭残高は、１，０００万円となる。この１，０００万円の内訳は、抹消扱いとした定期受取により得られるはずであった売却金額分の１００万円と、運用口削除による売却金額分の９００万円とである。つまり、運用口削除の売注文の約定金額には、抹消扱いとした定期受取により得られるはずであった売却金額分が含まれており、運用口削除の売注文は、本来の定期受取の売注文（運用口削除の申込が無かったとした場合の定期受取の売注文）と、本来の運用口削除の売注文（定期受取の売注文を行ったとした場合におけるその後の運用口削除の売注文）とを、まとめた状態となっている。なお、１００万円は、運用口記憶手段４３（図３参照）に記憶されている定期受取指定金額である。
さらに、６月５日（月）の夜間バッチ処理では、金銭振替手段３１による金銭振替処理を実行する（図２３のステップＳ１８）。すなわち、金銭振替手段３１により、売買システム７０との間で、定期受取の分を含めた運用口削除の金額（１，０００万円）の金銭振替を行う。運用口削除の売注文の約定時には、約定金額の全額を、売買システム７０へ送金するようになっているからである。これにより、１，０００万円の金銭振替金額データが、通信回線２を介して売買システム７０へ送信される。売買システム７０では、売買システム側金銭振替手段７３により、この１，０００万円の金銭振替金額データを受信して顧客の主口座への振替が行われ、主口座の金銭残高が１，０００万円増加する。
また、金銭振替手段３１により、定期受取の金銭振替明細（金銭振替金額＝１００万円）を作成するとともに、運用口削除の金銭振替明細（金銭振替金額＝９００万円）を作成する。従って、運用口削除の金銭振替明細に記載する金額は、運用口削除の売注文の約定に伴って売買システム７０へ送信した金銭振替金額１，０００万円から、定期受取（売注文を伴う月末イベント）の金銭振替明細に記載する金額１００万円を差し引いた金額とする。
この処理により、定期受取は、抹消扱いとされ、定期受取の売注文の注文データは作成されず、運用口削除の売注文の注文データに、まとめられた状態となるのに対し、金銭振替明細については、定期受取と、運用口削除とで別々のものが作成されることになる。換言すれば、売注文の注文データ作成については、定期受取と運用口削除とが１本化されて金額が１，０００万円とされ、売買システム７０との間の金銭振替処理（基幹システム側の主口座への入金処理）についても、１本化されて金額が１，０００万円とされるのに対し、金銭振替明細については、別々に作成されて金額が１００万円と９００万円になる。従って、通常は、金銭振替処理と、その金銭振替明細の作成処理とが、１対１の関係となるのに対し、１対２の関係となっている。このため、抹消扱いとされた定期受取についても金銭振替明細が作成されるので、顧客との契約に基づき行った定期受取判定処理で、一旦、当月に定期受取の売却注文データを作成するという判定結果が出たにもかかわらず、定期受取が実施されたことになっていないという事態を回避することができる。
＜金銭振替明細の作成：図１９〜図２３／従来システムとの比較（図２５参照）および課題の説明（図２０、図２１参照）＞
なお、従来システムでは、図２５を用いて既に詳述したように、定期受取の売注文の注文データは、翌営業日（６月１日（木））が注文できる日であるか否かにかかわらず、月末営業日（５月３１日（水））に作成していたので、そもそも注文データ作成待機中という状態がないことから、定期受取の売注文の注文データ作成待機中に、運用口削除の申込が行われるという事態は生じなかった。換言すれば、定期受取の売注文の注文データは、月末営業日（５月３１日（水））に作成され、それによるホールド期間が設定されるので、その後に、運用口削除の申込があっても、運用口削除の売注文の注文データは、ホールド期間の終了後に作成されるため、定期受取と運用口削除との間で、売注文の注文データ、金銭振替処理、および金銭振替明細の作成処理が交錯するような事態は生じなかった。従って、上述したような本実施形態のファンドラップシステム１０で生じる課題は、従来システムでは発生する余地がなかった。本発明では、顧客と契約した運用スタイルに沿った目的（所望）のポートフォリオに、より一層近づけるために、注文データ作成待機を行う構成としたので、それに伴って生じる課題を解決していることになる。以下では、図２０および図２１を用いて、その課題を説明する。
図２０に示された比較参照用処理（１）は、［Ａ］翌営業日が実際に注文することができない日である場合に、注文データの作成を待機する処理と、［Ｂ］運用口削除が申し込まれたタイミングで、注文データ作成待機中のイベントが存在した場合に、待機中のイベントを抹消扱いとする処理とを適用した場合である。上述したように、［Ａ］は、目的のポートフォリオに近づけるために採用した処理であるが、［Ａ］の処理を行うことを前提として、［Ｂ］の処理を行うようにした結果、次のような課題が生じる。
図２０において、５月３１日（水）の夜間バッチ処理では、翌営業日（６月１日（木））が海外休場日の銘柄があるため、定期受取の売注文の注文データ作成が待機となり、ホールド期間は設定されない。［Ａ］の処理を採用したためであり、この点が、前述した図２５の従来システムの場合と異なる。そして、ホールド期間未設定のため、運用口削除の申込の当日（６月１日（木））に、運用口削除の売注文の注文データが作成される。
運用口削除イベントでは、削除対象の運用口の全保有銘柄の全数量（全口数）を売却する。従って、運用口削除の申込があり、かつ、定期受取の売注文の注文データが未だ作成されていない状態である場合には、［Ｂ］の処理を採用するので、定期受取のイベントは抹消扱いとなり、定期受取の売注文の注文データ作成は行われない。運用口削除の売注文として、まとめて売注文の注文データを作成することになる。
これにより、定期受取は、顧客との契約に基づき実施判定を行い、一旦、実施するという判定結果が出ているにもかかわらず、運用口削除の申込により定期受取のイベントが抹消扱いとなり、定期受取の売注文の注文データ作成が行われず、定期受取の金銭振替処理やその金銭振替明細の作成処理も行われなくなってしまう。このため、顧客との契約内容を忠実に履行するという観点では好ましくない。
図２１に示された比較参照用処理（２）は、上述した［Ａ］および［Ｂ］の処理に対し、さらに、［Ｃ］注文データ作成待機中のイベントは抹消扱いとするが、金銭振替は行う処理を適用した場合であり、次のような課題が生じる。
図２１において、６月５日（月）の夜間バッチ処理では、運用口削除の売注文の最遅約定日になったので、約定処理が行われ、投資信託の各保有銘柄の残高数量（口数）についての評価金額１，０００万円は、０円となり、一方、金銭残高は、１，０００万円になる。そして、売買システム（基幹システム）の主口座への金銭振替処理が行われ、運用口削除の金銭振替明細が作成されるが、運用口削除の売注文の約定金額の全額の金銭振替となるため、この金銭振替明細に記載される金銭振替金額は、１，０００万円である。
一方、［Ｃ］の処理を採用したので、定期受取（売注文を伴う月末イベント）の注文データ作成は行わないが、金銭振替は行うことになるため、１００万円（運用口記憶手段４３（図３参照）に記憶されている定期受取指定金額）について、売買システム（基幹システム）の主口座への金銭振替処理が行われ、定期受取の金銭振替明細が作成される。この金銭振替明細に記載される金銭振替金額は、１００万円である。
従って、６月５日（月）の運用口削除の売注文の約定により金銭残高が１，０００万円となっているが、この金銭残高１，０００万円に対し、合計で１，１００万円の金銭振替処理（内訳：定期受取の金銭振替金額１００万円、運用口削除の金銭振替金額１，０００万円）が行われるので、６月６日（火）以降の金銭残高は、マイナス１００万円となってしまう。
以上のような図２０および図２１で示した課題を解消するために、本実施形態のファンドラップシステム１０では、前述した図１９で示される処理を実行する。
＜本実施形態の効果＞
このような本実施形態によれば、次のような効果がある。すなわち、ファンドラップシステム１０では、営業日（国内営業日）であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報が、注文可否日記憶手段５７（図１４参照）に記憶され、この情報を用いて決定された注文日が、イベント反映手段２４による注文管理処理で、注文管理記憶手段５２（図１０参照）に記憶され、注文作成手段２５による注文データ作成タイミング判断処理で、注文管理記憶手段５２に記憶されている注文日を用いて、判断時点の日に注文データを作成するか、または作成を待機するかを判断するので、注文データ作成日と注文日とを近づけることができる。このため、注文データ作成時の評価金額と、注文約定時の評価金額との差異を小さくすることができ、適切な売買金額を含む注文データを作成することができるので、従来システムに比べ、運用スタイルに沿ったポートフォリオを、より一層適切に維持することができる。
また、上記のように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、注文明細を作成することができなくなる事態が生じる。すなわち、注文明細の作成には、売買金額を含む注文データの他に、注文管理上の日付（注文日、約定日、受渡日）が必要となるが、スタイル変更のイベントまたは投資対象銘柄変更のイベントが発生し、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口（イベントの対象となる運用口）の各構成銘柄が変更されてしまうと、日付算出手段２６により、注文明細の作成に必要な日付が算出されていないという事態が生じる。この事態の発生状況の詳細については、図１６を用いて既に詳述しているので、ここでは詳しい説明を省略する。
これに対し、ファンドラップシステム１０では、スタイル変更や投資対象銘柄変更のイベントの発生状況や注文の進行状況に応じ、日付算出手段２６による日付の算出対象銘柄を、運用口銘柄構成記憶手段５９（図１４参照）に記憶されている運用口の各構成銘柄、または、残高記憶手段６０（図１４参照）に記憶されている当該運用口の残高数量がゼロでない各保有銘柄のいずれかから選択するようにしたので、上述したような注文明細の作成に必要な日付が算出されていないという事態を回避することができる。
さらに、前述したように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、顧客との契約上、必要となる金銭振替明細を作成することができなくなる事態が生じる場合がある。すなわち、定期受取や寄附等の月末イベントは、顧客との契約に基づき、条件を満たしたら実施し、売注文を行うべきイベントであるが、ファンドラップシステム１０では、このような月末イベントが発生し、注文データの作成が待機状態となっている最中に、運用口削除が申し込まれる場合が考えられ、この場合に、運用口削除の申込により、定期受取等の月末イベントを抹消扱いとし、それ以降の処理を行わないことにすると、注文データの作成、注文、金銭振替明細の作成の各処理が行われないことになってしまう。定期受取や寄附等は、顧客との契約に従って実施されるものであるので、一旦、実施するという判定結果が出て、これらの月末イベントが発生したら、売注文を行い、金銭振替明細の作成も行うべきものであるため、好ましくない事態が生じることになる。運用口削除の申込は、定期受取や寄附等を実施するという判定結果が出た後に行われているからである。このような事態の発生の詳細については、図２０および図２１を用いて、既に詳述しているので、ここでは詳しい説明を省略する。
これに対し、ファンドラップシステム１０では、図１９に示すように、定期受取等の月末イベントについては、抹消扱いとし、売注文の注文データの作成は行わないようにするが、金銭振替明細は、運用口削除の申込が無ければ、本来得られるはずであった売却金額を含む状態で作成するようにする。一方、運用口削除のイベントについては、抹消扱いとした定期受取等の月末イベントの売注文の分を含めた状態の注文数量または注文金額を含む売注文の注文データを作成し、金銭振替明細の作成では、抹消扱いとした定期受取等の月末イベントの売注文により得られるはずであった売却金額を差し引いた金額を含む金銭振替明細を作成するようにする。このため、顧客との契約上、必要となる金銭振替明細を作成することができなくなるという問題を解消することができる。
また、前述したように注文データ作成タイミングを、実際の注文日に近づけるように変更した結果、リバランスについて従来通りの考え方を踏襲すると、不都合が生じる可能性がある。すなわち、予め定められた日（例えば、月末営業日）にリバランス判定処理を行い、リバランスの実施が必要であると判定されても、その日にリバランスのための注文データが作成されず、作成を待機する状態となる場合（例えば、翌月の月初営業日が海外休場日となる銘柄がある場合）があるので、従来通りの考え方を踏襲すると、それ以降で注文が可能になる日の前営業日（例えば、海外休場日となっている翌月の月初営業日、または翌月の月初営業日から海外休場日が２日以上連続している場合には、連続する海外休場日の最後の日）にリバランス判定処理を再度実行し、リバランス要の判定結果が出たときに、リバランスのための注文データの作成を行うことになる。しかし、リバランス判定処理は、顧客との契約で、予め定められた日（例えば、月末営業日）に運用スタイルに沿ったポートフォリオとなっているか否かを確認する処理であるため、リバランス判定処理の実行日が、予め定められた日（例えば、月末営業日）よりも後の日になってしまうことは好ましくない。
これに対し、ファンドラップシステム１０では、注文作成手段２５によるリバランスのための注文データの作成を、リバランス手段２３によるリバランスの実施の要否判定と切り離して行うので、注文データ作成待機に伴ってリバランス判定処理の実行日も、予め定められた日（例えば、月末営業日）よりも後の日になってしまうという事態を回避することができる。このため、予め定められた日におけるリバランス判定処理の実行を確保できるので、契約の忠実な履行を実現することができる。すなわち、ファンドラップシステム１０では、リバランス手段２３によるリバランス判定処理は、再実行することはなく、予め定められた日（例えば、月末営業日）に実行するだけとし、そのときのリバランス要の判定結果を受けて、注文作成手段２５による注文データ作成タイミング判断処理で注文作成条件を満たした場合に、リバランス実施の要否判定時点ではなく、注文データ作成タイミング判断時点での基準価額による評価金額を用いて注文データを作成する。なお、リバランス実施の要否判定時点からの基準価額の変動の大きさによっては、注文データ作成タイミング判断時点では、既にリバランスを実施しなくてもよい程に、ポートフォリオが所望の状態になっている場合もあり得るが、この場合でも、一旦、リバランス手段２３による判定処理でリバランスを実施するという判定結果が出ている以上、顧客との契約を忠実に履行するという観点で、注文作成手段２５により注文データを作成し、注文を行う。
また、従来システムでは、予め定められた日（例えば、月末営業日）にリバランス判定処理を行い、リバランス要の判定結果が出たら、その日に注文データを作成していたので、海外休場日等の介在により、注文データ作成日と実際の注文日とが離れてしまう場合があり、作成した注文データを用いて注文を行ったとしても、注文約定後の状態が、所望のポートフォリオまたはそれに近い状態になっていない場合も生じ得ることから、リバランス実施の効果が十分に得られない可能性もあった。つまり、注文に使用する注文データが、時間の経過により、リバランスの役に立たない状態になっている可能性もあった。これに対し、ファンドラップシステム１０では、注文データ作成日と注文日とを近づけることができるので、リバランス実施の効果が適切に得られる注文データを作成して注文を行うことができる。
＜変形の形態＞
なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。
例えば、前記実施形態では、図１６〜図１８を用いた各日付の算出対象銘柄の変更の説明は、スタイル変更イベントで説明されていたが、投資対象銘柄変更イベントでも同様である。
また、前記実施形態では、図１９〜図２３を用いた金銭振替明細の作成の説明は、定期受取イベント（狭義）と運用口削除イベントとが同時期に発生したケースで説明されていたが、寄附イベント（狭義）等の売注文を伴う月末イベントと運用口削除イベントとが同時期に発生したケースでも同様である。
以上のように、本発明のファンドラップシステムおよびプログラムは、例えば、投資信託を含む金融商品の売買を行う既設の売買システムと連携してファンドラップサービスを提供する場合等に用いるのに適している。
２ 通信回線
１０ ファンドラップシステム
２１ 設定受付手段
２２ イベント準備手段
２３ リバランス手段
２４ イベント反映手段
２５ 注文作成手段
２６ 日付算出手段
３１ 金銭振替手段
４４ 金銭残高記憶手段
４９ イベント記憶手段
５２ 注文管理記憶手段
５７ 注文可否日記憶手段
５８ 約定・受渡日数記憶手段
５９ 運用口銘柄構成記憶手段
６０ 残高記憶手段
６１ 算出日付記憶手段
７０ 売買システム

Claims (4)

  1. 顧客から預かった資産を顧客により選択された運用口毎の運用スタイルで運用する投資一任サービスとして、投資信託への投資を取り扱うファンドラップサービスを提供する処理を実行するコンピュータからなるファンドラップシステムであって、
    投資信託の売買について、営業日であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報を、投資信託の銘柄識別情報と関連付けて記憶する注文可否日記憶手段と、
    注文日から約定日までの日数、および注文日から受渡日までの日数を、投資信託の銘柄識別情報と関連付けて記憶する約定・受渡日数記憶手段と、
    顧客の運用口を構成する投資信託の各銘柄についての銘柄識別情報を、顧客識別情報および運用口識別情報と関連付けて記憶する運用口銘柄構成記憶手段と、
    顧客の保有する投資信託の残高数量を、銘柄識別情報、顧客識別情報、および運用口識別情報と関連付けて記憶する残高記憶手段と、
    前記運用口銘柄構成記憶手段に記憶されている運用口の各構成銘柄、または前記残高記憶手段に記憶されている当該運用口の残高数量がゼロでない各保有銘柄のいずれかから選択した日付の算出対象銘柄について、当該運用口の全ての銘柄について注文可能な日として前記注文可否日記憶手段に記憶されている日を、当該運用口の各銘柄に共通する注文日として決定し、決定した前記注文日に対応する約定日および受渡日を前記約定・受渡日数記憶手段に記憶された日数から算出するとともに、当該運用口の全ての前記算出対象銘柄についての前記約定日および前記受渡日から最遅約定日および最遅受渡日を求め、得られた前記注文日、前記約定日、および前記受渡日を、銘柄識別情報および運用口識別情報と関連付けて算出日付記憶手段に記憶させるとともに、得られた前記最遅約定日および前記最遅受渡日を、運用口識別情報と関連付けて前記算出日付記憶手段に記憶させる処理を毎営業日に実行する日付算出手段と、
    売買注文の作成を要するイベントが発生した場合に、当該イベントの発生時点で前記算出日付記憶手段に記憶されている前記注文日、前記最遅約定日、および前記最遅受渡日を、当該イベントについてのイベント番号、顧客識別情報、および運用口識別情報と関連付けて注文管理記憶手段に記憶させる注文管理処理を実行するイベント反映手段と、
    前記注文管理記憶手段に記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、イベント発生以降の毎営業日に実行し、注文データを作成すると判断した場合に、当該判断時点で前記算出日付記憶手段に記憶されている注文日、約定日、および受渡日を用いてこれらの日付および注文データを含む注文明細を作成し、作成した前記注文明細を、顧客識別情報および運用口識別情報と関連付けて注文明細記憶手段に記憶させる注文明細作成処理を実行する注文作成手段とを備え、
    前記イベント反映手段は、
    運用スタイルを変更するスタイル変更のイベント、または、運用スタイルを構成する資産クラス内の銘柄を変更する投資対象銘柄変更のイベントが発生した場合には、前記運用口銘柄構成記憶手段に記憶されている当該運用口の各構成銘柄を、変更後の銘柄に更新する銘柄変更処理も実行する構成とされ、
    前記日付算出手段は、
    前記注文管理記憶手段に記憶されている前記イベント番号および前記最遅約定日を用いて、前記スタイル変更のイベントまたは前記投資対象銘柄変更のイベントが発生し、かつ、前記スタイル変更または前記投資対象銘柄変更による売注文の最遅約定日よりも前の日であると判断した場合には、前記残高記憶手段に記憶されている当該運用口の残高数量がゼロでない各保有銘柄を、前記算出対象銘柄として選択し、それ以外の場合には、前記運用口銘柄構成記憶手段に記憶されている当該運用口の各構成銘柄を、前記算出対象銘柄として選択する処理を実行する構成とされている
    ことを特徴とするファンドラップシステム。
  2. 顧客から預かった資産を顧客により選択された運用口毎の運用スタイルで運用する投資一任サービスとして、投資信託への投資を取り扱うファンドラップサービスを提供する処理を実行するコンピュータからなるファンドラップシステムであって、
    投資信託の売買について、営業日であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報を、投資信託の銘柄識別情報と関連付けて記憶する注文可否日記憶手段と、
    顧客の金銭残高を、顧客識別情報と関連付けて記憶する金銭残高記憶手段と、
    運用口削除またはその他のイベントの申込を受け付ける処理を実行する設定受付手段と、
    売買注文の作成を要するイベントが発生した場合に、前記注文可否日記憶手段に記憶された情報を用いて決定された当該イベントの売買注文についての注文日を、当該イベントについてのイベント番号、顧客識別情報、および運用口識別情報と関連付けて注文管理記憶手段に記憶させる注文管理処理を実行するとともに、前記設定受付手段により運用口削除のイベントの申込を受け付けた場合に、前記注文管理記憶手段に記憶されている注文日を用いて注文データ作成待機中になっている別のイベントの有無を判断し、注文データ作成待機中になっている別のイベントがあった場合に、当該別のイベントを抹消扱いとするイベント抹消処理を実行するイベント反映手段と、
    抹消扱いとなっていないイベントの売買注文について、前記注文管理記憶手段に記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、抹消扱いとなっていないイベント発生以降の毎営業日に実行し、注文データを作成すると判断した場合に、注文データを含む注文明細を作成し、作成した前記注文明細を、顧客識別情報および運用口識別情報と関連付けて注文明細記憶手段に記憶させる注文明細作成処理を実行する注文作成手段と、
    前記金銭残高記憶手段に記憶された金銭残高について通信回線で接続された売買システムまたは他のシステムとの間で金銭振替処理を実行するとともに、金銭振替金額を含む金銭振替明細を作成する金銭振替明細作成処理を実行する金銭振替手段とを備え、
    前記注文作成手段は、
    運用口削除のイベントの申込があり、定期受取、寄附、またはその他の売注文を伴う月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文の注文データを作成する際には、抹消扱いとした前記月末イベントの売注文の分を含めた状態の数量または金額を、運用口削除の売注文の注文数量または注文金額とする処理を実行する構成とされ、
    前記金銭振替手段は、
    運用口削除のイベントの申込があり、前記月末イベントが抹消扱いとなっていた場合に、運用口削除の売注文の約定に伴って前記金銭残高記憶手段に記憶された金銭残高の全額を金銭振替金額とする金銭振替処理を実行するとともに、抹消扱いとした前記月末イベントの売注文により得られるはずであった売却金額を含む定期受取の金銭振替明細、および、前記金銭振替金額から前記月末イベントの売注文により得られるはずであった売却金額を差し引いた金額を含む運用口削除の金銭振替明細を作成する処理を実行する構成とされている
    ことを特徴とするファンドラップシステム。
  3. 顧客から預かった資産を顧客により選択された運用口毎の運用スタイルで運用する投資一任サービスとして、投資信託への投資を取り扱うファンドラップサービスを提供する処理を実行するコンピュータからなるファンドラップシステムであって、
    投資信託の売買について、営業日であるか否か以外の要素を加味して得られる注文可能な日であるか否かの情報を、投資信託の銘柄識別情報と関連付けて記憶する注文可否日記憶手段と、
    投資信託の基準価額を、投資信託の銘柄識別情報と関連付けて記憶する単価情報記憶手段と、
    顧客の保有する投資信託の残高数量を、銘柄識別情報、顧客識別情報、および運用口識別情報と関連付けて記憶する残高記憶手段と、
    リバランス実施判定年月日になった場合に、前記残高記憶手段に記憶された運用口の各保有銘柄の残高数量についてのリバランス判定時点での基準価額による評価金額、運用口銘柄構成記憶手段および運用スタイル・資産クラス構成記憶手段に記憶されている設定構成比率、並びに、契約記憶手段に記憶されているリバランス判定基準乖離率を用いて、リバランスの実施の要否を判定するリバランス判定処理を実行するリバランス手段と、
    このリバランス手段によりリバランスの実施が必要であると判定された場合、または売買注文の作成を要するその他のイベントが発生した場合に、前記注文可否日記憶手段に記憶された情報を用いて決定された当該リバランスまたはその他のイベントの売買注文についての注文日を、当該リバランスまたはその他のイベントについてのイベント番号、顧客識別情報、および運用口識別情報と関連付けて注文管理記憶手段に記憶させる注文管理処理を実行するイベント反映手段と、
    リバランスまたはその他のイベントの売買注文について、前記注文管理記憶手段に記憶されている注文日を用いて、この注文日と判断時点の日との関係が予め定められた注文作成条件を満たすか否かにより、当該判断時点の日に注文データを作成するか、または作成を待機するかを判断する注文データ作成タイミング判断処理を、リバランスまたはその他のイベント発生以降の毎営業日に実行し、注文データを作成すると判断した場合に、注文データを含む注文明細を作成し、作成した前記注文明細を、顧客識別情報および運用口識別情報と関連付けて注文明細記憶手段に記憶させる注文明細作成処理を実行する注文作成手段とを備え、
    前記注文作成手段は、
    リバランスのイベントについては、前記残高記憶手段に記憶された運用口の各保有銘柄の残高数量についての注文データ作成タイミング判断時点での基準価額による評価金額、並びに、運用口銘柄構成記憶手段および運用スタイル・資産クラス構成記憶手段に記憶されている設定構成比率を用いて、リバランスの売買注文の注文数量または注文金額を算出して注文データを含む注文明細を作成し、作成した前記注文明細を、顧客識別情報および運用口識別情報と関連付けて前記注文明細記憶手段に記憶させる注文明細作成処理を実行する構成とされている
    ことを特徴とするファンドラップシステム。
  4. 請求項１〜３のいずれかに記載のファンドラップシステムとして、コンピュータを機能させるためのプログラム。
JP2019000902A 2019-01-07 2019-01-07 ファンドラップシステムおよびプログラム Active JP6738914B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2019000902A JP6738914B2 (ja) 2019-01-07 2019-01-07 ファンドラップシステムおよびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019000902A JP6738914B2 (ja) 2019-01-07 2019-01-07 ファンドラップシステムおよびプログラム

Publications (2)

Publication Number Publication Date
JP2020112842A JP2020112842A (ja) 2020-07-27
JP6738914B2 true JP6738914B2 (ja) 2020-08-12

Family

ID=71667004

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019000902A Active JP6738914B2 (ja) 2019-01-07 2019-01-07 ファンドラップシステムおよびプログラム

Country Status (1)

Country Link
JP (1) JP6738914B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6997477B1 (ja) * 2020-07-30 2022-01-17 株式会社スマートプラス プログラム、情報処理装置及び情報処理方法

Also Published As

Publication number Publication date
JP2020112842A (ja) 2020-07-27

Similar Documents

Publication Publication Date Title
US8260697B1 (en) Systems and methods for money fund banking with flexible interest allocation
US8204824B2 (en) System and method of account reconciliation for electronic transactions
US7509286B1 (en) Systems and methods for money fund banking with flexible interest allocation
US8239321B1 (en) System and method for allocation to obtain zero activity in one or more selected aggregated deposit accounts
US20070282724A1 (en) Asset based lending (abl) systems and methods
US20010054022A1 (en) Syndication loan administration and processing system
JPWO2004010356A1 (ja) 決済システム、決済装置、決済プログラム、および決済プログラム記憶媒体
US20130297486A1 (en) Hybrid installment-revolving credit method and system
JP5475386B2 (ja) 金融商品取引管理装置、プログラム
CN114331717B (zh) 交易风险控制方法、装置、计算机设备和存储介质
JP6738914B2 (ja) ファンドラップシステムおよびプログラム
JP4586185B2 (ja) 投資情報処理装置、システム、方法、プログラム及び投資情報処理システム用プログラム
US7856394B2 (en) Computer system and a method for managing a financial transaction
JP6563096B1 (ja) 積立残高管理システムおよびプログラム
JP7061992B2 (ja) 資産運用システムおよびプログラム
JP6795647B2 (ja) ファンドラップシステムおよびプログラム
JP6564118B1 (ja) 情報処理装置、情報処理方法および情報処理プログラム
JP6932684B2 (ja) 手数料算出システムおよびプログラム
JP7201728B2 (ja) 配当金再投資システムおよびプログラム
JP4605721B2 (ja) 投資情報処理装置、方法及びプログラム
JP7277677B1 (ja) 為替マッチング処理プログラム、為替マッチング処理方法、及び、為替マッチング処理システム
JP7302915B2 (ja) 金融商品取引管理装置、プログラム
JP6944667B1 (ja) 支援装置
JP2016170736A (ja) 金融商品売買注文システムおよびプログラム
JP6675966B2 (ja) 金融商品定期定額取引金額計算システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190311

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200713

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200720

R150 Certificate of patent or registration of utility model

Ref document number: 6738914

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250