Information processing device, information processing method, and program

Abstract

The goal is to achieve both the prevention of fraudulent use of credit cards and the reduction of the costs associated with prevention. [Solution] An information processing device comprising: an acquisition unit that acquires fraudulent credit payment information, which is determined to be fraudulent, and cost information, which is related to the costs incurred due to performing predetermined identity authentication at the time of execution of the credit payment, from among the credit payment information transmitted when a user makes a credit payment using a credit card at a credit card merchant; and an identification unit that identifies the identity authentication execution conditions for the merchant, regarding whether or not to perform the predetermined identity authentication, based on the fraudulent credit payment information and the cost information.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, and a program.

Background Art

[0002] Conventionally, techniques for preventing unauthorized use of credit cards by malicious third parties have been known. For example, Patent Document 1 discloses a technique in which a credit company approves a credit card payment only for purchases that match the applied content by prior application of a credit card member. (See Patent Document 1). <​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​One aspect of the present invention is an information processing device comprising: an acquisition unit that acquires, from credit payment information transmitted in response to a user making a credit payment using a credit card at a credit card merchant, fraudulent credit payment information in which the credit payment is determined to be fraudulent, and cost information relating to the costs incurred due to performing a predetermined identity authentication at the time of the credit payment; and an identification unit that identifies the identity authentication execution conditions for the merchant, regarding whether or not to perform the predetermined identity authentication, based on the fraudulent credit payment information and the cost information. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to achieve both the prevention of fraudulent use of credit cards and the suppression of the costs associated with such prevention. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows an example of a configuration for implementing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payments. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payments. [Figure 4] This is a configuration diagram of the payment server 100 according to the embodiment. [Figure 5] This figure shows an example of the contents of user information 172. [Figure 6] This figure shows an example of the contents of merchant / store information 176. [Figure 7] This figure shows an example of credit card payment information 178. [Figure 8] This diagram shows an example of the functional configuration of the authorization server 300. [Figure 9] This figure shows an example of SMS authentication performed by the fraud detection function 1 of the authorization server 300. [Figure 10]This sequence diagram shows an example of the flow of an online credit payment service executed through the cooperation of a user terminal device 10, a payment server 100, a merchant shopping server 200, and an authorization server 300. [Figure 11] This diagram shows an example of the contents of fraudulent credit card payment information 180. [Figure 12] This figure shows an example of the contents of cost information 182. [Figure 13] This diagram shows an example of the contents of Fraud / Cost Response Information 184. [Figure 14] This diagram illustrates the process of identifying the SMS authentication execution conditions, which is performed by the specific unit 154. [Figure 15] This flowchart shows an example of the processing flow executed by the information processing unit 150. [Figure 16] This figure shows an example of the configuration of a machine learning model related to a modified example. [Modes for carrying out the invention]

[0009] The following describes embodiments of the information processing apparatus, information processing method, and program of the present invention with reference to the drawings. Various devices, such as the "server" mentioned below, which provide services to users or perform internal analysis, may be implemented by a distributed group of devices, and the operators of each device may be different. Furthermore, the owner of the hardware of the devices (the provider of the cloud server) and the operator that actually operates them 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 will be referred to as the payment app. The electronic payment service is a service that supports payment for 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 e-commerce. A virtual store may include one provided by an entity different from the operator of the electronic payment service. In that case, when settling a purchase at a virtual store, the user may be directed to the interface screen of the electronic payment service. In the electronic payment service, a store is treated as belonging to, for example, a merchant (brand), and processing such as payment when a purchase is made at a store is mainly carried out between the user and the merchant. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [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 centering around the payment server 100. The electronic payment system for realizing 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, a franchise shopping server 200, and an authorization server 300. These devices communicate with each other via, for example, 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. Some or all of the functional configurations included in the electronic payment system may be distributed among a plurality of devices in any form, or may be integrated into any device.

[0011] The electronic payment system or the payment server 100 is an example of an "information processing device". Some of the functional configurations of the payment server 100 may be included in the authorization server 300 described later. In this case, the combined functional configuration of the payment server 100 and the authorization server 300 is an example of an "information processing device". All of the functional configurations 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". Further, among the payment server 100, the information processing unit 150 described later may be separated from the payment server 100 and mounted on an independent server device. In this case, the information processing unit 150 is an example of an "information processing device".

[0012] [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 reception function, and a program execution function. In the following description, the configurations for realizing these functions are respectively referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, the payment app 20 is executed by a processor such as a CPU, so as to operate in cooperation with the payment server 100 to provide an electronic payment service to the user. The payment app 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, etc. Further, in the user terminal device 10, the browser app 22 is executed by a processor such as a CPU, so as to access the franchise shopping server 200 and provide, for example, an online shopping service to the user.

[0013] [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. Note that the store code image 60 may be displayed by a display placed in the store (which may be a display of a terminal device such as a smartphone).

[0014] [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, tablet, personal computer, etc. The affiliated store interface 72 operates on the second store terminal device 70. The affiliated store interface 72 may be an affiliated store application or a browser. The affiliated store interface 72 accepts coupon settings etc. from the affiliated store operator and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image by running the affiliated store application, and reading a code image displayed by the user terminal device 10. Although not explained in Figure 1, affiliated stores may also be equipped with a card store terminal device that processes payments for physical credit cards presented to users. In that case, when a credit card payment is executed, the card store terminal device transmits credit card payment information related to the payment to the authorization server 300.

[0015] [Merchant Shopping Server] The merchant shopping server 200 is, for example, an online shopping service provided on a website by a credit card merchant. When the merchant shopping server 200 receives an access request from the browser application 22 installed on the user terminal device 10, it provides the browser application 22 with a service screen for the user to perform online shopping. The merchant shopping server 200 provides a credit payment service (online credit payment service) for settling for goods or services on the online shopping site. When a credit payment is executed on the online shopping site, the merchant shopping server 200 transmits the credit payment information related to that payment to the authorization server 300.

[0016] [Authorization Server] The authorization server 300 is, for example, a server device managed by the merchant's contracting company. The authorization server 300 performs authentication to determine whether or not to authorize a credit payment based on the credit payment information provided by the merchant shopping server 200. If the authorization server 300 authenticates that it will authorize the credit payment, 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.

[0017] [Payment Server] The payment server 100 is, for example, a server device of a credit card issuer. The payment server 100 confirms and executes the credit card payment based on the credit card payment information authenticated as legitimate by the authorization server 300. More specifically, when a predetermined date arrives, the payment server 100 deducts the payment amount indicated by the credit card payment information from the bank account linked to the user's credit card, and deposits the amount minus the payment fee into the merchant's bank account.

[0018] The payment server 100 further implements 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 a merchant server, in which case payment information is transmitted from the POS device to the payment server 100 via the merchant server. In the following description, these will not be specifically distinguished, and it will be assumed that payment information is transmitted from the first store terminal device 50.

[0019] Figures 2 and 3 are sequence diagrams illustrating the general flow of electronic payments. There may be two patterns for electronic payments: Pattern 1 and Pattern 2.

[0020] In the case of Pattern 1 shown in Figure 2 (hereinafter referred to as User Scan), the user terminal device 10, with the payment application 20 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 contains information about the store URL (Uniform Resource Locator). This store URL is an electronic payment service domain to which information that can identify the store has been added, and is associated with the merchant ID and store ID, etc., at the payment server 100 (described later). The payment application 20 sends the first payment information, including the store URL and account ID, to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen where the merchant name and store name are displayed (S5). The user terminal device 10 then generates second payment information, including at least the payment amount, and sends 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 sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 60 is displayed on a display placed in the store, the store code image 60 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0021] In the case of Pattern 2 shown in Figure 3 (hereinafter referred to as Store Scan), when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (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 barcode that was generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the first store terminal device 50 (presents it), and the first store terminal device 50 decodes the code image using its 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, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is obtained in advance by barcode scanning or manual input. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs the electronic payment (S17). The payment server 100 then sends a payment completion notification to the payment app 20 (S18), and the payment app 20 displays a payment completion screen (S19).

[0022] Furthermore, electronic payment may be performed using only one of the above patterns. Also, the "account ID" explained in Figure 2 may be other information that can be used as user identification information (for example, a phone number). In addition, the issuance of a one-time code may be omitted during store scanning, and the payment app 20 may display a code image generated based on the user's account ID. In that case, the payment server 100 will identify the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0023] [Payment Server Functional Configuration] Figure 4 is a diagram of the configuration of the payment server 100. The payment server 100 includes, for example, a communication unit 110, a content provision unit 120, a payment processing unit 130, an information management unit 140, an information processing unit 150, and a storage unit 170. Components other than the communication unit 110 and the storage unit 170 are realized, for example, by 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 LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), GPU (Graphics Processing Unit), and SOC (System On Chip), or by the cooperation of software and hardware. The program may be stored in advance on a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored on a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed on the storage device when the storage medium is inserted into the drive device.

[0024] The storage unit 170 can be an HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also be a NAS (Network Attached Storage) device that the payment server 100 can access via the network. The storage unit 170 stores information such as user information 172, content information 174, merchant / store 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.

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

[0026] The content provider unit 120, for example, has the functionality of a web server and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The content provider unit 120 reads 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 from the user while the content is being played by the payment application 20 and transmits the aforementioned payment information to the payment server 100. The above content may also be generated by the payment application 20. In this case, the content provider unit 120 provides the payment application 20 with the information necessary for generating the content.

[0027] The payment processing unit 130 performs payment processing based on 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.

[0028] Figure 5 shows an example of the contents of User Information 172. User Information 172 is an example of user registration information. User Information 172 includes, for example, user URL, account ID, telephone number, password, as well as information such as email address, user ID, name, address, date of birth, registration date, charge balance, credit payment settings, credit payment limit, credit payment amount, available credit payment amount, payment method settings, bank account, credit card number, charge history information, and payment history information. The user URL is used for money transfer processing between users. When registering for a new electronic payment service, registration of a telephone number and password is mandatory. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can set at will (or does not have to set). Similarly, the email address and name, address, and date of birth are also information that the user can set at will (or does not have to set). The registration date is the date the user registered for the electronic payment service (the date the account was created). Hereafter, the user instance (electronic payment account) to which this information is associated will be referred to as an account.

[0029] The charge balance is information indicating the balance of electronic money set by the user by sending money to their account in advance. Methods of sending money include sending from an ATM (Automatic Teller Machine) of a designated provider (bank) and sending from a registered bank account. The credit payment setting indicates whether or not the user has completed the settings to enable electronic payments using credit card payments (credit card payments using code information) via the payment app 20, and is set to either "Completed" or "Not Completed". The credit payment limit is the monthly limit for available credit payments, the credit payment amount is the amount of credit payments already made in the current month, and the available credit payment amount is the amount of credit payments available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the diagram shows only one credit payment limit, in reality there are also daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be described later. The payment method setting indicates whether the user will make an electronic payment using the charge balance or a credit payment at that time. The bank account and credit card number information, respectively, refers to the bank account or credit card number (account number, card number) to which funds can be deposited into the electronic payment service. The charge history information is a record of when the user has previously sent money to the electronic payment service to increase the charge balance. The payment history information shows the details of each payment made by the user (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

[0030] Figure 6 shows an example of the contents of the merchant / store information 176. The merchant / store information 176 includes, for example, a first table 176A in which the merchant ID and store ID are associated with the store URL, a second table 176B in which the merchant name and sales amount (as described above) are associated with the merchant ID, and a third table 176C in which the store name is associated with the store ID. In addition to this information, the merchant / store information 176 may also include information such as the merchant or store category, the store's location, and payment patterns.

[0031] The Information Management Unit 140 acquires information provided by other server devices and terminal devices. Based on the information acquired from the user terminal device 10 and the second store terminal device 70, the Information Management Unit 140 manages user information 172 and merchant / store information 176. The Information Management Unit 140 performs operations such as adding, editing, and deleting new records for user information 172 and merchant / store information 176. The Information Management Unit 140 also manages information acquired from the authorization server 300. Information acquired from the authorization server 300 is managed, for example, as credit payment information 178.

[0032] [Electronic payment] When the payment processing unit 130 obtains payment information from the user terminal device 10 or the first store terminal device 50, it refers to the user information 172 to obtain the user's "payment method setting". For users 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, which is managed in association with the user ID, and increasing the value of the merchant's sales proceeds item. For example, the value of the merchant's sales proceeds item is not used as electronic money itself, but rather the amount corresponding to the value of the sales proceeds item is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service.

[0033] The payment processing unit 130 performs electronic payment as follows for users whose "settings information" is set to "credit payment (credit payment using code information)". Credit payment is a payment method that is carried out in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service. The operator of the electronic payment service acts as the donor and allows electronic payment that does not depend on the charge balance within the credit payment limit. In order to use the credit payment service, it may be required to obtain a credit card provided by the operator of the electronic payment service. The amount used by credit payment is settled in a lump sum for the month on the payment date of the following month, for example, by withdrawal from a bank account. In this case, the payment processing unit 130 performs a provisional settlement by adding the settlement amount to the amount used by credit payment and subtracting the same amount from the available credit payment limit. When the closing date arrives, it processes the payment for the current month to be withdrawn on the payment date of the following month as described above, or requests the operator of the credit card company to perform the said process. If the settlement amount exceeds the available credit payment limit at the time of provisional settlement, an error notification is sent back to the payment app 20.

[0034] When a user makes a credit card payment, the payment processing unit 130 transmits the credit card payment information related to the payment to the authorization server 300, and the authorization server 300 may perform authentication to determine whether or not to authorize the credit card payment corresponding to the credit card payment information. If the authorization server 300 authenticates that it authorizes the credit card payment, it notifies the payment server 100 of this fact, and the payment processing unit 130 may perform subsequent payment processing.

[0035] The information processing unit 150 performs various information processing. For example, based on the fraudulent credit payment information 180, cost information 182, and fraud / cost response information 184 stored in the storage unit 170, the information processing unit 150 determines the authentication execution conditions for each merchant, regarding whether or not the authorization server 300 will perform predetermined authentication when a credit payment is executed. The information processing unit 150 may automatically set the determined authentication execution conditions in the authorization server 300, or it may display the authentication execution conditions as suggested information 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, a specification unit 154, a display control unit 156, and a setting unit 158 ​​as functional units, but the details of each function will be described later.

[0036] [overview] Thus, in this embodiment, when a user makes an electronic payment using a credit card at a merchant, there are three patterns: (1) using the online credit payment service on the web screen provided by the merchant shopping server 200, (2) setting the payment method to "credit payment" and making a payment using the payment app 20, and (3) presenting a physical credit card at the merchant's physical store and making a payment using a credit card payment terminal. In any of these patterns, the credit payment information is transmitted to the authorization server 300, and if the transaction is authorized by the authorization server 300, the payment server 100 confirms and executes the credit payment (i.e., when a predetermined date arrives, the payment amount indicated by the credit payment information is deducted from the bank account linked to the user's credit card, and the amount minus the payment fee is deposited into the merchant's bank account).

[0037] Incidentally, in recent years, a user 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's identity when they make an online credit card payment by requiring them to enter a one-time password or a password they have set in advance. Credit card payments are only permitted if the authentication is successful. Generally, 3D Secure authentication is not performed for all credit card payments, but only for online credit card payments where the score calculated based on fraud detection rules exceeds a threshold.

[0038] When performing user authentication using a one-time password, the authorization server 300 sends an SMS (Short Message Service) notification containing the one-time password to the user terminal device 10 linked to the phone number registered when the credit card was created, and performs authentication by accepting the 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 issuing company (i.e., in this embodiment, the operator of the payment server 100). Therefore, if 3D Secure authentication is frequently performed for legitimate credit card payments that do not inherently require authentication, the credit card issuing company will incur an excessive cost for sending SMS notifications that it does not inherently need to bear. As a result, there have been cases where the prevention of fraudulent use of credit cards and the suppression of the costs incurred in preventing such fraud have not been achieved simultaneously. SMS authentication is an example of "prescribed user authentication" in the claims.

[0039] Against this backdrop, in this embodiment, fraudulent credit payment information 180 is prepared for credit payments that are subsequently found to be fraudulent from the credit payment information transmitted to the authorization server 300, and cost information 182 is prepared that records the cost of sending SMS notifications. Based on fraud / cost response information 184 which aggregates the fraudulent credit payment information 180 and the cost information 182, the information processing unit 150 determines the authentication execution conditions for each merchant regarding whether or not to perform SMS authentication when a credit payment is executed. In the following description, (1) the use of an online credit payment service is assumed, 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 fraud detection of (2) credit payments by the payment application 20 and (3) credit payments by presenting a physical credit card, as long as a telephone number for SMS notification is registered in advance.

[0040] [Credit card payment information] Figure 7 shows an example of credit payment information 178. Credit payment information 178 is the transaction details information for each transaction received by the authorization server 300 for all credit payments made using the online credit payment service. Here, "all credit payments" means credit payments made using credit cards issued by credit card issuing companies (i.e., in this embodiment, the operator of the payment server 100). Credit payment information 178 is, for example, a transaction ID associated with information such as the transaction date, merchant code, merchant name, merchant category, credit card number, and credit payment amount.

[0041] [Authorization Server] Figure 8 shows an example of the functional configuration of the authorization server 300. The authorization server 300 has, for example, a fraud detection function 1 (for SMS authentication) and a fraud detection function 2 (for permission / denial determination). For each transaction of the received credit payment information 178, the fraud detection function 1 calculates a score S=f1(p1,p2,···,pn The system calculates a score S, and if the calculated score S is equal to or greater than the threshold, it performs SMS authentication. Here, p k (k=1,···n) represents the set of parameters to be input into the fraud detection rule f1, and the parameter set p k This includes, for example, arbitrary information such as the credit card payment amount, merchant identification information (merchant name, merchant category, etc.), payment time information (transaction date, payment time slot, etc.), and access source information (IP address, location, etc.). If the fraud detection function 1 uses access source information, the merchant shopping server 200 will send the access source information to the authorization server 300 in addition to the credit card payment information.

[0042] Fraud detection function 1 performs SMS authentication if the score S is greater than or equal to a threshold, while if the score S is less than the threshold, it does not perform SMS authentication and passes the transaction to fraud detection function 2 (for permission / denial determination). The fraud determination rule f1 may be further simplified by setting the score S as the amount of the credit card payment. In this case, fraud detection function 1 performs SMS authentication if the amount of the credit card payment is greater than or equal to a predetermined amount, but does not perform SMS authentication if the amount of the credit card payment is less than the threshold.

[0043] Fraud detection function 2 (for permission / denial determination) determines whether to permit or deny each transaction of the received credit payment information 178 based on a predetermined fraud detection rule f2, which is different from fraud detection rule f1. For the sake of explanation, fraud detection function 1 and fraud detection function 2 are implemented on the same authorization server 300, but fraud detection function 2 may also be implemented on the payment server 100 (i.e., on the credit card issuing company side), or on a server of a different company from the operator of the authorization server 300 (for example, a security-related company).

[0044] If the fraud detection function 2 authorizes the credit card payment transaction, information indicating this authorization is sent to the payment server 100 along with the credit card payment information 178, and the payment processing unit 130 confirms and executes the credit card payment. On the other hand, if the fraud detection function 2 does not authorize the credit card payment transaction, the authorization server 300 sends information indicating that the credit card payment for that transaction is not authorized to the merchant shopping server 200, and the merchant shopping server 200 displays notification information indicating that the credit card payment has failed to the browser application 22.

[0045] Figure 9 shows an example of SMS authentication performed by the fraud detection function 1 of the authorization server 300. As an example, Figure 9 shows a scenario in which a user launches a browser application 22 on the user terminal device 10, accesses the e-commerce site (merchant shopping server 200) of a jewelry store that is a credit card merchant, and attempts to use the online credit payment service. As shown on the left side of Figure 9, the user selects the product they wish to purchase on the e-commerce site, selects credit card as the payment method, and enters necessary information such as the card number and security code. After entering the necessary information, when the user presses the payment button B1, the merchant shopping server 200 sends information such as the transaction date, merchant code, merchant name, merchant category, credit card number (and security code), and credit payment amount to the authorization server 300 as credit payment information corresponding to this transaction.

[0046] When the authorization server 300 receives the credit payment information 178, it assigns a transaction ID to it and stores it as credit payment information 178. Next, the authorization server 300 uses the fraud detection function 1 to determine whether there is a possibility of fraud in the transaction. More specifically, the authorization server 300 determines whether the score S calculated according to the fraud determination rule f1 is above a threshold, and if it determines that the score S is above the threshold, it sends an SMS notification containing a one-time password to the phone number of the user terminal device 10. At the same time, as shown on the right side of Figure 9, the authorization server 300 displays an authentication screen on the user terminal device 10 for entering the one-time password. When the user enters the one-time password notified by 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 the authorization server 300 determines that authentication by the fraud detection function 1 was successful if the entered one-time password and the notified one-time password match.

[0047] [Sequence Diagram] Figure 10 is a sequence diagram showing an example of the flow of an online credit payment service executed through the cooperation of a user terminal device 10, a payment server 100, a merchant shopping server 200, and an authorization server 300. As an example, Figure 10 shows the flow when a user uses the online credit payment service, authentication is completed after an SMS notification is sent, and the credit payment is finally executed.

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

[0049] When the authorization server 300 receives credit payment information, it adds a transaction ID to the received credit payment information and stores it as credit payment information 178 (S104). Next, the authorization server 300 uses the 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 associated with 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).

[0050] The authorization server 300 sends an SMS notification containing a one-time password to the notified phone number (S112). The user checks the one-time password in the SMS notification and enters it on the authentication screen displayed in the browser application 22 (S114). After the authorization server 300 confirms that the received one-time password matches the one-time password it sent, it then uses the fraud detection function 2 to determine whether or not to allow the credit card payment (S116). If the authorization server 300 determines that the credit card payment should be allowed, it sends the 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).

[0051] [Information about fraudulent credit card payments] In this way, the authorization server 300 stores all credit payment information transmitted from the merchant shopping server 200 as credit payment information 178 in the payment server 100. Subsequently, for example, a person in charge at the payment server 100 (credit card issuing company) examines the credit payment information 178, identifies transaction data that corresponds to fraudulent credit payments from the transaction data of the credit payment information 178, and stores it in the storage unit 170 as fraudulent credit payment information 180.

[0052] Fraudulent credit card payment information 180 is, for example, a transaction ID associated with information such as the transaction date, merchant code, merchant name, merchant category, credit card number, credit card payment amount, whether or not SMS authentication was performed, and whether or not the transaction was approved / denied. The presence or absence of SMS authentication indicates whether or not the fraud detection function 1 of the authorization server 300 performed SMS authentication for a credit card payment that was found to be fraudulent. In other words, if the presence or absence of SMS authentication indicates "yes," it means that although the credit card payment was ultimately found to be fraudulent, SMS authentication was performed for the credit card payment. On the other hand, if the presence or absence of SMS authentication indicates "no," it means that although the credit card payment was fraudulent, SMS authentication was not performed for the credit card payment.

[0053] Transaction permission / denial indicates whether the authorization server 300's fraud detection function 2 permitted or denied the transaction. If transaction permission / denial indicates "permitted," it means that the credit card payment was permitted despite being a fraudulent credit card payment. On the other hand, if transaction permission / denial indicates "denied," it means that the credit card payment was denied as a fraudulent credit card payment. In other words, fraudulent credit card payment information 180 is information that records transactions from credit card payment information 178 that were ultimately identified as fraudulent credit card payments, regardless of whether SMS authentication was performed or whether the transaction was permitted or denied.

[0054] [Cost Information] Figure 12 shows an example of the contents of cost information 182. Cost information 182 is, for example, information such as the notification date, transaction ID, and cost associated with the 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 ID to which the SMS notification was issued. The cost is information indicating the cost incurred as a result of sending the SMS notification. The information processing unit 150 can identify the merchant associated with the transaction ID and calculate the SMS sending cost for each merchant by aggregating the data over a predetermined period.

[0055] [Fraud / Cost Management Information] Figure 13 shows an example of the contents of the fraud / cost response information 184. The fraud / cost response information 184 is, for example, information such as the merchant code, merchant name, number of SMS authentications, SMS authentication cost, number of fraudulent transactions, and fraudulent amount. The information processing unit 150 can calculate the number of SMS authentications, SMS authentication cost, number of fraudulent transactions, and fraudulent amount for each merchant by aggregating the fraudulent credit payment information 180 and cost information 182 over a predetermined period.

[0056] For example, the information processing unit 150 can identify a merchant by referring to the fraudulent credit payment information 180 using the transaction ID of the cost information 182 as a key, and for the identified merchant, it can calculate the number of SMS authentications by counting the number of SMS notification IDs and calculate the SMS authentication cost by summing up the costs. Also, for example, the information processing unit 150 can calculate the number of fraudulent transactions by referring to the fraudulent credit payment information 180 and counting the number of merchant codes. Also, for example, the information processing unit 150 can calculate the amount of fraud by referring to the fraudulent credit payment information 180 and summing up the credit payment amounts.

[0057] [Identifying the conditions for executing SMS authentication] The identification unit 154 identifies, for each merchant, SMS authentication execution conditions (the thresholds mentioned above) that can achieve both the prevention of fraudulent use of credit cards and the suppression of the costs incurred as a result of such prevention, based on the fraud / cost response information 184. More specifically, the identification unit 154 identifies SMS authentication execution conditions such that the SMS authentication cost and the amount of fraudulent activity are approximately equal.

[0058] Figure 14 is a diagram illustrating the process of identifying the SMS authentication execution conditions performed by the identification unit 154. In Figure 14, (a) represents the process of identifying "○○ Jewelry" with merchant code "A001" in the fraud / cost response information 184 of Figure 13, (b) represents the process of identifying "×× Electric" with merchant code "A002" in the fraud / cost response information 184 of Figure 13, and (c) represents the process of identifying "△△ Stationery" with merchant code "A003" in the fraud / cost response information 184 of Figure 13.

[0059] First, regarding (a) "XX Jewelry," according to the fraud / cost response information 184 in Figure 13, the SMS authentication cost (100,000 yen) is less than the fraudulent amount (200,000 yen). This means that the security measures using SMS authentication are insufficient against the fraud that occurred. Therefore, the identification unit 154 expands the range of transactions to which SMS authentication is performed by reducing the threshold of the fraud judgment rule f1. More specifically, the identification unit 154 reduces the threshold of the fraud judgment rule f1 until the SMS authentication cost, which increases by expanding the scope of SMS authentication, is approximately equal to the fraudulent amount (or, for example, until the difference between the two falls within a predetermined range). Since all history information regarding the merchant's credit card payments is recorded as credit card payment information 178, such simulations are possible. If the score S is set as the size of the credit card payment amount, the identification unit 154 expands the range of transactions to which SMS authentication is performed by reducing the size of the credit card payment amount that serves as the threshold.

[0060] Next, regarding (b) "XX Electric," according to the fraud / cost response information 184 in Figure 13, the SMS authentication cost (100,000 yen) exceeds the fraud amount (20,000 yen). This means that the security measures by SMS authentication are sufficient against the fraud that occurred. Therefore, the identification unit 154 reduces the range of transactions to which SMS authentication is performed by increasing the threshold of the fraud judgment rule f1. More specifically, the identification unit 154 increases the threshold of the fraud judgment rule f1 until the SMS authentication cost, which decreases by reducing the scope of SMS authentication, is approximately equal to the fraud amount. If the score S is set as the size of the credit payment amount, the identification unit 154 reduces the range of transactions to which SMS authentication is performed by increasing the size of the credit payment amount that serves as the threshold.

[0061] Next, regarding (c) "△△ Stationery," according to the fraud / cost response information 184 in Figure 13, no fraud occurred, and the SMS authentication cost (2,000 yen) far exceeded the fraudulent amount (0 yen). This means that security measures using SMS authentication are unnecessary. Therefore, the identification unit 154, for example, sets the threshold of the fraud judgment rule f1 to infinity, thereby disabling SMS authentication. Alternatively, the identification unit 154 may also disabling SMS authentication when the fraudulent amount is small (below a predetermined value). In this way, by specifying the SMS authentication execution conditions for each merchant, taking into account the balance between the SMS authentication cost and the fraudulent amount, it is possible to prevent fraudulent use of credit cards and suppress the costs incurred in connection with prevention.

[0062] In the above explanation, the fraudulent amount is calculated from all fraudulent credit card payment information 180 regardless of the transaction permission / denial determination result by the fraud detection function 2. However, the present invention is not limited to such a configuration. For example, the fraudulent amount in the fraud / cost response information 184 may be calculated only from records in the fraudulent credit card payment information 180 where the transaction was permitted (i.e., records where fraud was overlooked and actual damage occurred). This is because no actual damage occurred for credit card payments that were denied by the fraud detection function 2. In that case, the fraudulent amount in the fraud / cost response information 184 will decrease, and the identification unit 154 will reduce the range of transactions for which SMS authentication is performed by increasing the threshold of the fraud determination rule f1. This makes it possible to prevent fraudulent use of credit cards while further suppressing the costs incurred in preventing such fraud.

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

[0064] The setting unit 158 ​​may automatically set the threshold identified by the identification unit 154 in the fraud detection function 1 of the authorization server 300. In this case, the setting unit 158 ​​may refer to the merchant category of the merchant for which the threshold was identified by the identification unit 154 and set the same threshold for other merchants belonging to the same merchant category. This is based on the inventors' finding that the number of fraudulent credit card transactions and the amount of fraud are generally related to the type of business and business model of the merchant.

[0065] [Process flow] Next, with reference to Figure 15, the flow of processing performed by the information processing unit 150 will be explained. Figure 15 is a flowchart showing an example of the flow of processing performed by the information processing unit 150.

[0066] 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 the SMS authentication execution conditions for each merchant 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 on the authorization server 300 (step S204). This completes the processing of this flowchart.

[0067] [Differentiation] In the above embodiment, the identification unit 154 determines the threshold for SMS authentication execution conditions by simulating different thresholds so that the SMS authentication cost of the credit card issuer and the amount of fraudulent activity due to credit card fraud are approximately equal. In this modified example, a machine learning model is trained to output a threshold for SMS authentication execution conditions, taking information on credit card fraud as input. The identification unit 154 uses this trained machine learning model to identify the threshold for the merchant whose threshold is to be identified.

[0068] Figure 16 shows an example of the configuration of a machine learning model related to a modified example. As shown in Figure 16, a machine learning model such as a deep neural network is trained to take as input information such as the number of SMS authentications, SMS authentication costs, number of fraudulent transactions, and fraudulent amounts included in the fraud / cost response information 184 shown in Figure 13, and to output a threshold calculated in advance by the identification method shown in Figure 14. The identification unit 154 identifies the threshold by inputting information such as the number of SMS authentications, SMS authentication costs, number of fraudulent transactions, and fraudulent amounts of the merchants for which the threshold is to be identified into the trained machine learning model.

[0069] In other embodiments, the input to the machine learning model may include, for example, merchant categories. In other embodiments, the input to the machine learning model may include some or all of the credit payment information 178, fraudulent credit payment information 180, and cost information 182 of the merchants targeted for threshold identification. In other embodiments, the fraudulent amount used in machine learning may be calculated only from the records of fraudulent credit payment information 180 for which the transaction was permitted by the fraud detection function 2 (i.e., records for which fraud was overlooked and actual damage occurred).

[0070] According to the embodiment described above, when a user makes a credit card payment at a credit card merchant, the system obtains credit card payment information that has been determined to be fraudulent, as well as cost information related to the costs incurred due to performing a predetermined identity verification at the time of credit card payment. Based on the fraudulent credit card payment information and cost information, the system identifies the identity verification execution conditions for the merchant, determining whether or not to perform the predetermined identity verification. This makes it possible to prevent fraudulent use of credit cards and to suppress the costs incurred in preventing such fraud.

[0071] Although embodiments for carrying out the present invention have been described above using examples, the present invention is not limited in any way to these embodiments, and various modifications and substitutions can be made without departing from the spirit of the present invention. [Explanation of symbols]

[0072] 10. User terminal device 20 Payment Apps 22 Browser apps 100 Payment Servers 120 Content Provision Department 130 Payment Processing Unit 140 Information Management Department 150 Information Processing Unit 200 Merchant Shopping Servers 300 authorization servers

Claims

1. An acquisition unit that acquires, from the credit payment information transmitted when a user makes a credit payment using a credit card at a credit card merchant, fraudulent credit payment information that has been determined to be fraudulent, and cost information related to the costs incurred due to the predetermined identity authentication performed when the credit payment was executed. The system includes an identification unit that identifies the conditions for performing the authentication process for the merchant, based on the fraudulent credit payment information and the cost information, regarding whether or not to perform the predetermined authentication process. Information processing device.

2. The aforementioned predetermined authentication is an SMS authentication method in which, at the time of execution of the credit payment, an SMS (Short Message Service) notification containing a one-time password is sent to the user terminal device of the user who has been registered in advance, and the user terminal device is asked to input the one-time password. The aforementioned cost is the transmission cost incurred by the credit card issuer as a result of sending the SMS notification. The information processing apparatus according to claim 1.

3. The system further includes a display control unit that causes the identified personal authentication execution conditions to be displayed on the terminal device of the credit card issuing company. The information processing apparatus according to claim 2.

4. The aforementioned SMS authentication is performed when the fraud detection score for the credit card payment is above a threshold. The identifying unit identifies the threshold at which the amount of fraudulent payment indicated by the fraudulent credit payment information and the transmission cost are approximately equal as the conditions for executing the identity authentication. The information processing apparatus according to claim 2.

5. The fraud detection score is the 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 apparatus according to claim 4.

6. The system further includes a setting unit that sets the identified user authentication execution conditions on the authentication server that performs the predetermined user authentication. The information processing apparatus according to claim 1.

7. The setting unit also sets the authentication execution conditions specified for the merchant for other merchants belonging to the same category as the merchant. The information processing apparatus according to claim 6.

8. Computers When a user makes a credit card payment at a credit card merchant, the following credit card payment information is obtained: fraudulent credit card payment information, which indicates that the credit card payment was determined to be fraudulent; and cost information, which concerns the costs incurred due to the prescribed authentication process performed at the time of the credit card payment. Based on the fraudulent credit card payment information and the cost information, the conditions for performing identity verification regarding whether or not to perform the prescribed identity verification for the merchant are identified. Information processing methods.

9. On the computer, In response to a credit card transaction at a credit card merchant, the system obtains credit card transaction information that is transmitted when a user makes a credit card payment using their credit card, including fraudulent credit card transaction information where the transaction is determined to be fraudulent, and cost information related to the costs incurred due to the prescribed authentication process performed at the time of the credit card transaction. Based on the fraudulent credit card payment information and the cost information, the conditions for performing identity verification regarding whether or not to perform the prescribed identity verification for the merchant are identified. program.

Images