Method and system for evaluating merchant reputation

Abstract

The system and method can assess the merchant risk level on a more continuous metric scale rather than a binary classification. This can produce a continuous risk score that is proportional to the likelihood that the merchant is risky, effectively solving the gray-shade problem encountered by traditional blacklist methods. The continuous risk score feature provides greater flexibility because it allows the payment network to make dynamic pricing decisions (known as interchange optimization) based on the merchant risk level. Using collective intelligence from transactions across payment networks, the system and method can assess the merchant risk level with high accuracy. The system and method may be particularly beneficial for small merchants with lower transaction volumes because even a few fraudulent transactions can easily place them in the high-risk merchant category. In addition, the system and method can help payment processing networks make better decisions on cross-border transactions.

Description

Background Art

[0001] Payment fraud is a serious and growing problem for merchants, especially online retailers. Beyond the financial costs, fraud and / or chargebacks can damage a merchant's reputation and increase customer churn. Furthermore, excessive chargebacks can result in a merchant being placed on a watchlist called MATCH - MasterCard Alert to Control High-risk Merchants. Once a merchant is placed on MATCH, they may remain on the watchlist for up to five years. Being placed on MATCH can be severely damaging to a merchant. Not only does it occur after a merchant's account is terminated, but it can also serve to notify other acquiring banks that there are serious issues with the business. Consequently, being added to a watchlist often results in the end of a merchant's payment processing capabilities, as it can be extremely difficult for the merchant to find a new acquiring bank in any case.

[0002] Merchants may be aware of the consequences but lack the funds and resources to combat fraudulent transactions and / or chargebacks. Smaller merchants with lower transaction volumes are particularly at risk, as they lack access to a significant portion of transactions across payment networks to develop effective fraud detection solutions. Therefore, there is a need to develop dynamic and reliable systems that can accurately assess merchant risk levels. Summary of the Invention

[0003] A system and method are described that can assess adaptive risk scores and alert innocent merchants when they are attacked by illegal fraudsters or before they are placed on the MATCH watch list. The system and method may have the following contributions:

[0004] Near Real-Time: Detailed statistics on fraudulent and chargeback transaction percentages may not be immediately available to merchants, as the chargeback process can take one to six months to complete. Consequently, merchants are often unaware of chargebacks and fraud until their acquiring bank notifies them. Furthermore, given the temporal nature of fraudulent activity, previously low-risk merchants may become high-risk for a short period due to a burst of fraud attacks, then fall back to their normal levels of fraud and / or chargebacks. The proposed system and method can be dynamic, as it can assess merchant risk levels in near real time and provide early warning notifications to merchants.

[0005] Continuous vs. Discrete: The system and method improve upon the traditional approach of categorizing merchants into two groups: low-risk and high-risk. The proposed system and method assesses a continuous risk score proportional to the merchant's likelihood of being risky, effectively addressing the "grey shades" problem encountered in traditional blacklisting approaches. Continuous risk scoring provides payment processing networks with greater flexibility by allowing them to make dynamic pricing decisions (known as interchange optimization). For example, the network could decide to charge higher interchange fees to merchants whose transactions are riskier.

[0006] Reliability: The system and method can assess merchant risk levels based on the merchant's collective transaction behavior across the entire payment network. As a user transacts, each transaction from the user can be scored not only based on information associated with the current merchant, but also based on information associated with previous merchants. A merchant risk level can be derived by aggregating the risk scores of all transactions occurring at a particular merchant. Consequently, the resulting merchant risk level can be highly reliable, which can be particularly beneficial for smaller merchants with lower transaction volumes, as even a few fraudulent transactions can easily push them into the high-risk merchant category.

[0007] Furthermore, the system and method can help payment processing networks make better decisions about cross-border transactions. Merchants in some countries, such as China and Russia, are not obligated to report fraudulent transactions. Using collective intelligence from past user transactions at merchants that report fraud, the system and method can assess the risk level of merchants that do not report fraud.

[0008] Therefore, the system and method can assess the merchant risk level on a more continuous metric scale rather than a binary classification. This can produce a continuous risk score that is proportional to the likelihood that the merchant is risky, effectively solving the gray shade problem encountered by traditional blacklisting methods. The continuous risk score feature provides greater flexibility because it allows the payment network to make dynamic pricing decisions (known as interchange optimization) based on the merchant risk level. Using collective intelligence from transactions across payment networks, the system and method can assess the merchant risk level with high accuracy. The system and method may be particularly beneficial for small merchants with lower transaction volumes because even a few fraudulent transactions can easily place them in the high-risk merchant category. In addition, the system and method can help payment processing networks make better decisions for cross-border transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 This could be a diagram of the computers used in the system;

[0010] Figure 2 may be a diagram of a computing element that may be part of the system and that may perform the method;

[0011] Figure 3 which may be a flow chart of blocks performed by the method;

[0012] Figure 4 An example RNN model architecture may be shown;

[0013] Figure 5 Periodically aggregated hourly data sets may be shown;

[0014] Figure 6 An initial data set may be shown;

[0015] Figure 7A The rotation of the training set can be shown;

[0016] Figure 7B The rotation of the training set can be shown;

[0017] Figure 8 A point anomaly may be shown where a single spike 805 can be seen in the graph;

[0018] Figure 9 A score shift 905 (from low to high) followed by two spikes may be shown; and

[0019] Figure 10 A sudden jump in the risk score 1005 may be shown, with the score remaining high for a period of time.

[0020] Those skilled in the art will appreciate that the elements in the figures are shown for simplicity and clarity, and therefore not all connections and options are shown to avoid obscuring various aspects of the present invention. For example, common but well-understood elements that are useful or necessary in commercially viable embodiments are generally not depicted to facilitate unimpeded viewing of the various embodiments of the present disclosure. It will be further understood that certain actions and / or steps may be described or depicted in a particular order of occurrence, but those skilled in the art will understand that such specificity regarding order is not actually required. It will also be understood that the terms and expressions used herein are defined relative to their corresponding queries and research areas, unless a specific meaning has been otherwise set forth herein. DETAILED DESCRIPTION

[0021] The present disclosure will now be described more fully with reference to the accompanying drawings, which form a part of the present disclosure and illustrate specific exemplary embodiments by way of illustration, by which the present disclosure may be practiced. The presentation of these diagrams and exemplary embodiments should be understood as an example, and is not intended to be limited to any one of the embodiments shown. The present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; in fact, these embodiments are provided to make the present disclosure thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art. In addition, the present disclosure may be embodied as a method or apparatus. Therefore, the present disclosure may take the form of a fully hardware embodiment, a fully software embodiment, or an embodiment combining software and hardware aspects. Therefore, the following detailed description should not be taken in a limiting sense.

[0022] System 100 may include a computer network 102 linking one or more systems and computer components. In some embodiments, system 100 includes a user computing device 104, a merchant computer system 106, a payment network system 108, and a transaction analysis system 110.

[0023] The network 102 may be variously described as a communication link, a computer network, an Internet connection, etc. The system 100 may include various software or computer-executable instructions or components stored on tangible memory and dedicated hardware components or modules that employ the software and instructions in actual applications to manage network nodes for transactions, as described herein.

[0024] The various modules may be implemented as computer-readable storage devices containing computer-readable instructions (i.e., software) for execution by one or more processors of the system 100 within a dedicated or unique computing device. The modules may perform various tasks, steps, methods, blocks, etc., as described herein. The system 100 may also include both hardware and software applications, as well as various data communication channels for transmitting data between the various dedicated and unique hardware and software components.

[0025] It is generally believed that a network includes the interconnection and interoperability of hardware, data and other entities. A computer network or data network is a digital telecommunications network that allows nodes to share resources. In a computer network, computing devices use connections between nodes, such as data links, to exchange data with each other. For example, a hardware network may include clients, servers, and intermediate nodes (e.g., user computer system 104, merchant computer system 106, payment network system 108, and transaction analysis system 110) in a graph topology. In a similar manner, a data network may include data nodes in a graph topology, wherein each node includes relevant or linked information, software methods, and other data. Nodes such as mobile computing devices 104 may be managed to facilitate transactions with other nodes of the system (e.g., merchant computer system) based on data and instructions from various other nodes of the system 100.

[0026] It should be noted that the term "server" as used throughout this application generally refers to a computer, other device, program or its combination, which includes a processor and memory to process and respond to the request of a remote user / node across a communication network. The server sends its information to the request "client". As used herein, the term "client" generally refers to a computer, program, other device, user and / or its combination that can process and issue a request and obtain and process any response from a server through a communication or data network. The computer, other device, related data set, program or its combination that promotes, processes information and requests, and / or promotes the transmission of information from a source user to a destination user is generally referred to as a "node". The network is generally considered to promote the transmission of information from the source point to the destination. The node specifically responsible for promoting the transmission of information from the information source to the destination is generally referred to as a "router". Networks have many forms, such as local area networks (LANs), Pico networks, wide area networks (WANs), wireless networks (WLANs) and the like. For example, the Internet is generally considered to be the interconnection of numerous networks, so that remote clients and servers can access and interact with each other.

[0027] Mobile computing device 104 may include a smartphone 104 or other computing device capable of sending and receiving wireless digital communications. Mobile computing device 104 may include a processor 145, memory 146, and battery 147. Mobile computing device 104 may include an RFID tag 104A or other device capable of transmitting a radio signal including mobile computing device data, such as battery charge 107. Memory 146 of mobile computing device 104 may include various modules that include instructions that, when executed by processor 145, generally control the functionality of mobile computing device 104 and, more specifically, integrate the mobile computing device into system 100. For example, some modules may include an operating system 150A, a browser module 150B, a communication module 150C, and a wallet module 150D. Communication module 150C may include processor-executable instructions for sending and / or receiving signals from contactless components of the system. In some embodiments, communication module 150C may include an RFID receiver or instructions for implementing an RFID receiver. Wallet module 150D may also include payment device data 151. Payment device data 151 can securely identify the payment device 250 ( Figure 2 ) and the user's payment account information to facilitate transactions between the mobile computing device 104 and the merchant computer system 106. In some embodiments, the payment device data 151 can be tokenized so that only trusted partners can access the payment device data 151.

[0028] The merchant computer system 106 may include a computing device, such as a merchant server 129 including a processor 130 and a memory 132, the merchant server including components and instruction modules including processor-executable instructions to facilitate transactions with the mobile computing device 104 via other entities of the system 100. In some embodiments, the memory 132 may include a transaction communication module 134. The transaction communication module 134 may include instructions to send a merchant message 134A to other entities of the system 100 (i.e., 104, 108, 110) to generally indicate that a transaction has been initiated with the mobile computing device 104, and the wallet module 150D may include, among other things, payment account data, location data, and other data as described herein. For example, a node of the system 100 (e.g., mobile computing device 104 in general, and browser module 150B in particular) may access a merchant website to initiate a transaction. Some examples of transactions include the sale of tickets for specific seats at a venue.

[0029] The merchant computer system 106 may also include a transaction repository 142 and instructions for storing payment and other transaction data 142A in the transaction repository 142. The merchant computer system 106 may also include a product repository 143 and instructions for storing product and other data 143A in the product repository 143. In some embodiments, the merchant computer system 106 may also include instructions for storing a payment corresponding to the payment device 250 ( Figure 2 )'s payment device data 151, transaction data 143A and / or product data 143B, and other data received during the transaction, are sent from the mobile computing device 104 to the payment network system.

[0030] The payment network system 108 may include a payment server 156, which includes a processor 158 and memory 160. Memory 160 may include a payment network module 162, which includes instructions for facilitating payments between parties (e.g., one or more users, merchants, etc.) using the system 100. Module 162 may be communicatively connected to an account holder data repository 164, which includes payment network account data 164A. Payment network account data 164A may include any data used to facilitate payments and other funds transfers between system entities (e.g., 104, 106, and 110). For example, payment network account data 164A may include identification data, account history data, payment device data, etc. Module 162 may also include instructions for sending payment messages 166 to other entities and components of the system 100 to complete transactions between the mobile computing system 104 and the merchant computer system 106. For example, module 162 may include instructions for sending a payment message 166 to transaction analysis system 110 or other entity of system 100 to complete a purchase transaction. Message 166 may include data authorizing the purchase transaction, such as an authorization number or other identification, and may be tokenized or encrypted by system 100 before message 166 is sent to the system entity via network 102.

[0031] Transaction analysis system 110 can be used to provide real-time or near real-time analysis of merchant risk scores. Server 116 can have a memory for storing computer-executable instructions, which can physically configure processor 118 according to the computer-executable instructions. Transaction table 112 can store individual transactions 112A, 112B, 112C, and 112D for periodic or real-time analysis. Transaction data can be stored in databases 112 and 124, which can contain past entries 122A and 124A that can be used to analyze current transaction risk.

[0032] refer to Figure 2, an embodiment of a system and method for determining a merchant risk level in real time may be shown. As part of this determination, the entity 201 may be a user, a payment card, a merchant, a merchant category code (MCC), a merchant category group (MCG), or a zip code. Two types of entity profiles can be created in the current system—one based on domain knowledge and the other based on representation learning methods.

[0033] Domain knowledge

[0034] Typical entity profiles based on domain knowledge may include historical fraud rates, rejection rates, average amounts, etc. A typical example of such entity profiles - the distribution of fraud rates among different merchant category groups (MCGs) is shown below.

[0035]

[0036] Learning Profile

[0037] Representation learning-based profiles can include user embeddings and merchant embeddings. An embedding can be a representation of a topological object, manifold, graph, field, or the like in a space, such that its connectivity or algebraic properties are preserved. User embeddings can be created by first collecting all user-merchant pairs in the transaction data and then grouping these pairs by merchant. For each unique merchant, a list of all transactions and corresponding users can be found. Users can then be chronologically sorted based on transaction time. Each user in a sequence can be considered a "word," and the entire sequence can be considered a "sentence." By repeating the same process across all active merchants, a corpus of millions of sentences can be created. Word2vec or similar algorithms can be used to generate an embedding for each user. Similarly, merchant embeddings can be created by first collecting all user-merchant pairs in the transaction data and then grouping these pairs by user. Each user embedding can be a float vector of size 200, while each merchant embedding can be a float vector of size 400. The number of dimensions of each embedding representation can be chosen to be both efficient and effective for the task at hand. Both domain knowledge-based entity profiles and representation learning-based entity profiles can be updated periodically.

[0038] Transaction risk model

[0039] The transaction risk model 202 can be trained offline in a supervised manner using a combination of entity profiles and non-aggregated transaction-specific features (e.g., location, time, amount, etc.) as features, and using refund / fraud information as labels. The output of the model can be the probability that the transaction is fraudulent.

[0040] The probability can be converted into a risk score value between 1 and 100, where a higher score indicates a high-risk transaction and a lower score indicates a low-risk transaction. To score each transaction, the proposed system can use various models. Two models that can be used as a combination include (i) a gradient boosting machine (GBM) and (ii) a recurrent neural network (RNN) including two long short-term memory (LSTM) layers.

[0041] At a high level, machine learning can be used to score transactions over time, allowing past scores to be analyzed in light of perceived fraud to better determine the most appropriate score in the future. In some embodiments, the scores can be optimized over time. Machine learning can be used to analyze past scores using credit against actual outcomes for a user or entity. Machine learning can be used to review a training set of past scoring data and determine moving forward weighting.

[0042] Figure 6 A sample of artificial intelligence (AI) training data according to one or more embodiments may be shown. By way of example and not limitation, an artificial intelligence system may be trained by analyzing a set of training data 605. The training data may be broken down into sets, such as set A 610, set B 615, set C 620, and set D 625. As shown in FIG7a , one set may be used as a test set (e.g., set D 625), and the remaining sets may be used as training sets (set A 610, set B 615, and set C 620). The artificial intelligence system may analyze the training sets (set A 610, set B 615, and set C 620) and use the test set (set D 625) to test a model created from the training data. The data sets may then be shifted, as shown in FIG7b , where a test data set may be added to the training data set (e.g., set A 610, set B 615, and set D 625), and one of the training data sets that has not been used for testing (e.g., set C 620) may be used as the test data set. The analysis of the training data (set A 610, set B 615, and set D 625) can occur again with a new test set (set C 620) used to test the model, and the model can be optimized. The rotation of the data set can be repeated until all data sets have been used as test data sets. The model can then be considered complete and the model can then be used for additional data sets.

[0043] The RNN model architecture can be Figure 4. LSTM 405 can process a sequence of transactions for one cardholder at a time and can maintain a cell state vector c(t) 410 and a hidden state vector h(t) 415, which can act as a memory of past transaction behavior. The cell state vector c(t,) 410 can store information for a longer period of time, while the hidden state vector h(t) 415 can store information for a shorter period of time. At each time step, LSTM 405 can reset, modify, or mask the two state vectors 410415 using a built-in gating mechanism. The two state vectors c(t) 410 and h(t) 415 at any time step t can be concatenated 420 into {c(t), h(t)}, which can then be updated based on the previous state vectors c(t-1), h(t-1) and the current input vector x(t):

[0044] (c(t),h(t))=LSTM(c(t-1),h(t-1),x(t)) (Equation 1)

[0045] In Equation 1, the current input vector x(t) may consist of an entity profile created from transaction logs.

[0046] The prediction from the deep recurrent neural network model can be obtained by the following equation

[0047]

[0048] Where W and b are learnable parameter arrays. This can serve as a risk score indicating whether a transaction is high risk. The final risk score from the transaction can be a weighted average of the scores obtained from the GBM model and the RNN model. The following figure can present the performance curves of the GBM model, the RNN model, and the combined model.

[0049]

[0050] The combination of the two models can produce significant performance improvements. The values ​​in brackets report the area under the curve (AUC) score of the corresponding model. The higher the AUC value, the better the performance of the model.

[0051] Merchant risk model

[0052] The transaction risk model 202 introduced in the previous session can be used to score the transaction using the transaction scoring engine 206 ( Figure 2 ) generates a risk score for each transaction that occurs at the merchant. The merchant risk model 203 can then aggregate the transaction risk scores corresponding to the merchant and can use the merchant risk score engine 207 ( Figure 2 ) to obtain a merchant risk score in the range of 1-100. A higher score may indicate a high-risk merchant, and a lower score may indicate a low-risk merchant. Logically, the score can be adjusted to reflect the needs of the user.

[0053] The system and method can attribute risk scores to merchants in near real time, but if necessary, it may take approximately 1 day for an investigative team to review a merchant that exhibits unusual behavior. Figure 5 As shown in , the proposed system can aggregate risk scores on an hourly basis, for example, hour 1 (505), hour 2 (510) to hour 24 (515), by storing hourly transactions in data buckets, such as data bucket 1 (525) for hour 1 (505), data bucket 2 (530) for hour 2 (510), and data bucket 24 (535) for hour 24 (515), and taking the average of the risk scores for the transactions that occurred within that hour. The system can then compile the aggregated risk scores in a daily data bucket (540) at the end of each day to generate a merchant risk score (550).

[0054] Anomaly detection algorithm 208 in anomaly analysis model 204 ( Figure 2 ) can update the merchant risk scores to generate a list of suspicious merchants for review. Anomaly detection algorithm 208 can take many forms. In one embodiment, the algorithm can simply look for merchant risk scores that exceed a threshold. In another embodiment, the algorithm can highlight merchant risk scores that have changed more than expected over a certain time period, such as from one day to the next. In yet another embodiment, the algorithm can highlight merchant risk scores that have experienced the largest percentage change over a period of time. Of course, all or some of the different measures described can be part of a single algorithm and can be given different weights to determine which merchants the merchant profile manager 209 may need to take a closer look at.

[0055] Abnormal Analysis Model 204

[0056] One contribution of the proposed solution can be the near real-time anomaly detection capability for millions of merchants in the payment network. The daily aggregated merchant risk score can be viewed as a time series as shown below.

[0057]

[0058] For daily aggregated merchant risk scores, the anomaly analysis model 204 may utilize a recursive exponential filter to identify abnormal merchant behavior. The recursive exponential filter, which may be similar to the well-known Kalman filter, eliminates the need to store and reprocess past transaction records each time a risk score needs to be updated. The following example illustrates a series of pairs {s1, t1}, {s2, t2}, ..., {s n , t n}, {s n+1 , t n+1}, where si is time t i The merchant risk score at that time.

[0059] Assume {s i , t i} represents a series of pairs, where s i For the tth i The daily aggregated merchant risk score for day t. n The merchant risk level for a day can be defined as the running average y n , which can then be given by the following equation

[0060]

[0061] where T is a decay parameter that controls how quickly the model may forget its past history. n+1 After the next daily merchant risk score observation at time , the merchant risk level y n+1 It can be calculated as follows

[0062]

[0063] With slight manipulation of Equations 3 and 4, the systems and methods can express y using the following recursive formula: n+1 :

[0064] yn +1 =y n +K n+1 (s n+1 -y n ) (Equation 5)

[0065] where K n+1 Recursive formula conversion is also possible:

[0066]

[0067] Merchant risk level y n+1 with y n Significant deviations from s may indicate an anomaly. It is important to note that it may not be necessary to store the entire history of merchant risk scores. Instead, it may only be necessary to store the previous risk score s n , Previous merchant risk level y n and K n .

[0068] Figure 8 、 Figure 9 and Figure 10 Three examples of merchants exhibiting unusual behavior are presented. The first example ( Figure 8 ) may illustrate a point anomaly where a single spike 805 may be seen in the graph.

[0069] Second Example ( Figure 9 ) may show a score shift 905 (from low to high) followed by two spikes.

[0070] The third example ( Figure 10 ) may show a sudden jump in the risk score 1005, and the score remains high for a period of time.

[0071] How to evaluate new merchants?

[0072] In production, a "peer group" risk score may be maintained. A peer group may be a collection of merchants that offer similar goods or services. For example, all restaurants may belong to the same peer group. There may be a one-to-one mapping between merchant category codes (MCCs) and peer groups. There may be approximately 750 MCC codes in traditional transaction data, which may correspond to approximately 750 peer groups. In the system, the approximately 750 MCC groups may be further categorized into 22 merchant category groups (MCGs). For example, a restaurant MCC (5812) and a fast food restaurant MCC (5814) may be assigned the same MCG (10). The hierarchical classification of merchants of different granularity ensures that peer groups can be generated with robust statistics. If a merchant category code (MCC) has a small number of transactions, the system and method may move up a level to use a merchant category group (MCG). Similar to calculating a merchant risk score, all transaction risk scores in a peer group may be aggregated on an hourly basis, and the aggregated risk scores may be compiled at the end of each day to generate a peer group risk score. Peer group analysis may help assess the risk of new merchants with shorter historical data.

[0073] A computer-implemented method for determining a merchant's risk level in real time may be found at Figure 3 As shown in FIG. At block 200 , a transaction risk score may be calculated for each transaction occurring at a merchant during hour h, where h is a value between 1 and 24. The transaction risk model 202 may be trained offline in a supervised manner using a combination of entity profiles and non-aggregated transaction-specific features (e.g., location, time, amount, etc.) as features, and refund / fraud information as labels. The output of the model may be a probability that a transaction is fraudulent.

[0074] The probability can be converted into a risk score value between 1 and 100, where a higher score indicates a high-risk transaction and a lower score indicates a low-risk transaction. To score each transaction, the proposed system can use various models. Two models that can be used as a combination include (i) a gradient boosting machine (GBM) and (ii) a recurrent neural network (RNN) including two long short-term memory (LSTM) layers.

[0075] At block 210, the transaction risk scores for each transaction occurring at the merchant during hour h may be aggregated to obtain a value such as Figure 5The merchant risk score m for the merchant during the hour h shown in h At block 220 , the calculating and summarizing steps may be repeated for each hour h.

[0076] At block 230, a merchant risk score m may be compiled h (535, 530, 525)(540) to calculate the daily merchant risk score s i (550). The merchant risk model 203 may then aggregate the transaction risk scores corresponding to the merchant and may use the merchant risk score engine 207 ( Figure 2 ) to obtain a merchant risk score in the range of 1-100. A higher score may indicate a high-risk merchant, and a lower score may indicate a low-risk merchant. Logically, the score can be adjusted to reflect the needs of the user. In some embodiments, the transaction risk score can be averaged for all transactions occurring during the hour h.

[0077] At block 240, the daily merchant risk score s i (550) is provided to the merchant. In response, the merchant can see almost immediately when the merchant's risk score is approaching an alert level. In some embodiments, the systems and methods can identify the source of the change in the merchant's risk score. For example, if a certain card is causing a problem, the merchant can try to find that card. In other embodiments, purchases during certain time periods may be problematic, and the merchant can take additional risk reduction steps during those time periods. In yet another embodiment, the merchant can be notified that the sale of certain items has been identified as risky, and the merchant can adjust the sale of those items.

[0078] As can be seen, the system and method solve the technical problem of how to check merchant rating scores in a computationally efficient manner. In the past, checking merchant ratings in a timely manner was not even possible. In theory, a user might have made daily requests for updates, which may or may not have been responded to because providing the daily updates simply wasn't complete at the current time. Logically, merchant aggregation wasn't complete at the current time either. At the very least, the system and method enable several new capabilities previously unavailable using any computer system.

[0079] In some further embodiments, the method may further determine a peer group of the merchant, wherein the peer group includes one or more peer merchants that provide similar goods or services to the merchant. A transaction risk score may be calculated for each transaction occurring at the peer group during hour h, where h is 1 to 24. The transaction risk scores of each transaction occurring at the peer group during hour h may be aggregated to obtain a peer group risk score p for the peer group. h The calculation and aggregation steps may be repeated for each hour h. The peer group scores p may be compiled hTo calculate the daily peer group risk score p i The daily peer group risk score p i and daily merchant risk scores i Comparisons are made to better determine the transaction risk level of an individual merchant in light of a world of similar merchants.

[0080] In some embodiments, an anomaly detection algorithm may be used to determine a daily merchant risk score s i Is there an anomaly in t? If an anomaly is detected, the merchant can be added to the list. The anomaly detection algorithm may include n Determine the first merchant risk level, where

[0081] First merchant risk level y n is the running average of the merchant’s daily risk score si, where the first merchant’s risk level y n Calculated as follows

[0082]

[0083] And where T is the decay parameter, and i is 1 to n.

[0084] The time t can be determined n+1 The second merchant risk level at the time, where the second merchant risk level y n+1 Calculated as follows,

[0085]

[0086] The first merchant risk level y n With the second merchant risk level y n+1 If the first merchant's risk level is y n With the second merchant risk level y n+1 If the difference between them is higher than the threshold, an anomaly can be identified.

[0087] As previously mentioned, machine learning can be used to determine whether a transaction is likely fraudulent. A first entity profile can be created using a first dataset. A second entity profile can be created using a second dataset, where the second entity profile is created using the first entity profile, and a third dataset containing transaction data can be trained using the second entity profile to determine the probability that the transaction is fraudulent. The probability that the transaction is fraudulent can be converted into a transaction risk score. The second entity profile can include a user embedding and a merchant embedding, and the first entity profile can include one or more of a historical fraud rate, a transaction rejection rate, and an average transaction amount. For example, the transaction risk score can be any value from 1 to 100. Logically, a high transaction risk score can indicate a high-risk transaction, and a low transaction risk score can indicate a low-risk transaction.

[0088] System 400 may include, but is not limited to, any combination of LAN, MAN, WAN, mobile network, wired or wireless network, private network or virtual private network. Figure 1 Only one remote computing device 104 is shown in order to simplify and clarify the description, but it is understood that any number of client computers are supported and can communicate within the system 100.

[0089] In addition, certain embodiments are described herein as including a logic or number of components, modules, blocks, or mechanisms. Modules and method blocks may constitute software modules (e.g., code or instructions embodied on a machine-readable medium or in a transmission signal, where the code is executed by a processor) or hardware modules. A hardware module is a tangible unit that is capable of performing certain operations and can be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., stand-alone client or server computer systems) or one or more hardware modules (e.g., a processor or group of processors) of a computer system may be configured by software (e.g., an application or portion of an application) as a hardware module that operates to perform certain operations as described herein.

[0090] In various embodiments, a hardware module can be implemented mechanically or electronically. For example, a hardware module may include dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA)) or an application specific integrated circuit (ASIC) to perform certain operations. A hardware module may also include programmable logic or circuitry (e.g., as contained within a processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in a dedicated and permanently configured circuitry, or in a temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0091] Thus, the term "hardware module" should be understood to encompass a tangible entity, an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) so as to operate in a certain manner or perform certain operations described herein. As used herein, a "hardware-implemented module" refers to a hardware module. Contemplating embodiments in which hardware modules are temporarily configured (e.g., programmed), it is not necessary to configure or instantiate each of the hardware modules at any one time. For example, where a hardware module includes a processor configured by software, the processor can be configured as corresponding different hardware modules at different times. The software can thus configure the processor, for example, to constitute a particular hardware module at one time and to constitute a different hardware module at a different time.

[0092] A hardware module can provide information to other hardware modules and receive information from other hardware modules. Therefore, the described hardware modules can be considered to be coupled in a communication manner. When multiple such hardware modules exist simultaneously, communication can be achieved by transmitting signals (e.g., via suitable circuits and buses) connected to the hardware modules. In an embodiment where multiple hardware modules are configured or initialized at different times, communication between these hardware modules can be achieved by, for example, storing and retrieving information in a memory structure accessible to multiple hardware modules. For example, a hardware module can perform an operation and store the output of the operation in a memory device, and the hardware module is coupled to the memory device in a communication manner. Then, another hardware module can subsequently access the memory device to retrieve and process the stored output. The hardware module can also initiate communication with an input or output device and can operate on a resource (e.g., a collection of information).

[0093] The various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Regardless of whether the configuration is temporary or permanent, the processors may constitute processor-implemented modules that operate to perform one or more operations or functions. In some example embodiments, the modules mentioned herein may include processor-implemented modules.

[0094] Similarly, the methods or routines described herein can be processor-implemented at least in part. For example, at least some of the operations of the method can be performed by one or more processors or a hardware module implemented by the processor. The performance of certain operations can be distributed among one or more processors, not only residing in a single machine, but also across multiple machine deployments. In some example embodiments, one or more processors can be located in a single location (e.g., in a home environment, an office environment, or a server farm), while in other embodiments, the processor can be distributed across multiple locations.

[0095] The one or more processors may also be operable to support the performance of related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some operations may be performed by a group of computers (as instances of machines including the processors), which may be accessed via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs)).

[0096] The performance of certain operations can be distributed among one or more processors, not only residing within a single machine, but also deployed across multiple machines. In some example embodiments, one or more processors or processor-implemented modules can be located in a single geographic location (e.g., in a home environment, an office environment, or a server farm). In other example embodiments, one or more processors or processor-implemented modules can be distributed across multiple geographic locations.

[0097] Some parts of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals in machine memory (e.g., computer memory). These algorithms or symbolic representations are examples of techniques used by those skilled in the art of data processing to convey the substance of their work to other persons skilled in the art. As used herein, an "algorithm" is a self-consistent sequence of operations or similar processes that produce a desired result. In this context, algorithms and operations involve the physical manipulation of physical quantities. Typically, but not necessarily, such quantities can be in the form of electrical, magnetic, or optical signals that can be stored, accessed, transmitted, combined, compared, or otherwise controlled by a machine. Mainly for commonly used reasons, it is sometimes convenient to refer to such signals using words such as "data," "content," "bit," "value," "element," "symbol," "character," "item," "number," "digit," etc. However, these words are merely convenient labels and will be associated with appropriate physical quantities.

[0098] Unless specifically stated otherwise, discussions herein using words such as "process," "calculate," "compute," "determine," "present," "display," etc. may refer to the actions or processes of a machine (e.g., a computer) that controls or transforms data represented as physical (e.g., electrical, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0099] As used herein, any reference to "an embodiment," "some embodiments," "an embodiment," or "teachings" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrases "in some embodiments" or "teachings" in different places in the specification are not necessarily all referring to the same embodiment.

[0100] The expressions "coupled" and "connected," as well as their derivatives, may be used to describe some embodiments. For example, the term "coupled" may be used to describe some embodiments to indicate that two or more elements are in direct physical or electrical contact. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other. The embodiments are not limited in this context.

[0101] Furthermore, the drawings depict the preferred embodiment for illustrative purposes only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods shown herein may be employed without departing from the principles described herein.

[0102] After reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for the systems and methods described herein using the principles disclosed herein. Thus, while specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise configurations and components disclosed herein. It will be apparent to those skilled in the art that various modifications, changes, and variations may be made to the arrangement, operation, and details of the systems and methods disclosed herein without departing from the spirit and scope of any of the appended claims.

Claims

1. A computer-implemented method for determining a merchant risk level in real time, the method comprising: Calculate hours using the trading risk model of the trading analysis system h The transaction risk score for each transaction that occurred at the merchant during the period, where h is 1 to 24, wherein the transaction risk score is a continuous score, and wherein the transaction risk model comprises at least one of a gradient boosting machine model or a recurrent neural network model; Aggregate hours h The transaction risk score for each transaction occurring at the merchant during the period to obtain the transaction risk score for each hour h Merchant risk score for the merchant mentioned during the period m h ; For each hour h Repeating the calculating step and the summarizing step; Compiling the merchant risk score m h To calculate daily merchant risk score s i ; The daily merchant risk score s i Provided to the merchant.

2. The method according to claim 1, wherein the hours are aggregated h The step of calculating the transaction risk score for each transaction occurring at the merchant during the period further comprises calculating the hour h The average of the transaction risk scores of all transactions that occurred during the period.

3. The method according to claim 1, further comprising: determining a peer group for the merchant, wherein the peer group includes one or more peer merchants that offer similar goods or services to the merchant; Calculate hours h The transaction risk score for each transaction that occurred at the peer group during the period, where h From 1 to 24; Aggregate hours h The transaction risk score of each transaction occurring at the peer group during the period to obtain a peer group risk score for the peer group p h ; For each hour h Repeating the calculating step and the summarizing step; Compile the peer group scores p h To calculate daily peer group risk score p i ; as well as, The daily peer group risk score p i Daily Merchant Risk Score s i Make a comparison.

4. The method according to claim 1, further comprising: An anomaly detection algorithm is used to determine the daily merchant risk score s i Is there any abnormality in the as well as, If an anomaly is detected, the merchant is added to the list.

5. The method of claim 4, wherein the anomaly detection algorithm comprises: In time t n Determine a first merchant risk level, wherein the first merchant risk level y n Daily risk score for the merchant s i The running average of the first merchant risk level y n Calculated as follows, in T is the decay parameter and i 1 to n , In time t n＋1 Determine a second merchant risk level, wherein the second merchant risk level y n＋1 Calculated as follows, The first merchant risk level y n With the second merchant risk level y n＋1 For comparison, If the first merchant risk level y n With the second merchant risk level y n＋1 If the difference between them is higher than the threshold, an anomaly is identified.

6. The method according to claim 1, further comprising: Create the first entity profile using the first dataset A second entity profile is created using the second data set, wherein the second entity profile is created training a third dataset containing transaction data using the first entity profile and the second entity profile to determine a probability that a transaction is fraudulent; The probability that the transaction is fraudulent is converted into a transaction risk score. The method according to claim 6 , wherein the transaction risk score is any one of 1 to 100.

8. The method of claim 7, wherein a high transaction risk score indicates a high-risk transaction, and a low transaction risk score indicates a low-risk transaction.

9. The method of claim 6, wherein the first entity profile includes one or more of historical fraud rates, transaction decline rates, and average dollar amounts.

10. The method of claim 6, wherein the second entity profile includes a user embedding and a merchant embedding.

11. A computer system comprising input-output circuitry, a memory for storing computer-executable instructions, and a processor physically configured according to the computer-executable instructions, the computer-executable instructions implementing a method for determining a merchant risk level in real time, the method comprising computer-executable blocks for: Calculate the hours using the transaction risk model in the memory h The transaction risk score for each transaction that occurred at the merchant during the period, where h is 1 to 24, wherein the transaction risk score is a continuous score, and wherein the transaction risk model comprises at least one of a gradient boosting machine model or a recurrent neural network model; Aggregate hours h The transaction risk score for each transaction occurring at the merchant during the period to obtain the transaction risk score for each hour h Merchant risk score for the merchant mentioned during the period m h ; For each hour h Repeating the calculating step and the summarizing step; Compiling the merchant risk score m h To calculate daily merchant risk score s i ; as well as, The daily merchant risk score s i Provided to the merchant.

12. The computer system of claim 11, wherein the aggregated hours h The step of calculating the transaction risk score for each transaction occurring at the merchant during the period further comprises calculating the hour h The average of the transaction risk scores of all transactions that occurred during the period.

13. The computer system of claim 11 , further comprising computer executable instructions for: determining a peer group for the merchant, wherein the peer group includes one or more peer merchants that offer similar goods or services to the merchant; Calculate hours h The transaction risk score for each transaction that occurred at the peer group during the period, where h From 1 to 24; Aggregate hours h The transaction risk score of each transaction occurring at the peer group during the period to obtain a peer group risk score for the peer group p h ; For each hour h Repeating the calculating step and the summarizing step; Compile the peer group scores p h To calculate daily peer group risk score p i ; as well as, The daily peer group risk score p i Daily Merchant Risk Score s i Make a comparison.

14. The computer system of claim 11 , further comprising computer executable instructions for: An anomaly detection algorithm is used to determine the daily merchant risk score s i Whether there are any anomalies in the If an anomaly is detected, the merchant is added to the list.

15. The computer system of claim 14, wherein the anomaly detection algorithm comprises computer-executable steps for: In time t n Determine a first merchant risk level, wherein the first merchant risk level y n Daily risk score for the merchant s i The running average of the first merchant risk level y n Calculated as follows, in T is the decay parameter and i 1 to n , In time t n＋1 Determine a second merchant risk level, wherein the second merchant risk level y n＋1 Calculated as follows, The first merchant risk level y n With the second merchant risk level y n＋1 For comparison, If the first merchant risk level y n With the second merchant risk level y n＋1 If the difference between them is higher than the threshold, an anomaly is identified.

16. The computer system of claim 11, further comprising computer executable instructions for: creating a first entity profile using the first data set; creating a second entity profile using the second data set, wherein the second entity profile is created; training a third dataset containing transaction data using the first entity profile and the second entity profile to determine a probability that a transaction is fraudulent; The probability that the transaction is fraudulent is converted into a transaction risk score.

17. The computer system of claim 16, wherein the transaction risk score is any one of 1 to 100.

18. The computer system of claim 17, wherein a high transaction risk score indicates a high risk transaction and a low transaction risk score indicates a low risk transaction.

19. The computer system of claim 16, wherein the first entity profile includes one or more of a historical fraud rate, a transaction decline rate, and an average dollar amount.

20. The computer system of claim 16, wherein the second entity profile comprises a user embedding and a merchant embedding.

Images