JP2010244312A - Transfer control method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an information processing method enabling a transfer preventing a crime such as a transfer fraud, without using the feature of the transfer. <P>SOLUTION: By the authentication of a user/owner of the account of a transfer destination, whether the transfer is to be performed is decided based on the authentication result. In this case, the transfer may be suspended in a temporary retained state until the authentication at the transfer destination is completed. When the transfer in the temporary retained state exists in the transfer destination, a related person to the transfer destination may be notified of that effect. The notification may be made by mail, display on a Web page, etc. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a technique for controlling transfer and transfer to an account using a financial institution, and more particularly to a technique for suppressing crimes such as so-called transfer fraud.

  Currently, transfer (transfer) is generally used for payment to a trading partner. Payments can also be made to remote parties by bank transfer. However, so-called transfer frauds that pretend to be close relatives and make transfers are rampant.

Patent Literature 1 has been proposed as a technique for preventing this criminal act. Patent Document 1 displays a warning message for a transfer fraud only when there is a high possibility of a transfer fraud based on the details of the transfer request and the transfer history of the transfer source account. Here, in Patent Document 1, “high possibility of being involved in wire fraud” is determined based on the following viewpoints.
"If you have made a transfer to the same bank account before the transfer related to the transfer request and it has been a long time, it is not likely that the transfer related to the transfer request is due to a transfer fraud. In addition, even if it has not been transferred to the same bank account, if the transfer amount is fractional, it is due to purchase of goods, etc. Based on the insight that the transfer is not likely to be due to a transfer fraud, and if the transfer amount is small, it is not likely to be due to a transfer fraud. Is it sudden for the victim because he / she tries to make the transfer before he / she is in contact with his / her spouse, child, grandchild, etc. allegedly in trouble? Because it ’s an urgent transfer, it ’s based on the insight that if you ’re running multiple transfers in a row, it ’s not likely to be due to a transfer fraud. ” Judgment is made based on this.

JP 2007-272409 A

  In Patent Document 1, it is determined whether the transfer is a fraud based on the transfer characteristics. For this reason, when the transfer by fraud takes this characteristic in the opposite direction and makes the transfer according to the normal characteristic, it cannot be prevented. Moreover, it may happen to be the same as the characteristics of a normal transaction, and conversely, a normal transaction may have the characteristics described above. It is difficult to find characteristics that solve this problem for the following reasons. If the emphasis is placed on preventing fraud, the convenience of formal transactions will be impaired, and attempts to improve convenience will not prevent fraud transfers. In other words, you must satisfy both contradictions.

  In order to solve the above-described problems, the present invention employs the following configuration. That is, the user / holder is authenticated for the transfer account, and it is determined whether to establish the transfer based on this result. At this time, it is also included in the present invention that the transfer is temporarily held in a financial institution until authentication at the transfer destination.

  Further, in the present invention, when there is a temporary deposit in the transfer destination, the transfer recipient is notified to that effect (including information processing for prompting authentication such as sending an e-mail or displaying on a homepage). That is also one aspect thereof. In addition, if there are multiple temporary deposits at a single bank account, each transfer is changed from the temporary deposit by one-time authentication (including multiple authentications once) (depending on the result) It is also included in the present invention to make a transfer or make a transfer impossible.

  According to the present invention, it is possible to determine whether or not to establish a transfer in a stricter manner, and it is possible to prevent crimes such as so-called transfer fraud.

It is a block diagram of the Example of this invention. It is a flowchart which shows the process after a transfer person inputs transfer information until it is registered into DB of a bank system. It is a flowchart which shows the process which notifies the transfer holder name of the transfer information with which the bank system is registered. It is a flowchart which shows a process until a transfer holder name authenticates with respect to transfer information and a transfer process is completed. It is a figure which shows the example of the content of the transfer information D1. It is a figure which shows the example of the content of management DBD2. It is a figure which shows the example of the content of customer DB (D3). It is a figure which shows the example of the content of authentication log | history DB (D4).

  FIG. 1 is a system configuration diagram in one embodiment of the present invention. In FIG. 1, an ATM (S1) installed in a bank, a bank host computer (S3), a plurality of online PCs (S5), an R / W (S6) and a mobile phone (S7) connected thereto. And an IC card connected to ATM or R / W. Each of these devices is a so-called information processing device, and a processing unit called a CPU executes the processing according to a program.

  FIG. 2 is a flowchart showing a process from when the transfer person makes a transfer to inputting the transfer information until it is registered in the DB of the bank system. FIG. 3 is a flowchart showing a process of notifying the transfer holder of the transfer information registered in the bank system. FIG. 4 is a flowchart showing a process until the transfer holder is authenticated for the transfer information and the transfer process is completed.

The operation will be described below with reference to the drawings (particularly FIGS. 2 and 3).
In F21 of FIG. 2, the transfer information (D1) is input when performing the transfer from the transfer person. The transfer information (D1) is input using an ATM (S1) in the bank, an online PC (S5), a mobile phone (S7), or the like. After that, the cash is transferred by the transfer person or an instruction to transfer the funds from the transfer account is accepted, and the system moves the funds to the temporary account of the bank. Alternatively, the transfer process can be canceled without accepting input.

  Next, in F22, the ATM (S1), the online PC (S5), or the mobile phone (S7) determines whether the transfer by the transfer request accepted in F21 is a cash transfer. In this case, if it is determined to transfer in cash at F21 based on the operation from the user, the process proceeds to F27. If it is determined that the transfer will be made using the bank account of the transfer person, proceed to F23.

  In F23, the transfer information (D1) input in F21 is transmitted from the ATM (S1) or the like to the bank host computer and received by the host computer (S3). Here, in the case of transfer using an account, the name of the account holder of the account of the transfer person included in the transfer information (D1) is extracted as the name of the transfer person. In the case of the transfer by cash, the name of the transfer person who has been confirmed in F28 is extracted (host computer (S3)).

  In F24, the host computer (S3) refers to the authentication history DB (D4) of FIG. 4 corresponding to the transfer destination account number of the transfer information (D1), and confirms whether the name of the transfer person exists. When the name of the transfer person exists, it is assumed that the transfer destination account has been successfully authenticated to the transfer person in the past. If it does not exist, it is assumed that the transfer destination account has not been successfully authenticated to the transfer person in the past. If the transfer account has been successfully authenticated in the past, proceed to F30. If the transfer account has not been successfully authenticated in the past, proceed to F25.

  In F25, the host computer (S3) generates (numbers) a unique ID for the transfer information (D1) received in F23. The unique ID is, for example, account number + date / time + random number.

  In F26, the host computer (S3) stores the transfer information (D1) and the unique ID generated in F25 in the management DB (D2). At this time, the “state” of the management DB (D2) is not transmitted (information indicating untransmitted is stored).

  In F27, the ATM (S1) or the online PC (S5) reads the cardholder name from the IC card that can confirm the identity of the transfer person inserted (installed) in the R / W (S6).

  In F28, if the ATM (S1) or online PC (S5) has the same name as the cardholder read from the IC card that can be confirmed, and the transfer person name in the transfer information (D1) entered in F21, proceed to F23. . If the cardholder name read from the IC card that can verify the identity is different from the transferor name in the transfer information (D1) entered in F21, the process returns to F21.

  In F30, the host computer (S3) performs a general transfer process according to the transfer information (D1) input in F21. Money is delivered according to normal bank transactions.

  Next, with reference to FIG. 3, a process for notifying a transfer destination when there is a transfer request will be described.

  The host computer (S3) unprocesses each record of the customer DB (D3) at the start of FIG. This may be when the system is constructed. Further, when registering a record in the customer DB, unprocessed information may be stored.

  In F31, the host computer (S3) refers to the customer DB (D3) one by one for each account number and confirms whether there is an unprocessed record. If yes, go to F32. If not, go to F36.

  In F32, the host computer (S3) extracts an arbitrary record from the remaining records, and refers to the transmission schedule stored in the customer DB (D3) for this record. When referred to, the previous confirmation time of the customer DB (D3) is updated. In addition, the processing of the customer DB (D3) is updated to “processed”. Check if the current time has passed the transmission schedule time referenced from the previous confirmation time. This confirmation process is performed by comparing the previous confirmation time stored in the customer DB with the current time. Judge that it is the contact time when time has passed. If it is contact time, go to F33. If it is not contact time, go to F31.

  In F33, the host computer (S3) extracts, from the management DB (D2), the account number referred to in F31 and the transfer destination account number are the same and the status is “unsent”. If the number of extracted records is 0, there is no record whose status is “unsent”, and the process proceeds to F31. If one or more records are extracted, proceed to F34.

  In F35, the host computer (S3) transmits an email indicating that there is transfer information at the email address (of the extracted record) of the customer DB (D3) referred to in F31.

  In F36, the host computer (S3) waits until the check time (previously stored in the storage device) determined by the bank. For example, if it is determined to check at 1 hour intervals, if the check is performed at 2 o'clock, it waits until 3 o'clock of the next check time.

  Each step described above is repeated until each record in the customer DB (D3) is processed in F31. That is, referring to the record next to the currently referenced record, F32 to F34 are repeated. The order of reference does not matter. For example, if “account holder” currently refers to Hitachi Taro's record in a specific order, then “account holder” will refer to Hitachi Jiro's record. Further, the mail transmission (F34) may be repeatedly executed in F32 and F33, and the transmission may be executed collectively after there is no unprocessed record.

  The account holder who has received the number of transfer information uses his bank's ATM (S1), online PC (S5), mobile phone (S7), etc. to access and manage his customer page. Refer to DB (D2) data. That is, the PC (S5) or the like accesses the customer page and receives data in response to an operation from the user.

  Data that can be referred to on the customer page is data managed in the management DB (D2), customer DB (D3), and authentication history DB (D4). At this time, the “status” changes to “transmitted” by referring to the data whose “status” has not been transmitted.

  In F44, if there is no host computer (S3) whose “state” in the management DB (D2) is complete, the processing is terminated because there is no processing to be performed. In F45, the PC (S5) or the like accepts selection of transfer information whose “state” is not completed from the account holder.

  In F46, the ATM (S1) or the online PC (S5) performs authentication using an IC card that can identify the person. That is, authentication is performed using encryption processing of the IC card inserted in / W (S6). In this authentication, it is confirmed that the name of the IC card that can verify the identity of the account holder is the same. Any authentication method is acceptable.

  In F47, ATM (s1) or the like adds the name of the transfer person to the authentication history DB (D4) when the authentication performed in F46 is successful, and proceeds to F48. If the authentication is not successful, 1 is added to the “number of consecutive failures” of the customer DB (D3), and the process proceeds to F50.

  In F48, the host computer (S3) executes a deposit process for the transfer destination account of the transfer amount of the transfer information selected in F45. Funds to be deposited are funds temporarily stored by banks at F21. Also, the “continuous failure count” of the customer DB (D3) is set to zero. Here, it is said that the deposit is temporarily stored in the virtual account (temporary deposit account) DB (not shown) with information on the transfer (information specifying the transfer source and transfer destination, the transfer amount, and the transfer source instructed The date and time or the transfer date that is the date and time stored in the DB) and its state (temporary deposit, transfer completed, transfer impossible) are stored. Even if no transfer is made (even in a temporary deposit state), it is possible to determine whether the transfer source has complied with the payment due date according to the transfer timing. In addition, the transfer is suppressed for a transfer that cannot be transferred.

  In F49, the host computer (S3) sets the “state” of the record in the management DB (D2) for which the transfer process has been completed to complete. In F50, the “continuous failure count” in the customer DB (D3) is referred to. If the “number of consecutive failures” is 3 or more, proceed to F51. If the “number of consecutive failures” is less than 3, proceed to F46. In F51, the IC card that can be used for identity verification is locked so that the authentication performed in F46 cannot be performed.

S1 ... ATM
S2 ... IC card S3 ... bank host computer S4 ... DB
S5 ... PC
S6 ... R / W
S7 ... Mobile phone

Claims (4)

In a transfer control method for controlling a transfer process using a transfer source device, a transfer destination device, and a financial institution device connected to the transfer source device and the transfer destination device,
The transfer source device accepts a transfer request including the transfer destination and the transfer amount from the transfer person,
Sending the transfer request from the transfer source device to the financial institution device,
The financial institution device stores the transfer destination and transfer amount included in the transfer request in a database,
In response to an operation of a transferee participant for the transfer destination device, authentication for the participant is performed,
The said financial institution apparatus performs the transfer process of the said transfer amount with respect to the said transfer destination according to the result of the said authentication, The transfer control method characterized by the above-mentioned. In the transfer control method according to claim 1,
In the database, the transfer destination and the transfer amount are stored in association with information indicating a temporary storage state,
If the authentication is affirmative, the information indicating the temporary deposit state is changed to information indicating that the transfer has been completed, and if the authentication is negative, the information indicating the temporary deposit state is changed to information indicating that transfer cannot be performed. The transfer control method characterized by changing to. In the transfer control method according to claim 2,
In the database, information indicating the contact information of the transfer destination is further stored.
The financial institution apparatus, when information indicating the temporary custody status is stored for a certain period or longer, executes a process of prompting the participant to authenticate using the information indicating the contact address Control method. In the transfer control method according to claim 2 or 3,
When there are a plurality of transfer requests in a temporary deposit state at the transfer destination, the authentication is performed for each of the plurality of transfer requests with one authentication.

Images