JP7597979B1 - Information processing device, information processing method, and program - Google Patents

Abstract

[Problem] To prevent fraudulent use of credit cards while simultaneously reducing the costs associated with such prevention.
[Solution] An information processing device comprising: an acquisition unit that acquires fraudulent credit payment information, which is sent in response to a user making a credit payment using a credit card at a credit card affiliated store, where the credit payment is determined to be fraudulent, and cost information regarding the costs incurred as a result of performing a specified personal authentication when the credit payment is made; and an identification unit that identifies, based on the fraudulent credit payment information and the cost information, a personal authentication execution condition regarding whether or not to perform the specified personal authentication for the affiliated store.
[Selected Figure] Figure 1

Description

The present invention relates to an information processing device, an information processing method, and a program.

Conventionally, there are known technologies for preventing unauthorized use of credit cards by malicious third parties. For example, Patent Document 1 discloses a technology in which, upon advance application by a credit card member, the credit company approves credit card payments only for purchases that match the details of the application (see Patent Document 1).

JP 2005-107825 A

However, conventional technologies often focus on preventing fraudulent use of credit cards. As a result, it is sometimes difficult to prevent fraudulent use of credit cards while reducing the costs associated with such prevention.

The present invention has been made in consideration of these circumstances, and one of its objectives is to provide an information processing device, information processing method, and program that can prevent fraudulent use of credit cards while reducing the costs associated with such prevention.

One aspect of the present invention is an information processing device that includes an acquisition unit that acquires fraudulent credit payment information, which is sent in response to a credit payment made by a user at a credit card affiliated store using a credit card, and that acquires fraudulent credit payment information, which is determined to be fraudulent when the credit payment is made, and cost information, which is related to costs incurred as a result of performing a specific personal authentication when the credit payment is made; and an identification unit that identifies a personal authentication execution condition, which is related to whether or not to perform the specific personal authentication for the affiliated store, based on the fraudulent credit payment information and the cost information.

According to one aspect of the present invention, it is possible to prevent fraudulent use of credit cards while reducing the costs associated with such prevention.

FIG. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. FIG. 1 is a sequence diagram (part 1) illustrating an example of a general flow of electronic payment. FIG. 2 is a sequence diagram (part 2) illustrating an example of a general flow of electronic payment. FIG. 2 is a configuration diagram of a payment server 100 according to the embodiment. FIG. 11 is a diagram showing an example of the contents of user information 172. FIG. 13 is a diagram showing an example of the contents of affiliated store/store information 176. FIG. 13 is a diagram showing an example of credit card payment information 178. A diagram showing an example of the functional configuration of the authorization server 300. A figure showing an example of SMS authentication performed by fraud detection function 1 of authorization server 300. A sequence diagram showing an example of the flow of an online credit payment service executed through cooperation between a user terminal device 10, a payment server 100, an affiliated store shopping server 200, and an authorization server 300. FIG. 13 is a diagram showing an example of the contents of fraudulent credit card payment information 180. FIG. 11 is a diagram showing an example of the contents of cost information 182. 13 is a diagram showing an example of the contents of fraud/cost correspondence information 184. FIG. 11 is a diagram for explaining a process of specifying an SMS authentication execution condition executed by a specifying unit 154. FIG. 10 is a flowchart showing an example of the flow of processing executed by an information processing unit 150. FIG. 13 is a diagram illustrating an example of a configuration of a machine learning model according to a modified example.

Hereinafter, with reference to the drawings, an embodiment of an information processing device, an information processing method, and a program of the present invention will be described. Various devices for providing services to users and performing internal analysis, such as the "server" that will appear below, may be realized by a group of distributed devices, and each device may be operated by a different business operator. In addition, the owner of the hardware of the device (the cloud server provider) and the business that actually operates it may also be different. The application program and the payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a payment application. An electronic payment service is a service that supports payments related to the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for electronic commerce. A virtual store may include one provided by an entity other than the operator of the electronic payment service. In that case, when making a payment for shopping at a virtual store, the user may be controlled to transition to an interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and processing such as payment when a purchase is made at a store is mainly performed between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.

[Electronic payment service]
FIG. 1 is a diagram showing an example of the configuration of an electronic payment system in which an electronic payment service is realized. The electronic payment service is realized mainly by a payment server 100. The electronic payment system that realizes the electronic payment service includes, for example, one or more user terminal devices 10, one or more first store terminal devices 50, one or more second store terminal devices 70, a payment server 100, an affiliated store shopping server 200, and an authorization server 300. These devices communicate with each other, for example, via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, a network of a payment system such as a credit card, and the like. A part or all of the functional configuration included in the electronic payment system may be distributed to multiple devices in any form, or may be integrated into any device.

The electronic payment system or the payment server 100 is an example of an "information processing device". A part of the functional configuration of the payment server 100 may be included in the authorization server 300 described later. In this case, the functional configuration of the payment server 100 and the authorization server 300 combined is an example of an "information processing device". The entire functional configuration of the payment server 100 may be included in the authorization server 300. In this case, the authorization server 300 is an example of an "information processing device". Furthermore, of the payment server 100, the information processing unit 150 described later may be separated from the payment server 100 and implemented in an independent server device. In this case, the information processing unit 150 is an example of an "information processing device".

[User terminal device]
The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input acceptance function, and a program execution function. In the following description, the components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), and the like. In the user terminal device 10, a processor such as a CPU executes a payment application 20, thereby operating to provide an electronic payment service to a user in cooperation with a payment server 100. The payment application 20 is installed in the user terminal device 10 from, for example, an application store, and controls a camera, a communication device, a touch panel, and the like. Furthermore, in the user terminal device 10, a processor such as a CPU executes a browser application 22, thereby accessing an affiliated store shopping server 200 and operating to provide, for example, an online shopping service to a user.

[First store terminal device]
The first store terminal device 50 is installed in a store, for example. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store, and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).

[Second store terminal device]
The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. The second store terminal device 70 operates an interface 72 for the affiliated store. The interface 72 for the affiliated store may be an application for the affiliated store or a browser. The interface 72 for the affiliated store accepts the setting of a coupon by the operator of the affiliated store and transmits it to the payment server 100. The second store terminal device 70, which is a smartphone, has a function of displaying a code image corresponding to a store code image and reading a code image displayed by the user terminal device 10 by executing an application for the affiliated store. Although not illustrated in FIG. 1, the affiliated store may further be provided with a card store terminal device that processes the payment of a physical credit card presented by a user. In that case, when a credit payment is executed, the card store terminal device transmits credit payment information related to the payment to the authorization server 300.

[Member store shopping server]
The affiliated store shopping server 200 is, for example, an online shopping service provided on a website by an affiliated store of a credit card. In response to receiving access from the browser application 22 installed in the user terminal device 10, the affiliated store shopping server 200 provides the browser application 22 with a service screen for the user to perform online shopping. The affiliated store shopping server 200 provides a credit payment service (online credit payment service) for paying for products or services on the online shopping site. When a credit payment is executed on the online shopping site, the affiliated store shopping server 200 transmits credit payment information related to the payment to the authorization server 300.

[Authorization Server]
The authorization server 300 is, for example, a server device managed by a contracted company of the affiliated store. The authorization server 300 performs authentication (authorization) to determine whether or not to permit the credit payment corresponding to the credit payment information based on the credit payment information provided by the affiliated store shopping server 200. If the authorization server 300 authenticates that the credit payment is permitted, it provides the credit payment information to the payment server 100. The authorization server 300 is an example of an "authentication server" in the claims.

[Payment server]
The payment server 100 is, for example, a server device of a credit card issuing company (issuer). The payment server 100 confirms and executes the credit card payment based on the credit card payment information authenticated as valid by the authorization server 300. More specifically, the payment server 100 subtracts the payment amount indicated by the credit card payment information from the bank account linked to the user's credit card upon the arrival of a specified due date, and deposits the amount remaining after deducting the payment fee from the payment amount into the bank account of the affiliated store.

The payment server 100 further realizes electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case the payment information is sent from the POS device to the payment server 100 via the affiliated store server. In the following explanation, no distinction is made between these two, and it is assumed that the payment information is sent from the first store terminal device 50.

Figures 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns for electronic payment: pattern 1 and pattern 2.

In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10 with the payment application 20 activated decodes the store code image 60 by the optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which information capable of identifying the store is added, and is associated with the affiliated store ID, store ID, etc. in the payment server 100 (described later). The payment application 20 transmits the first payment information including the store URL and the account ID to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and transmits it to the payment application 20 (S4). The user inputs the payment amount into the user terminal device 10 on the screen on which the affiliated store name and store name are displayed (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount and transmits it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then transmits a payment completion notice (information for displaying a payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include not only the store URL but also information on the payment amount. In this case, the procedure in which the user inputs the payment amount is omitted, and the first payment information is transmitted to the payment server 100 with the information on the payment amount included. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.

In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, when the payment app 20 is started, when a payment operation is performed in the payment app 20, when the automatic update timing (for example, every minute) occurs, and at other timings, the payment app 20 sends a request to issue a one-time code to the payment server 100 (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image such as a QR code or a barcode generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first store terminal device 50, and the first store terminal device 50 decodes the code image using an optical reading function and obtains the one-time code, etc. (S15). Then, the first store terminal device 50 generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode or manually entering it. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). The payment server 100 then sends a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

Note that electronic payment may be made using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuance of a one-time code may be omitted in the store scan, and the payment app 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[Functional configuration of payment server]
4 is a configuration diagram of the payment server 100. The payment server 100 includes, for example, a communication unit 110, a content providing unit 120, a payment processing unit 130, an information management unit 140, an information processing unit 150, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), a GPU (Graphics Processing Unit), or an SOC (System On Chip), or may be realized by cooperation between software and hardware. The program may be stored in advance in a storage device such as a hard disk drive (HDD) or flash memory (a storage device with a non-transient storage medium), or may be stored in a removable storage medium (non-transient storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.

The storage unit 170 is a HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access via a network. The storage unit 170 stores information such as user information 172, content information 174, affiliated store/shop information 176, credit card payment information 178, fraudulent credit card payment information 180, cost information 182, and fraud/cost response information 184. Details of each piece of information will be described later.

The communication unit 110 is a communication interface for connecting to the network NW. The communication unit 110 is, for example, a network interface card.

The content providing unit 120 has, for example, a web server function, and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The content providing unit 120 reads out the necessary content from the content information 174 as appropriate, and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs by the user while the content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100. The above content may be generated by the payment application 20. In this case, the content providing unit 120 provides the payment application 20 with the information necessary for generating the content.

The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.

5 is a diagram showing an example of the contents of the user information 172. The user information 172 is an example of the registration information of a user. The user information 172 is, for example, a user URL, an account ID, a telephone number, a password, as well as information associated with an email address, a user ID, a name, an address, a date of birth, a registration date, a charge balance, a credit payment setting, a credit payment limit, a credit payment amount used, a credit payment available amount, a payment method setting, a bank account, a credit card number, a charge history information, and a payment history information. The user URL is used for a remittance process between users. When registering for the electronic payment service, it is necessary to register a telephone number and a password. The account ID is issued to the user by the payment server 100, and the user ID is an ID that can be set by the user at will (does not have to be set). The email address, and the name, address, and date of birth are also information that can be set by the user at will (does not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user instance (electronic payment account) to which this information is associated will be referred to as an account.

The charge balance is information indicating the balance of electronic money that is set by the user by transferring money to the account in advance. The means of transfer include transfer from an ATM (Automatic Teller Machine) of a designated company (bank) and transfer from a registered bank account. The credit payment setting is information indicating whether or not the setting for enabling electronic payment by credit payment using the payment application 20 (credit payment using code information) has been completed, and is set to either "completed" or "not completed". The credit payment limit is the credit payment limit that can be used each month, the credit payment usage amount is the amount of credit payment already used in the month, and the credit payment available amount is the amount of credit payment that can be used in the month, which is calculated by subtracting the credit payment usage amount from the credit payment limit. In the figure, only one credit payment limit is shown, but in reality, there is also a daily upper limit, and the lower of these may be set as the credit payment limit. Further details of credit payment will be described later. The payment method setting is setting information indicating whether the user will perform electronic payment using the charge balance or credit payment at that time. The bank account and credit card number are information on a bank account or credit card number (account number, card number) that can be used to deposit funds into an electronic payment service. The charge history information is a history of the user transferring funds to the electronic payment service in advance to increase the charge balance. The payment history information is information that indicates the details of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

Figure 6 is a diagram showing an example of the contents of affiliated store/store information 176. Affiliated store/store information 176 includes, for example, a first table 176A in which affiliated store IDs and store IDs are associated with store URLs, a second table 176B in which affiliated store names and sales amounts (described above) are associated with affiliated store IDs, and a third table 176C in which store names are associated with store IDs. In addition to this information, affiliated store/store information 176 may also include information such as the affiliated store or store category, store location, and payment patterns.

The information management unit 140 acquires information provided by other server devices and terminal devices. The information management unit 140 manages user information 172 and affiliated store/store information 176 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds, edits, and deletes new records for the user information 172 and affiliated store/store information 176. The information management unit 140 manages information acquired from the authorization server 300. The information acquired from the authorization server 300 is managed, for example, as credit payment information 178.

[Electronic Payment]
When payment information is obtained from the user terminal device 10 or the first store terminal device 50, the payment processing unit 130 refers to the user information 172 to obtain the "payment method setting" of the user. For a user whose "payment method setting" is set to "charge balance", the payment processing unit 130 performs electronic payment as follows. For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales. The item value of the affiliated store's sales is not used as electronic money itself, for example, but an amount corresponding to the item value of the sales is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.

The payment processing unit 130 performs electronic payment for users whose "setting information" is set to "credit payment (credit payment using code information)" as follows. Credit payment is a payment method in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service, and the operator of the electronic payment service acts as the creditor and allows electronic payment that is not dependent on the charge balance within the credit payment limit. In order to receive the credit payment service, it may be necessary to obtain a credit card provided by the operator of the electronic payment service. The amount used in the credit payment is settled on the payment date of the following month, for example, by debiting from a bank account, for one month. In this case, the payment processing unit 130 performs provisional payment by adding the payment amount to the credit payment amount and subtracting the same amount from the available credit payment amount, and when the closing date comes, it performs processing to debit the payment for the current month on the payment date of the following month as described above, or requests the operator of the credit card company to perform such processing. In addition, if the payment amount exceeds the available credit payment amount at the time of provisional payment, an error notification is returned to the payment application 20.

When a user makes a credit payment, the payment processing unit 130 may transmit credit payment information relating to the payment to the authorization server 300, and the authorization server 300 may perform authentication to determine whether or not to permit the credit payment corresponding to the credit payment information. If the authorization server 300 authenticates that the credit payment is permitted, it may notify the payment server 100 of this, and the payment processing unit 130 may perform subsequent payment processing.

The information processing unit 150 executes various information processing. For example, based on the fraudulent credit payment information 180, cost information 182, and fraud/cost correspondence information 184 stored in the memory unit 170, the information processing unit 150 determines the identity authentication execution conditions regarding whether or not the authorization server 300 will perform a specified identity authentication when a credit payment is executed for each affiliated store. The information processing unit 150 may automatically set the determined identity authentication execution conditions in the authorization server 300, or may display them as suggested information regarding the identity authentication execution conditions on the terminal device of the administrator of the payment server 100 (the terminal device of the credit card company). To realize these functions, the information processing unit 150 includes an acquisition unit 152, an identification unit 154, a display control unit 156, and a setting unit 158 as functional units, and the details of each function will be described later.

[overview]
In this embodiment, when a user makes an electronic payment using a credit card at an affiliated store, there are three patterns: (1) using an online credit card payment service on a web screen provided by the affiliated store shopping server 200, (2) setting the payment method to "credit card payment" and making a payment using the payment application 20, and (3) presenting a physical credit card at the affiliated store's actual store and making a payment using a terminal device for credit card payments. In any of these patterns, the credit card payment information is sent to the authorization server 300, and if the transaction is permitted by the authorization server 300, the payment server 100 confirms and executes the credit card payment (i.e., when a specified due date arrives, the payment amount indicated by the credit card payment information is subtracted from the bank account linked to the user's credit card, and the amount of the payment less the payment fee is deposited in the affiliated store's bank account).

In recent years, an identity authentication service called 3D Secure has been developed and deployed to make credit card payments on e-commerce sites and web services more secure. More specifically, 3D Secure authenticates the user when making an online credit card payment by having the user enter a one-time password or a password that the user has set in advance, and allows the credit card payment only if identity authentication is successful. 3D Secure authentication is generally not performed for all credit card payments, but only for online credit card payments for which the score calculated based on fraud determination rules is equal to or exceeds a threshold value.

When performing identity authentication using a one-time password, the authorization server 300 performs authentication by sending an SMS (Short Message Service) notification containing the one-time password to the user terminal device 10 linked to the telephone number registered when the credit card was created, and accepting input of the one-time password from the user terminal device 10 (SMS authentication). In this case, the cost of sending the SMS notification is borne by the credit card issuer (i.e., in the case of this embodiment, the operator of the payment server 100). Therefore, if 3D secure authentication is frequently performed for legitimate credit payments that do not require authentication, the credit card issuer will bear excessive costs for sending SMS notifications that it should not bear. As a result, there have been cases where prevention of fraudulent use of credit cards and reduction of costs associated with prevention have not been achieved at the same time. SMS authentication is an example of "predetermined identity authentication" in the scope of the claims.

In light of this situation, in this embodiment, fraudulent credit payment information 180 is prepared for credit payments that are subsequently found to be fraudulent credit payments from among the credit payment information sent to the authorization server 300, and cost information 182 is prepared that records the transmission cost of the SMS notification. The information processing unit 150 determines the identity authentication execution conditions regarding whether or not to perform SMS authentication when a credit payment is executed for each affiliated store, based on fraud/cost correspondence information 184 that aggregates the fraudulent credit payment information 180 and the cost information 182. Note that the following description assumes the use of (1) an online credit payment service, but the present invention is not limited to such a configuration, and the functions of the present invention described below can also be applied to (2) credit payments by the payment app 20 and (3) fraud detection of credit payments by presentation of a physical credit card, as long as a phone number for SMS notification is registered in advance.

[Credit card payment information]
7 is a diagram showing an example of the credit payment information 178. The credit payment information 178 is detailed information of each transaction received by the authorization server 300 for all credit payments using the online credit payment service. Here, all credit payments mean credit payments using credit cards issued by credit card issuers (i.e., in this embodiment, the operator of the payment server 100). The credit payment information 178 is, for example, a transaction ID associated with information such as a transaction date, an affiliated store code, an affiliated store name, an affiliated store category, a credit card number, and a credit payment amount.

[Authorization Server]
8 is a diagram showing an example of the functional configuration of the authorization server 300. The authorization server 300 has, as its functional parts, for example, a fraud detection function 1 (for SMS authentication) and a fraud detection function 2 (for permission/non-permission determination). The fraud detection function 1 calculates a score S=f ₁ (p ₁ , p ₂ , ..., p _n ) for each transaction of the accepted credit payment information 178 based on a predetermined fraud determination rule f ₁ , and performs SMS authentication when the calculated score S is equal to or greater than a threshold. Here, p _k (k=1, ...n) represents a parameter group to be input to the fraud determination rule f ₁ , and the parameter group p _k includes any information such as, for example, a credit payment amount, affiliated store identification information (affiliated store name, affiliated store category, etc.), payment time information (transaction date, payment time zone, etc.), and access source information (IP address, location, etc.). When the fraud detection function 1 uses the access source information, the affiliated store shopping server 200 will transmit the access source information to the authorization server 300 in addition to the credit payment information.

Fraud detection function 1 performs SMS authentication when score S is equal to or greater than a threshold, but passes the transaction to fraud detection function 2 (for determining whether to permit/deny) without performing SMS authentication when score S is less than the threshold. Fraud determination rule _f1 may be further simplified to set score S as the amount of credit card payment, in which case fraud detection function 1 performs SMS authentication when the amount of credit card payment is a predetermined amount or greater, but does not need to perform SMS authentication when the amount of credit card payment is less than the threshold.

The fraud detection function 2 (for permission/non-permission determination) determines whether or not to permit each transaction of the accepted credit payment information 178 based on a predetermined fraud determination rule _f2 different from the fraud determination rule _f1 . For convenience of explanation, the fraud detection function 1 and the fraud detection function 2 are implemented in the same authorization server 300, but the fraud detection function 2 may be implemented on the payment server 100 (i.e., the credit card issuing company side) or on a server of another company (e.g., a security-related company) different from the operating company of the authorization server 300.

If the credit payment transaction is permitted by fraud detection function 2, information indicating the permission is sent to payment server 100 together with credit payment information 178, and payment processing unit 130 confirms and executes the credit payment. On the other hand, if the credit payment transaction is not permitted by fraud detection function 2, authorization server 300 sends information indicating that the credit payment is not permitted for that transaction to affiliated store shopping server 200, and affiliated store shopping server 200 displays notification information indicating that the credit payment has failed on browser app 22.

Figure 9 is a diagram showing an example of SMS authentication executed by the fraud detection function 1 of the authorization server 300. As an example, Figure 9 shows a scene in which a user launches a browser application 22 on the user terminal device 10, accesses the EC site (affiliated store shopping server 200) of a jewelry store that is an affiliated store of a credit card, and attempts to use an online credit payment service. As shown on the left side of Figure 9, the user selects a product he or she wishes to purchase on the EC site, selects credit card as the payment method, and enters necessary information such as a card number and a security code. After entering the necessary information, when the user presses the payment button B1, the affiliated store shopping server 200 transmits information such as the transaction date, affiliated store code, affiliated store name, affiliated store category, credit card number (and security code), and credit payment amount as credit payment information corresponding to this transaction to the authorization server 300.

When the authorization server 300 receives the credit payment information 178, it assigns a transaction ID and stores it as the credit payment information 178. Next, the authorization server 300 uses the fraud detection function 1 to determine whether or not there is a possibility of fraud in the transaction. More specifically, the authorization server 300 determines whether or not the score S calculated according to the fraud determination rule _f1 is equal to or greater than a threshold, and if it determines that the score S is equal to or greater than the threshold, it sends an SMS notification containing a one-time password to the telephone number of the user terminal device 10. At the same time, as shown in the right part of FIG. 9, the authorization server 300 causes the user terminal device 10 to display an authentication screen for inputting a one-time password. When the user enters the one-time password notified via SMS into the authentication screen and presses the authentication button B2, the user terminal device 10 sends the entered one-time password to the authorization server 300, and if the entered one-time password matches the notified one-time password, the authorization server 300 determines that authentication using the fraud detection function 1 has been successful.

[Sequence diagram]
Fig. 10 is a sequence diagram showing an example of the flow of an online credit payment service executed by cooperation between the user terminal device 10, the payment server 100, the affiliated store shopping server 200, and the authorization server 300. Fig. 10 shows, as an example, the flow when a user uses the online credit payment service, authentication is completed after an SMS notification is sent, and credit payment is finally executed.

First, the user operates the browser application 22 on the user terminal device 10 to access the affiliated store shopping server 200 and use the online credit payment service (S100). Next, the affiliated store shopping server 200 transmits information regarding the transaction, such as the transaction date, affiliated store name, affiliated store code, affiliated store category, credit card number (and security code), and credit payment amount, as credit payment information to the authorization server 300 and requests authorization (S102).

When the authorization server 300 receives the credit payment information, it assigns a transaction ID to the received credit payment information and stores it as credit payment information 178 (S104). Next, the authorization server 300 uses fraud detection function 1 to determine whether SMS authentication is required for the transaction (S106). If the authorization server 300 determines that SMS authentication is required, it queries the payment server 100 for the telephone number linked to the credit card number included in the credit payment information 178 (S108). In response, the payment server 100 refers to the user information 172 to identify the telephone number and notifies the authorization server 300 (S110).

The authorization server 300 sends an SMS notification containing the one-time password to the notified telephone number (S112). The user checks the one-time password contained in the SMS notification and enters it into the authentication screen displayed on the browser application 22 (S114). After the authorization server 300 confirms that the received one-time password matches the one-time password sent, it then uses the fraud detection function 2 to determine whether or not to permit the credit card payment (S116). If the authorization server 300 determines that the credit card payment is permitted, it sends credit card payment information to the payment server 100 (S118). The payment server 100 executes the credit card payment based on the received credit card payment information (S120).

[Fraudulent credit card payment information]
In this way, the authorization server 300 stores all the credit payment information transmitted from the affiliated store shopping server 200 in the payment server 100 as credit payment information 178. After that, for example, a person in charge of the payment server 100 (credit card issuing company) examines the credit payment information 178 and identifies transaction data corresponding to fraudulent credit payments among the transaction data of the credit payment information 178, and stores the same in the memory unit 170 as fraudulent credit payment information 180.

Fraudulent credit card payment information 180, for example, associates with a transaction ID information such as transaction date, affiliated store code, affiliated store name, affiliated store category, credit card number, credit card payment amount, whether SMS authentication was performed, and whether the transaction was approved or not. The presence or absence of SMS authentication is information indicating whether or not SMS authentication was performed by the fraud detection function 1 of the authorization server 300 for a credit card payment that was found to be a fraudulent credit card payment. In other words, if the presence or absence of SMS authentication indicates "Yes", this indicates that the credit card payment was ultimately found to be a fraudulent credit card payment, but SMS authentication was performed. On the other hand, if the presence or absence of SMS authentication indicates "No", this indicates that SMS authentication was not performed for the credit card payment, even though it was a fraudulent credit card payment.

The transaction permission/not permission is information indicating whether the fraud detection function 2 of the authorization server 300 has permitted or not permitted the transaction. When the transaction permission/not permission indicates "permitted," this indicates that the credit payment in question was permitted despite being a fraudulent credit payment. On the other hand, when the transaction permission/not permission indicates "not permitted," this indicates that the credit payment in question was not permitted as a fraudulent credit payment. In other words, the fraudulent credit payment information 180 is information that records the transactions that were ultimately identified as fraudulent credit payments from the credit payment information 178, regardless of whether SMS authentication was performed or whether the transaction was permitted or not.

[Cost Information]
FIG. 12 is a diagram showing an example of the contents of the cost information 182. The cost information 182 is, for example, information such as a notification date, a transaction ID, and a cost associated with an SMS notification ID. The SMS notification ID is generated each time the authorization server 300 sends an SMS notification, and is recorded in association with the transaction of the transaction ID for which the SMS notification was issued. The cost is information indicating the cost incurred by sending the SMS notification. The information processing unit 150 can calculate the SMS sending cost for each affiliated store by identifying the affiliated store associated with the transaction ID and tallying up the cost over a predetermined period of time.

[Fraud/Cost Response Information]
13 is a diagram showing an example of the contents of the fraud/cost correspondence information 184. The fraud/cost correspondence information 184 is information in which, for example, the affiliated store code, the affiliated store name, the number of SMS authentications, the SMS authentication cost, the number of fraudulent cases, the amount of fraud, and the like are associated with each other. The information processing unit 150 can calculate the number of SMS authentications, the SMS authentication cost, the number of fraudulent cases, and the amount of fraud for each affiliated store by aggregating the fraudulent credit card payment information 180 and the cost information 182 over a predetermined period.

For example, the information processing unit 150 can refer to the fraudulent credit payment information 180 using the transaction ID in the cost information 182 as a key to identify an affiliated store, and can calculate the number of SMS authentications by counting the number of SMS notification IDs for the identified affiliated store, and can calculate the SMS authentication cost by adding up the costs. Also, for example, the information processing unit 150 can refer to the fraudulent credit payment information 180 and count the number of affiliated store codes to calculate the number of fraudulent cases. Also, for example, the information processing unit 150 can refer to the fraudulent credit payment information 180 and add up the credit payment amounts to calculate the fraudulent amount.

[Specifying SMS authentication execution conditions]
The identifying unit 154 identifies, for each affiliated store, an SMS authentication execution condition (the threshold value described above) that can prevent fraudulent use of a credit card while suppressing the costs associated with the prevention, based on the fraud/cost correspondence information 184. More specifically, the identifying unit 154 identifies an SMS authentication execution condition that makes the SMS authentication cost in the fraud/cost correspondence information 184 approximately equal to the fraudulent amount.

Figure 14 is a diagram for explaining the identification process of the SMS authentication execution condition executed by the identification unit 154. In Figure 14, (a) represents the identification process executed for "XX Jewelry" with the affiliated store code "A001" in the fraud/cost correspondence information 184 of Figure 13, (b) represents the identification process executed for "XX Electric" with the affiliated store code "A002" in the fraud/cost correspondence information 184 of Figure 13, and (c) represents the identification process executed for "△△ Stationery" with the affiliated store code "A003" in the fraud/cost correspondence information 184 of Figure 13.

First, for (a) "XX Jewelry", according to the fraud/cost correspondence information 184 in FIG. 13, the SMS authentication cost (100,000 yen) is lower than the fraudulent amount (200,000 yen). This means that the security measures by SMS authentication are insufficient against the fraud that has occurred. Therefore, the identification unit 154 expands the range of transactions for which SMS authentication is performed by reducing the threshold value of the fraud determination rule f 1. More specifically, the identification unit 154 reduces the threshold value of the fraud determination rule f ₁ until the SMS authentication cost, which increases by expanding the target range of SMS authentication, and the fraudulent amount are approximately equal (or, for example, until the difference between the _two falls within a predetermined range). Since all the history information on the credit payment of the affiliated store is recorded as the credit payment information 178, such a simulation is possible. When the score S is set as the size of the credit payment amount, the identification unit 154 expands the range of transactions for which SMS authentication is performed by reducing the size of the credit payment amount, which is the threshold value.

Next, for (b) "XX Electric", according to the fraud/cost correspondence information 184 in FIG. 13, the SMS authentication cost (100,000 yen) exceeds the fraudulent amount (20,000 yen). This means that the security measures by SMS authentication are sufficient against the fraud that has occurred. Therefore, the identification unit 154 narrows the range of transactions for which SMS authentication is performed by increasing the threshold of the fraud determination rule _f1 . More specifically, the identification unit 154 increases the threshold of the fraud determination rule _f1 until the SMS authentication cost, which is reduced by narrowing the target range of SMS authentication, becomes approximately equal to the fraudulent amount. When the score S is set as the size of the credit card payment amount, the identification unit 154 narrows the range of transactions for which SMS authentication is performed by increasing the size of the credit card payment amount, which is the threshold.

Next, for (c) "△△ Stationery", according to the fraud/cost correspondence information 184 in FIG. 13, no fraud has occurred, and the SMS authentication cost (2,000 yen) is much higher than the fraudulent amount (0 yen). This means that security measures using SMS authentication are not necessary. Therefore, the specification unit 154 does not apply SMS authentication, for example, by setting the threshold of the fraud determination rule f ₁ to infinity. As another aspect, the specification unit 154 may not apply SMS authentication when the fraudulent amount is small (below a predetermined value). In this way, by specifying the SMS authentication execution condition for each affiliated store in consideration of the balance between the SMS authentication cost and the fraudulent amount, it is possible to prevent fraudulent use of credit cards and reduce the costs incurred by the prevention at the same time.

In the above description, the fraudulent amount is calculated from all fraudulent credit card payment information 180, regardless of the result of the fraud detection function 2's decision on whether the transaction is permitted or not. However, the present invention is not limited to such a configuration, and for example, the fraudulent amount in the fraud/cost correspondence information 184 may be calculated only from records in the fraudulent credit card payment information 180 in which the transaction is permitted (i.e., records in which the fraud was overlooked and actual damage occurred). This is because no actual damage has occurred for credit card payments in which the fraud detection function 2 has denied the transaction. In this case, the fraudulent amount in the fraud/cost correspondence information 184 is reduced, and the identification unit 154 increases the threshold value of the fraud determination rule f ₁ to reduce the range of transactions for which SMS authentication is performed. This makes it possible to prevent fraudulent use of credit cards while further reducing the costs incurred in preventing the fraudulent use.

The display control unit 156 may display the threshold value identified by the identification unit 154, for example, on a terminal device of the credit card issuer (i.e., in this embodiment, the operator of the payment server 100) or on a terminal device of the operator of the authorization server 300. In response to this, the operator can set the fraud detection function 1 of the authorization server 300 to the threshold value.

The setting unit 158 may automatically set the threshold value identified by the identification unit 154 in the fraud detection function 1 of the authorization server 300. At this time, the setting unit 158 may refer to the member store category of the member store whose threshold value was identified by the identification unit 154, and set the same threshold value for other member stores belonging to the same member store category. This is based on the inventors' knowledge that, in general, the number of occurrences of fraudulent credit card use and the amount of fraud are closely related to the type of industry and business model of the member store.

[Process flow]
Next, the flow of processing executed by the information processing unit 150 will be described with reference to Fig. 15. Fig. 15 is a flow chart showing an example of the flow of processing executed by the information processing unit 150.

First, the acquisition unit 152 acquires fraudulent credit card payment information 180 and cost information 182 over a predetermined period (step S200). Next, the identification unit 154 identifies SMS authentication execution conditions for each affiliated store based on the acquired fraudulent credit card payment information 180 and cost information 182 (step S202). Next, the setting unit 158 sets the SMS authentication execution conditions identified by the identification unit 154 in the authorization server 300 (step S204). This ends the processing of this flowchart.

[Modification]
In the above embodiment, the identification unit 154 identifies the threshold as the SMS authentication execution condition by performing a simulation while changing the threshold so that the SMS authentication cost of the credit card issuer and the fraudulent amount due to fraudulent use of the credit card are approximately equal. In this modification, a machine learning model is trained so as to input information on fraudulent use of the credit card and output a threshold as the SMS authentication execution condition. The identification unit 154 uses the machine learning model trained in this way to identify the threshold of the affiliated store for which the threshold is to be identified.

FIG. 16 is a diagram showing an example of the configuration of a machine learning model according to a modified example. As shown in FIG. 16, a machine learning model such as a deep neural network is trained so as to input information such as the number of SMS authentications, the SMS authentication cost, the number of fraudulent cases, and the amount of fraud contained in the fraud/cost correspondence information 184 shown in FIG. 13, and output a threshold calculated in advance by the identification method shown in FIG. 14. The identification unit 154 identifies a threshold by inputting information such as the number of SMS authentications, the SMS authentication cost, the number of fraudulent cases, and the amount of fraud of the affiliated store to be identified as the threshold, to the trained machine learning model.

In another embodiment, the input to the machine learning model may include, for example, the affiliated store category. In another embodiment, the input to the machine learning model may include some or all of the affiliated store's credit payment information 178, fraudulent credit payment information 180, and cost information 182 for which the threshold is to be identified. In another embodiment, the fraudulent amount used in the machine learning may be calculated only from records of the fraudulent credit payment information 180 for which transactions were permitted by the fraud detection function 2 (i.e., records for which fraud was overlooked and actual damage occurred).

According to the embodiment described above, from the credit payment information sent in response to a credit payment made by a user at a credit card affiliated store using a credit card, fraudulent credit payment information in which the credit payment is determined to be fraudulent and cost information regarding the costs incurred by performing a specified personal authentication when the credit payment is made are obtained, and based on the fraudulent credit payment information and the cost information, a personal authentication execution condition regarding whether or not to perform the specified personal authentication is identified for the affiliated store. This makes it possible to prevent fraudulent use of credit cards while reducing the costs incurred by preventing fraud.

The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made without departing from the spirit of the present invention.

10 User terminal device 20 Payment application 22 Browser application 100 Payment server 120 Content provider 130 Payment processor 140 Information manager 150 Information processor 200 Member store shopping server 300 Authorization server

Claims (9)

an acquisition unit that acquires fraudulent credit card payment information, which is determined to be fraudulent when a credit card user makes a credit card payment at a credit card affiliated store using the credit card, and cost information, which is related to costs incurred as a result of performing a predetermined identity authentication when the credit card payment is made;
and a determination unit that determines a personal authentication execution condition regarding whether or not to perform the predetermined personal authentication for the affiliated store based on the fraudulent credit payment information and the cost information.
Information processing device. the predetermined identity authentication is SMS authentication in which, when the credit card payment is executed, a Short Message Service (SMS) notification containing a one-time password is sent to a user terminal device of the user who has been registered in advance, and input of the one-time password is accepted from the user terminal device;
the cost being a transmission cost incurred by the issuer of the credit card by sending the SMS notification;
The information processing device according to claim 1 . and a display control unit that displays the identified personal authentication execution condition on a terminal device of the credit card issuer.
The information processing device according to claim 2 . The SMS authentication is performed when a fraud determination score of the credit card payment is equal to or greater than a threshold value,
the identification unit identifies the threshold value at which the fraudulent payment amount indicated by the fraudulent credit card payment information is approximately equal to the transmission cost as the identity authentication execution condition;
The information processing device according to claim 2 . the fraud determination score is an amount of the credit card payment, and the SMS authentication is performed when the amount of the credit card payment is equal to or greater than a predetermined amount;
The information processing device according to claim 4. The device further includes a setting unit that sets the specified personal authentication execution condition in an authentication server that performs the predetermined personal authentication.
The information processing device according to claim 1 . The setting unit sets the identity authentication execution condition specified for the affiliated store for other affiliated stores that belong to the same category as the affiliated store.
The information processing device according to claim 6. The computer
Among credit card payment information transmitted in response to a credit card payment made by a user at a credit card affiliated store using a credit card, fraudulent credit card payment information that is determined to be fraudulent for the credit card payment and cost information related to costs incurred as a result of performing a predetermined identity authentication when the credit card payment was made are obtained;
specifying an identity authentication execution condition for the affiliated store as to whether or not to perform the predetermined identity authentication based on the fraudulent credit payment information and the cost information;
Information processing methods. On the computer,
Among credit card payment information transmitted in response to a credit card payment made by a user at a credit card affiliated store using a credit card, fraudulent credit card payment information that indicates that the credit card payment is fraudulent and cost information regarding costs incurred as a result of performing a predetermined identity authentication when the credit card payment is made are acquired,
specifying, for the member store, a personal authentication execution condition regarding whether or not to perform the predetermined personal authentication based on the fraudulent credit payment information and the cost information;
program.

Images