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

TITLE OF THE INVENTION:
ARTIFICIAL INTELLIGENCE BASED METHODS AND SYSTEMS FOR DETECTING FIRST PARTY FRAUD FOR PAYMENT TRANSACTIONS

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)

 
ARTIFICIAL INTELLIGENCE BASED METHODS AND SYSTEMS FOR DETECTING FIRST PARTY FRAUD FOR PAYMENT TRANSACTIONS

TECHNICAL FIELD
The present disclosure relates to artificial intelligence processing systems and, more particularly to, electronic methods and complex processing systems for determining and preventing a first party fraud or friendly fraud for payment transactions.
BACKGROUND
It is well known that fraudulent activities within a payment ecosystem lead to tremendous financial damages every year. One such fraudulent activity is first party fraud. The term ‘first party fraud’ refers to a fraudulent activity in which a cardholder defrauds a merchant either knowingly or unknowingly. First party fraud is committed by the cardholder by raising an illegitimate chargeback dispute with their issuing bank to reverse a legitimate transaction. First party fraud is further classified into two categories, i.e., friendly fraud and first party intentional fraud. Friendly fraud, sometimes also called chargeback fraud, is when a cardholder identifies a purchase on their transaction statement as fraudulent and disputes it to initiate the chargeback process under an impression that this transaction was not performed by them. For example, if the merchant name on the cardholder’s transaction statement is different from their ‘doing business as’ or DBA name, then the cardholder may think that this transaction was not performed by him thus convincing him to raise a chargeback dispute. On the other hand, first party intentional fraud is when a cardholder intentionally disputes a transaction to reverse the transaction to defraud the merchant. For example, a cardholder may purchase a product but later refuse that the purchase was made by him and raise a chargeback dispute. It is estimated that first party fraud accounts for 83% of fraud in industries like digital goods and the risk for merchants in such industries is very high. Further, a chargeback can account for a 4.7% revenue loss thus, resulting in higher operating costs for merchants. In most scenarios, the financial liability for the chargeback lies with the acquiring or issuing bank thus, resulting in higher operating costs for them as well. As may be understood, it is very difficult to determine whether a chargeback dispute is genuine or a first party fraud due to a lack of label datasets of first party fraud transactions and a lack of suspicious indicators for classifying chargeback disputes as first party fraud.
Conventionally, first party fraud is detected on the dispute level with the help of a dispute resolution team that analyzes the disputed transaction to determine whether the chargeback dispute is genuine or fraudulent. Additionally, existing solutions rely on individual cardholder/merchant review capability by providing them with sufficient transaction/profile information to avoid unnecessary disputes and turn into first party fraud. Disputes that are marked in a later stage as first party fraud are very time-consuming and expensive for all the involved parties to resolve. In some scenarios, it can take up to 90, 120, or 540 days to resolve chargeback disputes even if the transaction is a first party fraud transaction. Further, in the current scenario, there exists no solution to determine whether a transaction will later turn into a first party fraud transaction before an actual chargeback dispute is raised.
Therefore, there exists a technological need for technical solutions to detect and prevent first party fraud associated with payment transactions.
SUMMARY
Various embodiments of the present disclosure provide methods and systems for detecting and preventing first party fraud for a payment transaction. The computer-implemented method performed by a server system includes receiving a transaction authorization request for a payment transaction initiated by a cardholder with a merchant. The transaction authorization request includes at least a cardholder identifier (ID), a merchant ID, and one or more reason codes. Further, the method includes accessing a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID. Further, the method includes accessing a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID. Further, the method includes extracting one or more reason codes from the plurality of historically disputed payment transactions. The one or more reason codes may indicate one or more reasons for initiating historical chargeback disputes by the cardholder. Further, the method includes generating label data for the transaction authorization request based, at least in part, on the one or more reason codes. Further, the method includes determining via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and merchant profile. Further, the method includes determining via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data. Further, the method includes invalidating the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold.
In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to receive a transaction authorization request for a payment transaction initiated by a cardholder with a merchant. The transaction authorization request includes at least a cardholder identifier (ID), a merchant ID, and one or more reason codes. Further, the server system is caused to access a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID. Further, the server system is caused to access a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID. Further, the server system is caused to extract one or more reason codes from the plurality of historically disputed payment transactions. The one or more reason codes may indicate one or more reasons for initiating historical chargeback disputes by the cardholder. Further, the server system is caused to generate label data for the transaction authorization request based, at least in part, on the one or more reason codes. Further, the server system is caused to determine via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and merchant profile. Further, the server system is caused to determine via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data. Further, the server system is caused to invalidate the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold.
In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving a transaction authorization request for a payment transaction initiated by a cardholder with a merchant. The transaction authorization request includes at least a cardholder identifier (ID), a merchant ID, and one or more reason codes. Further, the method includes accessing a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID. Further, the method includes accessing a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID. Further, the method includes extracting one or more reason codes from the plurality of historically disputed payment transactions. The one or more reason codes may indicate one or more reasons for initiating historical chargeback disputes by the cardholder. Further, the method includes generating label data for the transaction authorization request based, at least in part, on the one or more reason codes. Further, the method includes determining via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and merchant profile. Further, the method includes determining via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data. Further, the method includes invalidating the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold.

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 illustrates an exemplary representation of an environment related to at least some example embodiments of the present disclosure;
FIG. 2 illustrates a sequence flow diagram depicting a lifecycle of a chargeback dispute, in accordance with an embodiment of the present disclosure;
FIG. 3 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
FIG. 4 illustrates a schematic block diagram representation for detecting first party fraud for payment transactions, in accordance with an embodiment of the present disclosure;
FIG. 5 represents a flow chart of a computer-implemented method for determining if a transaction authorization request for a payment transaction initiated by the cardholder with the merchant corresponds to a first party fraud payment transaction, in accordance with an embodiment of the present disclosure;
FIG. 6 represents a flow chart of a computer-implemented method for determining if a chargeback dispute initiation request for a payment transaction initiated by the cardholder with the merchant corresponds to a first party fraud payment transaction, in accordance with an embodiment of the present disclosure;
FIG. 7 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure; and
FIG. 8 is a simplified block diagram of an issuer 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
OVERVIEW
Various embodiments of the present disclosure provide methods, systems, user devices, and computer program products for determining and preventing a first party fraud or friendly fraud for payment transactions.
In an embodiment, a server system is configured to receive a transaction authorization request for a payment transaction initiated by a cardholder with a merchant. The transaction authorization request includes at least a cardholder identifier (ID), a merchant ID, and one or more reason codes. Here, the reason codes indicate one or more reasons for which disputes were either initiated or settled by the cardholder or merchant. In an embodiment, the one or more reason codes include at least one of a decline reason code, a chargeback reason code, a re-presentment reason code, and an arbitration reason code. In another embodiment, the server system is configured to access a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID.
In another embodiment, the server system is configured to generate the cardholder profile based, at least in part, on the plurality of historically disputed payment transactions and the cardholder ID. In an embodiment, the cardholder profile includes cardholder-related features. Further, the cardholder-related features include at least one of (a) historical dispute behavior of the cardholder, (b) historical dispute behavior corresponding to a particular merchant, (c) personal information identification (PII) validation, (d) spending behavior of the cardholder, (e) family fraud feature, and (f) subscription activity of the cardholder. In another embodiment, the server system is configured to generate the merchant profile based, at least in part, on the plurality of historically disputed payment transactions and the merchant ID. In an embodiment, the merchant profile includes merchant-related features. Further, the merchant-related features include at least one of (a) historical dispute and chargeback rate of the merchant, (b) merchant response on dispute raised, and (c) merchant name discrepancy. As may be understood, the cardholder and merchant profile both provide key insights into the behavior patterns of any particular cardholder or merchant, respectively.
In another embodiment, the server system is configured to access a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID. Further, the server system is configured to extract one or more reason codes from the plurality of historically disputed payment transactions. Herein, the one or more reason codes indicate one or more reasons for initiating historical chargeback disputes by the cardholder.
In another embodiment, the server system is configured to generate label data for the transaction authorization request based, at least in part, on the one or more reason codes. In an embodiment, the server system is configured to determine an end state associated with the one or more reason codes corresponding to each of the plurality of historically disputed payment transactions. Here, the end state is at least one of resolved during collaboration, resolved during chargeback, resolved during re-presentment, and resolved during the arbitration. Further, the server system is configured to determine if each of the plurality of historically disputed payment transactions is one of a first party fraud payment transaction and a third-party fraud payment transaction based, at least in part, on the end state. Further, the server system is configured to label the each of the plurality of historically disputed payment transactions as one of the first party fraud payment transaction and the third-party fraud payment transaction based, at least in part, on the determining step. Further, the server is configured to store a plurality of labeled first party fraud payment transactions as the label data.
In another embodiment, the server system is configured to determine via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and the merchant profile. In another embodiment, the server system is configured to determine via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and the label data.
In another embodiment, the server system is configured to invalidate the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold. In another embodiment, the server system is configured to validate the transaction authorization request based, at least in part, on the first party fraud score being lower than the predetermined threshold.
As may be understood, the various embodiments described above aim to solve the technical problems described earlier, i.e., how to prevent first party fraud and how to determine if a transaction authorization request is valid or invalid. In particular, determining the first party fraud score based on the dispute likelihood score and the label data enables the server system to determine if a transaction authorization request corresponds to a first party fraud and if it should be validated or invalidated. More specifically, if the first party fraud score is greater than the predetermined threshold then the transaction authorization request is invalidated. Otherwise, the transaction authorization request is validated. As may be understood, these embodiments, among other things, provide the technical effect or technical character of automatic real-time detection of first party fraud at the authorization level of a payment transaction, thereby ensuring a low first party fraud rate. It is noted that the detection of a first party fraud, before the transaction is even authorized, saves the acquirer, issuer, and the payment processor from the time-taking and financially expensive process of dispute settlement. Therefore, various dispute settlement stages such as presentment, re-presentment, pre-arbitration, and arbitration can be avoided.
Further, the above-mentioned embodiments enable the server system to generate labels for unlabeled transactions based on one or more reason codes. These labeled transactions can further be used to perform various deterministic operations on their own as well. Further, the novel approach of the present disclosure provides an automated process for determining the first party fraud thereby eliminating the need for a dedicated task force that would otherwise need to manually solve the dispute in a time-consuming and expensive process.
In an embodiment, the server system is configured to receive a chargeback dispute initiation request that includes at least a cardholder identifier (ID), a merchant ID, and a reason code for initiating a chargeback dispute. Further, the server system is configured to access a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID. Further, the server system is configured to access a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID. Further, the server system is configured to extract one or more reason codes from the plurality of historically disputed payment transactions. The one or more reason codes may indicate one or more reasons for initiating historical chargeback disputes by the cardholder. Further, the server system is configured to generate label data for the chargeback dispute initiation request initiated by the cardholder based, at least in part, on the one or more reason codes. Further, the server system is configured to determine via a first machine learning model, a dispute likelihood score for the chargeback dispute initiation request based, at least in part, on the cardholder profile and merchant profile. Further, the server system is configured to determine via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data. In an embodiment, the first machine learning model and the second machine learning models are binary classification models.
Further, the server system is configured to decline the chargeback dispute initiation request based, at least in part, on the first party fraud score being greater than a predetermined threshold. Alternatively, the server system is configured to authorize the chargeback dispute initiation request based, at least in part, on the first party fraud score being lower than the predetermined threshold. In an embodiment, the server system is a payment server associated with a payment network.
It is understood that the above-mentioned embodiments aim to solve the technical problem related to determining whether a chargeback dispute initiation request from a cardholder corresponds to a first party fraud transaction or not. The various embodiments provide a technical effect or technical character of directly declining the chargeback dispute initiation request if it is determined that the payment transaction corresponds to a first party fraud transaction. Therefore, in effect avoiding the various dispute settlement stages while saving time and resources for everyone involved in the payment process, i.e., the acquirer, issuer, and the payment processor. Otherwise, the chargeback dispute initiation request can be accepted. This enables faster claim settlement and quick dispute resolution.
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 refer 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 account" used throughout the description refers to a financial account that is used to fund a transaction (interchangeably referred to as "payment transaction" or “financial transaction”). Examples of the financial account include, but are not limited to, a savings account, a credit account, a checking account, and a virtual payment account. The financial account may be associated with a cardholder such as an individual person, a family, a commercial cardholder, a company, a corporation, a governmental cardholder, a non-profit organization, and the like. In some scenarios, a financial account may be a virtual or temporary payment account that can be mapped or linked to a primary financial account, such as those accounts managed by payment wallet service providers, and the like.
The term "payment network", used herein, 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 that 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 term "merchant", used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same business owner.
The terms "cardholder" and "customer" are used interchangeably throughout the description and refer to a person who holds a payment card such as a credit or a debit card that will be used at a merchant to perform a payment transaction.
Various embodiments of the present disclosure provide methods, systems, user devices, and computer program products for determining and preventing a first party fraud or friendly fraud for payment transactions. To that end, various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 8.
FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example 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, detecting and preventing first party fraud for a payment transaction, thereby reducing first party fraud. Further, embodiments of the present disclosure also enable a payment processor to detect the likelihood for a first party fraud in the future at the time of presentment of the transaction to an acquirer 108, i.e., even before a chargeback dispute is raised, thereby eliminating the need for processes such as collaboration, chargeback, re-presentment, and arbitration thus, saving time and resources. The term ‘presentment’ refers to a stage in the payment ecosystem where a cardholder 104 transacts at a merchant 106 and the acquirer presents the transaction and funds move to the acquirer. The term ‘collaboration’ refers to a chargeback prevention technique implemented by a payment processor such as Mastercard®. During the collaboration, disputes may be resolved in the favor of the cardholder 104, and funds move back to the issuer. The term ‘chargeback’ refers to a stage for disputes unresolved during collaboration where the issuer initiates a chargeback with a reason code and documentation, the chargeback being a charge that is returned to a payment card after the cardholder 104 successfully disputes an item on their account statement or transactions statement/report. The term ‘re-presentment’ refers to a stage during the chargeback dispute process that involves submitting evidence to the acquirer by the merchant 106 proving that the disputed transaction was valid and that the cardholder's claim should be overturned. If successful, the funds move from the issuer to the acquirer associated with the merchant. The term ‘arbitration’ refers to a stage involving the relevant payment processor stepping in to help resolve the dispute between the acquiring and issuing banks and by extension the merchant 106 and the cardholder 104. Herein, the payment processor reviews all the evidence supplied by both the issuing and acquiring banks and makes a final decision on what party to rule in favor of for the chargeback dispute.
The environment 100 generally includes a server system 102, the cardholder 104, the merchant, the acquirer server 108, an issuer server 110, a payment network 112 including a payment server 114, and a database 118, each coupled to, and in communication with (and/or with access to) 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 or cardholders 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 acquirer server 108, the issuer server 110, and the payment server 114 may communicate.
The cardholder 104 may operate a cardholder device (shown in the figure as a mobile phone) to conduct a payment transaction with the merchant 106. In various examples, the payment transaction may be conducted via a payment gateway application associated with a payment processor such as Mastercard®, or through a point-of-sale (POS) machine operated by the merchant 106. Examples of the cardholder device include, but are not limited to, a personal computer (PC), a mobile phone, a tablet device, a Personal Digital Assistant (PDA), a voice-activated assistant, a Virtual Reality (VR) device, a smartphone, and a laptop. In various examples, the cardholder 104 may be any individual, or representative of a corporate cardholder, non-profit organization, or any other person.
In an example, the cardholder 104 may have a payment account issued by an issuing bank (associated with the issuer server 110) and may be provided the payment card with financial or other account information encoded onto the payment card such that the cardholder 104 may use the payment card to initiate and complete a transaction using a bank account at the issuer server 110.
The issuer server 110 is a computing server that is associated with the issuer bank. The issuer bank is a financial institution that manages the payment accounts of multiple cardholders. Account details of the accounts established with the issuer bank are stored in the profiles of the cardholders 104 in the memory of the issuer server 110 or on a cloud server associated with the issuer server 110 (not shown). The terms “issuer”, “issuer bank”, “issuing bank” or “issuer server” will be used interchangeably herein.
The merchant 106 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. Further, the merchant 106 can be either a single business location or a chain of business locations of the same business owner.
In another example, the merchant 106 may have a payment account issued by an acquiring bank (associated with the acquirer server 108) to receive a payment from the cardholder 104. The acquirer server 108 is a computing server that is associated with the acquirer bank. The acquirer bank is a financial institution that manages the accounts of multiple merchants. Account details of the accounts established with the acquirer bank are stored in the profiles of the merchants 106 in the memory of the acquirer server 108 or on a cloud server associated with the acquirer server 108 (not shown). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
As explained earlier, the process for determining fraudulent activities such as first party fraud is very difficult for the various entities within the payment network due to a lack of label data and specific indicators. Further, the conventional methods of determining first party fraud require a dispute resolution team to validate each of the plurality of disputed transactions on a case-by-case basis by relying on a transaction or profile information of the cardholder 104 or the merchant 106. However, this dispute resolution process is very time-consuming and may take up to 90, 120, or 540 days as it involves various steps such as or includes various steps such as collaboration, chargeback, re-presentment, and arbitration (explained further with reference to FIG. 2). Further, there exists no solution to determine whether a transaction will later turn in to a first party fraud transaction before an actual chargeback dispute is raised.
To overcome the above limitations, the server system 102 is configured to validate a transaction authorization request to determine whether the transaction corresponds to a first party fraud transaction. Further, the server system 102 is configured to determine whether a disputed transaction corresponds to a first party fraud when a chargeback dispute is raised thereby, eliminating the need for collaboration, chargeback, re-presentment, and arbitration thus, saving time and resources. Furthermore, the server system 102 is configured to transmit a validation message with the acquirer server 108, the issuer server 110, or the payment server 114, the validation message (or ‘transaction authorization message’) includes a flag indicating a likelihood of whether a transaction corresponds to a first party fraud or not. In particular, the server system 102 is configured to determine the likelihood of whether a transaction corresponds to first party fraud or not by utilizing one or more Artificial Intelligence (AI) or Machine Learning (ML) models. To that end, the server system 102 further includes a first machine learning model 120 and a second machine learning model 122 to determine the likelihood of whether a transaction corresponds to first party fraud or not (explained later in the present disclosure). In a non-limiting example, the first machine learning model 120 and the second machine learning model 122 may be binary classification models. In another embodiment, the server system 102 is configured to determine whether a disputed transaction corresponds to third-party fraud when a chargeback dispute is raised.
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 payment server 114, the acquirer server 108, the issuer server 110, 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 be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the issuer server 110, the acquirer server 108, and the payment server 114. 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 steps as described herein, and/or embodied in at least one non-transitory computer-readable media.
In one embodiment, the database 118 is a central repository of data that is created by storing payment transaction data including a plurality of historical payment transactions indicating historical transactions that took place between the acquirers 108 and issuers 110 within the payment network 112. Further, the database 118 is configured to store a plurality of historically disputed payment transactions, the plurality of historically disputed payment transactions indicating payment transactions that were previously disputed by the cardholder 104. Each of the plurality of historically disputed payment transactions may include one or more reason codes such as decline reason code (in case of the declined transaction), chargeback reason code, re-presentment (or second presentment) reason code, arbitration reason code, and the like. Further, the plurality of historically disputed payment transactions includes payment transaction attributes such as, but not limited to, transaction identifier, merchant name, merchant identifier, merchant category code (MCC), cross-border transaction flag, payment card type (debit/credit/prepaid), card product type, transaction channel (such as e-commerce, recurring, POS), card-not-present (CNP) transaction flag, response code flag (approve/decline) and the like.
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 as 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.
FIG. 2 illustrates a sequence flow diagram 200 depicting the lifecycle of a chargeback dispute, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
At operation 202, the cardholder 104 performs a transaction at the merchant 106. In other words, the acquirer 108 associated with the merchant 106 presents the transaction to the issuer 110 of the cardholder 104 and the funds move from the issuer 110 to the acquirer 108 upon successful transaction authorization. This process is also known as a presentment.
At operation 204, the cardholder 104 initiates a chargeback dispute with the issuer 110 and the issuer 110 transmits the chargeback dispute message to the acquirer 108. In particular, at this stage the acquirer 108 and the issuer 110 share transaction information about the transaction with each other. In one example, the chargeback dispute message includes one or more reason codes that indicate a reason due to which the cardholder 104 initiated the chargeback dispute. For example, a reason code ‘4850’ may indicate that a chargeback was requested due to an installment billing dispute.
At operation 206, a chargeback response message is sent by the acquirer 108 to the issuer 110. The chargeback response message includes one of a successful chargeback flag and an unsuccessful chargeback flag. If the acquirer 108 and the issuer 110 decide with collaboration that a chargeback should be issued by the acquirer 108, then the acquirer 108 transmits a chargeback response message with a successful chargeback flag. As a result, the sequence flow moves to operation 208. Otherwise, if the acquirer 108 and the issuer 110 decide with collaboration that a chargeback should not be issued by the acquirer 108, then the acquirer 108 transmits a chargeback response message with an unsuccessful chargeback flag. As a result, the sequence flow moves to operation 210.
At the operation 208, the issuer 110 initiates a chargeback to the cardholder 104 with a reason code indicating the reason for the successful chargeback claim. In an example, the issuer 110 prepares the relevant documentation (i.e., evidence indicating that the transaction is indeed illegitimate) and issues the chargeback to the cardholder 104 within 90, 120, or 540 days. As a result, funds move back from the acquirer 108 to the issuer 110.
At the operation 210, a chargeback re-presentment message is sent by the acquirer 108 to the issuer 110. The chargeback re-presentment stage involves submitting evidence to the acquirer 108 by the merchant 106 proving that the disputed transaction was valid and that the cardholder's 104 dispute claim should be overturned. If successful, the funds move from the issuer 110 to the acquirer 108 associated with the merchant 106. In particular, a chargeback re-presentment message is transmitted when the merchant 106 wishes to fight the chargeback dispute. At this stage, the merchant 106 associated with the acquirer 108 shares relevant documentation (i.e., evidence indicating that the transaction is indeed legitimate). In an example, the acquirer 108 may respond with the chargeback re-presentment message to the issuer 110 within 45 days. The chargeback re-presentment message includes at least the relevant documentation and the reason code for denying the chargeback dispute.
At operation 212, a pre-arbitration stage begins. After receiving the chargeback re-presentment message, the issuer 110 reviews the relevant documentation and the reason code in the chargeback re-presentment message transmitted by the acquirer 108. Upon completion of its review, the issuer 110 either accepts or rejects the chargeback re-presentment message. If the issuer 110 approves the chargeback re-presentment message, then the initial credit of funds from the acquirer 108 to the issuer 110 is reversed and the funds move back to the merchant 106. On the other hand, if the chargeback re-presentment message is rejected by the issuer 110 then, the issuer 110 opens pre-arbitration with the payment server 114 of the payment network 112 at operation 216a.
At operation 214, the acquirer 108 represents the merchant 106 in responding to the payment server 114, upon determining that the merchant 106 wishes to accept or reject pre-arbitration. If the acquirer 108 responds that the pre-arbitration is rejected, then the funds remain with the issuer 110. Otherwise, if the acquirer 108 responds that the pre-arbitration is accepted then, the acquirer 108 opens pre-arbitration with the payment server 114 of the payment network 112 at operation 216b.
At operation 218, the payment server 114 examines the evidence and makes a final decision. This stage is also known as the arbitration stage. The losing party is then debited for both the chargeback amount and processing fees. In an example, the payment server 114 may be associated with a payment processor such as Mastercard®, and the dispute resolution team of the payment processor analyses the relevant documentation and reason codes from both the issuer 110 and the acquirer 108 to issue the final decision. In various scenarios, the resolution time by the payment server 114 maybe 45-75 days on average.
As it is evident from the sequence flow diagram 200, the chargeback dispute resolution process is very time-consuming and is not suitable for determining first party fraud therefore, there exists a need for a solution to address this problem. It is noted that in order to prevent first party fraud transactions, an intervention can be done either at the time of presentment at operation 202 or at the initiation of a chargeback dispute at operation 204. In other words, if the transaction is rejected during the transaction authorization process, then a chargeback dispute associated with first party fraud in the future can be avoided. Further, if the first party fraud is addressed at the time of chargeback dispute initiation by the cardholder 104, then the time-consuming process ranging from the operation 206 to the operation 218 can be avoided or outright eliminated. To that end, the server system 102 proposed by the present disclosure provides various embodiments for detecting and preventing first party fraud during transactions.
FIG. 3 illustrates a simplified block diagram of a server system 300, in accordance with an embodiment of the present disclosure. The server system 300 is similar to the server system 102. In some embodiments, the server system 300 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture. In one embodiment, the server system 300 is a part of the payment network 112 or is integrated within the payment server 114. In another embodiment, the server system 300 is embodied within the issuer server 110. In yet another embodiment, the server system 300 is embodied within the acquirer server 108.
The server system 300 includes a computer system 302 and a database 304. The computer system 302 includes at least one processor 306 for executing instructions, a memory 308, a communication interface 310, a storage interface 314, and a user interface 316 that communicate with each other via a bus 312.
In some embodiments, the database 304 is integrated within the computer system 302. For example, the computer system 302 may include one or more hard disk drives as the database 304. The storage interface 314 is any component capable of providing the processor 306 with access to the database 304. The storage interface 314 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 306 with access to the database 304.
Examples of the processor 306 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like. The memory 308 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 308 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 308 in the server system 300, as described herein. In another embodiment, the memory 308 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 300, without departing from the scope of the present disclosure.
The processor 306 is operatively coupled to the communication interface 310 such that the processor 306 is capable of communicating with a remote device 318 such as, the POS machine associated with any merchant such the merchant 106, or communicating with any cardholder such as the cardholder 104 connected to the network 116 (as shown in FIG. 1). It is noted that the server system 300 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 300 may include fewer or more components than those depicted in FIG. 3.
In one embodiment, the processor 306 includes a data pre-processing engine 320, a feature generation engine 322, a label generation engine 324, and an approval engine 326. It should be noted that the components, described herein, 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 320 includes suitable logic and/or interfaces for receiving a real-time transaction request (i.e., transaction authorization request) for a payment transaction between the cardholder 104 and the merchant 106. For instance, a cardholder ‘A’ purchases a product in a store operated by a merchant such as the merchant 106. To complete the payment for the product, the cardholder ‘A’ enters card details (such as card number, cardholder’s name, card expiration date, CVV) of their payment card on a POS machine of the merchant 106, and then the merchant 106 sends a transaction request to an acquirer such as the acquirer 108 which transmits a transaction authorization request to an issuer such as the issuer 110 associated with the cardholder 104 based on the card details of the cardholder 104. In a non-limiting example, a transaction authorization request includes at least a cardholder identifier (ID), and a merchant ID.
In another embodiment, the data pre-processing engine 320 is configured to access a cardholder profile associated with the cardholder from the database 304 based, at least in part, on the cardholder ID. Further, the data pre-processing engine 320 is configured to access a merchant profile associated with the merchant from the database 304 based, at least in part, on the merchant ID. It is noted that the process of generating the cardholder profile and the merchant profile is explained later in the present disclosure. In another embodiment, the data pre-processing engine 320 is configured to access a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID. In a non-limiting example, each disputed payment transaction of the plurality of historically disputed payment transactions includes one or more reason codes such as decline reason code (in case of the declined transaction), chargeback reason code, second presentment (or re-presentment) reason code, arbitration reason code, and the like. It is noted that the one or more reason codes indicate one or more reasons for initiating historical chargeback disputes by the cardholder 104, i.e., they indicate the past chargeback activity of the cardholder 104. In various non-limiting examples, the plurality of historically disputed payment transactions may be accessed for the past 90, 120, or 540 days. In another example, each of the plurality of historically disputed payment transactions further includes payment transaction attributes such as, but not limited to, transaction identifier, merchant name, merchant ID, merchant category code (MCC), cross-border transaction flag, payment card type (debit/credit/prepaid), card product type, transaction channel (such as e-commerce, recurring, POS), card-not-present (CNP) transaction flag, cardholder name, cardholder ID, response code flag (approve/decline), and the like. In another embodiment, the data pre-processing engine 320 is communicably coupled with the feature generation engine 322.
In an embodiment, the feature generation engine 322 includes suitable logic and/or interfaces for generating a cardholder profile of a cardholder such as the cardholder 104 associated with the cardholder ID. In particular, the feature generation engine 322 generates the cardholder profile based, at least in part, on the plurality of historically disputed payment transactions and the cardholder ID. In a non-limiting example, the cardholder profile includes various cardholder-related features such as historical dispute behavior of the cardholder, historical dispute behavior corresponding to a particular merchant, personal information identification (PII) validation, spending behavior of the cardholder, family fraud feature, and subscription activity of the cardholder. In other words, the feature generation engine 322 is configured to generate a cardholder profile including one or more cardholder-related features. In another embodiment, the feature generation engine 322 is configured to store the one or more cardholder-related features in the database 304 linked to the customer ID.
It is noted that the ‘historical dispute behavior of the cardholder’ feature indicates a likelihood of the cardholder 104 performing intentional first party fraud based on the past behavior of the cardholder 104. For example, if a cardholder has a high frequency of initiating chargeback disputes in the past, then the likelihood of them committing an intentional first party fraud is also high. In particular, the plurality of historically disputed payment transactions is analyzed by the feature generation engine 322 to determine the frequency of intentional illegitimate chargeback disputes raised by the cardholder 104. More specifically, re-presentment and arbitration reason codes associated with the plurality of historically disputed payment transactions performed by the cardholder are analyzed to determine the past behavior of the cardholder 104. It is noted that as per research conducted, 40% of first party fraudsters repeat a similar activity within a 60-day window, and 50% of first party fraudsters repeat a similar activity within a 90-day window. In a non-limiting example, a pseudo-code for determining the historical dispute behavior of the cardholder feature is given as follows:
Likelihood of first party fraud = Count/Amount of disputes by a card in past {X} number of days (X: 30, 60, 90,120 days) + Count/Amount of Total/Resolved/Rejected disputes by a card in {X} number of days + Count/Amount of disputes by card in Chargeback in last {X} number of days (reason code wise) + Count/Amount of disputes by card re-presentment in last {X} number of days (reason code wise) + Count/Amount of disputes which were filed as arbitration case in last {X} days + Count/Amount of transaction by the card after the transaction and before the dispute was raised + Total approved transactions of card in last {X} days + Total Non-sufficient Funds (NSF) declined transactions and rate of NSF declines of the card in the last {X} days + Count/Amount of transaction which were refunded (win rate) + Age of Cardholder in system – Months between first transaction on the card & the previous/current transaction + Count/Amount of transaction by card before/after the raised dispute + Distinct recurring merchant/industry/mcc for card in last {X} days + High Ratio of chargebacks challenged by Merchant + High Ratio of disputes won by acquirer in arbitration.

In an embodiment, the ‘historical dispute behavior corresponding to a particular merchant’ feature indicates a likelihood of the cardholder 104 performing intentional first party fraud with a particular merchant such as the merchant 106 based on the past behavior of the cardholder 104. For example, if a cardholder has a high frequency of initiating chargeback disputes against a particular in the past, then the likelihood of them committing an intentional first party fraud is also high. In particular, the plurality of historically disputed payment transactions is analyzed by the feature generation engine 322 to determine the frequency of chargeback disputes raised by the cardholder 104 against the merchant 106. In a non-limiting example, a pseudo-code for determining historical dispute behavior corresponding to a particular merchant feature is given as follows:
Likelihood of first party fraud = Ratio of Number of disputed transactions on Merchant to Total transaction + Ratio of Number of disputed transactions of MCC to Total transaction on MCC + Age of Cardholder on Merchant – Months between first and previous/current transaction on this merchant/industry/MCC + High/low/Medium historic spend profile of Cardholder on this Merchant/industry + Count/Amount of transaction of the card at the merchant in the past, Flag: Cardholder ever disputed transaction at this merchant + Total approved transaction of the card in last {days} at merchant + Total NSF declined transactions of the card in last {days} at merchant/industry/MCC

In an embodiment, the ‘Personal identifiable information (PII) validation’ feature indicates a likelihood of the cardholder 104 performing first party fraud with the merchant 106 based on comparing 3DS2 data corresponding to the transaction with 3DS2 data corresponding to a plurality of historically disputed transactions corresponding to the cardholder 104. In particular, the feature generation engine 322 compares the 3DS2 data of the ongoing transaction with historically disputed transactions and determines if the same PII is present between the ongoing transaction and the plurality of historically disputed transactions. In a non-limiting example, a pseudo-code for determining the PII validation feature for the cardholder is given as follows:
Likelihood of first party fraud = IP address, Device ID of Disputed transaction = Last 3 IP address, Device ID of the cardholder as used in an undisputed transaction, Flag if the same email was used in last good transaction and last 3 transactions, Flag if a same name was used in last good transaction and last 3 transactions, Flag if same IP used in last good transaction & last 3 transactions, Decision Intelligence score is above 800, Decision Intelligence score is below 200

In an embodiment, the ‘spending behavior of the cardholder’ feature indicates a likelihood of the cardholder performing first party fraud if a disputed transaction aligns with the past spending behavior of the cardholder 104. In a non-limiting example, a pseudo-code for determining the spending behavior of the cardholder feature is given as follows:
Likelihood of first party fraud = Cardholder disputing no authorized transaction on Merchant is high spender on this Merchant category

In an embodiment, the ‘family fraud’ feature indicates a likelihood of the cardholder 104 performing an unintentional first party fraud by raising a chargeback dispute without realizing that a child of the cardholder 104 has performed the transaction without the approval of the cardholder 104. In a non-limiting example, a pseudo-code for determining the family fraud feature is given as follows:
Likelihood of first party fraud = High number of previous CP Transaction on [children's toy stores, children apparel, Child education] + Online gaming Transaction + High historic dispute velocity of Cardholder + Count/Amount of Disputes raised for CNP transactions by a card at Children related Industry Merchants

In an embodiment, the ‘subscription activity of the cardholder’ feature indicates a likelihood of the cardholder 104 performing an unintentional first party fraud by raising a chargeback dispute for a payment transaction without realizing that the payment transaction is a recurring payment transaction for a subscription purchased by the cardholder 104. In particular, the feature generation engine 322 generates the subscription activity of the cardholder feature based on determining if the cardholder 104 has a history of disputing recurrent transactions associated with subscription services offered by different merchants. In a non-limiting example, a pseudo-code for determining the subscription activity of the cardholder feature is given as follows:
Likelihood of first party fraud = Velocity of disputed Transactions after account status inquiry (ASI) Transaction on other recurring merchants + NSF velocity of card

In another embodiment, the feature generation engine 322 is configured to generate a merchant profile of a merchant such as the merchant 106 associated with the merchant ID. In particular, the feature generation engine 322 generates the merchant profile based, at least in part, on the plurality of historically disputed payment transactions and the merchant ID. In a non-limiting example, the merchant profile includes various merchant-related features such as historical dispute and chargeback rate of the merchant, merchant response on dispute raised, and merchant name discrepancy. In other words, the feature generation engine 322 is configured to generate a merchant profile including one or more merchant-related features. In another embodiment, the feature generation engine 322 is configured to store the one or more merchant-related features in the database 304 linked to the merchant ID.
In an embodiment, the ‘historical dispute and chargeback rate of the merchant’ feature indicates a likelihood of a merchant (such as the merchant 106) being a victim of a first party fraud by the cardholder 104. In an example, the likelihood of first party fraud on a disputed transaction is high, if the transaction is performed at the merchant 106 with a historically low fraud rate and high in-favour dispute resolution rate. In a non-limiting example, a pseudo-code for determining the historical dispute and chargeback rate of the merchant feature is given as follows:
Likelihood of first party fraud = High Dispute velocity of card + Low fraud rate on Merchant + High Merchant favored dispute rate + Ticket size, industry, MCC, region, trace_id, CP/CMP, etc. + Count/Amount of transaction previously disputed at the Merchant + Difference in days between disputed transaction and last approved transaction on the Merchant + Fraud rate of Merchant + Ratio of disputes won by merchant (win rate) + Count/Amount of transaction on Merchant post a disputed transaction to now.

In an embodiment, the ‘merchant response on dispute raised’ feature indicates a likelihood of first party fraud based on analyzing the merchant’s response (including documentation submitted as evidence) during the chargeback process and determining that the merchant 106 believes that the disputed transaction is a first party fraud. It is noted that various natural language processing techniques may be used by the feature generation engine 322 to analyze the merchant’s response. In a non-limiting example, a pseudo-code for determining the merchant response on dispute raised feature is given as follows:
Likelihood of first party fraud = Merchant response contains “Attempt to commit Fraud”, “Friendly Fraud”, “Account blocked”, “Refund declined”, “Suspicious activity” + Count of transactions for different Merchant Dispute Responses.

In an embodiment, the ‘merchant name discrepancy’ feature indicates a likelihood of the cardholder 104 performing an unintentional first party fraud by raising a chargeback dispute due to being confused about the merchant name. As may be understood, if there is a discrepancy in the DBA name of the merchant on their store and their registered name with the acquirer 108, then its highly likely that the cardholder 104 may think that they have not performed a particular transaction due to it being associated with an unknown name, i.e., the registered name of the merchant on their transaction statement. In a non-limiting example, a pseudo-code for determining the merchant response on dispute raised feature is given as follows:
Likelihood of first party fraud = Text Match (Merchant_dba_Name, Cleaned Merchant_Name) < Threshold (the threshold being predefined by an administrator based on risk appetite)

In an embodiment, the feature generation engine 322 is communicably coupled with the label generation engine 324. In another embodiment, the label generation engine 324 includes suitable logic and/or interfaces for extracting one or more reason codes from the plurality of historically disputed payment transactions. It is noted that the one or more reason codes indicate one or more reasons due to which a chargeback dispute was raised by the cardholder 104 and how the dispute was eventually settled. In a non-limiting example, the one or more reason codes extracted by the label generation engine 324 include a decline reason code (in case of the declined transaction), a chargeback reason code, a second presentment (or re-presentment) reason code, an arbitration reason code, and the like.
In another embodiment, the label generation engine 324 is configured to generate label data for the transaction authorization request based, at least in part, on the one or more reason codes. In an alternative embodiment, the label generation engine 324 is configured to generate label data for the chargeback dispute initiation request initiated by the cardholder 104 based, at least in part, on the one or more reason codes. In particular, the label generation engine 324 generates label data based, at least in part, on an end state associated with the one or more reason codes corresponding to each of the plurality of historically disputed payment transactions. In a non-limiting example, the end state is at least one of resolved during collaboration, resolved during chargeback, resolved during re-presentment, and resolved during the arbitration. Then, the label generation engine 324 is configured to determine if each of the plurality of historically disputed payment transactions is one of a first party fraud payment transaction and a third-party fraud payment transaction based on the end state indicated by the one or more reason codes corresponding to each of the plurality of historically disputed payment transaction. Further, the label generation engine 324 is configured to label each of the plurality of historically disputed payment transactions as one of a first party fraud payment transaction and a third party fraud payment transaction. Further, storing the plurality of labeled first party fraud payment transactions as label data. In another embodiment, the label generation engine 324 is communicably coupled with the approval engine 326.
In an embodiment, the approval engine 326 includes suitable logic and/or interfaces for determining a dispute likelihood score based, at least in part, on the cardholder profile and merchant profile. In one non-limiting example, the determination of the dispute likelihood score is done by utilizing a first machine learning model. In an example, the first machine learning model may be an AI or ML model. In a non-limiting example, the first machine learning model is a binary classification model such as boosted tree-based binary classification model, extreme gradient boosting decision tree model, and the like. In particular, the approval engine 326 uses the one or more features included in the cardholder profile and merchant profile to determine the dispute likelihood score (described later in the present disclosure).
In another embodiment, the approval engine 326 is further configured to determine a first party fraud score based, at least in part, on the dispute likelihood score, and the label data. In one non-limiting example, the determination of the dispute likelihood score is done by utilizing a second machine learning model. In an example, the second machine learning model may be an AI or ML model. In a non-limiting example, the second first machine learning model is a binary classification model such as boosted tree-based binary classification model, extreme gradient boosting decision tree model, and the like. In particular, the approval engine 326 uses the dispute likelihood score, and the plurality of labeled first party fraud payment transactions stored in the label data to determine the first party fraud score (described later in the present disclosure).
In another embodiment, the approval engine 326 is configured to invalidate or decline the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold. In a non-limiting example, the predetermined threshold is determined or configured by an administrator (not shown) associated with either the acquirer 108 or the issuer 110 based on their internal policies and risk appetite. Further, upon determining that the first party fraud score is greater than the predetermined threshold, the approval engine 326 is configured to transmit a transaction declined message to the acquirer 108. In an example, the transaction declined message includes a first party fraud flag set as ‘1’ or unity indicating that the transaction authorization request corresponds to a first party fraud transaction. For example, if the predetermined threshold is configured as 0.70, then if the determined FPF score is 0.80, the approval engine 326 invalidates or declines the transaction authorization request via transmitting the transaction declined message. In an alternative embodiment, the approval engine 326 is configured to validate or authorize the transaction authorization request based, at least in part, on the first party fraud score being lower than the predetermined threshold. Further, upon determining that the first party fraud score is lower than the predetermined threshold, the approval engine 326 is configured to transmit a transaction authorization message to the acquirer 108. In an example, the transaction authorization message includes a first party fraud flag set as ‘0’ or zero indicating that the transaction authorization request doesn’t correspond to a first party fraud transaction. In some scenarios, the first party fraud flag being set as zero may indicate that the transaction authorization request corresponds to a third-party fraud or authorization-related dispute.
In another embodiment, the approval engine 326 is configured to invalidate or decline the chargeback dispute initiation request based, at least in part, on the first party fraud score being greater than a predetermined threshold. Further, upon determining that the first party fraud score is greater than the predetermined threshold, the approval engine 326 is configured to transmit a chargeback dispute declined message to the issuer 110. In an example, the chargeback dispute declined message includes a first party fraud flag set as ‘1’ or unity indicating that the chargeback dispute initiation request corresponds to a first party fraud transaction. For example, if the predetermined threshold is configured as 0.80, then if the determined FPF score is 0.90, the approval engine 326 invalidates or declines the chargeback dispute initiation request via transmitting the chargeback dispute declined message. In an alternative embodiment, the approval engine 326 is configured to validate or authorize the chargeback dispute initiation request based, at least in part, on the first party fraud score being lower than the predetermined threshold. Further, upon determining that the first party fraud score is lower than the predetermined threshold, the approval engine 326 is configured to transmit a chargeback dispute authorization message to the issuer 110. In an example, the chargeback dispute authorization message includes a first party fraud flag set as ‘0’ or zero indicating that the chargeback dispute initiation request doesn’t correspond to a first party fraud transaction. In some scenarios, the first party fraud flag being set as zero may indicate that the chargeback dispute initiation request corresponds to a third-party fraud or authorization-related dispute.
FIG. 4 illustrates a schematic block diagram representation for detecting first party fraud for payment transactions, in accordance with an embodiment of the present disclosure. In an embodiment, upon receiving the transaction authorization request message such as transaction authorization request message 402 for a real-time transaction between a cardholder (such as cardholder 104) and a merchant (such as merchant 106), the system (such as server system 300) is configured to determine whether the real-time transaction corresponds to a first party fraud transaction or not. At first, the server system 300 extracts a cardholder ID, merchant ID, and one or more reason codes from the transaction authorization message 402. Then, the server system 300 is configured to access a cardholder profile and a merchant profile associated with the cardholder 104 and the merchant 106 from a database (such as database 304), respectively using the cardholder ID, and merchant ID. Further, the server system 300 is configured to access a plurality of historically disputed payment transactions associated with the cardholder 104 based on the cardholder ID. Then, the server system 300 extracts one or more reason codes from the plurality of historically disputed payment transactions and generates label data using the one or more reason codes for the transaction authorization message 402.
Further, the server system is configured to determine using a first machine learning model (such as first machine learning model 328) a dispute likelihood score based, at least in part, on the cardholder profile and the label data. In a non-limiting example, the first machine learning 328 may be a decision tree-based classification model. As may be understood, decision trees are classification models which take a set of input features and splits an input dataset based on the inputted features as output. Illustratively, the splits made in the input data look like a leaf node of a tree. Further, the splits classify the input dataset into different leaves wherein each leaf node has maximum purity, i.e., each leaf node has a majority of the classes. For example, transaction data can be split into fraud and non-fraud categories based on fraud-related features. This feature of decision trees is further amplified using boosted tree-based classification models. In boosted tree-based classification models, multiple decision trees (known as weak learners) are utilized. These trees are combined to build a stronger classifier based on voting. Voting may be described as a machine learning estimator that trains various base models (i.e., multiple decision trees) and predicts based on aggregating the findings of each base model. The aggregated finding from the various base models is the output of the voting process. A pseudo-code for training a generic boosted tree classification model is given below:
Each tree is created iteratively
The tree’s output (h(x)) is given a weight (w) relative to its accuracy
The ensemble output is the weighted sum: y ̂(x)= ∑_t▒〖w_t h_t (x)〗
After each iteration (time t) each data sample is given a weight based on its misclassification and a new weak learner is added (h_t).
The more often a data sample is misclassified, the more important it becomes.
The goal is to minimize an objective function: O(x)= ∑_i▒l(y ̂_i,y_i ) + ∑_i▒Ω(f_t )
l(y ̂_i,y_i ): is the loss function --- the distance between the truth (y_i) and the prediction of the ith sample (y ̂_i).
Ω(f_t ): is the regularization function --- it penalizes the complexity of the ith tree to ensure that there is no overfitting.

It is noted that various boosting models are based on this principle but differ in their corresponding formulation of loss and regularization functions.

In another embodiment, the first machine learning model 328 is an eXtreme Gradient Boosting (XGBoost) type boosted tree classification model. The XGBoost model represents the objective function at a time ‘t’ as:
O^((t)) (x)= ∑_i▒l((y^((t) ) ) ̂_i,y_i ) + ∑_i▒Ω(f_t ) = ∑_i▒l((y^((t-1) ) ) ̂_i+ f_t (x_i),y_i ) + ∑_i▒Ω(f_t ) … Eqn. 1
Upon expanding Eqn. 1 using a series expanding method such as Taylor expansion, we receive:
O^((t)) (x) □(∶=) = ∑_i▒〖[l((y^((t-1) ) ) ̂_i,y_i )+ g_i f_t (x_i )+ 1/2 h_i f_i^2 (x_i )]〗+ ∑_i▒Ω(f_t ) … Eqn. 2
g_i= ∂_(y^((t-1) ) ) ̂ l((y^((t-1) ) ) ̂_i,y_i) … Eqn. 3
h_i= ∂_(y^((t-1) ) ) ̂^2 l((y^((t-1) ) ) ̂_i,y_i) … Eqn. 4
Herein, the regularization function is denoted by the following equation:
Ω(f_t )= γT+ 1/2 λ∑_i▒w_i^2 … Eqn. 5
In the above Eqn. 5, T is the number of leaf nodes in the tth weak learner. Further, the symbols γ and λ are hyperparameters.
In the present implementation, the first machine learning model 328 is trained with a dispute label (i.e., using the label data) as the target column. Further, classification of the transaction corresponding to the transaction authorization request message 402 is performed by the first machine learning model 328 based on the cardholder-related features and the merchant-related features included in the cardholder profile and the merchant profile respectively. It is understood that the output of the first machine learning model 328 indicates the dispute likelihood score. In an example, the first machine learning model 328 assigns a label = 1 if it is decided that the considered transaction will be disputed in the future. Otherwise, a label = 0 is assigned. Further, the cardholder-related features and the merchant-related features are used to train the first machine learning model 328 to accurately provide a probability (i.e., dispute likelihood score) for each transaction to be disputed in the future.
Further, the output of the first machine learning model 328 is fed as input to the second machine learning model 330 along with the previously determined label data by the server system 300. In a non-limiting example, the first machine learning 328 may be a decision tree-based classification model such as the XGBoost model (similar to the first machine learning model 328). The operation of the XGBoost model is not described again for the sake of brevity.
In the present implementation, the second machine learning model 330 is trained with first party fraud label as the target column. In an example, the second machine learning model 330 assigns a label = 1 if it is determined based on the output of the first machine learning model 328 and the label data that the transaction was reported as first party fraud in the future. Otherwise, a label = 0 is assigned. Further, the dispute likelihood score and historical label data can be used to train the first machine learning model 328 so as to accurately provide a probability (i.e., first party fraud score) for each transaction to be reported as a first party fraud transaction. In some scenarios, the server system 300 is configured to label the ongoing transaction as a first-party related dispute by setting a flag as 1 based on the prediction of the first party fraud score (see, 404). Otherwise, the server system 300 is configured to label the ongoing transaction as third-party related dispute by setting a flag as 0 based on the prediction of the first party fraud score (see, 406).
Further, the server system 300 is configured to validate the transaction authorization request based, at least in part, on the first party fraud score being lower than a predetermined threshold. Alternatively, the server system 300 is configured to invalidate the transaction authorization request based, at least in part, on the first party fraud score being greater than the predetermined threshold.
In an alternative embodiment, a chargeback dispute initiation request is analyzed by the server system 300 instead of the transaction authorization request message 402. Similarly to the previous embodiments, a first party fraud score is computed for the chargeback dispute initiation request. If the first party fraud score is lower than a predetermined threshold, then the chargeback dispute initiation request is authorized. Otherwise, the chargeback dispute initiation request is declined.
FIG. 5 represents a flow chart of a computer-implemented method 500 for determining if a transaction authorization request for a payment transaction initiated by the cardholder with the merchant corresponds to a first party fraud payment transaction, in accordance with an embodiment of the present disclosure. The method 500 depicted in the flow chart may be executed by, for example, a computer system. The computer system is identical to the server system 300. Operations of the flow chart of the method 500, and combinations of operations in the flow chart of the method 500, 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. It is noted that the operations of the method 500 can be described and/or practiced by using a system other than these computer systems. The method 500 starts at operation 502.
At operation 502, the method 500 includes receiving, by a server system 300, a transaction authorization request for a payment transaction initiated by a cardholder with a merchant. The transaction authorization request includes at least a cardholder identifier (ID), a merchant ID, and one or more reason codes.
At operation 504, the method 500 includes accessing, by the server system 300, a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID.
At operation 506, the method 500 includes accessing, by the server system 300, a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID.
At operation 508, the method 500 includes extracting, by the server system 300, one or more reason codes from the plurality of historically disputed payment transactions. The one or more reason codes may indicate one or more reasons for initiating historical chargeback disputes by the cardholder 104.
At operation 510, the method 500 includes generating, by the server system 300, label data for the transaction authorization request based, at least in part, on the one or more reason codes.
At operation 512, the method 500 includes determining, by the server system 300 via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and merchant profile.
At operation 514, the method 500 includes determining, by the server system 300 via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data.
At operation 516, the method 500 includes invalidating, by the server system 300, the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold.
The sequence of operations of the method 500 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
FIG. 6 represents a flow chart of a computer-implemented method 600 for determining if a chargeback dispute initiation request for a payment transaction initiated by the cardholder with the merchant corresponds to a first party fraud payment transaction, in accordance with an embodiment of the present disclosure. The method 600 depicted in the flow chart may be executed by, for example, a computer system. The computer system is identical to the server system 300. Operations of the flow chart of the method 600, and combinations of operations in the flow chart of the method 600, 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. It is noted that the operations of the method 600 can be described and/or practiced by using a system other than these computer systems. The method 600 starts at operation 602.
At operation 602, the method 600 includes receiving, by a server system 300, a chargeback dispute initiation request includes at least a cardholder identifier (ID), a merchant ID, and a reason code for initiating a chargeback dispute.
At operation 604, the method 600 includes accessing, by the server system 300, a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID.
At operation 606, the method 600 includes accessing, by the server system 300, a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID.
At operation 608, the method 600 includes extracting, by the server system 300, one or more reason codes from the plurality of historically disputed payment transactions. The one or more reason codes may indicate one or more reasons for initiating historical chargeback disputes by the cardholder 104.
At operation 610, the method 600 includes generating, by the server system 300, label data for the chargeback dispute initiation request initiated by the cardholder 104 based, at least in part, on the one or more reason codes.
At operation 612, the method 600 includes determining, by the server system 300 via a first machine learning model, a dispute likelihood score for the chargeback dispute initiation request based, at least in part, on the cardholder profile and merchant profile.
At operation 614, the method 600 includes determining, by the server system 300 via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data.
At operation 616, the method 600 includes declining, by the server system 300, the chargeback dispute initiation request based, at least in part, on the first party fraud score being greater than a predetermined threshold.
The sequence of operations of the method 600 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
Further, it is noted that although the various embodiments described herein relate to the financial or payment domain, the same should not be construed as limiting. In effect, the various embodiments of the present disclosure can be applied to various applications without departing from the scope of the present disclosure as well.
FIG. 7 is a simplified block diagram of a payment server 700, in accordance with an embodiment of the present disclosure. The payment server 700 is an example of the payment server 114 of FIG. 1. The payment server 700 and the server system 300 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 700 includes a processing system 705 configured to extract programming instructions from a memory 710 to provide various features of the present disclosure. The components of the payment server 700 provided herein may not be exhaustive and the payment server 700 may include more or fewer components than those depicted in FIG. 7. 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 700 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
Via a communication interface 715, the processing system 705 receives a request from a remote device 720, such as the issuer server 110 or the acquirer server 108. 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 700 includes a database 725. The database 725 also includes transaction processing data such as issuer ID, cardholder ID, country code, acquirer ID, merchant ID, among others.
When the payment server 700 receives a payment transaction request from the acquirer server 108 or a payment terminal (e.g., point of sale (POS) device, etc.), the payment server 700 may route the payment transaction request to an issuer server (e.g., the issuer server 110). The database 725 stores transaction identifiers for identifying transaction details (such as transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like).
In one example embodiment, the acquirer server 108 is configured to send an authorization request message to the payment server 700. The authorization request message includes, but is not limited to, the payment transaction request.
The processing system 705 further sends the payment transaction request to the issuer server 110 for facilitating the payment transactions from the remote device 720. The processing system 705 is further configured to notify the remote device 720 of the transaction status in form of an authorization response message via the communication interface 715. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 110. Alternatively, in one embodiment, the processing system 705 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 715, to the acquirer server 108.
In one embodiment, the database 725 is also configured to store historical clearing and chargeback activities associated with the plurality of cardholders. In an example, the database 725 may store information about transactions performed by the cardholder (e.g., the cardholder 104) at a plurality of merchants (e.g., the merchant 106).
FIG. 8 is a simplified block diagram of an issuer server 800, in accordance with an embodiment of the present disclosure. The issuer server 800 is an example of the issuer server 110 of FIG. 1. The issuer server 800 is associated with an issuer bank/issuer, in which a cardholder (e.g., the cardholder 104) may have an account, which provides a payment card. The issuer server 800 includes a processing module 805 operatively coupled to a storage module 810 and a communication module 815. The components of the issuer server 800 provided herein may not be exhaustive and the issuer server 800 may include more or fewer components than those depicted in FIG. 8. 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 issuer server 800 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
The storage module 810 is configured to store machine executable instructions to be accessed by the processing module 805. Additionally, the storage module 810 stores information related to, the contact information of the cardholder 104, bank account number, availability of funds in the account, payment card details, transaction details, payment account details, and/or the like. Further, the storage module 810 is configured to store payment transactions.
In one embodiment, the issuer server 800 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder (i.e., the cardholder 104), account identification information, payment card number, etc.) in the database 118. The details of the cardholder 104 may include, but not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder 104, etc.
The processing module 805 is configured to communicate with one or more remote devices such as a remote device 820 using the communication module 815 over a network such as the network 116 of FIG. 1. The examples of the remote device 820 include the server system 300, the payment server 114, the database 118 or other computing systems of the issuer server 800 and the network 116 and the like. The communication module 815 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 815 is configured to receive a payment transaction request performed by the cardholder (i.e., the cardholder 104) via the network 116. The processing module 805 receives payment card information, payment transaction amount, customer information, and merchant information from the remote device 820 (e.g., the payment server 114). The issuer server 800 includes a transaction database 830 for storing transaction data. In an example, the transaction database 830 is similar to the database 118.
The payment transaction data may include, but not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past x days to a particular cardholder, transaction location information, external data sources and other internal data to evaluate each transaction. The issuer server 800 includes a user profile database 825 storing user profiles associated with the plurality of cardholders. In one embodiment, the issuer server 800 is also configured to store historical fraudulent chargeback activities associated with the plurality of cardholders in a fraud database 835. The user profile data may include an account balance, a credit line, details of the cardholder (i.e., the cardholder 104), account identification information, payment card number, or the like. The details of the cardholder (i.e., the cardholder 104) may include, but not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder (i.e., the cardholder holder 104).
The one or more operations of the server system 300 that are disclosed with reference to FIGS. 1 to 8 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during the 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 a suitable communication means includes, 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 invention 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 invention. 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 300 and its various components 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 invention 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 from those which, are disclosed. Therefore, although the invention has been described based on 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:
receiving, by a server system, a transaction authorization request for a payment transaction initiated by a cardholder with a merchant, the transaction authorization request comprising at least a cardholder identifier (ID), a merchant ID, and one or more reason codes;
accessing, by the server system, a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID;
accessing, by the system, a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID;
extracting, by the system, one or more reason codes from the plurality of historically disputed payment transactions, the one or more reason codes indicating one or more reasons for initiating historical chargeback disputes by the cardholder;
generating, by the server system, label data for the transaction authorization request based, at least in part, on the one or more reason codes;
determining, by the server system via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and the merchant profile;
determining, by the server system via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and the label data; and
invalidating, by the server system, the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold.

2. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, the cardholder profile comprising cardholder-related features based at least in part on the plurality of historically disputed payment transactions and the cardholder ID, the cardholder-related features comprising at least one of (a) historical dispute behavior of the cardholder, (b) historical dispute behavior corresponding to a particular merchant, (c) personal information identification (PII) validation, (d) spending behavior of the cardholder, (e) family fraud feature, and (f) subscription activity of the cardholder.

3. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, the merchant profile comprising merchant-related features based, at least in part, on the plurality of historically disputed payment transactions and the merchant ID, the merchant-related features comprising at least one of (a) historical dispute and chargeback rate of the merchant, (b) merchant response on dispute raised, and (c) merchant name discrepancy.

4. The computer-implemented method as claimed in claim 1, wherein generating the label data, further comprises:
determining, by the server system, an end state associated with the one or more reason codes corresponding to each of the plurality of historically disputed payment transactions, the end state being at least one of resolved during collaboration, resolved during chargeback, resolved during re-presentment, and resolved during the arbitration;
determining, by the server system, if each of the plurality of historically disputed payment transactions is one of a first party fraud payment transaction and a third-party fraud payment transaction based, at least in part, on the end state;
labeling, by the server system, the each of the plurality of historically disputed payment transactions as one of the first party fraud payment transaction and the third-party fraud payment transaction based at least in part on the determining step; and
storing, by the server system, a plurality of labeled first party fraud payment transactions as the label data.

5. The computer-implemented method as claimed in claim 1, further comprising:
validating, by the server system, the transaction authorization request based, at least in part, on the first party fraud score being lower than the predetermined threshold.

6. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, a chargeback dispute initiation request comprising at least a cardholder identifier (ID), a merchant ID, and a reason code for initiating a chargeback dispute;
accessing, by the server system, a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID;
accessing, by the system, a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID;
extracting, by the system, one or more reason codes from the plurality of historically disputed payment transactions, the one or more reason codes indicating one or more reasons for initiating historical chargeback disputes by the cardholder;
generating, by the server system, label data for the chargeback dispute initiation request initiated by the cardholder based, at least in part, on the one or more reason codes;
determining, by the server system via a first machine learning model, a dispute likelihood score for the chargeback dispute initiation request based, at least in part, on the cardholder profile and merchant profile;
determining, by the server system via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data; and
declining, by the server system, the chargeback dispute initiation request based, at least in part, on the first party fraud score being greater than a predetermined threshold.

7. The computer-implemented method as claimed in claim 6, further comprising:
authorizing, by the server system, the chargeback dispute initiation request based, at least in part, on the first party fraud score being lower than the predetermined threshold.

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

9. The computer-implemented method as claimed in claim 1, wherein the first machine learning model and the second machine learning models are binary classification models.

10. The computer-implemented method as claimed in claim 1, wherein the one or more reason codes comprises at least one of decline reason code, chargeback reason code, re-presentment reason code, and arbitration reason code.

11. A server system, comprising:
a communication interface;
a memory comprising machine-readable instructions; and
a processor communicably coupled to the communication interface and the memory, the processor configured to execute the machine-readable instructions to cause the server system at least in part to:
receive a transaction authorization request for a payment transaction initiated by a cardholder with a merchant, the transaction authorization request comprising at least a cardholder identifier (ID), a merchant ID, and one or more reason codes;
access a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID;
access a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID;
extract one or more reason codes from the plurality of historically disputed payment transactions, the one or more reason codes indicating one or more reasons for initiating historical chargeback disputes by the cardholder;
generate label data for the transaction authorization request based, at least in part, on the one or more reason codes;
determine via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and merchant profile;
determine via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data; and
invalidate the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold.

12. The server system as claimed in claim 11, wherein the server system is further caused, at least in part, to:
generate a cardholder profile comprising cardholder-related features based, at least in part, on the plurality of historically disputed payment transactions and the cardholder ID, the cardholder-related features comprising at least one of (a) historical dispute behavior of the cardholder, (b) historical dispute behavior corresponding to a particular merchant, (c) personal information identification (PII) validation, (d) spending behavior of the cardholder, (e) family fraud feature, and (f) subscription activity of the cardholder.

13. The server system as claimed in claim 11, wherein the server system is further caused, at least in part, to:
generate a merchant profile comprising merchant-related features based, at least in part, on the plurality of historically disputed payment transactions and the merchant ID, the merchant-related features comprising at least one of (a) historical dispute and chargeback rate of the merchant, (b) merchant response on dispute raised, and (c) merchant name discrepancy.

14. The server system as claimed in claim 11, wherein to generate the label data, the server system is further caused, at least in part, to:
determine an end state associated with the one or more reason codes corresponding to each of the plurality of historically disputed payment transactions, the end state being at least one of resolved during collaboration, resolved during chargeback, resolved during re-presentment, and resolved during the arbitration;
determine if each of the plurality of historically disputed payment transactions is one of a first party fraud payment transaction and a third-party fraud payment transaction based, at least in part, on the end state;
label the each of the plurality of historically disputed payment transactions as one of a first party fraud payment transaction and a third-party fraud payment transaction based at least in part on the determining step; and
store a plurality of labeled first party fraud payment transactions as label data.

15. The server system as claimed in claim 11, wherein the server system is further caused, at least in part, to:
validate the transaction authorization request based, at least in part, on the first party fraud score being lower than the predetermined threshold.

16. The server system as claimed in claim 11, wherein the server system is further caused, at least in part, to:
receive a chargeback dispute initiation request comprising at least a cardholder identifier (ID), a merchant ID, and a reason code for initiating a chargeback dispute;
access a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID;
access a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID;
extract one or more reason codes from the plurality of historically disputed payment transactions, the one or more reason codes indicating one or more reasons for initiating historical chargeback disputes by the cardholder;
generate label data for the chargeback dispute initiation request initiated by the cardholder based, at least in part, on the one or more reason codes;
determine via a first machine learning model, a dispute likelihood score for the chargeback dispute initiation request based, at least in part, on the cardholder profile and merchant profile;
determine via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data; and
decline the chargeback dispute initiation request based, at least in part, on the first party fraud score being greater than a predetermined threshold.

17. The computer-implemented method as claimed in claim 16, further comprising:
authorize the chargeback dispute initiation request based, at least in part, on the first party fraud score being lower than the predetermined threshold.

18. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method comprising:
receiving a transaction authorization request for a payment transaction initiated by a cardholder with a merchant, the transaction authorization request comprising at least a cardholder identifier (ID), a merchant ID, and one or more reason codes;
accessing a cardholder profile associated with the cardholder and a merchant profile associated with the merchant from a database based, at least in part, on the cardholder ID and the merchant ID;
accessing a plurality of historically disputed payment transactions associated with the cardholder based, at least in part, on the cardholder ID;
extracting one or more reason codes from the plurality of historically disputed payment transactions, the one or more reason codes indicating one or more reasons for initiating historical chargeback disputes by the cardholder;
generating label data for the transaction authorization request based, at least in part, on the one or more reason codes;
determining via a first machine learning model, a dispute likelihood score based, at least in part, on the cardholder profile and the merchant profile;
determining via a second machine learning model, a first party fraud score based, at least in part, on the dispute likelihood score, and label data; and
invalidating the transaction authorization request based, at least in part, on the first party fraud score being greater than a predetermined threshold.

19. The non-transitory computer-readable storage medium as claimed in claim 18, further comprising:
generating the cardholder profile comprising cardholder-related features based at least in part on the plurality of historically disputed payment transactions and the cardholder ID, the cardholder-related features comprising at least one of (a) historical dispute behavior of the cardholder, (b) historical dispute behavior corresponding to a particular merchant, (c) personal information identification (PII) validation, (d) spending behavior of the cardholder, (e) family fraud feature, and (f) subscription activity of the cardholder.

20. The non-transitory computer-readable storage medium as claimed in claim 18, further comprising:
generating a merchant profile comprising merchant-related features based, at least in part, on the plurality of historically disputed payment transactions and the merchant ID, the merchant-related features comprising at least one of (a) historical dispute and chargeback rate of the merchant, (b) merchant response on dispute raised, and (c) merchant name discrepancy.