JP2019028863A - Money transfer supporting device, method for supporting money transfer, and money transfer supporting program - Google Patents

Abstract

To provide a money transfer supporting device, a method for supporting a money transfer, and a money transfer supporting program that can allow a remitter to transfer money safely.SOLUTION: A bank server 111 has a notification unit 401, a reception unit 402, and a money transfer control unit 403. The notification unit 401 issues a notification to the effect that money is being transferred to a receiver whose contact address has been registered in advance when the notification unit receives a request to send money to the receiver from a remitter. The reception unit 402 receives an approval for the money transfer from the receiver by the notification to the effect that the money transfer is being made to the receiver. The money transfer control unit 403 executes the money transfer in response to the approval accepted by the reception unit 402.SELECTED DRAWING: Figure 4

Description

  The present invention relates to a remittance support apparatus, a remittance support method, and a remittance support program.

  2. Description of the Related Art Conventionally, a user transfers money to a specified account by performing a predetermined procedure from a financial institution or an ATM (Automated Teller Machine). In remittance, remittance that is not intended by the remittance may be performed, such as fraudulent fraud (so-called transfer fraud). Transfer fraud is, for example, by pretending that the recipient (criminal) is a relative and making a transfer request to the designated account to the sender (victim), deceiving the sender and transferring money to the designated account. It is a fraud that makes you scam.

  As related prior art, past transfer transaction information is accumulated for each transfer requester, and a warning is displayed when the transfer destination account of this transfer transaction has not been transferred in the past (For example, refer to Patent Document 1 below).

JP 2007-102620 A

  However, in the prior art, there is a case where a remittance that is not intended by the remittance may be performed, so that the remittance may not be able to remit in peace. Specifically, the remittance that is not intended by the remittance may be caused by, for example, a misconception that, for example, the remittance is wrong, or an erroneous operation such as remittance of money in addition to the bank transfer fraud.

  The present invention eliminates the problems caused by the prior art described above, so that a remittance person can remit money safely. Particularly, the remittance support apparatus, remittance support method, and remittance support program that are effective for fraudulent fraud The purpose is to provide.

  In order to solve the above-described problems and achieve the object, the remittance support apparatus according to the present invention, when a request for remittance is received from a remittance to a recipient whose contact information is registered in advance, In response to the notification received by the receiving unit, a notifying unit for notifying the recipient that the remittance will be performed, a receiving unit for accepting the remittance from the recipient by the notification, and the accepting unit And a remittance control unit for executing the remittance.

  The remittance assistance apparatus according to the present invention is characterized in that, in the above invention, the consent includes authentication of the recipient.

  The remittance support apparatus according to the present invention is the remittance support apparatus according to the above invention, wherein the notification unit receives the predetermined character string when receiving the request including the input of the predetermined character string indicating the remittance from the remittance person. The notification including the above is performed.

  The remittance support apparatus according to the present invention is the remittance support apparatus according to the above invention, wherein the remittance control unit does not accept the consent by the accepting unit until a predetermined period elapses after the notification is made, When the accepting unit accepts that the remittance is not performed, the request accepted from the sender is canceled.

  The remittance support apparatus according to the present invention is characterized in that, in the above invention, when the request is canceled by the remittance control unit, the notification unit notifies the remittance to that effect. And

  In the remittance support apparatus according to the present invention as set forth in the invention described above, the notifying unit sends a request to the remittance to the remittance to the recipient, and the recipient's agent whose contact information has been registered in advance. When accepting from the remittance that the notification is to be made, the agent is notified, the accepting unit accepts the consent from the agent by the notification, and the remittance control unit is the agent The remittance is executed to the recipient in response to the consent from the user.

  In the remittance support apparatus according to the present invention, in the above invention, the notification includes an acceptance result of accepting from the remittance one or more types of authentication to be performed by the recipient out of a plurality of types of authentication. The authentication of the person is the kind of authentication indicated by the reception result.

  In addition, the remittance support method according to the present invention provides a notification that the remittance is performed to the recipient when a request for remittance is received from the remittance to the recipient whose contact information has been registered in advance. The computer executes a process of accepting an acceptance from the recipient that the remittance is performed according to the notification, and executing the remittance according to the accepted acceptance.

  In addition, the remittance support program according to the present invention provides a notification that the remittance will be performed to the recipient when a request for remittance is received from the remittance to the recipient whose contact information is registered in advance. And accepting from the recipient the consent that the remittance is performed by the notification, and causing the computer to execute a process of executing the remittance according to the accepted consent.

  According to the remittance support device, the remittance support method, and the remittance support program according to the present invention, the remittance person can remit with peace of mind, and the effect is particularly effective for countermeasures against fraud involving the relatives.

FIG. 1 is an explanatory diagram of a system configuration example of a remittance support system 100 according to the embodiment. FIG. 2A is a block diagram illustrating an example of a hardware configuration of the bank server 111. FIG. 2B is a block diagram illustrating an example of the hardware configuration of the sender terminal 121 and the receiver terminal 131. FIG. 3A is an explanatory diagram showing an example of the contents stored in the sender information database (DB) 112. FIG. 3B is an explanatory diagram showing an example of the contents stored in the recipient information database (DB) 113. FIG. 3C is an explanatory diagram showing an example of the contents stored in the agent information database (DB) 114. FIG. 3D is an explanatory diagram showing an example of the stored contents of the transaction information database (DB) 115. FIG. 4 is an explanatory diagram showing a functional configuration of the bank server 111. FIG. 5 is an explanatory view showing an example of a display screen when a request for remittance is made from the recipient 130 to the remittance 120 by e-mail. FIG. 6 is an explanatory diagram showing an example of a display screen when a remittance request is made at the remittance terminal 121. FIG. 7 is an explanatory diagram showing an example of a confirmation mail display screen displayed on the recipient terminal 131. FIG. 8 is an explanatory diagram showing an example of a display screen when accepting remittance from the recipient 130. FIG. 9 is an explanatory diagram illustrating an example of a display screen when an input of a comment from the recipient 130 is received. FIG. 10 is an explanatory diagram showing an example of a display screen of a remittance procedure completion notification displayed on the recipient terminal 131. FIG. 11 is an explanatory diagram showing an example of a display screen of a remittance procedure completion notification displayed on the remittance terminal 121. FIG. 12 is an explanatory diagram showing an example of a cancel notification display screen indicating that the remittance procedure displayed on the remittance terminal 121 has been cancelled. FIG. 13 is a sequence diagram illustrating an example (part 1) of the remittance support processing procedure according to the present embodiment. FIG. 14 is a sequence diagram illustrating an example (part 2) of the remittance support processing procedure according to the present embodiment. FIG. 15 is a sequence diagram illustrating an example (part 3) of the remittance support processing procedure according to the present embodiment. FIG. 16 is a sequence diagram illustrating an example (part 4) of the remittance support processing procedure according to the present embodiment. FIG. 17 is a flowchart illustrating an example of a remittance support processing procedure performed by the bank server 111.

  Exemplary embodiments of a remittance support apparatus, a remittance support method, and a remittance support program according to the present invention will be described below in detail with reference to the drawings.

(System configuration of remittance support system)
First, a system configuration example of the remittance support system 100 according to the embodiment will be described. FIG. 1 is an explanatory diagram of a system configuration example of a remittance support system 100 according to the embodiment. In FIG. 1, the remittance support system 100 includes a bank server 111, a remittance terminal 121, and a recipient terminal 131.

  The bank server 111 is a server provided in the bank 110, for example, and is an example of a remittance support apparatus. The bank server 111 is a general-purpose computer device such as a personal computer that manages card information of a cash card for each user and deposit / withdrawal of an account. The bank server 111 includes a CPU (Central Processing Unit), a memory, an interface, and the like.

  Further, the bank server 111 includes a sender information database (DB) 112, a recipient information database (DB) 113, an agent information database (DB) 114, and a transaction information database (DB) 115. The contents stored in the various DBs 112 to 115 will be described later with reference to FIGS. 3A to 3D.

  The remitter terminal 121 is a computer device used by the remitter 120 who transfers money to a designated account. For example, a smart phone or a tablet PC (Personal Computer) can be used as the remittance terminal 121. However, the remittance terminal 121 is not limited thereto, and can be, for example, a desktop PC, a notebook PC, a mobile phone, a PHS (Personal Handyphone System), an ATM (Automated Teller Machine) installed in a financial institution, or the like. It is. The sender terminal 121 has a CPU, a memory, an interface, and the like.

  The recipient terminal 131 is a general-purpose computer device such as a personal computer used by the recipient 130. As the recipient terminal 131, for example, a smartphone, a tablet PC, or the like can be used. However, the recipient terminal 131 is not limited to this, and a desktop PC, a notebook PC, a mobile phone, a PHS, or the like can also be used. The recipient terminal 131 has a CPU, a memory, an interface, and the like. It is assumed that contact information such as the mail address and telephone number of the recipient terminal 131 is registered in the bank server 111 in advance.

  In the money transfer support system 100, the bank server 111, the money sender terminal 121, and the recipient terminal 131 are connected via a wired or wireless network 140. The network 140 is, for example, the Internet, a mobile communication network, a LAN (Local Area Network), a WAN (Wide Area Network), or the like.

  A remittance support program according to the present invention is installed in the bank server 111. The bank server 111 performs processing according to various requests from the sender terminal 121 and the receiver terminal 131 and outputs various processing results to the sender terminal 121 and the receiver terminal 131.

  Here, the remittance support method according to the present embodiment will be described. As shown in (1) of FIG. 1, the remittance terminal 121 makes a remittance request to the recipient 130 to the bank server 111 in accordance with the operation of the remittance 120. Specifically, the remitter terminal 121 receives a request from the remitter 120 for remittance to the recipient 130. The recipient 130 corresponds to the recipient terminal 131 whose contact information is registered in the bank server 111 in advance. For example, as shown on the display screen 122, the remittance terminal 121 accepts a remittance destination indicating the recipient 130 and the amount to be remittance.

  When the bank server 111 accepts a remittance request from the remittance terminal 121, the bank server 111 notifies the remittance terminal 131 that remittance is performed as shown in (2). The notification that remittance is performed is a notification that remittance is performed from the remittance person 120 as shown in the display screen 132.

  Then, as shown in (3), when the recipient terminal 131 accepts from the recipient 130 the consent that the remittance will be performed, the recipient terminal 131 transmits that fact to the bank server 111. Then, as shown in (4), the bank server 111 executes remittance according to the acceptance accepted by the recipient terminal 131.

  As described above, in the present embodiment, the bank server 111 executes the remittance after obtaining the consent of the recipient 130 when sending the remittance from the sender 120 to the recipient 130. For this reason, the bank server 111 can suppress that the remittance 120 does not intend to perform remittance. Thereby, the remittance person 120 can remit money in comfort.

(Example of hardware configuration of bank server 111)
Next, an example of a specific configuration of the bank server 111 will be described. FIG. 2A is a block diagram illustrating an example of a hardware configuration of the bank server 111. In FIG. 2A, the computer device that realizes the bank server 111 includes a CPU 211, a memory 212, and a communication IF (Interface) 213. The units 211 to 213 included in the computer device are connected by a bus 210. The CPU 211 controls the entire computer device.

  The memory 212 stores programs such as a boot program and various database data. In addition, the memory 212 stores various programs and data related to provision of the remittance support service, such as a remittance support program and partial data of various databases.

  The memory 212 is used as a work area for the CPU 211. The memory 212 can be realized by, for example, a ROM (Read-Only Memory), a RAM (Random Access Memory), a HDD (Hard Disc Drive), and an HD (Hard Disc).

  The communication IF 213 is connected to the network 140 and controls an interface between the inside of the computer device and external devices such as the remittance terminal 121 and the recipient terminal 131. Specifically, the communication IF 213 controls data input / output between the inside of the computer device and the external device.

(An example of the hardware configuration of the sender terminal 121 and the receiver terminal 131)
Next, an example of the hardware configuration of the sender terminal 121 and the receiver terminal 131 will be described. FIG. 2B is a block diagram illustrating an example of the hardware configuration of the sender terminal 121 and the receiver terminal 131. Since the sender terminal 121 and the receiver terminal 131 have the same configuration, only the sender terminal 121 will be described below, and description of the receiver terminal 131 will be omitted.

  In FIG. 2B, the sender terminal 121 includes a CPU 221, a memory 222, an output device 223, an input device 224, and a communication IF 225. In addition, the units 221 to 225 included in the remittance terminal 121 are connected to each other by a bus 220.

  The CPU 221 controls the entire sender terminal 121. The CPU 221 controls the entire sender terminal 121 using various programs and data stored in the memory 222. The memory 222 can be realized by a hard disk, a flash memory, or the like.

  The output device 223 includes, for example, a display, a speaker, an audio output terminal, and the like. The display displays operation contents, guidance information for the user, and the like. The display displays various operation screens related to the money transfer support service. The display can be realized, for example, mainly by a liquid crystal display, an organic EL (Electro-Luminescence) display, or the like.

  The speaker outputs sound, alarm sound, and the like. The audio output terminal is a terminal for connecting a headphone or the like, and outputs sound, an alarm sound or the like to the connected headphone or the like in the same manner as a speaker.

  The input device 224 includes keys for inputting characters, numerical values, various instructions, and the like, and performs data input. The input device 224 can be realized by, for example, a touch panel or a keyboard. The input device 224 realized by a touch panel, a keyboard, or the like outputs a signal corresponding to an input operation on the input device 224 to the CPU 221.

  When the input device 224 is realized by a touch panel, the touch panel is stacked on the display surface side of the display. When the touch panel detects that a writing member such as a finger or a pen is in contact, the touch panel outputs an electrical signal corresponding to the contact position of the writing member with respect to the touch panel. As the touch panel, various known methods such as a resistive film method, a capacitance method, an acoustic pulse recognition method, an ultrasonic surface acoustic wave method, an infrared light shielding method, and an image recognition method can be used.

  The input device 224 includes a camera. The camera is controlled by the CPU 221 to capture an imaging target, generate image data, capture and input a two-dimensional code such as a barcode or QR code (registered trademark), and an OCR (Optical Character Reader) function. It is possible to input the characters photographed using the data.

  The input device 224 includes a microphone. The microphone performs analog / digital conversion on the voice of the speaker input as analog data, and generates digital audio data. By using the microphone, the user can input characters and the like via the remittance terminal 121 instead of using the touch panel or the keyboard.

  The communication IF 225 controls the interface between the sender terminal 121 and external devices such as the bank server 111 and the receiver terminal 131. The communication IF 225 may be connected to a telephone line network and used for voice communication.

  In addition, although not shown, the remittance terminal 121 has a function as an information processing apparatus such as a smartphone, such as a call function including a speaker and a communication function.

(Storage contents of various DBs 112 to 114)
Next, contents stored in the various DBs 112 to 114 included in the bank server 111 illustrated in FIG. 1 will be described with reference to FIGS. 3A to 3D. The various DBs 112 to 114 are realized by a storage unit such as a memory, for example.

  FIG. 3A is an explanatory diagram showing an example of the contents stored in the sender information database (DB) 112. In FIG. 3A, the sender information DB 112 has fields of sender ID (Identification), sender name, account number, and mail address. By setting information in each field, a record of sender information (for example, sender information 300-1 to 300-3) is stored.

  The sender ID indicates identification information assigned to each sender 120 (user). The sender's name indicates the name of the account holder corresponding to the sender 120. The account number is a number assigned to each account, and indicates the account number of the sender 120. The e-mail address indicates the e-mail address of the terminal corresponding to the sender 120, specifically, the e-mail address of the sender terminal 121.

  For example, the sender information 300-1 indicates a sender ID “A001”, a sender name “Soken Soko”, an account number “0123456”, and an email address “XX@XXX.jp”. Similarly, the sender information 300-2 and 300-3 other than the user ID “A001” are also stored in the sender information DB 112.

  In FIG. 3A, for the sake of convenience of explanation, the information of each field shown in the sender information DB 112 is stored. However, all fields shown in FIG. 3A may not be stored. For example, information on some fields (for example, e-mail addresses) may be stored in another DB in association with the user ID. In this case, some fields from the other DB using the user ID are stored. It is sufficient to acquire the information.

  FIG. 3B is an explanatory diagram showing an example of the contents stored in the recipient information database (DB) 113. In FIG. 3B, the recipient information DB 113 has fields of a sender ID, a recipient ID, a usual call name, a recipient name, an account number, an email address, a password, and image data. By setting information in each field, a record of recipient information (for example, recipient information 310-1 to 310-3) is stored.

  The sender ID indicates identification information given to each sender 120, and is the same as the sender ID stored in the sender information DB 112 (see FIG. 3A), and is indicated by the sender ID in the sender information DB 112. It also corresponds to each sender information 300. The recipient ID indicates identification information given to each recipient 130. The usual nickname is a nickname, regardless of Kanji, English, Katakana, etc. The recipient name indicates the name of the account holder corresponding to the recipient 130. The account number is a number assigned to each account and indicates the account number of the recipient 130. The e-mail address indicates the e-mail address of the terminal corresponding to the recipient 130, specifically, the e-mail address of the recipient terminal 131.

  The password indicates a character string for authentication when the recipient 130 accepts the remittance at the recipient terminal 131. Specifically, the password is a number or a symbol, and includes a secret word. The image information data indicates the face image data of the recipient 130 for performing face authentication instead of the password.

  For example, the recipient information 310-1 includes the sender ID “A001”, the recipient ID “B001”, the usual name “Taro”, the recipient name “Sokentaro”, the account number “1234567”, and the mail address “XX”. @ Xxx.jp ", password" xxx ", and image data" xxx ". Similarly, the recipient information 310-2 and 310-3 other than the recipient ID “B001” are also stored in the recipient information DB 113.

  In the recipient information DB 113, the “ordinary nickname” can be stored, so that the sender 120 can select “ordinary nickname” and send the money to the recipient 130. The bank server 111 can send an email requesting consent to the email address associated with the “ordinary name” sent from the sender terminal. As described above, the remittance person 120 selects the “ordinary nickname”, whereby the correct holder (recipient name) associated with the “ordinary nickname” can be specified.

  In FIG. 3B, for convenience of explanation, the information of each field shown in the recipient information DB 113 is stored, but it may not have all the fields shown in FIG. 3B. For example, information on some fields (for example, image data) may be stored in another DB in association with the user ID. In this case, some fields are stored from the other DB using the user ID. It is sufficient to acquire the information.

  FIG. 3C is an explanatory diagram showing an example of the contents stored in the agent information database (DB) 114. In FIG. 3C, the agent information DB 114 includes fields for a recipient ID, agent name, agent e-mail address, and agent password. By setting information in each field, records of agent information (for example, agent information 320-1 to 320-3) are stored.

  The recipient ID indicates identification information given to each recipient 130, and is the same as the recipient ID stored in the recipient information DB 113 (see FIG. 3B), and is indicated by the recipient ID of the recipient information DB 113. It also corresponds to each sender information 310. The name of the agent is the name of the person who represents the recipient 130, for example, the name of the spouse or child of the recipient 130. The agent mail address indicates the mail address of the agent terminal corresponding to the agent. The agent password indicates a character string for authentication used when the agent accepts remittance to the recipient 130 at the agent terminal.

  For example, the agent information 320-1 indicates the recipient ID “B001”, the agent name “Soken Hanako”, the agent e-mail address “XX@XXX.jp”, and the agent password “XXXXX”. . Further, for example, the agent information 320-2 indicates that no agent is registered. Specifically, for “Sokenjiro” (see FIG. 3B) corresponding to the recipient ID “B002”, Indicates that the agent is not registered. Similarly, the agent information 320-3 is also stored in the agent information DB 114.

  FIG. 3D is an explanatory diagram showing an example of the stored contents of the transaction information database (DB) 115. 3D, the transaction information DB 115 includes fields for transaction information ID, sender ID, recipient ID, recipient account number, amount, subject, authentication method, procedure date and time, and procedure completion status. By setting information in each field, a record of transaction information (for example, transaction information 330-1, 330-2) is stored.

  Transaction information ID shows the identification information attached | subjected for every transaction information. The sender ID indicates identification information given to each sender 120 and is the same as the sender ID stored in the sender information DB 112 (see FIG. 3A) and the recipient information DB 113 (see FIG. 3B). The sender ID corresponds to each sender information 300 indicated by the sender ID in the sender information DB 112 and each sender information 310 indicated by the recipient ID in the recipient information DB 113.

  The recipient ID indicates identification information given to each recipient 130 and is the same as the recipient ID stored in the recipient information DB 113 (see FIG. 3B) or the agent information DB 114 (see FIG. 3C). is there. The recipient ID also corresponds to each sender information 310 indicated by the recipient ID in the recipient information DB 113 and each agent information 320 indicated by the recipient ID in the agent information DB 114.

  The remittance destination account number is the account number of the remittance destination, for example, the account number shown in FIG. 3B, but may be a designated account number other than this. The amount indicates the amount of money transferred from the sender 120 to the recipient 130. The subject indicates the subject of an email transmitted from the bank server 111 in order for the recipient 130 to accept the remittance at the recipient terminal 131.

  The authentication method is an authentication method used in authentication performed when the recipient 130 accepts remittance at the recipient terminal 131, and indicates an authentication method designated by the remitter 120. The procedure date and time indicates the date and time when the remittance person 120 made a remittance request.

  The procedure completion status indicates whether or not the remittance request has been completed in response to the remittance request made by the remittor 120. Specifically, the procedure is completed when the recipient 130 consents. If the recipient 130 does not consent, the incomplete state is maintained.

  For example, the transaction information 330-1 includes a transaction information ID “X001”, a sender ID “A001”, a recipient ID “B001”, a sender account number “1234567”, an amount “5000 yen”, a subject “Sakura no Kai”, Indicates the authentication method “password”, the procedure date and time “○ month ○ date ○ hour ○ minute ○ second”, and the procedure completion status “completed”. Similarly, transaction information 330-2 other than the transaction information ID “X001” is also stored in the transaction information DB 115.

(Functional configuration of bank server 111)
FIG. 4 is an explanatory diagram showing a functional configuration of the bank server 111. In FIG. 4, the bank server 111 includes a notification unit 401, a reception unit 402, and a remittance control unit 403. The notification unit 401, the reception unit 402, and the remittance control unit 403 implement their functions by causing the CPU 211 to execute a program stored in the memory 212 (see FIG. 2A) of the bank server 111, for example.

  When the notification unit 401 receives a request from the sender 120 to send a remittance to a recipient 130 whose contact is registered in advance, the notification unit 401 notifies the recipient 130 of a notification that the remittance will be made. Do it. The contact address is a contact address corresponding to the recipient 130, and is a mail address or a telephone number. Specifically, the contact address may be a mail address or a telephone number of the recipient terminal 131 for each recipient 130, or may be a free mail mail address or a home phone number.

  “Registered in advance” means that it has already been registered when a remittance request is received. For example, it is at least a predetermined period (for example, 1) with reference to a request for remittance (remittance request). It is that it was registered before. Specifically, the recipient 130 whose contact information is registered in advance is a remittance destination to which remittance is performed at a predetermined frequency, for example, a target of financial assistance such as a child, a parent, or a sibling.

  To send money to the recipient 130 means to send money to the recipient account. Remittance is the transfer of funds to specified accounts, for example, the transfer of funds between accounts, or the transfer of funds from a financial institution's window or ATM to a specified account. , Transfer. The bank server 111 accepts a request from the sender 120 for remittance via the sender terminal 121 or ATM. The notification that the remittance will be performed is performed by e-mail, for example, but may be performed by a short message or telephone.

  The accepting unit 402 accepts from the recipient 130 consent that remittance will be performed according to the notification. The consent that the remittance is to be made can be done because the recipient 130 knows in advance that the remittance will be made. In other words, if the recipient 130 does not remember, it will be obtained from the recipient 130. It is never done.

  In the present embodiment, as a premise for performing remittance, the recipient 130 knows in advance that remittance will be performed by requesting remittance from the remittor 130 to the remittance 120 or by periodic remittance. Suppose that

  The acceptance by the accepting unit 402 is made to be performed by the recipient 130 by accessing the predetermined address indicated in the e-mail message from the recipient terminal 131, for example. However, acceptance of acceptance by the accepting unit 402 is not limited to this, and a blank email may be returned in response to a transmitted electronic mail or the like. In addition, when calling the contact information, for example, the consent may be accepted by an auto call.

  The remittance control unit 403 executes remittance according to the consent received by the receiving unit 402. Specifically, the remittance control unit 403 executes remittance to the recipient account when the accepting unit 402 accepts the consent of the recipient 130, and when the accepting unit 402 does not accept the acceptor 130. Does not perform the remittance.

  In this embodiment, the consent includes authentication of the recipient 130. The authentication of the recipient 130 is password authentication or biometric authentication performed by the recipient 130. Password authentication is authentication performed by determining whether a predetermined character string matches. Biometric authentication includes fingerprint authentication, face authentication, blood vessel authentication, retinal authentication, and palm-shaped authentication. Authentication may be performed by the bank server 111, may be performed by the recipient terminal 131, or may be performed by another device.

  In addition, the notification that remittance is performed includes a reception result in which one or more types of authentication to be performed by the recipient 130 from among a plurality of types of authentication are received from the remittor 120. The authentication performed by the recipient 130 is the type of authentication indicated by the reception result, that is, the type of authentication selected by the sender 120.

  Specifically, in the present embodiment, examples of the plurality of types of authentication include password authentication, face authentication, and fingerprint authentication. Among these, one or more types of authentication are accepted from the sender 120, and the recipient 130 authenticates by the accepted type of authentication. The number of types of authentication received from the sender 120 may be one type or a plurality of types.

  In the present embodiment, password authentication and face authentication are performed by the bank server 111. Specifically, the bank server 111 acquires a password and face image data from the recipient terminal 131 and performs authentication respectively. The fingerprint authentication is performed by the recipient terminal 131. Specifically, fingerprint authentication is performed using the fingerprint authentication function of the recipient terminal 131.

  However, the recipient 130 may select the authentication type without selecting the approval type by the remittance person 120. For example, when the recipient 130 is ill or serious and the agent is not registered (see the agent information 320-2 in FIG. 3C), a third party such as a colleague of the recipient 130 In some cases, the recipient terminal 131 is operated to request the remittance 120 to send money and to obtain consent for the money transfer.

  In this case, the third party images the image data of the face of the recipient 130 from the license of the recipient 130 using the imaging function of the recipient terminal 131, for example. Then, the captured image data is transmitted from the recipient terminal 131 to the bank server 111, and when the face authentication using the image data is successful in the bank server 111, the money can be transferred to the recipient account.

  Further, in the present embodiment, the notification unit 401 makes a notification including a predetermined character string when a request including an input of a predetermined character string indicating remittance is received from the sender 120. The predetermined character string is a character string used when contacting from the bank server 111 to the recipient terminal 131. The predetermined character string is specifically a keyword shared by the recipient 130 and the sender 120, and includes, for example, letters, symbols, numbers, and the like.

  The predetermined character string indicates to the recipient 130 that the notification is related to remittance before the recipient 130 confirms the content of the notification that the remittance will be performed, for example, at the stage where the notification is received. A string that can be shown.

  For example, the predetermined character string is used for a subject (title) attached to an e-mail. By using a predetermined character string in the subject line of the e-mail, it is possible to indicate to the recipient 130 that the e-mail is not a mischievous e-mail but an email for accepting remittance. Can be opened (confirmed). Thereby, the notification part 401 can accept consent that remittance will be performed.

  It is also possible to use a predetermined character string as the telephone number of a financial institution associated with the bank server 111. In this case, the bank number is notified by notifying the recipient 130 of the telephone number when a short message is received. A short message from the server 111 can be shown. Therefore, the recipient 130 can open the short message with peace of mind. Thereby, the notification part 401 can accept consent that remittance will be performed.

  It is also possible to use a predetermined character string as a telephone number of a financial institution associated with the bank server 111. In this case, by notifying the recipient 130 of the telephone number when a call is received, It can be shown that the call is from the server 111. For this reason, the recipient 130 can answer the call with peace of mind. Thereby, the notification part 401 can accept consent that remittance will be performed, for example by an auto call.

  Further, in the present embodiment, for example, the predetermined character string is notified when a remittance request is made from the recipient 130 to the remittance 120 before the remittance request from the remittor 120 to the bank server 111 is made. . However, the present invention is not limited thereto, and the predetermined character string may be determined on the remittance 120 side in the remittance request and notified to the recipient 130 from the remittance 120.

  In addition, the remittance control unit 403 cancels the remittance request when the acceptance unit 402 does not accept the approval after the notification that the remittance is performed until the predetermined period elapses. The predetermined period is, for example, 24 hours. “Cancel” refers to, for example, canceling all, but is not limited to this, and may be resumed after being temporarily interrupted.

  The remittance control unit 403 cancels the remittance request addressed to the recipient 130 when the accepting unit 402 accepts that the remittance is not performed. For example, if a predetermined period of time has passed since the notification that the remittance is made, or that the remittance is not accepted is not a request from the recipient 130 to the remittor 120, This can happen if the recipient 130 is an unintended remittance. For this reason, the remittance control unit 403 cancels the remittance request after the elapse of a predetermined period.

  In addition, when the remittance request addressed to the recipient 130 is canceled by the remittance control unit 403, the notification unit 401 notifies the remittor 120 of the fact. Specifically, the notification unit 401 notifies the remittance terminal 121 that the remittance request addressed to the recipient 130 has been canceled.

  Further, the notification unit 401 informs the sender 130 of a remittance request to the recipient 130 and notifies the recipient 130 (for example, the email address of the agent) that the contact information has been registered in advance. If accepted, the agent will be notified that the remittance will be made. The agent is, for example, a person who has a close relationship with the recipient 130, and specifically, a spouse or a child of the recipient 130.

  The accepting unit 402 accepts that the remittance is performed from the agent by notifying that the remittance is performed. The remittance control unit 403 performs remittance to the recipient 130 in response to the consent that remittance is performed from the agent. Specifically, when the accepting unit 402 accepts the agent's consent, the remittance control unit 403 executes remittance to the recipient account.

(Display screen examples of the sender terminal 121 and the receiver terminal 131)
FIG. 5 is an explanatory view showing an example of a display screen when a request for remittance is made from the recipient 130 to the remittance 120 by e-mail. A display screen 500 of FIG. 5 shows an e-mail creation screen. Specifically, as shown in the display screen 500, the bank server 111 requests the sender terminal to request a 5000 yen remittance for a predetermined title, the sender 120 (Soken Soko), by operating the recipient 130. The subject of the email sent to 121 is entered as “Sakura no Kai”. When the send button 501 is operated by the recipient 130 on the display screen 500, the recipient terminal 131 sends the contents shown on the display screen 500 to the bank server 111.

  FIG. 6 is an explanatory diagram showing an example of a display screen when a remittance request is made at the remittance terminal 121. A display screen 600 in FIG. 6 shows a remittance content input screen that can be displayed by accessing the bank server 111. Specifically, as shown in the display screen 600, the remittance 120 operation inputs the remittance account number, usual name, recipient name, remittance amount, subject, authentication type, and agent items. The

  In the display screen 600, the account number of the remittance destination is entered in “Remittance destination account number”. For example, when the drop-down button 601a is selected by the remittance person 120, an account number registered in advance is displayed in a selectable manner. Note that a number that has not been registered in advance can be directly input in the “remittance account number”.

  In the display screen 600, the nickname (for example, “Taro”) of the recipient 130 is input to “ordinary name”. For example, when the drop-down button 601e is selected by the money sender 120, a nickname registered in advance is displayed so as to be selectable.

  It should be noted that the item “for whom” may be used instead of the item “ordinary name”. The item “for whom” may be simply replaced with the name of “ordinary name”, that is, in the example of the display screen 600, a tallow similar to the nickname can be displayed. However, the item “for whom” can be, for example, the name of another person who can recall the recipient 130 for the sender 120 or the nickname of the other person.

  As described above, even if the item “for whom” is selected, an email requesting consent can be transmitted to the email address associated with the item “for whom” the sender 120 thinks. Specifically, even if the remittance destination is an unexpected (first time) account, an e-mail requesting approval of remittance may be sent to the e-mail address associated with the selection result in the “for whom” item it can.

  Note that when any one of the drop-down buttons 601a, 601b, and 601e is operated to select a value, the other two values may be determined according to the selection. Specifically, for example, when “Taro” is selected in the drop-down button 601e among the drop-down buttons 601a, 601b, and 601e, the bank server 111 refers to the recipient information DB 113, thereby Recipient name “Sokentaro” and account number “1234567” associated with “Taro” in “Name” may be determined.

  On the display screen 600, the name of the remittance destination is entered in “Recipient Name”. For example, when the drop-down button 601b is selected by the sender 120, the name of the recipient 130 registered in advance is displayed in a selectable manner.

  On the display screen 600, the amount to be transferred is input in “Remittance”. The amount of money to be sent can be arbitrarily determined by the sender 120. In the display screen 600, a title given to the e-mail is input to “Subject”.

  In the “authentication type”, any of password authentication, face authentication, and fingerprint authentication is input. For example, when the remittance person 120 selects the drop-down button 601c, one is input. However, in the “authentication type”, an item “not selected” may be displayed to be selectable. When the item “not selected” is selected, a predetermined authentication type (for example, password authentication) may be selected, or an authentication type can be arbitrarily selected on the recipient 130 side. It is good.

  On the display screen 600, “not specified” or “registered agent” is input as “agent”. For example, when the remittance person 120 selects the drop-down button 601d, one is input. When “not specified” is selected, the recipient is notified that the remittance will be performed, and the recipient needs to consent to the remittance. On the other hand, when “registered agent” is selected, the agent is notified that the remittance will be performed, and the agent needs to approve the remittance.

  When the execution button 602 is operated by the money sender 120 on the display screen 600, the contents shown on the display screen 600 are transmitted to the bank server 111. Thus, the operation performed on the remittance 120 side is completed. In addition, although the case where the remittance request is made from the remittance terminal 121 has been described, the remittance request can be made not only from the remittance terminal 121 but also from the ATM. Even when a remittance request is made from an ATM, a remittance request can be made on the same display screen as in FIG.

  FIG. 7 is an explanatory diagram showing an example of a confirmation mail display screen displayed on the recipient terminal 131. A display screen 700 of FIG. 7 shows a text screen of received mail. Specifically, the display screen 700 shows a notification 710 that a remittance to the recipient 130 will be performed. The notification 710 indicates that it is possible to accept consent from the recipient 130 that money transfer will be performed by accessing a site indicated by a URL (Uniform Resource Locator) 711.

  The display screen 700 shows an alarm 720. The alarm 720 indicates that it is possible to accept from the recipient 130 that remittance is not performed by accessing the site indicated by the URL 721. Further, by accessing the site indicated by the URL 721, it is possible to notify that a remittance that is not memorized is about to be performed. As a result, for example, it is possible to prevent a transfer fraud or provide information that leads to the identification of a criminal, and it is possible to take an appropriate initial response.

  FIG. 8 is an explanatory diagram showing an example of a display screen when accepting remittance from the recipient 130. The display screen 800 of FIG. 8 shows a password input screen that can be displayed by accessing the site indicated by the URL 711. When the recipient 130 inputs a password and the send button 801 is operated, the bank server 111 performs password authentication.

  The display screen 800 shows a case where password authentication is performed. When face authentication is designated by the sender 120, the face image data of the recipient 130 transmitted from the recipient terminal 131 is used as the face screen. Authentication is performed. When fingerprint authentication is designated by the remittance person 120, fingerprint authentication is performed at the recipient terminal 131, and the result is transmitted from the recipient terminal 131.

  FIG. 9 is an explanatory diagram illustrating an example of a display screen when an input of a comment from the recipient 130 is received. In the display screen 900 of FIG. 9, when a comment is input by the recipient 130 and the transmission button 901 is operated, the content of the comment is transmitted to the sender terminal 121 via the bank server 111. On the other hand, when the end button 902 is operated, the processing ends as it is.

  Here, the comment may include the personal information of the recipient 130. If the password and personal information are stolen in association with each other, there is a risk of damage such as skimming. In the present embodiment, the comment and password are not transmitted at the same time, but are transmitted separately.

  Specifically, first, only the password is transmitted, and then the comment is transmitted. Thus, the password can be transmitted as simple character string data. Therefore, it is possible to prevent the password and personal information from being associated and stolen.

  FIG. 10 is an explanatory diagram showing an example of a display screen of a remittance procedure completion notification displayed on the recipient terminal 131. A display screen 1000 in FIG. 10 shows a screen indicating that remittance has been completed. As a result, the recipient 130 can grasp that the remittance procedure has been completed.

  FIG. 11 is an explanatory diagram showing an example of a display screen of a remittance procedure completion notification displayed on the remittance terminal 121. A display screen 1100 in FIG. 11 shows a screen indicating that remittance has been completed. Thereby, the remittance person 120 can grasp | ascertain that the remittance procedure was completed.

  FIG. 12 is an explanatory diagram showing an example of a cancel notification display screen indicating that the remittance procedure displayed on the remittance terminal 121 has been cancelled. A display screen 1200 of FIG. 12 shows a screen indicating that the remittance has been stopped. For example, the remittance procedure is canceled when the consent of the recipient 130 is not obtained within 24 hours, or when it is accepted that the remittance is not performed from the recipient 130. The display screen 1200 allows the remittance person 120 to grasp that the remittance procedure has been completed.

(Example of remittance support processing procedure according to this embodiment)
Next, an example of a remittance support processing procedure according to the present embodiment will be described with reference to FIGS. FIG. 13 is a sequence diagram illustrating an example (part 1) of the remittance support processing procedure according to the present embodiment.

  In the sequence diagram of FIG. 13, the recipient terminal 131 makes a request for remittance to the remittance terminal 121 (step S1301). An example of the screen for requesting remittance includes the display screen 500 shown in FIG. In the remittance request, for example, the recipient terminal 131 transmits to the remittance terminal 121 that a remittance of 5000 yen is requested or that the subject of the mail transmitted from the bank server 111 is “Sakura no Kai”.

  The remittance terminal 121 makes a remittance request to the bank server 111 (step S1302). An example of the remittance request screen is, for example, the display screen 600 shown in FIG. In the remittance request, the sender terminal 121 transmits to the bank server 111, for example, a remittance amount of 5000 yen, a subject of an email “Sakura no Kai”, an authentication type, and the like.

  Then, the bank server 111 deposits an amount (5000 yen) corresponding to the remittance amount into the separate account 1310 (step S1303). The separate account 1310 is an account within a financial period that is temporarily stored before the remittance procedure is completed. The funds stored in the separate account 1310 are transferred to a designated account when a predetermined condition such as a predetermined date is met. Note that no fee is charged when transferring funds to the separate account 1310.

  Then, the bank server 111 transmits a confirmation e-mail indicating notification that remittance will be performed to the recipient terminal 131 (step S1304). The subject of the confirmation email is “Sakura no Kai”. As a result, the recipient 130 can confirm that it is an e-mail with contents related to the remittance procedure without opening it. Therefore, the recipient 130 knows that it is not a junk mail or the like, and can open the electronic mail with peace of mind. An example of the confirmation mail screen is the display screen 700 shown in FIG.

  Then, a predetermined site is accessed from the recipient terminal 131 to the bank server 111, and authentication is performed (step S1305). For example, a display screen 800 shown in FIG. 8 can be cited as an example of a screen used for authentication. Also, a comment may be received from the recipient 130 accompanying the authentication (see the display screen 900 in FIG. 9). Thereby, while being able to express an appreciation for the sender from the recipient, the sender can also confirm that the remittance was successful from the comment of the sender.

  Next, if the authentication is successful, the bank server 111 remits 5000 yen from the separate account 1310 to the recipient account (step S1306). A fee is charged when transferring funds from the separate account 1310 to the recipient account. Then, the bank server 111 transmits a completion notification to the sender terminal 121 and the receiver terminal 131 (step S1307). Thereby, a series of remittance support processing is completed.

  An example of a completion notification screen displayed on the recipient terminal 131 is the display screen 1000 shown in FIG. An example of the completion notification screen displayed on the sender terminal 121 is the display screen 1100 shown in FIG.

  In this way, since the remittance is executed with the consent of the recipient 130 whose contact information is registered in advance, remittance to a stranger can be suppressed. Remittance unintended by the recipient 130 can be suppressed.

  FIG. 14 is a sequence diagram illustrating an example (part 2) of the remittance support processing procedure according to the present embodiment. The remittance support processing procedure shown in FIG. 14 is different from the remittance support processing procedure shown in FIG. 13 in that the account number of the remittance destination is not an account number registered in advance. In the following description, the same parts as those in FIG. 13 are denoted by the same reference numerals, and description thereof is omitted.

  In FIG. 14, for example, it is assumed that the recipient 130 makes a remittance request to an account that is not registered in advance. Specifically, it is assumed that there is a remittance request from the recipient 130, for example, “I want to send money to the company account urgently”.

  In the sequence diagram of FIG. 14, the recipient terminal 131 registers a new account in the bank server 111 (step S1401). Then, the receiver terminal 131 requests the sender terminal 121 to send money to the new account (step S1402).

  Then, the remittance terminal 121 requests the bank server 111 to transfer money to the new account (step S1403). The remittance request is made, for example, on the display screen 600 shown in FIG. 6, and “remittance account number” is newly designated on the display screen 600.

  Next, as shown in step S1305, if the authentication is successful, the bank server 111 remits 5000 yen from the separate account 1310 to the new account (step S1404). Thereby, according to this Embodiment, it is also possible to transfer money to a new account. For this reason, even when there is a remittance request from the recipient 130 to an account that is not registered in advance, the sender 120 can transfer the account to the account with confidence.

  FIG. 15 is a sequence diagram illustrating an example (part 3) of the remittance support processing procedure according to the present embodiment. The remittance support processing procedure shown in FIG. 15 is different from the remittance support processing procedure shown in FIG. 13 in that the recipient terminal 131 is not used and the agent terminal 1500 is used. In the following description, the same parts as those in FIG. 13 are denoted by the same reference numerals, and description thereof is omitted.

  In FIG. 15, for example, it is assumed that the recipient 130 cannot make a request for remittance or accept the remittance, and the agent performs these. Specifically, for example, it is assumed that the recipient 130 is unconscious due to illness or an accident, and the agent makes a remittance request to the remittance and grants the remittance.

  In the sequence diagram of FIG. 15, the agent terminal 1500 makes a remittance request to the sender terminal 121 (step S1501). An example of the remittance request display screen is the display screen 500 shown in FIG. 5, but the sender is not the recipient 130 but an agent. In the remittance request, for example, the agent terminal 1500 transmits to the remittance terminal 121 that a remittance of 5000 yen is requested or that the subject of the mail transmitted from the bank server 111 is “Sakura no Kai”.

  Then, the bank server 111 deposits an amount (5000 yen) corresponding to the remittance amount into the separate account 1310 (step S1303), and then sends a confirmation e-mail indicating notification that remittance will be performed to the agent terminal 1500. (Step S1502). The subject of the confirmation email is “Sakura no Kai”.

  Thus, the agent can determine that the email is related to remittance by the subject (title) of the email, and can open the email. An example of the confirmation mail screen is the display screen 700 shown in FIG. 7, but the destination is not the recipient 130 but the agent.

  Next, the agent terminal 1500 accesses the bank server 111 to a predetermined site, and authentication is performed (step S1503). For example, as an example of a screen for performing authentication, the display screen 800 shown in FIG. 8 can be cited, and the password of the agent is input as the password. Also, a comment may be received from an agent accompanying the authentication.

  If the authentication of the agent is successful, the bank server 111 remits 5000 yen from the separate account 1310 to the recipient account (step S1306), and in addition to the sender terminal 121 and the recipient terminal 131, the agent terminal A completion notification is also transmitted to 1500 (step S1504). Thereby, a series of remittance support processing is completed.

  In this way, even when the recipient 130 and the sender 120 cannot be contacted directly, such as when the recipient 130 is seriously ill or critical, the recipient's agent accepts the transfer and accepts it. Money can be sent to the person 130. For this reason, even if it is a remittance request | requirement from an agent, the remittance person 120 can remit money to the receiver 130 in comfort.

  FIG. 16 is a sequence diagram illustrating an example (part 4) of the remittance support processing procedure according to the present embodiment. The remittance support processing procedure shown in FIG. 16 differs from the remittance support processing procedure shown in FIG. 13 in that authentication of the recipient 130 fails. In the following description, the same parts as those in FIG. 13 are denoted by the same reference numerals, and description thereof is omitted.

  In the sequence diagram of FIG. 16, as shown in step S 1304, when a confirmation mail is transmitted to the recipient terminal 131, the recipient terminal 131 accesses the bank server 111 to a predetermined site for authentication. However, it is assumed that the authentication has failed (step S1601). Specifically, the authentication failure means that the recipient 130 has entered a wrong password, the case where the recipient 130 has not accepted the remittance, or a predetermined time within 24 hours after the confirmation email is sent. Including no access to the site.

  When the authentication fails as described above, the bank server 111 returns 5000 yen from the separate account 1310 to the sender account (step S1602). There is no fee for returning funds from the separate account 1310 to the sender account. For this reason, when the authentication fails, no money is transferred to the recipient account and no fee is generated.

  Here, once the money is transferred to the account of the remittance destination that is not intended for the sender 120, it may be troublesome or difficult to return the transferred funds. Since the funds are not transferred to the designated account until the authentication of 130 is successful, the funds can be easily returned from the separate account 1310 to the sender account when the authentication of the recipient 130 fails.

  Then, the bank server 111 transmits a cancel notification to the remitter terminal 121 (step S1603). Thereby, a series of remittance support processing is completed. An example of the cancel notification screen displayed on the sender terminal 121 is the display screen 1200 shown in FIG.

  Thus, when authentication fails, in order to cancel a remittance request, remittance which the recipient 130 does not intend, such as a transfer fraud, can be suppressed, for example. In addition, when the authentication fails, a cancel notification is performed, so that the sender 120 can recognize that fact. Thereby, it is possible to take a quick initial response to a crime such as a transfer fraud.

(Remittance support processing procedure performed by the bank server 111)
FIG. 17 is a flowchart illustrating an example of a remittance support processing procedure performed by the bank server 111. In the flowchart of FIG. 17, the bank server 111 determines whether or not a remittance request (see FIG. 6) has been received from the remittance terminal 121 (step S1701). The bank server 111 waits until a remittance request is received from the remittance terminal 121 (step S1701: No).

  When the bank server 111 receives a remittance request from the remittance terminal 121 (step S1701: Yes), the bank server 111 deposits the remittance amount into another account (step S1702). Then, it is determined whether or not an agent is specified in the remittance request from the remittance terminal 121 (step S1703). When no agent is designated (step S1703: No), the bank server 111 refers to the recipient information DB 113 (see FIG. 3B) and acquires the mail address of the recipient 130 (step S1704).

  When the agent is designated (step S1703: Yes), the bank server 111 refers to the agent information DB 114 (see FIG. 3C) and acquires the agent's mail address (step S1705). Then, the bank server 111 transmits a confirmation mail (see FIG. 7) to the acquired mail address (step S1706).

  Next, the bank server 111 determines whether or not the authentication (see FIG. 8) has succeeded (step S1707). The authentication here includes not only authentication such as password authentication but also the consent of the recipient 130. If the authentication is not successful (step S1707: No), the bank server 111 determines whether or not a predetermined time (for example, 24 hours from the transmission of the confirmation mail) has elapsed (step S1708).

  When the predetermined time has not elapsed (step S1708: No), the bank server 111 determines whether it is a re-request timing (step S1709). The re-request timing is, for example, every hour. By making the re-request, it is possible to prompt the recipient 130 to view the confirmation mail and to accept the remittance.

  If it is not the re-request timing (step S1709: NO), the bank server 111 proceeds to step S1707. If it is the re-request timing (step S1709: YES), the bank server 111 proceeds to step S1706.

  When the predetermined time has elapsed (step S1708: Yes), the bank server 111 returns the amount to be transferred from another account to the sender account (step S1710), and transmits a cancellation notice (see FIG. 12) to the sender terminal 121 ( In step S1711), a series of processes according to this flowchart is terminated.

  When the bank server 111 succeeds in the authentication (step S1707: Yes), specifically, when the authentication such as the password authentication succeeds and the recipient 130 obtains the consent, the remittance amount is received from the separate account. The account is transferred to the account (step S1712), a completion notice (see FIGS. 10 and 11) is transmitted to the sender terminal 121 and the receiver terminal 131 (step S1713), and a series of processing according to this flowchart ends.

  As described above, when the bank server 111 according to the present embodiment receives a remittance request from the remittor 120 to the recipient 130 whose contact information has been registered in advance, the remittance accepted from the recipient 130 is Remittance was carried out according to the consent to be done.

  Thereby, while it is possible to transfer money only to a person whose contact is registered in advance, it is not possible to transfer money to a person whose contact is not registered in advance. Therefore, since remittance to a stranger can be prevented, remittance that is not intended by the remittance person 120 can be suppressed, and this is particularly effective as a countermeasure against fraudulent fraud (so-called transfer fraud).

  Further, according to the bank server 111 according to the present embodiment, the recipient 130 whose contact information is registered and the recipient 130 who actually receives the remittance are regarded as being the same person, and the recipient 130 consents. And remittance can be executed. For this reason, remittance unintended by the recipient 130, which may occur due to a misunderstanding that the remittance person 120 makes a mistake in the destination or an erroneous operation such as remittance of money in duplicate, can be suppressed.

  Thereby, the bank server 111 can suppress remittance that is not intended for both the recipient 130 and the remittance 120. Therefore, according to the present embodiment, remittance can be performed with peace of mind, and a sound remittance service can be provided.

  Further, according to the bank server 111 according to the present embodiment, since the authorization includes authentication performed by the recipient 130, the recipient 130 whose contact information is registered, and the recipient 130 who actually receives the remittance, Can be confirmed with the same accuracy (identity confirmation). Thereby, according to the bank server 111, it is possible not to perform remittance to a stranger, and remittance that the recipient 130 does not grasp, such as a transfer fraud, can be suppressed.

  Further, if the recipient terminal 131 in which the contact information is registered breaks down, the recipient 130 notifies the other recipient terminals 131 in which the contact information is not registered that the remittance is performed. Suppose that the sender 120 requests that he wants. In this case, the notification destination may be changed to another recipient terminal 131 by the operation of the sender 120.

  In this case, by including the authentication performed by the recipient 130 when accepting the remittance, the recipient 130 having the other recipient terminal 131 whose contact information is not registered and the recipient who actually receives the remittance. 130 can be confirmed (identity confirmation). Therefore, even when the recipient 130 uses another recipient terminal 131 whose contact address is not registered, remittance that the recipient 130 does not grasp, such as a transfer fraud, can be suppressed.

  Further, according to the bank server 111 according to the present embodiment, a predetermined character string (for example, “Sakura no Kai”) is used for a remittance request to the recipient 130, and a notification including the predetermined character string is performed. did. Accordingly, it is possible to indicate to the recipient 130 that the notification is related to remittance before the recipient 130 confirms the notification, for example, at the reception stage.

  Specifically, the bank server 111 can indicate that the e-mail has the contents related to remittance without opening the recipient 130 by using the character string in the subject of the e-mail. Therefore, the recipient 130 knows that it is not a junk mail or the like, and can open the electronic mail with peace of mind. Therefore, according to the bank server 111, it can suppress that a confirmation mail is not opened and consent is not obtained.

  In addition, the bank server 111 according to the present embodiment receives the remittance request received from the remittance person 120 when the approval is not accepted until a predetermined period (for example, 24 hours) elapses after the notification is made. I decided to cancel. As a result, the bank server 111 considers that the recipient 130 does not intend to receive the payment after a predetermined period of time, can cancel the remittance request, and can suppress remittance that the recipient 130 does not intend.

  Further, the bank server 111 according to the present embodiment cancels the remittance request received from the remittance person 120 when it is accepted that the remittance is not performed. As a result, the bank server 111 can prevent remittance unintended by the recipient 130.

  Further, since the remittance 120 has the intention of remittance, while the recipient 130 does not have the intention of receiving, the possibility of a crime such as a transfer fraud is suspected. For this reason, the designated account of the remittance can be alerted to the possibility of being used for crimes, and measures can be taken to prevent crimes.

  In addition, when the remittance request is canceled, the bank server 111 according to the present embodiment makes a notification indicating that to the remittance terminal 121. Thereby, the remittance person 120 can grasp that the remittance request was canceled. For this reason, the sender 120 can confirm the remittance with the recipient 130 and take a quick initial response to a crime such as a transfer fraud. Can be done.

  In addition, when the bank server 111 according to this embodiment accepts a remittance request, it notifies the agent's contact information that the remittance will be made, and executes the remittance by accepting the consent from the agent. It was possible. For this reason, the bank server 111 can regard the agent whose contact information is registered as the recipient 130 and execute remittance to the recipient 130 with the consent of the agent.

  Thereby, according to the bank server 111, even when the recipient 130 and the remittance 120 cannot be contacted directly, for example, when the recipient 130 is seriously ill or serious, the agent of the recipient 130 Since acceptance of remittance can be accepted and remittance can be made to the recipient 130, the convenience of the remittance support method according to the present embodiment can be improved.

  In addition, the bank server 111 according to the present embodiment uses at least one type of authentication accepted from the sender 120 among a plurality of types of authentication for the authentication used when the remittance is accepted. In this way, by selecting the authentication type on the remittance 120 side without selecting the authentication type on the recipient 130 side, for example, when a transfer fraud is assumed, the remittance 120 is selected. If the authentication and the authentication provided by the criminal are different, the criminal cannot succeed in the authentication. Thereby, since the safety | security of authentication can be strengthened, a transfer fraud can be suppressed.

  The remittance support method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation.

  The remittance support program is a hard disk, flexible disk, CD (Compact Disc) -ROM (Read Only Memory), MO (Magneto-Optical Disk), DVD (Digital Versatile Disk), USB (Universal Serial Bus reading memory, etc.). It is stored in a possible storage medium and executed by being read from the storage medium by a computer. Further, the remittance support program may be distributed via a network such as the Internet.

  As described above, the remittance support apparatus, the remittance support method, and the remittance support program according to the present invention are useful for a remittance support apparatus, a remittance support method, and a remittance support program that perform remittance. The present invention is suitable for a remittance support apparatus, a remittance support method, and a remittance support program that perform remittance to a registered recipient 130.

100 Remittance Support System 110 Bank 111 Bank Server 112 Sender Information Database (DB)
113 Recipient Information Database (DB)
114 representative information database (DB)
115 Transaction Information Database (DB)
120 Remittance 130 Recipient 121 Remittance Terminal 131 Recipient Terminal 140 Network 211, 221 CPU
212,222 Memory 213,225 Communication IF
223 Output device 224 Input device 210, 220 Bus 401 Notification unit 402 Reception unit 403 Remittance control unit

Claims (9)

A notification unit for notifying the recipient that the remittance is to be performed when a request for remittance is made to the recipient whose contact information has been registered in advance;
An accepting unit that accepts from the recipient the consent that the remittance is performed by the notification;
A remittance control unit that executes the remittance in response to the consent received by the accepting unit;
A remittance support apparatus characterized by comprising: The consent includes authentication of the recipient,
The remittance support apparatus according to claim 1. The notification unit performs the notification including the predetermined character string when the request including the input of the predetermined character string indicating the remittance is received from the sender.
The remittance support apparatus according to claim 1 or 2. The remittance control unit accepts that the acceptance is not accepted by the accepting unit until a predetermined period elapses after the notification is made, or that the remittance is not accepted by the accepting unit Cancel the request received from the sender,
The remittance support apparatus according to any one of claims 1 to 3. When the request is canceled by the remittance control unit, the notification unit performs notification to the remittance to that effect,
The remittance support apparatus according to claim 4. When the notification unit receives from the remittance a request to send the remittance to the recipient and a notification that the contact is registered in advance and to notify the recipient's agent, The notice to the agent,
The accepting unit accepts the consent from the agent by the notification,
The remittance control unit executes the remittance addressed to the recipient in response to the consent from the agent.
The remittance support apparatus according to any one of claims 1 to 5. The notification includes an acceptance result in which one or more types of authentication to be performed by the recipient from a plurality of types of authentication are accepted from the sender.
The authentication is the type of authentication indicated by the acceptance result.
The remittance support apparatus according to claim 2, wherein: When a request for remittance is made to a recipient whose contact information has been registered in advance, the recipient is notified that the remittance will be performed.
Acceptance from the recipient that the remittance will be made by the notification,
Execute the remittance according to the accepted acceptance,
A remittance support method, characterized in that a computer executes processing. When a request for remittance is made to a recipient whose contact information has been registered in advance, the recipient is notified that the remittance will be performed.
Acceptance from the recipient that the remittance will be made by the notification,
Execute the remittance according to the accepted acceptance,
A remittance support program that causes a computer to execute processing.

Images