Claims:CLAIMS
We claim:

1. A computer-implemented method, comprising:
accessing, by a server system, historical payment transaction data associated with fraudulent payment transactions from a transaction database, the fraudulent payment transactions performed by a plurality of payment instruments associated with cardholders at a plurality of merchants;
defining, by the server system, a base graph based, at least in part, on the historical payment transaction data, the base graph representing a computer-based graph representation of the plurality of payment instruments as first nodes and the plurality of merchants as second nodes and relationships between the first nodes and the second nodes as edges;
identifying, by the server system, common point of purchase (CPP) compromise merchants from the plurality of merchants by calculating CPP compromise scores associated with the plurality of merchants, the CPP compromise scores calculated by performing a plurality of iterations, wherein an iteration of the plurality of iterations comprises the following steps:
generating, by the server system, a sub-graph based, at least in part, on the base graph, the sub-graph representing a relationship graph of one or more payment instruments that are used at 'k' number of merchants;
determining, by the server system, blame scores assigned to a set of merchants involved in the sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in a previous iteration; and
calculating, by the server system, posterior fraud probabilities at current iteration associated with the set of merchants based, at least in part, on the blame scores and a CPP model; and
determining, by the server system, the CPP compromise scores associated with the plurality of merchants based, at least in part, on final posterior fraud probabilities of the plurality of merchants at final iteration of the plurality of iterations.

2. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, a plurality of graph features corresponding to each of the plurality of merchants based, at least in part, on the historical payment transaction data.

3. The computer-implemented method as claimed in claim 1, further comprising:
classifying, by the server system, a merchant of the plurality of merchants as a CPP compromised merchant based, at least in part, on a corresponding CPP compromise score of the merchant and a threshold value.

4. The computer-implemented method as claimed in claim 3, wherein a posterior fraud probability for the merchant at an iteration 'i' corresponds to a sum of number of fraudulent payment cards at the iteration 'i' and alpha (α) divided by sum of total number of payment cards at the iteration 'i' and beta (β), and wherein the alpha and beta are hyper-parameters.

5. The computer-implemented method as claimed in claim 4, wherein the alpha (α) corresponds to an average number of fraudulent payment instruments associated with the merchant of the plurality of merchants divided by an iteration number.

6. The computer-implemented method as claimed in claim 4, wherein the beta (β) corresponds to an average of a total number of payment instruments utilized at the merchant of the plurality of merchants.

7. The computer-implemented method as claimed in claim 1, wherein value of 'k' is in a range of 1 to 'n', and wherein 'n' represents a number of the plurality of merchants.

8. The computer-implemented method as claimed in claim 1, wherein the CPP model is based at least on Bayesian statistics method.

9. The computer-implemented method as claimed in claim 1, wherein the server system is a payment server associated with a payment network.

10. A server system configured to perform the computer-implemented method as claimed in claims 1-8.
, Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
ARTIFICIAL INTELLIGENCE BASED METHODS AND SYSTEMS FOR DETECTING COMMON POINTS OF PURCHASE COMPROMISED MERCHANTS

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

 
ARTIFICIAL INTELLIGENCE BASED METHODS AND SYSTEMS FOR DETECTING COMMON POINTS OF PURCHASE COMPROMISED MERCHANTS

TECHNICAL FIELD
[0001] The present disclosure relates to artificial intelligence processing systems and, more particularly to, electronic methods and complex processing systems for detecting common points of purchase compromised or breached merchants.

BACKGROUND
[0002] Over the last few years, there has been an increase in online fraudulent payment transactions. Many of these online fraudulent payment transactions may begin with a common point of purchase (CPP) compromise merchant. Generally, CPP is a physical or virtual location of a payment network that is compromised or attacked by fraudsters to steal sensitive information (e.g., payment card information). For example, the CPP may include an automated teller machine (ATM), a point-of-sale (POS) device, a payment website that collects or processes payment-related information, and so on. Conventionally, fraudsters used to install skimming devices in ATM machines or POS devices to steal payment card information from the payment cards of cardholders but nowadays, fraudsters use advanced techniques to steal payment card information without stealing the payment card of the cardholder. In general, a skimming device is a piece of equipment that fraudsters attach over card readers at ATMs, or POS devices to steal sensitive payment card information.
[0003] Along with the usage of CPP compromised merchants, the fraudsters may use other fraudulent attacks such as testing and fraud attack. Generally, in a testing attack, a fraudster may check the validity of a stolen payment card of a cardholder by performing a small amount of electronic payment transaction that is usually unnoticeable to the cardholder at a fixed terminal (e.g., ATM, POS device, etc.). In a fraud attack, the fraudster may use the information of the stolen payment card to make purchases of goods or services using bulk fraudulent payment cards.
[0004] Currently, large-scale CPP events have become endemic that involve the compromise of tens of millions of primary account numbers (PAN) of active payment accounts annually. In many cases, these compromised payment accounts are exposed in public places (e.g., internet, dark web) and not detected by law enforcement efforts.
[0005] In view of the above discussion, there exists a technological need for a method of analyzing large-scale transactional information for detecting common points of purchase (CPP) compromised merchants.

SUMMARY
[0006] Various embodiments of the present disclosure provide methods and systems for detecting common points of purchase compromised merchants.
[0007] In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing historical payment transaction data associated with fraudulent payment transactions from a transaction database. The fraudulent payment transactions are performed by a plurality of payment instruments associated with cardholders at a plurality of merchants. The computer-implemented method includes defining a base graph based, at least in part, on the historical payment transaction data. The base graph represents a computer-based graph representation of the plurality of payment instruments as first nodes and the plurality of merchants as second nodes and relationships between the first nodes and the second nodes as edges. The computer-implemented method includes identifying common point of purchase (CPP) compromise merchants from the plurality of merchants by calculating CPP compromise scores associated with the plurality of merchants. The CPP compromise scores are calculated by performing a plurality of iterations. During each iteration, the computer-implemented method includes generating a sub-graph based, at least in part, on the base graph. The sub-graph represents a relationship graph of one or more payment instruments that are used at 'k' number of merchants. In addition, during each iteration, the computer-implemented method includes determining blame scores assigned to a set of merchants involved in the sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in a previous iteration. During each iteration, the computer-implemented method includes calculating posterior fraud probabilities at a current iteration associated with the set of merchants based, at least in part, on the blame scores and a CPP model. The computer-implemented method further includes determining the CPP compromise scores associated with the plurality of merchants based, at least in part, on final posterior fraud probabilities of the plurality of merchants at the final iteration of the plurality of iterations.
[0008] Other aspects and example embodiments are provided in the drawings and the detailed description that follows.

BRIEF DESCRIPTION OF THE FIGURES
[0009] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0010] FIG. 1 illustrates an exemplary representation of an environment related to at least some embodiments of the present disclosure;
[0011] FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0012] FIGS. 3A-3D, collectively, represent example representations of a process of generating the plurality of sub-graphs from the base graph, in accordance with an embodiment of the present disclosure;
[0013] FIGS. 4A-4D, collectively, represent example representations of tables representing mathematical values for calculating the blame scores and posterior fraud probabilities without hyper-parameters, in accordance with an embodiment of the present disclosure;
[0014] FIGS. 5A-5D, collectively, represent example representations of tables representing mathematical values for calculating the blame scores and posterior fraud probabilities with hyper-parameters, in accordance with an embodiment of the present disclosure;
[0015] FIG. 6 represents an example representation of a table representing mathematical values for calculating cumulative alpha and cumulative beta based on hyper-parameters, in accordance with an embodiment of the present disclosure;
[0016] FIG. 7 represents a flow chart of a method for identifying CPP compromised merchants from the plurality of merchants, in accordance with an embodiment of the present disclosure;
[0017] FIG. 8 illustrates a flow diagram depicting a method for detecting CPP compromised merchants, in accordance with an embodiment of the present disclosure;
[0018] FIG. 9 is a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure; and
[0019] FIG. 10 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
[0020] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
[0021] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0022] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0023] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0024] The term "payment network", used herein, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as, Mastercard®.
[0025] The term "merchant", used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location, or a chain of business locations of the same entity.
[0026] The terms "cardholder", “user”, and “customer” are used interchangeably throughout the description and refer to a person who holds a credit or a debit card that will be used by a merchant to perform a payment transaction.
[0027] The term "payment account" used throughout the description refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, an e-wallet account, a checking account, and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by payment wallet service providers.
[0028] The term "payment card", used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility in order to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated with a payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
OVERVIEW
[0029] Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for detecting common point of purchase (CPP) compromised merchants. More specifically, embodiments of the present disclosure disclose a method for detecting common merchants that may be compromised by fraudsters to steal sensitive information (e.g., personal identification number (PIN) of payment card associated with the cardholder, payment account details such as name, type of account, etc.) from payment card of a cardholder.
[0030] As noted above, fraudsters may use CPP compromised merchants to steal sensitive information from a payment card associated with a payment account of a cardholder. More specifically, the fraudsters may use compromised automated teller machines (ATMs), point-of-sale (POS) devices, or fraudulent websites to steal sensitive information associated with the payment account of the cardholder. In an example, the fraudsters may use skimming devices to steal the payment card information from the payment card of the cardholder. In another example, the fraudsters may use advanced techniques to steal payment card information without stealing the payment card of the cardholder. The fraudsters may further use testing attacks and fraud attacks along with CPP-compromised merchants to steal payment card information associated with the payment account of the cardholder.
[0031] To overcome such problems or limitations, the present disclosure describes a server system that is configured to detect the CPP-compromised merchants (i.e., breached merchants). More specifically, the present disclosure describes a mathematical solution that runs various iterations to calculate posterior fraud probabilities for various merchants. Initially, the server system is configured to calculate posterior fraud probabilities for merchants that include payment cards transacted at only one merchant. Thereafter, the server system is configured to calculate posterior fraud probabilities for merchants that include payment cards transacted at two merchants, three merchants, and so on.
[0032] At least one of the technical problems addressed by the present disclosure includes the detection of CPP-compromised merchants with high precisions.
[0033] The server system includes at least a processor and memory. In one non-limiting example, the server system is a payment server. The server system is configured to access historical payment transaction data associated with fraudulent payment transactions from a transaction database. The fraudulent payment transactions may be performed by a plurality of payment instruments associated with cardholders at a plurality of merchants. In one example, the plurality of payment instruments may include payment cards (e.g., credit cards, debit cards, etc.), wallet service providers, payment accounts of the cardholders, etc. In one embodiment, the historical payment transaction data may include data associated with the fraudulent payment transactions over a period of time (e.g., 1 month, 6 months, 2 years, etc.).
[0034] In one example, the cardholders may perform electronic payment transactions at the plurality of merchants using the plurality of payment instruments. In an example, the cardholders may perform the electronic payment transactions at a point-of-sale (POS) device installed at a facility (e.g., institution, building, apartment, commercial space, etc.) associated with the merchant. In another example, the cardholders may perform the electronic payment transactions at an automated teller machine (ATM). In yet another example, the cardholders may perform the electronic payment transactions at a payment website (e.g., merchant website) associated with the merchant. In one embodiment, the server system is configured to generate a plurality of graph features corresponding to each of the plurality of merchants based, at least in part, on the historical payment transaction data.
[0035] The server system is configured to define a base graph based, at least in part, on the historical payment transaction data. In one embodiment, the base graph may be a bipartite graph, attributed heterogeneous graph, and the like. In addition, the base graph represents a computer-based graph representation of the plurality of payment instruments as first nodes and the plurality of merchants as second nodes. The relationships between the first nodes and the second nodes are further represented as edges. In one embodiment, there may be any number of the first nodes, the second nodes, and the edges to define a highly scalable base graph. In one embodiment, the base graph represents the fraudulent payment transactions performed by the plurality of payment instruments associated with the cardholders at the plurality of merchants. In one embodiment, the server system is configured to generate a plurality of feature vectors corresponding to each of the plurality of merchants based, at least in part, on the historical payment transaction data.
[0036] In one embodiment, the server system is configured to generate a plurality of sub-graphs from the base graph in a plurality of iterations. In one example, each sub-graph is created in each iteration of the plurality of iterations. The plurality of sub-graphs is generated by the server system for identifying common point of purchase (CPP) compromise merchants from the plurality of merchants by calculating CPP compromise scores associated with the plurality of merchants. The CPP compromise scores are calculated by performing the plurality of iterations.
[0037] During each iteration, the server system is configured to generate a sub-graph based, at least in part, on the base graph. The sub-graph represents a relationship graph of one or more payment instruments that are used at 'k' number of merchants. In one embodiment, the value of 'k' is in a range of 1 to 'n', where 'n' represents a number of the plurality of merchants. For example, in the first iteration, a first sub-graph represents a relationship graph of one or more payment instruments that are used at one merchant. In the second iteration, a second sub-graph represents a relationship graph of the one or more payment instruments that are used at two merchants. In the third iteration, a third sub-graph represents a relationship graph of the one or more payment instruments that are used at three merchants, and so on.
[0038] During each iteration, the server system is configured to determine blame scores assigned to a set of merchants involved in the sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in a previous iteration. For example, during the second iteration, the server system determines blames scores assigned to the set of merchants involved in the second sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in the first iteration. Similarly, the server system is configured to determine blames scores assigned to the set of merchants involved in any sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in the previous iteration.
[0039] During each iteration, the server system is configured to calculate posterior fraud probabilities at the current iteration associated with the set of merchants based, at least in part, on the blame scores and a CPP model. The server system is further configured to determine the CPP compromise scores associated with the plurality of merchants based, at least in part, on final posterior fraud probabilities of the plurality of merchants at the final iteration of the plurality of iterations. In one embodiment, the server system is configured to classify the plurality of merchants into the CPP compromise merchants if the final posterior fraud probabilities of the plurality of merchants are greater than a threshold.
[0040] In one embodiment, the final posterior fraud probability for each of the plurality of merchants corresponds to a sum of a number of fraudulent payment cards at iteration 'i' and alpha (α) divided by the sum of the total number of payment cards at iteration 'i' and beta (β), where alpha and beta are hyper-parameters. The alpha corresponds to an average number of fraudulent payment cards associated with each merchant of the plurality of merchants divided by iteration number. The beta corresponds to an average of a total number of payment cards utilized at each merchant of the plurality of merchants.
[0041] In one embodiment, the server system is configured to calculate cumulative alpha for the sub-graph for each of the plurality of iterations. The cumulative alpha corresponds to alpha for the first iteration and the cumulative alpha corresponds to a sum of the alpha for the sub-graph and the cumulative alpha of the previous sub-graph for remaining of the plurality of iterations. In one embodiment, the server system is configured to calculate cumulative beta for the sub-graph for each of the plurality of iterations. The cumulative beta corresponds to beta for the first iteration and the cumulative beta corresponds to a sum of the beta for the sub-graph and the cumulative beta of the previous sub-graph for remaining of the plurality of iterations.
[0042] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure performs a large-scale scanning of a plurality of merchants to detect common points of purchase (CPP) compromised merchants. The present disclosure provides a mathematical solution that runs various iterations to calculate posterior fraud probabilities for the plurality of merchants and based on final posterior fraud probabilities of the plurality of merchants calculated in the final iteration, the system detects or identifies the CPP compromised merchants. The present disclosure may also detect test merchants, bad merchants, and fraudulent attack merchants along with the CPP compromised merchants.
[0043] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 10.
[0044] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, utilizing a common point of purchase (CPP) model for identifying merchants associated with payment instruments that may be compromised, etc. The environment 100 generally includes a plurality of cardholders 102a, 102b, and 102n (collectively, represented as cardholders 102), a plurality of merchants (for the sake of clarity, a single merchant 104 is shown), a server system 106, a transaction database 108, an issuer server 112, an acquirer server 114, and a payment network 116 including a payment server 118, each coupled to, and in communication with (and/or with access to) a network 110. The network 110 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber-optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among the entities illustrated in FIG. 1, or any combination thereof.
[0045] Various entities in the environment 100 may connect to the network 110 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, or any combination thereof. For example, the network 110 may include multiple different networks, such as a private network made accessible by the network 110 to the server system 106, and a public network (e.g., the Internet).
[0046] In the illustrative embodiment, the cardholders 102 may be any individuals, representatives of a corporate entity, non-profit organizations, or any other persons. More specifically, the cardholders 102 may be any individual buyers and/or customers, or any other persons that are presenting a payment card during a payment transaction to a merchant representative or other seller or via an online interface associated with the merchant 104. Each of the cardholders 102 may have a payment instrument (e.g., a payment card) issued by an issuing bank (associated with the issuer server 112) and may be provided with the payment card with financial or other account information encoded onto the payment card.
[0047] In one example, the cardholders 102 purchase goods or services from the merchant 104 using payment instruments to pay the merchant 104. Examples of the merchant 104 may include any retail shop, restaurant, supermarket or establishment, government and/or private agencies, or any such place equipped with payment terminals, such as point-of-sale (POS) devices where customers visit for performing financial transactions in exchange for any goods and/or services or any transaction that requires financial transaction between the cardholder 102 and the merchant 104.
[0048] In some embodiments, the cardholders 102 are associated with the issuer server 112. In one embodiment, the issuer server 112 is associated with a financial institution normally called an "issuer bank" or "issuing bank" or simply "issuer", in which a cardholder (e.g., the cardholders 102) may have a payment account, (which also issues a payment card, such as a credit card or a debit card), and provides microfinance banking services (e.g., payment transaction using credit/debit cards) for processing electronic payment transactions, to the cardholders 102.
[0049] In some embodiments, the merchant (e.g., the merchant 104) is associated with the acquirer server 114. In one embodiment, the acquirer server 114 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0050] The server system 106 is configured to perform one or more of the operations described herein. In general, the server system 106 is configured to perform detection of CPP compromised merchants. The server system 106 is a separate part of the environment 100 and may operate apart from (but still in communication with, for example, via the network 110, the payment server 118, the acquirer server 114, and any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 106 may actually be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the acquirer server 114. In addition, the server system 106 should be understood to be embodied in at least one computing device in communication with the network 110, which may be specifically configured, via executable instructions, to perform as described herein, and/or embodied in at least one non-transitory computer-readable media.
[0051] In one embodiment, the server system 106 is the payment server 118. The server system 106 is configured to access historical payment transaction data associated with fraudulent payment transactions performed with a plurality of payment instruments (e.g., payment account, digital wallet, payment card, etc.) by the cardholders 102, from the transaction database 108. Based on the historical payment transaction data, the server system 106 defines a base graph (e.g., bipartite graph, attributed heterogeneous graph, etc.). The base graph shows the relationship (i.e., edges of the base graph) between the plurality of payment instruments (represented as first nodes) and the plurality of merchants 104 (represented as second nodes). The server system 106 is configured to run a plurality of iterations to identify a common point of purchase (CPP) compromised merchants from the plurality of merchants 104 by calculating CPP compromise scores associated with the plurality of merchants 104.
[0052] In one embodiment, the server system 106 is configured to generate a plurality of sub-graphs in the plurality of iterations. More specifically, during each iteration, the server system 106 generates a sub graph based, at least in part, on the base graph. The sub-graph represents a relationship graph of one or more payment instruments that are used at 'k' number of merchants. In addition, value of 'k' is in a range of 1 to n, where n is a natural number that represents a number of the plurality of merchants 104. The server system 106 is configured to determine blame scores assigned to a set of merchants involved in the sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in a previous iteration. Based on the blame scores and a CPP model, the server system 106 is further configured to calculate posterior fraud probabilities at the current iteration associated with the set of merchants. At the final iteration of the plurality of iterations, the server system 106 utilizes final posterior probabilities of the plurality of merchants 104 to determine the CPP compromise scores associated with the plurality of merchants 104.
[0053] The transaction database 108 may include information of transactions performed between the plurality of merchants 104 and the cardholders 102. In one embodiment, the transaction database 108 may include information of both fraudulent transactions as well as non-fraudulent transactions. In one embodiment, the fraudulent transactions may be reported by the cardholders 102. In one example, the transaction database 108 may include timestamp and location information related to fraudulent transactions performed by a plurality of payment cards at the plurality of merchants 104.
[0054] In one embodiment, the payment network 116 may be used by the payment card issuing authorities as a payment interchange network. The payment network 116 may include a plurality of payment servers such as, the payment server 118. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transactions among a plurality of financial activities that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0055] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks; and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0056] Referring now to FIG. 2, a simplified block diagram of a server system 200 is shown, in accordance with an embodiment of the present disclosure. The server system 200 is similar to the server system 106. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
[0057] The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 for executing instructions, a memory 208, a communication interface 210, and a storage interface 214 that communicate with each other via a bus 212.
[0058] In some embodiments, the database 204 is integrated within the computer system 202. For example, the computer system 202 may include one or more hard disk drives as the database 204. A storage interface 214 is any component capable of providing the processor 206 with access to the database 204. The storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204. In one embodiment, the database 204 is configured to store a CPP model 226.
[0059] Examples of the processor 206 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like. The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.
[0060] The processor 206 is operatively coupled to the communication interface 210 such that the processor 206 is capable of communicating with a remote device 216 such as, the payment server 118, or communicating with any entity connected to the network 110 (as shown in FIG. 1). In one embodiment, the processor 206 is configured to access historical payment transaction data associated with fraudulent payment transactions from the transaction database 108.
[0061] It is noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 200 may include fewer or more components than those depicted in FIG. 2.
[0062] In one embodiment, the processor 206 includes a data pre-processing engine 218, a graph creation engine 220, a fraud probability generator 222, and a scoring engine 224. It should be noted that components, described herein, such as the data pre-processing engine 218, the graph creation engine 220, the fraud probability generator 222, and the scoring engine 224 can be configured in a variety of ways, including electronic circuitries, digital arithmetic and logic blocks, and memory systems in combination with software, firmware, and embedded technologies.
[0063] The data pre-processing engine 218 includes suitable logic and/or interfaces for accessing historical payment transaction data associated with fraudulent payment transactions from the transaction database 108 for a period of time. The historical payment transaction data for each payment transaction may include, but is not limited to, merchant name identifier, unique merchant identifier, a timestamp, geo-location data, information of the payment instrument involved in the payment transaction.
[0064] In particular, the data pre-processing engine 218 is configured to receive a list of payment instruments (for example, payment cards, payment account number, etc.) from a third party server or the payment server 118 indicating flagged or reported as fraudulent payment instruments. The data pre-processing engine 218 is configured to compare identifiers of the list of payment instruments to the stored payment instruments and identify a plurality of merchants involved in payment transactions with the list of payment instruments.
[0065] In one embodiment, the data-preprocessing engine 218 is configured to perform operations (such as data-cleaning, normalization, feature extraction, and the like) on the historical payment transaction data. The data pre-processing engine 218 may remove the fraudulent payment transaction data for the payment instruments (e.g., payment cards) that have been reported as lost or stolen by the cardholders 102.
[0066] The data pre-processing engine 218 may extract the payment transaction data associated with the payment cards of the cardholders 102. In one embodiment, the data pre-processing engine 218 may extract merchant identifier information of the payment cards for a specific geo-location using merchant identifier table. In such manner, the data pre-processing engine 218 is configured to extract information of the plurality of payment instruments used by the cardholders 102 to transact at the plurality of merchants 104.
[0067] In one embodiment, the data pre-processing engine 218 is configured to create entities of location based on channel and a list of the plurality of merchants 104 at which the fraudulent payment transactions have been performed. In this way, the data pre-processing engine 218 is configured to identify the plurality of merchants 104 at which the fraudulent payment transactions have been performed. The data pre-processing engine 218 is further configured to access information of all payment cards that have transacted at the identified plurality of merchants 104 based on the location of the identified plurality of merchants 104. Furthermore, the data pre-processing engine 218 is configured to access a number of total payment cards and a number of fraudulent payment cards at each merchant of the plurality of merchants 104.
[0068] In one embodiment, the data pre-processing engine 218 may use natural language processing (NLP) algorithms to extract a plurality of graph features based on the data elements. The plurality of graph features is used to define the base graph. The plurality of graph features may include, but is not limited to, geolocation data associated with the fraudulent payment transactions, population density, transaction velocity (i.e., frequency of financial transaction among the cardholders 102), historical fraud data, and transaction history. In one embodiment, the geolocation data associated with the fraudulent payment transactions may include information or data associated with identification or estimation of real-world geographic location of the mobile device, or web-based computer or processing device.
[0069] The graph creation engine 220 includes suitable logic and/or interfaces for defining the base graph based, at least in part, on the plurality of graph features identified from the historical payment transaction data. The base graph represents a computer-based graph representation of the plurality of payment instruments as first nodes and the plurality of merchants 104 as second nodes. In addition, relationships between the first nodes and the second nodes are represented as edges. The graph creation engine 220 may generate the base graph that associates the first nodes (i.e., the plurality of payment instruments) and the second nodes (i.e., the plurality of merchants 104) using one or more relationships (i.e., edges). In this case, the base graph may include the first nodes (e.g., nodes relating to the payment card numbers associated with the cardholders 102 etc.), the second nodes (e.g., nodes relating to the merchant identifiers associated with the plurality of merchants 104) and edges (e.g., edges representing fraudulent payment transactions among the related nodes). In at least some embodiments, the base graph is a node-based structure including a plurality of nodes. In one example, the first nodes are connected to the second nodes using respective edges.
[0070] Additionally, the base graph may include metadata associated with the nodes (i.e., the first nodes and the second nodes), and/or information identifying the one or more relationships (such as, for example, payment transaction, fraud connection, etc.) among the nodes. In one example, the fraud connection represents fraud activities among the cardholders 102 during the past time.
[0071] The base graph may be a directed graph, bipartite graph, attributed heterogenous graph, and the like. In addition, the base graph gets modified with time. In one example, each edge of the base graph represents a payment transaction performed between a cardholder (e.g., the cardholder 102a) and a merchant of the plurality of merchants 104. The graph creation engine 220 includes suitable logic and/or interfaces for generating a plurality of sub-graphs based, at least in part, on the base graph. Each sub-graph represents a relationship graph of one or more payment instruments that are used at 'k' number of merchants. In addition, value of 'k' is in a range of 1 to 'n', where 'n' represents a number of the plurality of merchants. In one embodiment, the graph creation engine is configured to partition the base graph into the plurality of sub-graphs in a plurality of iterations.
[0072] In one example, during the first iteration, the graph creation engine 220 is configured to partition a base graph G into a first sub-graph G1. The first sub-graph G1 is a relationship graph of the one or more payment instruments (e.g., payment cards, payment accounts, digital wallets, etc.) that have transacted at only one merchant. In a similar manner, during the second iteration, the graph creation engine 220 is configured to partition the base graph G into a second sub-graph G2. The second sub-graph G2 is a relationship graph of the one or more payment instruments (e.g., payment cards, payment accounts, digital wallets, etc.) that have transacted at two merchants. In a similar manner, during the third iteration, the graph creation engine 220 is configured to partition the base graph G into a third sub-graph G3. The third sub-graph G3 is a relationship graph of the one or more payment instruments (e.g., payment cards, payment accounts, digital wallets, etc.) that have transacted at three merchants, and so on. In one embodiment, the graph creation engine 220 is configured to partition the base graph into 'n' number of sub-graphs in 'n' number of iterations. For example, the last sub-graph is created in the last iteration of the plurality of iterations. In addition, the last sub-graph is a relationship graph of the one or more payment instruments (e.g., payment cards, payment accounts, digital wallets, etc.) that have transacted at 'n' number of merchants based on the historical payment transaction data.
[0073] The fraud probability generator 222 includes suitable logic and/or interfaces for calculating final posterior fraud probabilities of the plurality of merchants 104. During each iteration, the fraud probability score generation engine 222 is configured to determine blame scores assigned to a set of merchants involved in the sub-graph. In one embodiment, the blame scores are determined based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in a previous iteration. For example, blame scores for the set of merchants involved in the fourth sub-graph are determined based on prior fraud probabilities associated with the set of merchants calculated in the previous (i.e., third) iteration.
[0074] Based on the blame scores and the CPP model 226, the fraud probability score generation engine 222 is configured to calculate posterior fraud probabilities at the current iteration associated with the set of merchants. In one embodiment, the CPP model 226 may include mathematical formulas and expressions for calculating values of the blame scores and prior fraud probabilities associated with the set of merchants. For example, based on the blame scores determined during the fourth iteration for the fourth sub-graph, the posterior fraud probabilities for the set of merchants are calculated.
[0075] In one example, the base graph is a relationship graph of fraudulent payment cards and the plurality of merchants 104. In the first iteration, the processor 206 is configured to generate a first sub-graph of the set of merchants that include only those payment cards that have been used for transacting at only one merchant. The processor 206 is further configured to update the blame scores only for these merchants. Further, during the second iteration, the processor 206 is configured to generate a second sub-graph of the set of merchants that include only those payment cards that have been used for transacting at two merchants. Based on the blame scores calculated during the first iteration, the blame scores for the set of merchants in the second sub-graph are determined. The processor 206 is further configured to calculate the posterior fraud probabilities for the set of merchants for the second sub-graph based on the first sub-graph and the second sub-graph.
[0076] In a similar manner, during the third iteration, the processor 206 is configured to generate a third sub-graph of the set of merchants that include only those payment cards that have been used for transacting at three merchants. Based on the blame scores calculated during the second iteration, the blame scores for the set of merchants in the third sub-graph are determined. The processor 206 is further configured to calculate the posterior fraud probabilities for the set of merchants for the third sub-graph based on the first sub-graph, the second sub-graph, and the third sub-graph.
[0077] The scoring engine 224 includes suitable logic and/or interfaces for determining CPP compromise scores associated with the plurality of merchants 104 based, at least in part, on final posterior fraud probabilities of the plurality of merchants 104 at the final iteration of the plurality of iterations. At the final iteration of the plurality of iterations, the final posterior fraud probabilities of the plurality of merchants 104 are determined. Based on the final posterior fraud probabilities, the CPP compromise scores associated with the plurality of merchants 104 are determined, and based on the CPP compromise scores, the common point of purchase (CPP) compromised merchants are identified.
[0078] In one embodiment, CPP compromised merchants are identified based on a deep learning (DL) based merchant breach algorithm. In general, deep learning is a subset of machine learning (ML) and artificial intelligence (AI) with multiple levels of representation, to progressively extract higher-level features from raw input. The merchant breach algorithm utilizes time-series classification with distribution modeling. Initially, the merchant breach algorithm generates a fraud grid including fraud ratios for the plurality of merchants 104 over different time duration (e.g., one year, three years, etc.). The fraud ratio at a particular time duration indicates a probability of re-utilization of the reported fraudulent payment cards within the particular time duration at the CPP compromised merchant.
[0079] In addition, fraud ratio distribution is modeled at an overall and merchant level using Monte Carlo simulations to give an understanding of the fraud ratio being way above the overall and merchant level fraud ratio distribution. In one embodiment, the number of fraudulent payment cards is modeled as Poisson distribution and cumulative distribution probability is estimated.
[0080] In the fraud ratio table, a triangular pattern is observed in the merchant data matrix for various merchants. These merchants are further detected as CPP-compromised merchants. In one embodiment, the convolutional neural network is used to identify this triangular pattern to extract merchant features. The merchant features may include, but are not limited to, the cumulative distribution probabilities, the total number of the payment cards used, fraud ratios for the merchants, and scores from the convolutional neural network. The merchant features are further fed into a sequential model that uses teacher forcing to identify the CPP compromised merchants.
[0081] The sequential model uses a long short-term memory (LSTM) architecture that uses teacher forcing to re-look at all the inputs and previous time steps before making the final classification decision. In general, LSTM is an artificial recurrent neural network architecture used in the field of deep learning capable of learning order dependence in sequence prediction problems. Teacher forcing uses previous time-step input’s output as its current input. The re-look classification architecture is configured to add the input back into the decoder. Further, outputs of the LSTM decoder layer are concatenated for calculation of the final output.
[0082] The sequential model concatenates all the outputs from the decoder LSTMs to classify the merchant as a CPP merchant, thereby enforcing the classification model to take into consideration individual time features as important to make the final prediction, instead of the general trend. In one embodiment, the use of feature engineering with convolutional neural network and Monte Carlo simulations significantly increase the performance of the merchant breach algorithm.
[0083] In one embodiment, the scoring engine 224 is configured to identify the CPP compromised merchants based on the CPP compromise scores and output of the merchant breach algorithm. In one embodiment, the CPP compromise score generation engine 224 classifies the plurality of merchants 104 into the CPP compromise merchants if the final posterior fraud probabilities of the merchants 104 are greater than a threshold value.
[0084] In some embodiments, the server system 106 is configured to detect test merchants, bad merchants, and fraudulent attack merchants along with the CPP compromised merchants. The test merchants include those merchants that can be used to verify information of stolen payment instruments (e.g., payment card associated with a cardholder). In addition, bad merchants include those merchants that consistently show high fraudulent rates. Further, the fraudulent attack merchants include those merchants that are victims of targeted fraudulent attacks. In some embodiments, the CPP compromised merchants identified from the plurality of merchants may be further used in the calculation of network scores, such as account reissuance score, high-risk merchant/channel score, and the like.
[0085] FIGS. 3A-3D, collectively, represent example representations of a process of generating the plurality of sub-graphs from the base graph, in accordance with an embodiment of the present disclosure.
[0086] As explained above, the processor 206 is configured to define the base graph based on the plurality of graph features. The plurality of graph features may include, but is not limited to, geolocation data associated with the payment transactions, population density, transaction velocity (i.e., frequency of payment transactions at the plurality of merchants 104), historical payment transaction data, and transaction history. The base graph represents a computer-based graph representation of the plurality of payment instruments as the first nodes and the plurality of merchants 104 as the second nodes. In addition, relationships between the first nodes and the second nodes are represented as weights of the edges. The relationship between the first nodes and the second nodes is set forth in solid, dashed, and/or bolded lines (e.g., with arrows). The processor 206 is also configured to determine weights and directions of edges based on the plurality of graph features (not shown in figures).
[0087] Referring now to FIG. 3A, an example representation 300 of a base graph G is shown. The base graph G is defined and generated based on the plurality of graph features extracted from the historical payment transaction data. The base graph G represents a computer-based graph representation of the plurality of payment instruments as the first nodes P1-P4 and the plurality of merchants 104 as the second nodes M1-M4. In other words, the first nodes represent the plurality of payment instruments P1-P4 and the second nodes represent the plurality of merchants M1-M4. In addition, the weights of the edges are determined based on the plurality of graph features. In one embodiment, the edges may represent payment transactions performed by the cardholders 102 with the plurality of payment instruments at the plurality of merchants 104.
[0088] In one embodiment, the processor 206 is configured to update the base graph by adding first nodes or second nodes, adding edges, removing the first nodes or the second nodes, removing edges, adding additional metadata for existing first nodes and second nodes, removing metadata for existing first nodes and second nodes, and/or the like. In this case, the processor 206 is also configured to update the base graph by adding additional first nodes, second nodes, and edges that identify new relationships between the plurality of payment instruments and the plurality of merchants 104.
[0089] Referring now to FIG. 3B, an example representation 310 of generating a first sub-graph G1 from the base graph G is shown. In the first iteration of the plurality of iterations, the first sub-graph G1 is generated. The first sub-graph G1 includes only those payment instruments that have been used for transactions at only one merchant. As shown in FIG. 3B, the first sub-graph G1 includes the payment instrument P2, the payment instrument P4, the merchant M2, and the merchant M4. In addition, the payment instrument P2 has been used for the transaction at only the merchant M2 and the payment instrument P4 has been used for the transaction at only the merchant M4. Further, the blame scores are determined for the set of merchants M2 and M4 involved in the sub-graph G1 based on the fraud probabilities associated with the set of merchants. In one embodiment, during the first iteration, fraud probabilities of the set of merchants are initialized based on the number of the merchants at which the plurality of payment instruments has transacted. For example, fraud probability for the merchant M2 may be initialized to 1 as payment instrument P2 has only transacted at the merchant M2. In a similar manner, fraud probability for the merchant M4 may be initialized to 0.5 as two payment instruments (i.e., payment instrument P3 and payment instrument P4) have transacted at the merchant M4. The mathematical model for the calculation of the blame scores is explained in detail with reference to FIG. 4.
[0090] Referring now to FIG. 3C, an example representation 320 of generating a second sub-graph G2 from the base graph G is shown. In the second iteration of the plurality of iterations, the second sub-graph G2 is generated. The second sub-graph G2 includes only those payment instruments (e.g., payment cards) that have been used for performing transactions at two merchants. As shown in FIG. 3C, the second sub-graph G2 includes the payment instrument P3, the merchant M3, and the merchant M4. In addition, the payment instrument P3 has been used for the transaction at two merchants (i.e., the merchant M3 and the merchant M4). Further, the blame scores are determined for the set of merchants M3 and M4 involved in the sub-graph G2 based on the prior fraud probabilities associated with the set of merchants M3 and M4. Based on the blames scores and the CPP model 226 (i.e., mathematical model), the posterior fraud probabilities at the current iteration (i.e., the second iteration) associated with the set of merchants (i.e., the merchant M3 and the merchant M4) are calculated. The mathematical model for the calculation of the blame scores and the fraud probabilities is explained in detail with reference to FIG. 4.
[0091] Referring now to FIG. 3D, an example representation 330 of generating a third sub-graph G3 from the base graph G is shown. In the third iteration of the plurality of iterations, the third sub-graph G3 is generated. The third sub-graph G3 includes only those payment instruments (e.g., payment cards) that have been used for performing transactions at three merchants. As shown in FIG. 3D, the third sub-graph G3 includes the payment instrument P1, the merchant M1, the merchant M2, and the merchant M3. In addition, the payment instrument P1 has been used for the transaction at three merchants (i.e., the merchant M1, the merchant M2, and the merchant M3). Further, the blame scores are determined for the set of merchants M1, M2, and M3 involved in the third sub-graph G3 based on the prior fraud probabilities associated with the set of merchants M1, M2, and M3. Based on the blame scores and the CPP model 226 (i.e., mathematical model), the posterior fraud probabilities at current iteration (i.e., the third iteration) associated with the set of merchants (i.e., the merchant M1, the merchant M2, and the merchant M3) are calculated. In other words, posterior fraud probabilities at the current iteration (i.e., the third iteration) are calculated based on the base graph G, the first sub-graph G1, and the second sub-graph G2. The mathematical model for the calculation of the blame scores and the fraud probabilities is explained in detail with reference to FIG. 4.
[0092] FIGS. 4A-4D, collectively, represent example representations of tables representing mathematical values for calculating the blame scores and posterior fraud probabilities without hyper-parameters, in accordance with an embodiment of the present disclosure.
[0093] As explained above, the processor 206 is configured to determine the blame scores and posterior fraud probabilities for the plurality of merchants 104. In addition, the blame scores and posterior fraud probabilities associated with the plurality of merchants 104 are updated during each iteration. At the final iteration, the final posterior fraud probability for each of the plurality of merchants 104 represents the CPP compromise score of each merchant.
[0094] As shown in FIG. 4A, a table 400 represents merchant identifier of the plurality of merchants 104 along with weights and blames normalized for the plurality of merchants 104 for the plurality of iterations. The table 400 includes five columns, namely merchant identifier, payment card, the payment card used at a number of merchants, weight, and blame scores. The table includes various rows depicting corresponding values for the five columns.
[0095] In one embodiment, information such as merchant identifier, payment card, and payment card used at a number of merchants are included in the historical payment transaction data accessed from the transaction database 108. The values in the aforementioned columns may represent exemplary data. In addition, weights and blame scores for the plurality of merchants 104 may be assigned and updated during each iteration of the plurality of iterations. In one embodiment, the CPP model 226 includes the mathematical formulas and expressions for the calculation of the weights and the blame scores. The CPP model 226 is defined based at least on Bayesian statistics-based methods.
[0096] As explained above, during the first iteration, the weights and blames may be initialized based on the number of the plurality of merchants 104 at which the plurality of payment instruments (i.e., payment cards) have transacted. For example, weight and blame for the payment card "xx" for the merchant 1 are 1 and 1 respectively. For the remaining iterations, the weights for any given instantaneous current iteration may be updated based on prior fraud probabilities of previous iterations. For example, the value of weight (i.e., 50%) for the card 1 used at the merchant 1 (i.e., fourth row) is calculated based on prior fraud probability calculated for the merchant 1 during the first iteration (shown in FIG. 4B). Similarly, weights are updated for the plurality of merchants 104 during each iteration of the plurality of iterations.
[0097] In one embodiment, blame scores are updated based on prior fraud probabilities of the plurality of merchants 104. More specifically, blame scores are updated based on normalized weights of the payment cards used at the set of merchants during each iteration of the plurality of iterations. For example, blame score for the payment card 1 (i.e., fourth row) is calculated as: weight of payment card 1 at merchant 1 (i.e., 50%) / weight of payment card 1 at merchant 1 (i.e., 50%) + weight of payment card 1 at merchant 3 (i.e., 13.64%). In a similar manner, blame scores are updated for each of the plurality of merchants 104.
[0098] Referring now to FIG. 4B, a table 410 represents values calculated for fraudulent payment instruments (i.e., fraudulent payment cards) used at only one merchant during the first iteration of the plurality of iterations, in accordance with an embodiment of the present disclosure. The table 410 represents a merchant identifier of the plurality of merchants 104 along with information such as fraudulent payment cards, total number of payment cards, etc. used during the first iteration of the plurality of iterations. The table 410 includes seven columns, namely merchant, sum blame, number of fraudulent payment cards, total number of payment cards, the total number of payment cards at iteration 'i', total number of fraudulent payment cards, and prior fraud probabilities. The table 410 includes various rows depicting corresponding values for the seven columns.
[0099] During the first iteration, the corresponding values of the sum blames, and the prior fraud probabilities are shown in FIG. 4B. In one embodiment, the prior fraud probability for each of the plurality of merchants 104 is calculated as: sum blame / total number of payment cards at iteration 'i'. For example, the prior fraud probability for the merchant 1 (i.e., 50.00%) is calculated as: sum blame for the merchant 1 (i.e., 2) / total number of payment cards at iteration 'i' for the merchant 1 (i.e., 4). In a similar manner, the prior fraud probability for the merchant 2 and the merchant 3 is calculated and shown in the table 410.
[00100] Referring now to FIG. 4C, a table 420 represents values calculated for fraudulent payment instruments (i.e., fraudulent payment cards) used at two merchants during second iteration of the plurality of iterations, in accordance with an embodiment of the present disclosure.
[00101] As shown in FIG. 4C, the table 420 represents merchant identifier of the plurality of merchants 104 along with information such as fraudulent payment cards, the total number of payment cards, etc. used during the second iteration of the plurality of iterations. The table 420 includes seven columns, namely merchant, sum blame, number of fraudulent payment cards, the total number of payment cards, total number of payment cards at iteration 'i', the total number of fraudulent payment cards, and prior fraud probabilities. The table 420 includes various rows depicting corresponding values for the seven columns.
[00102] During the second iteration, corresponding values of the sum blames, and the prior fraud probabilities are shown in FIG. 4C. In one embodiment, sum blame for each of the plurality of merchants 104 is calculated as a weighted average of the blame scores for the payment cards that have been used at two merchants. These values may be taken from the table of FIG. 4A. For example, the sum blame for the merchant 1 may be calculated as a weighted average of the blame scores for the payment cards that have been used at two merchants for the merchant 1 (i.e., 0.785714286 as shown in fourth-row blame column of FIG. 4A). Similarly, the sum blame for the merchant 2 may be calculated as a weighted average of the blame scores for the payment cards that have been used at two merchants for the merchant 2 (i.e., 0.18571428 + 0.18571428 + 0.18571428 as shown in rows 11, 12, and 12 blame column of FIG. 4A). In a similar manner, the sum blame for the merchant 3 is calculated.
[00103] In one embodiment, the prior fraud probability for each of the plurality of merchants 104 is calculated as: sum blame of a particular merchant for current iteration + sum blame of the particular merchant for previous iteration / total number of payment cards at iteration 'i' for a particular merchant for current iteration + total number of payment cards at iteration 'i' for the particular merchant for the previous iteration. For example, the prior fraud probability for the merchant 1 (i.e., 2.68%) is calculated as: sum blame for the merchant 1 at current iteration (i.e., 0.785714286) + sum blame for the merchant 1 at previous iteration (i.e., 2) / total number of payment cards at iteration 'i' for the merchant 1 at current iteration (i.e., 100) + a total number of payment cards at iteration 'i' for the merchant 1 at previous iteration (i.e., 4). Similarly, the prior fraud probability for the merchant 2 and the merchant 3 is calculated and represented in the table 420.
[00104] Referring now to FIG. 4D, a table 430 represents values calculated for fraudulent payment instruments (i.e., fraudulent payment cards) used at three merchants during the third iteration of the plurality of iterations, in accordance with an embodiment of the present disclosure.
[00105] As shown in FIG. 4D, the table 430 represents merchant identifier of the plurality of merchants 104 along with information such as fraudulent payment cards, the total number of payment cards, etc. used during the third iteration of the plurality of iterations. The table 430 includes seven columns, namely merchant, sum blame, number of fraudulent payment cards, the total number of payment cards, total number of payment cards at iteration 'i', the total number of fraudulent payment cards, and prior fraud probabilities. The table 430 includes various rows depicting corresponding values for the seven columns.
[00106] During the third iteration, corresponding values of the sum blames, and the prior fraud probabilities are shown in FIG. 4D. In one embodiment, sum blame for each of the plurality of merchants 104 is calculated as a weighted average of the sum blames for the payment cards that have been used at three merchants. These values may be taken from the table of FIG. 4A. For example, the sum blame for the merchant 1 is calculated as a weighted average of the blame scores for the payment cards that have been used at three merchants for the merchant 1 (i.e., 0.1952871 shown in the fifth row blame column of FIG. 4A + 0.1952871 shown in sixth-row blame column of FIG. 4A). In a similar manner, the sum blame for the merchant 2 and the merchant 3 is calculated.
[00107] In one embodiment, the prior fraud probability for each of the plurality of merchants 104 is calculated as: sum blame of a particular merchant for current iteration + sum blame of the particular merchant for all previous iterations / total number of payment cards at iteration 'i' for a particular merchant for current iteration + a total number of payment cards at iteration 'i' for the particular merchant for all previous iterations.
[00108] For example, the prior fraud probability for the merchant 1 (i.e., 1.56%) is calculated as: sum blame for the merchant 1 at current iteration (i.e., 0.390574143) + sum blame for the merchant 1 at second iteration (i.e., 0.785714286) + sum blame for the merchant 1 at first iteration (i.e., 2) / total number of payment cards at iteration 'i' for the merchant 1 at current iteration (i.e., 100) + a total number of payment cards at iteration 'i' for the merchant 1 at second iteration (i.e., 100) + a total number of payment cards at iteration 'i' for the merchant 1 at first iteration (i.e., 4).
[00109] In a similar manner, the prior fraud probability for the merchant 2 and the merchant 3 is calculated and represented in the table 430. It is to be noted that calculations performed without hyper-parameters (i.e., based on tables depicted in FIGS. 4A-4D) may give rise to small merchant problems. The small merchant problem means that for smaller merchants of the plurality of merchants 104, the prior fraud probabilities may peak much higher and larger than for larger merchants of the plurality of merchants 104. In other words, heavier weightage is given to the smaller merchants. As a result, smaller merchants with a high number of payment instruments (e.g., fraudulent payment cards) have a high prior fraud probability during earlier iterations. These high prior fraud probabilities do not decrease even if the number of iterations is increased. This may further lead to a bias in selecting the smaller merchants as the CPP compromised merchants as mid-size and large merchants do not appear in top results for the prior fraud probability score.
[00110] To overcome this problem, hyperparameters (i.e., alpha and beta) are introduced at each iteration of the plurality of iterations. In one embodiment, alpha and beta are introduced to normalize the posterior fraud probability of the plurality of merchants 104 during each iteration of the plurality of iterations. The mathematical calculations and expressions for calculation of the blame scores and the posterior fraud probabilities with the inclusion of alpha and beta are explained in detail with reference to FIGS. 5A-5D.
[00111] FIGS. 5A-5D, collectively, represent example representations of tables representing mathematical values for calculating the blame scores and posterior fraud probabilities with hyper-parameters, in accordance with an embodiment of the present disclosure. The hyper-parameters include alpha (α) and beta (β).
[00112] In one embodiment, the final posterior fraud probability for each of the plurality of merchants 104 corresponds to a sum of the number of fraudulent payment cards at iteration 'i' and alpha (α) divided by the sum of the total number of payment cards at iteration 'i' and beta (β). In other words, the final posterior fraud probability for each merchant is calculated as: number of fraudulent payment cards at iteration 'i' + alpha (α) / total number of payment cards at iteration 'i' + beta (β).
[00113] In one embodiment, during each iteration, alpha corresponds to an average number of fraudulent payment instruments (e.g., payment cards) at iteration 'i' for the plurality of merchants 104. In addition, beta corresponds to an average of the total number of payment instruments (e.g., payment cards) at iteration 'i' utilized at each merchant of the plurality of merchants 104. In an embodiment, the prior fraud probability for new merchants may be calculated as: alpha / beta, except for the first iteration. In another embodiment, the prior fraud probability for new merchants may be calculated as: alpha / (beta * iteration number), except for the first iteration.
[00114] In one embodiment, the processor 206 is configured to calculate cumulative alpha for each sub-graph for each of the plurality of iterations. For the first iteration, the cumulative alpha corresponds to alpha. For remaining of the plurality of iterations, the cumulative alpha corresponds to the sum of alpha for the current sub-graph and cumulative alpha of the previous sub-graph.
[00115] In one embodiment, the processor 206 is configured to calculate cumulative beta for each sub-graph for each of the plurality of iterations. For the first iteration, the cumulative beta corresponds to beta. For the remaining plurality of iterations, the cumulative beta corresponds to the sum of beta for the current sub-graph and the cumulative beta of the previous sub-graph.
[00116] In some embodiments, the processor 206 is configured to determine the blame scores and posterior fraud probabilities for the plurality of merchants 104 with the inclusion of alpha and beta hyper-parameters. In addition, the blame scores and posterior fraud probabilities associated with the plurality of merchants 104 are updated during each iteration. At the final iteration (i.e., last iteration), the final posterior fraud probability for each of the plurality of merchants 104 is calculated, based on which each of the plurality of merchants 104 is classified as CPP compromise merchant or normal merchant.
[00117] As shown in FIG. 5A, a table 500 represents merchant identifier of the plurality of merchants 104 along with weights and blames normalized for the plurality of merchants 104 for the plurality of iterations. The table 500 includes five columns, namely merchant identifier, payment card, the payment card used at a number of merchants, weight, and blame scores. The table 500 includes various rows depicting corresponding values for the five columns.
[00118] In one embodiment, information such as merchant identifier, payment card, and payment card used at a number of merchants are included in the historical payment transaction data accessed from the transaction database 108. The values in the aforementioned columns may represent exemplary data. In addition, weights and blame scores for the plurality of merchants 104 may be assigned and updated during each iteration of the plurality of iterations. In one embodiment, the CPP model 226 includes the mathematical formulas and expressions for the calculation of the weights and the blame scores.
[00119] As explained above, during the first iteration, the weights and blame scores may be initialized based on the number of the plurality of merchants 104 at which the plurality of payment instruments (i.e., payment cards) have transacted. For example, weight and blame for the payment card xx for the merchant 1 are 1 and 1 respectively (see, row 2). For the remaining iterations, the weights for any given instantaneous current iteration may be updated based on prior fraud probabilities of previous iterations. For example, value of weight (i.e., 2.27%) for the card 1 used at the merchant 1 (i.e., fourth row) is calculated based on prior fraud probability calculated for the merchant 1 during the first iteration (shown in FIG. 5B). In a similar manner, weights are updated for the plurality of merchants 104 during each iteration of the plurality of iterations.
[00120] In one embodiment, blame scores are updated based on prior fraud probabilities of the plurality of merchants 104. More specifically, blame scores are updated based on normalized weights of the payment cards used at the set of merchants during each iteration of the plurality of iterations. For example, blame score for the payment card 1 (i.e., fourth row) is calculated as: weight of payment card 1 at merchant 1 (i.e., 2.27%) / weight of payment card 1 at merchant 1 (i.e., 2.27%) + weight of payment card 1 at merchant 3 (i.e., 2.82%). In a similar manner, blame scores are updated for each of the plurality of merchants 104.
[00121] Referring now to FIG. 5B, a table 510 represents values calculated for fraudulent payment instruments (i.e., fraudulent payment cards) used at only one merchant during the first iteration of the plurality of iterations, in accordance with an embodiment of the present disclosure.
[00122] As shown in FIG. 5B, the table 510 represents merchant identifier of the plurality of merchants 104 along with information such as fraudulent payment cards, the total number of payment cards, etc. used during the first iteration of the plurality of iterations. The table 510 includes nine columns, namely merchant, sum blame, number of fraudulent payment cards, the total number of payment cards, the total number of payment cards at iteration 'i', the total number of fraudulent payment cards, cumulative alpha, cumulative beta, and prior fraud probabilities. The table 510 includes various rows depicting corresponding values for the nine columns.
[00123] During the first iteration, corresponding values of the sum blames, cumulative alpha, cumulative beta, and the prior fraud probabilities are shown in FIG. 5B. In one embodiment, the prior fraud probability for each of the plurality of merchants 104 is calculated as: sum blame for corresponding merchant + cumulative alpha for corresponding merchant / total number of payment cards at iteration 'i' + cumulative alpha for the corresponding merchant + cumulative beta for the corresponding merchant. For example, the prior fraud probability for the merchant 1 (i.e., 2.27%) is calculated as: sum blame for the merchant 1 (i.e., 2) + cumulative alpha for the merchant 1 (i.e., 0.0261) / total number of payment cards at iteration 'i' for the merchant 1 (i.e., 4) + cumulative alpha for the merchant 1 (i.e., 0.0261) + cumulative beta for the merchant 1 (i.e., 85.2615). In a similar manner, the prior fraud probability for the merchant 2 and the merchant 3 is calculated and shown in the table 510.
[00124] Referring now to FIG. 5C, a table 520 represents values calculated for fraudulent payment instruments (i.e., fraudulent payment cards) used at two merchants during the second iteration of the plurality of iterations, in accordance with an embodiment of the present disclosure.
[00125] As shown in FIG. 5C, the table 520 represents merchant identifier of the plurality of merchants 104 along with information such as fraudulent payment cards, the total number of payment cards, etc. used during the second iteration of the plurality of iterations. The table 520 includes nine columns, namely merchant, sum blame, number of fraudulent payment cards, the total number of payment cards, the total number of payment cards at iteration 'i', the total number of fraudulent payment cards, cumulative alpha, cumulative beta, and prior fraud probabilities. The table 520 includes various rows depicting corresponding values for the nine columns.
[00126] During the second iteration, corresponding values of the sum blames, cumulative alpha, cumulative beta, and the prior fraud probabilities are shown in FIG. 5C. In one embodiment, sum blame for each of the plurality of merchants 104 is calculated as a weighted average of the sum blames for the payment cards that have been used at two merchants. These values may be taken from the table of FIG. 5A. For example, the sum blame for the merchant 1 may be calculated as a weighted average of the sum blames for the payment cards that have been used at two merchants for the merchant 1 (i.e., 0.44583369 as shown in row 4 blame of FIG. 5A). In a similar manner, the sum blame for the merchant 2 may be calculated as a weighted average of the sum blames for the payment cards that have been used at two merchants for the merchant 2 (i.e., 0.23673664 + 0.23673664 + 0.23673664 as shown in rows 11, 12, and 13 blame of FIG. 5A). In a similar manner, the sum blame for the merchant 3 is calculated.
[00127] In one embodiment, the prior fraud probability for each of the plurality of merchants 104 is calculated as: sum blame of a particular merchant for current iteration + sum blame of the particular merchant for the previous iteration + cumulative alpha for the particular merchant at current iteration / total number of payment cards at iteration 'i' for the particular merchant for current iteration + the total number of payment cards at iteration 'i' for the particular merchant for the previous iteration + cumulative alpha for the particular merchant at current iteration + cumulative beta for the particular merchant at the current iteration. For example, the prior fraud probability for the merchant 1 (i.e., 1.03%) is calculated as: sum blame for the merchant 1 at current iteration (i.e., 0.44583369) + sum blame for the merchant 1 at previous iteration (i.e., 2) + cumulative alpha for the merchant 1 at current iteration (i.e., 0.0466) / total number of payment cards at iteration 'i' for the merchant 1 at current iteration (i.e., 100) + total number of payment cards at iteration 'i' for the merchant 1 at previous iteration (i.e., 4) + cumulative alpha for the merchant 1 at current iteration (i.e., 0.0466) + cumulative beta for the merchant 1 at current iteration (i.e., 138.6637). In a similar manner, the prior fraud probability for the merchant 2 and the merchant 3 is calculated and represented in the table 520.
[00128] Referring now to FIG. 5D, a table 530 represents values calculated for fraudulent payment instruments (i.e., fraudulent payment cards) used at three merchants during the third iteration of the plurality of iterations, in accordance with an embodiment of the present disclosure.
[00129] As shown in FIG. 5D, the table 530 represents merchant identifier of the plurality of merchants 104 along with information such as fraudulent payment cards, total number of payment cards, etc. used during the third iteration of the plurality of iterations. The table 530 includes nine columns, namely merchant, sum blame, number of fraudulent payment cards, the total number of payment cards, total number of payment cards at iteration 'i', the total number of fraudulent payment cards, cumulative alpha, cumulative beta, and prior fraud probabilities. The table 530 includes various rows depicting corresponding values for the nine columns.
[00130] During the third iteration, corresponding values of the sum blames, cumulative alpha, cumulative beta, and the prior fraud probabilities are shown in FIG. 5D. In one embodiment, sum blame for each of the plurality of merchants 104 is calculated as a weighted average of the sum blames for the payment cards that have been used at three merchants. These values may be taken from the table of FIG. 5A. For example, the sum blame for the merchant 1 is calculated as a weighted average of the blame scores for the payment cards that have been used at three merchants for the merchant 1 (i.e., 0.22185653 shown in row 4 blame of FIG. 5A + 0.22185653 shown in row 5 blame of FIG. 5A). In a similar manner, the sum blame for the merchant 2 and the merchant 3 is calculated and represented in the table 530.
[00131] In one embodiment, the prior fraud probability for each of the plurality of merchants 104 is calculated as: sum blame of a particular merchant for current iteration + sum blame of the particular merchant for all previous iterations + cumulative alpha for the particular merchant for current iteration / total number of payment cards at iteration 'i' for the particular merchant for current iteration + total number of payment cards at iteration 'i' for the particular merchant for all previous iterations + cumulative alpha for the particular merchant for current iteration + cumulative beta for the particular merchant for the current iteration. For example, the prior fraud probability for the merchant 1 (i.e., 0.76%) is calculated as: sum blame for the merchant 1 at current iteration (i.e., 0.44371306) + sum blame for the merchant 1 at second iteration (i.e., 0.44583369) + sum blame for the merchant 1 at first iteration (i.e., 2) + cumulative alpha for the merchant 1 for current iteration (i.e., 0.0632) / total number of payment cards at iteration 'i' for the merchant 1 at current iteration (i.e., 100) + total number of payment cards at iteration 'i' for the merchant 1 at second iteration (i.e., 100) + total number of payment cards at iteration 'i' for the merchant 1 at first iteration (i.e., 4) + cumulative alpha for the merchant 1 for current iteration (i.e., 0.0632) + cumulative beta for the merchant 1 for current iteration (i.e., 186.7470). In a similar manner, the prior fraud probability for the merchant 2 and the merchant 3 is calculated and represented in the table 530.
[00132] It is to be noted that the mathematical formulas and expressions for calculating the value of the hyper-parameters (i.e., alpha and beta), cumulative alpha, and cumulative beta may also be stored in the CPP model 226. Further, calculations for the hyper-parameters, cumulative alpha, and cumulative beta for each of the plurality of iterations may be explained in detail with reference to FIG. 6.
[00133] FIG. 6 represents an example representation of a table 600 representing mathematical values for calculating cumulative alpha and cumulative beta based on hyper-parameters, in accordance with an embodiment of the present disclosure.
[00134] The table 600 represents sub-graph number of the plurality of sub-graphs along with values, such as alpha, beta, cumulative alpha, cumulative beta, etc. for the plurality of sub-graphs. The table 600 includes ten columns, namely sub-graph number, average fraudulent payment instruments (i.e., fraudulent payment cards) at the merchant, average total payment instruments (i.e., payment cards) at the merchant, average fraudulent payment cards / total payment cards, alpha, beta, alpha / (alpha + beta), cumulative alpha, cumulative beta, and cumulative alpha / cumulative beta. The table 600 includes various rows depicting corresponding values for the ten columns.
[00135] In one embodiment, information such as sub-graph number, average fraudulent payment instruments (i.e., fraudulent payment cards) at the merchant, and average total payment instruments (i.e., payment cards) at the merchant are included in the historical payment transaction data accessed from the transaction database 108. The values in the aforementioned columns may represent exemplary data. In one embodiment, the CPP model 226 includes the mathematical formulas and expressions for the calculation of the hyper-parameters, cumulative alpha, and cumulative beta.
[00136] In one embodiment, alpha is calculated as: average fraudulent payment instruments (i.e., fraudulent payment cards) at merchant / sub-graph number. For example, alpha for first sub-graph (see, row 2) is calculated as: average fraudulent payment instruments (i.e., fraudulent payment cards) at merchant (i.e., 0.02605437) / sub-graph number (i.e., 1). In a similar manner, alpha for second sub-graph (see, row 3) is calculated as: average fraudulent payment instruments (i.e., fraudulent payment cards) at merchant (i.e., 0.041145468) / sub-graph number (i.e., 2). In a similar manner, alpha for the rest of the plurality of sub-graphs is calculated and represented in the table 600.
[00137] In one embodiment, beta is calculated as: average total payment instruments (i.e., payment cards) at the merchant. For example, a beta for the first sub-graph (see, row 2) is calculated as: average total payment instruments (i.e., payment cards) at the merchant (i.e., 85.2615). In a similar manner, a beta for the second sub-graph (see, row 3) is calculated as: average total payment instruments (i.e., payment cards) at the merchant (i.e., 53.4022). In a similar manner, beta for the rest of the plurality of sub-graphs is calculated and represented in the table 600.
[00138] In one embodiment, for the first iteration, cumulative alpha is equal to alpha. In addition, for the remaining of the plurality of iterations, cumulative alpha corresponds to the sum of alpha for the current sub-graph and cumulative alpha of the previous sub-graph. For example, cumulative alpha for the first sub-graph is equal to alpha for the first sub-graph (i.e., 0.02605437) (see, row 2). In addition, cumulative alpha for second sub-graph is calculated as: alpha for current sub-graph (i.e., second sub-graph) (i.e., 0.02057273) + cumulative alpha for previous sub-graph (i.e., first sub-graph) (i.e., 0.02605437). In a similar manner, cumulative alpha for the rest of the sub-graphs is calculated and represented in the table 600.
[00139] In one embodiment, for the first iteration, cumulative beta is equal to beta. In addition, for the remaining of the plurality of iterations, cumulative beta corresponds to the sum of beta for the current sub-graph and cumulative beta of the previous sub-graph. For example, the cumulative beta for the first sub-graph is equal to the beta for the first sub-graph (i.e., 85.26152882) (see, row 2). In addition, cumulative beta for second sub-graph is calculated as: beta for current sub-graph (i.e., second sub-graph) (i.e., 53.4022) + cumulative beta for previous sub-graph (i.e., first sub-graph) (i.e., 85.26152882). In a similar manner, the cumulative beta for the rest of the sub-graphs is calculated and represented in the table 600.
[00140] FIG. 7 represents a flow chart 700 of a method for identifying CPP compromised merchants from the plurality of merchants 104, in accordance with an embodiment of the present disclosure. The sequence of operations of the flow chart 700 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the flow chart 700, references may be made to elements described in FIG. 1 and FIG. 2.
[00141] At 702, the server system 200 accesses historical payment transaction data associated with fraudulent payment transactions from the transaction database 108. In one embodiment, the fraudulent payment transactions may be performed by the plurality of payment instruments associated with the cardholders 102 at the plurality of merchants 104. In one embodiment, the historical payment transaction data is accessed for a particular time duration (e.g., 1 month, 6 months, 1 year, 2 years, etc.).
[00142] At 704, the server system 200 generates a plurality of graph features corresponding to each of the plurality of merchants based, at least in part, on the historical payment transaction data. The plurality of graph features may include, but is not limited to, geolocation data associated with the fraudulent payment transactions, population density, transaction velocity (i.e., frequency of payment transactions among the cardholders 102), historical fraudulent payment data, and transaction history.
[00143] At 706, the server system 200 defines the base graph based, at least in part, on the plurality of graph features. The base graph is a computer-based graph representation of the plurality of payment instruments as the first nodes and the plurality of merchants 104 as the second nodes. In addition, relationships (e.g., payment transactions) between the first nodes and the second nodes are represented as edges of the base graph.
[00144] At 708, the server system 200 runs a plurality of iterations to generate a plurality of sub-graphs based, at least in part, on the base graph. In one embodiment, each sub-graph is generated in each iteration of the plurality of iterations based on the sub-graph. In addition, the first sub-graph created in the first iteration is a graph representation of only those payment instruments (e.g., fraudulent payment cards) that have transacted at only one merchant of the plurality of merchants 104. The second sub-graph is created in the second iteration, and it is a graph representation of only those payment instruments (e.g., fraudulent payment cards) that have transacted at two merchants of the plurality of merchants 104.
[00145] At 708a, during each iteration of the plurality of iterations, the server system 200 determines blame scores assigned to the set of merchants involved in the corresponding sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in a previous iteration. In one embodiment, the server system 200 determines the blame scores based on the CPP model 226. The calculations for the blame scores at each iteration is herein explained in detail with reference to FIG. 4 and FIG. 5, and therefore, they are not reiterated for the sake of brevity.
[00146] At 708b, during each iteration of the plurality of iterations, the server system 200 calculates posterior fraud probabilities at the current iteration associated with the set of merchants based, at least in part, on the blame scores and the CPP model 226. The calculations for the posterior fraud probabilities at each iteration are herein explained in detail with reference to FIG. 4 and FIG. 5, and therefore, they are not reiterated for the sake of brevity.
[00147] At 710, at the final iteration of the plurality of iterations, the server system 200 determines the CPP compromise scores associated with the plurality of merchants 104 based, at least in part, on final posterior fraud probabilities of the plurality of merchants 104 at the final iteration of the plurality of iterations.
[00148] At 712, the server system 200 classifies the plurality of merchants 104 into the CPP compromise merchants if the final posterior fraud probabilities of each of the plurality of merchants 104 are greater than a threshold.
[00149] The sequence of steps of the flow chart 700 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[00150] FIG. 8 illustrates a flow diagram depicting a method 800 for detecting CPP compromised merchants, in accordance with an embodiment of the present disclosure. The method 800 depicted in the flow diagram may be executed by, for example, the server system 200. Operations of the method 800, and combinations of operation in the method 800, may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions. The operations of the method 800 are described herein may be performed by an application interface that is hosted and managed with help of the server system 200. The method 800 starts at operation 802.
[00151] At operation 802, the method 800 includes accessing, by the server system 200, historical payment transaction data associated with fraudulent payment transactions from the transaction database 108. The fraudulent payment transactions may be performed by the plurality of payment instruments associated with the cardholders 102 at the plurality of merchants 104.
[00152] At operation 804, the method 800 includes defining, by the server system 200, the base graph based, at least in part, on the historical payment transaction data. The base graph represents a computer-based graph representation of the plurality of payment instruments as the first nodes and the plurality of merchants 104 as the second nodes and relationships between the first nodes and the second nodes as edges.
[00153] At operation 806, the method 800 includes identifying, by the server system 200, common point of purchase (CPP) compromise merchants from the plurality of merchants 104 by calculating CPP compromise scores associated with the plurality of merchants 104. The CPP compromise scores are calculated by performing the plurality of iterations. An iteration of the plurality of iterations includes the following steps 806a-806c.
[00154] At operation 806a, during each iteration, the method 800 includes generating, by the server system 200, a sub-graph based, at least in part, on the base graph. The sub-graph represents a relationship graph of one or more payment instruments that are used at 'k' number of merchants.
[00155] At operation 806b, during each iteration, the method 800 includes determining, by the server system 200, blame scores assigned to a set of merchants involved in the sub-graph based, at least in part, on prior fraud probabilities associated with the set of merchants calculated in a previous iteration.
[00156] At operation 806c, during each iteration, the method 800 includes calculating, by the server system 200, posterior fraud probabilities at current iteration associated with the set of merchants based, at least in part, on the blame scores and the CPP model 226.
[00157] At operation 808, the method 800 includes determining, by the server system 200, the CPP compromise scores associated with the plurality of merchants 104 based, at least in part, on final posterior fraud probabilities of the plurality of merchants 104 at final iteration of the plurality of iterations.
[00158] The sequence of operations of the method 800 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[00159] FIG. 9 is a simplified block diagram of an acquirer server 900, in accordance with an embodiment of the present disclosure. The acquirer server 900 is an example of the acquirer server 114 of FIG. 1. The acquirer server 900 is associated with an acquirer bank/acquirer, in which a merchant (e.g., the merchant 104) may have an account, which provides a payment card. The acquirer server 900 includes a processing module 905 operatively coupled to a storage module 910 and a communication module 915. The components of the acquirer server 900 provided herein may not be exhaustive and the acquirer server 900 may include more or fewer components than those depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00160] The storage module 910 is configured to store machine-executable instructions to be accessed by the processing module 905. Additionally, the storage module 910 stores information related to, the contact information of the plurality of merchants 104, bank account number, availability of funds in the account, transaction details, and/or the like. Further, the storage module 910 is configured to store payment transactions.
[00161] In one embodiment, the acquirer server 900 is configured to store profile data (e.g., an account balance, a credit line, details of the plurality of merchants 104, account identification information, payment card number) in the database 116. The details of the plurality of merchants 104 may include, but are not limited to, name, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of each of the plurality of merchants 104 etc.
[00162] The processing module 905 is configured to communicate with one or more remote devices such as a remote device 920 using the communication module 915 over a network such as the network 110 of FIG. 1. The examples of the remote device 920 include the server system 106, the payment server 118, the transaction database 108 or other computing systems of the acquirer server 900 and the network 110, and the like. The communication module 915 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 915 is configured to receive a payment transaction request performed by the cardholders 102 via the network 110. The processing module 905 receives a payment card information, a payment transaction amount, customer information, and merchant information from the remote device 920 (i.e., the payment server 118). The acquirer server 900 includes a transaction database 930 for storing transaction data. The transaction data may include, but not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction. The acquirer server 900 includes a merchant profile database 925 storing merchant profiles associated with the plurality of merchants 104.
[00163] The merchant profile data may include details of each of the plurality of merchants 104 such as name, physical attributes, location, registered contact number, alternate contact number, registered e-mail address, and the like.
[00164] FIG. 10 is a simplified block diagram of a payment server 1000, in accordance with an embodiment of the present disclosure. The payment server 1000 is an example of the payment server 118 of FIG. 1. The payment server 1000 and the server system 106 of FIG. 1 may use the payment network 116 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
[00165] The payment server 1000 includes a processing system 1005 configured to extract programming instructions from a memory 1010 to provide various features of the present disclosure. The components of the payment server 1000 provided herein may not be exhaustive and that the payment server 1000 may include more or fewer components than that depicted in FIG. 10. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 1000 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00166] Via a communication interface 1015, the processing system 1005 receives a request from a remote device 1020, such as the acquirer server 114, a merchant device associated with the merchant, or a cardholder device hosting a payment gateway application. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 1000 includes a database 1025. The database 1025 also includes transaction processing data such as issuer ID, country code, acquirer ID, merchant identifier (MID), among others.
[00167] When the payment server 1000 receives a payment transaction request from the acquirer server 114 or the payment terminal, the payment server 1000 may route the payment transaction request to an issuer server (e.g., the issuer server 112 of FIG. 1). The database 1025 stores transaction identifiers for identifying transaction details such as transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like.
[00168] In one example embodiment, the acquirer server 114 is configured to send an authorization request message to the payment server 1000. The authorization request message includes, but is not limited to, the payment transaction request.
[00169] The processing system 1005 further sends the payment transaction request to the issuer server 112 for facilitating payment transactions from the remote device 1020. The processing system 1005 is further configured to notify the remote device 1020 of the transaction status in form of an authorization response message via the communication interface 1015. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 112. Alternatively, in one embodiment, the processing system 1005 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 1015, to the acquirer server 114.
[00170] Without limiting the scope of the present disclosure, the one or more example embodiments disclosed herein provide methods and systems for detecting common point of purchase (CPP) compromised merchants from a plurality of merchants. More specifically, historical payment transaction data associated with fraudulent payment transactions are accessed from a transaction database to define a base graph. Based on the base graph, a plurality of sub-graphs is generated in a plurality of iterations. During each iteration, blame scores are assigned to a set of merchants involved in the sub-graph based on prior fraud probabilities associated with the set of merchants calculated in a previous iteration. In addition, during each iteration, posterior fraud probabilities at the current iteration associated with the set of merchants are calculated based on the blame scores and a CPP model. Further, CPP compromise scores associated with the plurality of merchants are calculated based on final posterior fraud probabilities of the plurality of merchants at the final iteration of the plurality of iterations. The CPP compromised merchants are detected based on the CPP compromise scores.
[00171] The disclosed methods with reference to FIGS. 1 to 10, or one or more operations of the methods 700 and 800 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Webbook, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00172] Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the disclosure. For example, the various operations, blocks, etc. described herein may be enabled and operated using hardware circuitry (for example, complementary metal-oxide-semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00173] Particularly, the server system 200 (e.g., the server system 106) and its various components such as the computer system 202 and the database 204 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer-readable media include any type of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g., magneto-optical disks), CD-ROM (compact disc read-only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00174] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the scope of the invention.
[00175] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.