DESC:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR FRAUD DETECTION BASED ON TEMPORAL TRANSACTION SEQUENCES BETWEEN CARDHOLDERS AND MERCHANTS

APPLICANT(S):

Name:

Nationality:

Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

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

PREAMBLE TO THE DESCRIPTION

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

DESCRIPTION
(See next page)

METHODS AND SYSTEMS FOR FRAUD DETECTION BASED ON TEMPORAL TRANSACTION SEQUENCES BETWEEN CARDHOLDERS AND MERCHANTS

TECHNICAL FIELD
The present disclosure relates to artificial intelligence processing systems and, more particularly to, electronic methods and complex processing systems for detecting fraudulent payment transactions between merchants and cardholders based on approaches of natural language processing methods.

BACKGROUND
Nowadays, many consumers use several banking cards/payment cards, such as credit cards, debit cards, prepaid cards, etc., for performing financial transactions (e.g., payment transactions). Online purchases done using credit or debit cards are referred to as Card Not Present (CNP) transactions. The scale of cyber threats has grown by leaps and bounds as the digital payment ecosystem is evolving rapidly. A fraud score is an informational tool that helps gauge the risk involved with transactions before processing. This is done by identifying traits and historical trends associated with suspicious behavior and fraudulent transactions. This process is commonly used to detect fraud in the transactions to avoid losses. With so much at stake and so many variables changing, it’s vital to have a real-time monitoring system for fraud detection. Over the last few years, the payment industry has been increasingly focused on protecting payments and combating fraud, which is why striking the right balance in approving transactions and managing fraud is important.
The Power of Artificial Intelligence (AI) is utilized to analyze over a thousand of transactions every minute, analyze behavioral history at a customer level and use a large amount of historical fraud data to arrive at a score, also known as a fraud risk score. The fraud risk score then enables the card issuer to apply the intelligence to the next transaction. The fraud risk score also helps financial institutions increase the accuracy of real-time approvals of genuine transactions and reduce false declines, thereby improving the customer experience. The technology behind fraud risk determination examines how a specific account is used over time to detect normal and abnormal shopping spending behaviors. In doing so, it leverages account information like customer value segmentation, risk profiling, location, merchant, device data, time of the day, and type of purchase made. Current fraud risk scoring products are primarily focused on risk assessment, working within predefined rules. Fraud detection frameworks were traditionally designed as expert
systems which relied on a large set of rules stored in a knowledge base and have served the industry with high precision and business interpretability. However, due to frequent rule updates and unmanageable growth in the number of rules required to capture sophisticated fraud patterns, the payment industry has moved to data-driven methods such as statistical and machine learning models. Further, existing machine learning models do not learn the entity interaction explicitly and latent representation learned in some of the methods may be sub-optimal.
Thus, there is a need for a technical solution for improving the fraud risk score in order to improve the accuracy of real-time approvals of genuine transactions and reduce false declines through the use of artificial intelligence and deep learning techniques that provide cross-entity interaction learning.

SUMMARY
Various embodiments of the present disclosure provide methods and systems for detecting fraudulent payment transactions between merchants and cardholders based on approaches of natural language processing methods.
In an aspect, a computer-implemented method is disclosed. The method includes accessing, by a server system, information of historical payment transactions associated with a plurality of cardholders performed at a plurality of merchants within a particular time interval from a transaction database. The method includes determining, by the server system, temporal cardholder transaction sequences associated with the plurality of cardholders and temporal merchant transaction sequences associated with the plurality of merchants based, at least in part, on information of the historical payment transactions, and generating, by the server system, cross-entity transaction sequences based, at least in part, on the temporal cardholder transaction sequences and the temporal merchant transaction sequences. The method includes determining, by the server system, cardholder embeddings associated with the plurality of cardholders and merchant embeddings associated with the plurality of merchants based, at least in part, on the cross-entity transaction sequences and an entity representation learning model and generating, by the server system via an autoencoder, combined transaction embeddings based, at least in part, on the cardholder embeddings and the merchant embeddings. The method further includes training, by the server system, a fraud risk prediction model based, at least in part, on the combined transaction embeddings, the fraud risk prediction model trained to predict fraudulent payment transactions.
Other aspects and example embodiments are provided in the drawings and the detailed description that follows.

BRIEF DESCRIPTION OF THE FIGURES
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:
FIG. 1 is an example representation of an environment, related to at least some example embodiments of the present disclosure;
FIG. 2 is a simplified block diagram of a server system, in accordance with one embodiment of the present disclosure;
FIG. 3 is a schematic representation of a data flow among different modules of the processor, in accordance with an embodiment of the present disclosure;
FIG. 4 is a block diagram representation of the generation of cardholder embeddings and merchant embeddings, in accordance with an embodiment of the present disclosure;
FIG. 5 is a schematic block diagram representation of a process of generating cardholder embedding tables, in accordance with an embodiment of the present disclosure;
FIG. 6 is a process flow for training a fraud risk prediction model based on representation learning of intents of cardholders and merchants from temporal transaction sequences, in accordance with an embodiment of the present disclosure;
FIG. 7 is a block diagram representation of the generation of cardholder and merchant embeddings and training a fraud risk prediction model based on a combined transaction embedding, is shown, in accordance with an embodiment of the present disclosure;
FIG. 8 is a process flow chart of a method for training a fraud risk prediction model, in accordance with an embodiment of the present disclosure; and
FIG. 9 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
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
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.
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 is 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.
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.
The term "payment instrument", used throughout the description, refers to a paper-based or electronic payment means or other payment means used to initiate the transfer of funds. Example of the payment instruments includes payment accounts, payment cards / cards (such as, debit card, credit card, etc.), digital payment cards, e-wallets, etc.
The term "payment network", used throughout the description, refers to a network or collection of systems used for the transfer of funds through the 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®.
The terms "account holder", "user", “cardholder”, and "customer" are used interchangeably throughout the description and refer to a person who has a payment account or a payment card (e.g., credit card, debit card, etc.) associated with the payment account, that will be used by a merchant to perform a payment transaction. The payment account may be opened via an issuing bank or an issuer server.
The term "issuer", used throughout the description, refers to a financial institution normally called as an "issuer bank" or "issuing bank" in which an individual or an institution may have an account. The issuer also issues a payment card, such as a credit card or a debit card, etc. Further, the issuer may also facilitate online banking services such as electronic money transfer, bill payment, etc., to the account holders through a server system called as "issuer server" throughout the description.
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 either in online or offline manner, and it can refer to either a single business location, or a chain of business locations of the same entity.
The term "acquirer", used throughout the description, refers to a financial institution that is part of the financial payment system and normally called as a “merchant bank” or the “acquiring bank” or “acquirer bank” or simply “acquirer” in which the merchant first establishes an account to accept the payment. The acquirer may also facilitate online services such as electronic money transfer to the account holders i.e., merchants through a server system called as "acquirer server" throughout the description.
The term "embeddings", used throughout the description, generally, refers to a low-dimension translation of a high-dimension vector. More specifically, the embedding space is a relatively low-dimensional space into which a high-dimensional vector can be translated. Embeddings further make it easier to perform machine learning related tasks on large inputs.
OVERVIEW
Various example embodiments of the present disclosure provide methods, systems, user devices, and computer program products for improving fraud risk scores of a payment transaction in order to identify genuine transaction patterns from fraudulent ones, leading to a significant drop in fraud losses and improvements in customer experience.
Conventional fraud risk scoring models uses transaction attributes as features and model fraud detection as a binary classification problem. As the fraud event rate is very low, binary classification models suffer due to severe class imbalance. Anomaly detection based models overcome this problem but have their limitations in terms of high false-positive rate. Further, the sophistication of emerging fraud behavior is generally too
complex to be described using only transaction attributes. Although, deep learning methods have shown promising results in capturing complex transaction attributes’ interactions, resulting in more accurate and precise payment fraud detection models. However, one consistent concern with most existing methodologies is that the feature set describing a card’s transaction does not consider the historical purchase and selling pattern of the involved entities (merchant and cardholder).
To overcome above technical limitations, the present disclosure describes an intent learning model that semantically captures the intent of a transaction by learning from prior sequence of transactions, enabling us to discern plausible merchants for a card. In case, the representation of the next transaction doesn’t match the collective intent
of involved entities, that transaction could be a fraud. The present disclosure utilizes an natual language processing (NLP) approach using skip-gram model on sentences of cards and merchants, based on their interaction with each other, to learn embeddings. These learned semantic representations, when used as features in modeling fraud detection on transactions, outperform all baseline fraud detection models.
To guarantee responses for real-time fraud prediction requests, a low latency system is crucial. Due to the drift in behavior of cards and merchants over time, there’s also a need for using new transaction data to update the embeddings. The present disclosure proposes a 2 part deployable solution: 1) periodic offline training and 2) online real-time prediction. The periodic offline training recreates static card and merchant embeddings using new transactions, and then uploaded online, which along with transaction attributes, are used for real-time fraud prediction.
In one embodiment, the present disclosure describes a server system that is configured to implement an intent learning model for detecting fraudulent payment transactions. In one embodiment, the server system includes at least a processor and a memory. In one non-limiting example, the server system is a payment server associated with a payment network. Initially, the server system is configured to access information of historical payment transactions associated with a plurality of cardholders performed at a plurality of merchants within a particular time interval from a transaction database. The information of the historical payment transactions includes a series of payment transactions associated with cardholders and merchants associated with a particular geo-graphical location. The server system is configured to determine temporal cardholder transaction sequences associated with the plurality of cardholders and temporal merchant transaction sequences associated with the plurality of merchants based, at least in part, on information of the historical payment transactions. A temporal cardholder transaction sequence or session corresponding to a cardholder indicates a time-ordered sequence of identifiers of one or more merchants where the cardholder has performed a set of payment transactions within a particular time interval. The temporal merchant transaction sequence corresponding to a merchant indicates time-ordered sequence of identifiers of one or more cardholders who have performed one or more payment transactions within the particular time interval at the merchant.
Thereafter, the server system is configured to generate cross-entity transaction sequences based, at least in part, on the temporal cardholder transaction sequences and the temporal merchant transaction sequences. The cross-entity transaction sequences include first cross-entity transaction sequences and second cross-entity transaction sequences. The first cross-entity transaction sequences are generated by the temporal cardholder transaction sequences and the second cross-entity transaction sequences are generated based, at least in part, the temporal merchant transaction sequences.
In one embodiment, the server system is configured to determine cardholder embeddings associated with the plurality of cardholders and merchant embeddings associated with the plurality of merchants based, at least in part, on the cross-entity transaction sequences and an entity representation learning model. The entity representation learning model is implemented based at least on a first skip-gram model and a second skip-gram model. The skip-gram models are very similar to Word2vec model. The server system is configured to determine merchant embeddings of the plurality of merchants based, at least in part, on the first cross-entity transaction sequences and the first skip-gram model. The server system is configured to determine cardholder embeddings of the plurality of cardholders based, at least in part, on the second cross-entity transaction sequences and the second skip-gram model.
In one embodiment, the server system is configured to generate, via an autoencoder, combined transaction embeddings based, at least in part, on the cardholder embeddings and the merchant embeddings. Then, a fraud risk prediction model is trained based on the combined transaction embeddings to predict fraudulent payment transactions between cardholders and merchants. During training, a loss value of the fraud risk prediction model is back-propagated to the autoencoder and the entity representation learning model for fine-tuning.
Various embodiments of the present disclosure enable the generation of offline feature representation i.e., card embeddings and merchant embeddings that further help in addressing the problem of implementing sophisticated deep learning models in real-time environment for detecting fraudulent transactions with increased accuracy. Current techniques utilize long term and short term variables aggregated on respective time horizon and do not fully capture the behavioral changes of cards. Cross linkage model captures out-of-behavior interaction of card with merchants and captures short-term behavioral changes in card transactions better than traditional long-term variables. This further takes care of individual entity behavior and cross learning by establishing linkage between riskier merchants and cards. Velocity features often fail to capture out-of-behavior lower ticket size fraud transactions which can be better captured using latent complex interactions as explained herein.
Additionally, the present disclosure improves existing fraud detection models by learning the semantic intent of transaction via their historical sequence in real-time. The present disclsoure also describes that combined embeddings of involved merchant and card when passed along with transaction-level features as an input to the downstream supervised model for fraud detection, leads to improved performance on all classification metrics.
Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 9.
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, modeling fraud risk prediction models by learning representations of payment entities to semantically capture the intent of performing payment transactions based on natural language processing (NLP) models. The environment 100 generally includes a server system 102, a plurality of cardholders 104a, 104b, and 104c (collectively, represented as cardholder 104) who have performed payment transactions at a plurality of merchants 106a, 106b, and 106c (collectively, represented as merchant 106), an issuer server 108, an acquirer server 110, and a payment network 112 including a payment server 114, each coupled to, and in communication with a network 116. The network 116 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 two or more of the parts illustrated in FIG. 1, or any combination thereof.
Various entities in the environment 100 may connect to the network 116 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, future communication protocols or any combination thereof. For example, the network 116 may include multiple different networks, such as a private network made accessible by the server system 102 and a public network (e.g., the Internet, etc.) through which the server system 102, the issuer server 108, and the acquirer server 110 may communicate.
In one example, the cardholder 104a may be any individual, representative of a corporate entity, non-profit organization, or any other person. In addition, each cardholder may have a payment account issued by corresponding issuing banks (associated with the issuer server 108) and may be provided with a payment card with financial or other account information encoded onto the payment card such that each of the plurality of cardholders 104a-104c may use the payment card to initiate and complete a payment transaction using a bank account at the issuing bank. Examples of the payment card may include, but are not limited to, a smartcard, a debit card, a credit card, and the like.
In one embodiment, the issuer server 108 is a financial institution that manages accounts of multiple account holders (e.g., the plurality of cardholders 104a-104c). In addition, account details of the payment accounts established with the issuer bank are stored in account holder profiles of the account holders (e.g., the plurality of cardholders 104a-104c) in memory of the issuer server 108 or on a cloud server associated with the issuer server 108. The terms “issuer server”, “issuer”, or “issuing bank” will be used interchangeably herein.
Further, the cardholders 104a-104c may perform the payment transactions at the merchants 106a-106c. In an example, the plurality of cardholders 104a-104c may transact at the plurality of merchants 106a-106c (e.g., using a merchant terminal) to perform payment transactions for purchasing goods and/or services offered by the plurality of merchants 106a-106c. In an example, the merchant terminal may include Point-Of-Sale (POS) device, Point-Of-Purchase (POP) device, Point-Of-Interaction (POI) device, and the like. In one implementation, each payment account associated with the plurality of merchants 106a-106c may be managed by an acquiring bank (e.g., the acquirer server 110).
In one embodiment, the acquirer server 110 is associated with a financial institution (e.g., a bank) that processes financial transactions. The acquirer server 110 can be an institution that facilitates the processing of payment transactions for the plurality of merchants 106a-106c, or an institution that owns platforms to 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”, “acquirer bank”, “acquiring bank”, or “acquirer server” will be used interchangeably herein.
In one non-limiting example, a cardholder opens a merchant application on its user device to perform a payment transaction using stored information of a primary account number (PAN) and/or a payment card associated therewith to purchase goods or services offered by a merchant (e.g., merchant 106a). After submitting a payment from the payment account associated with the payment card, a payment authorization request associated with the submitted payment is authorized in near real-time and the required funds associated with the payment are kept pending for the payment transaction. The funds are then debited from the payment account associated with the cardholder and credited to the payment account associated with the merchant. The funds are exchanged in place of goods or services provided by the merchant to the cardholder.
In general (not in accordance with embodiments of the present disclosure), there are many analytical artificial intelligence (AI) models used to predict different financial indicators for such payment transactions. For example, a fraud risk model is used to detect whether a payment transaction is fraudulent or not. Such analytical AI models are developed mainly based on card-level features or static transaction features of such payment transactions. However, the analytical AI models do not consider cardholder-merchant relationship and lack in providing correct predictions and they fail to capture any type of interaction between cardholder and merchant involved in a transaction.
For example, any given merchant may interact with a few of the cardholder accounts. Therefore, the past payment transactions of cardholders and merchants implicitly create a bipartite graph between cardholders and merchants. This sparse, high-dimensional bipartite graph is very difficult to use for detecting fraudulent transactions.
To overcome the above-mentioned issues, the server system 102 is configured to perform one or more of the operations described herein and leverage the merchant-cardholder transactions to provide useful analytical methods, thereby exposing new functionality based on the merchant-cardholder relationship in its entirety. The server system 102 is configured to improve fraud risk models by learning representation learning of payment entities (e.g., merchants and cardholders) using natural language processing (NLP) based approaches to semantically capture intent of past payment transactions. The server system 102 is configured to predict future plausible merchants for a cardholder or vice-versa. In particular, the server system 102 is configured to implement a neural network architecture that can be grouped into three components: (a) an entity representation learning model, (b) autoencoder for optimal transaction embedding generation, and (c) a fraud prediction task model. A detailed explanation of these components is described in a later set of figures.
The server system 102 is a separate part of the environment 100 and may operate apart from (but still in communication with, for example, via the network 116), the plurality of cardholders 104a-104c, the plurality of merchants 106a-106c, and any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may actually be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the cardholder 104a. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 116, 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.
In one embodiment, the server system 102 coupled with a database 118 is embodied within the payment server 114, however, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the issuer server 108. The database 118 may be incorporated in the server system 102 or may be an individual entity connected to the server system 102 or may be a database stored in cloud storage. In one embodiment, the database 118 may store learned cardholder embeddings and merchant embeddings, or layer parameters (e.g., weights and biases) and hyperparameters associated with a fraud risk prediction model.
The transaction database 120 stores transaction data i.e., information of the plurality of payment transactions (e.g., credit card transactions, debit card transactions and the like) performed by the plurality of cardholders 104a-104c. For example, the transaction database 120 may store authorization, clearing, and/or chargeback data associated with the cardholders 104a-104c. The transaction database 120 may store historical payment transaction data associated with the cardholders 104a-104c. This information may be transmitted to another computing device, for example, the server system 102 described herein according to various example embodiments. In one embodiment, the transaction data is provided by the issuer of the cardholders. The transaction data may include transaction attributes describing a given transaction.
The transaction data may define relationships between cardholder accounts and merchants. For example, when a customer buys an item from a merchant, a relationship is defined. Similarly, when the customer transacts with another merchant, a relationship is defined. Thus, the transaction data can be leveraged to expose a variety of different attributes of the accounts, such as account activity, customer preferences, similarity to other accounts, and the like. However, the merchant-cardholder transaction data is sparse, as any given cardholder account (which includes merchant accounts that perform transactions with other merchants) interacts with a small fraction of merchants. The transaction history of a cardholder can be leveraged to capture the information about merchants frequented by that card. Similarly, for merchants, their historical transactions can be used to learn the information of cardholders frequenting that merchant. Any mismatch in the learned interaction pattern of involved entities could be a behavioral anomaly and points towards a potential fraud. For example, transaction of a card at a gambling merchant, given that its recent transactions were at a domestic ATM, fuel and grocery merchants, could be a behavioral anomaly as the intent of this cardholder, defined by this recent history, is more semantically related to that of an everyday outing merchant like a retail shop than an infrequent leisure merchant like a casino. This interaction pattern of card and merchant involved in a transaction is referred to as the intent of that transaction, which can be leveraged to extend the capability of existing fraud detection models to detect fraud in the present disclosure.
In one embodiment, the payment network 112 may be used by the payment card issuing authorities as a payment interchange network. The payment network 112 may include a plurality of payment servers such as the payment server 114. Examples of payment interchange network 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.).
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.
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 102. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
In one embodiment, the server system 200 is configured to perform various downstream task-specific predictions for cardholders or merchants by training artificial intelligence models based on cardholder-merchant relationship data. In particular, the server system 200 performs two-part deployable solution: (a) periodic offline training and (b) online real-time prediction. The periodic offline training recreates static card and merchant embeddings using new transactions, and then uploaded online, which along with transaction attributes, are used for real-time fraud prediction.
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.
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. The 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 model parameters of entity representation learning model, layer parameters of trained autoencoder and model parameters of fraud risk prediction model.
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 graphical processing unit (GPU), 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.
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 114, the issuer server 108, or communicating with any entity connected to the network 116 (as shown in FIG. 1). In one embodiment, the processor 206 is configured to access payment transaction data associated with the cardholder 104a from the transaction database 120.
It is to be 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 to be noted that the server system 200 may include fewer or more components than those depicted in FIG. 2.
In one embodiment, the processor 206 includes a data pre-processing engine 218, a temporal transaction sequencer 220, an entity representation learning engine 222, an autoencoder 224, and a fraud risk prediction engine 226. It should be noted that components, described herein, such as the data pre-processing engine 218, the temporal transaction sequencer 220, the entity representation learning engine 222, the autoencoder 224, and the fraud risk prediction engine 226 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.
The data pre-processing engine 218 includes suitable logic and/or interfaces for accessing information of historical payment transactions associated with a plurality of cardholders 104a-104c performed at a plurality of merchants 106a-106c within a particular time interval from a transaction database 120. In particular, the data pre-processing engine 218 may query the transaction database 120 for the plurality of payment transactions performed by the cardholders 104a-104c based on account identifiers of the cardholders 104a-104c. In some implementations, the data pre-processing engine 218 may access a set of payment transactions associated with the cardholders 104a-104c from the issuer server 108. The set of payment transactions may include a sequence of card transactions at different merchants for a particular cardholder within the particular time interval. In another embodiment, the data pre-processing engine 218 may access a set of payment transactions associated with the merchants 106a-106c from the acquirer server 110.
The information of the historical payment transactions may include any number and type of attributes describing a given transaction. For example, the information of the historical payment transactions may include at least an account identifier (e.g., a customer account number, a customer credit card number, a merchant account number, etc.), a merchant identifier (e.g., a merchant name), a timestamp associated with the transaction, an amount of the transaction, and a geo-graphical location of the payment transaction, among many other data attributes. As such, the data space of the historical payment transactions is high-dimensional, including data defining millions (or more) of cardholder accounts and merchants.
Based on the information of the historical payment transactions, the data pre-processing engine 218 may identify relationships between cardholder accounts and merchants. For example, when a cardholder transacts with a merchant, a relationship is defined. The data pre-processing engine 218 may generate a bipartite graph based on the identified relationships between the cardholder accounts and the merchants. For example, if the cardholder makes purchases at merchants A and B within a time threshold (e.g., within an hour, a day, etc.), the transactions between the cardholder and the merchants A and B may be considered to be within the same context. Each unique entity ID (e.g., cardholder ID and merchant ID) in the bipartite graph is assigned a unique identifier corresponding to a row in the lookup table. In order to bring cross-modal linkage between the two entities, i.e., card and merchant, the data pre-processing engine 218 is configured to create the associated card IDs and merchant IDs that are brought in the same N-dimensional space.
In some implementations, the data pre-processing engine 218 is configured to perform operations (such as data-cleaning, normalization, feature extraction, and the like) on payment transactions associated with each cardholder.
The temporal transaction sequencer 220 includes suitable logic and/or interfaces for determining temporal cardholder transaction sequences associated with the plurality of cardholders 104a-104c and temporal merchant transaction sequences associated with the plurality of merchants 106a-106c based, at least in part, on information of the historical payment transactions. For each cardholder, a temporal cardholder transaction sequence indicates time-ordered sequence of merchants where the cardholder has performed a set of payment transactions within the particular time interval. Further, for each merchant, a temporal merchant transaction sequence indicates time-ordered sequence of cardholders who have transacted at the merchant within the particular time interval. The intuition behind using time-ordered transaction sequences of entities (e.g., merchants and cardholders) is to capture the general semantic intent of the corresponding entities for a particular set of transactions. For example, if a cardholder who lives in Washington, D.C. may be traveling to New York City, the cardholder performs transactions for booking a rental taxi using a rental car app (e.g., merchant 'M1'), paying at airport lounge shop (denoted as merchant 'M2'), and thereafter booking a hotel (i.e., merchant 'M3') in the New York, all the merchants transacted by the cardholder within a time session are related by the intent of the cardholder. In other words, the temporal cardholder transaction sequence (e.g., M1, M2, and M3) indicates time-order merchant sequences of merchants that may be semantically related by intent of the cardholder.
Once the temporal cardholder transaction sequences and the temporal merchant transaction sequences are generated, the temporal transaction sequencer 220 is configured to generate cross-entity transaction sequences. For the temporal cardholder transaction sequence of the cardholder, a cross-entity transaction sequence is generated by inserting cardholder identifier of the cardholder in the temporal cardholder transaction sequence based at least on a hyper parameter. In one illustrative example, a cardholder has performed transactions at merchants M1, M2, M3, M4 and M5 in time-ordered manner within a session. Then, the temporal transaction sequencer 220 is configured to generate a temporal cardholder transaction sequence (e.g., M1 M2 M3 M4 M5) associated with the cardholder and then sandwich cardholder identifier into the temporal cardholder transaction sequence based on a training window so that while learning merchant representation, cardholder representation is also learned. Basically, the training window defines a position where the cardholder identifier should be inserted in the temporal cardholder transaction sequence. Initially, the cardholder identifier is inserted in a heuristic manner to create a sentence that is fed to the entity representation learning model of the cardholders.
In a similar fashion, for the temporal merchant transaction sequence, a cross-entity transaction sequence is generated by inserting merchant identifier of the merchant in the temporal merchant transaction sequence.
During training phase, the temporal transaction sequencer 220 is configured to provide the cross-entity transaction sequences to the entity representation learning engine 222.
The entity representation learning engine 222 includes suitable logic and/or interfaces for determining cardholder embeddings associated with the plurality of cardholders 104a-104c and merchant embeddings associated with the plurality of merchants 106a-106c based, at least in part, on the cross-entity transaction sequences and an entity representation learning model. The entity representation learning model is analogous to word2vec model where embeddings are generated using historical co-occurring sequences which capture the aforementioned intent of cardholder and merchant encounters by extracting the semantics behind these interactions. In one embodiment, the entity representation learning model is implemented based on skip-gram model. The skip-gram models provide cardholder embedding of each cardholder and merchant incorporating information about the profile of cardholder or merchant encounter and its time-ordered sequential relation, along with the cardholder-merchant relationship. The word2vec model using skip-gram approach takes sentences as input and considers each distinct word as an entity. The key principle behind skip-gram is that, given an entity, the model should be able to predict its neighboring entities in the corpus. The objective of skip gram is to maximize the following average log probability:
1/N ?_(n=1)^N¦?_(-c=j=c:c?0)¦logp(m_(n+j)?m_n )
where c is the context window size, m_n is the target entity, {m_(n+j) | |j| = c} is the set of context entities and the conditional probability p(m_(n+j)?m_n ) is defined by:
p(m_0¦m_i )=exp (v_mi.v_(m_o)^T¦)/(?_(j=1)^N¦?exp(v_mi.v_(m_j)^T¦) ?)
In one embodiment, the processor 206 is configured to define a sentence in the corpus as the time-ordered sequence of merchants encountered by a card, for card representation generation, and cards transacted at a merchant, for merchant representation generation, in a defined time frame (referred as a session). To generate merchant embedding, the processor 206 is configured to input merchant sessions, “C1, C2, C3, C4, . . .” (Ci : ith card) to a first skipgram model of the entity representation learning model. This approach captures the co-occurring card relationship and incorporates them into the embeddings. Similarly, for cardholder embeddings, the card session of merchants is fed into a second skip-gram model of the entity representation learning model.
The entity representation learning engine 222 is configured to provide the cardholder embeddings and the merchant embeddings to the autoencoder 224. In one embodiment, the database 204 is configured to store the merchant embeddings and the cardholder embeddings.
The autoencoder 224 includes suitable logic and/or interfaces for generating combined transaction embeddings based, at least in part, on the cardholder embeddings and the merchant embeddings and conventional transaction attributes. The autoencoder 224 is trained using learnt entity embeddings (i.e., cardholder embeddings and merchant embeddings). Further, these representations are passed through an autoencoder to generate a latent representation referred as transaction embedding. In general, the autoencoders are a special category of feed-forward neural networks that are used to learn efficient embedding of the training data. An autoencoder network has the same input and output dimensions; it transforms the input to a hidden representation, having a different dimension than the input (and output) dimension, and then reconstruct the input from this hidden representation. It tries to learn the function f?(X) = X for an input X, where ? denotes the function parameters to be learned. In other words, it tries to approximate the identity function, which can be done trivially, but by placing constraints on the network, such as by limiting the number of hidden units, the trivial solution can be eliminated.
During training phase, the autoencoder 224 is trained using the cardholder embeddings of the cardholders 104a-104c, the merchant embeddings of the merchants 106a-106c, and conventional transaction attributes of the historical payment transactions. The autoencoder 224 is able to produce combined transaction embeddings or latent representation of the attributes, which can be used to retrieve the original features. The latent representation has a smaller dimension than the original features which makes learning of the fraud risk prediction model easier.
The fraud risk prediction engine 226 is configured to train the fraud risk prediction model based, at least in part, on the combined transaction embeddings. In one embodiment, the fraud risk prediction model is implemented based on a multi-layer feed-forward neural network architecture. The fraud risk prediction model is trained with the labeled transactions where each transaction is represented by Z, the features generated by the autoencoder 224. For testing, a transaction attribute vector passes through autoencoder (only encoder) and corresponding transformed vector is fed to trained fraud risk prediction model for classification.
FIG. 3 is a schematic representation 300 of a data flow among different modules of the processor 206, in accordance with an embodiment of the present disclosure.
As mentioned previously, the processor 206 is configured to generate a bipartite graph (see, 302) having at least one cardholder node and at least one merchant node connected by a transaction edge. Graph embedding methods learn the interaction between entities (i.e., card and merchant) either from static or from temporal graphs. For fraud detection task, learnt interaction between card and merchant helps in capturing out-of-behavior interaction of card with merchants.
Temporal graph methods help in capturing short-term behavioral changes in card transactions better than traditional long term variables used in fraud risk score calculations. Biased random walk over heterogeneous bi-partite graph based on time of interaction between the cards and merchants is performed by the processor 206. Traversal probabilities are assigned either through exponential or linear function. This results in randomly selected time-based transaction sequences for each card-merchant node. Bias walks using an exponential distribution equation is used to get the temporal interaction sequences. The equation is as shown below.
...Eqn. (1)
Where, each edge e?E_Tis assigned a probability and t_min is the minimum time associated with an edge in the graph.
The data pre-processing engine 218 is configured to provide processed transaction data to the temporal transaction sequencer 220 (see, 304). The temporal transaction sequencer 220 is configured to generate a temporal cardholder transaction sequence of each cardholder (e.g., a cardholder C1) where the transaction sequence includes a list of merchants (e.g., merchants M1, M2, M3, M4) arranged based on a time of performed transactions at the merchants. In a similar manner, the temporal transaction sequencer 220 is configured to generate a temporal merchant transaction sequence of each merchant (e.g., merchant M1) where the transaction sequence includes a list of cardholders (e.g., cardholders C1, C2, C3, C4, C5) arranged based on a time of transactions by these cardholders at the merchant.
Thereafter, the temporal transaction sequencer 220 is configured to generate a first cross-entity transaction sequence based on the temporal cardholder transaction sequence of each cardholder. The first cross-entity transaction sequence is generated by inserting cardholder identifier of the cardholder in the temporal cardholder transaction sequence. The position of insertion of cardholder identifier of the cardholder is decided based on a training context window of the entity representation learning model. Similarly, a second cross-entity transaction sequence is generated by inserting merchant identifier of the merchant in the temporal merchant transaction sequence.
The first and second cross-entity transaction sequences are provided to the entity representation learning engine 222 (see, 306). The entity representation learning engine 222 generates merchant embeddings 308a and cardholder embeddings 308b using first skip-gram model and second skip-gram model, respectively. A combination of merchant and cardholder embeddings (see, 310) is provided to autoencoder 224 to generate a combined transaction embedding (see, 312). The fraud risk prediction engine 226 determines fraud risk scores of payment transactions based on the combined transaction embedding.
During execution phase, the server system 200 determines whether a new cardholder is risky or not, based on a classfication output of the cardholder embedding of the new cardholder.
FIG. 4 is a block diagram representation 400 of generation of cardholder embeddings and merchant embeddings, in accordance with an embodiment of the present disclosure.
As explained with reference to FIG. 2, the temporal transaction sequencer 220 is configured to generate temporal transaction sequences / temporal interaction sequences for each cardholder and each merchant. At first, a session of card C1 402 interacting with different merchants (M1, M2, M3, M4 and M5) sorted temporally in a sentence structure and in a time-based manner is represented. A session of merchant M1 406 interacting with different cards (C1, C2, C3, C4 and C5) sorted temporally in a sentence structure and a time-based manner is represented. It is noted that the notations M1, M2… Mn actually represent a corresponding ID of the merchants and the notations C1, C2…. Cn actually represent a corresponding ID or the number of the card or cardholder. The processor 206 is configured to define a sentence in the corpus as the time-ordered sequence of merchants encountered by a card, for card representation generation, and cards transacted at a merchant, for merchant representation generation, in a defined time frame (referred as a session). To generate merchant embedding, the processor 206 is configured to input merchant sessions, “C1, C2, C3, C4, . . .” (Ci : ith card) to a first skipgram model. This approach captures the co-occurring card relationship and incorporates them into the embeddings. Similarly, for card embeddings, the card session is fed to train second skip gram model. Drawing analogy from NLP, similar merchants, for example, all grocery stores, will be in close proximity in embedding space because of their nature of being transacted at inter-changeably by cards.
A session of card C2 404 interacting with different merchants (M1, M2’, M3, M4’, M5 and M6) sorted temporally in a sentence structure is represented. The patterns present in the transaction sequence of cards help to capture the semantic relation amongst them. For example, as shown in the session of card C2 404, since C1 and C2 are doing transactions with merchant M1 and merchant M3, there is a possibility that merchant M2 and merchant M2’ may be similar to each other. Further, if two merchants M1 and M2 are occurring in the context (neighborhood) of a merchant M3 then it might be inferred that M1 and M2 are similar in nature. Also, if a card is getting a decline on an MCC 7995 (gambling merchant) and getting an approval on the neighbor node, it infers that they are in close proximity in terms of a topological structure. A session of merchant M2 408 interacting with different cards (C1, C2’, C3, and C4’) sorted temporally in a sentence structure is represented. As shown in the session of merchant M2 408, since merchants M1 and M2 are doing transactions with card C1 and card C3, there is a possibility that card C1 and card C3’ are similar to each other.
Next, cross-entity transaction sequences 420 are generated from the temporal transaction sequences 410. As shown, the cross-entity transaction sequences 420 are shown to include a cross-entity transaction sequence 402a, a cross-entity transaction sequence 404a, a cross-entity transaction sequence 406a, and a cross-entity transaction sequence 408a as generated from the corresponding temporal transaction sequences 410 (including sequences 402, 404, 406 and 408) by sandwiching each card ID between every merchant IDs and vice versa. For example, the cross-entity transaction sequence 402a is generated by sandwiching the merchant M1 (ID) and merchant M2 between every card C1 (ID), the merchant M3 and merchant M4 between every card C1, and so on. This is exemplarily represented as C1-M1-M2-C1-M3-M4-C1-M5 as the cross-entity transaction sequence 402a. Similarly, the cross-entity transaction sequence 406a is generated by sandwiching the card C1 and card C2 between every merchant M1, the card C3 and the card C4 between every merchant M1, and so on. This is exemplarily represented as M1-C1-C2-M1-C3-C4-M1-C5 as the cross-entity transaction sequence 406a. Likewise, the cross-entity transaction sequence 404a for the card C2 and the cross-entity transaction sequence 408a for the merchant M2 are generated as shown in FIG. 4. The cross-entity transaction sequences 420 are generated such that when the card representation is learnt, the merchant representation is also learnt simultaneously.
The cross-entity transaction sequences 420 are fed to the entity representation learning engine 222 which uses skip-gram method to generate cardholder embeddings 430 and merchant embeddings 432 at once. The sandwiched representation of time sequenced merchant and card interactions to create the embeddings in the same embedding space learns cross linkage between merchant and card which is essential for fraud detection problem. The offline generated embedding can be stored and used for computing the improved fraud risk score for future transactions for a pre-determined period of time for example 2 months. Further, new embeddings may be generated periodically.
Referring now to FIG. 5, a schematic block diagram representation 500 of a process of generating cardholder and merchant embeddings, is shown, in accordance with an embodiment of the present disclosure. As explained with reference to FIG. 2, in order to bring cross-modal linkage between the two entities, i.e., card and merchant, the associated card IDs and merchant IDs are brought in the same N-dimensional space by the processor 206 (see, 502). In an example embodiment, a transaction history sequence of each card is generated by extracting associated transaction information of each card from the transaction database 120 of FIG. 1. Thereafter, card and merchant transaction graph network is generated by extracting associated transaction information of each card and each merchant from the transaction database 120.
Next, the temporal transaction sequence is processed to generate cross-entity transaction sequence by sandwiching each card ID between every merchant IDs and vice versa. Such a transaction sequence is processed through skip gram method (see, 504). In one embodiment, coupled networks such as, one for card and one for merchant are used where inputs to RNNs/Transformers/Word2vec are interlinked to capture better interaction. Next, schema creation and embedding file transfer are performed (see, 506). The entity embedding tables 510 including a merchant embedding vector table 514a and a cardholder embedding vector table 514b are generated by the entity representation learning engine 222 as shown (see, 508). The merchant embedding vector table 514a is shown to include columns 512a and 512b namely, a merchant ID and an embedding vector, respectively. For an exemplary merchant ID 720...5001, a corresponding merchant embedding vector is represented as [0.09, 0.277, 0.56]. The cardholder embedding vector table 514b is shown to include columns 516a and 516b namely, a card number and an embedding vector, respectively. For an exemplary card ID 51….xxxx, a corresponding card embedding vector is represented as [0.48,0.31…0.817]. In one embodiment, transaction, card and merchant embeddings are created in a way to learn complex interactions amongst entities coupled by implementable downstream model. The offline generated embeddings are then loaded to evaluate the fraud risk score in real-time.
Basically, a card representation contains information of the merchants it transacted with and a merchant in turn contains information about the cards. Over multiple iterations of model training, the information finally being captured for any ID is aggregation of merchant ID and card ID information. Using the model, the false positive fraudulent transactions can be reduced to 1:2 compared to the existing methods where the ratio is 1:8. Improved fraud risk score is able to push non-fraudulent transaction in HIGH fraud risk score bands to LOW improved fraud risk score (improving the false positive rate) and push fraudulent transaction from LOW fraud risk score band to HIGH improved fraud risk scores, thus, increasing the detection rate.
FIG. 6 is a process flow of method 600 for training a fraud risk prediction model based on representation learning of intents of cardholders and merchants from temporal transaction sequences, in accordance with an embodiment of the present disclosure. The sequence of operations of the method 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 600, and combinations of operation in the method 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 process flow starts at operation 602.
At 602, the server system 200 accesses training data from a transaction database 120. The training data may include historical payment transactions of a plurality of cardholders 104a-104c who have performed the payment transactions at the plurality of merchants 106a-106c within a particular time interval.
At 604, the server system 200 may generate time-ordered transaction sequences i.e., temporal transaction sequences corresponding to the cardholders 104a-104c and the merchants 106a-106c.
At 606, the server system 200 generates first and second cross-entity transaction sequences or sentences based on temporal transaction sequences of the cardholders 104a-104c and the merchants 106a-106c in a heuristic manner. A first cross-entity transaction sequence is generated based on a temporal cardholder transaction sequence (i.e., a list of merchants arranged according to a time of cardholder transactions of a cardholder) by inserting a cardholder identifier of the cardholder into the temporal cardholder transaction sequence according to a hyperparameter of a first skip-gram model. In a similar manner, a second cross-entity transaction sequence is generated based on a temporal merchant transaction sequence (i.e., a list of cardholders arranged according to time of cardholder transactions at the merchant) by inserting the merchant identifier into the temporal merchant transactions sequence according to a hyperparameter of a second skip-gram model.
At 608, the server system 200 provides the first and second cross-entity transaction sequences to a first skip-gram model and a second skip-gram model, respectively (see, FIG. 7).
The first skip-gram model is configured to learn merchant representations with respect to intents of the cardholders. The first skip-gram model is configured to learn semantic intent of cardholder transactions to learn merchant embeddings. The second skip-gram model is configured to learn semantic intent of transactions at merchants to learn cardholder embeddings.
At 610, the server system 200 generates a merchant embedding for each merchant based on the first cross-entity transaction sequences using a first skip-gram model. In particular, the first skip-gram model takes each first cross-entity transaction sequence as an input and predicts neighboring entities of each target entity based on an objective (see, Eqn. (2)). It should be noted that merchants which are similar in nature of their commercial activity are nearby in the embedding space and have a high cosine similarity.
At 612, the server system 200 generates a cardholder embedding of each cardholder based on the second cross-entity transaction sequences using the second skip-gram model. It should be noted that cardholders which are similar in nature of their payment activity are nearby in the embedding space and have a high cosine similarity.
At 614, the server system 200 concatenates the merchant and cardholder embeddings along with transaction attributes of the historical payment transactions.
At 616, the server system 200 provides the concatenated representation to an autoencoder to generate a combined transaction embedding.
At 618, the server system 200 trains the fraud risk prediction model based on the combined transaction embedding.
Experimental Design:
An experimental setup for entity representation learning and fraud classification is described. Further, the present disclosure describes few baseline approaches for comparing the performance of the current model with existing state-of-art algorithms.
Training Details
For generating n-dimensional card and merchant representations, Intent2Vec employs a skip-gram model with negative sampling using a window size of 4 and min count as 5 for pruning the card and merchant data. In the experiment, a decaying learning rate is initialized as 0.03, minimum value is set as 0.0007 and n is set to 100. These representations are then fed to an autoencoder to generate transaction embeddings. A 6-layer autoencoder with 1024-512-128-128-512-1024 units is trained with mean square error loss. Encoder’s last layer is used to extract the learned 128-dimensional transaction embedding. For the downstream classification task, class weights are assigned in 80: 1 ratio to address the high class imbalance.
Model Evaluation
The models are evaluated on Precision, Recall, F1 score, and Area Under Precision-Recall Curve. Results in Table 1 show the performance of the proposed model on test data based on the threshold which gives highest F1 score on validation data. Results in Table 1 show that feeding card and merchant embeddings along with transaction features significantly improves the model’s performance. It shows the importance of historical information of transactions captured in entities’ embedding for detecting fraud. It can be seen that supervised methods outperform anomaly based unsupervised method. Also, even using entity representations along with transaction features as input, linear model performs poorly in comparison to non-linear models as they fail to capture the non-linear relationship among entities present in a transaction.

BASELINE PRECISION RECALL F1 AUC-PR
DADN 0.09 0.29 0.13 0.03
AE+LR 0.09 0.11 0.10 0.03
AE+MLP 0.34 0.39 0.36 0.32
AE+RF 0.75 0.34 0.47 0.44
AE+LGBM 0.68 0.47 0.55 0.53
TabNet 0.65 0.59 0.62 0.55
AE+LR 0.21 0.26 0.24 0.16
AE+MLP 0.92 0.66 0.77 0.76
AE+RF 0.77 0.7 0.74 0.72
AE+LGBM 0.85 0.7 0.77 0.76

Table 1
Further, it is observed that merchants which are similar in nature of their commercial activity are nearby in the embedding space and have a high cosine similarity. The table 2 shows few merchants and their nearest neighbors in the embedding space. The below table shows that most merchants similar to a food merchant 1 are food joints.

Merchants Similarity with Marchant 1
Food Merchant 2 0.77
Food Merchant 3 0.74
Food Merchant 4 0.72
Food Merchant 5 0.70
Food Merchant 6 0.70

In a similar manner, it is observed that two cards having a similar distribution of transactions across industries will be closer in embedding space
Referring now to the FIG. 7, a block diagram representation 700 of the generation of cardholder and merchant embeddings and training a fraud risk prediction model based on a combined transaction embedding, is shown, in accordance with an embodiment of the present disclosure.
At first, the server system 200 determines temporal transaction sequences i.e., sessions of cardholders and merchants based on historical payment transactions. The temporal transaction sequences are converted into cross-entity transaction sequences. As mentioned earlier, the server system 200 generates first and second cross-entity transaction sequences or sentences based on temporal transaction sequences of the cardholders 104a-104c and the merchants 106a-106c in a heuristic manner. A first cross-entity transaction sequence is generated based on a temporal cardholder transaction sequence (i.e., a list of merchants arranged according to a time of cardholder transactions of a cardholder) by inserting a cardholder identifier of the cardholder into the temporal cardholder transaction sequence according to a hyperparameter of a first skip-gram model 702. In a similar manner, a second cross-entity transaction sequence is generated based on a temporal merchant transaction sequence (i.e., a list of cardholders arranged according to time of cardholder transactions at the merchant) by inserting the merchant identifier into the temporal merchant transactions sequence according to a hyperparameter of a second skip-gram model 704.
Thereafter, the first skip-gram model 702 generates cardholder representations (see, 706) including merchant sentences and the second skip-gram model 704 generates merchant rerpresentations 708 including cardholder sentences. Based on the cardholder representations, the cardholder embedding 710 is created. In similar manner, the merchant embedding 712 is generated based on the cardholder sentences. Thereafter, the server system 200 creates corresponding transaction attributes and concatenates merchant and cardholder embeddings along with the transaction attributes. The concatenated representation is provided to the autoencoder 714 which generates a combined transaction embedding that is fed to a downstream classification task 716 (e.g., fraud risk prediction model).
FIG. 8 is a process flow chart of a method 800 for training a fraud risk prediction model, in accordance with an embodiment of the present disclosure. The sequence of operations of the method 800 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 800, and combinations of operation in the method 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 process flow starts at operation 802.
At the operation 802, the method 800 includes accessing, by a server system 200, information of historical payment transactions associated with a plurality of cardholders 104a-104c performed at a plurality of merchants 106a-106c within a particular time interval from a transaction database 120.
At operation 804, the method 800 includes determining, by the server system 200, temporal cardholder transaction sequences associated with the plurality of cardholders 104a-104c and temporal merchant transaction sequences associated with the plurality of merchants 106a-106c based, at least in part, on information of the historical payment transactions.
At operation 806, the method 800 includes generating, by the server system 200, cross-entity transaction sequences based, at least in part, on the temporal cardholder transaction sequences and the temporal merchant transaction sequences.
At operation 808, the method 800 includes determining, by the server system 200, cardholder embeddings associated with the plurality of cardholders 104a-104c and merchant embeddings associated with the plurality of merchants based, at least in part, on the cross-entity transaction sequences and an entity representation learning model.
At operation 810, the method 800 includes generating, by the server system via an autoencoder, combined transaction embeddings based, at least in part, on the cardholder embeddings and the merchant embeddings.
At operation 812, the method 800 includes training, by the server system, a fraud risk prediction model based, at least in part, on the combined transaction embeddings, the fraud risk prediction model trained to predict fraudulent payment transactions. The method further includes back-propagating, by the server system, a loss value of the fraud risk prediction model to the autoencoder and the entity representation learning model for fine-tuning layer parameters of the autoencoder and model parameters of the entity representation learning model.
FIG. 9 is a simplified block diagram of a payment server 900, in accordance with an embodiment of the present disclosure. The payment server 900 is an example of the payment server 114 of FIG. 1. The payment server 900 and the server system 200 may use the payment network 112 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
The payment server 900 includes a processing system 905 configured to extract programming instructions from a memory 910 to provide various features of the present disclosure. The components of the payment server 900 provided herein may not be exhaustive and the payment 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 payment server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
Via a communication interface 915, the processing system 905 receives a request from a remote device 920, such as the issuer server 108 or the acquirer server 110. 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 900 includes a database 925. The database 925 also includes transaction processing data such as issuer ID, country code, acquirer ID, merchant identifier (MID), among others.
When the payment server 900 receives a payment transaction request from the acquirer server 110 or a payment terminal (e.g., point of sale (POS) device, etc.), the payment server 900 may route the payment transaction request to an issuer server (e.g., the issuer server 108). The database 925 is configured to store transaction identifiers for identifying transaction details such as, transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like.
In one example embodiment, the acquirer server 110 is configured to send an authorization request message to the payment server 900. The authorization request message includes, but is not limited to, the payment transaction request.
The processing system 905 further sends the payment transaction request to the issuer server 108 for facilitating the payment transactions from the remote device 920. The processing system 905 is further configured to notify the remote device 920 of the transaction status in form of an authorization response message via the communication interface 915. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 108. Alternatively, in one embodiment, the processing system 905 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 915, to the acquirer server 110.
The disclosed methods with reference to FIGS. 1 to 9, or one or more operations of the method 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, net book, Web book, tablet computing device, smart phone, 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.
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).
Particularly, the server system 200 (e.g., the server system 102) 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.
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 spirit and scope of the invention.
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.
,CLAIMS:CLAIMS
We claim:

1. A computer-implemented method, comprising:
accessing, by a server system, information of historical payment transactions associated with a plurality of cardholders performed at a plurality of merchants within a particular time interval from a transaction database;
determining, by the server system, temporal cardholder transaction sequences associated with the plurality of cardholders and temporal merchant transaction sequences associated with the plurality of merchants based, at least in part, on the information of the historical payment transactions;
generating, by the server system, cross-entity transaction sequences based, at least in part, on the temporal cardholder transaction sequences and the temporal merchant transaction sequences;
determining, by the server system, cardholder embeddings associated with the plurality of cardholders and merchant embeddings associated with the plurality of merchants based, at least in part, on the cross-entity transaction sequences and an entity representation learning model;
generating, by the server system via an autoencoder, combined transaction embeddings based, at least in part, on the cardholder embeddings and the merchant embeddings; and
training, by the server system, a fraud risk prediction model based, at least in part, on the combined transaction embeddings, the fraud risk prediction model trained to predict fraudulent payment transactions.

2. The computer-implemented method as claimed in claim 1, wherein a temporal cardholder transaction sequence corresponding to a cardholder indicates a time-ordered sequence of identifiers of one or more merchants where the cardholder has performed a set of payment transactions within the particular time interval.

3. The computer-implemented method as claimed in claim 1, wherein a temporal merchant transaction sequence corresponding to a merchant indicates a time-ordered sequence of identifiers of one or more cardholders who have performed one or more payment transactions within the particular time interval at the merchant.

4. The computer-implemented method as claimed in claim 1, wherein the entity representation learning model is implemented based on a first skip-gram model and a second skip-gram model.

5. The computer-implemented method as claimed in claim 1, wherein the cross-entity transaction sequences comprise first cross-entity transaction sequences and second cross-entity transaction sequences.

6. The computer-implemented method as claimed in claims 4 or 5, further comprising:
generating, by the server system, the first cross-entity transaction sequences based, at least in part, on the temporal cardholder transaction sequences; and
determining, by the server system, the merchant embeddings of the plurality of merchants based, at least in part, on the first cross-entity transaction sequences and the first skip-gram model.

7. The computer-implemented method as claimed in claims 4 or 5, further comprising:
generating, by the server system, the second cross-entity transaction sequences based, at least in part, on the temporal merchant transaction sequences; and
determining, by the server system, the cardholder embeddings of the plurality of cardholders based, at least in part, on the second cross-entity transaction sequences and the second skip-gram model.

8. The computer-implemented method as claimed in claim 1, further comprising:
back-propagating, by the server system, a loss value of the fraud risk prediction model to the autoencoder and the entity representation learning model.

9. The computer-implemented method as claimed in claim 1, wherein the fraud risk prediction model is a multi-layer feed-forward neural network.

10. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-9.