Description: The present disclosure relates to artificial intelligence-based processing systems within the financial domain, particularly focusing on electronic methods and complex processing systems for detecting suspicious merchants involved in preauthorization transactions.
BACKGROUND
Preauthorization (also termed as ‘authorization hold’, ‘card authorization’, or ‘pre-auth’) refers to a service that is offered by payment card providers (e.g., debit card and/or credit card providers) where the card issuing entities (e.g., an issuer bank) put a temporary hold on a predefined amount requested by a merchant providing a service to a cardholder, for a future payment transaction. This hold reduces the balance of cardholder’s available funds on a temporary basis until the transaction is processed by the merchant. Herein, the merchant can be considered to have processed the transaction, when the transaction is successfully completed, aborted, or if the hold period expired. Preauthorization is commonly used in application areas such as health care, hotel bookings, rental cars, petrol/gas stations, activity providers, etc. Preauthorization benefits, among other advantages, in mitigating fraud by cardholders and consequent chargebacks, avoiding merchant discount rate fees, reducing transaction costs, obviating refund fees, minimizing merchant-caused refunds, offering a payment guarantee, ensuring that cardholders pay for their services, and improving cardholders satisfaction.
Notwithstanding the benefits of preauthorization, there exists a possibility for merchants to exploit cardholders through preauthorization. For example, merchants might pre-authorize an amount higher than the actual transaction value to hold more funds from the cardholder’s account temporarily. Consequently, the cardholder may have reduced available funds for other transactions or purchases. Moreover, in some other examples, merchants might unnecessarily extend the hold duration of the pre-authorization, leading to an extended period for which the cardholder’s funds are reserved, even if the transaction is not completed.
In certain cases, merchants might preauthorize transactions without obtaining explicit consent of the cardholders or by providing misleading information. Additionally, frequent instances of preauthorization of small amounts can create inconvenience for cardholders and result in a significant cumulative hold on their funds. Moreover, cardholders face a lot of confusion and surprise charges when merchants fail to provide clear and transparent information about the preauthorization process. Therefore, despite the advantages of preauthorization for merchants and cardholders, these exploitative practices followed by some merchants can erode the trust of cardholders. As a consequence, the cardholders may opt to stop using preauthorization as a payment method when purchasing goods or services from merchants.
Thus, there exists a need for technical solutions that can effectively detect suspicious merchants engaged in preauthorization transactions. Such technical solutions will effectively prevent any manipulation of consumers by unscrupulous merchants misusing the preauthorization facility for personal gains.
SUMMARY
Various embodiments of the present disclosure provide methods and systems for detecting suspicious merchants involved in preauthorization 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 a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount. The payment transaction is to be conducted by a cardholder to a merchant. Upon receiving the pre-auth request, the method further includes accessing pre-auth transaction data corresponding to the merchant from a database associated with the server system. Herein, the pre-auth transaction data may include historical information related to a plurality of pre-auth transactions performed by the merchant with a plurality of cardholders. The method further includes generating a plurality of features based, at least in part, on the pre-auth transaction data. 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 set of Machine Learning (ML) models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features. Herein, the pre-auth risk score indicates a probability of the merchant being suspicious. Furthermore, the method includes flagging an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score.
In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to receive a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount. Herein, the payment transaction is to be conducted by a cardholder to a merchant. Upon receiving the pre-auth request, the server system is caused to access pre-auth transaction data corresponding to the merchant from a database associated with the server system. Herein, the pre-auth transaction data includes historical information related to a plurality of pre-auth transactions performed by the merchant with a plurality of cardholders. The server system is further caused to generate a plurality of features based, at least in part, on the pre-auth transaction data. The plurality features include 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 server system is caused to generate, via a set of Machine Learning (ML) models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features. Herein, the pre-auth risk score indicates a probability of the merchant being suspicious. Furthermore, the server system is caused to flag an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score.
In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount. Herein, the payment transaction is to be conducted by a cardholder to a merchant. Upon receiving the pre-auth request, the method further includes accessing pre-auth transaction data corresponding to the merchant from a database associated with the server system. Herein, the pre-auth transaction data may include historical information related to a plurality of pre-auth transactions performed by the merchant with a plurality of cardholders. The method further includes generating a plurality of features based, at least in part, on the pre-auth transaction data. 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 set of Machine Learning (ML) models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features. Herein, the pre-auth risk score indicates a probability of the merchant being suspicious. Furthermore, the method includes flagging an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score.

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 a preauthorization (pre-auth) risk score, in accordance with an embodiment of the present disclosure;
FIG. 4A illustrates a schematic representation of a process of training a set of machine learning (ML) models for generating the pre-auth risk score, in accordance with an embodiment of the present disclosure;
FIG. 4B illustrates a flow diagram of a process of training the set of ML models, in accordance with an embodiment of the present disclosure;
FIG. 5 illustrates a flow diagram depicting a method for generating a pre-auth risk score, in accordance with an embodiment of the present disclosure;
FIG. 6 illustrates a flow diagram depicting a method for detecting suspicious merchants involved in pre-auth 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”, “consumer”, 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 “aggregate merchant” may have been used throughout the description and may refer to a merchant having an aggregate merchant account which refers to a merchant account aggregating several new and small businesses into one account. Herein, it may be noted that rather than assigning each merchant with their own unique Identity (ID), the payment aggregator has its own merchant ID and account with an acquiring bank and combines several businesses under this ID. Thus, in this case, the payment aggregator may be referred to as an aggregate merchant.
The term “suspicious merchant” used throughout the description, unless the context suggests otherwise, refers to a merchant or an aggregate merchant that is involved in some suspicious activities. For instance, in a scenario of preauthorization of a payment transaction, a merchant that more frequently requests for preauthorization of a larger amount from the consumers for a particular service in comparison to its actual cost can be considered to be suspicious of having intentions to hold funds of the consumers temporarily for several illicit reasons. Other instances may include merchants that unnecessarily extend the duration of preauthorization hold, merchants that preauthorize transactions without the consent of the consumer, merchants frequently preauthorizing small amounts, merchants being unclear about their terms and conditions causing confusion and additional charges to the consumers, and the like may be considered as suspicious merchants. Herein, it may be noted that the merchants utilizing the preauthorization facility for personal benefits without causing any inconvenience to the consumers is permissible, however, causing any kind of inconvenience to the consumers makes such merchants suspicious.
The terms “preauthorization”, “authorization hold”, “card authorization”, and “pre-auth” are used interchangeably throughout the description and refer to a service offered by payment card providers (e.g., debit card and/or credit card providers and/or issuers) whereby the card providers put a temporary hold on some percentage of the funds of a cardholder in return to a service from a merchant, for a future payment transaction during an occasion. Herein, the merchant clears the transaction or the transaction is settled when either the transaction is completed or aborted, or because the hold got expired. Examples of the occasions when such pre-auth transactions may be applicable may include health care, hotel bookings, rental cars, petrol/gas stations, activity providers, etc.
The term “pre-auth amount” used throughout the description, unless the context suggests otherwise, refers to a predefined amount that is requested for preauthorization during a purchase by a cardholder, to make sure that the cardholder has sufficient funds in their account to receive a particular service from the merchant. The payment of this preauthorized amount or even less or more than the pre-auth amount will be made by the cardholder when the cardholder is checking out based on the actual expenditure of the cardholder while using the particular service provided by the merchant.
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. In some instances, while swiping the payment card at the merchant’s end, the merchant can raise a preauthorization request to check the eligibility of the merchant to use the service that the cardholder is willing to receive from the merchant. In this case, the payment will not be made at the beginning of receiving the service, instead, it will be made upon completion of the service or at the time of checking out. Herein, the payment may or may not be the same as the amount requested in the preauthorization request.
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, payment at a terminal (e.g., point of sale (POS) terminal, ATM, self-service kiosks, and the like. In the case of preauthorization, such a transaction may not happen before receiving the service, but instead at the time of the completion of receiving the service.
OVERVIEW
Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for detecting suspicious merchants involved in preauthorization (pre-auth) transactions. In an embodiment, the present disclosure describes a server system for detecting the suspicious merchants involved in the pre-auth transactions. 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 a pre-auth request corresponding to a payment transaction for a pre-auth amount. Herein, the payment transaction is to be conducted by a cardholder to a merchant. Upon receiving the pre-auth request, the server system is caused to access pre-auth transaction data corresponding to the merchant from a database associated with the server system. The pre-auth transaction data includes historical information related to a plurality of pre-auth transactions performed by the merchant with a plurality of cardholders. The server system is further caused to generate a plurality of features based, at least in part, on the pre-auth transaction data. 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 server system is caused to generate, via a set of Machine Learning (ML) models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features. The pre-auth risk score indicates a probability of the merchant being suspicious. In an embodiment, the set of ML models may include a first ML model, a second ML model, and a third ML model. In at least one embodiment, the first ML model, the second ML model, and the third ML model may correspond to a Gradient Boosting Machine (GBM) model. It may be noted that for generating the pre-auth risk score, the server system may be configured to determine, via the first ML model of the set of ML models, a predicted percentage of the pre-auth amount that is most likely expected to be cleared by the cardholder while conducting the payment transaction based, at least in part, on a first set of features from the plurality of features. The server system may further be configured to generate an amount-based score based, at least in part, on the pre-auth amount, the predicted percentage of the pre-auth amount, and a threshold pre-auth percentage value.
The server system is further configured to determine, via the second ML model of the set of ML models, a predicted clearance period within which the cardholder is most likely expected to clear the payment transaction based, at least in part, on a second set of features from the plurality of features. Furthermore, the server system is configured to generate a period-based score based, at least in part, on a clearance period taken by the cardholder to clear the predicted percentage of the pre-auth amount, the predicted clearance period, and a threshold tolerance period.
Furthermore, the server system is configured to determine, via a third ML model of the set of ML models, a probability of the payment transaction being suspicious based, at least in part, on a third set of features from the plurality of features. The server system is further configured to generate the pre-auth risk score based, at least in part, on the amount-based score, the period-based score, and the probability of the payment transaction being suspicious.
In an embodiment, the first set of features may include at least one of: an approval rate, an amount of transactions, a count of transactions, an amount approved, a count approved, an average approval amount, a count of pre-auth transactions, an amount of pre-auth transactions, a count of approved pre-auth transactions, an amount of approved pre-auth transactions, an approval rate pre-auth, an average clearing percentage for pre-auth, and the like, corresponding to the cardholders and merchants.
Additionally or alternatively, the first set of features may further include at least one of: merchant category code (MCC), MCC overall approval rate, MCC overall pre-auth approval rate, MCC clearing percentage for pre-auth, count of declines for different reason codes, top MCCs on which transactions are conducted, and the like. Additionally or alternatively, the first set of features may further include an aggregate merchant approval rate, an aggregate merchant count transaction, an aggregate merchant amount transaction, an aggregate merchant count transaction pre-auth, an aggregate merchant amount transaction pre-auth, an aggregate merchant approval rate pre-auth, an aggregate merchant percentage of cleared amount pre-auth, and the like corresponding to a plurality of aggregate merchants.
Further, the second set of features, without limitation, includes one or more combinations of an average time to clear transactions, an average time to clear transactions pre-auth, and the like corresponding to the cardholders and merchants. The third set of features may include, among others, a fraud count, a fraud amount, a fraud count pre-auth, a fraud amount pre-auth, a fraud rate overall, a fraud rate pre-auth, and the like corresponding to the cardholders and merchants.
In some embodiments, for the server system to be able to use the set of ML models for generating the pre-auth risk score, the server system may have to generate the set of ML models. Therefore, in an embodiment, the server system may further be configured to generate the set of ML models. More specifically, in an embodiment, the server system may be configured to generate the first ML model based, at least in part, on performing a first set of operations iteratively till the performance of the first ML model converges to first predefined criteria. Herein, the first set of operations may include: (1) initializing the first ML model based, at least in part, on one or more first model parameters and an initial prediction, (2) generating, via the first ML model, a decision tree for generating predictions based, at least in part on, the first set of features of the plurality of features, (3) computing, via the first ML model, one or more optimization parameters based at least on a performance of the decision tree, using one or more optimization functions, (4) building, via the first ML model, a new decision tree for reducing the one or more optimization parameters, (5) assigning, via the first ML model, weights to the new decision tree and the previously generated decision tree based, at least in part, on a performance of the new decision tree and the previously generated decision tree in reducing the one or more optimization parameters, and (6) generating, via the first ML model, an ensemble of a plurality of decision trees by adding predictions of the new decision tree to predictions of the previously generated decision tree and optimizing the one or more first model parameters.
Further, in some embodiments, the server system may be configured to generate the second ML model based, at least in part, on performing a second set of operations iteratively till the performance of the second ML model converges to second predefined criteria. Herein, the second set of operations may include: (1) initializing the second ML model based, at least in part, on one or more second model parameters and an initial prediction, (2) generating, via the second ML model, a decision tree for generating predictions based, at least in part on the second set of features of the plurality of features, (3) computing, via the second ML model, one or more optimization parameters based at least on a performance of the decision tree, using one or more optimization functions, (4) building, via the second ML model, a new decision tree for reducing the one or more optimization parameters, (5) assigning, via the second ML model, weights to the new decision tree and the previously generated decision tree based, at least in part, on a performance of the new decision tree and the previously generated decision tree in reducing the one or more optimization parameters, (6) generating, via the second ML model, an ensemble of a plurality of decision trees by adding predictions of the new decision tree to predictions of the previously generated decision tree and optimizing the one or more second model parameters.
Furthermore, in some embodiments, the server system may be configured to generate the third ML model based, at least in part, on performing a third set of operations iteratively till the performance of the third ML model converges to third predefined criteria. Herein, the third set of operations may include: (1) initializing the third ML model based, at least in part, on one or more third model parameters and an initial prediction, (2) generating, via the third ML model, a decision tree for generating predictions based, at least in part on the third set of features of the plurality of features, (3) computing, via the third ML model, one or more optimization parameters based at least on a performance of the decision tree, using one or more optimization functions, (4) building, via the third ML model, a new decision tree for reducing the one or more optimization parameters, (5) assigning, via the third ML model, weights to the new decision tree and the previously generated decision tree based, at least in part, on a performance of the new decision tree and the previously generated decision tree in reducing the one or more optimization parameters, and (6) generating, via the third ML model, an ensemble of a plurality of decision trees by adding predictions of the new decision tree to predictions of the previously generated decision tree and optimizing the one or more third model parameters. Finally, the server system may be configured to flag an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score.
Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure is intended to facilitate issuers with ability to identify suspicious merchants and/or suspicious payment transactions associated with preauthorization (pre-auth) that seek to misuse the pre-auth facility. This effectively prevents the inconvenience to consumers that might have otherwise been caused due to the hold of a larger percentage of funds of the consumers and/or for prolonged hold periods. The technical solutions provided in this disclosure employ advanced data analytics and AI-based techniques to forecast the expected percentage of pre-auth amounts that will be safely cleared by cardholders. Such intelligent forecasting, coupled with the determination of optimal clearance periods within which the cardholder would be expected to settle the pre-auth transaction helps issuers to optimize treasury operations, obtain decision-making intelligence, account management intelligence, and facilitate quick payment service transactions. In addition, the system proposed in the present disclosure also facilitates detecting a propensity for the cardholder to suffer from Non-sufficient Funds (NSF) which is a significant technical benefit as it ensures a reliable payment ecosystem. Overall, the technical benefits of the disclosed system encompass a more secure, efficient, and customer-friendly preauthorization process within the financial domain that is achieved by intelligent AI-based techniques, advanced fraud detection capabilities, enhanced risk management, 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, forecasting a percentage of a preauthorization (pre-auth) amount that would be expected from a cardholder at the time of clearing a payment transaction with a merchant, forecasting a period within which the cardholder would be expected to clear the payment transaction corresponding to the pre-auth amount, determining a probability that the payment transaction is suspicious, detecting suspicious merchants involved in pre-auth transactions, and the like. It is noted that the term ‘pre-auth transaction’ as used herein refers to payment transactions that are conducted between a cardholder and a merchant based on a pre-auth request.
The environment 100 generally includes a plurality of entities such as a server system 102, a plurality of cardholders 104(1), 104(2), … 104(N), where ‘N’ is a non-zero natural number (collectively referred to as a ‘plurality of cardholders 104’ or ‘cardholders 104’ or singularly as ‘cardholder 104’), a plurality of merchants 106(1), 106(2), … 106(N) where ‘N’ is a non-zero natural number (collectively referred to as a ‘plurality of merchants 106’ or ‘merchants 106’), a plurality of issuer servers 108(1), 108(2), … 108(N), where ‘N’ is a non-zero natural number (collectively referred to as a ‘plurality of issuer servers 108’ or ‘issuer servers 108’), a plurality of acquirer servers 110(1), 110(2), … 110(N), where ‘N’ is a non-zero natural number (collectively referred to as a ‘plurality of acquirer servers 110’ or ‘acquirer servers 110’), a payment network 112 including a payment server 114, and a database 116 each coupled to, and in communication with (and/or with access to) a network 118. The network 118 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 118 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 118 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 cardholders 104 use one or more payment cards to make payment transactions. As may be understood, the cardholder (e.g., the cardholder 104(1)) may be any individual, representative of a corporate entity, a non-profit organization, or any other person that is presenting payment account details during an electronic payment transaction. The cardholder (e.g., the cardholder 104(1)) may have a payment account issued by an issuing bank (not shown in figures) associated with the issuer server 108 and may be provided with a payment card with financial or other account information encoded onto the payment card such that the cardholder (i.e., the cardholder 104(1)) may use the payment card to initiate and complete a payment transaction using a bank account at the issuing bank.
In another embodiment, the cardholders 104 may use their corresponding electronic devices (not shown in figures) 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 106 may include retail shops, restaurants, supermarkets or establishments, government and/or private agencies, or any such places equipped with POS terminals, where cardholders visit for performing the financial transaction in exchange for any goods and/or services or any financial transactions.
In one scenario, the cardholders 104 may use their corresponding payment accounts to conduct payment transactions with the merchants 106. Moreover, it may be noted that each of the cardholders 104 may use their corresponding payment cards differently or make the payment transaction using different means of payment. For instance, the cardholder 104(1) may enter payment account details on an electronic device (not shown) associated with the cardholder 104(1) to perform an online payment transaction. In another example, the cardholder 104(2) may utilize the payment card 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(3) may enter details of the payment card to transfer funds in the form of fiat currency on an e-commerce platform to buy goods. In another instance, each cardholder of the plurality of cardholders 104 (e.g., the cardholder 104(1)) may transact at any merchant from the plurality of merchants 106 (e.g., the merchant 106(1)).
In one embodiment, the cardholders 104 are associated with the issuer servers 108. In one embodiment, the issuer servers 108 are associated with financial institutions normally called an “issuer bank”, “issuing bank” or simply “issuer”, in which a cardholder (e.g., the cardholder 104(1)) 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(1)).
In an embodiment, the merchants 106 are generally associated with the acquirer servers 110. In one embodiment, the acquirer servers 110 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(1) uses their payment card for making payment at a merchant (e.g., the merchant 106(1)), a pre-auth request may be generated for checking whether the cardholder 104(1) has sufficient funds in their bank account for receiving a particular service from the merchant 106(1). In such a scenario, the cardholder 104(1) does not have to make the payment in the beginning as the actual charges for receiving such a service may not be known at that time. Herein, instead, an estimated amount for the corresponding service is held by the issuer bank of the cardholder 104(1) from the funds of the cardholder 104(1) temporarily, until the time of checkout of the cardholder 104(1). The amount that is held is neither accessible to the cardholder 104(1) nor transmitted to the merchant 106(1) until the time of checkout of the cardholder 104(1). Further, while checking out, the actual amount that the cardholder 104(1) is supposed to clear is calculated and that amount from the pre-auth amount is deducted from the account of the cardholder 104(1) and transmitted to the account of the merchant 106(1) and the remaining amount from the pre-auth amount is released and made available for the cardholder 104(1) to use. In some scenarios, the amount that is actually charged to the cardholder 104(1) may be the same as the pre-auth amount. In some other scenarios, the amount that is actually charged may be much less than the pre-auth amount, for instance, it could be less than 50 percent (%) of the pre-auth amount. In such scenarios, it may be understood that a major portion of the funds of the cardholder 104(1) is unnecessarily held because of the pre-auth request of such a huge amount. Herein, the merchant 106(1) may or may not have illicit intensions of raising such a pre-auth request. Irrespective of the merchant’s intention, the cardholder 104(1) would be facing the inconvenience because of the hold of a huge portion of their funds preventing them from using that amount for their other expenditures. Furthermore, the merchant 106(1) may hold the pre-auth amount for the cardholder 104(1) for a longer duration than what is otherwise needed as per the pre-authorization process.
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 issuers and/or the cardholders 104 to understand the behavior of merchants 106 raising pre-auth requests frequently and detecting suspicious merchants involved in the pre-auth transactions using various Artificial Intelligence (AI) or Machine Learning (ML) models. 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 issuers to detect such suspicious merchants. In an embodiment, along with detecting the suspicious merchants, the server system 102 also performs forecasting a percentage of the pre-auth amount that would be expected from a cardholder (e.g., the cardholder 104(1)) at the time of clearing the payment transaction with a merchant (e.g., the merchant 106(1)), forecasting a time period within which the cardholder 104(1) would be expected to clear the payment transaction corresponding to the pre-auth amount, determining a probability of the payment transaction being suspicious, 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 118) 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.
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 pre-auth transactions performed by the merchant (e.g., the merchant 106(1)) with the plurality of cardholders 104 that are a part of the network 118 and store the same in the database 116. Therefore, in an embodiment, the database 116 may store a set of ML models 120 and pre-auth transaction data 122. In a non-limiting example, the pre-auth transaction data 122 may include historical information related to a plurality of pre-auth transactions performed by the merchant 106(1) with the plurality of cardholders 104.
Further, it may be noted that, in an example, the server system 102 coupled with the database 116 is embodied within the payment server 114, however, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the issuer servers 108 and the acquirer servers 110. The database 116 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 116 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 116. In one implementation, the database 116 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 116.
In other various examples, the database 116 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 116 also stores merchant profile data associated with the plurality of merchants 106. 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 104 at a particular merchant (e.g., the merchant 106(1)), information of fraudulent or non-fraudulent transactions performed at the merchant, various terminals (e.g., point-of-sale (POS) devices, automated teller machines (ATMs), etc.) associated with each merchant (e.g., the merchant 106(1)), and the like.
In yet another example, the database 116 stores historical payment transaction data that may also include real-time transaction data of the plurality of cardholders 104 and the plurality of merchants 106. 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 machine, 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 116 provides a storage location for data and/or metadata obtained from various operations performed by the server system 102.
In an embodiment, whenever a merchant (e.g., the merchant 106(1)) or a cardholder (e.g., the cardholder 104(1)) initiates a pre-auth request, it may be noted that the server system 102 is configured to receive the pre-auth request. Herein, the pre-auth request may correspond to a payment transaction for a pre-auth amount. Herein, the payment transaction is to be conducted by the cardholder 104(1) to the merchant 106(1). In an embodiment, the payment transaction may correspond to a future transaction that may be conducted at the time of checking out or once the service is received/completed.
Upon receiving the pre-auth request, the server system 102 identifies a possibility of the merchant 106(1) being suspicious. To that effect, the server system 102 may initially access the pre-auth transaction data 122 corresponding to the merchant 106(1) from the database 116. As may be understood, the pre-auth transaction data 122 includes the historical information related to the plurality of pre-auth transactions performed by the merchant 106 (1) with the plurality of cardholders 104. For example, the historical information may include, but is not limited to, a pre-auth transaction amount, a frequency of raising pre-auth requests at a particular cardholder from the plurality of cardholders 104, a count of approvals for the pre-auth requests, a count of rejections of the pre-auth requests, reason of rejection, time period allotted in past for clearing of pre-auth transactions, any complaints registered in the name of the merchant, feedback from the cardholders 104, cardholder-related personal details, merchant-related personal details, and the like.
It may be noted that using the pre-auth transaction data 122, the server system 102 may have to train the set of ML models 120 so that the server system 102 can identify suspicious merchants every time it receives pre-auth requests. Therefore, the pre-auth transaction data 122 may have to be prepared for training the set of ML models 120 which involves pre-processing of the pre-auth transaction data 122. One of the pre-processing steps includes the generation of features for each datapoint from the pre-auth transaction data 122. Thus, in an embodiment, the server system 102 is further configured to generate a plurality of features based, at least in part, on the pre-auth transaction data 122.
In an example embodiment, the plurality of features may include a plurality of cardholder-related features corresponding to each cardholder (e.g., the cardholder 104(1)) of the plurality of cardholders 104 and a plurality of merchant-related features corresponding to the merchant (e.g., the merchant 106(1)). Herein, it may be noted that the plurality of cardholder-related features corresponding to the cardholder 104(1) may be generated based, at least in part, on historical information related to a plurality of pre-auth transactions performed by the cardholder 104(1) at the plurality of merchants 106. This way the plurality of cardholder-related features for each 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 116, wherein the historical information is associated with the pre-auth transaction data 122.
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 pre-auth transactions performed by the merchant 106(1) with the plurality of cardholders 104. The server system 102 may further be configured to generate, via the set of ML models 120, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features. Herein, the pre-auth risk score may indicate a probability of the merchant 106(1) being suspicious. The process of the generation of the pre-auth risk score is described in the present disclosure with reference to FIG. 3.
Moreover, for the server system 102 to be able to use the set of ML models 120, the server system 102 may have to train and generate the set of ML models 120. In a non-limiting example, the set of ML models 120 may include at least three ML models including a first ML model, a second ML model, and a third ML model. However, it may be noted that the set of ML models 120 may include any number of ML models without limiting the scope of the invention.
Therefore, in an embodiment, the server system 102 may further be configured to generate each of the set of ML models 120 based, at least in part, on performing a set of operations iteratively till the performance of each of the set of ML model 120 converges to predefined criteria corresponding to each of the set of ML models 120. 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 set of ML models 120 may or may not remain the same, as a set of features provided to each of the set of ML models 120 may be different. Thus, for training each of the set of ML models 120, the plurality of features may also be split into at least three sets if the set of ML models 120 includes at least three ML models. Further, it may be noted that the plurality of features may be split into more than three sets depending upon the count of ML models in the set of ML models 120 without limiting the scope of the present disclosure.
In some embodiments, each of the set of ML models 120 may correspond to a Gradient Boosting Machine (GBM) model. In a specific example, each of the set of ML models 120 may correspond to an extreme gradient boosting (XGBoost) model. As may be understood that in some scenarios, each of the set of ML models 120 may be generated by the server system 102, the process of the generation of each of the set of ML models 120 is further described with reference to FIGS. 4A and 4B.
It may be noted that as one of the objectives of the present disclosure is to understand the behavior of the merchants 106 for identifying suspicious merchants, the merchant-related features are also considered along with the cardholder-related features for training each of the set of ML models 120.
Upon generating the pre-auth risk score, in an embodiment, the server system 102 may also be configured to flag an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score. In a non-limiting example, the pre-auth risk score may be a value between 0 and 1. Herein, a value close to 0 may indicate a lower risk which means that the merchant 106(1) is less likely to be suspicious. Alternatively, a value close to 1 may indicate a higher risk which means that the merchant 106(1) is more likely to be suspicious. Further, in an embodiment, the threshold risk score may be around 0.5, thereby indicating a lower risk when the pre-auth risk score is less than the threshold risk score and a higher risk when the pre-auth risk score is greater than or equal to the threshold risk score. In some embodiments, the threshold risk score may be any other value without limiting the scope of the invention.
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 118, 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 114. 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 first machine learning (ML) model 218, a second ML model 220, a third ML model 222, and the preauthorization (pre-auth) transaction data 224. Herein, the first ML model 218, the second ML model 220, and the third ML model 222 and examples for the set of ML model 120 of FIG. 1, and the pre-auth transaction data 224 are identical to the pre-auth transaction data 122 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 forecasting a percentage of a pre-auth amount that would be expected from a cardholder (e.g., the cardholder 104(1) at the time of clearing a payment transaction with a merchant (the merchant 106(1)), forecasting a time period within which the cardholder 104(1) would be expected to clear the payment transaction corresponding to the pre-auth amount, determining a probability that the payment transaction being suspicious, detecting suspicious merchants involved in pre-auth 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 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or 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 226 such as the issuer servers 108, the acquirer servers 110, the payment server 114, or communicating with any entity connected to the network 118 (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 228, a training module 230, a preauthorization score computation module 232, and a notification module 234. It should be noted that components, described herein, such as the data pre-processing module 228, the training module 230, the preauthorization 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 228 includes suitable logic and/or interfaces for receiving a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount. Herein, the payment transaction is to be conducted by the cardholder 104(1) to the merchant 106(1). It may be understood that when the cardholder 104(1) approaches or contacts the merchant 106(1) for purchasing a product or to receive a service, the pre-auth request can be initiated and transmitted to the issuer even though the payment transaction may be conducted at a later stage.
For example, the cardholder 104(1) visits a hotel and requests for booking a hotel room for a few days say for seven days. Herein, suppose the hotel has a facility for accepting payments while checking out of the hotel. In such a scenario, the merchant i.e., the hotel authorities may initiate a pre-auth request to the issuer bank of the cardholder 104(1) to check if the cardholder 104(1) has sufficient balance or funds in their account in case a debit card is used. In case a credit card is used by the cardholder 104(1) for booking the hotel room, the pre-auth request may be initiated to check whether a credit limit associated with the credit card of the cardholder 104(1) permits the cardholder 104(1) to obtain such a service from the merchant i.e., the hotel authorities.
It may be noted that while initiating the pre-auth request, the merchants 106, generally have the flexibility to request an estimated amount for preauthorization from the issuer bank based on the type of service the merchants 106 are providing. Upon receiving such pre-auth requests, the issuers are supposed to verify the authenticity of such pre-auth requests and approve or reject them. The server system 102 helps the issuers to make such decisions by providing a pre-auth risk score associated with such pre-auth requests.
Further, in the example considered, once the pre-auth request from the hotel authorities is accepted by the issuer, the estimated amount which may also be referred to as the pre-auth amount may be held by the issuer. This prevents the cardholder 104(1) from accessing the amount that is held. It is important to note that the pre-auth amount is not transferred to the account of the hotel authorities immediately in response to the pre-auth request. This is because, as per the policies of the hotel authorities and standard policies that may be associated with the pre-authorization facility, the payment transaction would be made to the merchant when the cardholder 104(1) is checking out from the hotel. In addition, the payment transaction may be conducted upon computing actual expenditures of the cardholder 104(1) during the stay in the booked hotel room for the requested period, or shorter/longer period than the requested period. The amount computed based on the actual expenditures of the cardholder 104(1) may be different or the same as the pre-auth amount.
In an embodiment, the pre-auth request may include a plurality of details corresponding to the payment transaction that needs to be performed by the cardholder 104(1) at the merchant 106(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, merchant’s preauthorization policies, and the like. In another non-limiting example, the plurality of details may further include cardholder ID, cardholder account details, cardholder contact details, issuer’s preauthorization policies, issuer’s terms and conditions, and the like.
In some embodiments, the database 204 may also keep track of such pre-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), and the like. In yet another embodiment, the historical payment transaction dataset may include information related to the acquirer servers 110 such as the date of merchant registration with the acquirer servers 110, amount of payment transactions performed at the acquirer servers 110 in a day, number of payment transactions performed at the acquirer servers 110 in a day, maximum transaction amount, minimum transaction amount, number of fraudulent merchants or non-fraudulent merchants registered with the acquirer servers 110, and the like.
Further, in an embodiment, upon receiving the pre-auth request, the data pre-processing module 228 may be configured to access the pre-auth transaction data 224 corresponding to the merchant 106(1) from the database 204 associated with the server system 200. Herein, the pre-auth transaction data 224 may include historical information related to a plurality of pre-auth transactions performed by the merchant 106(1) with a plurality of cardholders (e.g., the cardholders 104).
In a non-limiting example, the historical information may be similar to the historical payment transaction dataset, but related to the plurality of pre-auth transactions performed by the merchant 106(1) with the plurality of cardholders 104 instead of mere payment transactions as mentioned above. In another example, the historical information may include a pre-auth transaction amount, a frequency of raising pre-auth requests at a particular cardholder from the plurality of cardholders 104 by the merchant 106(1), a count of approvals for the pre-auth requests from the merchant 106(1), a count of rejections of the pre-auth requests, a metric indicating reason of rejection, time period allotted in past for clearing of pre-auth transactions, metrics related to any complaints registered in the name of the merchant 106(1), metrics related to feedback from the cardholders 104, cardholder-related personal details, merchant-related personal details, and the like.
It may be noted that the pre-auth transaction data 224 corresponding to the merchant 106(1) may be accessed by the data pre-processing module 228 to analyze the corresponding pre-auth transaction data 224 for obtaining characteristics or properties of data samples of the pre-auth transaction data 224 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 228 may further be configured to generate a plurality of features based, at least in part, on the pre-auth transaction data 224.
In some embodiments, prior to the generation of the features, the data pre-processing module 228 may be configured to gather data samples from the pre-auth transaction data 224 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 228 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 228 may be configured to select a subset of relevant features from the plurality of features for reducing dimensionality and improving 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(1)) of the plurality of cardholders 104 and a plurality of merchant-related features corresponding to the merchant 106.
It may be noted that the plurality of features may be generated for training a set of ML models (e.g., the set of ML models 120) including the first ML model 218, the second ML model 220, and the third ML model 222. Therefore, the plurality of features is provided as input to the training module 230. Herein, it may be noted that the set of ML models 120 may include any number of ML models without limiting the scope of the invention.
In an embodiment, the training module 230 includes suitable logic and/or interfaces for training the set of ML models by performing a set of operations iteratively till the performance of each of the set of ML models converges to predefined criteria for each of the set of ML models. Herein, it may be noted that for training each of the set of ML model 120, a separate set of features may be used. Therefore, in an embodiment of training the first ML model 218, the second ML model 220, and the third ML model 222, the plurality of features may be split into a first set of features, a second set of features, and a third set of features respectively. Further, the first set of features may be used for training the first ML model 218, the second set of features may be used for training the second ML model 220, and the third set of features may be used for training the third ML model 222.
In an embodiment, the first set of features may include at least: an approval rate, an amount of transactions, a count of transactions, an amount approved, a count approved, an average approval amount, a count of pre-auth transactions, an amount of pre-auth transactions, a count of pre-auth transactions approved, an amount of pre-auth transactions approved, an approval rate pre-auth, an average clearing percentage for pre-auth, and the like corresponding to the plurality of cardholders 104 and the plurality of merchants 106.
In another embodiment, the first set of features may further include at least: merchant category code (MCC), MCC overall approval rate, MCC overall pre-auth approval rate, MCC clearing percentage for pre-auth, count of declines for different reason codes, top MCCs on which transactions are conducted, and the like.
In yet another embodiment, the first set of features may further include at least: an aggregate merchant approval rate, an aggregate merchant count transaction, an aggregate merchant amount transaction, an aggregate merchant count of pre-auth transaction, an aggregate merchant amount of pre-auth transaction, an aggregate merchant pre-auth approval rate, an aggregate merchant percentage of cleared pre-auth amount, and the like corresponding to a plurality of aggregate merchants.
Further, in an embodiment, the second set of features may include at least: an average time to clear transactions, an average time to clear pre-auth transactions, and the like corresponding to the plurality of cardholders 104 and the plurality of merchants 106.
In another embodiment, the third set of features may include at least: a fraud count, a fraud amount, a fraud count pre-auth, a fraud amount pre-auth, an overall fraud rate, a pre-auth fraud rate, and the like corresponding to the plurality of cardholders 104 and the plurality of merchants 106.
It may be noted that the plurality of features may be split into the first set of features, the second set of features, and the third set of features as mentioned above, based on the objective of the training of the first ML model 218, the second ML model 220, and the third ML model 222 respectively. Moreover, in an embodiment, each of the set of ML models 120 may correspond to an extreme gradient boosting (XGBoost) model.
Thus, in an embodiment, the training module 230 may be configured to generate the first ML model 218 based, at least in part, on performing a first set of operations iteratively till the performance of the first ML model 218 converges to first predefined criteria. In an embodiment, the first ML model 218 may be trained to predict a percentage of the pre-auth amount that would be expected to be cleared by the cardholders 104. Herein, the first set of operations may be chosen based on the type of ML model being trained and the first set of features may be chosen based on the above-mentioned objective of the first ML model 218. Therefore, in an embodiment, the first set of operations may include initializing the first ML model 218, generating decision trees with every iteration and optimized loss function and other optimization parameters, assigning weights to each of the decision trees, and obtaining an ensemble of the decision trees. These operations may be performed iteratively till the performance of the first ML model 218 converges to the first predefined criteria. In a non-limiting example, the first predefined criteria may include the saturation of 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.
Further, in an embodiment, the training module 230 may be configured to generate the second ML model 220 based, at least in part, on performing a second set of operations iteratively till the performance of the second ML model 220 converges to second predefined criteria. Herein, the second set of operations and the second predefined criteria are substantially similar to that of the first ML model 218. In an embodiment, the second ML model 220 may be trained to predict a clearance period within the cardholders 104 is expected to clear the payment transaction, and hence the second set of features may be chosen based on achieving this objective of the second ML model 220.
In another embodiment, the training module 230 may be configured to generate the third ML model 222 based, at least in part, on performing a third set of operations iteratively till the performance of the third ML model 222 converges to a third predefined criteria. Herein, the third set of operations and the third predefined criteria are substantially similar to that of the first ML model 218. In an embodiment, the third ML model 222 may be trained to determine a probability of the payment transaction being suspicious, and hence the third set of features may be chosen based on achieving this objective of the third ML model 222. The process of training each of the set of ML models 120 is described in the present disclosure with reference to FIGS. 4A and 4B. The set of ML models 120 that are trained by the training module 230 are used by the preauthorization score computation module 232.
Further, upon training the set of ML models in an embodiment, the preauthorization score computation module 232 includes suitable logic and/or interfaces for generating, via the set of ML models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features. Herein, the pre-auth risk score may indicate a probability of the merchant 106(1) being suspicious.
In an embodiment, it may be noted that for generating the pre-auth risk score, the preauthorization score computation module 232 may be configured to determine, via the first ML model 218 of the set of ML models 120, a predicted percentage of the pre-auth amount that is most likely expected to be cleared by the cardholder 104(1) while conducting the payment transaction based, at least in part, on the first set of features from the plurality of features. Herein, it may be noted that the first set of features is related to all pre-auth cleared payment transactions for a certain period related to both the plurality of merchants 106 and the plurality of cardholders 104. Also, the first set of features may include details such as pre-auth approval rate, pre-auth amounts, a count of pre-auth transactions, and the like. Therefore, the first ML model 218 gets trained to predict a percentage of the pre-auth amount that will be expected from the cardholder 104(1) to clear at the time of clearing the payment transaction. The preauthorization score computation module 232 may further be configured to generate an amount-based score based, at least in part, on the pre-auth amount, the predicted percentage of the pre-auth amount, and a threshold pre-auth percentage value.
In an embodiment, the preauthorization score computation module 232 may compare the predicted percentage of the pre-auth amount with the threshold pre-auth percentage value. In a non-limiting example, the predicted percentage of the pre-auth amount may be a number between 0 and 1 (normalized), and the threshold pre-auth percentage value may be about 0.5. Additionally, in another non-limiting example, the amount-based score may also be a number between 0 and 1. Upon comparison if the predicted percentage of the pre-auth amount is greater than the threshold pre-auth percentage value, the amount-based score may be close to 1 or equal to 1, otherwise, it will be close to 0 or equal to 0. In other words, if the pre-auth amount is 50 dollars ($), however, the predicted percentage of the pre-auth amount is 0.7 i.e. 70 percent (%) of the pre-auth amount i.e. 35$ which is close to the pre-auth amount, and also greater that the threshold pre-auth percentage value i.e., 50% of the pre-auth amount (25$). In such a scenario, the amount-related score may have to be 1 and hence is in favor of approving the pre-auth request. In case the predicted percentage of the pre-auth amount is about 45% or 0.45 of the pre-auth amount i.e., 22.5$ which is less than the pre-auth amount and is also less than the threshold pre-auth percentage value. In such a scenario, the amount-related score may have to be 0 and hence is in favor of rejecting the pre-auth request.
Upon generating the amount-related score, the preauthorization score computation module 232 may be configured to determine, via the second ML model 220 of the set of ML models 120, a predicted clearance period within which the cardholder 104(1) is most likely expected to clear the payment transaction based, at least in part, on the second set of features from the plurality of features. Herein, it may be noted that the second set of features is related to all pre-auth cleared payment transactions for a certain period related to both the plurality of merchants 106 and the plurality of cardholders 104. Also, the second set of features may include details such as an average time to clear transactions, an average time to clear pre-auth transactions, and the like. Therefore, the second ML model 220 gets trained to predict a clearance period within which the cardholder 104(1) is expected to clear the payment transaction. The preauthorization score computation module 232 may further be configured to generate a period-based score based, at least in part, on a clearance period taken by the cardholder 104(1) to clear the predicted percentage of the pre-auth amount, the predicted clearance period, and a threshold tolerance period.
In an example, a clearance period might vary from 7 days to almost a month. However, if the funds of the cardholder 104(1) are held for longer periods very frequently, then such pre-auth requests may have to be rejected to prevent the cardholder 104(1) from facing any inconvenience as the funds are not accessible for the cardholder 104(1) for that particular clearance period. In addition, in some embodiments, if the difference between the predicted clearance period and the clearance period taken by the cardholder 104(1) to clear the predicted percentage of the pre-auth amount is larger for a corresponding pre-auth request, then such requests may also have to be rejected.
In a non-limiting example, the predicted clearance period might vary between 0 to 30 days. In another example, it can be a negative value such as -1 when the cardholder 104(1) is not actually expected to clear the payment transaction. In another non-limiting example, the clearance period taken by the cardholder 104(1) to clear the predicted percentage of the pre-auth amount may be the same as the predicted clearance period or may be different. Therefore, in an embodiment, the threshold tolerance period may correspond to a threshold value for a difference between the predicted clearance period and the clearance period taken by the cardholder 104(1) to clear the predicted percentage of the pre-auth amount. In a non-limiting example, the threshold tolerance period may be about 3 days. In another non-limiting example, the period-based score may be a number between 0 and 1.
Therefore, the preauthorization score computation module 232 may compare the difference between the predicted clearance period and the clearance period taken by the cardholder 104(1) to clear the predicted percentage of the pre-auth amount with the threshold tolerance period. Upon comparison, if the difference is greater than the threshold tolerance period then the period-based score may be close to 1 or equal to 1 which implies to be in favor of rejecting the corresponding pre-auth request. Alternatively, if the difference is less than or equal to the threshold tolerance period then the period-based score may be close to 0 or equal to 0 which implies to be in favor of approving the corresponding pre-auth request.
Upon generating the period-based score, the preauthorization score computation module 232 may determine, via the third ML model 222 of the set of ML models 120, a probability of the payment transaction being suspicious based, at least in part, on the third set of features from the plurality of features. Herein, it may be noted that the third set of features are related to all pre-auth cleared payment transactions for a certain period related to both the plurality of merchants 106 and the plurality of cardholders 104. Also, the third set of features may include details related to fraudulent activities such as fraud count, fraud amount, fraud count pre-auth, fraud amount pre-auth, fraud rate, fraud rate pre-auth, and the like. Therefore, the third ML model 222 gets trained to determine a probability of the payment transaction being suspicious.
Further, in an embodiment, the preauthorization score computation module 232 may generate the pre-auth score based, at least in part, on the amount-based score, the period-based score, and the probability of the payment transaction being suspicious. In a non-limiting example, the pre-auth risk score may be an integer value which may be 0 or 1. Herein, it may be noted that the pre-auth risk score indicates the probability of the merchant being suspicious Therefore, it may be noted that if the pre-auth risk score is equal to 1 then the probability of the merchant being suspicious is more. Alternatively, if the pre-auth risk score is equal to 0 then the probability of the merchant being suspicious is less.
Upon obtaining the pre-auth risk score, it may have to be shared with the issuer, as the issuer is responsible for approving or declining the pre-auth request. Therefore, in an embodiment, the notification module 234 includes suitable logic and/or interfaces for flagging the issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score. In other words, it may be noted that a notification may be transmitted to the issuer about the pre-auth risk score being greater than or equal to the threshold risk score.
In a non-limiting example, the threshold risk score maybe 0.5. For instance, if the pre-auth risk score is greater than or equal to 0.5 then it can be rounded off to 1 and hence the pre-auth request is considered to have a higher probability of being received from a suspicious merchant. Alternatively, if the pre-auth risk score is less than 0.5 then it can be rounded off to 0 and hence the pre-auth request is considered to have a lower probability of being received from a suspicious merchant.
FIG. 3 illustrates a block diagram representation 300 depicting a process flow of generating the pre-auth risk score (e.g., a pre-auth risk score 302), in accordance with an embodiment of the present disclosure. In an embodiment, the pre-auth risk score 302 may be generated by the server system 200 via the preauthorization score computation module 232. To explain the process of generating the pre-auth risk score 302 consider an example of a cardholder 304 accessing a car rental website 306 via a cardholder’s mobile phone 308 for booking a car 310 on rent for four days. It may be noted that when the cardholder 304 provides debit card details for booking the car 310 on rent on the car rentals’ website 306, a merchant (e.g., car rental authorities 312) can verify whether the cardholder 304 is eligible for booking the car 310 on rent before permitting the cardholder 304 to proceed with the booking. To do so, the car rental authorities 312 share a pre-auth request 314 to an issuer bank 316 which has an account of the cardholder 304. The pre-auth request 314 may be associated with pre-auth amount. Herein, the pre-auth amount may be a certain amount that may include a rent corresponding to the car 310 that the cardholder 304 is willing to book along with some additional charges that may occur due to any future damages to the rented car 310 or any other charges.
Suppose the issuer bank 316 is using a facility provided by the server system 200 for checking whether the car rental authorities 312 are trying to misuse the facility of raising a pre-auth request (e.g., the pre-auth request 314). Therefore, the server system 200 receives the pre-auth request 314 via the data pre-processing module 228. Upon receiving the pre-auth request 314, the server system 200 accesses the pre-auth transaction data 224 from the database 204 via the data pre-processing module 228. As may be understood, the pre-auth transaction data 224 includes historical information related to a plurality of pre-auth transactions performed by the car rental authorities 312 with a plurality of cardholders in the past. Therefore, it may be noted that this pre-auth transaction data 224 may help the server system 200 to understand the behavior of the car rental authorities 312 in the past with other cardholders.
It may be noted that to understand the behavior of the car rental authorities 312 with the cardholders in the past may mean that the server system 200 may learn a pattern that the car rental authorities 312 may be following to decide the pre-auth amount to be charged, a pattern of clearing amounts paid by the cardholders in past during settlement, a pattern of clearing periods of the cardholders in past, a pattern of frauds associated with the car rental authorities 312 and/or the customers, and the like. The server system 200 may also learn legitimate patterns like how much pre-auth amount must be requested so that it is close to the clearing amounts that the cardholders might pay during settlement, what should be a clearing period, and the like.
For the server system 200 to learn the above-mentioned operations, the server system 200 may use the set of ML models 120 including the first ML model 218, the second ML model 220, and the third ML model 222. Therefore, the server system 200 may train and generate the set of ML models 120 via the training module 230. Herein, the training module 230 may train the set of ML models 120 using the plurality of features (e.g., a plurality of features 318). It may be noted that the plurality of features 318 may be generated from the pre-auth transaction data 224 by the server system 200 via the data pre-processing module 228. As mentioned above, the plurality of features 318 may include cardholder-related features 318A and merchant-related features 318B as shown in FIG. 3 as the training of the set of ML models 120 requires features associated with both for better performance of each of the set of ML models 120 and obtain more efficient results in comparison to conventional methods. Herein, it may be noted that the cardholder-related feature 318A may correspond to features related to the cardholder 304 and the merchant-related features 318B may be features related to the merchants such as the car rental authorities 312.
Upon obtaining the plurality of features 318 from the pre-auth transaction data 224, the plurality of features 318 may be prepared from training the set of ML models 120 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 228.
Herein, for training each of the first ML model 218, the second ML model 220, and the third ML model 222, the plurality of features 318 may be split into the first set of features 320, the second set of features 322, and the third set of features 324 respectively. Examples of the first set of features 320, the second set of features 322, and the third set of features 324 are described in the present disclosure with reference to FIG. 2.
Further, in the current example, the server system 200 may train the first ML model 218 based, at least in part on, the first set of features 320 via the training module 230. The training module 230 may train the first ML model 218 to predict a percentage of the pre-auth amount that would be expected to be cleared by the cardholder 304. Similarly, the server system 200 may train the second ML model 220 based, at least in part, on the second set of features 322 via the training module 230. The training module 230 may train the second ML model 220 to predict a clearance period within which the cardholder 304 is expected to clear the payment transaction corresponding to the pre-auth request 314 from the car rental authorities 312. Moreover, the server system 200 may train the third ML model 222 based, at least in part, on the third set of features 324 via the training module 230. The training module 230 may train the third ML model 222 to determine a probability of the payment transaction corresponding to the pre-auth request 314 received from the car rental authorities 312 is suspicious.
Upon training the set of ML models 120, the server system 200 may use them for computing the pre-auth risk score 302 via the preauthorization score computation module 232. Herein, the pre-auth risk score 302 may indicate a probability of the car rental authorities 312 being suspicious i.e., the probability of the car rental authorities 312 misusing the facility of generating a pre-auth request 314.
Further, as described in the present disclosure with reference to FIG. 2 the intermediate steps of generating the pre-auth risk score 302 may include generating the amount-based score, the period-based score, and the probability of the payment transaction being suspicious. Later, based on the amount-based score, the period-based score, and the probability of the payment transaction being suspicious, the pre-auth risk score 302 may be generated.
For example, suppose cars at the car rentals’ website 306 can be rented at a rate of about 20$/day. Herein, the cardholder 304 wants to rent the car 310 for four days, therefore, the total amount should be 80$. However, the car rental authorities 312 while generating the pre-auth request 314, request a larger amount by mentioning about considering any breakage charges, fuel charges, considering a possibility of extension of the rental period, additional taxes, etc. Suppose the pre-auth amount requested by the car rental authorities 312 is 160$. Here, it may be noted that the car rental authorities 312 have charged the pre-auth amount which is double the actual amount that was supposed to be charged. The issuer bank 316 checks for the bank balance of the cardholder 304 and is responsible for checking whether the car rental authorities 312 are misusing a pre-auth facility. Therefore, the issuer bank 316 uses the server system 200 and generates the pre-auth risk score for the car rental authorities 312. Suppose upon learning the historic behavior of the car rental authorities 312, the server system 200 may predict that the cardholder 304 will have to pay 50% of the pre-auth amount i.e., 80$ while checking out, and hence provide an amount-based score corresponding to 0 as the predicted percentage of the pre-auth amount was very less such that is equal to the threshold pre-auth percentage value which generally is 50%.
Further, suppose the server system 200 may predict a clearance period of 7 days, however, the cardholder 304 cleared the payment transaction after 12 days. As may be understood when the threshold tolerance period is about 3 days, then since the cardholder 304 took 5 days extra time to clear the settlement, the period-based score may be equal to 1. Lastly, since the history of the car rental authorities 312 included fraud history, the server system 200 predicted the probability of the payment transaction being suspicious to be unity. Herein, it may be noted that the value of 0 for the amount-based score, the value of 1 for the period-based score, and the probability of 1 are all in favor of declining the pre-auth request 314 as all these values are indicating that the car rental authorities 312 are trying to misuse the pre-auth facility. Therefore, the pre-auth risk score may also be 1 which indicates that the probability of the car rental authorities 312 being suspicious is higher. Later, the issuer bank 316 may have to be notified about the car rental authorities 312 being suspicious. Thus, the server system 200 may transfer a notification 326 to the issuer bank 316 via the notification module 234 as shown in FIG. 3. Once the issuer bank 316 receives the notification 326, the issuer bank 316 responds to the pre-auth request 314 of the car rental authorities 312 with a request decline message 328 as shown in FIG. 3. The same information may also be provided to the cardholders 304 for awareness of the cardholders 304 about such suspicious merchants in the market of car rentals.
FIG. 4A illustrates a schematic representation 400 of a process of training of the set of ML models (e.g., the set of ML models 120) for generating the pre-auth risk score (e.g., the pre-auth risk score 302), in accordance with an embodiment of the present disclosure. In a non-limiting example, the set of ML models 120 may include the first ML model 218, the second ML model 220, and the third ML model 222. Herein each of the first ML model 218, the second ML model 220, and the third ML model 222 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 first ML model 218, the second ML model 220, and the third ML model 222, the pre-auth risk score 302 may be generated.
Moreover, as may be understood that, in an embodiment, each of the set of ML models 120 may be a Gradient Boosting Machine (GBM) model or an extreme gradient boosting (XGBoost) model, training steps of each of the set of ML models 120 may be same with an only difference in the features provided to each of the set of ML models 120.
As used herein, 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 which 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 that 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 pre-auth transaction data 224 along with the plurality of features 318. 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 decision trees (e.g., decision trees 404(1), 404(2), … 404(M) where ‘M’ is a non-zero Natural number, hereinafter, interchangeably referred to as decision trees 404) sequentially, where a subset of the training data for each subsequent tree (e.g., the decision tree 404(2)) is chosen based on the performance of the previous decision trees (e.g., the decision tree 404(1)), as shown in FIG 4A. More specifically, each decision tree 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 decision trees. Therefore, each new decision tree corrects the errors made by the previous trees. This will finally produce ‘M’ decision trees, where ‘M’ depends on the number of predetermined iterations for the algorithm, which provide ‘M’ predictions 406(1), 406(2), … 406(M) where ‘M’ is a non-zero natural number, hereinafter, interchangeably referred to as predictions 406).
Further, the final classification is made by combining the outputs (e.g., the predictions 406) of all the classifiers (decision trees) with the chosen weighting and averaging method. In other words, it may be noted that an average of the predictions 406 (see, 408) may be performed by the XGBoost model for obtaining a final prediction 410 as shown in FIG. 4A.
FIG. 4B illustrates a flow diagram representation 460 of a process flow of training the set of ML models 120, in accordance with an embodiment of the present disclosure. In a non-limiting example, the set of ML models 120 may include the first ML model 218, the second ML model 220, and the third ML model 222. In another example, the set of ML models may include any number of ML models without limiting the scope of the present disclosure. Herein, in an embodiment, each of the set of ML models 120 may be trained via the training module 230 by performing a set of operations iteratively till the performance of each of the set of ML models 120 converges to predefined criteria. In a non-limiting example, each of the set of ML models 120 may be an XGBoost model whose basic functionality is explained in the present disclosure with reference to FIG. 4A.
In a specific embodiment, the set of operations may include model initialization 462, decision tree generation 464, optimization parameters computation 466, new decision tree generation 468, weights assignment 470, ensemble decision trees 472, optimize model parameters 474, and check whether the performance of the ML model (e.g., each of the set of ML models 120) converged to the predefined criteria (see, 476). In case of the ML model converges to the predefined criteria, the training of the ML model stops (see, 478), otherwise, the set of operations in the training of the ML model would be repeated as shown in FIG. 4B.
As may be understood that 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 462 may include initializing an ML model (e.g., the first ML model 218, the second ML model 220, or the third ML model 222) of the set of ML models 120 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 decision tree generation 464 may include a step of generating a set of classification and regression trees. In this step, based on the training data a decision tree may be generated. In other words, it may be noted that this step includes generating a decision tree for generating predictions 406 (as shown in FIG. 4A) based, at least in part, on a set of features from the plurality of features. Herein, the set of features selected from the plurality of features may be dependent upon whether the ML model is the first M model 218, the second ML model 220, or the third ML model 222.
Later, the step of optimization parameters computation 466 may be implemented. Herein, the ML model may compute one or more optimization parameters based at least on the performance of the decision tree, 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 decision tree generation 468 may include building a new decision tree for reducing the one or more optimization parameters. Herein, it may be noted that the new decision tree 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 470 may include assigning weights to the new decision tree and the previously generated decision tree based, at least in part, on a performance of the new decision tree and the previously generated decision tree in reducing the one or more optimization parameters. For example, decision trees that contribute more to the model’s predictive performance receive higher weights.
Later, in an embodiment, the step of ensemble decision trees 472 may be performed which includes generating an ensemble of a plurality of decision trees (e.g., decision trees 404, as shown in FIG. 4A) by adding predictions (e.g., prediction 406(2)) of the new decision tree to predictions (e.g., prediction 406(1)) of the previously generated decision tree. Lastly, the step of optimizing model parameters 474 may be performed which includes optimizing the one or more model parameters for the corresponding ML model of the set of ML models 120.
Upon obtaining the ensemble of the decision trees 404 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, 478), 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 trees 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 a 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 first ML model 218 via the training module 230. The training module 230 may perform a first set of operations to generate the first ML model 218. Upon performing the first set of operations, the first ML model 218 may get trained using the pre-auth transaction data 224 and learn to generate a predicted percentage of the pre-auth amount that may be expected to be cleared by the cardholder 104(1) while closing the payment transaction at the merchant 106(1). Herein, the first ML model 218 may be based on the first set of features.
Similarly, the second ML model 220 may get trained using the pre-auth transaction data 224 and learn to generate a predicted clearance period within which the payment transaction is expected to be cleared by the cardholder 104(1). Herein, the second ML model 220 may be based on the second set of features. Lastly, the third ML model 222 may get trained using the pre-auth transaction 224 and learn to determine a probability of the payment transaction being suspicious. Herein, the third ML model 222 may be based on the third set of features 324.
Moreover, it may be noted that the set of operations performed for training each of the first ML model 218, the second ML model 220, and the third ML mode 222 may be the same as described above with reference to the step of model initialization 462 to the step of checking the performance of the model (see, 476) with the difference being the set of features on which the training process is implemented for each model.
FIG. 5 illustrates a process flow diagram depicting a method 500 for generating a pre-auth risk score (e.g., the pre-auth risk score 302), in accordance with an embodiment of the present disclosure. The method 500 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 500 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 500, and combinations of operations in the method 500 may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions. The plurality of operations is depicted in the process flow of the method 500. The process flow starts at operation 502.
At 502, the method 500 includes determining, by a server system (e.g., the server system 200) via a first machine learning (ML) model (e.g., the first ML model 218) of a set of ML models (e.g., the set of ML models 120), a predicted percentage of a pre-auth amount that is most likely expected to be cleared by a cardholder (e.g., the cardholder 104(1)) while conducting a payment transaction based, at least in part, on a first set of features (e.g., the first set of features 320) from a plurality of features (e.g., the features 318).
At 504, the method 500 includes generating, by the server system 200, an amount-based score based, at least in part, on the pre-auth amount, the predicted percentage of the pre-auth amount, and a threshold pre-auth percentage value.
At 506, the method 500 includes determining, by the server system 200 via a second ML model (e.g., the second ML model 220) of the set of ML models 120, a predicted clearance period within which the cardholder 104(1) is most likely expected to clear the payment transaction based, at least in part, on a second set of features (e.g., the second set of features 322) from the plurality of features 318.
At 508, the method 500 includes generating, by the server system 200, a period-based score based, at least in part, on a clearance period taken by the cardholder 104(1) to clear the predicted percentage of the pre-auth amount, the predicted clearance period, and a threshold tolerance period.
At 510, the method 500 includes determining, by the server system 200 via a third ML model (e.g., the third ML model 222) of the set of ML models 120, a probability of the payment transaction being suspicious based, at least in part, on a third set of features (e.g., the third set of features 324) from the plurality of features 318
At 512, the method 500 includes generating, by the server system 200, the pre-auth score based, at least in part, on the amount-based score, the period-based score, and the probability of the payment transaction being suspicious.
FIG. 6 illustrates a process flow diagram depicting a method 600 for detecting suspicious merchants involved in pre-auth transactions, 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 802.
At 602, the method 600 includes receiving, by a server system (e.g., the server system 200), a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount. Herein, the payment transaction is to be conducted by a cardholder (e.g., the cardholder 104(1)) to a merchant (e.g., the merchant 106(1)).
At 604, the method 600 includes, upon receiving the pre-auth request 314, accessing, by the server system 200, pre-auth transaction data (e.g., the pre-authorization data 224) corresponding to the merchant 106(1) from a database (e.g., the database 204) associated with the server system 200. Herein, the pre-auth transaction data 224 includes historical information related to a plurality of pre-auth transactions performed by the merchant 106(1) with a plurality of cardholders (e.g., the cardholders 104).
At 606, the method 600 includes generating, by the server system 200, a plurality of features (e.g., the features 318) including: a plurality of cardholder-related features (e.g., the cardholder-related features 318A) corresponding to each cardholder of the plurality of cardholders 104 and a plurality of merchant-related features (e.g., the merchant-related features 318B) corresponding to the merchant 106(1) based, at least in part, on the pre-auth transaction data 224.
At 608, the method 600 includes generating, by the server system 200 via a set of Machine Learning (ML) models (e.g., the set of ML models 120), a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features 318. Herein, the pre-auth risk score 302 indicates a probability of the merchant 106(1) being suspicious.
At 610, the method 600 includes flagging, by the server system 200, an issuer about the pre-auth request 314 when the pre-auth risk score 302 is at least equal to a threshold risk score.
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 110 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 preauthorization (pre-auth) transactions associated with the merchant.
In one embodiment, the acquirer server 700 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholders 104, account identification information, and a payment card number) in a transaction database 708. The details of the cardholders 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 118 of FIG. 1. The examples of the remote device 710 include the server system 102, the payment server 114, the issuer servers 108, 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 cardholders 104 via the network 118. 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 114). 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 cardholders 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, pre-auth transactions, 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 108 of FIG. 1. The issuer server 800 is associated with an issuer bank/issuer, in which an account holder (e.g., the cardholders 104(1)-104(N)) 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 cardholders (e.g., the cardholders 104(1)-104(N)), 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 preauthorization transactions associated with the cardholders 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 104, account identification information, payment card number, etc.) in a database. The details of the cardholders 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 cardholders 104.
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 118 of FIG. 1. Examples of the remote device 808 include the server system 200, the payment server 114, the acquirer servers 110 or other computing systems of the issuer server 800. The communication module 806 is capable of facilitating such operative communication with the remote devices 808 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(1)) via the network 118. 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 114). 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, details of the account holders, account identification information, payment card number, or the like. The details of the account holders (e.g., the cardholders 104(1)-104(N)) 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 cardholders 104.
FIG. 9 illustrates a simplified block diagram of the payment server 900, in accordance with an embodiment of the present disclosure. The payment server 900 is an example of the payment server 114 of FIG. 1. The payment server 900 and the server system 200 may use the payment network 112 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
The payment server 900 includes a processing 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 108, the acquirer servers 110, 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 110 or a payment terminal (e.g., IoT device), the payment server 900 may route the payment transaction request to the issuer servers 108. 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 110 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 108 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 108. 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 110. 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 FIGS. 5 and 6, 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.
, Claims:1. A computer-implemented method, comprising:
receiving, by a server system, a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount, the payment transaction to be conducted by a cardholder to a merchant;
upon receiving the pre-auth request, accessing, by the server system, pre-auth transaction data corresponding to the merchant from a database associated with the server system, the pre-auth transaction data comprising historical information related to a plurality of pre-auth transactions performed by the merchant with a plurality of cardholders;
generating, by the server system, a plurality of features comprising: 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 based, at least in part, on the pre-auth transaction data;
generating, by the server system via a set of Machine Learning (ML) models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features, the pre-auth risk score indicating a probability of the merchant being suspicious; and
flagging, by the server system, an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score.

2. The computer-implemented method as claimed in claim 1, wherein the set of ML models comprises a first ML model, a second ML model, and a third ML model, wherein the first ML model, the second ML model, and the third ML model comprises a Gradient Boosting Machine (GBM) model.

3. The computer-implemented method as claimed in claim 1, wherein generating the pre-auth risk score comprises:
determining, by the server system via a first ML model of the set of ML models, a predicted percentage of the pre-auth amount that is most likely to be cleared by the cardholder while conducting the payment transaction based, at least in part, on a first set of features from the plurality of features;
generating, by the server system, an amount-based score based, at least in part, on the pre-auth amount, the predicted percentage of the pre-auth amount, and a threshold pre-auth percentage value;
determining, by the server system via a second ML model of the set of ML models, a predicted clearance period within which the cardholder is most likely to clear the payment transaction based, at least in part, on a second set of features from the plurality of features;
generating, by the server system, a period-based score based, at least in part, on a clearance period taken by the cardholder to clear the predicted percentage of the pre-auth amount, the predicted clearance period, and a threshold tolerance period;
determining, by the server system via a third ML model of the set of ML models, a probability of the payment transaction being suspicious based, at least in part, on a third set of features from the plurality of features; and
generating, by the server system, the pre-auth risk score based, at least in part, on the amount-based score, the period-based score, and the probability of the payment transaction being suspicious.

4. The computer-implemented method as claimed in claim 3, wherein the first set of features comprises at least one of: an approval rate, an amount of transactions, a count of transactions, an amount approved, a count approved, an average approval amount, a count of pre-auth transactions, an amount of pre-auth transactions, a count of approved pre-auth transactions, an amount of approved pre-auth transactions, an approval rate pre-auth, and an average clearing percentage for pre-auth corresponding to the plurality of cardholders and a plurality of merchants.

5. The computer-implemented method as claimed in claim 4, wherein the first set of features further comprises at least one of: merchant category code (MCC), MCC overall approval rate, MCC overall pre-auth approval rate, MCC clearing percentage for pre-auth, count of declines for different reason codes, and top MCCs on which transactions are conducted.

6. The computer-implemented method as claimed in claim 4, wherein the first set of features further comprises: an aggregate merchant approval rate, an aggregate merchant count transaction, an aggregate merchant amount transaction, an aggregate merchant count transaction pre-auth, an aggregate merchant amount transaction pre-auth, an aggregate merchant approval rate pre-auth, and an aggregate merchant percentage of cleared amount pre-auth corresponding to a plurality of aggregate merchants.

7. The computer-implemented method as claimed in claim 3, wherein the second set of features comprises at least one of: an average time to clear transactions and an average time to clear transactions pre-auth corresponding to the plurality of cardholders and a plurality of merchants.

8. The computer-implemented method as claimed in claim 3, wherein the third set of features comprises at least one of: a fraud count, a fraud amount, a fraud count pre-auth, a fraud amount pre-auth, a fraud rate overall, and a fraud rate pre-auth corresponding to the plurality of cardholders and a plurality of merchants.

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

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

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

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

13. 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 a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount, the payment transaction to be conducted by a cardholder to a merchant;
upon receiving the pre-auth request, access pre-auth transaction data corresponding to the merchant from a database associated with the server system, the pre-auth transaction data comprising historical information related to a plurality of pre-auth transactions performed by the merchant with a plurality of cardholders;
generate a plurality of features comprising: 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 based, at least in part, on the pre-auth transaction data;
generate, via a set of Machine Learning (ML) models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features, the pre-auth risk score indicating a probability of the merchant being suspicious; and
flag an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score.

14. The server system as claimed in claim 13, wherein the set of ML models comprises a first ML model, a second ML model, and a third ML model, wherein the first ML model, the second ML model, and the third ML model comprises a Gradient Boosting Machine (GBM) model.

15. The server system as claimed in claim 13, wherein to generate the pre-auth score the server system is further caused, at least in part, to:
determine, via a first ML model of the set of ML models, a predicted percentage of the pre-auth amount that is most likely to be expected to be cleared by the cardholder while conducting the payment transaction based, at least in part, on a first set of features from the plurality of features;
generate an amount-based score based, at least in part, on the pre-auth amount, the predicted percentage of the pre-auth amount, and a threshold pre-auth percentage value;
determine, via a second ML model of the set of ML models, a predicted clearance period within which the cardholder is most likely expected to clear the payment transaction, at least in part, on a second set of features from the plurality of features;
generate a period-based score based, at least in part, on a clearance period taken by the cardholder, the predicted clearance period, and a threshold tolerance period;
determine, via a third ML model of the set of ML models, a probability of the payment transaction being suspicious based, at least in part, on a third set of features from the plurality of features; and
generate the pre-auth score based, at least in part, on the amount-based score, the period-based score, and the probability of the payment transaction being suspicious.

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

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

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

19. The server system as claimed in claim 13, wherein the server system is a payment server associated with a payment network.

20. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method comprising:
receiving a preauthorization (pre-auth) request corresponding to a payment transaction for a pre-auth amount, the payment transaction to be conducted by a cardholder to a merchant;
accessing pre-auth transaction data corresponding to the merchant from a database associated with the server system, the pre-auth transaction data comprising historical information related to a plurality of pre-auth transactions performed by the merchant with a plurality of cardholders;
generating a plurality of features comprising: 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 based, at least in part, on the pre-auth transaction data;
generating, via a set of Machine Learning (ML) models, a pre-auth risk score associated with the payment transaction based, at least in part, on the plurality of features, the pre-auth risk score indicating a probability of the merchant being suspicious; and
flagging an issuer about the pre-auth request when the pre-auth risk score is at least equal to a threshold risk score.