Description: The present disclosure relates to artificial intelligence-based processing systems, particularly focusing on electronic methods and complex processing systems for detecting unauthorized resellers in payment transactions.
BACKGROUND
The global marketplace has witnessed a proliferation of goods sold through various channels, including authorized distribution networks and unofficial, unregulated channels commonly referred to as ‘grey markets’. These grey markets include a complex ecosystem where products are traded outside the authorized distribution chain. This often creates challenges for manufacturers, brand owners, and consumers alike. Within the grey markets, unauthorized resellers acquire products from undisclosed sources and sell them through channels not approved or recognized by the original manufacturers or brand owners. These resellers operate independently, often sourcing products from surplus inventory, parallel imports, or other unofficial sources.
For manufacturers and brand owners, the presence of unauthorized resellers in grey markets poses multifaceted challenges. The challenges include a lack of control over product quality, potential brand dilution due to inferior or counterfeit products, erosion of brand value, and loss of revenue due to price differentials between authorized and unauthorized distribution channels. Users purchasing goods from grey market resellers are often unaware of the product’s origins, authenticity, or warranty coverage. This lack of transparency exposes consumers to potential risks related to product quality, after-sales support, and warranty services, leading to dissatisfaction and distrust in the brand.
Additionally, the presence of unauthorized resellers in grey markets raises legal issues concerning trademark infringements, distribution rights violations, and breaches of contractual agreements between brand owners and authorized distributors. Legal actions against these resellers often involve challenges in identifying and restraining their operations due to their decentralized and elusive nature. Recent technological advancements, such as blockchain, artificial intelligence (AI), and data analytics, offer potential solutions for monitoring, identifying, and mitigating the impact of unauthorized resellers in grey markets. These technologies provide opportunities for improved tracking, authentication, and enforcement mechanisms to curb the activities of grey market resellers. However, these solutions only provide products for particular merchants and have access to limited transaction data from a particular merchant. Also, for detecting the presence of the unauthorized resellers the conventional methods mostly use the labeled dataset from the transaction data available.
Thus, there exists a compelling need for innovative methodologies and systems that leverage technological advancements to effectively detect, track, and deter the activities of unauthorized resellers operating within grey markets and with a plurality of merchants. Such solutions aim to protect brand integrity, ensure consumer confidence, and maintain the sanctity of authorized distribution networks.
SUMMARY
Various embodiments of the present disclosure provide methods and systems for detecting unauthorized resellers in payment transactions.
In an embodiment, a computer-implemented for detecting suspicious merchants involved in preauthorization transactions is disclosed. The computer-implemented method performed by a server system includes receiving an authorization (auth) request associated with a payment transaction initiated by a cardholder with a merchant via a payment card. It is to be noted that the merchant may be an online merchant and the cardholder may transact with the online merchant using an online app or website. The payment transaction is to be conducted by a cardholder to the merchant. Upon receiving the auth request, the method further includes a plurality of features for the cardholder from a database associated with the server system based, at least in part, on a plurality of payment transactions performed by the cardholder with a plurality of merchants. Herein, at least one feature of the plurality of features indicate a hoarding transaction pattern associated with a set of labeled payment transactions (otherwise, also referred to as a labeled transaction dataset) of the plurality of payment transactions. The plurality of payment transactions may also include a set of unlabeled payment transactions (otherwise, also referred to as an unlabeled transaction dataset) as well. The advantage of using the labeled and unlabeled transaction dataset enables the use of all the available datasets for the detection of the hoarder. Herein, the plurality of features includes a plurality of cardholder-related features corresponding to the cardholder and a plurality of merchant-related features corresponding to the merchant. Further, the method includes generating, via a pseudo-label generation model, a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and the plurality of payment transaction attributes, for generating a set of pseudo-labeled payment transactions. Further, the method includes generating, via a hoarding prediction model, a hoarding probability score associated with the ongoing payment transaction based, at least in part, on the set of labeled payment transactions and the set of pseudo-labeled payment transactions. Herein, the hoarding probability score indicates a likelihood of the ongoing payment transaction being associated with a hoarding risk. Furthermore, the method includes transmitting the hoarding probability score to an acquirer server associated with the merchant for further action.
In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to receive an authorization (auth) request associated with a payment transaction initiated by a cardholder with a merchant via a payment card. Herein, the payment transaction is to be conducted by a cardholder to a merchant. Upon receiving the auth request, the server system is caused to access a plurality of features for the cardholder from a database associated with the server system based, at least in part, on a plurality of payment transactions performed by the cardholder with a plurality of merchants. Herein, at least one feature of the plurality of features indicates a hoarding transaction pattern associated with a set of labeled payment transactions of the plurality of payment transactions. The plurality of features includes a plurality of cardholder-related features corresponding to the cardholder of the plurality of cardholders and a plurality of merchant-related features corresponding to the merchant. Further, the server system is caused to generate, via a pseudo-label generation model, a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and the plurality of payment transaction attributes, for generating a set of pseudo-labeled payment transactions. Further, the server system is caused to generate, via a hoarding prediction model, a hoarding probability score associated with the ongoing payment transaction based, at least in part, on the set of labeled payment transactions and the set of pseudo-labeled payment transactions. Herein, the hoarding probability score indicates a likelihood of the payment transaction being associated with a hoarding risk. Furthermore, the server system is caused to transmit the hoarding probability score to an acquirer server associated with the merchant for further action.
In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving an authorization (auth) request associated with a payment transaction initiated by a cardholder with a merchant via a payment card. Herein, the payment transaction is to be conducted by a cardholder to a merchant. Upon receiving the auth request, the method further includes accessing a plurality of features for the cardholder from a database associated with the server system based, at least in part, on a plurality of payment transactions performed by the cardholder with a plurality of merchants. Herein, at least one feature of the plurality of features indicate a hoarding transaction pattern associated with a set of labeled payment transactions of the plurality of payment transactions. Herein, the plurality of features includes a plurality of cardholder-related features corresponding to each cardholder of the plurality of cardholders and a plurality of merchant-related features corresponding to the merchant. Further, the method includes generating, via a pseudo-label generation model, a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and a plurality of payment transaction attributes, for generating a set of pseudo-labeled payment transactions. Further, the method includes generating, via a hoarding prediction model, a hoarding probability score associated with the payment transaction based, at least in part, on the set of labeled payment transactions and the set of pseudo-labeled payment transactions. Herein, the hoarding probability score indicates a likelihood of the ongoing payment transaction being associated with a hoarding risk. Furthermore, the method includes transmitting the hoarding probability score to an acquirer server associated with the merchant for further action.

BRIEF DESCRIPTION OF THE FIGURES
For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
FIG. 1 illustrates a schematic representation of an environment related to at least some example embodiments of the present disclosure;
FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
FIG. 3 illustrates a process flow diagram of generating the hoarding probability score, in accordance with an embodiment of the present disclosure;
FIG. 4 illustrates a schematic representation of a process of training machine learning (ML) models for generating the hoarding probability score, in accordance with an embodiment of the present disclosure;
FIG. 5 illustrates a flow diagram of a process of training the machine learning models, in accordance with an embodiment of the present disclosure;
FIG. 6 illustrates a flow diagram depicting a method for generating a hoarding probability score involved in payment transactions, in accordance with an embodiment of the present disclosure;
FIG. 7 illustrates a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
FIG. 8 illustrates a simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure; and
FIG. 9 illustrates a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
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 appearances of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
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, a system, a method, or a 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 terms “account holder”, “user”, “cardholder”, and “buyer” 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 “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. For example, the merchants may include buyers and sellers of commodities for profit, a trader, a storekeeper, health care centers, hotels, restaurants, vehicle rentals, petrol/gas stations, etc.
The term “hoarder” used throughout the description, unless the context suggests otherwise, refers to a cardholder who is involved in some hoarding activity. For instance, in a scenario of bulk purchase of products in a payment transaction, a cardholder who performs repeated bulk purchasing from a merchant after a regular interval of time may be termed as a “hoarder”. The cardholder may resell the products brought in bulk without proper authorizations required for reselling the products. Herein, it may be noted that the cardholders involved in such types of unauthorized reselling may cause loss to the merchants.
The terms “payment network” and “card network” are used interchangeably throughout the description and refer to a network or collection of systems used for the transfer of funds through the use of cash substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Payment networks are companies that connect an issuing bank with an acquiring bank to facilitate online payment. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash substitutes that may include payment cards, letters of credit checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as Mastercard®.
The term “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 the form of data stored in a user device, where the data is associated with a payment account such that the data can be used to process the financial transaction between the payment account and a merchant’s financial account.
The term “payment account” used throughout the description refers to a financial account that is used to fund a financial transaction. Examples of the financial account include, but are not limited to a savings account, a credit account, a checking account, and a virtual payment account. The financial account may be associated with an entity, such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, 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 terms “payment transaction”, “financial transaction”, “event”, and “transaction” are used interchangeably throughout the description and refer to a transaction of payment of a certain amount being initiated by the cardholder. More specifically, refers to electronic financial transactions including, for example, online payment, and payment at a terminal (e.g., point of sale (POS) terminal, ATM, self-service kiosks, and the like).
OVERVIEW
Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for detecting unauthorized resellers associated with a payment transaction. In an embodiment, the present disclosure describes a server system for detecting the unauthorized resellers/hoarders associated with the payment transaction. The server system may be a payment server associated with a payment network. The server system includes a processor and a memory. In an embodiment, the server system is configured to receive an authorization (auth) request corresponding to a payment transaction. Herein, the payment transaction is to be conducted by a cardholder to a merchant via a payment card. Upon receiving the auth request, the server system is caused to access a cardholder-related dataset associated with the cardholder from the database based, at least in part, on the plurality of payment transaction attributes. Herein, the cardholder-related dataset may include historical information corresponding to the plurality of payment transactions performed by the cardholder with the plurality of merchants. Further, the server system may extract a plurality of features from the cardholder-related dataset associated with each payment transaction. The server system may further store the plurality of features for each payment transaction performed by the cardholder in the database for future access.
Further, the server system may access the plurality of features for the cardholder from the database based, at least in part, on the plurality of payment transactions performed by the cardholder with the plurality of merchants. Herein, at least one feature of the plurality of features may indicate a hoarding transaction pattern associated with a set of labeled payment transactions of the plurality of payment transactions. The plurality of features may also be associated with a set of unlabeled payment transactions. The advantage of using the labeled and unlabeled payment transactions enables the use of all the available datasets for the detection of the hoarder. The plurality of features includes a plurality of cardholder-related features corresponding to each cardholder of the plurality of cardholders and a plurality of merchant-related features corresponding to the merchant. It may be noted that the plurality of features includes at least one of, an amount of transactions, a count of transactions in a plurality of hoarding zones, a count of high velocity transactions in the plurality of hoarding zones, a frequency of transactions in the plurality of hoarding zones, a count of transactions in past few months, a count of transactions with merchant with high hoarding transaction in past, an email associated with hoarding, a count of cards associated with emails, and the like.
Further, the server system is caused to generate, via a pseudo-label generation model, a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and the plurality of payment transaction attributes, for generating a set of pseudo-labeled payment transactions. In an embodiment, the two ML models may include the pseudo-label generation model and a hoarding prediction model. In at least one embodiment, the pseudo-label generation model and the hoarding prediction model may correspond to a binary classification model. Further, the server system is caused to generate, via the hoarding prediction model, a hoarding probability score associated with the ongoing payment transaction based, at least in part, on the set of labeled payment transactions and the set of pseudo-labeled payment transactions. Herein, the hoarding probability score indicates a likelihood of the ongoing payment transaction being associated with a hoarding risk. It may be noted that for generating the hoarding probability score, the server system may be configured to determine, a plurality of payment cards that are associated with the cardholder based on the personal information of the user such as the email ID and shipping address of the cardholder. Based on this data a card-based score is generated which is further used to determine the hoarding risk score. Further, a plurality of hoarding zones is determined and the probability of the payment transaction being associated with the hoarding risk is also determined. It is noted that the card-based score, the plurality of hoarding zones, and the probability of the payment transaction being associated with the hoarding risk are used to determine the hoarding probability score associated with the payment transaction.
The server system is further configured to generate, the pseudo-label generation model and the hoarding prediction model (referred to as ML models or set of ML models) based, at least in part, on performing a set of operations iteratively till the performance of the pseudo-label generation model and the hoarding prediction model converges to predefined criteria. The server system is further configured to initialize the ML models based, at least in part, on one or more model parameters and an initial prediction. Further, the server system is configured to generate a classifier for generating predictions based, at least in part on the plurality of features and further compute one or more optimization parameters based at least on the performance of the classifier, using one or more optimization functions. Further, the server system is configured to build a new classifier for reducing one or more optimization parameters and further assign weights to the new classifier and the previously generated classifier based, at least in part, on the performance of the new classifier and the previously generated classifier in reducing the one or more optimization parameters. Furthermore, the server system is configured to generate an ensemble of a plurality of classifiers by adding predictions of the new classifier to predictions of the previously generated classifier and optimizing one or more first model parameters.
Furthermore, the server system is configured to transmit a transaction decline message from the merchant to the cardholder if the hoarding probability score is more than a predefined threshold.
In an embodiment, the server system is configured to transmit a transaction-approved message from the merchant to the cardholder if the hoarding probability score is less than a predefined threshold.
Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure is intended to facilitate merchants with the ability to identify suspicious cardholders and/or suspicious payment transactions associated with the hoarding behavior or associated with the unauthorized reseller behavior. Unauthorized resellers can damage a brand’s reputation by selling counterfeit or low-quality products. Detecting and stopping them helps maintain the brand’s integrity and quality standards. The technical solutions provided in the present disclosure employ advanced data analytics and AI-based techniques to detect whether a cardholder is a hoarder or not, by generating a hoarding probability score. Such intelligent forecasting, coupled with the notification to the merchant helps the merchant to obtain decision-making intelligence whether to allow the transaction to proceed or not. In addition, the system proposed in the present disclosure also facilitates detecting a type or level of risk involved with the hoarding transaction, i.e., whether the hoarding transaction is of high risk, medium risk, or low risk based on the hoarding probability score. Overall, the technical benefits of the disclosed system encompass more secure, and efficient, to detect hoarders within the financial domain that is achieved by intelligent AI-based techniques, advanced detection capabilities, and data-driven decision-making.
Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 9.
FIG. 1 illustrates a block diagram representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, determining a hoarding probability score that helps to detect whether a cardholder is an unauthorized reseller, whether a payment transaction is suspicious of being performed by an unauthorized reseller, detect suspicious cardholders (otherwise, also referred to as unauthorized reseller) before observing a hoarding behavior on at least one merchant, during hoarding, or after the hoarding behavior is observed on the at least one merchant.
The environment 100 generally includes a plurality of entities, such as a server system 102, a cardholder 104 with a mobile device 106, and a plurality of payment cards 108(1), 108(2), … 108(N), (collectively referred to as a ‘plurality of payment cards 108’ or ‘payment cards 108’ or singularly as ‘payment card 108’), a plurality of merchants 110(1), 110(2), … 110(N) (collectively referred to as a ‘plurality of merchants 110’ or ‘merchants 110’), a plurality of issuer servers 112(1), 112(2), … 112(N), (collectively referred to as a ‘plurality of issuer servers 112’ or ‘issuer servers 112’), a plurality of acquirer servers 114(1), 114(2), … 114(N), (collectively referred to as a ‘plurality of acquirer servers 114’ or ‘acquirer servers 114’), a payment network 116 including a payment server 118, and a database 120 each coupled to, and in communication with (and/or with access to) a network 122. Herein, ‘N’ is a non-zero natural number.
The network 122 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts or users illustrated in FIG. 1, or any combination thereof.
Various entities in the environment 100 may connect to the network 122 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, New Radio (NR) communication protocol, any future communication protocol, or any combination thereof. In some instances, the network 122 may utilize a secure protocol (e.g., Hypertext Transfer Protocol (HTTP), Secure Socket Lock (SSL), and/or any other protocol, or set of protocols for communicating with the various entities depicted in FIG. 1.
In an embodiment, the cardholder 104 uses one or more payment cards, such as the payment cards 108(1), 108(2)… 108(N) to make payment transactions using the mobile device 106. As may be understood, the cardholder (e.g., the cardholder 104) may be any individual, representative of a corporate entity, a non-profit organization, or any other person who is presenting payment account details during an electronic payment transaction, or a hoarder who does unauthorized reselling. The cardholder (e.g., the cardholder 104) may have a payment account issued by an issuing bank (not shown in figures) associated with the issuer servers 112 and may be provided with a payment card (e.g., payment card 108(1)) with financial or other account information encoded onto the payment card 108(1) such that the cardholder (i.e., the cardholder 104) may use the payment card 108(1) to initiate and complete a payment transaction using a bank account at the issuing bank. In another embodiment, the cardholder 104 may use multiple payment cards such as the payment cards 108(1), 108(2) … 108(N) to transact with the merchant such as the merchant 110.
In yet another embodiment, the cardholder 104 may use their corresponding electronic devices (e.g., the mobile device 106) to access a mobile application or a website associated with the issuing bank, or any third-party payment application to perform a payment transaction. In various non-limiting examples, the electronic devices may refer to any electronic devices, such as, but not limited to, personal computers (PCs), tablet devices, smart wearable devices, Personal Digital Assistants (PDAs), voice-activated assistants, Virtual Reality (VR) devices, smartphones, laptops, and the like.
In an embodiment, the merchants 110 may include retail shops, restaurants, supermarkets or establishments, government and/or private agencies, or any such places equipped with POS terminals, where cardholders visit to perform the financial transactions in exchange for any goods and/or services or any financial transactions.
In one scenario, the cardholder 104 may use their corresponding payment accounts to conduct payment transactions with the plurality of merchants 110. Moreover, it may be noted that each of the cardholder 104 may use their corresponding payment cards differently or make the payment transaction using different means of payment. For instance, the cardholder 104 may enter payment account details on an electronic device (e.g., the mobile device 106) associated with the cardholder 104 to perform an online payment transaction. In another instance, the cardholder 104 may utilize the payment card 108(1) to perform an offline payment transaction. It is understood that generally, the term “payment transaction” refers to an agreement that is carried out between a buyer and a seller to exchange goods or services in exchange for assets in the form of a payment (e.g., cash, fiat-currency, digital asset, cryptographic currency, coins, tokens, etc.). For example, the cardholder 104 may enter details of the payment card to transfer funds in the form of fiat currency on an e-commerce platform to buy goods. Further, the cardholder 104 may transact at any merchant from the plurality of merchants 110 (e.g., the merchant 110(1)).
In one embodiment, the cardholder 104 is associated with the issuer servers 112. In one embodiment, the issuer servers 112 are associated with financial institutions normally called an “issuer bank”, “issuing bank” or simply “issuer”, in which a cardholder (e.g., the cardholder 104) may have the payment account, (which also issues a payment card, such as a credit card or a debit card), and provides microfinance banking services (e.g., payment transaction using credit/debit cards) for processing electronic payment transactions, to the cardholder (e.g., the cardholder 104).
In an embodiment, the merchants are generally associated with the acquirer servers 114. In one embodiment, the acquirer servers 114 are associated with financial institutions (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, merchants, or institutions that own platforms that make either online purchases or purchases made via software applications possible. The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
In a non-limiting example, when the cardholder 104 uses their payment card out of the plurality of payment card 108(1), 108(2), … 108(N) for making payment at a merchant (e.g., the merchant 110) via a merchant website, an authorization request may be generated for checking whether the cardholder 104 is a hoarder or not. In such a scenario, the cardholder 104 may enter a plurality of personal details and a plurality of transaction-related details for placing the order with the merchant say the merchant 110. Herein, instead, of purchasing a single product from the merchant the cardholder 104 may make a bulk purchase from the merchant of the same product. The cardholder 104 may make a bulk purchase to further resell the products in an unauthorized manner and without the consent of the merchant such as the merchant 110(1). It is noted that unauthorized reselling can lead to a loss of profits for the original manufacturer or brand. Further, the products might be sold at a lower price by unauthorized resellers such as the cardholder 104, which can result in a decrease in sales for the original manufacturer, leading to a loss of revenue. For example, the cardholder 104 may initiate unauthorized reselling of the products brought by them in bulk, and may not adhere to the same quality standards as authorized resellers, which can lead to damage to the brand’s reputation. This can result in a loss of customer trust and loyalty, which can be detrimental to the brand’s long-term success. Additionally, it is to be noted that unauthorized resellers may not offer the same level of warranty and support as authorized resellers, which can result in dissatisfaction and negative reviews of the buyer for the original manufacturer or brand. This can damage the brand’s reputation and lead to a loss of customer trust and loyalty.
The above-mentioned technical problem, among other problems, is addressed by one or more embodiments implemented by the server system 102 and methods thereof provided in the present disclosure.
In one embodiment, the server system 102 is configured to facilitate the detection of unauthorized resellers/hoarders at the merchant’s end using various Artificial Intelligence (AI) or Machine Learning (ML) models. In some embodiments, this detection may be done before a hoarding transaction, during the hoarding transaction, or after the hoarding transaction has occurred. In some embodiments, the server system 102 may be deployed as a standalone server or may be implemented in the cloud as software as a service (SaaS). The server system 102 may be configured to provide or host a software application on electronic devices used by the merchant to detect such hoarding transactions. In an embodiment, along with detecting the hoarding transactions, the server system 102 also notifies the merchant about the amount of risk involved with the hoarding transaction and also recommends actions that may be taken by the merchant (e.g., the merchant 110(1)), determining a probability of the payment transaction being a hoarding transaction, and the like.
It should be understood that the server system 102 is a separate part of the environment 100, and may operate apart from (but still in communication with, for example, via the network 122) any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may be incorporated, in whole or in part, into one or more parts of the environment 100.
Further, it may be noted that, in an example, the server system 102 coupled with the database 120 is embodied within the payment server 118, however, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the issuer servers 112 and the acquirer servers 114. The database 120 may be incorporated in the server system 102 or maybe an individual entity connected to the server system 102 or maybe a database stored in cloud storage.
In various non-limiting examples, the database 120 may include one or more hard disk drives (HDD), solid-state drives (SSD), an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a redundant array of independent disks (RAID) controller, a storage area network (SAN) adapter, a network adapter, and/or any component providing the server system 102 with access to the database 120. In one implementation, the database 120 may be viewed, accessed, amended, updated, and/or deleted by an administrator (not shown) associated with the server system 102 through a database management system (DBMS) or relational database management system (RDBMS) present within the database 120.
As may be understood, for the server system 102 to be able to facilitate such features, the server system 102 collects historical information related to the previous transactions performed by the plurality of cardholders such as the cardholder104 with the plurality of merchants (e.g., the merchants 110(1), 110(2), … 110(N)) that are a part of the network 122 and store the same in the database 120. In an embodiment, the database 120 may also store a pseudo-label generation model 124 and a hoarding prediction model 126.
In a non-limiting example, the historical information is related to a plurality of transactions performed by the cardholder such as the cardholder 104 and other cardholders with the plurality of merchants, such as the merchants 110(1), 110(2) …110(N). In an embodiment, the historical information may include payment cards associated with the cardholders with previous hoarding history, merchants who are more prone to the hoarding activity, and a region or zone where merchants are more prone to hoarding activity (unauthorized reselling). It is noted that the region or zone where merchants are more prone to hoarding activity may also be referred to as a “hoarding zone”. In an embodiment, the historical information may also include previous transactions performed by the cardholders with the plurality of merchants such as the merchants 110 or the various payment cards such as the payment cards 108(1), 108(2) … 108(N) owned by the cardholders such as the cardholder 104.
In other various examples, the database 120 may also include multifarious data, for example, social media data, Know Your Customer (KYC) data, payment data, trade data, employee data, Anti Money Laundering (AML) data, market abuse data, Foreign Account Tax Compliance Act (FATCA) data, and fraudulent payment transaction data.
Further, in an example, the database 120 also stores merchant profile data associated with the plurality of merchants 110. In one embodiment, the merchant profile data may include data such as the merchant DBA name, name of the merchant, transaction information of the plurality of cardholders such as the cardholder 104 at a particular merchant (e.g., the merchant 110(1)), information of fraudulent or non-fraudulent transactions performed at the merchant, information about the previous unauthorized hoarding done at the merchant end of the merchants 110, information about the particular cardholder responsible for unauthorized hoarding at the merchants such as the merchants 110, various terminals (e.g., point-of-sale (POS) devices, automated teller machines (ATMs), etc.), associated with each merchant (e.g., the merchant 110(1)), and the like.
In yet another example, the database 120 stores historical payment transaction data that may also include real-time transaction data of the plurality of cardholders such as the cardholder 104 and the plurality of merchants 110. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past ‘x’ number of days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction. In addition, the database 120 provides a storage location for data and/or metadata obtained from various operations performed by the server system 102.
In an embodiment, whenever a cardholder (e.g., the cardholder 104) initiates an authorization (auth) request, it may be noted that the server system 102 is configured to receive the auth request. Herein, the auth request may correspond to a payment transaction initiated by a cardholder such as the cardholder 104 with the merchant 110(1). Herein, the payment transaction is to be conducted by the cardholder 104 to the merchant 110(1). In an embodiment, the payment transaction may correspond to a future transaction which may be conducted at the time of checking out or once the service is received/completed, or may correspond to a past transaction which has already occurred between the cardholder 104 and the merchant 110.
Upon receiving the auth request, the server system 102 identifies a possibility of the cardholder 104 being a hoarder or an unauthorized reseller. To that effect, the server system 102 may initially access the historical transaction data corresponding to the merchant 110(1) and the cardholder 104 from the database 120. As may be understood, the historical transaction data includes the historical information related to a plurality of transactions performed by the merchant 110(1) with the plurality of cardholders such as the cardholder 104. For example, the historical information may include, but is not limited to, past transaction amounts for which the cardholders transacted with the merchant such as the merchant 110(1), a categorization of the merchant such as the merchant 110(1) as high risk, medium risk or low risk, number of transactions with high-risk merchants, number of transactions with a merchant such as the merchant 110(1) with high hoarding transactions in past, number of transactions of the merchant 110(1) with the specific cardholder such as the cardholder 104, and the like.
As may be understood, the historical transaction data includes the historical information related to the plurality of transactions performed by the cardholder such as the cardholder 104, the email information indicator, i.e., if the cardholder 104 is associated with multiple email identifiers (IDs), a cardholder email associated with the hoarding transactions in the past, number of payment cards associated with an email ID of the cardholder 104, number of hoarding transactions on other payment cards associated with the email ID of the cardholder 104.
It may be noted that using the historical transaction data, the server system 102 may have to train the pseudo-label generation model 124 and the hoarding prediction model 126 so that the server system 102 can identify cardholders with hoarding risks every time it receives auth requests. Therefore, the historical transaction data may have to be prepared for training the pseudo-label generation model 124 and the hoarding prediction model 126 which involves pre-processing of the historical transaction data. One of the pre-processing steps includes the generation of features for each data point from the historical transaction data. Thus, in an embodiment, the server system 102 is further configured to generate a plurality of features based, at least in part, on the historical transaction data for the corresponding cardholder 104.
In an example embodiment, the plurality of features may include a plurality of cardholder-related features corresponding to the cardholder 104 and a plurality of merchant-related features corresponding to the merchant (e.g., the merchant 110(1)). Herein, it may be noted that the plurality of cardholder-related features corresponding to the cardholder 104 may be generated based, at least in part, on historical information related to a plurality of auth transactions performed by the cardholder 104 at the plurality of merchants 110. This way the plurality of cardholder-related features for the cardholder 104 may be determined by the server system 102. Herein, it may be noted that such historical information may also be accessed from the database 120, wherein the historical information is associated with the historical transaction data.
Furthermore, in an embodiment, the plurality of merchant-related features may be generated based, at least in part, on historical information related to a plurality of past auth transactions performed by the merchant such as the merchant 110(1) with the plurality of cardholders such as the cardholder 104. The server system 102 may further be configured to generate, via the pseudo-label generation model 124 and the hoarding prediction model 126, a hoarding risk score, hereinafter, interchangeably referred to as a hoarding probability score associated with the payment transaction based, at least in part, on the plurality of features. Herein, the hoarding risk score may indicate a likelihood of the payment transaction being associated with a hoarding risk or further risks associated with unauthorized reselling of the products. The process of the generation of the hoarding risk score is described in the present disclosure with reference to FIG. 3. Furthermore, in an embodiment, the plurality of hoarding zone-related features may be generated based, at least in part, on historical information related to a plurality of past auth transactions. Herein, the hoarding zone-related features may include a number of high-velocity transactions performed by the payment cards in top hoarding zones based on latitude/longitude data, the number of transactions in the past few months in the hoarding zones, and the like. Additionally, other common features considered for determining the hoarding risk score may include the number of transactions in the past few months by the cardholder 104, the average amount spent by the cardholder 104, the number of high-value transactions (transaction bins), previous months chargeback amount associated with the cardholder, etc.
It may be noted that apart from the historical transaction data, the server system 102 also considers the ongoing transaction attributes such as the personal data or the three-Domain Secure (3DS 2.0) data associated with the cardholder 104, the auth data associated with the ongoing transaction to determine the hoarding risk score associated with the cardholder and the same will be explained with respect to FIG. 2.
Moreover, for the server system 102 to be able to use the pseudo-label generation model 124 and the hoarding prediction model 126, the server system 102 may have to train and generate the two models. Therefore, in an embodiment, the server system 102 may further be configured to generate each of the pseudo-label generation model 124 and the hoarding prediction model 126 based, at least in part, on performing a set of operations iteratively till the performance of each of the pseudo-label generation model 124 and the hoarding prediction model 126 converges to predefined criteria corresponding to each of the pseudo-label generation model 124 and the hoarding prediction model 126. It may be noted that the set of operations performed, a count of iterations for performing the set of operations, and the predefined criteria for each of the pseudo-label generation model 124 and the hoarding prediction model 126 may be the same, as a set of features provided to each of the pseudo-label generation model 124 and the hoarding prediction model 126 is also same. Thus, for training each of the pseudo-label generation model 124 and the hoarding prediction model 126, the plurality of features may be required.
In some embodiments, each of the pseudo-label generation model 124 and the hoarding prediction model 126 may correspond to a binary classification model. In a specific example, each of the two ML models may correspond to an extreme gradient boosting (XGBoost) model or a Multi-layer Perceptron (MLP) classifier. As may be understood, in some scenarios, each of the two ML models may be generated by the server system 102, the process of the generation of each of the ML models is further described in subsequent figures.
It may be noted that as one of the objectives of the present disclosure is to understand the hoarding behavior of the cardholder 104 for identifying potential hoarders/unauthorized resellers, the cardholder-related features are also considered along with the merchant-related features for training each of the pseudo-label generation model 124 and the hoarding prediction model 126.
Upon generating the hoarding risk score, in an embodiment, the server system 102 may also be configured to flag a merchant or the acquirer about the auth request when the hoarding risk score is at least equal to a threshold risk score. It is to be noted that the value of the threshold risk score may be different for each merchant such as the merchant 110(1), merchant 110(2), etc. In a non-limiting example, the hoarding risk score may be a value between 0 and 999. Herein, a value close to 0 may indicate a lower risk which means that the cardholder 104 who is performing the payment transaction is less likely to be a hoarder/unauthorized reseller. Alternatively, a value close to 999 may indicate a higher risk which means that the cardholder 104 is more likely to be a hoarder/unauthorized reseller. Further, in an embodiment, the hoarding risk score indicates a lower risk when the hoarding risk score is less than the threshold risk score and a higher risk when the hoarding risk score is greater than or equal to the threshold risk score. In some embodiments, the threshold risk score may be of any other value without limiting the scope of the invention. In one embodiment, the method includes merchant-wise probability scaling for top hoarding-related cards (based on hoarding probability associated with the payment card and event rate) to give a score between 900-999. In other embodiments, the merchant-wise probability scaling for other payment cards may be from 0-899.
The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks; and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device is shown in FIG. 1 may be implemented as multiple, distributed systems or devices. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 122, which may be specifically configured, via executable instructions, to perform steps as described herein, and/or embodied in at least one non-transitory computer-readable media.
FIG. 2 illustrates a simplified block diagram of a server system 200, in accordance with an embodiment of the present disclosure. The server system 200 is identical to the server system 102 of FIG. 1. In one embodiment, the server system 200 is a part of the payment network 112 or integrated within the payment server 118. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
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, a user interface 212, and a storage interface 214. The one or more components of the computer system 202 communicate with each other via a bus 216. The components of the server system 200 provided herein may not be exhaustive and the server system 200 may include more or fewer components than those depicted in FIG. 2. Further, two or more components depicted in FIG. 2 may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities.
In some embodiments, the database 204 is integrated into the computer system 202. In one non-limiting example, the database 204 is configured to store a pseudo-label generation model 218, a hoarding prediction model 220, and the dataset 222 including the historical and present transaction data. Herein, the pseudo-label generation model 218 and the hoarding prediction model 220 and examples for the pseudo-label generation model 124 and the hoarding prediction model 126 of FIG. 1, and the dataset 222 are identical to the historical transaction data mentioned in the description of FIG. 1.
Further, the computer system 202 may include one or more hard disk drives as the database 204. The user interface 212 is an interface such as a Human Machine Interface (HMI) or a software application that allows users such as an administrator to interact with and control the server system 200 or one or more parameters associated with the server system 200. It may be noted that the user interface 212 may be composed of several components that vary based on the complexity and purpose of the application. Examples of components of the user interface 212 may include visual elements, controls, navigation, feedback and alerts, user input and interaction, responsive design, user assistance and help, accessibility features, and the like. More specifically these components may correspond to icons, layout, color schemes, buttons, sliders, dropdown menus, tabs, links, error/success messages, mouse and touch interactions, keyboard shortcuts, tooltips, screen readers, and the like.
The storage interface 214 is any component capable of providing the processor 206 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.
The processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for monitoring and detecting the hoarding activity of the cardholder such as the cardholder 104 while performing a payment transaction with a merchant such as the merchant 110, determining a probability that the payment transaction being related to hoarding risk, detecting suspicious cardholders involved in the payment transactions, and the like. 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 graphical processing unit (GPU), a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like.
The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 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 in the server system 200, as described herein. In another embodiment, the memory may be realized in the form of a database server or a 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 224 such as the issuer servers 112, the acquirer servers 114, the payment server 118, or communicating with any entity connected to the network 122 (as shown in FIG. 1).
It is noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 200 may include fewer or more components than those depicted in FIG. 2. It should be noted that the server system 200 is identical to the server system 102 described in reference to FIG. 1.
In one implementation, the processor 206 includes a data pre-processing module 226, a training module 228, a pseudo-label generation module 230, a hoarding risk score computation module 232, and a notification module 234. It should be noted that components, described herein, such as the data pre-processing module 226, the training module 228, the pseudo-label generation module 230, the hoarding risk score computation module 232, and the notification module 234 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.
In an embodiment, the data pre-processing module 226 includes suitable logic and/or interfaces for receiving an authorization (auth) request corresponding to a payment transaction initiated by the cardholder 104. Herein, the payment transaction is to be conducted by the cardholder 104 to the merchant 110(1). It may be understood that when the cardholder 104 approaches or contacts the merchant 110(1) to purchase a product or to receive a service, the auth request can be initiated and transmitted to the acquirer/merchant even though the payment transaction may be conducted at a later stage.
For example, the cardholder 104 initiates an online purchase of a play station on an online merchant such as the merchant 110(2). Herein, suppose the merchant 110(2) has a facility for accepting payments using debit or credit cards. In such a scenario, the merchant, i.e., the online merchant may initiate an auth request to the payment server (e.g., the payment server 118) to check if the cardholder 104 has sufficient balance or funds in their account in their issuer bank in case a debit card is used. In case a credit card is used by the cardholder 104 for online purchase transaction of the play station, the auth request may be initiated to check whether a credit limit associated with the credit card of the cardholder 104 permits the cardholder 104 to obtain such a service from the merchant.
It may be noted that while initiating the auth request, the cardholder 104, may purchase multiple quantities of the same product from the same merchant/similar merchants. Upon receiving such auth requests, the merchants and the associated acquirers are supposed to verify the authenticity of such auth requests and approve or reject them. The server system 102 helps the merchants and the associated acquirers to make such decisions by providing a hoarding probability risk score associated with such auth requests.
Further, in the example considered, once the auth request from the merchant 110(1) is received by the server system 200, the hoarding behavior related to the cardholder 104 is identified. This includes extracting the personal data about the cardholder 104 and also the transaction-related details of the cardholder 104. It is to be noted that the personal details may be the 3DS 2.0 related data about the cardholder 104 such as a cardholder name, a cardholder email ID, a cardholder phone number, a cardholder shipping address, a cardholder-related browser IP address, a cardholder related browser details, such as time zone, latitude, longitude, etc. Additionally, the transaction-related details will include a transaction card number, a transaction amount, a transaction-related date and time, a merchant ID related to the merchant with whom the cardholder 104 is transacting, and the like.
In an embodiment, the auth request/transaction request may include a plurality of details corresponding to the payment transaction that needs to be performed by the cardholder 104 at the merchant such as the merchant 110(1). In a non-limiting example, the plurality of details may include a merchant identity (ID), merchant account details, merchant contact details, merchant terms, and conditions, cardholder personal details, and the like. In another non-limiting example, the plurality of details may further include cardholder ID, cardholder account details, cardholder contact details, and the like.
In some embodiments, the database 204 may also keep track of such auth requests and hence may store such requests and the plurality of details associated with such requests. In some other embodiments, the database 204 may also store a historical payment transaction dataset including information related to at least merchant name identifier, unique merchant identifier, timestamp information, geo-location related data, merchant category code (MCC), information related to payment instruments involved in the set of historical payment transactions, cardholder identifier, permanent account number (PAN), merchant DBA name, disclosed merchant category, country code, transaction identifier, and the like. In one example, the historical payment transaction dataset may define a relationship between a cardholder account and a merchant account. For example, when a cardholder purchases an item from a merchant, a relationship is defined.
In another embodiment, the historical payment transaction dataset may include information related to past payment transactions such as transaction date, transaction time, geo-location of a transaction, transaction amount, transaction marker (e.g., fraudulent or non-fraudulent, hoarder or non-hoarder), and the like. In yet another embodiment, the historical payment transaction dataset may include information related to the acquirer servers 114, such as the date of merchant registration with the acquirer servers 114, amount of payment transactions performed at the acquirer servers 114 in a day, number of payment transactions performed at the acquirer servers 114 in a day, maximum transaction amount, minimum transaction amount, number of hoarders or non-hoarders registered with the acquirer servers 114, and the like.
Further, in an embodiment, upon receiving the auth request, the data pre-processing module 226 may be configured to access the dataset 222 which includes the historical transaction dataset corresponding to the cardholder 104 and the merchant such as the merchant 110(1) from the database 204 associated with the server system 200. Herein, the dataset 222 may include historical information related to a plurality of auth transactions performed by the merchant 110(1) with a plurality of cardholders (e.g., the cardholder 104).
In a non-limiting example, the historical information may be similar to the historical payment transaction dataset but related to the plurality of auth transactions performed by the merchant 110(1) with the plurality of cardholder 104 instead of mere payment transactions as mentioned above. In another example, the historical information may include a transaction amount, a frequency of hoarding transactions at a particular merchant such as the merchant 110(1) from the plurality of cardholders such as the cardholder 104, and the like.
It may be noted that the historical transaction data corresponding to the cardholder 104 and the merchant 110 may be accessed by the data pre-processing module 226 from the dataset 222 to analyze the corresponding historical transaction data for obtaining characteristics or properties of data samples of the historical transaction data which may also be referred to as features. In other words, it may be understood that one of the pre-processing steps includes generating features from input data. Therefore, the data pre-processing module 226 may further be configured to generate a plurality of features based, at least in part, on the dataset 222.
In some embodiments, prior to the generation of the features, the data pre-processing module 226 may be configured to gather data samples from the dataset 222 and target values. Herein, in one embodiment, the target values may include labels for a classification task or numerical values for a regression task. Further, the data pre-processing module 226 may be configured to perform pre-processing steps, such as handling missing values, scaling the features, encoding categorical variables, and splitting the data into training and testing sets.
In some other embodiments, upon generating the plurality of features, the data pre-processing module 226 may be configured to select a subset of relevant features from the plurality of features for reducing dimensionality and improving the model’s efficiency and generalization. Further, the plurality of features may include a plurality of cardholder-related features corresponding to each cardholder (e.g., the cardholder 104) and a plurality of merchant-related features corresponding to the merchant 110 along with the region/ hoarding zone-related features.
It may be noted that the plurality of features may be generated for training the two ML models (e.g., the pseudo-label generation model 218 and the hoarding prediction model 220). Therefore, the plurality of features is provided as input to the training module 228. Herein, it may be noted that the two ML models may include any number of ML models without limiting the scope of the invention.
In an embodiment, the training module 228 includes suitable logic and/or interfaces for training the pseudo-label generation model 218 and the hoarding prediction model 220 by performing a set of operations iteratively until the performance of each of the two ML models converges to predefined criteria for each of the two ML models. Herein, it may be noted that for training each of the pseudo-label generation model 218 and the hoarding prediction model 220, the same set of features or a separate set of features may be used.
In an embodiment, the set of features may include at least: the plurality of transactions performed by the cardholder such as the cardholder 104, the email information indicator i.e. if the cardholder 104 is associated with multiple email IDs, a cardholder email associated with the hoarding transactions in the past, number of payment cards associated with email IDs of the cardholder 104, number of hoarding transactions on other payment cards associated with the email ID of the cardholder 104. In an additional embodiment, the hoarding zone-related features may include a number of high-velocity transactions performed by payment cards in top hoarding zones based on latitude/longitude data, the number of payment transactions in the past few months in the hoarding zones, and the like. Additionally, other common features considered for determining the hoarding risk score may include the number of payment transactions in the past few months by the cardholder, the average amount spent by the cardholder, the number of high-value transactions (transaction bins), previous months’ chargeback amount associated with the cardholder, etc. The merchant-related features may include past transaction amounts for which the cardholders transacted with the merchant such as the merchant 110(1), a categorization of the merchant such as the merchant 110(1) as high risk, medium risk, or low risk, number of payment transactions with high-risk merchants, number of payment transactions with a merchant such as the merchant 110(1) with high hoarding transactions in past, number of payment transactions of the merchant with the specific cardholder such as the cardholder 104, and the like.
In another embodiment, the features may further include at least: merchant category code (MCC), MCC overall approval rate, MCC clearing percentage for auth, count of declines for different reason codes, top MCCs on which transactions are conducted, top MCCs with the hoarding risk, and the like.
Upon generating the plurality of features for each payment transaction performed by the cardholder 104 in the database 204 that can be accessed in the future whenever necessary for further processing. Further, in one embodiment, when the auth request is received from the merchant 110(1) with whom the cardholder 104 may have initiated the payment transaction, the plurality of features for the cardholder 104 may have to be accessed from the database 204 for further processing. Thus, the data pre-processing module 226 may be configured to access the plurality of features for the cardholder 104 from the database 204 based, at least in part, on the plurality of payment transactions performed by the cardholder 104 with the plurality of merchants.
In a non-limiting implementation, it should be noted that at least one feature of the plurality of features may indicate a hoarding transaction pattern associated with a set of labeled payment transactions of the plurality of payment transactions. For example, based on historical transaction data associated with a particular payment card (e.g., payment card 108(1)) used by the cardholder 104 to perform historical payment transactions, features are extracted. Further, the data pre-processing module 226 can determine a transaction pattern associated with the payment card 108(1) based on the extracted features. In one embodiment, the transaction pattern can be considered to be a hoarding transaction pattern, if the cardholder 104 makes a bulk transaction at a repeated interval of time of the same product. Therefore, the data pre-processing module 226 analyzes the transaction pattern associated with the payment card and determines whether the pattern resembles a hoarding behavior. If yes, then the data pre-processing module 226 may label the corresponding payment card and the payment transactions performed using the corresponding payment card as hoarding.
Further, the data pre-processing module 226 may determine other payment cards that may be associated with the same cardholder based on transaction attributes such as, but not limited to, an email ID or a shipping address associated with the cardholder 104. These payment cards and respective payment transactions may also be labeled as hoarding. Thus, it may be understood that the set of labeled payment transactions may correspond to a set of payment transactions of the plurality of payment transactions that are labeled to be hoarding since their behavior matches with the hoarding transaction pattern.
Furthermore, the plurality of features may also include at least one feature that may indicate the payment transactions that are unlabeled or that are difficult to label as a transaction pattern associated with such payment transactions does not have a standard or a predefined pattern. Such payment transactions may also have to be considered for efficiently determining a hoarding probability score associated with an ongoing payment transaction or future payment transactions. However, since they are not labeled it may be difficult to process such information by the server system 200. Thus, the pseudo-label generation module 230 is configured to generate a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and the plurality of payment transaction attributes. Further, the pseudo-label generation module 230 may be configured to generate the pseudo-label for each unlabeled payment transaction for generating a set of pseudo-labeled payment transactions. In one embodiment, the pseudo-label generation module 230 may generate the pseudo-label for each unlabeled payment transaction using pseudo-label generation model 218. As mentioned earlier, for the pseudo-label generation module 230 to be able to use the pseudo-label generation model 218, the pseudo-label generation module 230 may have to train and generate the pseudo-label generation model 218.
Moreover, in an embodiment, each of the two ML models may correspond to an extreme gradient boosting (XGBoost) model. Thus, in an embodiment, the training module 228 may be configured to generate the pseudo-label generation model 218 based, at least in part, on performing a first set of operations iteratively until the performance of the pseudo-label generation model 218 converges to first predefined criteria. In an embodiment, the pseudo-label generation model 218 may be trained to generate pseudo-labels for an unlabeled dataset (unlabeled payment transactions). The pseudo-label generation model 218 uses a concept of semi-supervised learning, where a model is trained on a combination of labeled and unlabeled data. In scenarios where labeled data is scarce or expensive to obtain, pseudo-labeling helps utilize unlabeled data to improve model performance. The pseudo-label generation model 218 involves training a classifier on the available labeled data, and then using the trained model to predict labels for the unlabeled data. These predicted labels are considered ’pseudo-labels’. The unlabeled data points that the model confidently predicts pseudo-labels for the unlabeled data that can be used as if they were true labels for further training. Herein, the first set of operations may be chosen based on the type of ML model being trained and the plurality of features may be chosen. The advantage of using the labeled and unlabeled transaction dataset enables the use of all the available datasets for the detection of a hoarder (otherwise, also referred to as an ‘unauthorized reseller’). Therefore, in an embodiment, the first set of operations may include initializing the pseudo-label generation model 218, generating classifiers with every iteration and optimized loss functions and other optimization parameters, assigning weights to each of the classifiers, and obtaining an ensemble of the classifiers. These operations may be performed iteratively till the performance of the pseudo-label generation model 218 converges to the first predefined criteria. In a non-limiting example, the first predefined criteria may include the saturation of the one or more optimization parameters. Herein, the one or more optimization parameters may be saturated after a plurality of iterations of the first set of operations is performed.
Upon obtaining the set of pseudo-labeled payment transactions, the hoarding risk score computation module 232 may be configured to generate a hoarding probability score associated with the ongoing payment transaction, based, at least in part, on the labeled payment transactions and the set of pseudo-labeled payment transactions. In one embodiment, the hoarding risk score computation module 232 may generate the hoarding probability score using the hoarding prediction model 220. For using the hoarding prediction model 220, the hoarding risk score computation module 232 may have to train and generate the hoarding prediction model 220.
Thus, in an embodiment, the training module 228 may be configured to generate the hoarding prediction model 220 based, at least in part, on performing a second set of operations iteratively till the performance of the hoarding prediction model 220 converges to a second predefined criteria. Herein, the second set of operations and the second predefined criteria are substantially similar to that of the pseudo-label generation model 218. In an embodiment, the hoarding prediction model 220 may be trained to predict a hoarding risk score associated with the cardholder 104 with respect to the payment transaction, and hence the second set of features may be chosen based on achieving this objective of the hoarding prediction model 220.
Further, upon training the two ML models in an embodiment, the pseudo-label generation module 230 includes suitable logic and/or interfaces for generating, via the set of ML models, the pseudo-labels for the unlabeled dataset (e.g., the unlabeled payment transactions) based, at least in part, on the plurality of features. Herein, the pseudo-labels may be used to predict labels for the unlabeled data present in the dataset. The generated pseudo-labels are used to retrain the hoarding prediction model 220 using both the pseudo-labels and true labels in order to output the hoarding risk score.
In an embodiment, it may be noted that for generating the pseudo-labels, the pseudo-label generation module 230 may be configured to determine, via the pseudo-label generation model 218, an email ID of the cardholder 104 associated with a plurality of payment cards based, at least in part, on the plurality of features. Herein, it may be noted that the plurality of features is related to all payment transactions for a certain period related to both the plurality of merchants 110 and the plurality of cardholders such as the cardholder 104.
In an embodiment, the pseudo-label generation module 230 may use the auth data to generate pseudo-labels for the unlabeled dataset. Cardholders 104 can be labeled as hoarders if a hoarding behavior is observed. The pseudo-label generation module 230 may generate true labels by identifying product details in a payment transaction message associated with the payment transaction using a string matching mechanism with the merchant details. In an example, the pseudo-label generation module 230 may label the transaction/associated cardholder as a hoarder if a high frequency of transactions is observed. In another example, if repeated transactions are observed in 15-minute intervals by the same cardholder such as the cardholder 104 purchasing the same product, at the same merchant in same quantity the cardholder 104 may be labeled as the hoarder. In another example, if the payment cards are associated with more than ten accepted transactions of the same amount with the same merchant, then the corresponding payment cards and the associated cardholder may be labeled as a hoarder.
Upon generating the pseudo-labels for each unlabeled payment transaction, the set of pseudo-labeled payment transactions and the set of labeled payment transactions are further forwarded to the hoarding prediction model 220 of the two ML models. The hoarding prediction model 220 is trained to detect a hoarding risk score associated with the ongoing payment transaction using the hoarding risk score computation module 232. The hoarding risk score computation module 232 may further be configured to generate the hoarding risk score based, at least in part, on the generated set of pseudo-labeled payment transactions, the set of labeled payment transactions from the dataset 222, the plurality of features and the data associated with the payment transaction.
In an example, if a cardholder such as the cardholder 104 is associated with an email ID, the hoarding risk score computation module 232 determines whether the email ID is associated with a plurality of payment cards such as C1, C2…Cn. Additionally, the hoarding risk score computation module 232 may detect that a particular card such as the card C2 associated with the cardholder 104, is related to the previous history of hoarding-based transactions/unauthorized reselling of the products. On such a detection, the hoarding risk score computation module 232 may mark other payment cards associated with the cardholder as suspicious, and the related cardholder is marked as a hoarder.
In another non-limiting example, the shipping address of the cardholder such as the cardholder 104 is identified. Using the dataset 222 which includes the historical transaction dataset, the hoarding risk score computation module 232 detects whether the shipping address of the cardholder is associated with a hoarding activity. In a non-limiting example, the hoarding risk score computation module 232 may detect that a hoarding activity of purchasing a particular product was done at the same shipping address as that of the cardholder 104. Therefore, in an embodiment, the hoarding risk score computation module 232 may provide the hoarding risk score for the current ongoing transaction as 995. Upon computing the hoarding risk score, the hoarding risk score computation module 232 may compare the hoarding risk score with the merchant-specific threshold risk score. The merchant-specific threshold risk score may be used differently for hoarding related payment cards and for the other payments. For example, the payment cards such as the top hoarding-related payment cards (based on hoarding probability and event rate) may be given a score between 900-999, while the other cards may be given a hoarding risk score of 0-899. Additionally, based on the comparison of the hoarding risk score with the merchant-specific threshold risk score, the payment transaction may be marked as high risk, medium risk, or low risk.
Therefore, the hoarding risk score computation module 232 may compare the difference between the predicted hoarding risk score and the threshold risk score associated with the particular merchant 110 such as the merchant 110(1). Upon comparison, if the predicted hoarding risk score is greater than the threshold risk score, then the hoarding risk score is high and is probably in the range of 900-999. Alternatively, if the predicted hoarding risk score is less than the threshold risk score then the hoarding risk score is comparatively low and is probably in the range of 0-899.
Upon generating the hoarding risk score, the hoarding risk score computation module 232 may determine the risk level involved with the cardholder 104 associated with the payment transaction using the plurality of features. In an embodiment, the hoarding risk score computation module 232 may transmit the hoarding risk score to the merchant or to the associated acquirer server to facilitate the merchant in taking further action. It is to be noted that, based on the high hoarding risk score, the merchant may decline the payment transaction, review the payment transaction, or approve the payment transaction. It is to be noted that, this process of detecting whether the cardholder is a hoarder or not can be done before the hoarding process that is, the payment cards with previous hoarding history with other merchants will be flagged before hoarding. Alternatively, the detection may be done during the hoarding process in which the new payment cards will have a cold start and the hoarding risk score will be calculated after some transactions have been done based on momentum/velocity thresholds. Further, for the detection of the hoarding risk associated with the cardholder of the hoarding cards (NOT flagged earlier) will be flagged after hoarding behavior is observed on one merchant.
FIG. 3 illustrates a block diagram representation 300 depicting a process flow of generating a hoarding probability score 324 (e.g., a reseller risk score), in accordance with an embodiment of the present disclosure. In an embodiment, the hoarding probability score 324 may be generated by the server system 200 via a hoarding prediction model 322. To explain the process of generating the hoarding probability score 324 consider an example of a cardholder 302 accessing a first merchant application (app) 306 via a cardholder’s mobile phone 304 for placing an order for a product ‘X’. It may be noted that when the cardholder 302 provides credit card details for booking the product ‘X’ on the first merchant app 306, a merchant (e.g., merchant 310) can verify whether the cardholder 302 is eligible for ordering the product ‘X’ before permitting to the cardholder 302 to proceed. To do so, a transaction request 308 along with the payment transaction attributes goes to the merchant 310 which has an account of the cardholder 302. The transaction request 308 may include the personal information of the cardholder 302 and transaction-related information of the ongoing transaction initiated by the cardholder 302. Herein, the personal information of the cardholder 302 includes 3DS 2.0 (3D Secure 2) data such as a cardholder name, a cardholder email ID, a cardholder phone number, a shipping address related to the cardholder, the browser details of the cardholder, etc. Further, the transaction-related information may include data, such as a card number, a transaction amount, a transaction date and time, a merchant ID related to the merchant with whom the cardholder is transacting. The payment transaction data or attributes may include, but is not limited to, transaction attributes, such as transaction amount, source of funds, such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources, pre-auth transactions, and other internal data to evaluate each transaction.
Suppose the merchant 310 is using a facility provided by the server system 200 to check whether the cardholder 302 is trying to hoard the products by making a bulk purchase of products on the merchant’s website and then might resell the products without proper authorization for the same. Therefore, the server system 200 receives the transaction request 308 via the data pre-processing module 312. Upon receiving the transaction request 308, the server system 200 accesses the cardholder 302 and merchant 310 related data from a database 314 via the data pre-processing module 312. As may be understood, the cardholder 302 and merchant 310 related data includes historical information related to a plurality of transactions performed by the cardholder 302 with a plurality of merchants in the past. Therefore, it may be noted that this data may help the server system 200 to understand the behavior of the cardholder 302 and the merchants with whom the cardholder interacted in the past.
It may be noted that to understand the behavior of the cardholder 302 (whether the behavior is of the hoarder or not) and the merchants (whether they have previously been at risk of bulk purchasing/hoarding and unauthorized reselling) in the past may mean that the server system 200 may learn a transaction pattern that the hoarders or unauthorized resellers may be following to decide a hoarding transaction pattern associated with the hoarders or unauthorized reseller.
For the server system 200 to learn the above-mentioned operations, the server system 200 may use a pseudo-label generation model 318. Therefore, the server system 200 may train and generate the pseudo-label generation model 318. Herein, a training module (e.g., the training module 228 of FIG. 2) may train the pseudo-label generation model 318 using the plurality of features (e.g., features 316). It may be noted that the plurality of features 318 may be generated from the historical transaction data by the server system 200 via the data pre-processing module 312. As mentioned above, the plurality of features 318 may include cardholder-related features, transaction-related features, and merchant-related features. The training of the pseudo-label generation model 318 and the hoarding prediction model 322 requires similar features associated with both for better performance of each of the ML models and to obtain more efficient results in comparison to conventional methods. Herein, it may be noted that the cardholder-related features may correspond to features related to the cardholders, transaction-related features may correspond to features related to the historical transactions and the merchant-related features may be features related to the merchants.
The plurality of features may be prepared from training the pseudo-label generation model 318 by performing one or more pre-processing operations such as handling missing values, scaling features, encoding the features, and the like. Herein, it may be noted that the one or more pre-processing operations may be performed by the server system 200 via the data pre-processing module 312. Herein, for training each of the pseudo-label generation model 318 and the hoarding prediction model 322, the plurality of features 316 may be used.
Further, in the current example, the server system 200 may train the pseudo-label generation model 318 and the hoarding prediction model 322 based, at least in part, on the generated features 316 via the training module. The training module may train the pseudo-label generation model 318 to generate pseudo-labels associated with the unlabeled dataset such as the set of unlabeled payment transactions. Similarly, based on the same set of features the training module may train the hoarding prediction model 322 to predict a hoarding probability score associated with the transaction initiated by the cardholder 302. It is to be noted that for training the pseudo-label generation model 318 a labeled dataset 328 and an unlabeled dataset 330 are accessed from the database 314. Further, the pseudo-label generation model 318 and the hoarding prediction model 322 are binary classification models. Examples of the pseudo-label generation model 318 and the hoarding prediction model 322 may be XGBoost (Extreme Gradient Boosting). The pseudo-label generation model 318 is trained on the labeled dataset using the features 316, the trained model is then used to generate pseudo-label predictions on the unlabeled dataset 330. The generated pseudo-labels using a pseudo-label generation module 320 along with the labeled dataset 328 are then fed into the hoarding prediction model 322 to generate the hoarding probability score 324. The architecture of the machine learning model used in the pseudo-label generation model and the hoarding prediction model is further explained in FIG. 4.
Upon training the two ML models, the server system 200 may use them for computing the hoarding probability score 324 via the hoarding prediction model 322. Herein, the hoarding probability score 324 may indicate a probability of the cardholder 302 being a hoarder/unauthorized reseller i.e., the probability of the cardholder 302 reselling the products brought in bulk from the merchant in an unauthorized manner.
Further, the intermediate steps of generating the hoarding probability score 324 include determining a plurality of payment cards that are associated with the cardholder such as the cardholder 104 based on the personal information of the user, such as the email ID and shipping address of the cardholder 104. Based on this data a payment card-based score is generated which is further used to determine the hoarding risk score. Further, a plurality of hoarding zones is determined, and the probability of the payment transaction being associated with the hoarding risk is also determined. It is noted that the payment card-based score, the plurality of hoarding zones, and the probability of the payment transaction being associated with the hoarding risk are used to determine the hoarding probability score associated with the payment transaction.
In an embodiment, if the frequency of bulk transactions is more than a threshold, the payment transaction may be labeled as a hoarding transaction. For example, if a bulk transaction order of the same amount is repeated every 15 minutes, the payment transaction may be labeled as a hoarding transaction. Also, the associated payment card will be labeled as a payment card linked to a hoarder. Also, the cardholder associated with the payment card used for a hoarding transaction is tracked for other payment cards using the 3DS 2.0 data such as the email ID of the cardholder. If a particular payment card of the cardholder is labeled as a payment card linked to a hoarder, all other payment cards associated with the same email ID will be marked as being associated with the hoarder. In yet another example, the shipping address from the 3DS 2.0 data may be used to track the hoarding behaviors. For example, all the payment cards associated with the same shipping address that previously had hoarding behavior will be marked as hoarders. Once it is determined that, whether the cardholder 302 is a hoarder or not, the merchant 310 may be notified about the same via a notification module 326, so that the merchant 310 can take necessary actions, such as blocking the ongoing payment transaction, requesting additional details from the cardholder 302 to inquiry for the hoarding behavior, to report the cardholder 302 for being a hoarder, etc.
FIG. 4 illustrates a schematic representation 400 of a process of training of the two ML models (e.g., the pseudo-label generation model 318 and the hoarding prediction model 322) for generating the hoarding probability score, in accordance with an embodiment of the present disclosure. Herein each of the pseudo-label generation model 318, and the hoarding prediction model 322 may be trained and generated separately and independently for separate purposes as mentioned earlier in the present disclosure, and then based on outputs obtained from each of the pseudo-label generation model 318 and the hoarding prediction model 322, the hoarding probability score may be generated.
Moreover, as may be understood, in an embodiment, each of the pseudo-label generation model 318 and the hoarding prediction model 322 may be a binary classification model such as a Gradient Boosting Machine (GBM) model or an extreme gradient boosting (XGBoost) model, training steps of each of the two ML models may be same along with the features provided to each of the two ML models 318 and 322.
The term “Gradient Boosting” refers to a popular boosting algorithm in machine learning used for classification and regression tasks. It may be noted that boosting is one kind of ensemble learning method that trains the model sequentially and each new model tries to correct the previous model. It combines several weak learners into strong learners. Similarly, as used herein, the term “extreme gradient boosting” refers to a type of boosting algorithm in machine learning that is similar to the GBM model, however, the difference is in model details, for example, the XGBoost model in comparison to the GBM model is more regularized model formalization to control a problem of over-fitting, which gives a better performance.
As may be understood, the XGBoost model is a scalable tree-boosting system that is capable of solving real-world problems with remarkable performance using minimal resources. Herein, the XGBoost model receives an input data 402. In an embodiment, the input data 402 may be similar to the transaction data accessed from the database along with the plurality of features. In an embodiment, the input data 402 may be split into training data and testing data, whereby the training data may be used while training the XGBoost model and the testing data may be used while testing whether the XGBoost model is functioning as per its purpose of training or not.
Further, the XGBoost model produces individual classifiers (e.g., classifiers 404(1), 404(2), … 404(N) where ‘N’ is a non-zero Natural number, hereinafter, interchangeably referred to as classifiers 404) sequentially, where a subset of the training data for each subsequent tree (e.g., the classifier 404(2)) is chosen based on the performance of the previous classifiers (e.g., the classifier 404(1)), as shown in FIG 4. More specifically, each classifier is trained on the examples that were incorrectly classified by the previous classifiers.
It may be noted that the XGBoost model uses Newton boosting, a second-order gradient boosting technique based on the gradient descent algorithm which aims to minimize the loss when adding new models or classifiers. Therefore, each new classifier corrects the errors made by the previous trees. This will finally produce ‘N’ classifiers, where ‘N’ depends on the number of predetermined iterations for the algorithm, which provide ‘N’ risk scores 406(1), 406(2) … 406(N), hereinafter, interchangeably referred to as risk scores 406.
Further, the final classification is made by combining the outputs (e.g., the risk scores 406) of all the classifiers (classifiers) with the chosen weighting and averaging method. In other words, it may be noted that an average of the risk scores 406 (see, 408) may be performed by the XGBoost model for obtaining a hoarding risk score 410 as shown in FIG. 4.
FIG. 5 illustrates a flow diagram representation 500 of a process flow of training the ML models (the pseudo-label generation model 318 and the hoarding prediction model 322), in accordance with an embodiment of the present disclosure. In a non-limiting example, the ML models may include the pseudo-label generation model 218 and the hoarding prediction model 220. Herein, in an embodiment, the pseudo-label generation model 318 and the hoarding prediction model 322 may be trained via the training module 228 by performing a set of operations iteratively till the performance of each of the ML models converges to predefined criteria. In a non-limiting example, each of the pseudo-label generation model 318 and the hoarding prediction model 322 may be an XGBoost model whose basic functionality is explained in the present disclosure with reference to FIG. 4.
In a specific embodiment, the set of operations may include model initialization 502, classifier generation 504, optimization parameters generation 506, new classifier generation 508, weights assignment 510, ensemble classifiers 512, optimize model parameters 514, and check whether the performance of the ML model (e.g. the pseudo-label generation model 318 and the hoarding prediction model 322) converged to the predefined criteria (see, 516). In case the ML model converges to the predefined criteria, the training of the ML model stops (see, 518), otherwise, the set of operations in the training of the ML model would be repeated as shown in FIG. 5.
As may be understood, the XGBoost model is a supervised learning model, the model may use the training data with the plurality of features say ‘xi’ that are independent variables to predict a target variable say ‘yi’ that may be labeled for classification task or numerical values for regression task.
In an embodiment, basic elements of supervised learning may include a mathematical model and parameters associated with the mathematical model and objective function which is a combination of a training loss and regularization. Examples of mathematical models include exponential decay, exponential growth, quadratic function, and linear function. In a non-limiting example, when a linear model may be considered, the prediction may be given by the following equation:
y ^_i=?_j¦? ?_j x_ij … Eqn. 1
Herein, the Eqn. 1 may correspond to a linear combination of weighted input features (xij) and ‘?_j’ may refer to a coefficient/parameter that is used as weights multiplied with the input features. Further, it may be noted that the task of training the model amounts to finding the best parameters ‘?’ that best fit the training data and labels. In order to train the model, the objective function may have to be defined to measure how well the model fits the training data.
A salient characteristic of the objective function is that it consists of two parts: training loss and regularization term and is represented by the following equation:
obj?(?)=L(?)+O(?) … Eqn. 2
Herein, ‘L’ is the loss function, and ‘?’ is the regularization term. In some embodiments, the loss function may include mean squared loss, logistic loss, or the like. The regularization term controls the complexity of the model, which helps avoid overfitting.
In another embodiment, other parameters may include hyperparameters such as, but not limited to, a number of boosting rounds, a learning rate, a maximum tree depth, and the like. In some embodiments, the regularization terms may be two in number. It is important to carefully tune these parameters for better model performance.
In an embodiment, the step of model initialization 502 may include initializing an ML model (e.g., the pseudo-label generation model 218, the hoarding prediction model 220) based, at least in part, on one or more model parameters and an initial prediction. In a non-limiting example, the one or more model parameters may include the parameters and the hyperparameters mentioned above. Herein, the initial prediction may include a simple prediction such as a mean of the target values for regression tasks, or the most frequent class for classification tasks.
In another embodiment, the step of classifier generation 504 may include a step of generating a set of classification and regression trees. In this step, based on the training data, a classifier may be generated. In other words, it may be noted that this step includes generating a classifier (as shown in FIG. 4) based, at least in part, on a set of features from the plurality of features.
Later, the step of optimization parameters generation 506 may be implemented. Herein, the ML model may compute one or more optimization parameters based at least on the performance of the classifier, using one or more optimization functions. In a non-limiting example, the one or more optimization parameters may include a loss function, a gradient (first derivative) of the loss function, a hessian (second derivative) of the loss function, and the like. Herein, it may be noted that each of the one or more parameters may be computed using their respective optimization functions. More specifically, it may be noted that the gradient indicates how much the predictions need to be updated to reduce the overall loss. Similarly, hessian is used to adjust the step size (learning rate) during the optimization process.
Further, in an embodiment, the step of new classifier generation 508 may include building a new classifier for reducing the one or more optimization parameters. Herein, it may be noted that the new classifier may reduce the one or more optimization parameters by capturing patterns and relationships that were not well-modeled by the previous trees.
In an embodiment, the step of weights assignment 510 may include assigning weights to the new classifier and the previously generated classifier based, at least in part, on the performance of the new classifier and the previously generated classifier in reducing the one or more optimization parameters. For example, classifiers that contribute more to the model’s predictive performance receive higher weights.
Later, in an embodiment, the step of ensemble classifiers 512 may be performed which includes generating an ensemble of a plurality of classifiers by adding predictions of the new classifier to predictions of the previously generated classifier. Lastly, the step of optimizing model parameters 514 may be performed which includes optimizing the one or more model parameters for the corresponding ML model.
Upon obtaining the ensemble of the classifiers and optimizing the one or more model parameters, the performance of the ML model is checked for its convergence to the predefined criteria. If the performance of the ML model converges to the predefined criteria, the training process stops (see, 518), otherwise, the process repeats, until the corresponding convergence is achieved.
In some embodiments, the predefined criteria for the convergence of the ML model may be dependent on one or more factors such as a number of iterations or trees, a minimum improvement in loss, validation set performance, and early stopping criteria. Herein, in an embodiment, the factor of the number of iterations or classifiers may refer to a criterion in which a maximum number of iterations is fixed for the training process and once the model reaches that number, the training process stops. In another embodiment, the factor of the minimum improvement in loss may refer to a criterion in which a minimum improvement in the loss function in consecutive iterations is observed and if the improvement falls below a predefined threshold the training process stops.
In yet another embodiment, the factor of validation set performance may refer to monitoring the performance of the model on a validation set at each iteration and if the performance of the model on the validation set does not improve or starts to degrade, then the training process stops. Further, in an embodiment, the factor of early stopping criteria may refer to a criterion that may be chosen to prevent overfitting. It involves dividing the training data into training and validation sets. The training process continues until the performance on the validation set stops improving, and then the model with the best performance on the validation set is selected as the final model.
Further, it may be noted that in an embodiment, the server system 200 may generate the pseudo-label generation model 218 via the training module 228. The training module 228 may perform a first set of operations to generate the pseudo-label generation model 218. Upon performing the first set of operations, the pseudo-label generation model 218 may get trained using the dataset 222 and learn to generate pseudo-labels for the unlabeled dataset in the transaction data. Herein, the pseudo-label generation model 218 may be based on the set of features.
Similarly, the hoarding prediction model 220 may get trained using the dataset 222 along with the pseudo-labels generated for each unlabeled payment transaction and learn to generate a hoarding probability score for the ongoing transaction initiated by the cardholder 104. Herein, the hoarding prediction model 220 may be based on the same set of features.
Moreover, it may be noted that the set of operations performed for training each of the pseudo-label generation model 218 and the hoarding prediction model 220 may be the same as described above with reference to the step of model initialization 502 to the step of checking the performance of the model (see, 516) with the difference being the input data on which the model generates the pseudo-labels and the hoarding probability score.
FIG. 6 illustrates a process flow diagram depicting a method 600 for generating a hoarding probability score, in accordance with an embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 600, and combinations of operations in the method 600 may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions. The plurality of operations is depicted in the process flow of the method 600. The process flow starts at operation 602.
At 602, the method 600 includes receiving, by a server system (e.g., the server system 200) an authorization request associated with a payment transaction initiated by a cardholder 104 with a merchant such as the merchant 110(1) via a payment card, the authorization request includes a plurality of payment transaction attributes (e.g., payment transaction attributes may include personal information of the cardholder 302 and transaction-related information associated with the transaction).
At 604, the method 600 includes accessing, by the server system 200, a plurality of features for the cardholder 104 from a database (e.g., database 204) associated with the server system 200 based, at least in part, on a plurality of payment transactions performed by the cardholder 104 with a plurality of merchants, wherein at least one feature of the plurality of features indicate a hoarding transaction pattern associated with a set of labeled payment transactions of the plurality of payment transactions.
At 606, the method 600 includes generating, by a pseudo-label generation model 124 associated with the server system 200, a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and the plurality of payment transaction attributes, for generating a set of pseudo-labeled payment transactions.
At 608, the method 600 includes generating, by a hoarding prediction model 126 associated with the server system 102, a hoarding probability score associated with the ongoing payment transaction based, at least in part, on the set of labeled payment transactions and the set of pseudo-labeled payment transactions. The hoarding probability score indicates a likelihood of the ongoing payment transaction being associated with the hoarding risk.
At 610, the method 600 includes facilitating, by a communication interface 210 associated with the server system 200, a transmission of the hoarding probability score to an acquirer server 114 associated with the merchant 110.
FIG. 7 illustrates a simplified block diagram of an acquirer server 700, in accordance with an embodiment of the present disclosure. The acquirer server 700 is an example of the acquirer servers 114 of FIG. 1. The acquirer server 700 is associated with an acquirer bank/acquirer, in which a merchant may have an account, which provides a payment card. The acquirer server 700 includes a processing module 702 operatively coupled to a storage module 704 and a communication module 706. The components of the acquirer server 700 provided herein may not be exhaustive and the acquirer server 700 may include more or fewer components than those depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 700 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
The storage module 704 is configured to store machine-executable instructions to be accessed by the processing module 702. Additionally, the storage module 704 stores information related to, the contact information of the merchant, bank account number, availability of funds in the account, payment card details, transaction details, and/or the like. Further, the storage module 704 is configured to store payment transactions and hoarding risk scores with the merchant such as the merchant 110(1).
In one embodiment, the acquirer server 700 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder 104, account identification information, and a payment card number) in a transaction database 708. The details of the cardholder 104 may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, etc.
The processing module 702 is configured to communicate with one or more remote devices such as a remote device 710 using the communication module 706 over a network such as the network 122 of FIG. 1. The examples of the remote device 710 include the server system 102, the payment server 118, the issuer servers 112, or other computing systems of the acquirer server 700, and the like. The communication module 706 is capable of facilitating such operative communication with the remote devices and cloud servers using Application Program Interface (API) calls. The communication module 706 is configured to receive a payment transaction request performed by the cardholder 104 via the network 122. The processing module 702 receives payment card information, a payment transaction amount, cardholder information, and merchant information from the remote device 710 (i.e., the payment server 118). The acquirer server 700 includes a user profile database 712 and the transaction database 708 for storing transaction data. The user profile database 712 may include information of the cardholder 104. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction.
FIG. 8 illustrates a simplified block diagram of an issuer server 800, in accordance with an embodiment of the present disclosure. The issuer server 800 is an example of the issuer servers 112 of FIG. 1. The issuer server 800 is associated with an issuer bank/issuer, in which an account holder (e.g., the cardholder 104) may have an account, which provides a payment card. The issuer server 800 includes a processing module 802 operatively coupled to a storage module 804 and a communication module 806. The components of the issuer server 800 provided herein may not be exhaustive and the issuer server 800 may include more or fewer components than those depicted in FIG. 8. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 800 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
The storage module 804 is configured to store machine-executable instructions to be accessed by the processing module 802. Additionally, the storage module 804 stores information related to, the contact information of the plurality of cardholders (e.g., the cardholder 104), a 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 804 is configured to store payment transactions and hoarding risk scores associated with the cardholder 104.
In one embodiment, the issuer server 800 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholders, account identification information, payment card number, etc.) in a database. The details of the cardholder 104 may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like.
The processing module 802 is configured to communicate with one or more remote devices such as a remote device 808 using the communication module 806 over a network such as the network 122 of FIG. 1. Examples of the remote device 808 include the server system 200, the payment server 118, the acquirer servers 114 or other computing systems of the issuer server 800. The communication module 806 is capable of facilitating such operative communication with the remote devices and cloud servers using Application Program Interface (API) calls. The communication module 806 is configured to receive a payment transaction request performed by an account holder (e.g., the cardholder 104) via the network 122. The processing module 802 receives payment card information, a payment transaction amount, customer (cardholder) information, and merchant information from the remote device 808 (e.g., the payment server 118). The issuer server 800 includes a transaction database 810 for storing transaction data. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, preauthorization transactions, transaction velocity features such as count and transaction amount sent in the past x days to a particular account holder, transaction location information, external data sources, and other internal data to evaluate each transaction. The issuer server 800 includes a user profile database 812 storing user profiles associated with the plurality of account holders.
The user profile data may include an account balance, a credit line, and details of the account holders, account identification information, payment card number, or the like. The details of the account holders (e.g., the cardholder 104) may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder 104.
FIG. 9 illustrates a simplified block diagram of a payment server 900, in accordance with an embodiment of the present disclosure. The payment server 900 is an example of the payment server 118 of FIG. 1. The payment server 900 and the server system 200 may use the payment network 116 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
The payment server 900 includes a processing module 902 configured to extract programming instructions from a memory 904 to provide various features of the present disclosure. The components of the payment server 900 provided herein may not be exhaustive and the payment server 900 may include more or fewer components than that depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
Via a communication module 906, the processing module 902 receives a request from a remote device 908, such as the issuer servers 112, the acquirer servers 114, or the server system 102. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 900 includes a database 910. The database 910 also includes transaction processing data such as issuer ID, country code, acquirer ID, and merchant identifier (MID), among others.
When the payment server 900 receives a payment transaction request from the acquirer servers 114 or a payment terminal (e.g., IoT device), the payment server 900 may route the payment transaction request to the issuer servers 112. The database 910 stores transaction identifiers for identifying transaction details such as transaction amount, IoT device details, acquirer account information, transaction records, merchant account information, and the like.
In one example embodiment, the acquirer servers 114 are configured to send an authorization request message to the payment server 900. The authorization request message includes, but is not limited to, the payment transaction request.
The processing module 902 further sends the payment transaction request to the issuer servers 112 for facilitating the payment transactions from the remote device 908. The processing module 902 is further configured to notify the remote device 908 of the transaction status in the form of an authorization response message via the communication module 906. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer servers 112. Alternatively, in one embodiment, the processing module 902 is configured to send an authorization response message for declining the payment transaction request, via the communication module 906, to the acquirer servers 114. In one embodiment, the processing module 902 executes similar operations performed by the server system 200, however, for the sake of brevity, these operations are not explained herein.
The disclosed method with reference to FIG. 5, or one or more operations of the server system 200 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during the implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such a suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software, and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
Particularly, the server system 200 and its various components may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or the 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 includes any type of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read-only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different from those which, are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the 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.
, C , Claims:
1. A computer-implemented method, comprising:
receiving, by a server system, an authorization request associated with a payment transaction initiated by a cardholder with a merchant via a payment card, the authorization request comprising a plurality of payment transaction attributes;
accessing, by the server system, a plurality of features for the cardholder from a database associated with the server system based, at least in part, on a plurality of payment transactions performed by the cardholder with a plurality of merchants, wherein at least one feature of the plurality of features indicates a hoarding transaction pattern associated with a set of labeled payment transactions of the plurality of payment transactions;
generating, by a pseudo-label generation model associated with the server system, a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and the plurality of payment transaction attributes, for generating a set of pseudo-labeled payment transactions;
generating, by a hoarding prediction model associated with the server system, a hoarding probability score associated with the ongoing payment transaction based, at least in part, on the set of labeled payment transactions and the set of pseudo-labeled payment transactions, the hoarding probability score indicating a likelihood of the ongoing payment transaction being associated with a hoarding risk; and
facilitating, by a communication interface associated with the server system, a transmission of the hoarding probability score to an acquirer server associated with the merchant.

2. The computer-implemented method as claimed in claim 1, wherein the pseudo-label generation model and the hoarding prediction model comprise a binary classification model.

3. The computer-implemented method as claimed in claim 1, further comprising:
accessing, by a server system, a cardholder-related dataset associated with the cardholder from the database based, at least in part, on the plurality of payment transaction attributes, the cardholder-related dataset comprising historical information corresponding to the plurality of payment transactions performed by the cardholder with the plurality of merchants;
extracting, by the server system, the plurality of features from the cardholder-related dataset associated with each payment transaction; and
storing, by the server system, the plurality of features for each payment transaction performed by the cardholder in the database.

4. The computer-implemented method as claimed in claim 1, wherein generating the hoarding probability score comprises:
determining, by the server system via the hoarding prediction model, a plurality of payment cards associated with the cardholder based, at least in part, on a first set of attributes from the plurality of payment transaction attributes;
generating, by the server system, a card-based score based, at least in part, on the plurality of payment cards associated with the cardholder;
determining, by the server system, a plurality of hoarding zones based, at least in part, on a plurality of first transactions performed by a plurality of cardholders with the plurality of merchants;
generating, by the server system, a hoarding zone-based score based, at least in part, on the plurality of hoarding zones and the plurality of payment transaction attributes;
determining, by the server system, a probability of the payment transaction being associated with the hoarding risk based, at least in part, on the plurality of features; and
determining, by the server system, the hoarding probability score for the cardholder based, at least in part, on the card-based score, the hoarding zone-based score, and the probability of the payment transaction being associated with the hoarding risk.

5. The computer-implemented method as claimed in claim 4, wherein the first set of attributes comprises at least one of a cardholder email identifier (ID) and a cardholder shipping address.

6. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, the pseudo-label generation model based, at least in part, on performing a first set of operations iteratively till the performance of the pseudo-label generation model converges to first predefined criteria, the first set of operations comprising:
initializing the pseudo-label generation model based, at least in part, on one or more pseudo-label generation model parameters and an initial prediction;
generating, via the pseudo-label generation model, a classifier for generating predictions based, at least in part on the plurality of features;
computing, via the pseudo-label generation model, one or more optimization parameters based at least on a performance of the classifier, using one or more optimization functions;
building, via the pseudo-label generation model, a new classifier for reducing the one or more optimization parameters;
assigning, via the pseudo-label generation model, weights to the new classifier and the previously generated classifier based, at least in part, on a performance of the new classifier and the previously generated classifier in reducing the one or more optimization parameters; and
generating, via the pseudo-label generation model, an ensemble of a plurality of classifiers by adding predictions of the new classifier to predictions of the previously generated classifier and optimizing the one or more first model parameters.

7. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, the hoarding prediction model based, at least in part, on performing a second set of operations iteratively till the performance of the hoarding prediction model converges to second predefined criteria, the second set of operations comprising:
initializing the hoarding prediction model based, at least in part, on one or more hoarding prediction model parameters and an initial prediction;
generating, via the hoarding prediction model, a classifier for generating predictions based, at least in part on the plurality of features;
computing, via the hoarding prediction model, one or more optimization parameters based at least on a performance of the classifier, using one or more optimization functions;
building, via the hoarding prediction model, a new classifier for reducing the one or more optimization parameters;
assigning, via the hoarding prediction model, weights to the new classifier and the previously generated classifier based, at least in part, on a performance of the new classifier and the previously generated classifier in reducing the one or more optimization parameters; and
generating, via the hoarding prediction model, an ensemble of a plurality of classifiers by adding predictions of the new classifier to predictions of the previously generated classifier and optimizing the one or more first model parameters.

8. The computer-implemented method as claimed in claim 1, wherein the plurality of features comprises at least one of: an amount of transactions, a count of transactions in a plurality of hoarding zones, a count of high-velocity transactions in the plurality of hoarding zones, a frequency of transactions in the plurality of hoarding zones, a count of transactions in past few months, a count of transactions with merchant with high hoarding transaction in past, an email associated with hoarding, a count of cards associated with emails.

9. The computer-implemented method as claimed in claim 1, further comprising:
facilitating, via the communication interface associated with the server system, a transmission of a transaction decline message to the cardholder from the merchant if the hoarding probability score is at least equal to a predefined threshold.

10. The computer-implemented method as claimed in claim 1, further comprising:
facilitating, via the communication interface associated with the server system, a transmission of a transaction-approved message to the cardholder from the merchant if the hoarding probability score is less than a predefined threshold.

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

12. 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 cause the server system to at least:
receive an authorization request associated with a payment transaction initiated by a cardholder with a merchant via a payment card, the authorization request comprising a plurality of payment transaction attributes;
access a plurality of features for the cardholder from a database associated with the server system based, at least in part, on a plurality of transactions performed by the cardholder with a plurality of merchants, wherein at least one feature of the plurality of features indicate a hoarding transaction pattern associated with a set of labeled payment transactions of the plurality of transactions;
generate, by a pseudo-label generation model associated with the server system, a pseudo-label for each unlabeled payment transaction from the plurality of payment transactions based, at least in part, on the plurality of features and the plurality of payment transaction attributes, for generating a set of pseudo-labeled payment transactions;
generate, by a hoarding prediction model associated with the server system, a hoarding probability score associated with the ongoing payment transaction based, at least in part, on the set of labeled payment transactions and the set of pseudo-labeled payment transactions, the hoarding probability score indicating a likelihood of the ongoing payment transaction being associated with a hoarding risk; and
facilitate, by a communication interface associated with the server system, a transmission of the hoarding probability score to an acquirer server associated with the merchant.

13. The server system as claimed in claim 12, wherein the pseudo-label generation model and the hoarding prediction model comprises a binary classification model.

14. The server system as claimed in claim 12, wherein to generate the hoarding probability score the server system is further caused, at least in part, to:
determine, via the hoarding prediction model, the plurality of payment cards associated with the cardholder based, at least in part, on a first set of attributes from the plurality of payment transaction attributes;
generate a card-based score based, at least in part, on the plurality of payment cards associated with the cardholder;
determine a plurality of hoarding zones based, at least in part, on a plurality of first transactions performed by a plurality of cardholders with the plurality of merchants;
generate a hoarding zone-based score based, at least in part, on the plurality of hoarding zones and the plurality of payment transaction attributes;
determine a probability of the payment transaction being associated with the hoarding risk-based, at least in part, on the plurality of features; and
determine the hoarding probability score for the cardholder based, at least in part, on the card-based score, the hoarding zone-based score, and the probability of the payment transaction being associated with the hoarding risk.

15. The server system as claimed in claim 14, wherein the first set of attributes comprises at least one of a cardholder email identifier (ID) and a cardholder shipping address.

16. The server system as claimed in claim 12, wherein the server system is further caused to generate the pseudo-label generation model based, at least in part, on performing a first set of operations iteratively till the performance of the pseudo-label generation model converges to first predefined criteria, the first set of operations comprising:
initializing the pseudo-label generation model based, at least in part, on one or more pseudo-label generation model parameters and an initial prediction;
generating, via the pseudo-label generation model, a classifier for generating predictions based, at least in part on the plurality of features;
computing, via the pseudo-label generation model, one or more optimization parameters based at least on a performance of the classifier, using one or more optimization functions;
building, via the pseudo-label generation model, a new classifier for reducing the one or more optimization parameters;
assigning, via the pseudo-label generation model, weights to the new classifier and the previously generated classifier based, at least in part, on a performance of the new classifier and the previously generated classifier in reducing the one or more optimization parameters; and
generating, via the pseudo-label generation model, an ensemble of a plurality of classifiers by adding predictions of the new classifier to predictions of the previously generated classifier and optimizing the one or more first model parameters.

17. The server system as claimed in claim 12, wherein the server system is further caused to generate the hoarding prediction model based, at least in part, on performing a second set of operations iteratively till the performance of the hoarding prediction model converges to second predefined criteria, the second set of operations comprising:
initializing the hoarding prediction model based, at least in part, on one or more hoarding prediction model parameters and an initial prediction;
generating, via the hoarding prediction model, a classifier for generating predictions based, at least in part on the plurality of features;
computing, via the hoarding prediction model, one or more optimization parameters based at least on a performance of the classifier, using one or more optimization functions;
building, via the hoarding prediction model, a new classifier for reducing the one or more optimization parameters;
assigning, via the hoarding prediction model, weights to the new classifier and the previously generated classifier based, at least in part, on a performance of the new classifier and the previously generated classifier in reducing the one or more optimization parameters; and
generating, via the hoarding prediction model, an ensemble of a plurality of classifiers by adding predictions of the new classifier to predictions of the previously generated classifier and optimizing the one or more first model parameters.

18. The server system as claimed in claim 12, wherein the plurality of features comprises at least one of: an amount of transactions, a count of transactions in a plurality of hoarding zones, a count of high-velocity transactions in the plurality of hoarding zones, a frequency of transactions in the plurality of hoarding zones, a count of transactions in past few months, a count of transactions with merchant with high hoarding transaction in past, an email associated with hoarding, a count of cards associated with emails.

19. The server system as claimed in claim 12, wherein the server system is further caused at least in part, to facilitate a transmission of a transaction decline message from the merchant to the cardholder if the hoarding probability score is at least equal to a predefined threshold.

20. The server system as claimed in claim 12, wherein the server system is further caused at least in part, to facilitate a transmission of a transaction-approved message from the merchant to the cardholder if the hoarding probability score is less than a predefined threshold.