JP2017016291A - Computer system for managing banking account - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an EBM (Event Based Marketing) system which highly accurately estimates a customer's need for capital.SOLUTION: There is provided a system comprising: means for classifying into a main account which continuously receives predetermined transfers or continuously makes predetermined transfers, or into a sub-account which is not continuously subjected to predetermined transfers, on the basis of transfer history of the past; means for determining that a large amount of remittance transferred to the main account is a remittance with a predetermined purpose, on the basis of attribute data of the main account; means for determining that a large amount of remittance received in the sub-account is candidate remittance with the possibility of being a remittance with a predetermined purpose; and means for determining that the remittance candidate received in the sub-account is a remittance with the same purpose as the large amount of remittance transferred to the main account, on the basis of attribute data of the sub-account, in the case that a transfer origin and a transfer date of the candidate remittance coincide with the transfer origin and the transfer date of the large amount of remittance transferred to the main account.SELECTED DRAWING: Figure 3

Description

  The present invention relates to a computer system for supporting sales in a financial institution or the like. In particular, the present invention relates to an EBM (Event Based Marketing) computer system that captures changes in customer circumstances, analyzes the cause of the change, and appropriately provides financial products that meet customer funding needs.

  Banks and other financial institutions sell and contract financial products such as time deposits, investment trusts, and card loans. Understand customer's funding needs and appropriately recommend financial products that meet customer's funding needs. We conduct sales activities so that we can.

  In that respect, the bank settlement information is information necessary to grasp the funding needs without listening to the customer.

  Normally, a sales person at a financial institution confirms the transaction history of the account that the sales person is in charge of, and that the customer in charge has some reason (for example, a retirement payment has been received due to the retirement of the customer). ) Based on experience and intuition. However, since such experiences and intuitions tend to vary in judgment, there is a need for systematization to grasp customer funding needs, and computer systems using EBM have been proposed in the past. .

  As a prior art of such a system, for example, Patent Document 1 is disclosed. In Patent Document 1, in a system in a certain financial institution, the total amount of transactions between a deposit-side account and a payee-side account in a specific target period is calculated, and deposits in a period earlier than the specific target period are calculated. A technique for comparing the total transaction amount between the customer's account and the recipient's account is disclosed.

Japanese Patent No. 5416852

  However, customers often have multiple accounts in a specific bank or multiple banks, and often use the multiple accounts according to their purpose. The customer's financial needs are not fully understood. The conventional technology does not consider such a point.

  In many cases, customers have a plurality of accounts at one or a plurality of branches of a specific bank, and use the plurality of accounts according to the purpose. With regard to an account (referred to as a main account) that is mainly used for periodic transfers such as salary transfers, it is relatively easy to grasp the needs for funds because the movement of funds is active. However, as for the account used for depositing and withdrawing specific funds (referred to as sub-accounts), the movement of funds is not active, so attention is paid to specific accounts (particularly sub-accounts). It is not always easy to grasp the customer's financial needs with high accuracy.

  Therefore, in one embodiment of the present invention, an object is to determine with high accuracy the funding needs of a customer who has a specific account (particularly, an account other than the main account) at his / her financial institution.

  Further, customers often have a plurality of accounts in a plurality of banks, and often use the plurality of accounts according to the purpose. In particular, in the case of a local financial institution, not only the headquarters of the company where the customer works, but also a factory or office is often not in the sales area of the local financial institution. In such a case, since the local financial institution does not have a transaction with the company where the customer works, it determines the funding needs only from the payment information of the employee who is the customer. It is not always easy to grasp.

  Therefore, in another aspect of the present invention, by grasping transactions outside the business area of a financial institution (particularly a local financial institution), the financial needs of customers who have a primary account or a secondary account at their own financial institution, One of the issues is to determine with high accuracy.

  According to one aspect of the present invention, in a computer system for managing a financial account, a main account that has received a predetermined continuous transfer or a predetermined continuous transfer based on a past transfer history And means for classifying the account into a secondary account without a predetermined continuous transfer, and the large deposit transferred to the main account is a deposit with a predetermined purpose based on the attribute data of the main account. A means for determining, a means for determining that the large deposit received in the sub-account is a candidate deposit that may be a deposit with a predetermined purpose, and a candidate deposit transferred to the sub-account. When the transfer source and transfer date match the transfer source and transfer date of the large deposit transferred to the main account, the payment candidate transferred to the sub account is based on the attribute data of the sub account, Same as the large deposit transferred to the main account And a means for determining that the deposit is intended.

According to one aspect of the present invention, the purpose of the amount transferred to a sub-account as well as the main account of a financial institution can be grasped, so that the customer's funding needs can be grasped with high accuracy.
Other objects, features and advantages of the present invention will become apparent from the following description of embodiments of the present invention with reference to the accompanying drawings.

It is a figure which shows the outline of the system of one Example of this invention. It is a functional block diagram of the system of FIG. It is a flowchart which shows an example of the flow of a process of the system of FIG. An example of the data structure used in the system of FIG. 1 is shown. It is a functional block diagram of the system of another Example of this invention. It is a flowchart which shows an example of the flow of a process of the system of FIG. It is a functional block diagram of the system of another Example of this invention. It is a flowchart which shows an example of the flow of a process of the system of FIG.

  Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.

Example 1
In the present embodiment, a system for determining (estimating) an account of a customer who has received a retirement allowance is shown.
FIG. 1 is a diagram showing an outline of a system according to an embodiment of the present invention. In the present embodiment, in order to simplify the explanation, a description will be given using a system consisting of two banks, A bank and B bank.

  In FIG. 1, a system 100 includes an EBM system 200 possessed by Bank A and an EBM system 300 possessed by Bank B. Each of these is connected by a network 500 or the like.

  The EBM system 200 of bank A includes an in-line server 210, a terminal 220 (220-1,... 220-n: n is a positive integer), and an in-line DB (Database) 230. The server 210, the terminal 220, and the in-line DB 230 are connected via a network or the like.

  The EBM system 300 of bank B includes an in-line server 310, a terminal 320 (320-1,... 320-m: m is a positive integer), and an in-line DB 330.

  An example of the configuration of the bank A's EBM system 200 will be described. The bank server 210 is a computer for managing transfers between accounts in Bank A and transfers between the bank account and another bank account. The terminal 220 is a terminal capable of browsing transfer information between accounts. The bank DB 230 manages various data (information) such as customer accounts. Specifically, it stores information such as the name of the customer and the amount of money, and also has settlement information (transaction history) of each customer in bank A. Further, in the bank DB 230, for example, when funds are transferred in the account of a target customer, information on the amount is updated in accordance with the transfer.

  Note that a processor is included in the system 100 or a part or all of the units constituting the system 100 in the present embodiment, and each processor takes part or all of the processing of the system.

  Since the configuration of the EBM system 300 of the bank B in this embodiment is the same as the configuration of the EBM system 200 of the bank A, description thereof is omitted. In this embodiment, as long as the subsystems of the A bank and the B bank can be linked with each other, the configuration in the A bank and B bank subsystems may be changed.

FIG. 2 is a functional block diagram of the system of FIG. 1 according to the first embodiment. For convenience of explanation, FIG. 2 shows only a functional block diagram of the ABM EBM system 200.
The control unit 211 controls each unit described later.
The workplace determination unit 212 determines the workplace of the customer who has the account using information such as past salary transfer in the account A.

  The past salary transfer determination unit 213 searches that a certain amount of money is transferred from a specific company or the like every month (or at predetermined intervals), and that these series of transfers are salary transfers. judge. Also, a salary transfer history (list) is created as necessary. The salary transfer amount varies every month depending on whether there is an overtime fee, various allowances, etc., but the monthly salary transfer may be determined in consideration of the fact that the transfer amount varies within a certain range.

  The retirement allowance candidate deposit determination unit 214 determines that the large deposit is a “retirement allowance candidate” when a large deposit that is considered to be a retirement deposit is confirmed in a specific account.

  The retirement allowance determination unit 215, for the deposit determined to be a candidate for retirement allowance in the account A, determines the deposit date, work place information, age (or age), approximate working years (for example, in units of one year) Whether it is a retirement allowance or not is determined based on customer attribute data that has opened an account such as a unit of several years. For example, if the customer's age reaches 60 and there is a predetermined large deposit in the following month or year (if a retirement candidate is deposited), the large deposit is a retirement allowance. I can judge.

Here, customer attribute data is stored in a customer attribute DB 232 described later. The customer attribute data may include a variety of information. For example, in addition to the customer's own information, the customer's attribute data may include information related to the customer (for example, family structure information, name identification information). The retirement allowance determination unit 215 may also determine that the monthly salary transfer account and the retirement transfer account are the same customer.

  The customer account DB 231 (DataBase) manages the funds deposited for each customer account. Further, the transaction history may be managed based on the settlement information for each account.

  The customer attribute DB 232 records customer attribute data (for example, customer-specific information such as customer name (corporate name), address, date of birth, occupation, family structure, etc.). Some customers have opened multiple accounts (for example, a savings account and a fixed deposit account) in the same bank. In order to centrally manage such customers (to properly manage so-called name identification), the plurality of accounts can be managed using identifiers for identifying the plurality of accounts as the same customer. It may be configured as follows.

  The settlement information DB 233 is a device for accumulating information necessary for settlement of funds (settlement information) such as liquidity fund information related to the liquidity of the bank's own deposits and exchange rates.

  When the retirement allowance determination unit 215 determines that the retirement allowance has been received, the retirement allowance receiving customer DB 234 writes that the retirement allowance has been received as the corresponding customer information. Further, the name of the company that transferred the retirement allowance and the transfer date may be written.

  The retirement allowance receiving company information DB 403 records information about the company of the employee (financial institution customer) who received the retirement allowance.

  3A and 3B are flowcharts showing the flow of processing in the functional block shown in FIG. Hereinafter, the flow of processing in the present embodiment will be described with reference to FIG.

  FIG. 3A is a flowchart for determining whether a customer who has a main account in the bank has received a retirement allowance.

  In S1010, based on the settlement process, a deposit process for transferring the designated amount into the designated customer account is performed. Here, the payment information includes various information for performing normal business processing in the financial institution. However, as will be described later, a part of the information is used in this embodiment. It is.

  In S1020, it is determined whether or not the deposit process based on the settlement information is a large deposit that may be a retirement allowance. In this embodiment, such a large deposit is referred to as a “retirement allowance candidate”. Specifically, for example, it is confirmed whether or not the retirement allowance candidate is a large amount of money exceeding a predetermined amount. As for the predetermined amount, each financial institution may determine the predetermined amount individually, or a plurality of financial institutions, a common server, or the like may determine the predetermined amount.

  In S1030, it is determined whether or not the customer to whom the retirement allowance has been received has received a salary transfer every month prior to this. Although the bank (for example, Bank A) did not receive a salary transfer, there is a possibility that another bank (for example, Bank B) has received a salary transfer. That is, there is a possibility that the account for receiving retirement payments and the account for receiving salary may be different. If a salary transfer has been received, it is determined that the person is a salary transfer person. In other words, in the present embodiment, this salary transfer person is a customer who has a main account in the bank (for example, Bank A).

  Moreover, if it is not receiving salary transfer, it determines with it being a salary non-transfer person. The process in the case where it is determined that the person is not a payer will be described with reference to FIG. In other words, in this embodiment, the non-payee is a customer who may have a main account in another bank (for example, Bank B), but is not in the main bank (for example, Bank A). It means that the customer does not have an account but has a sub account.

  It should be noted that an identifier or a flag for identifying the payer and the non-payer may be added on the DB.

  In S1040, salary transfer persons are extracted from the customers to whom the retirement allowance candidates have been transferred.

  In S1050, the past payment is searched and the past salary transfer history of the extracted salary transfer person is created.

  In S1060, the place of work is determined based on the past salary transfer history.

  In S1070, in addition to the result of the processing up to S1060, necessary information (for example, information on the workplace) is obtained from the customer attribute data, and it is determined whether or not the received retirement candidate is a retirement allowance. To do. For example, if the customer's age reaches 60 and a severance pay candidate is paid in the following month or a predetermined year of the following year, the severance pay candidate can be determined to be a severance pay.

  In S1080, if it is determined that it is a retirement allowance, the retirement receipt customer information list of the main account is updated. This severance payee customer information list is composed of a company / corporate name estimated to transfer severance pay and a transfer date.

  In S1090, it is determined whether or not the determination is completed for all salary earners who have received the retirement allowance candidate. If it is determined for all salary earners who have received the retirement allowance, the process proceeds to S1100. If there are still salary earners that need to be determined, the process returns to S1040 and the present process is continued.

  In S1100, the severance pay receiving customer information list is transmitted to the severance pay receiving company information DB, and the list managed in the severance pay receiving company information DB is updated. As a result, the fact that the corresponding customer has received the retirement payment is recorded in the retirement payment receiving company information DB.

  In S1110, the updated sales retirement receipt customer information list is notified to the sales staff in the bank. After determining the retirement allowance, the data is output in a data format that can be understood by humans (for example, sent by e-mail), and the sales representative of the account is contacted or the call center representative is contacted. As a result, a sales representative or a call center representative can present a financial product corresponding to the customer's funding needs by visiting the customer or making a call. Note that S1110 may be omitted when the process of FIG.

FIG. 3B is a flowchart for determining whether a customer who does not have a primary account in the bank but has a secondary account (an account other than the primary account) has received a retirement allowance.
Here, there are some customers whose monthly salary transfer account and retirement payment transfer account are not the same. That is, the monthly salary transfer account is Bank A, but the retirement payment transfer account may be Bank B. A certain amount of money (large deposit) is suddenly transferred to the bank B account having such a customer one day. In such a case, the retirement allowance receiving company information DB is accessed, and it is confirmed whether or not there is a transfer from the same transfer source on the same day. The presence / absence of a company that has issued a retirement allowance is checked from the retirement allowance receiving company information DB.

  The process shown in FIG. 3B may be a process executed after the process shown in FIG.

  In S1041, the salary non-transfer person determined in S1030 is extracted. The salary non-transferr means a customer who does not have a primary account in the bank but has a secondary account (an account other than the primary account).

  In S1042, the severance pay receiving company information DB is accessed to receive the severance pay receiving customer information list.

  In S1071, based on the information from the retirement payee company information DB, it is recorded in the retirement payee customer information list that the remittance payment was received from the same transfer source on the same day as the retirement pay candidate deposited in the bank. To see if it is. In the severance pay customer information list, information on the name of the company that received the severance payment and the payment date is managed. Furthermore, the attribute data of the sub account is acquired from the customer attribute DB 232 and the like, and the age of the customer who has the sub account (for example, 60 years old) is specified. Based on such information, it is determined whether the retirement allowance is a true retirement allowance. For example, there is a possibility that there is a large deposit in the sub-account from the same transfer source (company) on the same day as the payment of the candidate for retirement allowance, and that the age of the customer who has the sub-account has received the retirement allowance If it is a certain age (for example, 60 years old), the retirement allowance candidate can be determined to be a retirement allowance. However, the amount of retirement allowance varies depending on the job title and years of service at the time of retirement, so the range of the amount for determining retirement allowance may be determined in advance.

  In S1081, if it is determined that the payment is a retirement allowance, the retirement receipt customer information list of the sub-account is updated. This severance payee customer information list is composed of a company / corporate name estimated to transfer severance pay and a transfer date. The sub-account retirement receipt customer information list may be updated to overwrite the retirement receipt customer information list of the main account created in S1080 of FIG. 3A. It may be created separately from the customer information list.

  In S1091, it is determined whether or not the determination is completed for all salary earners who have received the retirement allowance candidate. If it is determined for all salary earners who have received the retirement allowance, the process proceeds to S1100. If there are any remaining salary earners that need to be determined, the process returns to S1041 to continue this processing.

  In step S1101, the retirement payment receiving customer information list is transmitted to the retirement payment receiving company information DB, and the list managed in the retirement payment receiving company information DB is updated. As a result, the fact that the corresponding customer has received the retirement payment is recorded in the retirement payment receiving company information DB.

  In S1111, the updated sales retirement receipt customer information list is notified to the sales staff in the bank. Here, the list of retirement payment receiving customer information is composed only of information determined only from the main account (the name of the company / corporation that transferred the retirement allowance and the transfer date), or only information determined from the sub account. Alternatively, the information may be configured by combining these pieces of information. After the retirement allowance is determined, information recorded in a data format that can be understood by humans is output (for example, sent by e-mail), and the sales representative of the account is contacted.

  Such individual information is called MCIF. MCIF is an abbreviation for “Marketing Customer Information File” and means a file of customer information for marketing. According to an embodiment of the present invention, such a customer information file can be automatically constructed, so that efficient marketing can be performed, and sales support for proposing financial products according to customer's funding needs. It can be performed.

In the determination of retirement allowance in S1070 or S1071, retirement allowance for retirement was received based on such information if there is information such as general retirement age in the workplace information. It may also be determined. Further, if it is clear that the age is clearly younger than the general age of work, it may be determined that the employee has retired early.
In this embodiment, the procedure for reflecting the individual retirement benefit company information in the retirement benefit receiving customer information list in S1080 or S1081, and then transmitting the updated retirement benefit receiving customer information list in S1110 or S1111. As described above, as another embodiment, the configuration may be such that only individual retirement company information is individually transmitted to the bank without listing individual retirement company information.

  FIG. 4 shows an example of a data structure used in the system of FIG.

  FIG. 4A shows a data structure 2010 of the settlement information of the main account, which is composed of a requester ID (requester name), a payee ID (recipient name), a communication type, an account date, and a transaction amount. . The client ID is an ID (identifier) assigned to a person who requests the transfer of funds, a company, a corporation, or the like. The payee ID is an ID assigned to a person who receives funds, a company, a corporation, or the like. The communication item indicates the purpose of the transfer (payment), for example, salary transfer. The account date represents the date of deposit. The transaction amount indicates the amount received. Further, a main account flag may be provided in the data structure. As the main account flag, when the customer (recipient) is determined to be a salary transfer person in S1030 of FIG. 3, “1” indicating that it is a main account may be written. On the other hand, when it is determined in S1030 of FIG. 3 that the person is not a payer, “0” indicating a sub account may be written. Further, when it is not determined whether the account is a main account or a sub account, the flag may not be set.

  For example, in this embodiment, in FIG. 4A, 500,000 yen is transferred every month from Kanagawa Prefecture, the transfer source, to the individual A, the transfer destination, until March 15, 2015. Is shown (the history before November 15, 2014 is omitted). Furthermore, on April 10, 2015, it is shown that 10,000,000 yen has been transferred, and this large deposit is determined to be a retirement allowance candidate. Here, it is assumed that there is no transfer from another transfer source for the individual A.

  FIG. 4B shows a data structure 2020 for determining a work place from a past salary transfer history. Extracting a predetermined data structure (in this embodiment, a data structure for determining a work place) from the settlement information by specifying a specific transfer source (client ID) and the period of the account date Can do. Here, the transfer determined to be a retirement allowance candidate is excluded.

  Further, in FIG. 4B, additional information for processing the data is added to the extracted data structure. In this embodiment, an item called “account date” is added. It is specified for each client ID (in this embodiment, salary transfer source) that the year and month of salary transfer.

  As shown in FIG. 4 (b), if the transfer to the individual A is sorted (classified) by the client (ID) and the fact that the account date is generated every month is taken into consideration, the series of these will be changed. It can be determined that the transfer is a pay transfer without referring to the communication type. One reason for not referring to the communication type is that the communication type may differ (for example, simply “transfer”) depending on the company / corporation of the transfer source.

  FIG. 4C shows a data structure 2030 of the number of months received, which is generated by counting the number of months received based on the account date. The number of months received indicates, for example, the period during which the customer has been at the company, so the amount of retirement allowance may be estimated from the number of months received and the monthly salary transfer history, for example.

  FIG. 4D shows a data structure 2040 of the settlement information of the sub account. Even if there is no salary transfer, etc., if there is a large deposit (a candidate for retirement allowance is transferred), it is determined to be a sub-account.

  According to the present embodiment, for example, by applying the result determined in the primary account of bank A to the secondary account of the same bank A, it is possible to grasp the funding needs of the secondary account. That is, it becomes possible to determine the customer's funding needs with high accuracy from the settlement information of the sub-account using the information of the main account of the financial institution.

(Example 2)
FIG. 5 shows a second embodiment of the present invention. In the first embodiment, the EBM system of each bank is provided with the retirement allowance receiving company information DB. However, in the second embodiment, the retirement pay receiving company information DB provided in each bank is DB managed. An example is shown that is configured as a collaborative system 400 that is commonly managed via a server. The collaborative system jointly manages specific information (MCIF), and may be referred to as a joint MCIF center.

  The cooperative system 130 includes a DB management server 401, a retirement allowance determination unit 215, a retirement allowance receiving company information DB 403 for A bank, and a retirement pay receiving company information DB 413 for B bank. In addition, by providing a retirement allowance receiving company information DB for each bank such as a retirement paying company information DB 413 for bank A and a retirement paying company information DB 423 for bank B, each bank can provide appropriate information. Can be managed. In this embodiment, the DB management server 401 controls all DBs. However, in another embodiment, a management server may be provided for each DB.

  In the second embodiment, unlike the first embodiment, since the retirement allowance determination unit 215 is provided in the collaborative system 130, the step of determining the retirement allowance in each bank can be omitted. In addition, a plurality of banks that share the retirement benefit recipient company information list with each other can be managed under the common system.

  FIG. 6 is a flowchart illustrating an example of processing of the collaborative system 130 according to the second embodiment. In this embodiment, in particular, when a retirement allowance candidate (large deposit) is deposited in Bank A, the retirement candidate candidate deposited in Bank A using the result determined in the main account of Bank A or Bank B. An example for showing that it is determined that is a retirement allowance.

  In S1210, the DB management server 401 of the communalization system 130 acquires retirement benefit receiving company information from each bank (in this embodiment, A bank and B bank). The retirement allowance receiving company information is, for example, the company that transferred the retirement allowance and the transfer date.

  In S1220, the DB management server 401 transmits the retirement allowance company information acquired from the A bank to the A bank retirement allowance company information DB 413, and instructs to update the information in the DB. Similarly, the DB management server 401 transmits the retirement allowance company information acquired from the B bank to the B bank retirement allowance company information DB 413, and instructs to update the information in the DB. Here, the retirement allowance company information acquired in S1220 may generate a retirement benefit receiving customer information list based on the procedure as determined in FIG. 3A in each bank.

  In S1230, the DB management server 401 of the cooperative system 130 receives from A bank a signal requesting a determination as to whether or not a customer (payment non-payment person) having a sub account of A bank has received a retirement allowance.

  In S1240, the DB management server 401 accesses the retirement allowance receiving company information DB 413 for A bank and inquires about retirement allowance company information. If there is applicable retirement allowance company information, the process proceeds to S1250. If there is no relevant retirement allowance company information, the process proceeds to S1260.

  In S1250, the DB management server 401 obtains retirement allowance company information from the A bank retirement allowance receiving company information DB 413.

  In S1260, if there is no corresponding retirement benefit company information DB 413 in the bank A retirement payee company information DB 413, another bank retirement payee company information DB (in this embodiment, a retirement money recipient company for B bank). The information DB 423) is accessed to obtain the corresponding retirement company information. If there is no applicable retirement allowance company information in another bank retirement payee company information DB, the DB management server 401 may generate a signal indicating that acquisition is impossible.

  In S <b> 1270, the DB management server 401 determines whether or not the non-payee has received the retirement allowance based on the acquired retirement allowance company information.

  In S1280, the DB management server 401 sends the determination result of S1270 to the retirement allowance company information DB 403 of Bank A, and instructs to update the information in the retirement allowance company information DB 413.

  In S1290, the DB management server 401 transmits the determination result of S1270 to the A bank. Note that S1290 may be executed before S1280.

  In S1300, the DB management server 401 may update the severance pay customer information list based on the determination result in S1270. Further, the updated retirement payee customer information list may be transmitted to an arbitrary bank.

  As another example, when the DB management server 401 receives a signal requesting a retirement receipt customer information list from the A bank or the B bank in S1230, the DB management server 401 receives the retirement payment for A bank. The company information DB 413 and / or the B bank retirement allowance receiving company information DB 423 may be accessed to generate a necessary retirement pay receiving customer information list and return it to the requesting bank.

  According to this example, the number of target customers can be increased by handling payment information using a joint system at a plurality of financial institutions, and a part of the transactions can be grasped in advance to meet the customer's funding needs. Judgment can be made.

  According to the present embodiment, since the funding needs are grasped by the joint system, even if outside the business area, if the company has a transaction with the joint system participating financial institution, the judgment can be made more accurately. In other words, according to this embodiment, by grasping transactions outside the business area of a financial institution (particularly a local financial institution), the financial needs of customers who have a primary account or a secondary account at their own financial institution are highly accurate. Can be determined.

(Example 3)
The present embodiment is a modification of the first embodiment, and has an apartment loan contract, which regularly repays the loan and receives information on the main account that receives rent income from the apartment. An example of estimating a sub-account that does not have a loan contract with another bank but receives rent income is shown.

FIG. 6 is a functional block diagram of the system according to the third embodiment. For convenience of explanation, FIG. 6 shows only a functional block diagram of the EBM system 200 of A bank.
The control unit 611 controls each unit described later.
The lease destination determination unit 612 determines a company / corporation, etc., in which the customer having the account rents the apartment, using information on the past loan repayment history in the account A and the like.

  The past repayment history determination unit 613 searches that a certain amount of money has been transferred from a specific company every month (or at predetermined intervals), and that these series of transfers are rent income. judge. Also, a rent income history (list) is created as necessary.

  The rent income candidate receipt determination unit 614 determines that the receipt is a “rent income candidate” when a deposit that is considered to be rent income is confirmed in a specific account.

  The rent income determination unit 615 determines whether or not the deposit determined to be a rent income candidate in the account A is rent income based on customer attribute data for opening an account such as loan contract information. Determine.

Here, customer attribute data is stored in a customer attribute DB 632 described later. The customer attribute data may include a variety of information. For example, in addition to the customer's own information, the customer's attribute data may include information related to the customer (for example, family structure information, name identification information). The rent income determination unit 615 may also determine that the rent transfer account and the loan account are the same.

  The customer account DB 631 (DataBase) manages the funds deposited for each customer account. Further, the transaction history may be managed based on the settlement information for each account.

  The customer attribute DB 632 records customer attribute data (for example, customer-specific information such as customer name (corporate name), address, date of birth, occupation, family structure, etc.). Some customers have opened multiple accounts (for example, a savings account and a fixed deposit account) in the same bank. In order to centrally manage such customers (to properly manage so-called name identification), the plurality of accounts can be managed using identifiers for identifying the plurality of accounts as the same customer. It may be configured as follows.

  The settlement information DB 633 is a device for accumulating liquidity fund information related to the liquidity of the bank's deposits and information (settlement information) necessary for the settlement of funds such as an exchange rate.

  The rent income receiving customer DB 634 writes that the rent income has been received as the corresponding customer information when the rent income judging unit 615 judges that the rent has been received. In addition, the name of the company that transferred the rent and the transfer date may be written.

  The rent income receiving customer information DB 603 records information about customers who have received rent income.

  8A and 8B are flowcharts showing the flow of processing in the functional block shown in FIG. Hereinafter, the flow of processing in the present embodiment will be described with reference to FIG.

  FIG. 8A is a flowchart for determining whether a customer who has a main account in the bank (who has a loan contract) has received rent income.

  In S2010, based on the settlement process, a deposit process for transferring the designated amount into the designated customer account is performed.

  In S2020, it is determined whether or not the deposit processing based on the settlement information is a deposit that may be rent income. In this embodiment, such payment is referred to as “rent income candidate”. As for the method of determining a rent income candidate, each financial institution may individually determine the predetermined amount, or a plurality of financial institutions, a common server, or the like may determine the predetermined amount.

  In S2030, it is determined whether the customer to whom the rent income candidate has been deposited has made a loan contract at present or in the past. The bank (for example, Bank A) did not have a loan contract, but there may be a loan contract for another bank (for example, Bank B). That is, the loan payment account and the rent receiving account may be different. If you have a loan contract, determine that you are a loan contractor. That is, in the present embodiment, this loan contractor means a customer who has a main account in the bank (for example, Bank A).

  If the bank does not have a loan contract, it is determined that the person is not a loan contractor. The process when it is determined that the person is not a loan non-contractor will be described with reference to FIG. In other words, in this embodiment, the loan non-contractor is a customer who may have a main account in another bank (for example, Bank B), but is not in the main bank (for example, Bank A). It means that the customer does not have an account but has a sub account.

  An identifier or flag for identifying the loan contractor and the loan non-contractor may be added to the DB.

  In S2040, a loan contractor is extracted from the customers to whom the rent income candidates are transferred.

  In S2050, past repayments are searched and a loan repayment history of the extracted loan contractor is created.

  In S2060, the workplace is determined based on the past salary transfer history.

  In S2070, in addition to the processing results up to S2060, necessary information (for example, loan contract information) is obtained from customer attribute data, and it is determined whether or not the rent income candidate received is rent income. To do. For example, it may be determined whether or not it is rent income by estimating how much rent income can be expected every month from information on the loan contract.

  In S2080, if it is determined that the income is rent income, the rent income receiving customer information list of the main account is updated. This rent revenue receiving customer information list is composed of a company / corporate name estimated to transfer rent and a transfer date.

  In S2090, it is determined whether or not the determination has been completed for all loan contractors who have received the rent income candidates. If the determination is made for all loan contractors to whom the rent income candidates have been deposited, the process proceeds to S2100. If there is a loan contractor that needs to be determined, the process returns to S2040 to continue the process.

  In S2100, the rent income receiving customer information list is transmitted to the rent income receiving customer information DB, and the list managed by the rent income receiving customer information DB is updated. Thereby, the fact that the corresponding customer has received the rent income is recorded in the rent income receiving customer information DB.

  In step S2110, the updated rent income receiving customer information list is notified to the sales staff in the bank. After it is determined that there is rent income, the data is output in a data format that can be understood by humans (for example, sent by e-mail) to contact the sales person in charge of the account, or contact the person in charge at the call center. To do. As a result, a sales representative or a call center representative can present a financial product corresponding to the customer's funding needs by visiting the customer or making a call. Note that S2110 may be omitted when the process of FIG.

FIG. 8B is a flowchart for determining whether a customer who does not have a primary account in his / her bank but has a secondary account (an account other than the primary account) receives rent income.
Here, some customers do not have the same loan contract account as the rent transfer account. In other words, the loan contract account is Bank A, but the account that receives the rent transfer may be Bank B. A certain amount of money (payment) is suddenly transferred to the bank B account having such a customer one day. In such a case, the rent revenue receiving customer information DB is accessed and it is confirmed whether or not there is a transfer from the same transfer source on the same day. From the rent revenue receiving customer information DB, it is confirmed whether or not there is a company to which the rent has been transferred. If there is a corresponding company, it is determined that the rent income has been transferred to the B bank.

  The process shown in FIG. 8B may be a process executed after the process shown in FIG.

  In S2041, the loan non-contractor determined in S2030 is extracted. A loan non-contractor means a customer who does not have a primary account in the bank but has a secondary account (an account other than the primary account).

  In S2042, the rent income receiving customer information DB is accessed to receive the rent income receiving customer information list.

  In S2071, based on the information from the rent income receiving customer information DB, it is recorded in the rent income receiving customer information list that the rent has been received from the same transfer source on the same day as the rent income candidate received by the bank. Check whether it is. In the rent income receiving customer information list, information on the name of the company that received the rent and the payment date is managed. Further, the attribute data of the sub account may be acquired from the customer attribute DB 232 or the like, and the customer information having the sub account may be specified. Based on such information, it is determined whether or not the rent income candidate is true rent income. For example, if there is payment in the sub-account from the same transfer source (company) on the same day as the payment of the rent income candidate, it can be determined that the rent income candidate is rent income. However, since the amount of rent income varies depending on the property, the range of the amount for determining rent income may be determined in advance.

  In S2081, if it is determined that it is rent income, the rent income receiving customer information list of the sub-account is updated. This rent revenue receiving customer information list is composed of a company / corporate name estimated to transfer rent and a transfer date. The rent income receiving customer information list of the sub-account may be updated so as to overwrite the rent income receiving customer information list of the main account created in S2080 of FIG. 8 (a). It may be created separately from the customer information list.

  In S2091, it is determined whether or not the determination has been completed for all salary earners who have received rent income candidates. If the determination is made for all salary earners who have received rent income candidates, the process proceeds to S1100. If there are any remaining salary earners that need to be determined, the process returns to S1041 to continue this processing.

  In S2101, the rent income receiving customer information list is transmitted to the rent income receiving customer information DB, and the list managed by the rent income receiving customer information DB is updated. Thereby, the fact that the corresponding customer has received the rent income is recorded in the rent income receiving customer information DB.

  In S2111, the updated rent receiving customer information list is notified to the sales staff in the bank. Here, the rent revenue receiving customer information list may consist only of information determined only from the main account (name of company / corporation to which the rent was transferred and the transfer date), or only information determined from the sub-account. The information may be composed of a combination of these pieces of information. After it is determined as rent income, information recorded in a data format that can be understood by humans is output (for example, sent by e-mail), and the sales representative of the account is contacted.

  As shown in Examples 1 to 3, in the present invention, based on the past transfer history, it is classified into a main account and a sub-account, and the large amount transferred to the sub-account based on the transfer information of the main account By determining the purpose of the deposit, it becomes possible to grasp the funding needs of customers who have not only the primary account but also the secondary account with high accuracy.

  Although the embodiments of the present invention have been described above, various alternatives, modifications, and variations can be made by those skilled in the art based on the above description, and the present invention is not limited to the various embodiments described above without departing from the spirit of the present invention. It encompasses alternatives, modifications or variations.

100 System 200, 300 EBM system 210, 310 Internal server 211, 320 Control unit 212 Work place determination unit 213 Past salary transfer determination unit 214 Retirement payment candidate deposit determination unit 215 Retirement allowance determination unit 220 Terminal 230 Internal DB
231 Customer Account DB
232 Customer attribute DB
233 Financial Information DB
234 Retirement benefits recipient DB
401 DB management server 403 Retirement allowance receiving company information DB
500 networks

According to one aspect of the present invention, in a computer system for managing a financial account, a main account that has received a predetermined continuous transfer or a predetermined continuous transfer based on a past transfer history And determining that the deposit transferred to the main account is a deposit with a predetermined purpose based on the attribute data of the main account. Means for determining that the deposit transferred to the sub-account is a deposit candidate that may be a deposit with a predetermined purpose, and a transfer source of the deposit candidate transferred to the sub-account And the transfer date matches the transfer source and transfer date of the deposit transferred to the main account, the deposit candidate transferred to the sub-account is based on the attribute data of the sub-account. With the same purpose as the deposit transferred to And a means for determining that the system is provided.

In S2060, the lease destination is determined based on the transfer history such as past loan repayment .

Claims (5)

In a computer system that manages financial accounts,
A means for classifying a primary account that has received a predetermined continuous transfer or a predetermined continuous transfer based on a past transfer history, and a sub-account that does not have a predetermined continuous transfer;
Means for determining that the large deposit transferred to the main account is a deposit with a predetermined purpose based on the attribute data of the main account;
Means for determining that the large deposit received in the sub-account is a candidate deposit that may be a deposit with a predetermined purpose;
If the transfer source and transfer date of the candidate deposit transferred to the sub-account match the transfer source and transfer date of the large deposit transferred to the main account, the transfer candidate transferred to the sub-account is Based on the attribute data of the sub-account, means for determining that the deposit has the same purpose as the large deposit transferred to the main account;
A system comprising: In a computer system that manages financial accounts,
Based on past salary transfer history, classify into primary account with salary transfer and secondary account without salary transfer,
Means for determining that the large deposit transferred to the main account is a retirement allowance based on the attribute data of the main account;
Means for determining that the large deposit deposited in the sub-account is a retirement allowance;
The retirement allowance transferred to the sub-account when the transfer source and transfer date of the retirement candidate transferred to the sub-account match the transfer source and transfer date of the retirement payment transferred to the main account. Means for determining that the candidate is a retirement allowance based on the attribute data of the sub-account;
A system comprising: In a computer system that manages financial accounts,
Based on past repayment history, a means to classify a loan into a primary account with a loan and a secondary account without a loan,
Means for determining that the deposit transferred to the main account is rent income based on the attribute data of the main account;
Means for determining that the deposit received in the sub-account is a rent income candidate;
If the transfer source and transfer date of the rent income candidate transferred to the sub-account match the transfer date and transfer date of the retirement payment transferred to the main account, the rent revenue transferred to the sub-account Means for determining that the candidate is rent income based on the attribute data of the sub-account;
A system comprising: In a computer system that manages financial accounts,
Multiple EBM systems;
A collaborative system,
With
Each of the plurality of EBM systems includes means for classifying into a primary account having a predetermined continuous transfer and a secondary account having no predetermined continuous transfer based on a past transfer history,
One of the plurality of EBM systems is
Means for determining that the large deposit transferred to the main account is a deposit with a predetermined purpose based on the attribute data of the main account, and transmitting to the collaborative system;
With
One or the other of the plurality of EBM systems is
Means for determining that the large deposit received in the sub-account is a candidate deposit that may be a deposit with a predetermined purpose, and transmitting an inquiry signal to the collaborative system;
With
The collaborative system is
If the transfer source and transfer date of the candidate deposit transferred to the sub-account match the transfer source and transfer date of the large deposit transferred to the main account, the sub-account attribute data is used to Means for determining that the deposit candidate deposited in the account is the same deposit as the large deposit deposited in the main account; In a computer program for managing financial accounts,
A means for classifying a primary account that has received a predetermined continuous transfer or a predetermined continuous transfer based on a past transfer history, and a sub-account that does not have a predetermined continuous transfer;
Means for determining that the large deposit transferred to the main account is a deposit with a predetermined purpose based on the attribute data of the main account;
Means for determining that the large deposit received in the sub-account is a candidate deposit that may be a deposit with a predetermined purpose;
If the transfer source and transfer date of the candidate deposit transferred to the sub-account match the transfer source and transfer date of the large deposit transferred to the main account, the transfer candidate transferred to the sub-account is Based on the attribute data of the sub-account, means for determining that the deposit has the same purpose as the large deposit transferred to the main account;
A program comprising: