JP2005227910A - 取引口座情報管理システム及び管理方法 - Google Patents
取引口座情報管理システム及び管理方法 Download PDFInfo
- Publication number
- JP2005227910A JP2005227910A JP2004034200A JP2004034200A JP2005227910A JP 2005227910 A JP2005227910 A JP 2005227910A JP 2004034200 A JP2004034200 A JP 2004034200A JP 2004034200 A JP2004034200 A JP 2004034200A JP 2005227910 A JP2005227910 A JP 2005227910A
- Authority
- JP
- Japan
- Prior art keywords
- identification information
- user identification
- transaction status
- user
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 30
- 239000000284 extract Substances 0.000 claims abstract description 4
- 238000007726 management method Methods 0.000 claims description 39
- 230000008859 change Effects 0.000 claims description 14
- 238000012545 processing Methods 0.000 abstract description 23
- 230000008569 process Effects 0.000 description 18
- 238000007596 consolidation process Methods 0.000 description 9
- 238000004364 calculation method Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 5
- 239000007788 liquid Substances 0.000 description 5
- 238000013500 data storage Methods 0.000 description 3
- 239000010931 gold Substances 0.000 description 3
- 229910052737 gold Inorganic materials 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000009825 accumulation Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000005406 washing Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000001771 impaired effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
【課題】 ネットバンキングにおいて、金融機関のコンピュータシステムやネットワークに過大な負荷をかけずに、口座情報の更新と取引状況の提供を迅速に行う。
【解決手段】 店舗番号及び顧客番号からなるユーザ識別情報のマスターデータ26aと、マスターデータ26aと同一の検索用データ26bとを関連付けて格納するユーザ識別情報格納部26と、取引口座の基礎情報28と当該口座の取引レコード29とを関連付けて格納する取引状況格納部27と、ユーザ識別情報を変更するイベントが発生した場合にマスターデータ26aを変更後のユーザ識別情報に更新するマスターデータ更新部35と、ユーザから取引状況の照会を受付けた場合に、ユーザ識別情報に基づいて検索用データ26bを抽出して取引状況格納部27から取引状況を検索してユーザに提供する取引状況照会処理部37とを備えた。
【選択図】 図2
【解決手段】 店舗番号及び顧客番号からなるユーザ識別情報のマスターデータ26aと、マスターデータ26aと同一の検索用データ26bとを関連付けて格納するユーザ識別情報格納部26と、取引口座の基礎情報28と当該口座の取引レコード29とを関連付けて格納する取引状況格納部27と、ユーザ識別情報を変更するイベントが発生した場合にマスターデータ26aを変更後のユーザ識別情報に更新するマスターデータ更新部35と、ユーザから取引状況の照会を受付けた場合に、ユーザ識別情報に基づいて検索用データ26bを抽出して取引状況格納部27から取引状況を検索してユーザに提供する取引状況照会処理部37とを備えた。
【選択図】 図2
Description
この発明は、インターネットなどのネットワークを通じて顧客の取引状況を提供するネットバンキングにおける口座情報の管理システム及び管理方法に関する。
近年、ADSL(Asymmetric Digital Subscriber Line)や光ファイバー網などの通信インフラの整備や、パーソナルコンピュータ(PC)や携帯電話を初めとする通信端末の普及に伴い、インターネットを利用した種々のサービスが広く普及してきている。その一例として、金融機関が提供するネットバンキングが挙げられる。ユーザは、自宅のPC等で金融機関のWEBサイトにアクセスしてネットバンキングを利用することで、24時間いつでも自己の銀行口座の残高や入出金履歴などの情報を確認したり、振込み依頼を行うことができる。また、金融機関にとっては、このネットバンキングは残高照会や振込みの処理等において支店窓口やATMで受付ける場合に比べて人的負荷やコストを格段に低減できるというメリットがある。
このようなネットバンキングにおける口座情報の管理方法として、例えば特許文献1に開示されている発明が参考となる。
特開2002−49746号公報
またネットバンキングにおいては、ユーザに過去の取引状況や過去の特定の時点における資産残高等(以下、「取引状況」と総称する)を提供するために、金融機関は各口座の所定期間の履歴情報や資産運用状況を蓄積している。この取引状況の蓄積期間は、従来は過去3ヶ月程度であったが、ユーザから「ネットバンキングにおいても前年の同時期の取引状況と比較したい」「まとまった期間で資産残高の推移を把握したい」といったニーズに応えるべく、過去12ヶ月間程度に延長されつつある。また、近年のユーザの投資性向の高まりや保有資産の分散ニーズに伴って、ユーザが保有する口座の種別も多様化してきている。例えば、普通預金などに加えて、投資信託や外貨預金などの取引口座を保有するユーザが増えてきている。
ところで、ネットバンキングでユーザに提供される取引状況の一部の情報は、金融機関の勘定系システムから1週間、1ヶ月などの所定期間内の取引履歴や月末等の時点における資産残高のファイルを切り出して集約・加工した上で取込んでいる。そして、ユーザから取引状況の照会があった場合に、このような取引状況のファイルから該当するデータを検索して提供するようにしている。これにより、勘定系システムにアクセスしなくてもネットバンキングシステムによってユーザに取引状況を提供することができるようにし、勘定系システムにアクセスが集中してサーバに過度の負荷がかかって本来の業務処理に支障が出ることを防止している。
ここで、金融機関において店舗を統廃合したり、引越しなどのユーザの都合によって口座を移管する場合、金融機関が管理するユーザ識別情報を変更する必要がある。このユーザ識別情報は、通常、管理する店舗の識別情報と顧客情報とから構成され、このユーザ識別情報にユーザが保有する1又は2以上の取引口座の番号が関連付けられて管理されている。
このような店舗の統廃合等に伴って、前記取引状況ファイルに蓄積している過去の取引状況のユーザ識別情報も同期を取って更新する必要が生じる。このようなユーザ識別情報の更新は、通常は休日深夜などのシステムのメンテナンス時に一括して実行される。
しかし、前記のように取引状況ファイルに蓄積する情報の蓄積期間が延長され、対象口座の数も増加しているため、更新の対象となる取引状況の情報量が膨大なものとなる。例えば、ユーザ毎の取引状況ファイルは、口座の科目や取引内容等に応じて20前後のテーブルに分割されて勘定系システムから取得して蓄積される。そのため、各テーブルに格納された全ての取引状況のレコードについて更新対象ユーザの取引であるかを判別し、対象ユーザの取引である場合にユーザ識別情報を更新する、という処理を全てのテーブルに対して繰り返し実行しなければならない。
このような取引状況の更新に要する処理時間を以下の条件で試算した。なお、複数のデータテーブル毎の顧客(契約者)数、更新対象件数等は、図6の上段に詳細に示している。
<試算条件>
・400店舗中、5店舗で統廃合発生
・サーバの処理能力は、10分当り2.5万件の取引状況レコードの更新可能
・各データテーブル毎に顧客1人当りのレコード数が異なる(1〜3件/人)
・12ヵ月分蓄積された取引状況を更新
<試算結果>
更新対象件数:データテーブル1の顧客数×(テーブル1の総レコード数÷顧客数)×12ヶ月×(5店舗÷400店舗)+データテーブル2の顧客数×…=約813万件
更新処理時間:813万件÷2.5万件×10分÷60分=約54時間
<試算条件>
・400店舗中、5店舗で統廃合発生
・サーバの処理能力は、10分当り2.5万件の取引状況レコードの更新可能
・各データテーブル毎に顧客1人当りのレコード数が異なる(1〜3件/人)
・12ヵ月分蓄積された取引状況を更新
<試算結果>
更新対象件数:データテーブル1の顧客数×(テーブル1の総レコード数÷顧客数)×12ヶ月×(5店舗÷400店舗)+データテーブル2の顧客数×…=約813万件
更新処理時間:813万件÷2.5万件×10分÷60分=約54時間
このように、取引履歴の更新に2日以上も要することになり、この間、金融機関はネットバンキングシステムにおける取引状況の照会サービスを停止若しくは制限する必要がある。
この点、上記した特許文献1には、本来の店舗番号(本籍店舗番号)とは別の管理店舗番号を導入し、これらの番号と口座番号及び取引レコード(入出金項目・入出金額・実行日)とを夫々紐付けしておくことが提案されている。この特許文献1では、店舗の統廃合等に際して、本籍店舗番号と管理店舗番号とが同一の場合には両方の番号を同時に更新し、これらの番号が異なる場合には本籍店舗番号だけを更新することにしている(請求項23、24)。
しかし、このような手法は、勘定系システムのマスターデータを更新する場合には採用できる余地があるとしても、ネットバンキングの取引状況の更新には応用できないものである。すなわち、特許文献1では、全ての取引状況を本籍店舗番号及び管理店舗番号に関連付けて蓄積しているため(図9参照)、これらの番号を変更する場合には、上記試算と同様に、膨大な時間を要することになる。また、マスターデータだけを随時更新しておき、取引状況(取引ログテーブル)は更新しないで、ユーザから取引履歴の照会があった場合にマスターデータにアクセスして更新後の履歴情報を検索することも考えられる。しかし、この場合には、勘定系システムへのアクセスが集中して業務処理に影響が出ると共に、照会の度にマスターデータにアクセスする工程が必要となり、取引状況の提供までに時間がかかってネットバンキングの利便性を損なうおそれがある。
本発明は上記の課題を解決するためになされたもので、金融機関のコンピュータシステムやネットワークに過大な負荷をかけずに、口座情報(ユーザ識別情報)の更新と取引状況の提供とを迅速に実行できる口座情報の管理システム及び管理方法を提供することを目的とする。
上述した課題を解決するために、本発明の第1の主要な観点によれば、ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報の管理システムであって、金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータと、このマスターデータと同一の検索用データとを関連付けて格納するユーザ識別情報格納手段と、前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して格納する取引状況格納手段と、前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納手段のマスターデータを更新するマスターデータ更新手段と、前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納手段から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納手段から収集しネットワークを通じて当該ユーザに提供する取引状況出力手段とを備えたことを特徴とする口座情報管理システムが提供される。
このような構成によれば、ネットバンキングシステムは、勘定系システムで管理しているユーザ識別情報とこのユーザ識別情報に関連付けられた取引状況とを取得し、ユーザ識別情報をマスターデータとして保持する。また、このマスターデータと同一の検索用データを格納しておく。店舗の統廃合等のイベントが発生したときには、マスターデータだけを変更し、検索用データは格納時のまま保持する。そして、ユーザから過去の取引状況の照会を受付けた時に、マスターデータではなく、検索用データで取引状況を検索・収集してユーザに提供する。これにより、ユーザ識別情報の変更前に勘定系システムから取得して保存しておいた取引状況の全てを更新しなくても過去の取引状況を収集でき、更新処理を短時間で行うことが可能になる。
すなわち、勘定系システムから取得した時点では、マスターデータとして登録するユーザ識別情報と、取引状況に含まれるユーザ識別情報と、マスターデータと同一の検索用データとは常に一致する。これは、前記イベントが発生して勘定系システムの顧客情報が更新された後でも同様である。そのため、イベント発生後にネットバンキングシステムのマスターデータを更新しても、過去の特定の時点で取得した取引状況に含まれるユーザ識別情報は検索用データによって検索することが可能になる。
また、本発明は、ネットバンキングシステムで蓄積しておいた過去の取引状況を検索用データに基づいて検索・収集できるので、ユーザから照会を受付ける度に勘定系システムにアクセスする必要がなく、サーバやネットワークへの負担を軽減できると共に、取引状況を迅速にユーザに提供できる。
ここで、本明細書において取引状況とは、普通預金口座(日本円、外貨)等の流動性預金口座における入出金の実行日や項目などの取引状況や、投資信託口座や金の取引口座等の資産管理口座における月末等の特定の時点における仮想資産残高・時価評価額などの、定期的にユーザに通知する口座情報の全てを含む概念である。
本発明の一の実施形態によれば、さらに、金融機関の上位システムから所定周期で前記ユーザ識別情報のレコードを取得し、このレコードを識別する情報に関連付けて前記ユーザ識別情報格納手段に格納するユーザ識別情報取得手段を備え、前記マスターデータ更新手段は、前記イベントが発生した場合に、ユーザ識別情報格納手段から更新対象となる1又は2以上のユーザ識別情報レコードを抽出し、抽出したユーザ識別情報レコードのマスターデータを変更後のユーザ市域別情報に更新するものである。
このような構成により、更新対象のユーザ識別情報のレコードを瞬時に特定できマスターデータの更新処理時間をより短縮できる。
本発明の他の実施形態によれば、前記ユーザ識別情報取得手段は、前記取引状況格納手段が取引状況を取得するタイミングで前記ユーザ識別情報のレコードを取得するものである。これにより、取引状況とユーザ識別情報とを紐付けて管理することが容易となる。
本発明の他の実施形態によれば、前記取引状況格納手段は、金融機関の上位システムから所定周期で取引口座の科目・取引内容に応じて複数のデータテーブルに分割された取引状況を取得してこの取引状況をテーブル毎に格納するものであり、前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記検索用データに基づいて前記複数のデータテーブル毎に取引状況を収集するものである。
このような構成により、取引状況の取得・管理(検索)を効率的に行え、取引状況の照会処理を短時間で行うことができる。
本発明の他の実施形態によれば、前記マスターデータ更新手段は、金融機関の上位システムがユーザ識別情報を更新するタイミングと異なるタイミングでマスターデータの更新を行うものである。これにより、上位システムの方で更新処理について十分な検証が行われた結果に基づいてユーザ識別情報を更新することができる。
本発明の他の実施形態によれば、前記ユーザ識別情報格納手段は、前記イベントに係るユーザについてイベント発生日を取得して格納するものであり、前記取引状況格納手段は、各口座に対して入出金が実行された日を含む取引状況を取得して格納するものであり、前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記ユーザ識別情報格納手段から当該ユーザのイベント発生日を特定し、前記収集した取引状況に含まれる入出金実行日と比較することによって、各取引がイベント発生日よりも前か後かを識別可能にして当該取引状況をユーザに提供するものである。
このような構成によれば、ユーザは、ユーザ識別情報(管理店舗)の変更前後の取引状況を容易に識別することができると共に、変更前後の口座が統一して管理されていることを確認できる。
また、本発明の第2の主要な観点によれば、ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報をコンピュータによって管理する方法であって、金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータを取得し、このマスターデータと同一の検索用データを生成し、これらのデータを関連付けてユーザ識別情報格納部に格納するユーザ識別情報格納工程と、前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して取引状況格納部に格納する取引状況格納工程と、前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納部のマスターデータを更新するマスターデータ更新工程と、前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納部から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納部から収集しネットワークを通じて当該ユーザに提供する取引状況出力工程とを備えたことを特徴とする口座情報管理方法が提供される。
このような構成によれば、上記した第1の主要な観点における取引口座情報管理システムを利用して好適に実行できる取引口座情報提供方法を得ることができる。
本発明によれば、金融機関のコンピュータシステムやネットワークに過大な負荷をかけずに、ユーザ識別情報の更新と取引状況の提供を迅速に実行できる口座情報管理システム及び管理方法を得ることができる。
なお、この発明の他の特徴と顕著な効果は、次の発明を実施するための最良の形態の項の記載と添付した図面とを参照することで、より明確に理解される。
以下、この発明の実施形態を、図面を参照して説明する。まず、図1を参照して、本実施形態の全体構成について説明する。
(全体構成)
この図で符号1で示す口座情報管理システムは、金融機関2が設置・運営するネットバンキングシステム3の一部の機能を構成するシステム(サーバ)である。この口座情報管理システム1は、同じくネットバンキングシステム3を構成する電子メールサーバ4及びWebサーバ5とLAN等の専用回線で接続されている。ネットバンキングシステム3は、CC(Channel Control)サーバ6を介して、金融機関2の契約マスターファイル7と、MCIF(Marketing Customer Information File)サーバ8及び情報系ホスト9を備えた情報系システム10と、顧客データベース(DB)11及び取引口座毎の勘定情報のマスターファイル12を備えた勘定系システム13とに夫々接続される。後述するように、前記口座情報管理システム1は、契約マスターファイル7、情報系システム10若しくは勘定系システム13から必要な情報を取得する。上記したサーバ4〜6、8やマスターファイル7、12等は何れも1又は2以上のコンピュータによって構成されている。
口座情報管理システム1は、前記Webサーバ5によってインターネットに接続可能な環境が構築されており、ファイアウォール14を介して顧客(ユーザ)15の通信端末(PCや携帯電話等)16から取引履歴等の口座情報の照会を受付けて提供したり、また、前記勘定系システム13から取得したユーザ識別情報(店舗番号と顧客番号)や取引状況などの口座情報を管理するものである。なお、金融機関2におけるネットバンキングシステム3や情報系システム10、勘定系システム13等のシステム構成は従来周知であるため、以下においては、本発明の特徴に関連する事項について説明する。
(システム構成)
次に、図2を参照して、前記口座情報管理システム1の概略構成を説明する。
このシステム1は、CPU17、RAM18、入出力装置19、通信デバイス20が接続されたバス21に、データ格納部22と、プログラム格納部23とを備えている。
このシステム1は、CPU17、RAM18、入出力装置19、通信デバイス20が接続されたバス21に、データ格納部22と、プログラム格納部23とを備えている。
データ格納部22は、前記金融機関2に設置されるサーバ(コンピュータシステム)の記憶領域に確保された一定の領域であり、契約情報格納部25、ユーザ識別情報格納部26及び取引状況格納部27を備えている。
契約情報格納部25は、前記契約マスターファイル7から取得されたユーザ15と金融機関2との間で締結されたネットバンキング利用契約の内容(契約期間や可能取引等)と、ネットバンキングシステムにログインする際のユーザID・パスワードからなる認証情報と、この認証情報に関連付けられたユーザ識別情報(後述する)とを格納している。
ユーザ識別情報格納部26には、例えば図3に示すように、前記勘定系システム13から毎月定期的(毎月最終営業日等)に送信されるユーザ識別情報のマスターデータ26a、後述する検索用データ生成部34が生成した検索用データ26b、ユーザ識別情報の取得月26c及び店舗統廃合等のイベント発生日26dが12ヵ月分蓄積されて格納されている。このユーザ識別情報は、金融機関2に1以上の口座を保有するユーザを識別するためのIDであり、例えば、4桁の店舗番号と8桁の顧客番号からなる。ユーザが保有する全ての口座の番号は、このユーザ識別情報に関連付けられて前記勘定系システム13や契約マスター7によって管理されている。前記マスターデータ26a、検索用データ26bは、このユーザ識別情報格納部26に格納される時点では、勘定系システム13で管理されているユーザ識別情報と常に一致している。
取引状況格納部27には、前記勘定系システム13から毎月定期的(毎月最終営業日等)に送信される1ヶ月毎の取引状況が12ヵ月分蓄積されて格納されている。また、この取引状況格納部27は、図4に示すように、前記ユーザ識別情報28と、口座番号29と、当該口座の入出金項目30a、支払/預り金額30b、30c及び入出金実行日30dを含む取引状況30と、取得月31とを格納するものである。図示は省略するが、投資信託口座などの資産運用を目的とする口座については、月末等の特定の時点における仮想資産残高や理論上の資産残高等が各月の取引レコードとして格納される。ここで、取引状況に関連付けられるユーザ識別情報28は、この取引状況格納部27に格納される時点では前記ユーザ識別情報格納部26に格納されたマスターデータ26a、検索用データ26b及び勘定系システム13で管理されているユーザ識別情報と常に一致している。
本実施形態では、取引状況30は、図5に示すように、取引口座の科目・取引内容に応じて19のテーブルに分割された状態で勘定系システム13から取得され、これらのテーブル毎に取引状況格納部27に蓄積・格納される。これにより、膨大な取引状況の送信や管理(検索等)の効率を向上できる。
これらの各テーブルの契約ユーザ数や履歴情報のレコード数は大きく異なる。具体的には、図6に示すように、口座種別コード=1の「取引総合レポート‐状況サマリー‐」は、口座を保有している全ての顧客の履歴情報のサマリーであるため、毎月の取引レコード数は顧客数と同数となる。また、口座種別コード=2の「資産借入明細‐流動性預金」は、全てのユーザが保有していると考えられ入出金も頻繁に行われるため、毎月の取引レコード数はユーザ数よりはるかに多くなる。一方、口座種別コード=9の「資産借入明細‐金」では、金融機関との間で「金取引」の契約を締結している顧客は少数であり、頻繁に入出金が繰り返されることはないため、取引レコード数は極めて少なくなる。これらの各テーブルは、ユーザ識別情報で紐付けされている。
上記した各格納部25〜27はリレーショナルデータベースを構成しており、契約情報格納部25若しくは取引状況格納部27とユーザ識別情報格納部26とは、ユーザ識別情報をキーにして相互にデータを参照可能とされている。
また、図2のプログラム格納部23は、メインプログラムの他、取引状況取得部32、ユーザ識別情報取得部33、検索用データ生成部34、マスターデータ更新部35、取引状況の照会受付・認証部36、及び取引状況照会処理部37を備えている。これらの各構成要素32〜37は、前記金融機関2のサーバ(コンピュータシステム)にインストールされたコンピュータソフトウェアプログラム若しくはそのサブルーチンであり、前記CPU17によってRAM18上にロードされて適宜実行されることで後述する各機能を奏するものである。
取引状況取得部32は、毎月の所定日に前記勘定系システム13の勘定情報マスターファイル12にアクセスして直近の1ヶ月分の全ての口座に係る取引状況(取引レコード)を取得して取得日31と共に前記取引状況格納部27に格納するものである。なお、毎月の所定日に勘定系システム13から送信されるデータを取得するようにしても良い。本実施形態では、12ヵ月分の取引状況を格納するようにしているため、既に12ヵ月分の取引状況が取引状況格納部27に格納されている場合には、取得月31が13ヵ月前のものを削除した上で最新の取引状況を登録する。
また、この取引状況取得部32は、ユーザ15から取引状況の照会があった場合に取引状況照会処理部37の指示を受けて、このユーザ15から取得したユーザ識別情報に基いて前記ユーザ識別情報格納部26から対応する検索用データ26bを特定し、この検索用データ26bに基づいて取引状況格納部27から当該口座の取引状況を収集する機能も備えている。
ユーザ識別情報取得部33は、毎月の所定日に金融機関2の勘定系システム13にアクセスしてユーザ識別情報テーブルを取得し、このテーブルを識別する情報として取得月26cを付して前記ユーザ識別情報格納部26に格納するものである。このユーザ識別情報テーブルは、前記取引状況と同時に取得することが好ましい。また、取引状況と同様に、取得月26cが13ヵ月前のものを削除した上で最新のユーザ識別情報を登録する。なお、毎月の所定日に勘定系システム13から送信されるデータを取得するようにしても良い。
検索用データ生成部34は、前記ユーザ識別情報取得部33が取得したユーザ識別情報テーブルについて、前記マスターデータ26aをコピーして検索用データ26bを生成し、前記ユーザ識別情報格納部26に取得月26cと共に登録するものである。この検索用データ生成部34が生成した検索用データ26bは、生成時においてはマスターデータ26a及び前記取引状況格納部27に格納されるユーザ識別情報28と常に一致している。
マスターデータ更新部35は、店舗の統廃合などのユーザ識別情報を変更するイベントが発生し、前記勘定系システム13から変更前後のユーザ識別情報を取得して更新の指示を受け付けた場合に、変更前のユーザ識別情報と前記ユーザ識別情報格納部26の検索用データ26bとを照合して更新対象の口座を特定し、更新対象の全てのユーザ識別情報テーブルのマスターデータ26aを変更後のユーザ識別情報に更新するものである。この更新処理は、前記勘定系システム13によって顧客DB11やMCIFサーバ8のユーザ識別情報が更新された後に行われる。これにより、ユーザ識別情報の更新を検証した後でネットバンキングの更新を行うことができる。
取引状況照会処理部37は、前記照会受付・認証部36がユーザ15から取得したユーザ識別情報に基づいて前記ユーザ識別情報格納部26から照会に係る口座の検索用データ26bを特定し、この検索用データ26bに基づいて前記取引状況格納部27から前記複数のテーブル毎に当該口座の取引状況を抽出し、所定の表示レイアウトを生成してネットワークを通じて当該ユーザ15に提供するものである。
本実施形態では、照会対象口座のイベント発生日26dを特定し、前記取引状況に含まれる入出金実行日29dがこのイベント発生日26dよりも前か後かを識別可能にして当該取引状況をユーザに提供するようにしている。例えば、図6に示すように、口座情報の照会画面において、取引履歴のリスト中に、口座変更後の取引であることを示す記号40(リスト右欄の「!」)を表示する。図示の例では、平成15年7月11日から22日の間に店舗統廃合などのイベントが発生し口座情報が変更されている。これにより、ユーザ15は、変更前後の取引を識別することができると共に、変更前後の口座が統一して管理されていることを確認できる。この図の画面は、図7の「お取引レポート」のトップ画面で各口座の取引状況のサマリーを確認したユーザが、例えば流動性預金の内訳ボタン41を押下した場合に表示される。また、図6に示す記号40(リスト右欄の「!」)は、前記イベントが発生した月に限って表示するのが好ましい。
(マスターデータの更新時間の試算)
ここで、図6を参照して、前記マスターデータ更新部35がマスターデータを更新する処理件数や処理時間を試算する。試算条件は、上記従来技術で示したものと同じ条件を用いる。
この図に示す様に、各データテーブル毎の契約顧客数(A)と、顧客毎の1ヵ月の取引レコード件数(B)とを乗算した12ヶ月分の総レコード数(C)の19テーブルの総合計は約6憶5千万レコードであり膨大な量となっている。ここで、顧客毎の1ヵ月の取引レコード件数(B)は、図示しないデータテーブル毎の全取引件数をそのデータテーブルの全顧客数(A)で除算した値を概算で示している。
前記取引レコード数(C)を、試算条件である更新対象店舗比率(この試算条件では5/400)で除算すると、更新対象レコード数(D)は約813万件となる。これが従来の更新処理を行う場合の対象件数である。
これに対して、本実施形態では、図6の下段に示すように、ユーザ識別情報テーブル(A’)はデータテーブル毎の契約者数とは無関係に、最大値である「1:取引総合レポート‐状況サマリー‐」の顧客数(500万)と同数となる。また、12ヵ月の総レコード数(C’)は、毎月取得するユーザ識別情報テーブル(A’)に単に12を乗算した値となる。従って、本実施形態における取引履歴の更新対象レコード数(D’)は、12ヵ月の総レコード数(C’)に、試算条件である更新対象店舗比率(5/400)を乗算した75万件となる。
この条件で、試算した場合、更新時間は以下のように算出される。
<試算結果>
更新処理時間:75万件(D’)÷2.5万件×10分÷60分=5時間
<試算結果>
更新処理時間:75万件(D’)÷2.5万件×10分÷60分=5時間
このように、従来の処理時間54時間が10分の1以下に短縮できることが分かる。この程度の処理時間であれば、休日の深夜などのシステムメンテナンス時に行うことも十分可能である。
(処理工程)
次に、図9〜図11のフローチャートを参照して、本発明の処理工程をその機能と共に説明する。
(取引状況及びユーザ識別情報の登録フロー)
まず、図9を参照して、取引状況の取得及びユーザ識別情報の登録フローを説明する。
この処理では、前記取引状況取得部32が、毎月の最終営業日後の深夜に、前記勘定系システム13から当月の1ヵ月分の取引状況を取得する(ステップ1)。取得する取引状況は、前述したように19個のデータテーブルに分割されている。また、同時に前記ユーザ識別情報取得部33がユーザ識別情報テーブルを取得する(ステップS2)。前記した様に、この時点では、ユーザ識別情報テーブルに含まれるユーザ識別情報と取引状況が関連付けられているユーザ識別情報とは、勘定系システム13で管理されているユーザ識別情報と一致している。
ここで、取引状況及びユーザ識別情報テーブルの取得月26c、31に基づいて既に過去12ヵ月分の情報が登録されていると判別される場合には(ステップS3のYes)、取得月が13ヵ月前の1ヵ月分の取引状況及びユーザ識別情報テーブルを検索して削除する(ステップ4)。そして、取得した当月分の取引状況に取得月31を付して取引状況格納部27に格納する(ステップS5)。
また、前記検索用データ生成部34は、取得したユーザ識別情報テーブルのマスターデータ(店舗番号と顧客番号)をコピーして検索用データ26bを生成して前記ユーザ識別情報取得部33に受け渡す(ステップ6)。前記ユーザ識別情報取得部33は、生成された検索用データ26bと前記取得したユーザ識別情報とを、取得月26cを付してユーザ識別情報格納部26に格納する(ステップS7)。これにより、勘定系システム13で管理されるユーザ識別情報と同一のユーザ識別情報をマスターデータ及び検索用データとして保持し、かつ、取引状況をこれらの情報に関連付けて登録することができる。なお、取引状況とユーザ識別情報とを、取引状況取得部32若しくはユーザ識別情報取得部33によって一括して取得・登録することもできる。この場合は、何れか一方の機能(工程)を省略できる。
(マスターデータの更新フロー)
次に、図10を参照して前記マスターデータ更新部35によるマスターデータの更新(洗い換え)処理フローを説明する。この更新処理は、毎月などの所定周期ではなく、月中であっても店舗の統廃合等のイベントが発生する都度行うのが好ましい。
まず、前記マスターデータ更新部35が、勘定系システム13からユーザ識別情報の更新情報(変更前後のユーザ識別情報とイベント発生日)を取得して更新の指示を受け付けると(ステップS8)、取得した更新情報から更新前のユーザ識別情報(店舗番号と顧客番号)を抽出する(ステップS9)。抽出したユーザ識別情報で前記ユーザ識別情報格納部26のマスターデータ26aの欄を検索して更新の対象となるユーザ(ユーザ識別情報テーブル)を特定する(ステップ10)。
次いで、前記ステップS8で取得した更新情報から更新後のユーザ識別情報を抽出する(ステップS11)。抽出したユーザ識別情報を、前記特定した対象ユーザのマスターデータ26aの欄に上書きする(ステップS12)。また、更新情報からイベント発生日を抽出して該当欄26dに登録する(ステップS13)。
通常は、更新すべきユーザ識別情報のテーブルは複数あり(最大12ヵ月分)、また店舗の統廃合によってユーザ識別情報が変更されるユーザは複数いるため、このマスターデータ更新部33は全ての更新対象テーブル及び全ての更新対象ユーザについて上記したステップS9〜S13までの処理を実行する(ステップS14)。更新処理が完了した後、前記勘定系システム13に更新済みの通知を送信する(ステップS15)。
(取引状況の照会処理フロー)
次に、図11を参照して、取引状況の照会処理フローを参照する。
まず、前記照会受付・認証部36が、ユーザ15からID・パスワードの認証情報を取得して照会を受付けると(ステップS16)、認証情報と前記契約情報格納部25とを照合してユーザ認証を行う(ステップS17)。
認証が肯定的である場合、前記取引状況照会処理部37が起動して以下の各処理を行う。すなわち、取得した認証情報に関連付けられたユーザ識別情報を前記契約情報格納部25から検索し(ステップS18)、このユーザ識別情報に基いてユーザ識別情報格納部26から当該ユーザの検索用データ26bを特定する(ステップS19)。また、前記取引状況取得部32に対して、特定された検索用データ26bに基づいて、取引状況格納部27から当該ユーザの全ての口座(19テーブル)における取引状況の収集を指示する(ステップS20)。
ここで、特定された照会対象のユーザについてイベント発生日26dが登録されている場合にはマスターデータ26aの更新が行われていると判別し(ステップS21のYes)、このイベント発生日26dよりも入出金実行日29dが後の取引レコードにフラグを付与する(ステップS22)。この場合の取引レコードは、頻繁に入出金が実行される流動性預金口座の取引履歴に限るのが好ましい。一方、マスターデータ26aの更新が行われていない場合には(ステップS21のNo)、ステップS22の工程はスキップされる。
最後に、前記取引状況にフラグが付されているかに基づいて、ユーザ識別情報の変更(店舗の統廃合等)以前の取引状況と変更後の取引状況とを識別可能に表示した取引状況表示インタフェース(図7参照)を所定のレイアウトで生成してユーザ15の端末16に出力する(ステップS23)。
なお、この発明は上記の実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。
例えば、取引状況やユーザ識別情報に含まれる情報、取引状況の表示レイアウト、取引状況やユーザ識別情報のテーブルの保有期間等は上記したものに限られない。例えば、取引状況にユーザが任意に付した口座の識別情報(子供の名前等)を含めてこれを取引状況の表示インタフェースに表示することも可能である。また、取引状況等を13か月分保有して、前年同月の情報を提供できるようにしても良い。
また、マスターデータの更新のタイミングは、毎月・毎週等の所定周期で行ったり、所定の件数(更新対象の店舗数や対象ユーザ数等)に達した時に行ったり、勘定系システムと同時期に実行するようにしても良い。
1…口座情報管理システム
2…金融機関
3…ネットバンキングシステム
11…顧客データベース(DB)
12…勘定情報マスターファイル
13…勘定系システム
15…顧客(ユーザ)
16…通信端末
22…データ格納部
23…プログラム格納部
25…契約情報格納部
26…ユーザ識別情報格納部
26a…マスターデータ
26b…検索用データ
26c…ユーザ識別情報の取得月
26d…イベント発生日
27…取引状況格納部
28…ユーザ識別情報
29…口座番号
30…取引状況(取引レコード)
31…取引状況の取得月
32…取引状況取得部
33…ユーザ識別情報取得部
34…検索用データ生成部
35…マスターデータ更新部
36…照会受付・認証部
37…取引状況照会処理部
2…金融機関
3…ネットバンキングシステム
11…顧客データベース(DB)
12…勘定情報マスターファイル
13…勘定系システム
15…顧客(ユーザ)
16…通信端末
22…データ格納部
23…プログラム格納部
25…契約情報格納部
26…ユーザ識別情報格納部
26a…マスターデータ
26b…検索用データ
26c…ユーザ識別情報の取得月
26d…イベント発生日
27…取引状況格納部
28…ユーザ識別情報
29…口座番号
30…取引状況(取引レコード)
31…取引状況の取得月
32…取引状況取得部
33…ユーザ識別情報取得部
34…検索用データ生成部
35…マスターデータ更新部
36…照会受付・認証部
37…取引状況照会処理部
Claims (12)
- ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報の管理システムであって、
金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータと、このマスターデータと同一の検索用データとを関連付けて格納するユーザ識別情報格納手段と、
前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して格納する取引状況格納手段と、
前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納手段のマスターデータを更新するマスターデータ更新手段と、
前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納手段から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納手段から収集しネットワークを通じて当該ユーザに提供する取引状況出力手段と
を備えたことを特徴とする口座情報管理システム。 - 請求項1に記載のシステムにおいて、
さらに、金融機関の上位システムから所定周期で前記ユーザ識別情報のレコードを取得し、このレコードを識別する情報に関連付けて前記ユーザ識別情報格納手段に格納するユーザ識別情報取得手段を備え、
前記マスターデータ更新手段は、前記イベントが発生した場合に、ユーザ識別情報格納手段から更新対象となる1又は2以上のユーザ識別情報レコードを抽出し、抽出したユーザ識別情報レコードのマスターデータを変更後のユーザ識別情報に更新するものである
ことを特徴とする口座情報管理システム。 - 請求項2に記載のシステムにおいて、
前記ユーザ識別情報取得手段は、前記取引状況格納手段が取引状況を取得するタイミングで前記ユーザ識別情報のレコードを取得するものである
ことを特徴とする口座情報管理システム。 - 請求項1に記載のシステムにおいて、
前記取引状況格納手段は、金融機関の上位システムから所定周期で取引口座の科目・取引内容に応じて複数のデータテーブルに分割された取引状況を取得してこの取引状況をテーブル毎に格納するものであり、
前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記検索用データに基づいて前記複数のデータテーブル毎に取引状況を収集するものである
ことを特徴とする口座情報管理システム。 - 請求項1に記載のシステムにおいて、
前記マスターデータ更新手段は、金融機関の上位システムがユーザ識別情報を更新するタイミングと異なるタイミングでマスターデータの更新を行うものである
ことを特徴とする口座情報管理システム。 - 請求項1に記載のシステムにおいて、
前記ユーザ識別情報格納手段は、前記イベントに係るユーザについてイベント発生日を取得して格納するものであり、
前記取引状況格納手段は、各口座に対して入出金が実行された日を含む取引状況を取得して格納するものであり、
前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記ユーザ識別情報格納手段から当該ユーザのイベント発生日を特定し、前記収集した取引状況に含まれる入出金実行日と比較することによって、各取引がイベント発生日よりも前か後かを識別可能にして当該取引状況をユーザに提供するものである
ことを特徴とするシステム。 - ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報をコンピュータによって管理する方法であって、
金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータを取得し、このマスターデータと同一の検索用データを生成し、これらのデータを関連付けてユーザ識別情報格納部に格納するユーザ識別情報格納工程と、
前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して取引状況格納部に格納する取引状況格納工程と、
前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納部のマスターデータを更新するマスターデータ更新工程と、
前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納部から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納部から収集しネットワークを通じて当該ユーザに提供する取引状況出力工程と
を備えたことを特徴とする口座情報管理方法。 - 請求項7に記載の方法において、
さらに、金融機関の上位システムから所定周期で前記ユーザ識別情報のレコードを取得し、このレコードを識別する情報に関連付けて前記ユーザ識別情報格納部に格納するユーザ識別情報取得工程を備え、
前記マスターデータ更新工程は、前記イベントが発生した場合に、ユーザ識別情報格納部から更新対象となる1又は2以上のユーザ識別情報レコードを抽出し、抽出したユーザ識別情報レコードのマスターデータを変更後のユーザ市域別情報に更新するものである
ことを特徴とする口座情報管理方法。 - 請求項8に記載の方法において、
前記ユーザ識別情報取得工程は、前記取引状況格納部が取引状況を取得するタイミングで前記ユーザ識別情報のレコードを取得するものである
ことを特徴とする口座情報管理方法。 - 請求項7に記載の方法において、
前記取引状況格納工程は、金融機関の上位システムから所定周期で取引口座の科目・取引内容に応じて複数のテーブルに分割された取引状況を取得してこの取引状況をテーブル毎に格納するものであり、
前記取引状況出力工程は、ユーザから取引状況の照会を受付けた場合に、前記検索用データに基づいて前記複数のデータテーブル毎に取引状況を収集するものである
ことを特徴とする口座情報管理方法。 - 請求項7に記載の方法において、
前記マスターデータ更新工程は、金融機関の上位システムがユーザ識別情報を更新するタイミングと異なるタイミングでマスターデータの更新を行うものである
ことを特徴とする方法。 - 請求項7に記載の方法において、
前記ユーザ識別情報格納工程は、前記イベントに係るユーザについてイベント発生日を取得して格納するものであり、
前記取引状況格納工程は、各口座に対して入出金が実行された日を含む取引状況を取得して格納するものであり
前記取引状況出力工程は、ユーザから取引状況の照会を受付けた場合に、前記ユーザ識別情報格納部から当該ユーザのイベント発生日を特定し、前記収集した取引状況に含まれる入出金実行日と比較することによって、各取引がイベント発生日よりも前か後かを識別可能にして当該取引状況をユーザに提供するものである
ことを特徴とする方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004034200A JP2005227910A (ja) | 2004-02-10 | 2004-02-10 | 取引口座情報管理システム及び管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004034200A JP2005227910A (ja) | 2004-02-10 | 2004-02-10 | 取引口座情報管理システム及び管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005227910A true JP2005227910A (ja) | 2005-08-25 |
Family
ID=35002595
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004034200A Pending JP2005227910A (ja) | 2004-02-10 | 2004-02-10 | 取引口座情報管理システム及び管理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005227910A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010224881A (ja) * | 2009-03-24 | 2010-10-07 | Mizuho Information & Research Institute Inc | 取引データ処理方法、システム及びプログラム |
CN102402775A (zh) * | 2011-12-02 | 2012-04-04 | 苏州慧飞信息科技有限公司 | 一种基于网上银行的理财*** |
CN112463737A (zh) * | 2020-11-17 | 2021-03-09 | 中科金审(北京)科技有限公司 | 针对多格式数据智能匹配模板快速采集数据的***及方法 |
-
2004
- 2004-02-10 JP JP2004034200A patent/JP2005227910A/ja active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010224881A (ja) * | 2009-03-24 | 2010-10-07 | Mizuho Information & Research Institute Inc | 取引データ処理方法、システム及びプログラム |
CN102402775A (zh) * | 2011-12-02 | 2012-04-04 | 苏州慧飞信息科技有限公司 | 一种基于网上银行的理财*** |
CN112463737A (zh) * | 2020-11-17 | 2021-03-09 | 中科金审(北京)科技有限公司 | 针对多格式数据智能匹配模板快速采集数据的***及方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9418381B2 (en) | Method and system for notifying customers of transaction opportunities | |
US8032453B2 (en) | Method and system for notifying customers of transaction opportunities | |
US6856970B1 (en) | Electronic financial transaction system | |
US20120259753A1 (en) | System and method for managing collaborative financial fraud detection logic | |
KR101961899B1 (ko) | 가상화폐와 명목화폐 간의 환율을 고려한 가상화폐 자동 결제 서비스 제공 방법 | |
JP6409115B1 (ja) | 自動仕訳サーバおよび自動仕訳プログラム | |
EP3940611A1 (en) | Personal information management system, personal information management device, and personal information management method | |
JP4413575B2 (ja) | アカウントサービス情報の統合管理を支援する情報処理装置、アカウントサービス情報の統合管理方法、プログラム、および記録媒体 | |
CN111415067A (zh) | 企业及个人信用评级*** | |
US9805421B1 (en) | Integrated investment management system with network datafeed and incremental database refresh | |
JP2013065360A (ja) | 決済システム | |
WO2014193324A1 (en) | Risk reporting system | |
US7587350B1 (en) | Integrated investment management system with network datafeed | |
KR100321485B1 (ko) | 개인재무관리시스템 및 방법 | |
JP2005227910A (ja) | 取引口座情報管理システム及び管理方法 | |
KR20090063805A (ko) | 불법 금융 거래 정보를 관리하고 혐의 거래의 확인과보고서 작성 및 등록을 통합적으로 수행하는 방법 및시스템 | |
KR102107453B1 (ko) | 자금 관리 서비스 시스템 및 방법과, 이를 위한 모바일 장치 및 컴퓨터 프로그램 | |
JP2011034532A (ja) | 入金装置、入金支援装置、入金方法、入金支援方法およびプログラム | |
US20200065782A1 (en) | Recipient management in computer network initiated data transfers | |
JP5377199B2 (ja) | 信用情報機関に提供された個人信用情報の開示システム | |
JP2001350915A (ja) | 金融処理システム、金融処理システムのシステム処理方法、及び、そのためのプログラムを記録した記録媒体 | |
JP6915138B1 (ja) | 情報提供装置、プログラムおよび情報処理方法 | |
JP6934030B2 (ja) | 情報処理装置及び情報処理方法 | |
WO2023085247A1 (ja) | 情報処理方法、情報処理装置、情報処理プログラムおよび記録媒体 | |
KR20230097277A (ko) | 예금자보험대상 개인별 조회결과를 제공하는 방법 및 시스템 |