JP5850592B1 - 金融口座を管理するコンピュータ・システム - Google Patents

Abstract

【課題】顧客の資金ニーズを高精度で推測するＥＢＭ（Ｅｖｅｎｔ Ｂａｓｅｄ Ｍａｒｋｅｔｉｎｇ）のシステムを提供する。【解決手段】過去の振込履歴を基に、過去の振込履歴を基に、所定の継続的な振込を受けているまたは所定の継続的な振込をしている主口座と、所定の継続的な振込がない副口座とに分類する手段と、主口座に振り込まれた大口入金が、主口座の属性データを基に、所定の目的を持った入金であると判定する手段と、副口座に入金された大口入金が、所定の目的を持った入金である可能性がある候補入金であることを判定する手段と、候補入金の振込元と振込日が、主口座に振り込まれた大口入金の振込元と振込日と一致する場合に、副口座に入金された入金候補が、副口座の属性データを基に、主口座に振り込まれた大口入金と同じ目的の入金であることを判定する手段とを備えるシステムを提供する。【選択図】図３

Description

本発明は、金融機関等における営業を支援するためのコンピュータ・システムに関する。特に、顧客の事情の変化を捉えて、その事情の変化が生じた原因を分析して、顧客の資金ニーズにあわせた金融商品を適切に提供するＥＢＭ（Ｅｖｅｎｔ Ｂａｓｅｄ Ｍａｒｋｅｔｉｎｇ）のコンピュータ・システムに関する。

銀行等の金融機関では、定期預金や投資信託、カードローンなどの取り扱っている金融商品を販売・契約するため、顧客の資金ニーズを把握し、顧客の資金ニーズに応じた金融商品を適切に推奨できるように営業活動を行っている。

その点において、銀行の決済情報は、顧客に聴取することなく資金ニーズを把握する上で必要な情報である。

通常、金融機関の営業担当者は、営業担当者自身が担当する口座の取引履歴を確認して、担当する顧客が何らかの事情が発生したこと（例えば、顧客の退職により退職金を受け取ったことなど）を経験や勘で判断していた。但し、そのような経験や勘は、判断のバラツキが生じやすいために、顧客の資金ニーズを把握するためのシステム化が求められており、ＥＢＭを用いたコンピュータ・システムが従来から提案されている。

そのようなシステムの従来技術として、例えば、特許文献１が開示されている。特許文献１では、ある金融機関の中のシステムにおいて、特定の対象期間における入金側の口座と受取人側の口座との取引総額を計算して、当該特定の対象期間よりも過去の期間の入金側の口座と受取人側の口座との取引総額とを比較する技術が開示されている。

特許第５４１６８５２号

しかしながら、顧客は、特定の銀行若しくは複数の銀行に、複数の口座を保有しており、当該複数の口座を目的に応じて使い分けていることが多く、特定の口座の取引を調べただけでは、顧客の資金ニーズが十分に把握できない。従来技術は、このような点が考慮されていない。

顧客は、特定の銀行のひとつ又は複数の支店に、複数の口座を保有しており、当該複数の口座を目的に応じて使い分けていることが多い。主として給与振込等などの定期的な振込に使用している口座（主口座と称する）については、資金の動きが活発なので、資金ニーズを把握するのが比較的容易である。しかし、特定の資金の入金や出金のために使用している口座（副口座と称する）については、資金の動きが活発ではないので、特定の口座（特に、副口座）に注目してしまうと、高い精度で、顧客の資金ニーズを把握するのは必ずしも容易とは言えない。

よって、本発明の一態様においては、自己の金融機関で特定の口座（特に、主口座以外の口座）を有する顧客の資金ニーズを、高い精度で判定することを課題のひとつとする。

更に、顧客は、複数の銀行に、複数の口座を保有しており、当該複数の口座を目的に応じて使い分けていることも多い。特に、地方金融機関の場合、顧客の勤務先企業の本社だけでなく、工場や事業所も当該地方金融機関の営業エリアにないことが多い。かかる場合、当該地方金融機関は、顧客の勤務先企業との取引がないので、顧客である従業員の決済情報からのみ資金ニーズを判断するが、結果として、高い精度で、顧客の資金ニーズを把握することは必ずしも容易とは言えない。

よって、本発明の別の態様においては、金融機関（特に、地方金融機関）の営業エリア外の取引を把握することによって、自己の金融機関で主口座や副口座を有する顧客の資金ニーズを、高い精度で判定することを課題のひとつとする。

本発明の一態様によれば、金融口座を管理するコンピュータ・システムにおいて、過去の振込履歴を基に、所定の継続的な振込を受けているまたは所定の継続的な振込をしている主口座と、所定の継続的な振込がない副口座とに分類する手段と、前記主口座に振り込まれた入金が、前記主口座の属性データを基に、所定の目的を持った入金であると判定する手段と、前記副口座に振り込まれた入金が、所定の目的を持った入金である可能性がある入金候補であることを判定する手段と、前記副口座に振り込まれた入金候補の振込元と振込日が、前記主口座に振り込まれた入金の振込元と振込日と一致する場合に 、前記副口座に入金された前記入金候補が、前記副口座の属性データを基に、前記主口座に振り込まれた入金と同じ目的の入金であることを判定する手段と、を備えることを特徴とするシステムを提供する。

本発明の一態様によれば、金融機関の主口座だけでなく副口座に振り込まれた金額の目的が把握できるようになるので、顧客の資金ニーズを高精度で把握することができる。
本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。

本発明の一実施例のシステムの概略を示す図である。 図１のシステムの機能ブロック図である。 図１のシステムの処理の流れの一例を示すフローチャートである。 図１のシステムで使用するデータ構造の一例を示す。 本発明の別の実施例のシステムの機能ブロック図である。 図５のシステムの処理の流れの一例を示すフローチャートである。 本発明の更に別の実施例のシステムの機能ブロック図である。 図７のシステムの処理の流れの一例を示すフローチャートである。

以下、本発明を実施するための形態について、図面に基づいて説明する。

（実施例１）
本実施例では、退職金を受け取った顧客の口座を判定（推定）するシステムを示す。
図１は、本発明の一実施例のシステムの概略を示す図である。本実施例では、説明を簡単にするために、Ａ銀行とＢ銀行の２行からなるシステムを用いて説明する。

図１において、システム１００は、Ａ銀行が有するＥＢＭシステム２００と、Ｂ銀行が有するＥＢＭシステム３００とからなる。これらは、それぞれがネットワーク５００等で接続されている。

Ａ銀行のＥＢＭシステム２００は、行内サーバ２１０と、端末２２０（２２０-１、・・・２２０-ｎ：ｎは、正の整数）と、行内ＤＢ（Ｄａｔａｂａｓｅ：データベース）２３０とからなる。サーバ２１０、端末２２０、行内ＤＢ２３０は、それぞれネットワーク等で接続されている。

Ｂ銀行のＥＢＭシステム３００は、行内サーバ３１０と、端末３２０（３２０-１、・・・３２０-ｍ：ｍは、正の整数）と、行内ＤＢ３３０とからなる。

Ａ銀行のＥＢＭシステム２００の構成の一例について説明する。行内サーバ２１０は、Ａ銀行内の口座間の振り込みや自行の口座と他行の口座との振り込みを管理するためのコンピュータである。端末２２０は、各口座間の振り込み情報などを閲覧することができる端末である。行内ＤＢ２３０は、顧客の口座などの様々なデータ（情報）を管理している。具体的には、顧客の名称、金額などの情報を記憶しており、Ａ銀行内における各顧客の決済情報（取引履歴）なども有する。更に、行内ＤＢ２３０は、例えば、対象となる顧客の口座で資金が移動すると、その移動に応じて、金額の情報が更新される。

なお、本実施例におけるシステム１００、若しくは当該システム１００を構成する一部若しくは全部のユニットには、プロセッサが入っており、それぞれのプロセッサが、システムの処理の一部若しくは全部を担う。

本実施例におけるＢ銀行のＥＢＭシステム３００の構成は、Ａ銀行のＥＢＭシステム２００の構成と同様であるので、説明を省略する。本実施例において、Ａ銀行とＢ銀行とのサブシステムが互いに連携できる範囲であれば、Ａ銀行やＢ銀行のサブシステム内の構成を変えてもよい。

図２は、実施例１の図１のシステムの機能ブロック図である。説明の便宜上、図２では、Ａ銀行のＥＢＭシステム２００の機能ブロック図のみを示す。
制御部２１１は、後述する各部を制御する。
勤務先判定部２１２は、口座Ａにおける過去給与振り込みの情報等を用いて、当該口座を有する顧客の勤務先を判定する。

過去給与振込判定部２１３は、顧客が、毎月（若しくは所定の間隔で）、特定の企業等から、一定の金額が振り込まれていることを検索して、これら一連の振込を給与振込であると判定する。また、必要に応じて、給与振込の履歴（リスト）を作成する。なお、給与の振込額は、残業代や各種手当てなどの有無によって毎月異なるが、一定の範囲で振込額は変動することを考慮しつつ、毎月の給与振込を判定してもよい。

退職金候補入金判定部２１４は、特定の口座に、退職金と思われる大口入金が確認されたときに、その大口入金を「退職金候補」であると判断する。

退職金判定部２１５は、口座Ａに、退職金候補と判定された入金について、当該入金を、入金日、勤務先情報、年代（若しくは年齢）、おおよその在勤年数（例えば、１年単位でもよく数年単位でもよい）などの口座を開設している顧客属性データを基に、退職金であるか否かを判定する。例えば、顧客の年齢が６０歳に達し、その翌月または翌年度の所定の年月に所定の大口入金があれば（退職金候補が入金されれば）、その大口入金は、退職金であると判断できる。

ここで、顧客の属性データは、後述する顧客属性ＤＢ２３２に記憶されている。顧客の属性データは、多様な情報が含まれていてもよく、例えば、顧客自身の情報に加えて、顧客に関連する情報（例えば、家族構成の情報、名寄せの情報）を含めてもよい。また、退職金判定部２１５は、毎月の給与の振込口座と、退職金の振込口座が同一である顧客であることも判定してもよい。

顧客口座ＤＢ２３１（ＤａｔａＢａｓｅ）は、各顧客の口座毎に預金されている資金を管理している。また、口座毎の決済情報を基に、取引の履歴を管理してもよい。

顧客属性ＤＢ２３２は、顧客の属性データ（例えば、顧客の氏名（法人名）、住所、生年月日、職業、家族構成などの顧客固有の情報）が記録されている。また、顧客によっては、同一の銀行に複数の口座（例えば、普通預金の口座と定期預金の口座）を開設している場合がある。そのような顧客を一元管理するために（いわゆる名寄せを適切に管理するために）、当該複数の口座が同一顧客であることを識別するための識別子等を用いて、当該複数の口座を管理できるように構成されていてもよい。

決済情報ＤＢ２３３は、自行の預金の流動性に関する流動性資金情報や、為替レートなど資金の決済に必要な情報（決済情報）を蓄積するための装置である。

退職金受取顧客ＤＢ２３４は、退職金判定部２１５で、退職金が入金されたと判定された場合に、該当する顧客情報として、退職金を受け取ったことを書き込む。更に、退職金を振り込んだ企業名および振込日も書き込んでもよい。

退職金受取企業情報ＤＢ４０３は、退職金を受け取った従業者（金融機関の顧客）の企業に関する情報を記録している。

図３（ａ）（ｂ）は、図２で示した機能ブロックにおける処理の流れを示すフローチャートである。以下、本実施例における処理の流れを、図３を用いて説明する。

図３（ａ）は、自行に主口座を有している顧客が退職金を受け取ったどうかを判定するためのフローチャートである。

Ｓ１０１０では、決済処理に基づいて、指定された顧客の口座に、指定された金額を振り込むための入金処理を行う。ここで、決済情報には、金融機関において通常の業務処理を行うための様々な情報が含まれているが、本実施例で使用するのは、後述するように、その中の一部の情報である。

Ｓ１０２０では、決済情報に基づく入金処理で、退職金である可能性がある大口入金であるか否かを判定する。本実施例では、このような大口入金を、「退職金候補」と称することにする。退職金候補の判定方法について、具体的には、例えば、所定の金額を超えた高額な入金であったか否かを確認する。なお、所定の金額については、各金融機関が個別に当該所定の金額を決定してもよく、複数の金融機関や共通のサーバなどが当該所定の金額を決定してもよい。

Ｓ１０３０では、退職金候補が入金された顧客が、これより以前に、給与振り込みを毎月受けていたかどうかを判定する。自行（例えば、Ａ銀行）では給与振り込みを受けていなかったが、他行（例えば、Ｂ銀行）で給与振り込みを受けている可能性がある。すなわち、退職金等の受取口座と、給与の受取口座が異なる可能性があるからである。もし、給与振り込みを受けていたら、給与振込者であると判定する。すなわち、本実施例においては、この給与振込者は、自行（例えば、Ａ銀行）に主口座を有している顧客であることを意味する。

また、給与振込を受けていなければ、給与非振込者であると判定する。給与非振込者であると判定された場合の処理は、図３（ｂ）で説明する。すなわち、本実施例においては、この給与非振込者は、他行（例えば、Ｂ銀行）に主口座を有している可能性のある顧客ではあるが、自行（例えば、Ａ銀行）には主口座を有しておらず副口座を有している顧客であることを意味する。

なお、ＤＢ上に、給与振込者と給与非振込者とを識別するための識別子やフラグなどを付加してもよい。

Ｓ１０４０では、退職金候補が振り込まれた顧客の中から、給与振込者を抽出する。

Ｓ１０５０では、過去の決済を検索して、抽出された給与振込者の過去の給与振り込み履歴を作成する。

Ｓ１０６０では、過去の給与振り込みの履歴に基づいて、勤務先を判定する。

Ｓ１０７０では、Ｓ１０６０までの処理の結果に加えて、顧客の属性データから必要な情報（例えば、勤務先の情報）を入手して、入金された退職金候補が退職金であるか否かを判定する。例えば、顧客の年齢が６０歳に達し、その翌月または翌年度の所定の年月に退職金候補が入金されれば、その退職金候補は、退職金であると判断できる。

Ｓ１０８０では、退職金であることが判定されると、主口座の退職金受取顧客情報リストを更新する。この退職金受取顧客情報リストとは、退職金を振り込んだと推定される企業・法人名と振込日とから構成されている。

Ｓ１０９０では、退職金候補が入金された全ての給与所得者に対して判定が終了したか否かを判断する。退職金候補が入金された全ての給与所得者に対して、判定を行ったのであれば、Ｓ１１００へ進む。判定が必要な給与所得者が残っていれば、Ｓ１０４０へ戻って、本処理を継続する。

Ｓ１１００では、退職金受取顧客情報リストを退職金受取企業情報ＤＢに送信して、退職金受取企業情報ＤＢで管理しているリストを更新する。これにより、該当する顧客が退職金を受け取ったことが退職金受取企業情報ＤＢに記録される。

Ｓ１１１０では、更新された退職金受取顧客情報リストを、自行内の営業担当者へ通知する。退職金と判定された後は、人間がわかるようなデータ形式で出力（例えば、電子メールで送信）して、当該口座の営業担当者へ連絡したり、コールセンターの担当者へ連絡したりする。これにより、営業担当者やコールセンターの担当者は、該当する顧客へ訪問したり、電話をかけたりして、顧客の資金ニーズに応じた金融商品を提示することができる。なお、後述する図３（ｂ）の処理を引き続き実行する時などは、Ｓ１１１０を省略してもよい。

図３（ｂ）は、自行に主口座を有していないが副口座（主口座以外の口座）を有している顧客が退職金を受け取ったどうかを判定するためのフローチャートである。
ここで、毎月の給与の振込口座と退職金の振込口座が同一ではない顧客もいる。すなわち、毎月の給与の振込口座は、Ａ銀行であったが、退職金の振り込み口座がＢ銀行である場合がある。そのような顧客を有するＢ銀行の口座には、ある日突然、所定の金額（大口入金）が振り込まれることになる。このような場合は、退職金受取企業情報ＤＢにアクセスして、同日に、同一の振込元から振り込みがあったかどうかを確認する。退職金受取企業情報ＤＢから、退職金を出した企業の有無を確認して、もし該当する企業があれば、Ｂ銀行に振り込まれたものは、退職金であると判定する。

図３（ｂ）の処理は、図３（ａ）の処理が終了した後に実行される処理であってもよい。

Ｓ１０４１では、Ｓ１０３０において判定された給与非振込者を抽出する。給与非振込者とは、自行に主口座を有していないが副口座（主口座以外の口座）を有している顧客を意味する。

Ｓ１０４２では、退職金受取企業情報ＤＢにアクセスして、退職金受取顧客情報リストを受信する。

Ｓ１０７１では、退職金受取企業情報ＤＢからの情報を基に、自行に入金された退職金候補と同日に同一の振込元から、退職金の入金があったことが退職金受取顧客情報リストに記録されているかどうかを確認する。退職金受取顧客情報リストでは、退職金を入金した企業名と入金日に関する情報が管理されている。更に、顧客属性ＤＢ２３２などから、副口座の属性データを取得して、副口座を有している顧客の年齢（例えば、６０歳）を特定する。このような情報を基に、退職金候補が、真の退職金であるか否かが判断される。例えば、退職金候補の入金と同日に、同じ振込元（企業）から、副口座に、大口入金があり、更に、副口座を有している顧客の年齢が退職金を受け取っている可能性がある年齢（例えば、６０歳）であれば、その退職金候補は、退職金であると判定できる。ただし、退職金の金額は、退職した時の役職や勤続年数によって異なるので、退職金と判定するための金額の範囲を予め決めておいてもよい。

Ｓ１０８１では、退職金であることが判定されると、副口座の退職金受取顧客情報リストを更新する。この退職金受取顧客情報リストとは、退職金を振り込んだと推定される企業・法人名と振込日とから構成されている。なお、副口座の退職金受取顧客情報リストについては、図３（ａ）のＳ１０８０で作成した主口座の退職金受取顧客情報リストに上書きするように更新してもよく、主口座の退職金受取顧客情報リストとは別個に作成してもよい。

Ｓ１０９１では、退職金候補が入金された全ての給与所得者に対して判定が終了したか否かを判断する。退職金候補が入金された全ての給与所得者に対して、判定を行ったのであれば、Ｓ１１００へ進む。判定が必要な給与所得者が残っていれば、Ｓ１０４１へ戻って、本処理を継続する。

Ｓ１１０１では、退職金受取顧客情報リストを退職金受取企業情報ＤＢに送信して、退職金受取企業情報ＤＢで管理しているリストを更新する。これにより、該当する顧客が退職金を受け取ったことが退職金受取企業情報ＤＢに記録される。

Ｓ１１１１では、更新された退職金受取顧客情報リストを、自行内の営業担当者へ通知する。ここで、退職金受取顧客情報リストは、主口座のみから判定された情報（退職金を振り込んだ企業・法人名と、その振込日）のみ、又は副口座から判定された情報のみから構成されてもよく、これらの情報を組み合わせた情報から構成されてもよい。退職金と判定された後は、人間がわかるようなデータ形式で記録された情報を出力（例えば、電子メールで送信）して、当該口座の営業担当者へ連絡する。

なお、このような個々の情報は、ＭＣＩＦと呼ばれる。ＭＣＩＦとはＭａｒｋｅｔｉｎｇ Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｉｌｅの略称であり、マーケティング用の顧客情報のファイルを意味する。本発明の一実施例によれば、そのような顧客情報ファイルを自動的に構築することができるので、効率の良いマーケティングができ、顧客の資金ニーズに応じた金融商品を提案するための営業支援を行うことができる。

なお、Ｓ１０７０やＳ１０７１の退職金の判定においては、更に、勤務先情報の一般的な定年の年齢などの情報も有していれば、そのような情報を基に、定年による退職金を受け取ったことも判定してもよい。また、勤務先の一般的年齢よりも明らかに若い年齢であることがわかれば、早期退職であることも判定してもよい。
なお、本実施例では、Ｓ１０８０やＳ１０８１で、個々の退職金企業情報を退職金受取顧客情報リストに反映させてから、Ｓ１１１０やＳ１１１１で、更新された退職金受取顧客情報リストを送信する手順を説明したが、別の実施例として、個々の退職金企業情報をリスト化せずに、個々の退職金企業情報だけを個別に、銀行に送信するような構成でもよい。

図４は、図１のシステムで使用するデータ構造の一例を示す。

図４（ａ）は、主口座の決済情報のデータ構造２０１０を示しており、依頼人ＩＤ（依頼人名）、受取人ＩＤ（受取人名）、通信種目、勘定日、取引金額から構成されている。依頼人ＩＤは、資金の振り込みの依頼をする人や企業・法人等に割り振られたＩＤ（識別子）である。受取人ＩＤは、資金を受け取る人や企業・法人等に割り振られたＩＤである。通信種目は、振込（入金）の目的を示し、例えば、給与振込などである。勘定日は、入金された年月日を表している。取引金額は、入金された金額を示す。更に、当該データ構造には、主口座フラグを設けてもよい。主口座フラグとは、顧客（受取人）が、図３のＳ１０３０において、給与振込者であると判定されている時には、主口座であることを示す「１」を書き込んでもよい。一方で、図３のＳ１０３０において、給与非振込者であると判定されている時には、副口座であることを示す「０」を書き込んでもよい。また、主口座か副口座かを判定されていないときには、当該フラグをたてなくてもよい。

例えば、本実施例においては、図４（ａ）において、振込元である神奈川県から、振込先である個人Ａへ、２０１５年３月１５日まで、毎月５００，０００円が振り込まれていることが示されている（２０１４年１１月１５日より前の履歴は省略）。更に、２０１５年４月１０日には、１０，０００，０００円が振り込まれていることが示されおり、この大口入金が、退職金候補であると判定される。なお、ここでは、個人Ａに対して、他の振込元からの振込が無いと仮定する。

図４（ｂ）は、過去の給与振込履歴から、勤務先を判定するためのデータ構造２０２０である。決済情報から、特定の振込元（依頼人ＩＤ）と勘定日の期間とを指定することにより、所定のデータ構造（本実施例においては、勤務先を判定するためのデータ構造）を抽出することができる。ここでは、退職金候補と判定された振込は、除外する。

更に、図４（ｂ）では、抽出されたデータ構造に、データを加工するための付加情報を追加する。本実施例においては、「勘定年月」と称する項目を追加する。何年何月分の給与振込であることを、依頼人ＩＤ（本実施例においては、給与の振り込み元）毎に特定する。

図４（ｂ）に示すように、個人Ａへの振込を依頼人（ＩＤ）で、ソート（分類）し、勘定年月が毎月発生していることも判定基準に加味すれば、これら一連の振込が、通信種目を参照せずとも、給与振込であることが判定できる。なお、通信種目を参照しない理由のひとつは、振込元の企業・法人によって、通信種目が異なる（例えば、単に「振込」である）場合があるからである。

図４（ｃ）は、受給月数のデータ構造２０３０を示しており、勘定年月を基に、受給月数をカウントすることにより生成される。受給月数は、例えば、顧客が企業に在籍していた期間を示しているので、例えば、受給月数と、毎月の給与振込履歴から、退職金の金額を推定してもよい。

図４（ｄ）は、副口座の決済情報のデータ構造２０４０を示す。給与振込等が無いのに、大口入金がある（退職金候補が振り込まれる）と、副口座であると判定される。

本実施例によれば、例えば、銀行Ａの主口座で判定した結果を、同じ銀行Ａの副口座に適用することで、副口座の資金ニーズを把握することができる。すなわち、金融機関の主口座の情報を用いて、副口座の決済情報から顧客の資金ニーズを、高い精度で判定することが可能となる。

（実施例２）
図５は、本発明の実施例２を示す。実施例１では、各銀行のＥＢＭシステム内部に、退職金受取企業情報ＤＢを備えている構成を示したが、実施例２では、各銀行が備えている退職金受取企業情報ＤＢを、ＤＢ管理サーバを介して、共通に管理する共同化システム４００として構成した例を示している。なお、共同化システムは、特定の情報（ＭＣＩＦ）を共同管理するので、共同ＭＣＩＦセンターと称してもよい。

共同化システム１３０は、ＤＢ管理サーバ４０１と、退職金判定部２１５と、Ａ銀行用退職金受取企業情報ＤＢ４０３、Ｂ銀行用退職金受取企業情報ＤＢ４１３を備えている。また、Ａ銀行用退職金受取企業情報ＤＢ４１３と、Ｂ銀行用退職金受取企業情報ＤＢ４２３とのように、銀行毎にそれぞれの退職金受取企業情報ＤＢを設けることにより、各銀行で適切な情報を管理することができる。本実施例においては、ＤＢ管理サーバ４０１が全てのＤＢを制御しているが、別の実施例においては、ＤＢ毎に管理サーバを設けてもよい。

実施例２では、更に、実施例１とは異なり、共同化システム１３０内に、退職金判定部２１５が備えられているので、各銀行で退職金を判定する工程を省くことができる。また、退職金受取企業情報リストを相互に共有する複数の銀行を、共同化システムの管理下におくことができる。

図６は、実施例２の共同化システム１３０の処理の一例を示すフローチャートである。本実施例では、特に、Ａ銀行に退職金候補（大口入金）が入金された場合に、Ａ銀行またはＢ銀行の主口座で判定された結果を用いて、Ａ銀行に入金された退職金候補が退職金であることを判定することを示すための一例を示す。

Ｓ１２１０において、共同化システム１３０のＤＢ管理サーバ４０１は、各銀行（本実施例では、Ａ銀行、Ｂ銀行）から、退職金受取企業情報を取得する。退職金受取企業情報とは、例えば、退職金を振り込んだ企業と、振込日である。

Ｓ１２２０において、ＤＢ管理サーバ４０１は、Ａ銀行から取得した退職金企業情報を、Ａ銀行用退職金企業情報ＤＢ４１３に送信し、当該ＤＢ内の情報を更新するように指示する。同様に、ＤＢ管理サーバ４０１は、Ｂ銀行から取得した退職金企業情報をＢ銀行用退職金企業情報ＤＢ４１３に送信し、当該ＤＢ内の情報を更新するように指示する。ここで、Ｓ１２２０で取得する退職金企業情報は、各銀行において図３（ａ）で判定されたような手順に基づいて、退職金受取顧客情報リストを生成してもよい。

Ｓ１２３０において、共同化システム１３０のＤＢ管理サーバ４０１は、Ａ銀行から、Ａ銀行の副口座を有する顧客（給与非振込者）が退職金を受け取った否かの判定を依頼する信号を受信する。

Ｓ１２４０において、ＤＢ管理サーバ４０１は、Ａ銀行用退職金受取企業情報ＤＢ４１３にアクセスをして、退職金企業情報を照会する。もし、該当する退職金企業情報があれば、Ｓ１２５０へ進む。該当する退職金企業情報がなければ、Ｓ１２６０へ進む。

Ｓ１２５０において、ＤＢ管理サーバ４０１は、Ａ銀行用退職金受取企業情報ＤＢ４１３から退職金企業情報を取得する。

Ｓ１２６０において、Ａ銀行用退職金受取企業情報ＤＢ４１３に、該当する退職金企業情報がない場合は、別の銀行用の退職金受取企業情報ＤＢ（本実施例においては、Ｂ銀行用退職金受取企業情報ＤＢ４２３）にアクセスして、該当する退職金企業情報を取得する。別の銀行用の退職金受取企業情報ＤＢにも、該当する退職金企業情報がない場合は、ＤＢ管理サーバ４０１が、取得不可能であることを示す信号を生成してもよい。

Ｓ１２７０において、ＤＢ管理サーバ４０１は、取得した退職金企業情報を基に、給与非振込者が退職金を受け取ったか否かを判定する。

Ｓ１２８０において、ＤＢ管理サーバ４０１は、Ｓ１２７０の判定結果を、Ａ銀行の退職金企業情報ＤＢ４０３に送信して、退職金企業情報ＤＢ４１３の情報を更新するように指示する。

Ｓ１２９０において、ＤＢ管理サーバ４０１は、Ｓ１２７０の判定結果を、Ａ銀行へ送信する。なお、Ｓ１２９０は、Ｓ１２８０よりも前に実行してもよい。

Ｓ１３００において、ＤＢ管理サーバ４０１は、Ｓ１２７０における判定結果を基に、退職金受取顧客情報リストを更新してもよい。また、更新した退職金受取顧客情報リストを任意の銀行に送信してもよい。

別の実施例として、Ｓ１２３０で、ＤＢ管理サーバ４０１は、Ａ銀行またはＢ銀行から、退職金受取顧客情報リストを依頼する信号を受信した場合に、ＤＢ管理サーバ４０１は、Ａ銀行用退職金受取企業情報ＤＢ４１３および／またはＢ銀行用退職金受取企業情報ＤＢ４２３にアクセスして、必要な退職金受取顧客情報リストを生成し、当該依頼をした銀行へ返信するような構成でもよい。

本実施例によれば、複数の金融機関で共同システムを使用して決済情報を取り扱うことで、対象顧客数を増やすとともに、一部については取引を事前に把握することで、顧客の資金ニーズを判断することができる。

本実施例によれば、共同システムで資金ニーズを把握するため、営業エリア外であっても、共同システム参加金融機関と取引がある企業であれば、より精度よく判定できる。すなわち、本実施例によれば、金融機関（特に、地方金融機関）の営業エリア外の取引を把握することによって、自己の金融機関で主口座や副口座を有する顧客の資金ニーズを、高い精度で判定することができる。

（実施例３）
本実施例は、実施例１の変形例であり、アパートのローンの契約をしており、定期的にローンを返済すると共に、アパートから賃料収入を受けている主口座の情報を基に、アパートのローンの契約は他行で契約していないが、賃料収入を受けている副口座を推定する例を示す。

図６は、実施例３のシステムの機能ブロック図である。説明の便宜上、図６では、Ａ銀行のＥＢＭシステム２００の機能ブロック図のみを示す。
制御部６１１は、後述する各部を制御する。
賃貸先判定部６１２は、口座Ａにおける過去のローン返済履歴の情報等を用いて、当該口座を有する顧客が、アパートを賃貸している企業・法人等を判定する。

過去返済履歴判定部６１３は、顧客が、毎月（若しくは所定の間隔で）、特定の企業等から、一定の金額が振り込まれていることを検索して、これら一連の振込を賃料収入であると判定する。また、必要に応じて、賃料収入の履歴（リスト）を作成する。

賃料収入候補入金判定部６１４は、特定の口座に、賃料収入と思われる入金が確認されたときに、その入金を「賃料収入候補」であると判断する。

賃料収入判定部６１５は、口座Ａに、賃料収入候補と判定された入金について、当該入金を、ローン契約情報などの口座を開設している顧客属性データを基に、賃料収入であるか否かを判定する。

ここで、顧客の属性データは、後述する顧客属性ＤＢ６３２に記憶されている。顧客の属性データは、多様な情報が含まれていてもよく、例えば、顧客自身の情報に加えて、顧客に関連する情報（例えば、家族構成の情報、名寄せの情報）を含めてもよい。また、賃料収入判定部６１５は、賃料の振込口座と、ローンの口座が同一であることも判定してもよい。

顧客口座ＤＢ６３１（ＤａｔａＢａｓｅ）は、各顧客の口座毎に預金されている資金を管理している。また、口座毎の決済情報を基に、取引の履歴を管理してもよい。

顧客属性ＤＢ６３２は、顧客の属性データ（例えば、顧客の氏名（法人名）、住所、生年月日、職業、家族構成などの顧客固有の情報）が記録されている。また、顧客によっては、同一の銀行に複数の口座（例えば、普通預金の口座と定期預金の口座）を開設している場合がある。そのような顧客を一元管理するために（いわゆる名寄せを適切に管理するために）、当該複数の口座が同一顧客であることを識別するための識別子等を用いて、当該複数の口座を管理できるように構成されていてもよい。

決済情報ＤＢ６３３は、自行の預金の流動性に関する流動性資金情報や、為替レートなど資金の決済に必要な情報（決済情報）を蓄積するための装置である。

賃料収入受取顧客ＤＢ６３４は、賃料収入判定部６１５で、賃料が入金されたと判定された場合に、該当する顧客情報として、賃料収入を受け取ったことを書き込む。更に、賃料を振り込んだ企業名および振込日も書き込んでもよい。

賃料収入受取顧客情報ＤＢ６０３は、賃料収入を受け取った顧客に関する情報を記録している。

図８（ａ）（ｂ）は、図７で示した機能ブロックにおける処理の流れを示すフローチャートである。以下、本実施例における処理の流れを、図８を用いて説明する。

図８（ａ）は、自行に主口座を有している（ローン契約をしている）顧客が賃料収入を受け取ったどうかを判定するためのフローチャートである。

Ｓ２０１０では、決済処理に基づいて、指定された顧客の口座に、指定された金額を振り込むための入金処理を行う。

Ｓ２０２０では、決済情報に基づく入金処理で、賃料収入である可能性がある入金であるか否かを判定する。本実施例では、このような入金を、「賃料収入候補」と称することにする。賃料収入候補の判定方法については、各金融機関が個別に当該所定の金額を決定してもよく、複数の金融機関や共通のサーバなどが当該所定の金額を決定してもよい。

Ｓ２０３０では、賃料収入候補が入金された顧客が、現在若しくは過去にローンの契約をしていたかどうかを判定する。自行（例えば、Ａ銀行）ではローン契約をしていなかったが、他行（例えば、Ｂ銀行）でローン契約をしている可能性がある。すなわち、ローンの支払い口座と、賃料の受取口座が異なる可能性があるからである。もし、ローン契約をしていたら、ローン契約者であると判定する。すなわち、本実施例においては、このローン契約者は、自行（例えば、Ａ銀行）に主口座を有している顧客であることを意味する。

また、自行でローン契約をしていなければ、ローン非契約者であると判定する。ローン非契約者であると判定された場合の処理は、図８（ｂ）で説明する。すなわち、本実施例においては、このローン非契約者は、他行（例えば、Ｂ銀行）に主口座を有している可能性のある顧客ではあるが、自行（例えば、Ａ銀行）には主口座を有しておらず副口座を有している顧客であることを意味する。

なお、ＤＢ上に、ローン契約者とローン非契約者とを識別するための識別子やフラグなどを付加してもよい。

Ｓ２０４０では、賃料収入候補が振り込まれた顧客の中から、ローン契約者を抽出する。

Ｓ２０５０では、過去の返済を検索して、抽出されたローン契約者のローン返済履歴を作成する。

Ｓ２０６０では、過去のローン返済等の振込の履歴に基づいて、賃貸先を判定する。

Ｓ２０７０では、Ｓ２０６０までの処理の結果に加えて、顧客の属性データから必要な情報（例えば、ローン契約の情報）を入手して、入金された賃料収入候補が賃料収入であるか否かを判定する。例えば、ローン契約の情報から、毎月どれだけの賃料収入が見込めるかを推定することによって、賃料収入であるか否かを判定してもよい。

Ｓ２０８０では、賃料収入であることが判定されると、主口座の賃料収入受取顧客情報リストを更新する。この賃料収入受取顧客情報リストとは、賃料を振り込んだと推定される企業・法人名と振込日とから構成されている。

Ｓ２０９０では、賃料収入候補が入金された全てのローン契約者に対して判定が終了したか否かを判断する。賃料収入候補が入金された全てのローン契約者に対して、判定を行ったのであれば、Ｓ２１００へ進む。判定が必要なローン契約者が残っていれば、Ｓ２０４０へ戻って、本処理を継続する。

Ｓ２１００では、賃料収入受取顧客情報リストを賃料収入受取顧客情報ＤＢに送信して、賃料収入受取顧客情報ＤＢで管理しているリストを更新する。これにより、該当する顧客が賃料収入を受け取ったことが賃料収入受取顧客情報ＤＢに記録される。

Ｓ２１１０では、更新された賃料収入受取顧客情報リストを、自行内の営業担当者へ通知する。賃料収入があると判定された後は、人間がわかるようなデータ形式で出力（例えば、電子メールで送信）して、当該口座の営業担当者へ連絡したり、コールセンターの担当者へ連絡したりする。これにより、営業担当者やコールセンターの担当者は、該当する顧客へ訪問したり、電話をかけたりして、顧客の資金ニーズに応じた金融商品を提示することができる。なお、後述する図８（ｂ）の処理を引き続き実行する時などは、Ｓ２１１０を省略してもよい。

図８（ｂ）は、自行に主口座を有していないが副口座（主口座以外の口座）を有している顧客が賃料収入を受け取っているか否かを判定するためのフローチャートである。
ここで、ローンの契約口座と賃料の振込を受ける口座が同一ではない顧客もいる。すなわち、ローンの契約口座は、Ａ銀行であったが、賃料の振込を受ける口座がＢ銀行である場合がある。そのような顧客を有するＢ銀行の口座には、ある日突然、所定の金額（入金）が振り込まれることになる。このような場合は、賃料収入受取顧客情報ＤＢにアクセスして、同日に、同一の振込元から振り込みがあったかどうかを確認する。賃料収入受取顧客情報ＤＢから、賃料を振り込んだ企業の有無を確認して、もし該当する企業があれば、Ｂ銀行に振り込まれたものは、賃料収入であると判定する。

図８（ｂ）の処理は、図８（ａ）の処理が終了した後に実行される処理であってもよい。

Ｓ２０４１では、Ｓ２０３０において判定されたローン非契約者を抽出する。ローン非契約者とは、自行に主口座を有していないが副口座（主口座以外の口座）を有している顧客を意味する。

Ｓ２０４２では、賃料収入受取顧客情報ＤＢにアクセスして、賃料収入受取顧客情報リストを受信する。

Ｓ２０７１では、賃料収入受取顧客情報ＤＢからの情報を基に、自行に入金された賃料収入候補と同日に同一の振込元から、賃料の入金があったことが賃料収入受取顧客情報リストに記録されているかどうかを確認する。賃料収入受取顧客情報リストでは、賃料を入金した企業名と入金日に関する情報が管理されている。更に、顧客属性ＤＢ２３２などから、副口座の属性データを取得して、副口座を有している顧客の情報を特定してもよい。このような情報を基に、賃料収入候補が、真の賃料収入であるか否かが判断される。例えば、賃料収入候補の入金と同日に、同じ振込元（企業）から、副口座に、入金があれば、その賃料収入候補は、賃料収入であると判定できる。ただし、賃料収入の金額は、物件によって異なるので、賃料収入と判定するための金額の範囲を予め決めておいてもよい。

Ｓ２０８１では、賃料収入であることが判定されると、副口座の賃料収入受取顧客情報リストを更新する。この賃料収入受取顧客情報リストとは、賃料を振り込んだと推定される企業・法人名と振込日とから構成されている。なお、副口座の賃料収入受取顧客情報リストについては、図８（ａ）のＳ２０８０で作成した主口座の賃料収入受取顧客情報リストに上書きするように更新してもよく、主口座の賃料収入受取顧客情報リストとは別個に作成してもよい。

Ｓ２０９１では、賃料収入候補が入金された全ての給与所得者に対して判定が終了したか否かを判断する。賃料収入候補が入金された全ての給与所得者に対して、判定を行ったのであれば、Ｓ１１００へ進む。判定が必要な給与所得者が残っていれば、Ｓ１０４１へ戻って、本処理を継続する。

Ｓ２１０１では、賃料収入受取顧客情報リストを賃料収入受取顧客情報ＤＢに送信して、賃料収入受取顧客情報ＤＢで管理しているリストを更新する。これにより、該当する顧客が賃料収入を受け取ったことが賃料収入受取顧客情報ＤＢに記録される。

Ｓ２１１１では、更新された賃料受取顧客情報リストを、自行内の営業担当者へ通知する。ここで、賃料収入受取顧客情報リストは、主口座のみから判定された情報（賃料を振り込んだ企業・法人名と、その振込日）のみ、又は副口座から判定された情報のみから構成されてもよく、これらの情報を組み合わせた情報から構成されてもよい。賃料収入と判定された後は、人間がわかるようなデータ形式で記録された情報を出力（例えば、電子メールで送信）して、当該口座の営業担当者へ連絡する。

実施例１〜３で示したように、本発明においては、過去の振込履歴を基に、主口座と副口座とに分類し、主口座の振込情報を基に、副口座に振り込まれた大口入金の目的を判断することによって、主口座だけでなく副口座を有する顧客の資金ニーズを高精度で把握することができるようになる。

以上のように本発明の実施態様について説明したが、上述の説明に基づいて当業者にとって種々の代替例、修正又は変形が可能であり、本発明はその趣旨を逸脱しない範囲で前述の種々の代替例、修正又は変形を包含するものである。

１００ システム
２００、３００ ＥＢＭシステム
２１０、３１０ 行内サーバ
２１１、３２０ 制御部
２１２ 勤務先判定部
２１３ 過去給与振込判定部
２１４ 退職金候補入金判定部
２１５ 退職金判定部
２２０ 端末
２３０ 行内ＤＢ
２３１ 顧客口座ＤＢ
２３２ 顧客属性ＤＢ
２３３ 決算情報ＤＢ
２３４ 退職金受取顧客ＤＢ
４０１ ＤＢ管理サーバ
４０３ 退職金受取企業情報ＤＢ
５００ ネットワーク

Claims (5)

1. 金融口座を管理するコンピュータ・システムにおいて、
   過去の振込履歴を基に、所定の継続的な振込を受けているまたは所定の継続的な振込をしている主口座と、所定の継続的な振込がない副口座とに分類する手段と、
   前記主口座に振り込まれた入金が、前記主口座の属性データを基に、所定の目的を持った入金であると判定する手段と、
   前記副口座に入金された入金が、所定の目的を持った入金である可能性がある入金候補であることを判定する手段と、
   前記副口座に振り込まれた入金候補の振込元と振込日が、前記主口座に振り込まれた入金の振込元と振込日と一致する場合に、前記副口座に入金された前記入金候補が、前記副口座の属性データを基に、前記主口座に振り込まれた入金と同じ目的の入金であることを判定する手段と、
   を備えることを特徴とするシステム。
2. 金融口座を管理するコンピュータ・システムにおいて、
   過去の給与振込履歴を基に、給与振込がある主口座と給与振込がない副口座とに分類する手段と、
   前記主口座に振り込まれた大口入金が、前記主口座の属性データを基に、退職金であると判定する手段と、
   前記副口座に振り込まれた大口入金が、退職金候補であると判定する手段と、
   前記副口座に振り込まれた前記退職金候補の振込元と振込日が、前記主口座に振り込まれた退職金の振込元と振込日と一致する場合に、前記副口座に入金された前記退職金候補が、前記副口座の属性データを基に、退職金であると判定する手段と、
   を備えることを特徴とするシステム。
3. 金融口座を管理するコンピュータ・システムにおいて、
   過去の返済履歴を基に、ローンの契約をしている主口座とローンの契約をしていない副口座とに分類する手段と、
   前記主口座に振り込まれた入金が、前記主口座の属性データを基に、賃料収入であると判定する手段と、
   前記副口座に振り込まれた入金が、賃料収入候補であると判定する手段と、
   前記副口座に振り込まれた前記賃料収入候補の振込元と振込日が、前記主口座に振り込まれた賃料収入の振込元と振込日と一致する場合に、前記副口座に入金された前記賃料収入候補が、前記副口座の属性データを基に、賃料収入であると判定する手段と、
   を備えることを特徴とするシステム。
4. 金融口座を管理するコンピュータ・システムにおいて、
   複数のＥＢＭシステムと、
   共同化システムと、
   を備え、
   前記複数のＥＢＭシステムは、それぞれ
   過去の振込履歴を基に、所定の継続的な振込がある主口座と、所定の継続的な振込がない副口座とに分類する手段を備え、
   前記複数のＥＢＭシステムの一方が、
   前記主口座に振り込まれた入金が、前記主口座の属性データを基に、所定の目的を持った入金であると判定して、共同化システムへ送信する手段を備え、
   前記複数のＥＢＭシステムの一方または他方が、
   前記副口座に振り込まれた入金が、所定の目的を持った入金である可能性がある入金候補であることを判定して、前記共同化システムに問い合わせの信号を送信する手段を備え、
   前記共同化システムは、
   前記副口座に振り込まれた入金候補の振込元と振込日が、前記主口座に振り込まれた入金の振込元と振込日と一致する場合に、前記副口座の属性データを基に、前記副口座に入金された前記入金候補が、前記主口座に振り込まれた入金と同じ目的の入金であることを判定する手段と、
   を備えることを特徴とするシステム。
5. 金融口座を管理するためのコンピュータ・プログラムにおいて、
   過去の振込履歴を基に、所定の継続的な振込を受けているまたは所定の継続的な振込をしている主口座と、所定の継続的な振込がない副口座とに分類する手段と、
   前記主口座に振り込まれた入金が、前記主口座の属性データを基に、所定の目的を持った入金であると判定する手段と、
   前記副口座に振り込まれた入金が、所定の目的を持った入金である可能性がある入金候補であることを判定する手段と、
   前記副口座に振り込まれた入金候補の振込元と振込日が、前記主口座に振り込まれた大口入金の振込元と振込日と一致する場合に、前記副口座に入金された前記入金候補が、前記副口座の属性データを基に、前記主口座に振り込まれた入金と同じ目的の入金であることを判定する手段と、
   を備えることを特徴とするプログラム。