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