JP6263288B1 - Bank system, method and program executed by bank system - Google Patents

Abstract

[PROBLEMS] In a banking system, when a policyholder of an insurance contract that is a customer who manages “agreement of non-public information” dies, an account and an insurance contract for the “agreement of non-public information” are changed to the insurance contract. In accordance with the inheritance by the insured person, the “agreement of non-public information” concerning the account and the insurance contract is changed. The bank system receives data indicating that the name of the insurance contract has been changed due to the death of the policyholder from the insurance company system (S1201), and the name change of the account whose name has been changed is It is determined that the policyholder is due to the death of the policyholder (S1207), the new account holder is the insured person of the insurance contract, and the new policyholder is the insured person of the insurance contract. This is determined (S1211), and the “agreement of non-public information” associated with the account is changed from that of the deceased policyholder to that of the insured acquired in advance (S1213). [Selection] Figure 12

Description

  The present invention relates to a bank system, a method executed by the bank system, and a program. More specifically, the present invention relates to a bank system for managing private information provided by a bank, and a method executed by the bank system. .

  In December 2007, the sale of insurance products by banks was completely lifted, and so-called bank window sales were conducted (see, for example, Patent Document 1). With the ban on full-scale sales of bank windows, measures to prevent harmful effects related to bank window sales were established. For example, private information protection measures (Enforcement Regulations, Article 212, Paragraph 2, Item 1) stipulate protection of “nonpublic information”. The “non-public information” includes “non-public financial information” that is customer information of the bank and “non-public insurance information” that is information acquired in connection with insurance solicitation. Since “non-public financial information” is information provided to the bank by customers for bank transactions such as deposits, private information protection measures prohibit the use of this information for insurance sales. In addition, private information protection measures require obtaining the consent of customers when using "private insurance information" for banking operations other than insurance solicitation.

  Therefore, when conducting insurance sales for customers who already have bank transactions such as deposits, banks should use the non-public information (non-public financial information) provided at the time of the existing bank transactions. Is obtained in advance from the customer (also referred to as “agreement of private financial information” in this specification) and managed. For subsequent insurance contracts, the bank will also use the information provided by customers (ie, policyholders) at the time of insurance solicitation (private insurance information) for bank operations other than insurance solicitation. Obtained consent (also referred to as “agreement of non-public insurance information” in this specification) from the policyholder (for example, obtained in the form of an important matter confirmation regarding insurance contracts) and managed.

  In addition, when a bank sells insurance with a customer who does not have an existing bank transaction (ie, when the bank has not obtained private financial information), the bank registers as a customer at the time of insurance solicitation and the customer. (I.e., insurance policyholder) obtains and manages "consent of private financial information" and "consent of private insurance information" (also referred to as "consent of private information" in this specification).

  In this way, a bank can obtain “private information consent” so that it can subsequently use the “non-public financial information” for insurance sales to its customers and policyholders. In addition, “private insurance information” can be used for bank operations other than insurance solicitation. As a result, for example, the bank can provide customers (insurance policyholders) with information such as after-following after insurance contracts and proposals for new financial transactions.

  FIG. 1 is a schematic diagram of the entire system including a conventional bank system 100. Referring to FIG. 1, the bank system 100 may be connected to one or more insurance company systems 120 via a network via a common gateway (GW) server 110. The bank system 100 can be connected to one or more operator terminals 130 via a network. The networks available between the banking system 100 and the insurance company system 120 and between the banking system 100 and the operator terminal 130 may be leased lines, LANs, WANs, or other types that perform similar functions. It can be a network.

  FIG. 2 is a system configuration diagram of a conventional bank system 100. As shown in FIG. 2, the bank system 100 includes a control unit 201, a main storage unit 202, an auxiliary storage unit 203, an interface (IF) unit 204, and the like connected to each other via a bus 210 and the like, as in a general computer. An output unit 205 can be provided. The bank system 100 can also include a customer master 206, a design document DB 207, and a private information DB 208 as files / databases.

  The control unit 201 is also called a central processing unit (CPU), controls each component in the bank system 100 and calculates data, and stores various programs stored in the auxiliary storage unit 203 into the main storage unit 202. Can be read and executed. The main storage unit 202 is also called a main memory, and can store various received data, computer-executable instructions, data after arithmetic processing by the instructions, and the like. The auxiliary storage unit 203 is a storage device typified by a hard disk (HDD) and is used when data and programs are stored for a long period of time.

  2 shows an example in which the control unit 201, the main storage unit 202, and the auxiliary storage unit 203 are provided in the same server computer. However, the bank system 100 includes the control unit 201, the main storage unit 202, and the auxiliary storage unit 203. By using a plurality, it is possible to realize parallel and distributed processing by a plurality of server computers. Alternatively, an embodiment in which a plurality of servers for the bank system 100 are installed and the plurality of servers share one auxiliary storage unit 203 is also possible. The same applies to a bank system 100 according to an embodiment of the present invention described later.

  The IF unit 204 serves as an interface for transmitting and receiving data to and from other systems and devices, and provides an interface for receiving various commands and input data (such as various masters and tables) from the operator terminal 130. be able to. The output unit 205 can provide a display screen for displaying the processed data, a printing unit for printing the data, and the like.

  The customer master 206 is a customer master file that stores basic information of bank customers, and includes a customer number (also referred to as a CIF (Customer Information File) number). When a customer newly makes a transaction with a bank, customer information is registered in the customer master 206. When joining the insurance, the customer who visits the window has a transaction with the bank, but the insured does not have a transaction with the bank (for example, a husband and wife have a transaction with the bank). In this case, the data of the insured who did not have a transaction with the bank is registered in the customer master 206.

  FIG. 3 is a diagram for explaining an example of the data structure of the customer master 206. As shown in FIG. 3, the customer master 206 can include a store number 301, a customer number 302, bank account information 303, attribute information 304, and a securities number 305. When a customer has accounts at multiple branches within the same bank, it is configured to include a common number (for example, a personal identification number that can be used for “name identification” processing) that connects the accounts. Also good.

  The store number 301 is a number that identifies each branch office that manages bank customers, and the customer number 302 is a number that identifies a customer in the branch office. The store number 301 and the customer number 302 can be collectively referred to as a CIF number (customer number). That is, in the example of FIG. 3, the store number 301 and the business partner number 302 are shown as different data items. However, they can be configured as one data item.

  The bank account information 303 is information on a customer's bank account, and can include information such as a store number, a subject, an account number, and an account name. The attribute information 304 can include information such as the customer's name, Kana name, address, and contact information.

  The security number 305 indicates the security number assigned to the insurance policy issued when the customer officially joins the insurance. As will be described later, the security number is issued by the insurance company system 120 when an application for an insurance contract is established. Therefore, the certificate number 305 is issued separately from the certificate number (the insurance company system 120 or the bank system 100 separately from the certificate number) until the application is made. Identifying design document data associated with the insurance product). The security number 305 can also function as a number for identifying original data for creating a design document or a number for identifying an insurance contract, which is stored in the design document DB 207. Since the design document is created in a document format, the original data for creating the design document refers to various data included in the design document.

  The non-public information 306 is information on non-public information, and can include a link to non-public information provided by a customer and stored in the non-public information DB 208.

  FIG. 4 is a diagram for explaining an example of the data structure of the design document DB 207. The design document DB 207 is a database that stores original data for creating a design document of one or more insurance products that the customer is considering or has already subscribed. The design document DB 207 can be further configured to store data for creating a design document. The design document created at the time of enrolling insurance is a document presented to explain the details of insurance and insurance in detail, including insurance contract details (including main contracts, special contracts, etc.), insurance payment method, policyholder / coverage In addition to information on insurers, this is a conventional document that includes contract application forms, handling reports (including supplementary materials), and recipient designation forms. For this reason, in this specification, the detailed description about each item described in the design document will be omitted.

  The design document DB 207 includes, as data items, a contractor's store number 410 and a business partner number 411 (CIF number), an insurance company code 401, a security number 402, a reception management ID 403, an insurance product name 404, a contractor's date of birth 405, The contractor name 406, the insurance content 407, the insurance premium description 408, and the proposal content 409 can be included.

  The contractor's store number 410 is a number for identifying each business store that manages bank customers, and matches the store number 301 stored in the customer master 206. The supplier number 411 is a number for identifying a customer in the sales office, and matches the supplier number 302 stored in the customer master 206. The customer master 206 and the design document DB 207 can be associated with each other by a CIF number (store number and customer number).

  The insurance company code 401 indicates the identification number of the insurance company, and the security number 402 is a number for identifying the design document presented to the customer, and a number for identifying the security number attached to the insurance policy. It is. Original data for creating the design document is provided from the bank system 100 to the insurance system 120 and the insurance system 120 creates the design document. For example, the design document number is assigned by the insurance system 120. obtain. The reception management ID 403 is an identifier for identifying original data for creating a design document, and is an identification number assigned in the bank system 100. The reception management ID 403 can be transmitted from the bank system 100 to the insurance company system 120 and used to correlate data in both systems.

  The insurance product name 404 indicates the name of the insurance presented to the customer (including a code identifying the insurance). Contractor date of birth 405 and contractor name 406 indicate the contractor's date of birth and name (including Kana's name), respectively, and these data items identify which customer the design document is associated with. Can also be used.

  The insurance content 407 indicates the content of the insurance contract, and describes, for example, the policyholder, the insured person, the insurance amount, the insurance premium, the payment expiry age, the insurance contract type, the number of payments, the payment route, the fee, and the insurance mechanism. For example, information such as a structure diagram (image) may be included. The insurance premium description 408 may indicate the details of the monthly premium paid. The proposal contents 409 may include information on payment patterns of insurance premiums to be proposed to the customer, such as specific insurance premiums, payment period expiration age, number of payments, and payment route. Information included in the proposal content 409 can be generated in the insurance company system 120 and stored in the design document DB 207.

  The private information DB 208 stores private information that is provided by a customer and in which a link is set in the customer master 206. Non-public information provided by the customer can include non-public information consent ("private financial information consent" and "private insurance information consent").

  FIG. 5 is a diagram for explaining an example of the data structure of the private information DB 208. The private information DB 208 includes, as data items, a store number 501 and a business partner number 502 (CIF number), a reception management ID 503, private information 504, and the like, which are stored in association with each other. Non-public information 504 includes the contents of important matters, whether or not there is consent to non-public information ("consent to non-public financial information" and "consent to non-public insurance information"), date and time of consent, method of obtaining consent, The history of acquisition can be included. Thereby, the bank can manage the “agreement of non-public information” by associating the customer master using the bank system as shown in FIG.

Patent No. 6046793

  By the way, as described above, the bank manages the “agreement of non-public information” obtained from the customer (insurance policyholder), but manages the “agreement of non-public information” for the insured person of the insurance contract. Not.

  Therefore, the bank cannot use the “non-financial financial information” for insurance sales unless it obtains “private financial information consent” in advance from the insured of the insurance contract. If you do not obtain the "consent" in advance, you cannot use the "non-public insurance information" for bank operations other than insurance solicitation. For example, such inconvenience may occur when a customer (insurance policyholder) whose bank manages “consent of private information” dies.

  An example is shown in which a bank sells insurance with a husband who has bank transactions as an insurance contractor and a wife who does not have bank transactions as an insured person, and manages husband's “agreement of non-public information”. When the husband (customer and policyholder) died, the name of the account related to the bank transaction of the husband was changed to the wife (insured), and the policyholder name of the insurance was deceased by the husband (original insurance contract) Person) to wife (insured person). In this case, the “private financial information consent” for the bank transaction related to the account managed by the bank is agreed by the deceased husband. In order to sell insurance to a new nominee, it is necessary to obtain consent from the wife and manage it in advance. Similarly, the “private insurance information consent” for the insurance contract managed by the bank was agreed by the deceased husband. In order to use it for work, it is necessary to obtain consent from the wife and manage it in advance.

  Therefore, a bank (insurance policyholder) who manages the “non-public information consent” of the bank dies and the bank and the insurance contract related to the “non-public information consent” are When inherited by an insured person, promptly and surely obtain and manage “acceptance of non-public information” for the account and insurance contract from the insured person who is the heir. desirable. If the insured who is the heir cannot obtain “agreement of non-public information”, it is desirable to invalidate the “agreement of non-public information” obtained from the dead quickly and reliably.

  The present invention has been made in view of such problems, and the purpose of the present invention is due to the death of a policyholder who is a customer who manages “agreement of nonpublic information” in a banking system. The management status of the “non-public information consent” related to the account and the insurance contract in accordance with the inheritance of the account and insurance contract related to the “non-public information consent” to the insured person of the insurance contract. Is to be able to change.

  In order to achieve such an object, the bank system according to one aspect of the present invention includes a non-public information database that stores consent for non-public information provided by a bank customer at the time of an insurance contract, and basic information of the bank customer. A customer master file to be stored, which includes an account information and an identifier for identifying an insurance contract, and stores the customer master file associated with the consent of non-public information and the account information whose account name has been changed. It is an account holder change database, which is an account holder change database including a new account holder, and data indicating that there has been a change in the policyholder name of the insurance contract due to the death of the policyholder from the insurance company system. An identifier for identifying the policyholder whose name has been changed, and a communication means for receiving data including information on the new policyholder, and account name For the account that has been renewed, based on the data received from the insurance company system, a means to determine that the account name change is due to the death of the policyholder, and a new account for the account in which the account name change was made Means for determining that the holder is an insured person of the insurance contract and that the new policyholder of the insurance contract is the insured person of the insurance contract, and non-public information associated with the account whose account name change has been made And a means for changing the consent of the person who died from that of the deceased policyholder to that previously obtained from the insured at the time of the insurance contract and stored in the non-public information database.

  In one embodiment, if it is determined that the account transfer is due to the death of the policyholder, and the new account holder of the account where the account transfer was made is not an insured person of the insurance contract or insurance In the case where it is determined that the new policyholder of the contract is not an insured person of the policy contract, it is further provided with means for deleting the consent of the non-public information associated with the account whose account is changed And In one embodiment, the communication means communicates with an operator terminal to receive consent for private information. The bank system further includes an insurance policyholder name change database for storing data received from the insurance company system.

  The present application is a method executed by a banking system which is an aspect of the invention. The bank system is a non-public information database that stores consent of non-public information provided by a bank customer at the time of an insurance contract, and a customer master file that stores basic information of the bank customer, and identifies account information and an insurance contract Account holder change database that contains the customer master file that contains the identifier and is associated with the consent of private information and the account that has been changed, and that contains the new account holder This method is data indicating that the bank system has changed the policyholder name of the insurance contract due to the death of the policyholder from the insurance company system. Receiving data containing an identifier identifying the policy and information about the new policyholder, the banking system will change the account name. And the banking system determines that the account name change is due to the death of the policyholder based on the data received from the insurance company system, and the bank system Determining that the account holder is the policyholder and the new policyholder is the policyholder, and the banking system associates the account with the account change Changing the consent of the non-public information received from that of the deceased policyholder to that previously obtained from the insured at the time of the insurance contract and stored in the non-public information database. And

  One aspect of the present invention is a computer program that causes a computer to execute the above method.

  As described above, according to the present invention, in the banking system, the account related to the “private information consent” and the death of the policyholder who manages the “private information consent” In response to the inheritance of the insurance contract by the insured person of the insurance contract, it becomes possible to change the management state of “agreement of non-public information” regarding the account and the insurance contract.

It is the schematic of the whole system containing the conventional bank system. It is a block diagram of the conventional bank system. It is a figure explaining an example of the data structure of the conventional customer master. It is a figure explaining an example of the data structure of the conventional design document DB. It is a figure explaining the data structure of private information DB of one Embodiment of this invention. It is a block diagram of the bank system of one Embodiment of this invention. It is a figure explaining the data structure of design document DB of one Embodiment of this invention. It is a figure explaining the data structure of reception management ID DB of one Embodiment of this invention. It is a flowchart explaining the process performed by the bank system of one Embodiment of this invention. It is a figure explaining the data structure of account name change DB of one Embodiment of this invention. It is a figure explaining the data structure of insurance policyholder name change DB of one Embodiment of this invention. It is a flowchart explaining the process performed by the bank system of one Embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The same or similar reference signs indicate the same or similar elements.

  FIG. 6 is a block diagram showing a bank system according to an embodiment of the present invention. As shown in FIG. 6, the bank system 100 can include a control unit 201, a main storage unit 202, an auxiliary storage unit 203, an interface (IF) unit 204, and an output unit 205 connected to each other by a bus 210 or the like. . The bank system 100 also includes a customer master 206, a design document DB 207, a private information DB 208, a reception management ID DB 601, an account name change DB 602, and an insurance policyholder name change DB 603 as files / databases.

  FIG. 7 is a diagram for explaining the data structure of the design document DB 207. The design document DB 207 is a database that stores original data for creating a design document of one or more insurance products that the customer is considering or has already subscribed. A part of the data structure of the design document DB 207 shown in FIG. 7 has been described with reference to FIG. As shown in FIG. 7, in the present embodiment, the design document DB 207 can include an insured person's date of birth 701, an insured person name 702, an insured person's store number 703, and a supplier number 704. The insured person's date of birth 701 and the insured person's name 702 are the information inputted from the operator terminal 130 or the design document received from the insurance company system 120, like the contractor's date of birth 405, the contractor's name 406, etc. And is stored in association with the reception management ID 403 and the securities number 402. The insured person's date of birth 701 and the insured person's name (kana) 702 can be included in the insurance content 407 and stored. The bank system 100 can receive the store number 703 and the customer number 704 of the insured person from the operator terminal 130 and store them in the design document DB 207. For example, when applying for insurance, the recruiter inputs the insured person's account information (store number, account number) to the operator terminal 130, searches the customer master 206, and stores the insured person's store number 703 and A supplier number 704 can be obtained and stored in the design document DB 207. For example, the account information of the insured person is described in an important matter confirmation that is a bank document signed when the customer applies for insurance from the operator terminal 130, and the recruiter enters the account information of the insured person in the operator terminal 130. Based on the above, the store number 703 and the business partner number 704 of the insured person corresponding to the account information of the insured person are acquired and stored in the design document DB 207. At that time, as described above, the bank system 100 creates a record of the insured person's non-public information in the non-public information DB 208 using the insured person's store number 703 and business partner number 704.

  FIG. 8 is a diagram for explaining the data structure of the reception management ID DB 601. The reception management ID 403 is numbered in the bank system 100 and transmitted to the insurance company system 120, so that it can be used for associating data in both systems. As shown in FIG. 8, the reception management ID DB 601 includes the reception management ID, the store number 301 of the contractor in the original data (FIG. 7) identified by the reception ID, and the business partner. The number 302 (CIF number) can be stored in association with each other.

  Here, a process from creation of design data to receipt of a security number issued by an insurance company from the insurance company system 120 and storage in the bank system 100 (design document DB 207 and customer master 206) will be described.

  FIG. 9 is a flowchart for explaining processing executed by the bank system. In S <b> 901, the bank system 100 can issue a reception management ID 403 in response to receiving the original data from the operator terminal 130, and store the original data and the reception management ID 403 in association with each other in the design document DB 207.

  In S903, the bank system 100 creates an important matter confirmation for the insurance contract (provides it to the operator terminal 130 and presents it to the customer). Further, the bank system 100 obtains the “private information consent” of the customer (contractor) input via the operator terminal 130, registers it in the private information DB 208, and stores it in the customer master 206 of the contractor. Set a link to At this time, the insured's “private information consent” is also input via the operator terminal 130, and the bank system 100 sends the private information DB 208 to the private information DB 208 in the same manner as the contractor's “private information consent”. Register and set a link in the insured customer master 206. The non-public information DB 208 can include, together with the reception management ID 403, a display indicating consent for using “non-public information”, an agreed date and time, an agreement acquisition method, an agreement acquisition process, and the like. Further, the bank system 100 stores the insured person's store number 703 and customer number 704 in the design document DB 207.

  In S905, the bank system 100 transmits the reception management ID and application data to the insurance company system 120. In S907, the insurance company system 120 receives the reception management ID and application data from the bank system 100. The insurance company system 120 processes the received application data and examines the application contents.

  In S913, insurance company system 120 determines application establishment related to the received application data, issues a security number, and provides bank system 100 with information on contract contents including reception management ID, security number, and contractor. Send a data file containing.

  In S915, when the bank system 100 receives the reception management ID and the securities number, the bank system 100 refers to the reception management ID DB 601 to acquire the contractor's store number and customer number corresponding to the reception management ID. Next, the bank system 100 sets the security number to the security number 402 in the design document DB corresponding to the store number and the customer number of the contractor, and the contract contents (for example, insurance product name 404, contract) indicated by the data file. The person's date of birth 405, the contractor name 406, the insurance content 407, the insurance premium details 408, etc.) are stored in the design document DB. Further, the bank system 100 sets the securities number in the securities number 305 in the customer master DB 206 corresponding to the contractor's store number and customer number.

  As described above, the securities number can be stored in the bank system 100 (design document DB 207 and customer master 206).

  FIG. 10 is a diagram for explaining the data structure of the account name change DB 602. As shown in FIG. 10, the account name change DB 602 is an account information for identifying an account for which one or more name changes have been made, a store number and an account number, and a store number that is a CIF number associated with the account. And a business partner number can be stored in association with each other. The account name change DB 602 can also store the date or date when the name change was made. For example, procedures such as inheritance take time. Account name change DB 602 is account information for identifying an account whose name has been changed so that the bank system can perform processing related to the account whose name has been changed by inheritance among accounts whose names have been changed after a certain period of time. Can be stored for at least the certain period of time.

  FIG. 11 is a diagram for explaining the data structure of the policyholder name change DB 603. If there is a change in the name of the policyholder of the insurance, the data including the insurance reception management ID and the reason for the policyholder change (information indicating that the policyholder died (for example, flag)) Sent from the system 120 to the bank system 100. This data may include the name of the new subscriber and the date of birth of the new subscriber. As shown in FIG. 11A, the policyholder name change DB 603 includes the reception management ID received by the bank system 100 from the insurance company system 120, the reason for the policyholder change, the new policyholder name, and the date of birth of the new policyholder. The days can be associated and stored.

  FIG. 11B is a diagram showing a data structure in which a store number and a customer number, which are CIF numbers of the contracted party and the insured, are added to the data structure of FIG. 11A. The added store number and customer number are obtained from the reception management ID DB 601 based on the reception management ID received from the insurance company system. Thereafter, the insured person's shop number and customer number can be obtained from the design document DB 207 based on the contractor's shop number and customer number.

  FIG. 12 is a flowchart illustrating processing executed by the bank system 100 according to the embodiment of this invention.

  In S1201, the bank system 100 receives data indicating that the name of the insurance contractor has been changed from the insurance company system 120. As shown in FIG. 11A, this data includes a reception management ID for identifying an insurance contract. The data also includes information indicating that the contractor who has been the reason for the contractor change has died, the name of the new contractor, and the date of birth of the new contractor.

  In S1203, based on the received reception management ID, the bank system 100 obtains a store number and a customer number that are CIF numbers (customer numbers) of the policyholders associated with the reception management ID. For example, the bank management system refers to the reception management ID DB 601 to acquire the store number and business partner number of the policyholder, and as shown in FIG. 11B, data received from the insurance company system 120 (see FIG. 11). 11 (a)).

  In S1204, the bank system 100 acquires the insured customer number (store number, customer number) from the design document DB 207 based on the insurance contractor's store number. As shown in FIG. 11B, the bank system 100 can store the insured customer number (store number, customer number) in the contractor name change DB 603.

  In S1205, the bank system 100 acquires information on the account whose name has been changed. For example, the bank system 100 can acquire account information (FIG. 10) whose name was changed during a predetermined period from the account name change DB 602. S1205 may be performed before S1201 or simultaneously with S1201.

  In S1207, the bank system 100 determines whether the customer number associated with the account acquired in S1205 matches the customer number acquired in S1203. That is, it is possible to determine that the name change of the account is due to the death of the policyholder (because of inheritance) by determining that both match. If they do not match, the process proceeds to S1209.

  In S1209, bank system 100 deletes the non-public information associated with the account whose account name has been changed. The bank system 100 uses the link set in the non-public information 306 set in the customer master in the customer master 206 corresponding to the customer number (store number, customer number) of the policyholder (dead) acquired in S1203. delete. Also, the private information stored in the private information DB 208 indicated by the deleted link may be deleted.

  In S1211, bank system 100 determines whether the changed holder matches the insured. For example, the bank system 100 determines that the changed attribute information (name and date of birth) of the customer master in the customer master DB 206 corresponding to the customer number associated with the account acquired in S1205 is the new contract received in S1201. The changed attribute information (name and date of birth) of the customer master in the customer master DB 206 corresponding to the customer name and the date of birth of the new contractor and corresponding to the customer number of the insured acquired in S1203. When the new contractor name received in S1201 and the date of birth of the new contractor match, it can be determined that the changed account and the holder of the insurance contract match the insured person. If the changed account and the holder of the insurance contract do not match the insured, the process proceeds to S1209. If the changed account and the holder of the insurance contract matches the insured, the process proceeds to S1213. move on.

  In S1213, the bank system 100 corresponds the link set in the private information 306 set in the customer master in the customer master DB 206 corresponding to the account whose name has been changed to the customer number of the insured person. Non-public information set in the customer master in the customer master DB 206 (that is, the customer master corresponding to the customer number of the insured person (new contractor and account holder after the change) acquired in S1204) Replace with the link set in 306.

  As described above, according to the bank system 100 of the present embodiment, the agreement of non-public information is made due to the death of the policyholder of the insurance contract that is the customer who manages the non-public information agreement. In response to the inheritance of the account and the insurance contract by the insured person of the insurance contract, the management state of “agreement of non-public information” related to the account and the insurance contract can be changed.

DESCRIPTION OF SYMBOLS 100 Bank system 110 Common gateway server 120 Insurance company system 130 Operator terminal 201 Control part 202 Main memory part 203 Auxiliary memory part 204 Interface (IF) part 205 Output part 206 Customer master 207 Design document DB
208 Private information DB
210 bus 601 reception management ID DB
602 Account name change DB
603 Policyholder name change DB

Claims (6)

A banking system,
A non-public information database that stores consent for non-public information provided by bank customers during insurance contracts;
A customer master file storing basic information of the bank customer, including an identifier identifying account information and an insurance contract, and associated with consent to the private information;
An account holder change database that stores information of the account that has been changed, and includes a new account holder;
Data indicating that the policyholder's name has been changed due to the death of the policyholder from the insurance company system. The identifier identifies the policyholder whose policyholder name has been changed, and information on the new policyholder. A communication means for receiving data including:
Means for determining, based on the data received from the insurance company system, that the account name change is due to the death of the policyholder for the account in which the account name change has been made;
Means for determining that a new account holder of the account whose name has been changed is an insured person of the insurance contract, and that the new policyholder of the insurance contract is an insured person of the insurance contract; ,
Consent of the non-public information associated with the account whose name has been changed is obtained in advance from the insured person at the time of the insurance contract from the deceased policyholder and stored in the non-public information database. A banking system with a means to change to what was left. When it is determined that the account name change is due to the death of the policyholder, and the new account holder of the account where the account name change is made is not an insured person of the insurance contract, or the insurance If it is determined that the new policyholder of the contract is not an insured person of the policy,
The bank system according to claim 1, further comprising means for deleting consent of the non-public information associated with the account for which the account name change has been made.   3. The bank system according to claim 1, wherein the communication unit communicates with an operator terminal at the time of the insurance contract, and receives consent of the non-public information provided from the insurance contractor and the insured person. .   4. The bank system according to claim 1, further comprising a policyholder name change database for storing the data received from the insurance company system. A method implemented by a banking system,
The bank system is a non-public information database for storing consent of non-public information provided by a bank customer at the time of an insurance contract, and a customer master file for storing basic information of the bank customer. An account holder change database that stores information on the customer master file and the account on which the account transfer was changed, including an identifier for identifying and associated with the consent of the non-public information, including the new account holder An account holder change database, the method comprising:
The bank system is data indicating that the policyholder name change of the insurance contract was caused by the death of the policyholder from the insurance company system, an identifier for identifying the insurance contract with the policyholder name change, and a new insurance Receiving data containing contractor information;
The bank system determines, based on the data received from the insurance company system, that the account name change is due to the death of the policyholder for the account that has undergone the account name change; ,
In the banking system, the new account holder of the account whose account name change has been made is the insured person of the insurance contract, and the new policyholder of the insurance contract is the insured person of the insurance contract. And deciding
The banking system obtains in advance the consent of the non-public information associated with the account whose name has been changed from that of the deceased policyholder from the insured at the time of the insurance contract, and the private information Changing to what has been stored in the information database.   A computer program for causing a computer to execute the method according to claim 5.

Images