METHODS AND SYSTEMS FOR PREDICTING CHARGEBACK BEHAVIORAL DATA OF ACCOUNT HOLDERS
Embodiments provide methods and systems for predicting chargeback behavioral data of an account holder. The method performed by a server system includes accessing payment transaction data associated with the account holder from a transaction database. The payment transaction data includes a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period. The method further includes generating a set of transaction features based on the set of transaction indicators. Furthermore, the method includes computing, via a chargeback risk prediction model, a set of chargeback risk probability scores corresponding to one or more time intervals associated with the account holder based, at least in part, on the set of transaction features. The method also includes transmitting a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores.
This application claims priority to Indian Patent Provisional Application No. 202141020933, filed May 8, 2021, which is incorporated herein by reference in its entirety.
TECHNICAL FIELDThe present disclosure relates to payment account networks and, more particularly to, electronic methods and complex processing systems for predicting chargeback behavioral data of account holders based on artificial intelligence techniques.
BACKGROUNDNowadays a huge volume of electronic payment transactions is performed by either consumers' mobile devices or payment cards with very much ease. However, with ease of performing electronic payment transactions online, also manifests complexities for merchants and/or service providers that facilitate the electronic payment transactions. In one example, since an electronic transaction between an account holder and a merchant may be disputed within a time period after the electronic transaction has occurred, the amount that is charged for the electronic transaction may be held (e.g., by a payment server) for a duration before being released to the merchant. The consumer may subsequently dispute the electronic transaction due to many reasons, such as a wrong amount being charged, unsatisfied with the product received, delivery problems, etc. This process of handling such disputes is called a chargeback. For example, an account holder may return the goods to the merchant, and then raise a chargeback request with an issuing bank for the return of the payment amount back to a payment account associated with the account holder. In general, an issuing bank immediately issues a credit for the payment amount of the transaction to the payment account of the account holder. Further, the issuing bank sends the chargeback request to a payment network. To address any chargeback requests, the issuing bank needs to pay a fee to get a procedure started to determine which entity (e.g., issuer, acquirer, merchant, or the account holder) will be left with the cost of the purchase of the goods or services.
In some cases, the merchant may also dispute the chargeback with the assistance of the acquiring bank. In general, the acquiring bank is associated with the merchant. Further, the issuing bank and the acquiring bank may attempt to mediate the chargeback through a dispute process. However, performing the dispute process uses valuable banking resources and takes up additional processing time to resolve the chargeback request. Moreover, if the issuing bank and the acquiring bank cannot agree to the chargeback request, a payment processor is responsible to solve the dispute and conclude to a final decision, using additional valuable resources.
Thus, there exists a need for a technical solution to overcome the above-stated disadvantages.
SUMMARYVarious embodiments of the present disclosure provide methods and systems for predicting chargeback behavioral data of an account holder.
In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes accessing payment transaction data associated with an account holder from a transaction database. The payment transaction data includes a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period. The method further includes generating a set of transaction features based, at least in part, on the set of transaction indicators. Furthermore, the method includes computing, via a chargeback risk prediction model, a set of chargeback risk probability scores corresponding to one or more time intervals associated with the account holder based, at least in part, on the set of transaction features. Each of the set of chargeback risk probability scores indicates future chargeback behavioral data of the account holder within a particular time interval of the one or more time intervals. The method also includes transmitting a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores.
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 access payment transaction data associated with an account holder from a transaction database. The payment transaction data includes a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period. The server system is caused to generate a set of transaction features based, at least in part, on the set of transaction indicators. Furthermore, the server system is caused to compute, via a chargeback risk prediction model, a set of chargeback risk probability scores corresponding to one or more time intervals associated with the account holder based, at least in part, on the set of transaction features. Each of the set of chargeback risk probability scores indicates future chargeback behavioral data of the account holder within a particular time interval of the one or more time intervals. The server system is also caused to transmit a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores.
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 accessing payment transaction data associated with an account holder from a transaction database. The payment transaction data includes a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period. The method further includes generating a set of transaction features based, at least in part, on the set of transaction indicators. Furthermore, the method includes computing, via a chargeback risk prediction model, a set of chargeback risk probability scores corresponding to one or more time intervals associated with the account holder based, at least in part, on the set of transaction features. Each of the set of chargeback risk probability scores indicates future chargeback behavioral data of the account holder within a particular time interval of the one or more time intervals. The method also includes transmitting a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores.
Other aspects and example embodiments are provided in the drawings and the detailed description that follows.
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:
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 DESCRIPTIONIn the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification is not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
Embodiments of the present disclosure may be embodied as an apparatus, system, method, or computer program product. Accordingly, embodiments of the present disclosure may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “engine,” “module,” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable storage media having computer-readable program code embodied thereon.
The term “payment account”, used throughout the description, refers to a financial account that is used to fund a financial transaction. Examples of 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 an entity such as a person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, the 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 card”, used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated with payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
The term “payment network”, used herein, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as, Mastercard®.
The term “merchant”, used throughout the description, generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location, or a chain of business locations of the same entity.
The terms “account holder”, “user”, “cardholder”, and “customer” are used interchangeably throughout the description and refer to a person who has a payment account or a payment card (e.g., credit card, debit card, etc.) associated with the payment account, that will be used by a merchant to perform a payment transaction. The payment account may be opened via an issuing bank or an issuer server.
The term “chargeback”, used throughout the description, generally refers to return of financial amount back to a payment account of an account holder for a payment transaction. In general, the chargeback may be issued based on a chargeback request raised by the account holder with an issuing bank that manages the payment account of the account holder. In one example, when a payment transaction occurs that is associated with a payment card (i.e., an account having a primary account number (PAN) associated therewith), an account holder has a period, for example, 60 to 180 days, during which the account holder can dispute the payment transaction with an issuing bank. A chargeback occurs when the cardholder of the account contacts the issuing bank to inform the issuing bank that the cardholder would like the charge removed from the account and funds from the transaction returned to the account.
Overview
Various embodiments of the present disclosure provide methods and systems for predicting chargeback behavioral data of a plurality of account holders within a period of time. In some embodiments, machine learning techniques may train a chargeback risk prediction model that more accurately predicts a likelihood of an account holder raising chargeback based at least on spend behavioral data.
In general, chargebacks may occur a number of reasons. A few reasons for chargebacks may include wrong transaction amounts, duplicate payment billing, previously canceled repetitive payments being charged, fraudulent transactions, etc. One of the most common reasons for the chargeback is fraud. For example, a debit card may be used without consent or proper authorization. In the chargeback process, an issuer of a payment account used in a payment transaction sends a chargeback request and chargeback reason code to an acquirer of the payment transaction. The chargeback reason may be a cardholder dispute (e.g., 4855, “Cardholder dispute for a recurring transaction”). In response, the acquirer may submit an approval of the chargeback request or contest the chargeback request to the issuer after checking evidences submitted by the merchant. Thus, it can be observed that the chargeback process would always be costly for parties involved in the payment transaction and consume valuable banking resources and banking time, etc.
Therefore, a preemptive remedial action is required for payment accounts that are likely to experience chargebacks so that processing requirements for handling the chargebacks at issuers/acquirers can be reduced or optimized. Hence, at least one of the technical problems addressed by the present disclosure includes (a) high network load and processing requirements at payment network, issuers, and/or acquirers due to chargebacks, and (b) high number of overall credit chargebacks.
To overcome such technical problems or limitations, the present disclosure describes a server system that is configured to predict chargeback behavioral data for an account holder for different prediction windows (e.g., next 3 months, next 6 months, next 9 months, next 12 months, etc.). The chargeback behavioral data may indicate or include a set of chargeback risk probability scores and chargeback risk levels corresponding to one or more time intervals (i.e., prediction windows). Each chargeback risk probability score is indicative of a probability that an account holder may raise chargebacks for future payment transactions within the particular time interval. The server system is also configured to determine probable chargeback amount bands of future chargeback requests raised by the account holder and determine a chargeback risk level corresponding to each time interval. Thereafter, the server system is configured to transmit a notification to an issuer server associated with the account holder based, at least in part, on the predicted chargeback behavioral data. In one example, the notification may include the set of chargeback risk probability scores and the chargeback risk levels corresponding to one or more time intervals. Based on the notification, the issuer server may perform one or more downstream tasks such as: (a) identifying account holder segments that are more likely to file a chargeback, (b) identifying account holder locations and demographics with high chargeback rates, (c) analyzing how the chargeback risk affect issuer's authorization logic, (d) determining account holders who can be targeted for incentives to reduce their likelihood to file chargebacks, etc.
In one embodiment, the server system includes at least a processor and a memory. In one non-limiting example, the server system is associated with a payment network. In another example, the server system is associated with an issuer server. The server system is configured to predict chargeback behavioral data of an account holder. Initially, the server system is configured to access payment transaction data associated with the account holder from a transaction database. The payment transaction data includes a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period. The server system is further configured to generate a set of transaction features based, at least in part, on the set of transaction indicators. The set of transaction indicators includes, but may not be limited to, spend transaction features, merchant features, fraud risk features, user activity features, and chargeback features.
Furthermore, the server system is configured to implement or run a chargeback risk prediction model to compute a set of chargeback risk probability scores corresponding to one or more time intervals associated with the account holder based, at least in part, on the set of transaction features. In an embodiment, the chargeback risk prediction model is a gradient boosted decision tree (GBDT) based classification model. In one non-limiting example, the one or more time intervals include 3 months, 6 months, 9 months, and 12 months. In addition, each chargeback risk probability score indicates future chargeback behavioral data of the account holder within a particular time interval of the one or more time intervals. Moreover, the server system is configured to transmit a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores. In an example, the issuer server may analyze the set of chargeback risk probability scores to perform one or more downstream tasks (e.g., prediction of fraudulent payment transactions, etc.). In one non-limiting example, each of the set of chargeback risk probability scores is a numeric value.
The server system is further configured to classify the account holder as a risky account holder or a non-risky account holder based, at least in part, on the set of chargeback risk probability scores. Upon classifying the account holder as the risky account holder, the server system is configured to determine a probable chargeback amount band for potential future chargeback requests raised by the account holder within each time interval based, at least in part, on each of the set of chargeback risk probability scores and a chargeback amount prediction model. Additionally, the probable chargeback amount band is determined for each of the one or more time intervals. More specifically, each probable chargeback amount band is determined for each time interval. The probable chargeback amount band may define a range in terms of a monetary value indicative of the probable chargeback amount that may be raised by the account holder for the corresponding time interval.
The server system is also configured to determine a chargeback risk level for each time interval based, at least in part, on the probable chargeback amount band. The chargeback risk level is selected from a plurality of chargeback risk levels. The plurality of chargeback risk levels includes a low chargeback risk level that is associated with a first chargeback amount band, a medium chargeback risk level that is associated with a second chargeback amount band, and a high chargeback risk level that is associated with a third chargeback amount band. In an embodiment, the chargeback amount prediction model is a gradient boosted decision tree (GBDT) based ranking model. In one non-limiting example, each of the chargeback risk level is defined with the facilitation of an alphanumeric value.
Various embodiments of the present disclosure offer multiple technical advantages and technical effects. For instance, the present disclosure provides a server system configured to perform advance prediction of chargeback requests that may be raised by the account holders along with the corresponding chargeback amounts for upcoming payment transactions, thus, enabling an issuer server to save valuable banking resources and time based on an understanding of the probability of chargebacks along with their probable chargeback amounts. Additionally, the present disclosure reduces the chances of account holder churning and mitigates chargeback arbitration needs. The present disclosure prevents both true and friendly fraud from occurring in the future and prioritizes the payment accounts with the highest levels of expected chargeback volume.
More specifically, techniques disclosed herein enable determination of future chargeback requests in advance, thus enabling an issuing bank to take appropriate actions (for example, declining particular payment transactions that may result in chargeback) in advance. Additionally, techniques disclosed herein inform the issuing bank in advance about probable chargeback amount bands in which the future chargeback requests may be raised by an account holder. Furthermore, the present disclosure provides a significantly more robust solution because of handling simultaneous/concurrent processor execution (such as applying one or more classification models over the same or different input, simultaneously and finding a gradient boosted classification model). Even further, the present disclosure improves the operations of processors because, by performing these synergistic operations to determine a set of chargeback risk probability scores corresponding to different prediction windows that can be used for further downstream applications, the processors will require fewer computation cycles in learning chargeback behavioral characteristics of account holders.
The technical improvement in the online payment system as described herein is a computer-based solution to a technical deficiency or problem that is itself rooted in computer technology (e.g., the problem itself derives from the use of computer technology). More specifically, chargeback is a significant problem for transactions conducted over an electronic payment network, especially for online transactions. Therefore, the present disclosure provides a system to predict chargeback behavioral data of an account holder and utilize the chargeback behavioral data in authorization related tasks such that chargeback rates for payment transactions can be minimized.
Various example embodiments of the present disclosure are described hereinafter with reference to
Various entities in the environment 100 may connect to the network 112 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 112 may include multiple different networks, such as a private network made accessible by the payment network 114 to the issuer server 108, the acquirer server 110, and the payment server 116, separately, and a public network (e.g., the Internet, etc.).
The account holder 104 may be an individual, representative of a corporate entity, non-profit organization, or any other person. The account holder 104 may have a payment account issued by corresponding issuing banks (associated with the issuer server 108) and may be provided with a payment card with financial or other account information encoded onto the payment card such that the account holder 104 may use the payment card to initiate and complete a payment transaction using a bank account at the issuing bank. Examples of the payment card may include, but are not limited to, a smartcard, a debit card, a credit card, and the like.
The environment 100 also includes a user device 126 associated with the account holder 104. The user device 126 may be a smartphone, a tablet, a laptop, a computer system, or any computing device. In an example, the user device 126 may include a portable device such as a laptop, smartwatch, PDA (personal digital assistant), smartphone, and the like. In another example embodiment, the user device 126 may include a fixed device such as a desktop, workstation, and the like. In one implementation, the account holder 104 may utilize the user device 126 to raise the chargeback request with the issuer server 108.
In one embodiment, the issuer server 108 is a financial institution that manages accounts of multiple account holders (e.g., the account holder 104). In addition, account details of the payment accounts established with the issuer bank are stored in account holder profiles of the account holders in memory of the issuer server 108 or on a cloud server associated with the issuer server 108. The terms “issuer server”, “issuer”, or “issuing bank” will be used interchangeably herein.
The environment 100 includes a merchant terminal 128 associated with the merchant 106. In addition, the merchant terminal 128 enables the account holders (e.g., the account holder 104) to perform electronic transactions for purchasing goods and/or services from the merchant 106. The merchant terminal 128 is associated with a unique merchant identifier (MID). Examples of the merchant terminal 128 may include Point-Of-Sale (POS) device, Point-Of-Purchase (POP) device, Point-Of-Interaction (POI) device, or the like. In one embodiment, the acquirer server 110 is associated with a financial institution (e.g., a bank) that processes financial transactions.
The acquirer server 110 can be an institution that facilitates the processing of payment transactions for the merchant 106, or an institution that owns platforms to make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank”, or “acquirer server” will be used interchangeably herein.
In one non-limiting example (not in accordance with embodiments of the present disclosure), the account holder 104 opens a merchant application on the user device 126 and performs a payment transaction using the information of a primary account number (PAN) and/or a payment card associated therewith to purchase goods or services offered by a merchant (e.g., the merchant 106). After submitting a payment from the payment account associated with the payment card, a payment authorization request associated with the submitted payment is authorized in near real-time and the required funds associated with the payment are kept pending for the payment transaction. However, the actual transfer of funds from the payment account of the account holder 104 may take 2 to 3 business working days. In other words, it may take 2 to 3 business working days for the payment transaction to clear the account holder's payment account. The clearing information may include merchant information (such as merchant ID, merchant state, merchant country, etc.), card product type, e-commerce indicator, cross-border indicator, recurring transaction indicator, card present (CP)/card-not present (CNP) transaction indicator, etc. At this point, the account holder 104 has a period of time (for example, 180 days, etc.) during which the payment transaction can be disputed by the account holder 104. In some scenarios, it may be possible that the account holder 104 may dispute the payment transaction based on various reasons. In an example, the account holder 104 may be unsatisfied with the goods or services provided by the merchant 106. In another example, the account holder 104 may not recognize the purchase for which the funds have been debited from the payment account of the account holder 104. In yet another example, the account holder 104 may determine that the purchase for which the funds have been debited from the payment account of the account holder 104 is fraudulent.
More specifically, the account holder 104 may then raise a chargeback request for the payment transaction during the period of time after the payment transaction is initiated. In such a scenario, the account holder 104 raises the chargeback request with the issuing bank (i.e., the issuer server 108). In an example, the chargeback request may further be transmitted to the acquirer server 110 associated with the merchant 106, via the payment server 116. Since the issuer server 108 or the payment server 116 does not have any visibility about any potential future chargeback requests corresponding to payment transactions performed by account holders that may result in additional processing time and resource requirements to resolve the future chargeback requests.
Additionally, it is observed that there is no system available for providing chargeback behavioral data of an account holder to issuers and/or merchants that indicates how likely a payment transaction is to lead to a chargeback.
To overcome the above-mentioned limitations, the environment 100 includes the server system 102 that is configured to predict chargeback behavioral data of account holders (e.g., account holder 104) and notify issuers about potential chargeback requests with a set of chargeback risk probability scores. The server system 102 is configured to transmit a notification to the issuer server 108 to perform one or more downstream tasks based at least on the predicted chargeback behavioral data. Based on the notification, the issuer server 108 may perform one or more downstream tasks such as: (a) identifying account holder segments that are more likely to file a chargeback, (b) identifying account holder locations and demographics with high chargeback rates, (c) analyzing how the chargeback risk affect issuer's authorization logic, (d) determining account holders who can be targeted for incentives to reduce their likelihood to file chargebacks, etc.
In one embodiment, the server system 102 is configured to implement a chargeback risk prediction model 122 and a chargeback amount prediction model 124 to perform one or more of the operations described herein. The server system 102, in communication with the issuer server 108/the payment server 116, is configured to compute a set of chargeback probability risk scores corresponding to different forward-looking time intervals (e.g., 3 months, 6 months, 1 year) of the account holder 104 and transmit the set of chargeback probability risk scores to the issuer server 108 so that any remedial action can be taken to mitigate chargeback occurrence.
In one embodiment, the server system 102 coupled with a database 120 is embodied within the payment server 116, however, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the issuer server 108. The database 120 may store the chargeback risk prediction model 122 and the chargeback amount prediction model 124. The database 120 may be incorporated in the server system 102 or may be an individual entity connected to the server system 102 or may be a database stored in cloud storage.
In one embodiment, the transaction database 118 stores information of past payment transactions performed by the plurality of account holders at merchants. For example, the transaction database 118 may store authorization, clearing, and chargeback data of the account holder 104. The transaction database 118 may store historical chargeback information associated with the primary account number (PAN) of the account holder 104. This information may be transmitted to another computing device, for example, the server system 102 described herein according to various example embodiments.
In one embodiment, the payment network 114 may be used by the payment card issuing authorities as a payment interchange network. The payment network 114 may include a plurality of payment servers such as the payment server 116. Examples of payment interchange network include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transactions among a plurality of financial activities that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
The number and arrangement of systems, devices, and/or networks shown in
Referring now to
The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 for executing instructions, a memory 208, a communication interface 210, and a storage interface 214 that communicate with each other via a bus 212. In some embodiments, the database 204 is integrated within the computer system 202. For example, the computer system 202 may include one or more hard disk drives as the database 204. The storage interface 214 is any component capable of providing the processor 206 with access to the database 204. The storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204. In some embodiments, the database 204 is configured to store a chargeback risk prediction model 226 and a chargeback amount prediction model 228. The chargeback risk prediction model 226 is identical to the chargeback risk prediction model 122 of
Examples of the processor 206 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, graphical processing unit (GPU), a field-programmable gate array (FPGA), and the like. The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure. The processor 206 is operatively coupled to the communication interface 210 such that the processor 206 is capable of communicating with a remote device 216 such as, the payment server 116, the issuer server 108, or communicating with any entity connected to the network 112 (as shown in
It is to be noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is to be noted that the server system 200 may include fewer or more components than those depicted in
In one embodiment, the processor 206 includes a data pre-processing engine 218, a feature generation engine 220 including a graph creation engine 220a, a chargeback prediction engine 222, and a notification engine 224. It should be noted that components, described herein, such as the data pre-processing engine 218, the feature generation engine 220 including the graph creation engine 220a, the chargeback prediction engine 222, and the notification engine 224 can be configured in a variety of ways, including electronic circuitries, digital arithmetic and logic blocks, and memory systems in combination with software, firmware, and embedded technologies.
The data pre-processing engine 218 includes suitable logic and/or interfaces for accessing or extracting payment transaction data associated with the account holder 104 from the transaction database 118. In particular, the data pre-processing engine 218 may query the transaction database 118 for past payment transactions of the account holder 104 based on an account identifier of the account holder 104. In one embodiment, the data pre-processing engine 218 may obtain the payment transaction data associated with the account holder 104 from the issuer server 108. The payment transaction data includes a set of transaction indicators corresponding to the past payment transactions performed by the account holder 104 within a predetermined time period. In an example, the predetermined time period may include 3 months, 6 months, 1 year, and the like.
Each past payment transaction may include a set of transaction indicators. The set of transaction indicators includes, but is not limited to, unique merchant identifier, geo-location data, payment means, timestamp information, merchant country, merchant state, merchant city, merchant location ID, transaction amount, transaction currency, acquiring bank, acquiring country, issuing bank, issuing country, card product type, e-commerce indicator, contactless payment indicator, recurring transaction indicator, user presence indicator, cross-border transaction indicator, and the like. The set of transaction indicators may also include authorization, clearing, and chargeback data of the account holder 104. For example, the set of transaction indicators may also include a chargeback status flag for the past payment transaction.
In some embodiments, the data pre-processing engine 218 is configured to perform operations (such as data-cleaning, normalization, feature extraction, and the like) on the past payment transactions.
The feature generation engine 220 includes suitable logic and/or interfaces for generating a set of transaction features based on the past payment transactions of the account holder 104. The set of transaction features or derived data may include at least: (a) account-specific transaction features and (b) graphical transaction features based on merchant-account holder interactions. The term “account-specific transaction features” herein is used to define transaction features that are generated specific to a payment account of the account holder 104.
The set of transaction features may be determined from or engineered from the payment transaction data of the past payment transactions. The set of transaction features may include categorical or numerical features. The set of transaction features includes at least one of: spend transaction features, merchant features of a plurality of merchants involved in the payment transactions, and fraud risk features. In an example, the spend transaction features are card-level or account-level features generated based on payment transactions performed by an account holder (e.g., the account holder 104) of the plurality of account holders. In an example, the merchant features are merchant-level features generated based on the plurality of account holders that transacted at a merchant (e.g., the merchant 106). In an example, the fraud risk features are generated based on the payment transactions performed due to fraud.
In one example, the spend transaction features may include a number of chargeback transactions performed per month for the particular time interval, the amount of chargeback spend per transaction for the particular time interval, previous chargeback count velocity, previous chargeback amount velocity, recurring transaction count velocity, transaction count velocity by merchant category, transaction amount velocity according to merchant category, card-present/card-not-present flag, transaction decline count, transaction decline amount, fraud chargeback count, first chargeback date, last chargeback date, chargeback amounts corresponding to e-commerce transactions, and the like.
In one example, the merchant features may include the maximum chargeback rate of all merchants in the last 3 months, 6 months, and so on, the average chargeback amount of all merchants in the last 3 months, 6 months, and so on, and the like.
In one example, the fraud risk features may include total fraud amount for card-not-present cross-border payment transactions performed in 1 month, 3 months, and so on, chargeback amount for fraudulent payment transactions performed at a merchant in 1 month, 3 months, and so on, and the like.
In one embodiment, a group of the set of transaction features (i.e., graphical transaction features) may be determined based at on a network graph between the account holder 104 and the plurality of merchants. The network graph captures merchant-account holder interactions. In other words, some of the set of transaction features are determined based on a graphical representation of the account holder 104 in view of risk or spend behavioral profiles of the plurality of merchants.
In one example, the feature generation engine 220 may include a machine learning model such as, but not limited to, Linear Discriminant Analysis (LDA) model, Independent Component Analysis (ICA) model, or Principal Component Analysis (PCA) model to generate the set of transaction features. In an embodiment, the feature generation engine 220 includes the graph creation engine 220a. In another embodiment, the graph creation engine 220a is communicably coupled to the feature generation engine 220.
The graph creation engine 220a includes suitable logic and/or interfaces for creating a network graph based, at least in part, on the payment transaction data. The network graph represents a computer-based graphical representation of a plurality of account holders (e.g., the account holder 104) as first nodes and merchants (e.g., the merchant 106) as second nodes and relationships between the first nodes and the second nodes as edges. In an example, the network graph can be a directed graph, a bipartite graph, an attributed heterogeneous graph, and the like. The graph creation engine 220a is also configured to update or modify the network graph with time.
The feature generation engine 220 is configured to access the network graph to generate the graphical transaction features based on the network graph. In this manner, the feature generation engine 220 generates the set of transaction features not only based on the individual features of the account holder 104 but also based on the features of the plurality of merchants at which the account holder 104 transacted (i.e., performed payment transactions) in the past.
It is observed that the chargeback has a strong recurring pattern on merchants but not a clear recurring pattern from the perspective of the account holder 104. More specifically, the merchants that have high past chargeback rates tend to continue to have more chargeback requests in the future; however, the payment accounts (or the payment cards) that have faced high past chargeback rates tend to stop all together. Therefore, the feature generation engine 220 is configured to generate the graphical transaction features that encapsulate risk profiles of the plurality of merchants with which the account holder 104 has interacted within a time period (for example, the past 3 months). In an example, the graphical transaction features include, but may not be limited to, maximum chargeback rates of the merchants the account holder 104 has transacted with in the past 1, 2, or 3 months, a weighted average of chargeback rates of all the merchants where the account holder 104 has interacted with (weight of each edge of the network graph being the amount spent), and the ratio of payment transactions that cross a threshold fraud risk value for each merchant of the plurality of merchants the account holder 104 has interacted with.
In one example, the feature generation engine 220 may use natural language processing (NLP) algorithms to generate the set of transaction features from the set of transaction indicators. In an example, the set of transaction features may also include maximum credit risk score of all chargeback payment transactions in the past 1, 2, and 3 months, decline pattern of payment cards in the past 1, 2, and 3 months, payment cards declined due to credit over limit, invalid card number, etc., and the like. It is to be noted that the above stated set of transaction features proved to be very effective for predicting a potential future chargeback (for example, payment transactions approved anomalously in between a continuous stream of declines are seen as a high chargeback risk).
In some implementations, the set of transaction features may be converted into a vector format to be fed as an input to various risk prediction models, including, for example, the chargeback risk prediction model 226 and the chargeback amount prediction model 228.
In an example, the set of transaction features is illustrated in Table 1 as:
The chargeback prediction engine 222 includes suitable logic and/or interfaces for predicting chargeback behavioral data of the account holder 104 for one or more time intervals (e.g., 0-3 months, 0-6 months, 0-9 months, 0-12 months, etc.). The ‘chargeback behavioral data’ may refer to include a set of chargeback risk probability scores and a set of chargeback risk levels for the one or more time intervals.
In particular, the chargeback prediction engine 222 is configured to compute a set of chargeback risk probability scores corresponding to the one or more time intervals associated with the account holder 104 based, at least in part, on the set of transaction features. More specifically, the chargeback prediction engine 222 is configured to run or implement the chargeback risk prediction model 226 to compute the set of chargeback risk probability scores. Each chargeback risk probability score of the set of chargeback risk probability scores indicates chargeback behavioral data of the account holder 104 within a particular time interval of the set of time intervals. In other words, each chargeback risk probability score indicates a probability of whether a chargeback request will be raised by the account holder 104 for future payment transactions to be performed by the account holder 104 within the particular time interval.
The chargeback risk prediction model 226 handles the classification of multiple classes through one model. In one non-limiting example, the chargeback risk prediction model 226 is based on a gradient boosting decision tree (GBDT) algorithm. In general, the gradient boosting decision tree (GBDT) model is a machine learning technique used for optimizing the predictive value of a model through successive steps in the learning process. More specifically, the gradient boosting decision tree (GBDT) model utilizes simpler (weak) prediction models sequentially, where each model tries to optimize errors left over by the previous model. The gradient boosting decision tree (GBDT) model is generally used to solve prediction problems in the classification and regression domain.
The chargeback prediction engine 222 is configured to initially train the chargeback risk prediction model 226. During the training phase, the data pre-processing engine 218 is configured to access training data i.e., historical transaction data associated with a plurality of account holders from the transaction database 118. The historical transaction data further includes a plurality of transaction indicators corresponding to payment transactions performed between the plurality of account holders (e.g., the account holder 104) and the plurality of merchants (e.g., the merchant 106) within a period of time. The period of time may include 6 months, 12 months, 2 years, and the like.
In one example, the training data used to train the GBDT model may be separated on a monthly basis. For example, the historical transactions related to a particular account holder may be separated on the monthly basis. The GBDT based classification model (or any other supervised model) may be trained to predict the likelihood of whether a user will raise a chargeback request in forward-looking time (i.e., future time interval). Decision trees may be well worked for such predictions because they handle mixed variable types well (e.g., categorical and numerical), they require little data preparation (e.g., no need to create dummy variables to shift the outcome), and they perform well with large data sets.
The input into the GBDT based classification model may be formatted in a particular fashion, such as a vector format like (x, Y)=(x1, x2, x3, . . . , xk, Y), where the dependent variable, Y, is the target variable that corresponds to the input variables x1, x2, x3, . . . , xk. For example, the target variable, Y, may be a probability of raising a chargeback request by an account holder during a prediction period and the input variables, x1, x2, x3, . . . , xk, may include user spend across merchant categories, merchant features, card present/card not present (CNP) transaction patterns, fraud risk features, payment channels, etc. Other arrangements and formats are also possible.
The chargeback prediction engine 222 is configured to perform the training process until a loss function of the GBDT based classification model reaches a predetermined threshold value. In one non-limiting example, the loss function is a cross-entropy (CE) loss function. Generally, the CE loss, also known as log loss, logarithmic loss, or logistic loss, is a loss used to measure the performance of a machine learning model whose output is a probability value between 0 and 1. Once the chargeback risk prediction model is trained, the chargeback risk prediction model 226 may use a new set of transactions related to the account holder 104 to determine a chargeback risk probability score corresponding to a forward-looking period or a prediction period.
In a similar manner, the chargeback prediction engine 222 is configured to train the chargeback amount prediction model 228 based, at least in part, on the historical transaction data. The chargeback amount prediction model 228 is GBDT based ranking model configured to determine a probable chargeback amount band for future potential chargeback requests that will be raised by the account holder 104. The chargeback amount prediction model 228 is configured to take the set of chargeback risk probability scores and the set of transaction features of the account holder 104 as inputs during prediction.
In one embodiment, the chargeback prediction engine 222 is configured to classify the account holder 104 as a risky account holder or non-risky account holder based on the set of chargeback risk probability scores. For example, when a chargeback risk probability score computed corresponding to a particular time interval is at least equal to (i.e., greater than or equal to) a predefined threshold value, the account holder 104 is classified as the risky account holder, otherwise, when the chargeback probability risk score computed corresponding to a particular time interval is lesser than the predefined threshold value, the account holder 104 is classified as a non-risky account holder.
When the account holder 104 is classified as the risky account holder, the chargeback prediction engine 222 is configured to predict probable chargeback amount bands for the one or more time intervals that may be raised by the account holder 104 via the chargeback amount prediction model 228. Then, the chargeback prediction engine 222 is configured to determine a chargeback risk level for each time interval based, at least in part, on a probable chargeback amount band. The probable chargeback amount bands are determined for the one or more time intervals.
In addition, the chargeback risk level is selected from a plurality of chargeback risk levels. The chargeback risk levels include a low chargeback risk level that is associated with a first chargeback amount band, a medium chargeback risk level that is associated with a second chargeback amount band, and a high chargeback risk level that is associated with a third chargeback amount band.
In some embodiments, the first, second, and third chargeback amount bands may be defined by issuers and may be different for different countries based on a currency of a particular country. In an example, the first, second, and third chargeback amount bands determined for the account holders belonging to United States of America (USA) may differ from the first, second, and third chargeback amount bands determined for the account holders belonging to Europe.
The chargeback prediction engine 222 is further configured to determine a chargeback risk level of the account holder 104 from among the plurality of chargeback risk levels for each time interval of the one or more time intervals based on a corresponding probable chargeback amount band for the potential future chargeback requests. In one non-limiting example, the plurality of chargeback risk levels includes three levels, including, for example, high chargeback risk level, medium chargeback risk level, and low chargeback risk level.
In an example, consider that for USA, the “high chargeback risk level” may correspond to a chargeback amount band of greater than $200, the “medium chargeback risk level” may correspond to a chargeback amount band of $100 to $200, and the “low chargeback risk level” may correspond to the chargeback amount band of less than $100.
In another example, consider that for Europe, the “high chargeback risk level” may correspond to the amount band of greater than €150, the “medium chargeback risk level” may correspond to the amount band of €50 to €150, and the “low chargeback risk level” may correspond to the amount band of less than €50.
In one non-limiting example, each of the set of chargeback risk probability scores is a numeric value. In one implementation, each chargeback risk probability score is a three-digit numeric value ranging from 001 to 999, indicative of the probability of chargeback to be experienced for the future payment transactions to be performed by the account holders. In an example, the chargeback risk probability score of 234 for the time interval 0-6 months indicates that there is a probability of 23.4% that the account holder 104 will raise the chargeback request in the next 6 months. In another example, the chargeback risk probability score of 876 for the time interval 0-12 months indicates that there is a probability of 87.6% that the account holder 104 will raise the chargeback request in the next 12 months.
In one non-limiting example, each of the chargeback risk levels is defined with the facilitation of an alpha-numeric value. In one implementation, the alphabet in the chargeback risk level may indicate the level of risk (e.g., H for high chargeback risk level, M for medium chargeback risk level, and L for low chargeback risk level) associated with the chargeback, and the numerical value may indicate the expected chargeback amount band that may be claimed or disputed by the account holder 104. In another implementation, the alphabet in the chargeback risk level may indicate the level of risk (e.g., A for high chargeback risk level, B for medium chargeback risk level, and C for low chargeback risk level) associated with the chargeback, and the numerical value may indicate the expected chargeback amount band that may be claimed or disputed by the account holder 104.
In an example, the alpha-numeric value ‘A01’ for the time interval 0-3 months may indicate that the account holder 104 is expected to claim the chargeback amount band of greater than $200 in the next 3 months. In another example, the alpha-numeric value B10 for the time interval 0-6 months may indicate that the account holder 104 is expected to claim the chargeback amount band between $100 and $200 in the next 6 months.
The notification engine 224 includes suitable logic and/or interfaces for transmitting a notification to an issuer server 108 associated with the account holder 104 based, at least in part, on the set of chargeback risk probability scores. In addition, the notification engine 224 is configured to transmit a notification to the issuer server 108 associated with the account holder 104 based, at least in part, on the chargeback risk level. Based on the notification, the issuer server 108 may perform one or more downstream tasks such as: (a) identifying account holder segments that are more likely to file a chargeback, (b) identifying account holder locations and demographics with high chargeback rates, (c) analyzing how the chargeback risk affect issuer's authorization logic, (d) determining account holders who can be targeted for incentives to reduce their likelihood to file chargebacks, etc.
In one implementation, the notification engine 224 may transmit notifications or alerts to the issuer server 108 for the account holders (e.g., the account holder 104) that are expected to raise the chargeback request in the future along with the expected chargeback amount. In one example, the notification engine 224 may transmit the notifications or alerts in real-time when the account holder 104 is performing the payment transaction. For example, the chargeback prediction engine 222 may compute the set of chargeback risk probability scores and their corresponding chargeback risk levels for the account holder 104, and based on the set of chargeback risk probability scores and their corresponding chargeback risk levels, the notification engine 224 may transmit the notification or alerts to the issuer server 108 in real-time.
As explained above, the processor 206 is configured to execute or run the chargeback risk prediction model 226 and the chargeback amount prediction model 228. The chargeback risk prediction model 226 is run to determine whether an account holder (e.g., the account holder 104) associated with an issuing bank (e.g., the issuer server 108) is expected to raise any chargeback requests in a time interval (e.g., 3 months, 6 months, 9 months, 12 months, etc.) in future. In case, the account holder 104 is expected to raise any chargeback requests in future, the processor 206 is also configured to predict the expected transaction amount that will be disputed by the account holder 104 in the raised chargeback requests. More specifically, the processor 206 is configured to execute the chargeback amount prediction model 228 to predict the expected chargeback amount bands for the expected chargeback requests.
In an embodiment, the chargeback risk prediction model 226 and the chargeback amount prediction model 228 are implemented on a timely basis, including, for example, monthly, weekly, quarterly, annually, and so on. After implementation of both these models, the processor 206 is configured to determine a list of account holders from the plurality of account holders associated with an issuing bank (e.g., the issuer server 108). The list of account holders represents the risky account holders determined based on the computed chargeback risk probability scores. The processor 206 may further categorize the risky account holders into various chargeback risk levels, including, for example, high chargeback risk level, medium chargeback risk level, and low chargeback risk level, based on execution of the chargeback amount prediction model 228.
As shown in
In some embodiments, the data pre-processing engine 218 is configured to perform operations (such as data-cleaning, normalization, feature extraction, and the like) on the various transaction indicators. The data pre-processing engine 218 is further configured to transmit the various transaction indicators to the feature generation engine 220 (see, 304). Furthermore, the feature generation engine 220 is configured to generate account-specific transaction features based, at least in part, on the various transaction indicators. In one embodiment, the feature generation engine 220 may also generate graphical transaction features for various payment transactions performed between the account holders and the merchants.
To generate the graphical transaction features, the feature generation engine 220 is configured to connect with the graph creation engine 220a (see, 306). More specifically, the feature generation engine 220 accesses the network graph of account holders and merchants. In the network graph, the account holders may be represented as the first nodes and the merchants may be represented as the second nodes, and relationships between the account holders and the merchants may be represented as edges. The term “relationship” herein may refer to a payment transaction performed between an account holder (e.g., the account holder 104) and a merchant (e.g., the merchant 106). In addition, the edges may be weighted or unweighted. The feature generation engine 220 is configured to generate the graphical transaction features from the network graph of account holders and merchants. In one example, the graphical transaction features may include hand-crafted transaction features.
In one implementation, the account-specific and graphical transaction features are converted into a vector format and then fed as an input to the chargeback risk prediction model 226 (see, 308). In one non-limiting example, the chargeback risk prediction model 226 is a gradient boosting decision tree (GBDT) based classification model. The chargeback risk prediction model 226 runs on the input data (i.e., the various transaction features) of the account holders and further computes the set of chargeback risk probability scores corresponding to the one or more time intervals for each account holder.
For example, the chargeback risk prediction model 226 runs on various transaction features associated with 10 different account holders. The chargeback risk prediction model 226 is configured to calculate 4 different chargeback risk probability scores corresponding to 4 different time intervals (e.g., next 3 months, next 6 months, next 9 months, and next 12 months) for each account holder. In one example, let us consider that for a first account holder, a chargeback risk probability score for first time interval i.e., next 3 months is calculated as 790, a chargeback risk probability score for second time interval i.e., next 6 months is calculated as 690, a chargeback risk probability score for third time interval i.e., next 9 months is calculated as 200, and a chargeback risk probability score for fourth time interval i.e., next 12 months is calculated as 990. If a threshold value for the chargeback risk probability score is 800, the first account holder is expected to raise chargeback requests within the time interval 0-12 months. In a similar manner, the chargeback risk prediction model 226 is configured to calculate the set of chargeback risk probability scores for the set of time intervals for each of the 10 different account holders.
It is to be noted that for the sake of simplicity, we have considered 800 as the threshold value for all the time intervals; however, it is possible that the threshold value is different for different time intervals of the one or more time intervals.
The chargeback risk prediction model 226 is further configured to classify the account holders as risky account holders or non-risky account holders based on the set of chargeback risk probability scores computed for each account holder. The term “non-risky account holders” herein refers to those account holders that are not expected to raise any chargeback request or dispute in the future (i.e., the one or more time intervals). The term “risky account holders” herein refers to those account holders that are expected to raise a chargeback request or dispute in the future (i.e., the one or more time intervals). Therefore, the chargeback risk prediction model 226 is configured to classify those account holders as non-risky account holders for which any of the chargeback risk probability score of the set of chargeback risk probability scores is less than the corresponding threshold value (see, 310). In addition, the processor 206 is configured to provide the various transaction features of the remaining account holders (i.e., the risky account holders) as an input to the chargeback amount prediction model 228 (see, 312).
In one non-limiting example, the chargeback amount prediction model 228 is a gradient boosting decision tree (GBDT) based ranking model. The chargeback amount prediction model 228 runs on the input data (i.e., the various transaction features) of the account holders and further computes the amount bands (depicting expected chargeback value) corresponding to the one or more time intervals for each account holder. In addition, a chargeback risk level associated with an amount band is received as an output of the chargeback amount prediction model 228 corresponding to each time interval of the one or more time intervals. Each amount band further corresponds to a chargeback risk level from among the plurality of chargeback risk levels.
For example, let us consider that the chargeback risk prediction model 226 classifies 2 account holders as the risky account holders and remaining 8 account holders as the non-risky account holders out of the 10 different account holders. The various transaction features of the 2 account holders are further fed as an input to the chargeback amount prediction model 228. Furthermore, the chargeback amount prediction model 228 is configured to calculate 4 different amount bands (i.e., 4 different chargeback risk levels) corresponding to 4 different time intervals (i.e., 0-3 months, 0-6 months, 0-9 months, and 0-12 months) for each account holder. Each amount band is associated with chargeback risk level of the plurality of chargeback risk levels. In one non-limiting example, the plurality of chargeback risk levels includes high chargeback risk level, medium chargeback risk level, and low chargeback risk level. In addition, the amount bands associated with the chargeback risk levels may depend on various factors, including, for example, currency of the country of origin of the account holder (e.g., the account holder 104).
In an example, let us consider that the country of origin of the account holders is Europe. Then, the high chargeback risk level is associated with the amount band of values greater than 150 €, the medium chargeback risk level is associated with the amount band of values between 75 € and 150 €, the low chargeback risk level is associated with the amount band of values less than 75 €. The chargeback risk level may further be represented using an alphabet (for example, A for high chargeback risk level, B for medium chargeback risk level, and C for low chargeback risk level) along with a numeric value.
The chargeback amount prediction model 228 is configured to output the set of chargeback risk levels for the one or more time intervals for the risky account holders. For example, for the first account holder, the chargeback risk level for the time interval 0-3 months is calculated as A01, the chargeback risk level for the time interval 0-6 months is calculated as B10, the chargeback risk level for the time interval 0-9 months is calculated as C00, and the chargeback risk level for the time interval 0-12 months is calculated as B10. Similarly, the chargeback amount prediction model 228 is configured to calculate the set of chargeback risk levels for the one or more time intervals for the second risky account holder. In some implementations, the chargeback amount prediction model 228 may categorize the risky account holders in various buckets, including, for example, high chargeback risk bucket, medium chargeback risk bucket, and low chargeback risk bucket, based on the computed set of chargeback risk levels (see, 314).
In one implementation, the chargeback risk prediction model 226 transmits the notification to the issuer server 108 based on the set of chargeback risk probability scores. In another implementation, the chargeback amount prediction model 228 transmits the notification to the issuer server 108 based on the set of chargeback risk levels. The issuer server 108 may further analyze the set of chargeback risk probability scores and the set of chargeback risk levels to perform one or more downstream prediction tasks (e.g., prediction of fraudulent payment transaction). In one implementation, the server system 200 is configured to transmit the set of chargeback risk probability scores and the set of chargeback risk levels associated with each of the plurality of account holders in the form of reports and insights to the issuer server 108. The reports are provided to the issuer server 108 to provide various recommendations to the issuer server 108 about the various account holders that are expected to raise chargeback claims in the future along with their expected chargeback claim amount.
In another implementation, the chargeback risk prediction model 226 transmits the notification based on the chargeback risk probability scores to the issuer server 108 in real-time via the network 112. For instance, if an account holder (e.g., the account holder 104) is performing a payment transaction with a merchant (e.g., the merchant 106) that is likely to experience the chargeback, the chargeback risk prediction model 226 routes the payment transaction along with the computed set of chargeback risk probability scores to the issuer server 108, thereby enabling the issuer server 108 to decline the payment transaction in real-time based on the computed set of chargeback risk probability scores.
As explained above, the processor 206 is configured to generate the graphical transaction features i.e., a group of the set of transaction features based, at least in part, on a network graph between an account holder 104 and a plurality of merchants interacted with the account holder 104 and a graph neural network (GNN). With reference to the
In one embodiment, each edge is a weighted edge. For example, weight w1 represents the weight of the edge existing between the account holder A1 and the merchant M1. Similarly, weight w2 represents the weight of the edge existing between the account holder A1 and the merchant M2 (as shown in
FeatureM1=[chargeback risk, fraud risk, average credit risk score . . . ] Eqn. (1)
Similarly, the graphical transaction features for the merchant M2 may be represented as:
FeatureM2=[chargeback risk, fraud risk, average credit risk score . . . ] Eqn. (2)
In one example, the graphical transaction features for an account holder (e.g., account holder A1) may be calculated as an aggregation of the transaction features of the merchants at which the account holder (e.g., account holder A1) transacted (i.e., performed payment transactions). With reference to
Graph FeatureA1=Aggregate (M1, M2)=w1*FeatureM1+w2*FeatureM2 Eqn. (3)
In this manner, the processor 206 is configured to generate the graphical transaction features for the account holders and the merchants present in the network graph 402.
The GBDT technique can be used for classification and regression problems. The gradient boosting decision tree-based model utilizes regression trees where a target variable can take continuous values (typically real numbers). For example, the target variable may be a likelihood of raising a chargeback by an account holder within a prediction period. Gradient boosting decisions trees are represented as a tree-like set of nodes forming a branch-like structure, in which each internal node represents a “test” on an attribute (e.g., if the age of a person is greater than or equal to 18), each branch represents the outcome of the test, and each leaf node represents a numerical score that is mapped to a class label (decision taken after computing all attributes). The paths from root node to leaf node represent classification rules. Gradient boosting decision trees may be used to reach a conclusion or predict an event or outcome given the input. In general, algorithms for constructing decision trees usually work top-down, by choosing a variable at each node or step that best splits the set of items or observations. Different algorithms use different metrics for measuring the best split, but these algorithms generally measure the homogeneity of the target value within the subset of observations. The metrics are applied to each candidate subset and the resulting values are combined (e.g., averaged) to provide a measure of the quality of the split. For example, an algorithm to make a locally optimal decision at each node or step with the goal of finding a global optimum (e.g., a greedy algorithm) is a common strategy for learning decision trees from training data (e.g., historical transaction data). Examples of gradient boosting decision trees include FastTree, XGBoost, AdaBoost, etc.
The training data used for the GBDT based classification model may include, but not limited to, transaction features of historical payment transactions performed by the plurality of account holders. The historical payment transactions may include payment transactions of a particular time interval (for example, 3 years).
The training data used for the GBDT based classification model may include, but not limited to, transaction features of historical payment transactions performed by the plurality of account holders. The historical payment transactions may include payment transactions of a particular time interval (for example, 3 years). In an implementation, the transaction features may include spend transaction features represented as s1, s2, s3 . . . sn (see, 502). In another implementation, the transaction features may include merchant features represented as m1, m2, m3 . . . mn (see, 504). In yet another implementation, the transaction features may include fraud risk features represented as f1, f2, f3 . . . fn (see, 506).
In one example, the spend transaction features may include number of chargeback transactions performed per month for the particular time interval, amount of chargeback spend per transaction for the particular time interval, and the like. In one example, the merchant features may include maximum chargeback rate of all merchants in last 3 months, 6 months, and so on, average chargeback amount of all merchants in last 3 months, 6 months, and so on, and the like. In one example, the fraud risk features may include total fraud amount for card-not present cross-border payment transactions performed in 1 month, 3 months, and so on, chargeback amount for fraudulent payment transactions performed at a merchant in 1 month, 3 months, and so on, and the like.
The spend transaction features, the merchant features, and the fraud risk features are aggregated together along with a corresponding chargeback label to generate an aggregated vector with chargeback label 508 for training the chargeback risk prediction model 226. In one example, the spend transaction features, the merchant features, and the fraud risk features may also be represented in the form of a vector. More specifically, the spend transaction features, the merchant features, and the fraud risk features are aggregated together to form the aggregated vector with chargeback label 508. The aggregated vector with chargeback label 508 is fed as an input to the chargeback risk prediction model 226 (i.e., GBDT based classification model) (see, 510).
The GBDT based classification model is trained based on the aggregated vector with chargeback label 508. The GBDT model is trained until a loss function (e.g., cross-entropy (CE) loss function) reaches a predetermined threshold value.
Performance MetricsThe performance metrics of the chargeback risk prediction model 226 and the chargeback amount prediction model 228 are illustrated below in Table 2:
The table 2 shows the prediction accuracy of the chargeback risk prediction model 226 and the chargeback amount prediction model 228. In the second row (see, first three columns) of the table, it can be seen that the top 1.2% of payment cards (i.e., 87853 payment cards) categorized or captured into a high chargeback risk level by the chargeback risk prediction model 226 were included in a fraction (i.e., 10.35%) of total payment cards that have actually raised chargeback requests within a period of time. Further, the chargeback amount prediction model 228 correctly predicts a fraction (i.e., 13.91%) of the total chargeback amounts within the period of time (see, the last two columns of the second row). It should be noted that the value of area. under the curve (AUC) is calculated to be 0.77 and the value of KS is calculated to be 40.04 for both the models.
Similarly, the third row depicts that the top 5% of payment cards predicted into the high chargeback risk level by the chargeback risk prediction model 226 belong to 25.3% of all the payment cards that have actually raised chargeback requests. Additionally, it is observed that the chargeback amount prediction model 228 provides 30-35% precision and recall for capturing the payment accounts with high chargeback amount.
At 602, the server system 200 access historical transaction data associated with a plurality of account holders from the transaction database 118. The historical transaction data includes a plurality of transaction indicators corresponding to past payment transactions performed by the plurality of account holders at a plurality of merchants within the period of time (e.g., 6 months, 1 year, 2 years, etc.). In one example, an account holder ‘A’ has performed 50 payment transactions at ten merchants M1-M10 within a first time period (e.g., 0-3 months) and 100 payment transactions at merchants M1-M10 and M11-M20 within a second time period (e.g., 3-6 months)).
At 604, the server system 200 determines a plurality of transaction features based on the plurality of transaction indicators of the past payment transactions. The plurality of transaction features may include spend transaction features, merchant features, fraud features, and chargeback features of account holders and merchants. The process of determining the plurality of transaction features may include filtering, transforming, normalizing, or processing the data to be used with the chargeback risk prediction model. In the above example, 100 transaction features are generated for the account holder ‘A’ for the first time period and the second time period.
At 606, the server system 200 generates a vector representation for each transaction feature on timely basis (e.g., weekly) of the plurality of account holders. According to the above example, a feature vector is generated for each transaction feature (e.g., a number of chargeback requests by the account holder ‘A’ within a particular time interval) on a weekly basis. Generally, a plurality of data subsets is formed for training and testing the chargeback risk prediction model 226.
At 608, the server system 200 trains the chargeback risk prediction model 226 based, at least in part, on the vector representation of each transaction feature of the plurality of account holders. For example, GBDT based classification model may be formed using a gradient boosting technique as discussed with respect to the
In one embodiment, the server system 200 performs the training process until the loss function reaches a predetermined threshold value. In one non-limiting example, the loss function is a cross-entropy (CE) loss function.
The sequence of steps 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.
At operation 702, the method 700 includes accessing, by the server system 200, payment transaction data associated with the account holder 104 from the transaction database 118. The payment transaction data includes the set of transaction indicators corresponding to payment transactions performed by the account holder 104 within the predetermined time period.
At operation 704, the method 700 includes generating, by the server system 200, the set of transaction features based, at least in part, on the set of transaction indicators.
At operation 706, the method 700 includes computing, by the server system 200 via the chargeback risk prediction model 226, the set of chargeback risk probability scores corresponding to one or more time intervals associated with the account holder 104 based, at least in part, on the set of transaction features. Each of the set of chargeback risk probability scores indicates future chargeback behavioral data of the account holder 104 within the particular time interval of the set of time intervals.
At operation 708, the method 700 includes transmitting, by the server system 200, a notification to an issuer server 108 associated with the account holder 104 based, at least in part, on the set of chargeback risk probability scores. For example, when any of the set of chargeback risk probability scores is above corresponding pre-determined threshold values, the server system 200 transmits the notification to the issuer server 104.
The sequence of operations of the method 700 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
The payment server 800 includes a processing system 805 configured to extract programming instructions from a memory 810 to provide various features of the present disclosure. The components of the payment server 800 provided herein may not be exhaustive and that the payment server 800 may include more or fewer components than those depicted in
Via a communication interface 815, the processing system 805 receives a request from a remote device 820, such as the issuer server 108 or the acquirer server 110. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 800 includes a database 825. The database 825 also includes transaction processing data such as issuer ID, country code, acquirer ID, merchant identifier (MID), among others.
When the payment server 800 receives a payment transaction request from the acquirer server 110 or a payment terminal (e.g., point of sale (POS) device, etc.), the payment server 800 may route the payment transaction request to an issuer server (e.g., the issuer server 108). The database 825 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 110 is configured to send an authorization request message to the payment server 800. The authorization request message includes, but is not limited to, the payment transaction request.
The processing system 805 further sends the payment transaction request to the issuer server 108 for facilitating the payment transactions from the remote device 820. The processing system 805 is further configured to notify the remote device 820 of the transaction status in form of an authorization response message via the communication interface 815. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 108. Alternatively, in one embodiment, the processing system 805 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 815, to the acquirer server 110.
In one embodiment, the database 825 is also configured to store historical clearing and chargeback activities associated with the plurality of account holders. In an example, the database 825 may store information about transactions performed by an account holder (e.g., the account holder 104) at a plurality of merchants (e.g., the merchant 106).
The storage module 910 is configured to store machine executable instructions to be accessed by the processing module 905. Additionally, the storage module 910 stores information related to, contact information of the account holder 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 910 is configured to store payment transactions.
In one embodiment, the issuer server 900 is configured to store profile data (e.g., an account balance, a credit line, details of the account holder (i.e., the account holder 104), account identification information, payment card number, etc.) in the transaction database 118. The details of the account holder 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 account holder 104, etc.
The processing module 905 is configured to communicate with one or more remote devices such as a remote device 920 using the communication module 915 over a network such as the network 112 of
The disclosed methods with reference to
Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the disclosure. For example, the various operations, blocks, etc. described herein may be enabled and operated using hardware circuitry (for example, complementary metal-oxide semiconductor (CMOS) based logic circuitry), firmware, software, and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
Particularly, the server system 200 (e.g., the server system 102) and its various components such as the computer system 202 and the database 204 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g., magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line. Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
Claims
1. A computer-implemented method for predicting chargeback behavioral data of an account holder, the computer-implemented method comprising:
- accessing, by a server system, payment transaction data associated with an account holder from a transaction database, the payment transaction data comprising a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period;
- generating, by the server system, a set of transaction features based, at least in part, on the set of transaction indicators;
- computing, by the server system via a chargeback risk prediction model, a set of chargeback risk probability scores corresponding to one or more time intervals based, at least in part, on the set of transaction features, each of the set of chargeback risk probability scores indicating chargeback behavioral data of the account holder within a particular time interval of the one or more time intervals; and
- transmitting, by the server system, a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores.
2. The computer-implemented method as claimed in claim 1, wherein the set of transaction features comprises at least one of: spend transaction features, merchant features of a plurality of merchants involved in the payment transactions, and fraud risk features.
3. The computer-implemented method as claimed in claim 2, wherein generating the set of transaction features comprises:
- determining, by the server system, a group of the set of transaction features of the account holder based, at least in part, on a network graph between the account holder and the plurality of merchants.
4. The computer-implemented method as claimed in claim 1, further comprising:
- classifying, by the server system, the account holder as a risky account holder or a non-risky account holder based, at least in part, on the set of chargeback risk probability scores; and
- upon classifying the account holder as the risky account holder, determining, by the server system, a probable chargeback amount band for potential future chargeback requests raised by the account holder within each time interval based, at least in part, on each of the set of chargeback risk probability scores and a chargeback amount prediction model.
5. The computer-implemented method as claimed in claim 4, wherein the chargeback risk prediction model is a gradient boosting decision tree (GBDT) based classification model, and wherein the chargeback amount prediction model is GBDT based ranking model.
6. The computer-implemented method as claimed in claim 4, further comprising
- determining, by the server system, a chargeback risk level for each time interval based, at least in part, on the probable chargeback amount band, wherein the chargeback risk level is selected from a plurality of chargeback risk levels comprising: a low chargeback risk level that is associated with a first chargeback amount band, a medium chargeback risk level that is associated with a second chargeback amount band, and a high chargeback risk level that is associated with a third chargeback amount band.
7. The computer-implemented method as claimed in claim 5, further comprising:
- transmitting, by the server system, the notification to the issuer server associated with the account holder based, at least in part, on the chargeback risk level for each time interval.
8. The computer-implemented method as claimed in claim 1, wherein the server system is associated with a payment network.
9. A server system, comprising:
- a communication interface;
- a memory comprising executable instructions; and
- a processor communicably coupled to the communication interface and the memory, the processor configured to execute the instructions to cause the server system, at least in part, to: access payment transaction data associated with an account holder from a transaction database, the payment transaction data comprising a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period; generate a set of transaction features based, at least in part, on the set of transaction indicators; compute via a chargeback risk prediction model, a set of chargeback risk probability scores corresponding to one or more time intervals based, at least in part, on the set of transaction features, each of the set of chargeback risk probability scores indicating chargeback behavioral data of the account holder within a particular time interval of the one or more time intervals; and transmit a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores.
10. The server system as claimed in claim 9, wherein the set of transaction features comprises at least one of: spend transaction features, merchant features of a plurality of merchants involved in the payment transactions, and fraud risk features.
11. The server system as claimed in claim 10, wherein the server system is further caused, at least in part, to:
- determine a group of the set of transaction features of the account holder based, at least in part, on a network graph between the account holder and the plurality of merchants.
12. The server system as claimed in claim 10, wherein the server system is further caused, at least in part, to:
- classify the account holder as a risky account holder or a non-risky account holder based, at least in part, on the set of chargeback risk probability scores; and
- upon classification of the account holder as the risky account holder, determine a probable chargeback amount band for potential future chargeback requests raised by the account holder within each time interval based, at least in part, on each of the set of chargeback risk probability scores and a chargeback amount prediction model.
13. The server system as claimed in claim 12, wherein the chargeback risk prediction model is a gradient boosting decision tree (GBDT) based classification model, and wherein the chargeback amount prediction model is GBDT based ranking model.
14. The server system as claimed in claim 12, wherein the server system is further caused, at least in part, to:
- determine a chargeback risk level for each time interval based, at least in part, on the probable chargeback amount band, wherein the chargeback risk level is selected from a plurality of chargeback risk levels comprising: a low chargeback risk level that is associated with a first chargeback amount band, a medium chargeback risk level that is associated with a second chargeback amount band, and a high chargeback risk level that is associated with a third chargeback amount band.
15. The server system as claimed in claim 14, wherein the server system is further caused, at least in part, to:
- transmit the notification to the issuer server associated with the account holder based, at least in part, on the chargeback risk level.
16. 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:
- accessing payment transaction data associated with an account holder from a transaction database, the payment transaction data comprising a set of transaction indicators corresponding to payment transactions performed by the account holder within a predetermined time period;
- generating a set of transaction features based, at least in part, on the set of transaction indicators;
- computing, via a chargeback risk prediction model, a set of chargeback risk probability scores corresponding to one or more time intervals based, at least in part, on the set of transaction features, each of the set of chargeback risk probability scores indicating chargeback behavioral data of the account holder within a particular time interval of the one or more time intervals; and
- transmitting a notification to an issuer server associated with the account holder based, at least in part, on the set of chargeback risk probability scores.
17. The non-transitory computer-readable storage medium as claimed in claim 16, wherein the set of transaction features comprises at least one of: spend transaction features, merchant features of a plurality of merchants involved in the payment transactions, and fraud risk features.
18. The non-transitory computer-readable storage medium as claimed in claim 16, further comprises:
- classifying the account holder as a risky account holder or a non-risky account holder based, at least in part, on the set of chargeback risk probability scores; and
- upon classifying the account holder as the risky account holder, determining a probable chargeback amount band for potential future chargeback requests raised by the account holder within each time interval based, at least in part, on each of the set of chargeback risk probability scores and a chargeback amount prediction model.
19. The non-transitory computer-readable storage medium as claimed in claim 16, wherein the chargeback risk prediction model is a gradient boosting decision tree (GBDT) based classification model, and wherein the chargeback amount prediction model is GBDT based ranking model.
20. The non-transitory computer-readable storage medium as claimed in claim 16, further comprises:
- determining a chargeback risk level for each time interval based, at least in part, on the probable chargeback amount band, wherein the chargeback risk level is selected from a plurality of chargeback risk levels comprising: a low chargeback risk level that is associated with a first chargeback amount band, a medium chargeback risk level that is associated with a second chargeback amount band, and a high chargeback risk level that is associated with a third chargeback amount band.
Type: Application
Filed: May 6, 2022
Publication Date: Nov 10, 2022
Inventors: Pranav Poduval (Noida), Arun Kanthali (Dewas), Ashish Kumar (Lucknow), Deepak Bhatt (Dehradun), Gaurav Oberoi (Meerut), Harsimran Bhasin (Delhi), Karamjit Singh (Gurugram), Rupesh Kumar Sankhala (Churu), Sangam Verma (Gurugram), Shiv Markam (Mandla)
Application Number: 17/739,040
