JP2018124773A - 銀行システム、銀行システムによって実行される方法、及びプログラム - Google Patents

Abstract

【課題】銀行システムにおいて、「非公開情報の同意」を管理している顧客である保険契約の契約者が死亡により、当該「非公開情報の同意」にかかる口座及び保険契約が、当該保険契約の被保険者に相続されたことに応じて、当該口座及び保険契約にかかる「非公開情報の同意」を変更する。
【解決手段】銀行システム１００が、保険会社システム１２０から保険契約者死亡による当該保険契約の名義変更があったことを示すデータを受信し（Ｓ１２０１）、名義変更された口座の当該名義変更が、保険契約の保険契約者死亡によるものであると決定し（Ｓ１２０７）、口座の新しい名義人が保険契約の被保険者であり、且つ保険契約の新しい契約者が当該保険契約の被保険者であることを決定し（Ｓ１２１１）、口座に関連付けられた「非公開情報の同意」を、死亡した保険契約者のものから予め取得しておいた被保険者のものに変更する（Ｓ１２１３）。
【選択図】図１２

Description

本発明は、銀行システム、銀行システムによって実行される方法、及びプログラムに関し、より詳細には、銀行が顧客から提供された非公開情報を管理する銀行システム、銀行システムによって実行される方法及びプログラムに関する。

平成１９年１２月に銀行による保険商品の販売が全面解禁され、いわゆる、銀行窓販が行われている（例えば、特許文献１参照）。銀行窓販の全面解禁に伴い、銀行窓販に係る弊害防止措置が設けられた。例えば、非公開情報保護措置（施行規則第２１２条第２項第１号）では、「非公開情報」の保護について定めている。「非公開情報」には、銀行の顧客情報である「非公開金融情報」と、保険募集に関連して知得した情報である「非公開保険情報」とがある。「非公開金融情報」は、預金などの銀行取引のために顧客から銀行に提供された情報であるため、非公開情報保護措置は、これを保険販売に利用することを禁止している。また、非公開情報保護措置は、「非公開保険情報」を、保険募集以外の銀行の業務に利用するときは、顧客の同意を得ることを要求している。

したがって、銀行は、預金などの銀行取引が既にある顧客に対して、保険販売を行う場合には、当該既存の銀行取引の際に提供された非公開情報（非公開金融情報）を利用することについて、予め当該顧客から同意（本明細書において「非公開金融情報の同意」とも言う。）を得て、管理している。その後の保険契約時には、銀行は、さらに、保険募集の際に顧客（すなわち、保険契約者）から提供された情報（非公開保険情報）を、保険募集以外の銀行の業務に利用することについて、当該保険契約者から同意（本明細書において「非公開保険情報の同意」とも言う。）を得て（例えば、保険契約に関する重要事項確認書等の形態で取得し）、管理している。

また、銀行が既存の銀行取引の無い客と保険販売を行う場合（すなわち、銀行が非公開金融情報を取得していない場合）には、銀行は、保険募集時に、顧客として登録するとともに当該顧客（すなわち、保険契約者）から「非公開金融情報の同意」及び「非公開保険情報の同意」（本明細書において「非公開情報の同意」とも言う。）を得て、管理している。

このように、銀行は、「非公開情報の同意」を得ることで、その後において、当該銀行の顧客且つ保険契約の契約者に対して、「非公開金融情報」を保険販売に利用できるようになり、また、「非公開保険情報」を保険募集以外の銀行の業務に利用できるようになる。この結果、銀行は、例えば、保険契約後のアフターフォローや新たな金融取引の提案などの情報提供を顧客（保険契約者）に対して行うことができるようになる。

図１は、従来の銀行システム１００を含むシステム全体の概要図である。図１を参照すると、銀行システム１００は、共同ゲートウェイ（ＧＷ）サーバ１１０を介して１つ以上の保険会社システム１２０にネットワークを経由して接続されることが可能である。また、銀行システム１００は、１つ以上のオペレータ端末１３０にネットワークを経由して接続されることが可能である。銀行システム１００と保険会社システム１２０との間、及び銀行システム１００とオペレータ端末１３０との間で利用可能なネットワークは、専用線、ＬＡＮ、ＷＡＮ、あるいは、これらと同様の機能を果たす他の種類のネットワークとすることができる。

図２は、従来の銀行システム１００のシステム構成図である。図２に示すように、銀行システム１００は、一般的なコンピュータと同様に、バス２１０などによって相互に接続された制御部２０１、主記憶部２０２、補助記憶部２０３、インターフェース（ＩＦ）部２０４及び出力部２０５を備えることができる。銀行システム１００はまた、ファイル／データベースとして、顧客マスタ２０６、設計書ＤＢ２０７及び非公開情報ＤＢ２０８を備えることができる。

制御部２０１は、中央処理装置（ＣＰＵ）とも呼ばれ、銀行システム１００内の各構成要素の制御やデータの演算を行い、また、補助記憶部２０３に格納されている各種プログラムを主記憶部２０２に読み出して実行することができる。主記憶部２０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令及び当該命令による演算処理後のデータなどを記憶することができる。補助記憶部２０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。

図２では、制御部２０１、主記憶部２０２及び補助記憶部２０３を同一のサーバコンピュータ内に設ける例を示したが、銀行システム１００は、制御部２０１、主記憶部２０２及び補助記憶部２０３を複数個使用することにより、複数のサーバコンピュータによる並列分散処理を実現するように構成されることもできる。あるいは、銀行システム１００用の複数のサーバを設置し、複数サーバが一つの補助記憶部２０３を共有する実施形態にすることも可能である。後述する、本願発明の実施形態の銀行システム１００においても、同様である。

ＩＦ部２０４は、他のシステムや装置との間でデータを送受信する際のインターフェースの役割を果たし、また、オペレータ端末１３０から各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供することができる。出力部２０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供することができる。

顧客マスタ２０６は、銀行顧客の基礎情報を格納する顧客マスタファイルであり、取引先番号（ＣＩＦ（Customer Information File）番号ともいう）を含むマスタファイルである。顧客が銀行との取引を新規に行う場合には、顧客マスタ２０６に顧客情報が登録されることになる。なお、保険への加入に際して、窓口を訪れた顧客は銀行との取引があるものの、被保険者は銀行との取引がない場合もある（例えば、夫婦のうち夫が銀行との取引があるが、妻である被保険者には銀行との取引がない場合）が、その場合には、顧客マスタ２０６に銀行との取引がなかった被保険者などのデータが登録されることになる。

図３は、顧客マスタ２０６のデータ構造の一例を説明する図である。図３に示すように、顧客マスタ２０６は、店番号３０１、取引先番号３０２、銀行口座情報３０３、属性情報３０４、及び証券番号３０５を含むことができる。顧客が同一銀行内の複数の営業店に口座を保有する場合に、それらの口座を結びつける共通番号（例えば、「名寄せ」処理などの際に利用可能な個人識別番号）を含むように構成されてもよい。

店番号３０１は、銀行顧客を管理するそれぞれの営業店を識別する番号であり、取引先番号３０２は、当該営業店における顧客を識別する番号である。店番号３０１及び取引先番号３０２を合わせてＣＩＦ番号（取引先番号）と呼ぶこともできる。すなわち、図３の例では、店番号３０１及び取引先番号３０２を異なるデータ項目として示したが、両者を合わせて１つのデータ項目として構成することもできる。

銀行口座情報３０３は、顧客の銀行口座の情報であり、店番号、科目、口座番号、口座名義などの情報を含むことができる。属性情報３０４は、顧客の氏名、カナ氏名、住所、連絡先などの情報を含むことができる。

証券番号３０５は、顧客が正式に保険に加入した際に発行される保険証券に付された証券番号を示す。後述するように、証券番号は、保険契約の申し込みが成立した際に保険会社システム１２０が発行するものである。しがたって、申し込みが成立するまでの間、証券番号３０５は、設計書番号（保険会社システム１２０又は銀行システム１００が証券番号とは別に発行する。顧客が加入を検討している１つ以上の保険商品に関連付けられた設計書のデータを識別する。）を示してもよい。証券番号３０５は、設計書ＤＢ２０７に格納されている、設計書を作成するための元データを識別する番号あるいは保険契約を識別する番号として機能することもできる。なお、設計書は書面の形式で作成されるものであるため、設計書を作成するための元データとは、設計書に含まれる各種データのことを指す。

非公開情報３０６は、非公開情報の情報であり、顧客から提供され、非公開情報ＤＢ２０８に格納された非公開情報へのリンクを含むことができる。

図４は、設計書ＤＢ２０７のデータ構造の一例を説明する図である。設計書ＤＢ２０７は、顧客が加入を検討している、又は既に加入済みの、１つ以上の保険商品の設計書を作成するための元データを格納するデータベースである。設計書ＤＢ２０７は、設計書を作成するデータを格納するようにさらに構成されることも可能である。保険加入時に作成される設計書は、保険や保障の内容を詳しく説明するために提示する書類であり、保険の契約内容（主契約、特約などを含む）、保険料払込方法、契約者・被保険者などの情報以外にも、契約申込書、取扱報告書（補足資料含む）、受取人指定書なども含む、従来から存在する書類である。このため、本明細書では、設計書に記載される各項目についての詳細な説明は省略することとする。

設計書ＤＢ２０７は、データ項目として、契約者の店番号４１０及び取引先番号４１１（ＣＩＦ番号）、保険会社コード４０１、証券番号４０２、受付管理ＩＤ４０３、保険商品名４０４、契約者生年月日４０５、契約者名４０６、保険内容４０７、保険料明細４０８及び提案内容４０９を含むことができる。

契約者の店番号４１０、銀行顧客を管理するそれぞれの営業店を識別する番号であり、顧客マスタ２０６に格納された店番号３０１と一致する。取引先番号４１１は、当該営業店における顧客を識別する番号であり、顧客マスタ２０６に格納された取引先番号３０２と一致する。顧客マスタ２０６と設計書ＤＢ２０７とは、ＣＩＦ番号（店番号及び取引先番号）により関連付けられることができる。

保険会社コード４０１は、保険会社の識別番号を示し、証券番号４０２は、顧客に対して提示された設計書を識別するための番号、及び保険証券に付された証券番号を識別するための番号である。設計書を作成するための元データが銀行システム１００から保険システム１２０に提供されて保険システム１２０によって設計書が作成されることになるが、例えば、設計書番号は、保険システム１２０によって採番され得る。受付管理ＩＤ４０３は、設計書を作成するための元データを識別する識別子であり、銀行システム１００内で採番される識別番号である。受付管理ＩＤ４０３は、銀行システム１００から保険会社システム１２０に送信されて、両システム内のデータを関連付けるために使用されることが可能である。

保険商品名４０４は、顧客に提示される保険の名称（保険を識別するコードを含む）を示す。契約者生年月日４０５及び契約者名４０６は、それぞれ、契約者の生年月日及び氏名（カナ氏名含む）を示し、これらのデータ項目は、設計書がどの顧客に関連付けられるかを識別するためにも使用され得る。

保険内容４０７は、保険の契約内容を示し、例えば、契約者、被保険者、保険金額、保険料、払込期間満了年齢、保険契約タイプ、払込回数、払込経路、手数料、保険の仕組みを説明するための仕組図（イメージ）などの情報を含むことができる。保険料明細４０８は、月々の払込保険料の明細を示しうる。提案内容４０９は、顧客に対して提案する保険料の払込パターン、例えば、具体的な保険料、払込期間満了年齢、払込回数、払込経路などの情報を含むことができる。提案内容４０９に含まれる情報は、保険会社システム１２０内で生成され、それらの情報が設計書ＤＢ２０７に格納されることが可能である。

非公開情報ＤＢ２０８は、顧客から提供され、顧客マスタ２０６内にリンクが設定された非公開情報が格納されている。顧客から提供され非公開情報は、非公開情報の同意（「非公開金融情報の同意」及び「非公開保険情報の同意」）を含むことができる。

図５は、非公開情報ＤＢ２０８のデータ構造の一例を説明する図である。非公開情報ＤＢ２０８は、データ項目として、店番号５０１及び取引先番号５０２（ＣＩＦ番号）、受付管理ＩＤ５０３、並びに非公開情報５０４等を含み、これらを関連付けて格納している。非公開情報５０４は、重要事項書の内容、非公開情報の同意（「非公開金融情報の同意」及び「非公開保険情報の同意」）の有無、同意の日時、同意の取得方法、同意の取得の経緯などを含むことができる。これにより、銀行は、図１に示すように銀行システムを用いて顧客マスタを関連付けて「非公開情報の同意」を管理することができる。

特許第６０４６７９３号

ところで、上述したように、銀行は、顧客（保険契約者）から得た「非公開情報の同意」を管理するものの、保険契約の被保険者については、「非公開情報の同意」を管理していない。

したがって、銀行は、保険契約の被保険者から別途に、「非公開金融情報の同意」を事前に得なければ「非公開金融情報」を保険販売に利用できず、また、「非公開保険情報の同意」を事前に得なければ「非公開保険情報」を保険募集以外の銀行の業務に利用できない。例えば、銀行が「非公開情報の同意」を管理している顧客（保険契約者）が死亡した場合にはこのような不都合が生じ得る。

銀行が、銀行取引のある夫を保険契約者とし、銀行取引のない妻を被保険者とする保険を販売し、夫の「非公開情報の同意」を管理している場合を例示する。夫（顧客且つ保険契約者）が死亡した場合に、夫の銀行取引に係る口座の名義が妻（被保険者）に変更され、当該保険の契約者名義が、死亡した夫（元の保険契約者）から妻（被保険者）に変更されたとする。この場合、銀行が管理している当該口座に関する銀行取引についての「非公開金融情報の同意」は、死亡した夫により同意されたものであるから、当該「非公開金融情報」を利用して、新しい名義人である妻に対して、保険販売を行うためには、事前に妻から同意を得て管理しておく必要がある。同様に、銀行が管理している当該保険契約についての「非公開保険情報の同意」は、死亡した夫により同意されたものであるから、当該「非公開保険情報」を保険募集以外の銀行の業務に利用するためにも、事前に妻から同意を得て管理しておく必要がある。

したがって、銀行は、当該銀行が「非公開情報の同意」を管理している顧客（保険契約者）が死亡し、当該「非公開情報の同意」にかかる、口座及び保険契約が、保険契約の被保険者に相続された場合には、速やかに且つ確実に、相続人である被保険者から、当該口座及び保険契約にかかる「非公開情報の同意」を得て管理できるようにすることが望ましい。相続人である被保険者から、「非公開情報の同意」を得られない場合には、速やかに且つ確実に、死亡者から得た「非公開情報の同意」を無効にすることが望ましい。

本発明は、このような問題に鑑みてなされたもので、その目的とするところは、銀行システムにおいて、「非公開情報の同意」を管理している顧客である保険契約の契約者の死亡により、当該「非公開情報の同意」にかかる口座及び保険契約が、当該保険契約の被保険者に相続されたことに応じて、当該口座及び保険契約にかかる「非公開情報の同意」の管理状態を変更できるようにすることにある。

このような目的を達成するために、本願発明の一態様である銀行システムは、保険契約に際して銀行顧客から提供された非公開情報の同意を格納する非公開情報データベースと、銀行顧客の基礎情報を格納する顧客マスタファイルであり、口座の情報及び保険契約を識別する識別子を含み、非公開情報の同意と関連付けられている、顧客マスタファイルと、口座名義変更が行われた口座の情報を格納する口座名義人変更データベースであり、新しい口座名義人を含む、口座名義人変更データベースと、保険会社システムから、保険契約者の死亡による保険契約の契約者名義変更があったことを示すデータであり、契約者名義変更があった保険契約を識別する識別子、及び新しい保険契約者の情報を含むデータを受信する通信手段と、口座名義変更が行われた口座について、保険会社システムから受信したデータに基づいて、口座名義変更が、保険契約者の死亡によるものであると決定する手段と、口座名義変更が行われた口座の新しい口座名義人が保険契約の被保険者であり、且つ保険契約の新しい保険契約者が保険契約の被保険者であると決定する手段と、口座名義変更が行われた口座に関連付けられた非公開情報の同意を、死亡した保険契約者のものから、被保険者から保険契約に際して予め取得し非公開情報データベースに格納しておいたものに変更する手段とを備えた、ことを特徴とする。

一実施形態では、口座名義変更が保険契約者の死亡によるものであると決定された場合、且つ口座名義変更が行われた口座の新しい口座名義人が保険契約の被保険者ではない、又は保険契約の新しい保険契約者が保険契約の被保険者ではないと決定された場合に、口座名義変更が行われた口座に関連付けられた非公開情報の同意を削除する手段をさらに備えたことを特徴とする。一実施形態では、通信手段は、オペレータ端末と通信して、非公開情報の同意を受信することを特徴とする。また、銀行システムは、保険会社システムから受信したデータを格納する保険契約者名義変更データベースをさらに備えた、ことを特徴とする。

本願は発明の一態様である銀行システムにより実行される方法である。銀行システムは、保険契約に際して銀行顧客から提供された非公開情報の同意を格納する非公開情報データベースと、銀行顧客の基礎情報を格納する顧客マスタファイルであり、口座の情報及び保険契約を識別する識別子を含み、非公開情報の同意と関連付けられている、顧客マスタファイルと、口座名義変更が行われた口座の情報を格納する口座名義人変更データベースであり、新しい口座名義人を含む、口座名義人変更データベースとを備え、当該方法は、銀行システムが、保険会社システムから、保険契約者の死亡による保険契約の契約者名義変更があったことを示すデータであり、契約者名義変更があった保険契約を識別する識別子、及び新しい保険契約者の情報を含むデータを受信することと、銀行システムが、口座名義変更が行われた口座について、保険会社システムから受信したデータに基づいて、口座名義変更が、保険契約者の死亡によるものであると決定することと、銀行システムが、口座名義変更が行われた口座の新しい口座名義人が保険契約の被保険者であり、且つ保険契約の新しい保険契約者が保険契約の被保険者であると決定することと、銀行システムが、口座名義変更が行われた口座に関連付けられた非公開情報の同意を、死亡した保険契約者のものから、被保険者から保険契約に際して予め取得し非公開情報データベースに格納しておいたものに変更することとを備える、ことを特徴とする。

本願は発明の一態様は、上記方法をコンピュータに実行させるコンピュータプログラムである。

以上説明したように、本発明によれば、銀行システムにおいて、「非公開情報の同意」を管理している顧客である保険契約者の死亡により、当該「非公開情報の同意」にかかる口座及び保険契約が、保険契約の被保険者に相続されたことに応じて、当該口座及び保険契約にかかる「非公開情報の同意」の管理状態を変更することが可能になる。

従来の銀行システムを含むシステム全体の概略図である。 従来の銀行システムの構成図である。 従来の顧客マスタのデータ構造の一例を説明する図である。 従来の設計書ＤＢのデータ構造の一例を説明する図である。 本発明の一実施形態の非公開情報ＤＢのデータ構造を説明する図である。 本発明の一実施形態の銀行システムの構成図である。 本発明の一実施形態の設計書ＤＢのデータ構造を説明する図である。 本発明の一実施形態の受付管理ＩＤ ＤＢのデータ構造を説明する図である。 本発明の一実施形態の銀行システムにより実行される処理を説明するフロー図である。 本発明の一実施形態の口座名義変更ＤＢのデータ構造を説明する図である。 本発明の一実施形態の保険契約者名義変更ＤＢのデータ構造を説明する図である。 本発明の一実施形態の銀行システムにより実行される処理を説明するフロー図である。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。同一又は類似の参照符号は、同一又は類似の要素を示す。

図６は、本発明の一実施形態にかかる銀行システムを示す構成図である。図６に示すように、銀行システム１００は、バス２１０などによって相互に接続された制御部２０１、主記憶部２０２、補助記憶部２０３、インターフェース（ＩＦ）部２０４及び出力部２０５を備えることができる。銀行システム１００はまた、ファイル／データベースとして、顧客マスタ２０６、設計書ＤＢ２０７、非公開情報ＤＢ２０８、受付管理ＩＤ ＤＢ６０１、口座名義変更ＤＢ６０２及び保険契約者名義変更ＤＢ６０３を備える。

図７は、設計書ＤＢ２０７のデータ構造を説明する図である。設計書ＤＢ２０７は、顧客が加入を検討している、又は既に加入済みの、１つ以上の保険商品の設計書を作成するための元データを格納するデータベースである。図７に示す設計書ＤＢ２０７のデータ構造の一部については、図４を参照して説明したので繰り返しの説明は省略する。図７に示すように、本実施形態では、設計書ＤＢ２０７は、被保険者生年月日７０１及び被保険者名７０２、被保険者の店番号７０３及び取引先番号７０４を含むことができる。被保険者生年月日７０１及び被保険者名７０２は、契約者生年月日４０５、契約者名４０６等と同様に、オペレータ端末１３０から入力された情報、又は保険会社システム１２０から受信した設計書のデータに含まれた情報であり、受付管理ＩＤ４０３や証券番号４０２と関連付けて格納されている。被保険者生年月日７０１及び被保険者名（カナ）７０２は保険内容４０７に含めて格納されることもできる。銀行システム１００は、オペレータ端末１３０から、被保険者の店番号７０３及び取引先番号７０４を受け取って、設計書ＤＢ２０７に格納することができる。例えば、募集人は、保険申込の際に、オペレータ端末１３０に被保険者の口座情報（店番号、口座番号）を入力して、顧客マスタ２０６を検索させて、被保険者の店番号７０３及び取引先番号７０４を得て設計書ＤＢ２０７に格納させることができる。例えば、顧客がオペレータ端末１３０から保険を申込んだときに署名する銀行書面である重要事項確認書に被保険者の口座情報を記載し、募集人がオペレータ端末１３０に当該被保険者の口座情報に基づいて、被保険者の口座情報に対応する被保険者の店番号７０３及び取引先番号７０４取得させて、設計書ＤＢ２０７に保管させる。そのとき、銀行システム１００は、上述したように、被保険者の店番号７０３及び取引先番号７０４で非公開情報ＤＢ２０８に被保険者の非公開情報のレコードを作成する。

図８は、受付管理ＩＤ ＤＢ６０１のデータ構造を説明する図である。受付管理ＩＤ４０３は、銀行システム１００内で採番されて保険会社システム１２０に送信されることで、両システム内のデータを関連付けるために使用されることが可能である。図８に示すように、受付管理ＩＤ ＤＢ６０１は、受付管理ＩＤと、当該受付ＩＤにより識別される、設計書を作成するための元データ（図７）中の契約者の店番号３０１及び取引先番号３０２（ＣＩＦ番号）とを関連づけて格納することができる。

ここで、設計データの作成から、保険会社により発行された証券番号を保険会社システム１２０から受信して、銀行システム１００（設計書ＤＢ２０７及び顧客マスタ２０６）に格納されるまでを説明する。

図９は、銀行システムにより実行される処理を説明するフロー図である。Ｓ９０１にて、銀行システム１００は、オペレータ端末１３０からの元データの受信に応答して受付管理ＩＤ４０３を発行し、当該元データと受付管理ＩＤ４０３を関連付けて設計書ＤＢ２０７に格納することができる。

Ｓ９０３にて、銀行システム１００は、当該保険契約に係る重要事項確認書を作成する（オペレータ端末１３０へ提供し顧客へ提示する）。また、銀行システム１００は、オペレータ端末１３０を介して入力された、顧客（契約者）の「非公開情報の同意」を取得して、非公開情報ＤＢ２０８へ登録し、契約者の顧客マスタ２０６内にリンクを設定する。このとき、被保険者の「非公開情報の同意」もオペレータ端末１３０を介して入力してもらい、銀行システム１００は、契約者の「非公開情報の同意」と同様に、非公開情報ＤＢ２０８へ登録し、被保険者の顧客マスタ２０６内にリンクを設定する。非公開情報ＤＢ２０８は、受付管理ＩＤ４０３とともに、「非公開情報」を利用することについての同意を示す表示、同意した日時、同意の取得方法、同意取得の経緯などを含むことができる。また、銀行システム１００は、設計書ＤＢ２０７に被保険者の店番号７０３及び取引先番号７０４を格納する。

Ｓ９０５にて、銀行システム１００は、受付管理ＩＤ及び申込データを保険会社システム１２０へ送信する。Ｓ９０７にて、保険会社システム１２０は、銀行システム１００から受付管理ＩＤ及び申込データを受信する。保険会社システム１２０は、受信した申込データを処理し、申込み内容を審査する。

Ｓ９１３にて、保険会社システム１２０は、受信した申込データに係る申し込み成立を決定し、証券番号を発行し、銀行システム１００へ、受付管理ＩＤ及び証券番号、並びに契約者等を含む契約内容の情報を含むデータファイルを送信する。

Ｓ９１５にて、銀行システム１００は、受付管理ＩＤ及び証券番号を受信すると、受付管理ＩＤ ＤＢ６０１を参照して受付管理ＩＤに対応する契約者の店番号及び取引先番号を取得する。次いで、銀行システム１００は、契約者の店番号及び取引先番号に対応する設計書ＤＢ中の証券番号４０２に証券番号をセットし、データファイルによって示される契約内容（例えば、保険商品名４０４、契約者生年月日４０５、契約者名４０６、保険内容４０７、保険料明細４０８等）を設計書ＤＢに格納する。また、銀行システム１００は、契約者の店番号及び取引先番号に対応する顧客マスタＤＢ２０６中の証券番号３０５に証券番号をセットする。

以上のようにして、銀行システム１００（設計書ＤＢ２０７及び顧客マスタ２０６）に証券番号が格納されることができる。

図１０は、口座名義変更ＤＢ６０２のデータ構造を説明する図である。図１０に示すように、口座名義変更ＤＢ６０２は、１つ以上の名義変更が行われた口座を識別する口座情報である、店番及び口座番号と、当該口座に関連付けられたＣＩＦ番号である店番号及び取引先番号とを関連付けて格納することができる。口座名義変更ＤＢ６０２は、名義変更が行われた日または日時を格納することもできる。例えば、相続等の手続には、時間がかかる。口座名義変更ＤＢ６０２は、銀行システムが名義変更された口座のうちの相続により名義変更された口座に関連する処理を一定期間経過後できるようにするために、名義変更された口座を識別する口座情報を、少なくとも当該一定期間にわたり格納することができる。

図１１は、保険契約者名義変更ＤＢ６０３のデータ構造を説明する図である。保険の契約者の名義に変更があった場合には、当該保険の受付管理ＩＤ，契約者変更の理由（契約者が死亡したことを示す情報（例えば、フラグ））を含むデータが、保険会社システム１２０から銀行システム１００へ送信される。このデータは、新しい契約者名及び新しい契約者の生年月日などを含むことができる。図１１（ａ）に示すように、保険契約者名義変更ＤＢ６０３は、銀行システム１００が保険会社システム１２０から受信した受付管理ＩＤ、契約者変更の理由、新しい契約者名及び新しい契約者の生年月日を関連付けて格納することができる。

図１１（ｂ）は、図１１（ａ）のデータ構造に、死亡した契約者及び被保険者のＣＩＦ番号である店番号及び取引先番号を付加したデータ構造を示す図である。付加される店番号及び取引先番号は、保険会社システムから受信した受付管理ＩＤに基づいて受付管理ＩＤ ＤＢ６０１から契約者の店番号及び取引先番号を取得する。その後、契約者の店番号及び取引先番号を基に設計書ＤＢ２０７から被保険者の店番号及び取引先番号が取得できる。

図１２は、本発明の一実施形態の銀行システム１００により実行される処理を説明するフロー図である。

Ｓ１２０１にて、銀行システム１００は、保険会社システム１２０から、保険の契約者の名義に変更があったことを示すデータを受信する。図１１（ａ）に示すように、このデータは、保険契約を識別する受付管理ＩＤを含む。また、このデータは、契約者変更の理由である契約者が死亡したことを示す情報、新しい契約者名及び新しい契約者の生年月日を含む。

Ｓ１２０３にて、銀行システム１００は、受信した受付管理ＩＤに基づいて、当該受付管理ＩＤに関連付けられた保険契約者のＣＩＦ番号（取引先番号）である店番号及び取引先番号を取得する。例えば、銀行管理システムは、受付管理ＩＤ ＤＢ６０１を参照して、保険契約者の店番号及び取引先番号を取得し、図１１（ｂ）に示すように、保険会社システム１２０から受信したデータ（図１１（ａ））に付加することができる。

Ｓ１２０４にて、銀行システム１００は、保険契約者の店番号を基づき設計書ＤＢ２０７から被保険者の取引先番号（店番号、取引先番号）を取得する。銀行システム１００は、図１１（ｂ）に示すように、契約者名義変更ＤＢ６０３に被保険者の取引先番号（店番号、取引先番号）を格納することができる。

Ｓ１２０５にて、銀行システム１００は、名義変更が行われた口座の情報を取得する。例えば、銀行システム１００は、口座名義変更ＤＢ６０２から所定期間の間に名義変更された口座情報（図１０）を取得することができる。Ｓ１２０５は、Ｓ１２０１よりも前に、またはＳ１２０１と同時に行われてもよい。

Ｓ１２０７にて、銀行システム１００は、Ｓ１２０５で取得した口座に関連付けられた取引先番号と、Ｓ１２０３で取得した取引先番号とが一致するかどうかを決定する。すなわち、両者が一致すると決定することで、口座の名義変更が、保険契約者の死亡によるものである（相続によるものである）と決定することができる。両者が一致しない場合には、Ｓ１２０９へ進む。

Ｓ１２０９にて、銀行システム１００は、口座名義変更が行われた口座に関連付けられた非公開情報を削除する。銀行システム１００は、Ｓ１２０３で取得した保険契約者（死亡）の取引先番号（店番、取引先番号）に対応する顧客マスタ２０６中の顧客マスタに設定された非公開情報３０６に設定されたリンクを削除する。また、削除したリンクにより示される非公開情報ＤＢ２０８内に格納された非公開情報も削除してもよい。

Ｓ１２１１にて、銀行システム１００は、変更後の名義人が、被保険者と一致するかを決定する。例えば、銀行システム１００は、Ｓ１２０５で取得した口座に関連付けられた取引先番号に対応する顧客マスタＤＢ２０６内の顧客マスタの変更済みの属性情報（氏名及び生年月日）が、Ｓ１２０１で受信した新しい契約者名及び新しい契約者の生年月日に一致し、且つＳ１２０３で取得した被保険者の取引先番号に対応する顧客マスタＤＢ２０６内の顧客マスタの変更済みの属性情報（氏名及び生年月日）が、Ｓ１２０１で受信した新しい契約者名及び新しい契約者の生年月日に一致する場合には、変更後の口座及び保険契約の名義人が、被保険者と一致すると決定することができる。変更後の口座及び保険契約の名義人が、被保険者と一致しない場合には、Ｓ１２０９へ進み、変更後の口座及び保険契約の名義人が、被保険者と一致する場合には、Ｓ１２１３へ進む。

Ｓ１２１３にて、銀行システム１００は、名義変更が行われた口座に対応する顧客マスタＤＢ２０６内の顧客マスタに設定された非公開情報３０６に設定されたリンクを、被保険者の取引先番号に対応する顧客マスタＤＢ２０６内の顧客マスタ（すなわち、Ｓ１２０４で取得した被保険者（新しい契約者であり、変更後の口座の名義人）の取引先番号に対応する顧客マスタ）に設定された非公開情報３０６に設定されたリンクに置き換える。

以上説明したように、本実施形態の銀行システム１００によれば、「非公開情報の同意」を管理している顧客である保険契約の契約者の死亡により、当該「非公開情報の同意」にかかる口座及び保険契約が、当該保険契約の被保険者に相続されたことに応じて、当該口座及び保険契約にかかる「非公開情報の同意」の管理状態を変更できるようになる。

１００ 銀行システム
１１０ 共通ゲートウェイサーバ
１２０ 保険会社システム
１３０ オペレータ端末
２０１ 制御部
２０２ 主記憶部
２０３ 補助記憶部
２０４ インターフェース（ＩＦ）部
２０５ 出力部
２０６ 顧客マスタ
２０７ 設計書ＤＢ
２０８ 非公開情報ＤＢ
２１０バス
６０１ 受付管理ＩＤ ＤＢ
６０２ 口座名義変更ＤＢ
６０３ 保険契約者名義変更ＤＢ

Claims (6)

1. 銀行システムであって、
   保険契約に際して銀行顧客から提供された非公開情報の同意を格納する非公開情報データベースと、
   前記銀行顧客の基礎情報を格納する顧客マスタファイルであり、口座の情報及び保険契約を識別する識別子を含み、前記非公開情報の同意と関連付けられている、顧客マスタファイルと、
   口座名義変更が行われた口座の情報を格納する口座名義人変更データベースであり、新しい口座名義人を含む、口座名義人変更データベースと、
   保険会社システムから、保険契約者の死亡による保険契約の契約者名義変更があったことを示すデータであり、契約者名義変更があった保険契約を識別する識別子、及び新しい保険契約者の情報を含むデータを受信する通信手段と、
   前記口座名義変更が行われた口座について、前記保険会社システムから受信した前記データに基づいて、前記口座名義変更が、前記保険契約者の死亡によるものであると決定する手段と、
   前記口座名義変更が行われた口座の新しい口座名義人が前記保険契約の被保険者であり、且つ前記保険契約の前記新しい保険契約者が前記保険契約の被保険者であると決定する手段と、
   前記口座名義変更が行われた口座に関連付けられた前記非公開情報の同意を、死亡した保険契約者のものから、前記被保険者から前記保険契約に際して予め取得し前記非公開情報データベースに格納しておいたものに変更する手段と
   を備えた、銀行システム。
2. 前記口座名義変更が前記保険契約者の死亡によるものであると決定された場合、且つ
   前記口座名義変更が行われた口座の新しい口座名義人が前記保険契約の被保険者ではない、又は前記保険契約の前記新しい保険契約者が前記保険契約の被保険者ではないと決定された場合に、
   前記口座名義変更が行われた口座に関連付けられた前記非公開情報の同意を削除する手段をさらに備えた、請求項１に記載の銀行システム。
3. 前記通信手段は、前記保険契約に際して、オペレータ端末と通信して、前記保険契約者及び前記被保険者から提供された前記非公開情報の同意を受信する、請求項１又は２に記載の銀行システム。
4. 前記保険会社システムから受信した前記データを格納する保険契約者名義変更データベースをさらに備えた、請求項１、２又は３に記載の銀行システム。
5. 銀行システムによって実行される方法であって、
   前記銀行システムは、保険契約に際して銀行顧客から提供された非公開情報の同意を格納する非公開情報データベースと、前記銀行顧客の基礎情報を格納する顧客マスタファイルであり、口座の情報及び保険契約を識別する識別子を含み、前記非公開情報の同意と関連付けられている、顧客マスタファイルと、口座名義変更が行われた口座の情報を格納する口座名義人変更データベースであり、新しい口座名義人を含む、口座名義人変更データベースとを備え、前記方法は、
   前記銀行システムが、保険会社システムから、保険契約者の死亡による保険契約の契約者名義変更があったことを示すデータであり、契約者名義変更があった保険契約を識別する識別子、及び新しい保険契約者の情報を含むデータを受信することと、
   前記銀行システムが、前記口座名義変更が行われた口座について、前記保険会社システムから受信した前記データに基づいて、前記口座名義変更が、前記保険契約者の死亡によるものであると決定することと、
   前記銀行システムが、前記口座名義変更が行われた口座の新しい口座名義人が前記保険契約の被保険者であり、且つ前記保険契約の前記新しい保険契約者が前記保険契約の被保険者であると決定することと、
   前記銀行システムが、前記口座名義変更が行われた口座に関連付けられた前記非公開情報の同意を、死亡した保険契約者のものから、前記被保険者から前記保険契約に際して予め取得し前記非公開情報データベースに格納しておいたものに変更することと
   を備える、方法。
6. 請求項５に記載の方法をコンピュータに実行させるコンピュータプログラム。

Images