Description:TECHNICAL FIELD
The present disclosure relates to artificial intelligence-based processing systems and, more particularly, to electronic methods and complex processing systems for identifying non-compliant merchants.

BACKGROUND
With the ever-increasing digitalization of the financial sector, it has become vital for merchants engaged in selling goods or providing services to settle their payment transactions digitally. Examples of digitally settled transactions include transactions settled via electronic transfer of funds or payment instruments such as payment cards. In order to perform digital transactions, merchants are required to set up a merchant account with an acquirer bank. Herein, the acquirer bank is a financial institution (e.g., a bank) that processes financial transactions for merchants associated with it. While setting up the merchant account, the merchant is required to fulfill some regulatory or compliance requirements and contractual obligations. One such requirement is to disclose, the category of the merchant that indicates the field of business of the merchant. For example, a merchant in the business of procuring and selling groceries should be categorized as a grocery merchant. As may be understood, different merchants are subject to different tax slabs/criteria and regulations based on their disclosed merchant categories. Further, while engaging in payment transactions via payment instruments such as payment cards, the payment processor (such as Mastercard®, Visa®, and the like.) associated with the payment card may charge some fees for securely facilitating the transaction based on the merchant category. Such fees generally vary greatly between different merchant categories such to factors such as interchange rate, higher chargeback risk, tiered rate, merchant category-associated risk, and the like. For example, a grocery merchant may be charged a lower fee by a payment processor than a cryptocurrency exchange merchant. Similarly, payment gateways operated by payment processors may also charge some fees for securely facilitating the transaction based on the merchant category.
In order to avoid taxes, high fees, or to circumvent government regulations among other reasons, a fraudster or a fraudulent merchant (known as a ‘non-compliant merchant’) can falsify their records and misclassify themselves with a different merchant category. For example, a cryptocurrency exchange merchant may misclassify themselves as a grocery merchant to avoid government regulations, payment processor fees, and taxes thereby, defrauding the payment processor and the government in the process. In some scenarios, a merchant may fail to correctly identify their merchant category and in turn, incorrectly report their merchant category thereby, becoming a non-compliant merchant. For example, a petrol pump operator with an attached convenience store may misclassify their merchant category by a genuine mistake. Furthermore, merchants that fail to disclose their merchant category due to negligence also fall into the category of non-compliant merchants. Therefore, to avoid such fraudulent or negligent behavior, it is essential to determine whether a merchant’s declared merchant category is true or not. In other words, it is essential to determine whether a merchant is a compliant or non-compliant merchant.
Conventionally, payment processors and regulators employ dedicated compliance analysts or a team of analysts for determining whether the merchant is a compliant merchant or a non-compliant merchant. Such teams analyze payment records of suspicious merchants along with in-person investigations to determine if a merchant is compliant or not. Further, ensemble machine learning models have also been developed for determining whether a merchant is compliant or not. These models combine several weak, simple models to obtain a stronger ensemble prediction. Although these conventional models are effective, they are complex and time-consuming. Further, these models require a list of suspicious merchants before they can operate since analyzing each and every merchant in the payment eco-system will be extremely complex, time-consuming, and requires tremendous processing resources.
Thus, there exists a technological need for technical solutions for identifying non-compliant merchants.
SUMMARY
Various embodiments of the present disclosure provide methods and systems for identifying non-compliant merchants.
In an embodiment, a computer-implemented method for identifying non-compliant merchants is disclosed. The computer-implemented method performed by a server system includes accessing a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system. The historical payment transaction dataset includes a set of historical payment transactions. The known compliant merchant dataset includes information related to a plurality of known compliant merchants. The computer-implemented method further includes determining a plurality of relevant cardholders involved in payment transactions at a plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset. Further, the computer-implemented method includes determining and extracting a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants. The computer-implemented method also includes determining, via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions. Furthermore, the computer-implemented method includes labeling each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants. In addition, the computer-implemented method includes generating a non-compliance report including a list of non-compliant merchants.
In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to access a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system. The historical payment transaction dataset includes information related to a plurality of historical payment transactions. The known compliant merchant dataset includes information related to a plurality of known compliant merchants. The server system is further caused to determine a plurality of relevant cardholders involved in payment transactions at the plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset. Further, the server system is caused to determine and extract a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants. Furthermore, the server system is caused to determine, via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions. The server system is caused to label each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants. Moreover, the server system is caused to generate a non-compliance report including a list of non-compliant merchants.
In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes accessing a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system. The historical payment transaction dataset includes information related to a plurality of historical payment transactions. The known compliant merchant dataset includes information related to a plurality of known compliant merchants. The method further includes determining a plurality of relevant cardholders involved in payment transactions at the plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset. The method also includes determining and extracting a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants. Further, the method includes determining, via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions. Furthermore, the method includes labeling each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants. The method includes generating a non-compliance report including a list of non-compliant merchants.
Further, the method also includes determining a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset. The method further includes determining a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name. In addition, the method includes determining one or more keywords associated with each webpage of the website associated with each non-compliant merchant based, at least in part, on the URL of the website. The method includes determining via an optimization model, a secondary merchant category based, at least in part, on the one or more keywords. Moreover, the method includes filtering each non-compliant merchant from the list of non-compliant merchants based, at least in part, on comparing the determined merchant category and the secondary merchant category. The method includes generating a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants. The method further includes transmitting the filtered non-compliance report to one of a plurality of acquirers and a plurality of issuers.

BRIEF DESCRIPTION OF THE FIGURES
For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
FIG. 1 illustrates an exemplary representation of an environment related to at least some example embodiments of the present disclosure;
FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
FIG. 3 illustrates a block diagram representation of a process flow through a categorization model and an optimization model, in accordance with an embodiment of the present disclosure;
FIGS. 4A, 4B, and 4C, collectively illustrate a schematic representation of the iterative process performed by the categorization model on a graph, in accordance with an embodiment of the present disclosure;
FIG. 5 illustrates a schematic representation of a process flow of filtering the list of non-compliant merchants, in accordance with an embodiment of the present disclosure;
FIG. 6 illustrates a process flow diagram depicting a method for identifying non-compliant merchants, in accordance with the present disclosure;
FIG. 7 illustrates a process flow diagram depicting a method for determining a merchant category of each of the plurality of unlabeled merchants via a categorization model, in accordance with an embodiment of the present disclosure;
FIG. 8 illustrates a process flow diagram depicting a method for generating a filtered non-compliance report, in accordance with an embodiment of the present disclosure;
FIG. 9 illustrates a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
FIG. 10 illustrates a simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure; and
FIG. 11 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.
Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification is not necessarily all refer to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
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 entirely hardware embodiment, an entirely 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”, “buyer”, and “customer” are used interchangeably throughout the description and refer to a person who has a payment account or a payment card (e.g., credit card, debit card, etc.) associated with the payment account, that will be used by a merchant to perform a payment transaction. The payment account may be opened via an issuing bank or an issuer server.
The term “merchant”, used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same entity.
The terms “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 an online payment. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash substitutes that may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as Mastercard®.
The term “payment card”, used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in the form of data stored in a user device, where the data is associated with a payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
The term “payment account”, used throughout the description refers to a financial account that is used to fund a financial transaction. Examples of the financial account include, but are not limited to a savings account, a credit account, a checking account, and a virtual payment account. The financial account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, the financial account may be a virtual or temporary payment account that can be mapped or linked to a primary financial account, such as those accounts managed by payment wallet service providers, and the like.
The terms “payment transaction”, “financial transaction”, “event”, and “transaction” are used interchangeably throughout the description and refer to a transaction of payment of a certain amount being initiated by the cardholder. More specifically, refers to electronic financial transactions including, for example, online payment, payment at a terminal (e.g., point of sale (POS) terminal), and the like. Generally, a payment transaction is performed between two entities, such as a buyer and a seller. It is to be noted that a payment transaction is followed by a payment transfer of a transaction amount (i.e., monetary value) from one entity (e.g., issuing bank associated with the buyer) to another entity (e.g., acquiring bank associated with the seller), in exchange of any goods or services.
The term “non-compliant merchant”, used throughout the description refers to a merchant that is a part of a payment network, failed to comply with rules and regulations made by one of a payment card issuer, a merchant service provider (MSP), an acquiring bank, etc. For example, merchants that are offering crypto services such as cryptocurrency trading, non-fungible token (NFT) trading, etc., without reporting about the same to the payment network are considered non-compliant merchants.
The term “known compliant merchant”, used throughout the description refers to a merchant that is a part of the payment network and is known to abide by the rules and regulations made by one of a payment card issuer, a merchant service provider (MSP), an acquiring bank, etc. Generally, such merchants are provided with a label of ‘known compliant merchant’ and this information is pre-stored in a database that is accessible to the payment network.

OVERVIEW
Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for identifying non-compliant merchants. In various embodiments, the present disclosure describes a server system for identifying non-compliant merchants. The server system includes a processor and a memory. Further, the server system is a payment server associated with a payment network. In an embodiment, the server system is configured to access a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system. Herein, the historical payment transaction dataset includes information related to a plurality of historical payment transactions and the known compliant merchant dataset includes information related to a plurality of known compliant merchants.
In another embodiment, the server system is configured to determine a plurality of relevant cardholders involved in payment transactions at the plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset. In another embodiment, the server system is configured to determine and extract a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions has been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants.
In another embodiment, the server system is configured to determine via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions. In particular, the categorization model is configured to iteratively perform a plurality of operations till the performance of the categorization model converges. In an example, the categorization model is a graph label propagation machine learning model and the categorization model converges when a particular node has the same assigned merchant category label as one or more neighbor nodes of the particular node.
It is noted that in an embodiment, the plurality of operations include at first, generating a graph including a first set of nodes and a second set of nodes connected via one or more edges. Herein, the first set of nodes corresponds to one or more payment cards associated with the plurality of relevant cardholders, the second set of nodes corresponds to the plurality of unlabeled merchants, the one or more edges correspond to the subset of relevant transactions performed between the first set of nodes and the second set of nodes connected by the one or more edges. Then, the plurality of operations includes generating a weight value for each of the second set of nodes based, at least in part, on the graph. Herein, the weight value corresponds to a probability of a merchant from the plurality of unlabeled merchants being the same merchant category as a merchant category of a known compliant merchant from the plurality of known compliant merchants. In an example, the graph includes a merchant-card bipartite graph. Then, the plurality of operations includes assigning a merchant category label to each node in the second set of nodes based, at least, on the generated weight value and the known compliant merchant dataset. This further includes assigning the merchant category label to each node in the second set of nodes based, at least in part, on determining that the generated weight value is greater than and equal to a predefined threshold. Further, the plurality of operations includes back-propagating the assigned merchant category labels to the first set of nodes from the second set of nodes.
In another embodiment, the server system is configured to label each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants. In another embodiment, the server system is configured to generate a non-compliance report including a list of non-compliant merchants.
In another embodiment, the server system is configured to determine a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset. In another embodiment, the server system is configured to determine a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name. In another embodiment, the server system is configured to determine one or more keywords associated with each webpage of the website associated with each non-compliant merchant based, at least in part, on the URL of the website. In another embodiment, the server system is configured to determine via an optimization model, a secondary merchant category based, at least in part, on the one or more keywords. In an example, the optimization model is a Natural Language Processing (NLP) machine learning model. Further, determining the secondary merchant category includes at first, determining a context of the website based, at least in part, on the one or more keywords and then, determining the secondary merchant category based, at least in part, on the context of the website.
In another embodiment, the server system is configured to filter each non-compliant merchant from the list of non-compliant merchants based, at least in part, on comparing the determined merchant category and the secondary merchant category. In another embodiment, the server system is configured to generate a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants. In another embodiment, the server system is configured to transmit a filtered non-compliance report to one of a plurality of acquirers and a plurality of issuers.
Various embodiments of the present disclosure provide multiple advantages and technical effects while addressing technical problems such as how to identify non-compliant merchants. To that end, the various embodiments of the present disclosure provide an approach for identifying compliant and non-compliant merchants among other technical effects. For instance, the present disclosure is intended to identify non-compliant merchants with more precise results compared to conventional methods. Conventional methods focused on a limited set of data such as time-based variables. However, the present disclosure focuses on a larger dataset compared to conventional methods. This makes the present disclosure more efficient, more accurate, and more reliable. Therefore, results obtained from the present disclosure provide more precise results as compared to the conventional methods. Also, the implementation of the methods and systems proposed in the present disclosure reduces complexity and does not involve the execution of complex algorithms.
In addition, relying on the plurality of relevant cardholders to extract relevant transactions and then, determining the merchant categories of a merchant using these relevant transactions reduces the processing resources required by the categorization model to identifying the category of a merchant. Further, the filtration process described for generating the filtered non-compliance report helps to reduce false positives or incorrect results in the non-compliance report. This process further optimizes the merchant identification process. Furthermore, the merchant identification approach described herein is computationally efficient and can easily be incorporated into the payment network.
Various embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 11.
FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, determining, if a declared merchant category of a merchant is correct or incorrect, determining if a merchant from a plurality of merchants is compliant or not, generating a list of non-compliant merchants, informing relevant entities of the compliant status of the merchant by sharing the list of non-compliant merchants, and the like.
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) (collectively, referred to as a plurality of cardholders 104 and ‘N’ is a Natural number), a plurality of merchants 106(1), 106(2), … 106(N) (collectively, referred to as a plurality of merchants 106 and ‘N’ is a Natural number), an acquirer server 108, an issuer server 110, and a payment network 112 including a payment server 114, each coupled to, and in communication with (and/or with access to) a network 116. The network 116 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts or users illustrated in FIG. 1, or any combination thereof.
Various entities in the environment 100 may connect to the network 116 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future communication protocols or any combination thereof. For example, the network 116 may include multiple different networks, such as a private network made accessible by the server system 102 and a public network (e.g., the Internet, etc.) through which the server system 102, the acquirer server 108, the issuer server 110, and the payment server 114 may communicate.
In an embodiment, the plurality of cardholders 104 use one or more payment cards 118(1), 118(2), … 118(N) (collectively, referred to hereinafter as a plurality of payment cards 118 and ‘N’ is a Natural number) respectively to make payment transactions. 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 110 (explained later) and may be provided a payment card (e.g., the payment card 118(1)) with financial or other account information encoded onto the payment card (e.g., the payment card 118(1)) such that the cardholder (i.e., the cardholder 104(1)) may use the payment card 118(1) to initiate and complete a payment transaction using a bank account at the issuing bank.
In an example, the plurality of 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. 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, Personal Digital Assistants (PDAs), voice-activated assistants, Virtual Reality (VR) devices, smartphones, and laptops.
The plurality of merchants 106 may include retail shops, restaurants, supermarkets or establishments, government and/or private agencies, or any such places equipped with POS terminals, where customers visit for performing the financial transaction in exchange for any goods and/or services or any financial transactions.
In one scenario, the plurality of cardholders 104 may use their corresponding payment accounts to conduct payment transactions with the plurality of merchants 106. Moreover, it may be noted that each of the plurality of cardholders 104 may use their corresponding plurality of payment cards 118 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 118(2) 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 118(3) 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 plurality of cardholders 104 is associated with the issuer server 110. In one embodiment, the issuer server is associated with a financial institution normally called an “issuer bank”, “issuing bank” or simply “issuer”, in which a cardholder (e.g., the cardholder 104a) 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 plurality of merchants 106 is associated with the acquirer server 108. In an embodiment, each merchant (e.g., the merchant 106(1)) is associated with an acquirer server (e.g., the acquirer server 108). In one embodiment, the acquirer server 108 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, merchants (e.g., the merchants 106), or institutions that own platforms that make either online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
As explained earlier, a merchant has to declare their merchant category to be compliant with the rules and regulations of an acquirer, an issuer, or a regulatory body. However, a fraudulent or negligent merchant may declare themselves as a different merchant category than their actual merchant categories due to different reasons. In various non-limiting examples, the different reasons may include avoiding higher fees from payment processors, avoiding taxes, money laundering, and the like. Therefore, it is the need of the hour, to determine whether the declared merchant category of any merchant is correct or incorrect. In other words, whether a merchant is compliant or non-compliant due to the status of their declared merchant category. Generally, analysts or a team of analysts are employed by a payment processor, an acquirer, or a government body to determine whether a merchant is compliant or not. However, this manual process is very time-consuming, labor-intensive, and expensive. Therefore, there exists a need for an approach for determining whether a merchant is compliant or non-compliant with the rules and regulations.
The above-mentioned technical problem among other problems is addressed by one or more embodiments implemented by the server system 102 of the present disclosure. In one embodiment, the server system 102 is configured to perform one or more of the operations described herein.
In one embodiment, the environment 100 may further include a database 120 coupled with the server system 102. In an example, the server system 102 coupled with the database 120 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 acquirer server 108 and the issuer server 110. The database 120 may be incorporated in the server system 102 or maybe an individual entity connected to the server system 102 or maybe a database stored in cloud storage. In one embodiment, the database 120 may store a categorization model 122, an optimization model 124, a historical payment transaction dataset 126, a known compliant merchant dataset 128, and the like.
In other various examples, the database 120 may also include multifarious data, for example, social media data, Know Your Customer (KYC) data, payment data, trade data, employee data, Anti Money Laundering (AML) data, market abuse data, Foreign Account Tax Compliance Act (FATCA) data, and fraudulent payment transaction data.
For instance, the database 120 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 120 stores the historical payment transaction dataset 126 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 120 provides a storage location for data and/or metadata obtained from various operations performed by the server system 102.
In an embodiment, the server system 102 is configured to access the historical payment transaction dataset 126 and the known compliant merchant dataset 128 from a database such as the database 120 associated with the server system 102. It is noted that the historical payment transaction dataset 126 includes information related to a plurality of historical payment transactions performed between the plurality of cardholders 104 and the plurality of merchants 106. The known compliant merchant dataset includes information related to a plurality of known compliant merchants (e.g., a merchant 106(4), a merchant 106(5), and a merchant 106(6)) (hereinafter alternatively also referred to as known compliant merchants 106(4)-106(6)). It is noted that the term ‘known compliant merchants 106(4)-106(6)’ refers to merchants that have already been analyzed and vetted previously by analysts or teams of analysts to be compliant. In other words, the declared merchant categories of such merchants have already been confirmed and thus, the compliance status of these merchants is known.
Then, the server system 102 is configured to determine a plurality of relevant cardholders (e.g., a cardholder 104(4), a cardholder 104(5), and a cardholder 104(6)) (hereinafter alternatively also referred to as relevant cardholders 104(4)-104(6)) involved in payment transactions at a plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset 126 and the known compliant merchant dataset 128. Thereafter, the server system 102 is configured to determine and extract a subset of relevant payment transactions from the historical payment transaction dataset 126. This is done based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders (e.g., a cardholder 104(4), a cardholder 104(5), and a cardholder 104(6)) (hereinafter alternatively also referred to as the relevant cardholders 104(4)-104(6)) at the plurality of known compliant merchants 106(4)-106(6) and a plurality of unlabeled merchants. In other words, these payment transactions have been performed by cardholders at these known merchants in the past.
Thereafter, the server system 102 is configured to determine a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions. In various non-limiting examples, one or more Artificial Intelligence (AI) or Machine Learning (ML) models for determining a merchant category of any merchant from the plurality of merchants 106. In a non-limiting example, the categorization model may be used for determining the merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions. The plurality of unlabeled merchants refers to a set of merchants for which the compliance status has not been determined. In other words, the plurality of unlabeled merchants is the set of merchants for which their disclosed merchant category has not been checked.
Thereafter, the server system 102 is configured to label each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants. Further, the server system 102 is configured to generate a non-compliance report including a list of merchants labeled as non-compliant.
In a non-limiting example, the server system 102 accesses the historical payment transaction dataset 126 and the known compliant merchant data 128 from the database 120 associated with the server system 102. For instance, the historical payment transaction dataset 126 includes a set of historical payment transactions performed by the cardholders 104.
In an example scenario, one or more merchants who are labeled to be non-compliant in the merchants 106(7)-106(9), could be compliant and wrongly labeled as being non-compliant. Thus, to validate the list of compliant and non-compliant merchants, the server system 102 may be further configured to determine a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset 126. It is understood that each and every merchant has registered with the acquirer or the regulatory bodies with a merchant DBA name. This information is generally included in the historical payment transaction dataset 126 since each transaction performed will include information related to the plurality of cardholders 104 and the plurality of merchants 106.
Then, the server system 102 is configured to determine a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name. In one example, a web scraping technique can be used to determine the URL of the website of a merchant.
Thereafter, the server system 102 is configured to determine one or more keywords associated with each webpage of the website associated with each non-compliant merchant based, at least in part, on the URL of the website. In one example, the web scraping technique can be used to extract keywords from each webpage of the website of a merchant. Further, the server system 102 is configured to determine a secondary merchant category based, at least in part, on the one or more keywords. In various non-limiting examples, one or more Artificial Intelligence (AI) or Machine Learning (ML) models are used for determining a secondary merchant category based, at least in part, on the one or more keywords. In a non-limiting example, the optimization model may be used for determining a secondary merchant category based, at least in part, on the one or more keywords.
Furthermore, each non-compliant merchant from the list of non-compliant merchants is filtered based, at least in part, on comparing the determined merchant category and the secondary merchant category. Then, a filtered non-compliance report is generated based, at least in part on, the list of filtered non-compliant merchants.
Lastly, the server system 102 may transmit at least one of the filtered non-compliance reports to acquirer servers associated with a plurality of acquirers or issuer servers associated with a plurality of issuers (not shown in Figures). Once the acquirers or issuers are notified about the non-compliant merchants, the acquirers or issuers may then take certain measures to make the payment network 112 more secure.
In one embodiment, the payment network 112 may be used by the payment card issuing authorities as a payment interchange network. Examples of the payment cards 118 include debit cards, credit cards, etc. Similarly, examples of payment interchange networks include but are not limited to, a Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of electronic payment transaction data between issuers and acquirers that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
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 116) 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.
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 116, which may be specifically configured, via executable instructions, to perform steps as described herein, and/or embodied in at least one non-transitory computer-readable media.
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, and a storage interface 212 that communicates with each other via a bus 214.
In some embodiments, the database 204 is integrated within the computer system 202. For example, the computer system 202 may include one or more hard disk drives as the database 204. A storage interface 212 is any component capable of providing the processor 206 with access to the database 204. The storage interface 212 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204. In one non-limiting example, the database 204 is configured to store a categorization model 216, an optimization model 218, a historical payment transaction dataset 220, a known compliant merchant dataset 222, and the like. It is noted that the categorization model 216, the optimization model 218, the historical payment transaction dataset 220, and the known compliant merchant dataset 222 are identical to the categorization model 122, the optimization model 124, the historical payment transaction dataset 126, and the known compliant merchant dataset 128 of FIG. 1.
The processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for determining, if a declared merchant category of a merchant is correct or incorrect. In other words, the processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for determining if a merchant from a plurality of merchants is compliant or not. 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 224 such as the acquirer server 108, the issuer server 110, the payment server 114, or communicating with any entity connected to the network 116 (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.
In one implementation, the processor 206 includes a data pre-processing module 226, a labeling module 228, a graph generation module 230, a filtration module 232, and a notification module 234. It should be noted that components, described herein, such as the data pre-processing module 226, the training module 228, the graph generation module 230, the filtration module 232, and the notification module 234 can be configured in a variety of ways, including electronic circuitries, digital arithmetic, and logic blocks, and memory systems in combination with software, firmware, and embedded technologies.
In an embodiment, the data pre-processing module 226 includes suitable logic and/or interfaces for accessing a historical payment transaction dataset 220 and a known compliant merchant dataset 222 from the database 204 associated with the server system200. In particular, the historical payment transaction dataset 220 includes information related to a plurality of historical payment transactions performed by the plurality of cardholders 104 with the plurality of merchants 106.
The set of historical payment transactions may be performed within a predetermined interval of time (e.g., 6 months, 12 months, 24 months, etc.). In an embodiment, the historical payment transaction dataset 220 includes information on both fraudulent and non-fraudulent payment transactions performed within the payment network 112.
In some non-limiting examples, the historical payment transaction dataset 220 includes 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, historical payment transaction dataset 220 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 220 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 220 may include information related to the acquirer server 108 such as the date of merchant registration with the acquirer server 108, amount of payment transactions performed at the acquirer server 108 in a day, number of payment transactions performed at the acquirer server 108 in a day, maximum transaction amount, minimum transaction amount, number of fraudulent merchants or non-fraudulent merchants registered with the acquirer server 108, and the like.
Similarly, in particular, the known compliant merchant dataset 222 may include data related to compliant merchants that are known by the payment network 112 to be compliant, details related to compliant merchants that indicate their compliant nature, and the like.
In some non-limiting examples, the known compliant merchant dataset 222 includes merchant name identifier, unique merchant identifier, compliant merchant DBA name, compliant disclosed merchant name, merchant category code (MCC), timestamp information, geo-location data, information related to payment instruments associated with the known compliant merchants, and the like. In one example, the known compliant merchant dataset 222 may define a relationship between a plurality of cardholders 104 or a plurality of cardholder accounts and a plurality of known compliant merchant accounts. For example, when a cardholder purchases an item from a known compliant merchant, a relationship is defined.
In an embodiment, the known compliant merchant dataset 222 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 another embodiment, the known compliant merchant dataset 222 may include information related to the acquirer server 108 such as the date of merchant registration with the acquirer server 108, amount of payment transactions performed at the acquirer server 108 in a day, number of payment transactions performed at the acquirer server 108 in a day, maximum transaction amount, minimum transaction amount, and the like.
In addition, the data pre-processing module 226 is configured to determine a plurality of relevant cardholders (e.g., the relevant cardholders 104(4)-104(6)) involved in payment transactions at a plurality of known compliant merchants (e.g., the compliant merchants 106(4)-106(6)) based, at least in part, on the historical payment transaction dataset 220 and the known compliant merchant dataset 222.
In an embodiment, for determining the relevant cardholders 104(4)-104(6), the data pre-processing module 226 initially, extracts a plurality of relevant payment transactions from the historical payment transaction dataset 220, based at least on payment transactions performed at the plurality of known compliant merchants (e.g., the compliant merchants 106(4)-106(6)). Further, the data pre-processing module 226 segregates the plurality of relevant cardholders (e.g., the relevant cardholders 104(4)-104(6)) from the plurality of cardholders 104 that are involved in the plurality of relevant payment transactions, based at least on the plurality of relevant payment transactions that are extracted.
Moreover, the data pre-processing module 226 is further configured to determine and extract a subset of relevant payment transactions from the historical payment transaction dataset 220 based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders (e.g., the relevant cardholders 104(4)-104(6)) at the plurality of known compliant merchants (e.g., the known compliant merchants 106(4)-106(6)) and a plurality of unlabeled merchants (e.g., the merchants 106(7)-106(9)).
In a non-limiting example embodiment, for the data pre-processing module 226 to extract the relevant payment transactions, the data pre-processing module 226 at first, may extract a plurality of relevant transaction details from the historical payment transaction dataset 220. The plurality of relevant transaction details is associated with one or more payment cards (e.g., the payment card 118(4)-118(6)) corresponding to the plurality of relevant cardholders (e.g., the relevant cardholders 104(4)-104(6)). For instance, the plurality of relevant transaction details may include past transactions performed at various merchants, names of merchants where the past transactions are performed, location of the merchants, a type of business owned by the merchants, a type of transaction allowed at the end of the merchants, a merchant category code (MCC) of each of the merchants, acquirer bank details, issuer bank details, etc.
Further, the data pre-processing module 226 may determine the subset of relevant payment transactions from the set of historical payment transactions that are performed by the plurality of relevant cardholders (e.g., the relevant cardholders 104(4)-104(6)) at the plurality of merchants (e.g., the merchants 106(7)-106(9)) based, at least in part, on the extracted plurality of relevant transaction details. In an embodiment, the data pre-processing module 226 then transmits the subset of relevant payment transactions to the labeling model 228.
The labeling module 228 includes suitable logic and/or interfaces for determining a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions. In one implementation, the labeling module 228 is configured to determine the merchant category using an AI or ML model. In one example, the determination is done using the categorization model 216. In one example, the categorization model 216 is a graph label propagation machine learning model. This aspect has been explained later in the present disclosure.
In another embodiment, the labeling module 228 is configured to label each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants.
In an implementation, the categorization model 216 is configured to perform a plurality of operations iteratively based, at least on, a graph-based label message-passing technique. In particular, at first, the labeling model 216 generates a graph via the graph generation module 230 (explained later). The graph includes a first set of nodes and a second set of nodes connected via one or more edges. Herein, the first set of nodes corresponds to one or more payment cards (e.g., the payment card 118(4)-118(6)) associated with the plurality of relevant cardholders (e.g., the relevant cardholders 104(4)-104(6)). Further, herein the second set of nodes corresponds to the plurality of unlabeled merchants (e.g., the merchants 106(7)-106(9)). Further, herein the one or more edges corresponds to the subset of relevant transactions performed between the first set of nodes and the second set of nodes connected by the one or more edges. This graph-based label message-passing technique is further explained in detail in further parts of the description with reference to FIGS. 3 and 4A-4C.
In an embodiment, the graph is generated with the graph generation module 230. It is noted that although the graph generation module 230 is shown as a separate module, the same can be implemented with the labeling module 228 as a sub-module as well. In an embodiment, the graph generation module 230 includes suitable logic and/or interfaces for facilitating the categorization model 216 to generate the graph. At first, the subset of relevant payment transactions received by the labeling module 228, is fed to the graph generation module 230. The graph generation module 232 determines one or more features required for the generation of the graph by analyzing the subset of relevant payment transactions. The one or more features may include one or more nodes and one or more edges connecting the one or more nodes. In a non-limiting example, the graph generation module 230 identifies the relevant cardholders 104(4)-104(6) that have made payment transactions with the merchants 106(7)-106(9) based at least on the subset of relevant payment transactions. More specifically, the relevant cardholders 104(4)-104(6) may use the one or more payment cards 118(4)-118(6) to make the corresponding payment transactions. Thus, the graph generation module 230 determines a first set of the one or more nodes as the one or more payment cards 117(4)-117(6) and a second set of the one or more nodes at the merchants 106(7)-106(9), with the one or more edges indicating the subset of the relevant payment transactions.
Upon determining the first set of nodes and the second set of nodes, the graph generation module 230 facilitates the categorization model 216 to generate the graph by connecting the first set of nodes and the second set of nodes connected with the one or more edges. Further, the categorization model 216 generates a weight value for each of the second set of nodes based, at least in part, on the graph. It is noted that the weight value in the categorization model 216 corresponds to a probability of a merchant from the plurality of unlabeled merchants being the same merchant category as a merchant category of a known compliant merchant from the plurality of known compliant merchants.
Thereafter, the categorization model 216 assigns a merchant category label to each node in the second set of nodes based, at least, on the generated weight value and the known compliant merchant dataset. In particular, the merchant category is assigned to the merchant based, at least in part, on determining that the generated weight value is greater than and equal to a predefined threshold. In a non-limiting example, the predetermined threshold may be 0.50. It is noted that the predetermined threshold may be configured by an administrator (not shown) of the server system 200. In one implementation, the merchant category may be assigned in the form of a Merchant Category Code (MCC). Further, the categorization model 216 back-propagates the assigned labels to the first set of nodes from the second set of nodes. This process repeats iteratively, and after every iteration, the weight value of each of the first set of nodes and the second set of nodes may be updated with a new value. As described earlier, this process can be repeated by the categorization model 216 till the performance of the categorization model 216 converges. The term ‘converge’ refers to a state where a particular node has the same assigned merchant category label as one or more neighbor nodes of the particular node.
In a non-limiting example, a node of the second set of nodes may be connected to a first predefined count of the first set of nodes, which means a merchant (e.g., the merchant 106(7)) of the merchants 106(7)-106(9) is receiving payment transactions from the first predefined count of the one or more payment cards 118(4)-118(6) associated with the relevant cardholders 104(4)-104(6). As the categorization model 216 processes further, weights are computed for each of the second set of nodes. It is noted when one or more parameters such as, but not limited to, a type of payment transaction that the merchants accept, a type of business the merchants are involved in, etc., with different nodes, are similar, then similar weights are computed for them. Then, merchant category labels are generated for each node in the second set of nodes. As may be understood, the generated weight value of the second set of nodes attached with the same nodes from the first set of nodes that are closer to each other represents merchants that are closer to each other in their relationship with one or more payment cards. Therefore, these nodes from the set of second nodes can be assigned similar merchant category labels. Since nodes of the plurality of known compliant merchants are also connected to the same payment card, the merchant category of the known compliant merchant can be assigned as the merchant category label of the unlabeled merchants.
Further, as the weights associated with nodes with the merchant category labels are propagated thus, the weights are calculated again. In each iteration, the newly generated weights for nodes corresponding to different merchant categories will come close within the graph in proximity. In other words, in the vector space, the nodes with similar merchant categories will become closer in proximity within the vector space. Upon the convergence of the categorization model 216, there exists a high probability that merchants with the same category labels are gathered together. Now, since previously unlabeled merchants now have merchant category labels assigned to them. In other words, a merchant category for the plurality of unlabeled merchants has been determined.
Now, the labeling module 228 can compare the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants to determine if they are the same or not. Upon comparing, if it is determined that the an unlabeled merchant from the plurality of unlabeled merchants has the same determined merchant category as the declared merchant category at the time of registration with the acquirer or payment network 112, then that unlabeled merchant is labeled as compliant. On the other hand, the unlabeled merchant is labeled as non-compliant.
In another embodiment, the labeling module 228 is configured to generate a non-compliance report including a list of merchants labeled as non-compliant. In particular, information of each merchant of the plurality of unlabeled merchants that is labeled as non-compliant due to their declared merchant category being different from the determined merchant category is added to the non-compliance report as a list. In another embodiment, the labeling module 228 is communicably coupled to the filtration module 232.
The filtration module 232 includes suitable logic and/or interfaces for determining a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset 220. Then, filtration module 232 is configured to determine a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name. In an example, web scraping techniques can be used to search the world wide web or the Internet to find a website associated with a name, i.e., the same or similar to the merchant DBA name. Upon finding suitable results, the URL for the website may be accessed or determined.
Further, one or more keywords associated with each webpage of the website associated with each non-compliant merchant are determined based, at least in part, on the URL of the website. As described earlier, similar web scraping techniques can be used to search each webpage of the website to determine the keywords present in it. Further, the filtration module 232 is configured to determine a secondary merchant category based, at least in part, on the one or more keywords. In various implementations, AI or ML models be used by the filtration module 232 to analyze the one or more keywords. In a particular implementation, the optimization model 218 is used by the filtration module 232 to analyze the one or more keywords for determining the secondary merchant category. In a non-limiting example, the optimization model is a Natural Language Processing (NLP) machine learning model.
In particular, the optimization model 218 is configured to determine a context of the website based, at least in part, on the one or more keywords. Then, the optimization model 218 is configured to determine the secondary merchant category based, at least in part, on the context of the website.
In addition, the filtration model 232 is configured to filter each non-compliant merchant from the list of non-compliant merchants based, at least in part, on comparing the determined merchant category and the secondary merchant category. In particular, the non-compliant merchant for which the secondary merchant category and the determined merchant category are not the same, their information is removed from the list of non-compliant merchants. Alternatively, if the determined merchant category and the secondary merchant category are identical, the non-compliant merchant is retained in the list of non-compliant merchants.
Upon filtering out the merchants that have a difference in the determined merchant category and the secondary merchant category, the filtration model 232 is configured to generate a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants. In another embodiment, the filtration model 232 is communicably coupled with the notification module 234.
In an embodiment, the notification module 234 includes suitable logic and/or interfaces for transmitting the filtered non-compliance report to one of a plurality of acquirers and a plurality of issuers. Basically, either one or both of the plurality of acquirers and the plurality of issuers are notified about the non-compliant merchants, so that the plurality of acquirers and/or the plurality of issuers may take remedial actions. In another scenario, the notification module 234 is configured to transmit the filtered non-compliance report to one or more regulatory bodies.
FIG. 3 illustrates a block diagram representation 300 of a process of identifying the valid non-compliant merchants and notifying the same to the acquirers 302, in accordance with an embodiment of the present disclosure. Upon referring to FIG. 3, it may be noted that the data pre-processing module 226 receives the historical payment transaction dataset 220 and the known compliant merchant dataset 222 from the database 204 associated with the server system 200. Examples of the historical payment transaction dataset 220 and the known compliant merchant dataset 222 are explained earlier with reference to FIG. 2.
Further, based on the historical payment transaction dataset 220 and the known compliant merchant dataset 222, the data pre-processing module 226 determines relevant cardholders 104(4)-104(6) involved in payment transactions at the known compliant merchants 106(4)-106(6). In addition, the data pre-processing module 226 determines and extracts the subset of relevant payment transactions 304 from the plurality of historical payment transactions (stored in the data fields of the historical payment transaction dataset 222) based, at least in part, on determining that the subset of relevant payment transactions 304 have been performed by the relevant cardholders 104(4)-104(6) at the plurality of known compliant merchants 106(4)-106(6) and the plurality of unlabeled merchants 106(7)-106(9). This data is fed to the labeling model 228. Then, the labeling model 228 performs the operations of the graph generation module 230 and operates the categorization model -216 to label the plurality of unlabeled merchants 106(7)-106(9).
Referring to FIG. 3, the graph 306 includes the first set of nodes and the second set of nodes connected via the one or more edges. The first set of nodes are corresponding to relevant cards C1 and C2, and the second set of nodes are corresponding to the merchants M1, M2, and M3. The relevant cards C1 and C2 may be identical to the relevant cards 118(4) and 118(5), and the merchants M1, M2, and M3 are identical to the merchants 106(7), 106(8), and 106(9) of FIG. 1. The one or more edges correspond to the relevant transactions performed between the relevant cards C1 and C2, and the merchants M1-M3.
Further, the graph 306 also shows that the relevant cards C1 and C2 also being connected to known compliant merchants kCM1 and kCM2 and other merchants such as Mx (‘x’ being any natural number) without limiting the scope of the invention. The known compliant merchants, i.e., kCM1 and kCM2 may also be connected to other payment cards such as Cx (‘x’ being any natural number) without limiting the scope of the invention.
Upon generating the graph 306, the labeling model 216 processes the graph 306 and assigns merchant category labels to the merchants M1-M3 based on the category of the neighbor nodes that are assigned to the known compliant merchants, i.e., kCM1 and kCM2. Therefore, FIG. 3 also shows a labeled graph 308, in which the labeling of the merchants M1-M3 is shown in the form of a pattern. The weights are then back-propagated to the relevant cards C1 and C2. Then, these steps are repeated iteratively till the categorization model 216 converges.
It may be noted that the Label Propagation Algorithm (LPA) is a fast algorithm for finding communities (communities of the same merchant categories) in a graph (e.g., the graph 306). Here, the categorization model 216, in other words, when the model 216 converges, merchants belonging to the same merchant categories will be grouped together into the same clusters or communities. It is noted that the categorization model 216 detects these communities using the graph structure alone. This means that the LPA may be used as a semi-supervised way of finding communities with initial communities being pre-selected. The LPA works by propagating labels throughout the network and forming communities based on this process of label propagation.
The aim behind the algorithm is that a single label can quickly become dominant in a densely connected group of nodes, but it will have trouble crossing a sparsely connected region. This means that the labels will get trapped inside a densely connected community or cluster when the algorithm converges. It is noted that the merchants thus, clustered in the final iteration of the graph are considered part of the same community.
In a non-limiting example, the pseudo-code for implementing the operation of the categorization model 216 is given below:
Initialize each node of the graph with a unique label (an identifier);
Propagating the label through the network; and
At every iteration of propagation, updating the label of each node to the one that the maximum number of its neighbor nodes belong to.
Iteratively repeating steps 1 to 3 till the model converges

It is noted that the model 216 converges when each node has the majority labels of its neighbors. As labels propagate, densely connected groups of nodes quickly reach a consensus on a unique label. At the end of the propagation, only a few labels will remain and the remaining will disappear. Nodes that have the same label at convergence are to belong to the same community.
In the illustrated example, when the algorithm is applied, by considering crypto transactions being a type of transaction that the non-compliant merchants failed to report to the payment network 112, a hypothesis is assumed by the present disclosure. The hypothesis is that the cardholders 104 involved in the crypto transactions are likely to have some common merchants which are offering crypto services. If such common merchants which are not reporting any crypto transactions on the payment network 112 are determined, then they are likely to be non-compliant.
In a non-limiting example, the pseudo-code for determining labels for the merchants involved in crypto services is given below:
Initialize payment cards that are involved in crypto transactions as 1 and others as 0 in a bipartite graph (as shown in FIG. 4A-4C) of the merchants and the payment cards;
determine the initialized card labels to the merchants as per equation (1) (as explained with reference to FIG. 4A-4C); and
Back-propagate the weights of these labels back to the payment cards.
Iteratively repeat the process from steps 1-3 till the model converges.

Further, the labeling module 226 compares the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants to determine if the merchant is compliant or not. Upon determining that the merchant is not compliant, the merchant is added to a list of non-compliant merchants. Thereafter, the labeling module 226 generates a non-compliance report based on the list of non-compliant merchants. Then, the non-compliance report is fed to filtration module 232. In an alternative embodiment, the compliant merchants are added to a list of compliant merchants. Thereafter, the labeling module 226 generates a compliance report based on the list of compliant merchants.
The filtration module 232 determines the merchant DBA name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset and locates a URL associated with the website of the merchant using the merchant DBA name. Then, one or more keywords associated with each webpage of the website associated with each non-compliant merchant are determined. Thereafter, the one or more keywords are fed to the optimization model 218. The optimization model 218 is configured to determine a secondary merchant category. Thereafter, the secondary merchant category is compared with the determined merchant category of each of the merchants on the list of non-compliant merchants. Further, the list of non-compliant merchants is filtered based on this comparison to generate a list of filtered non-compliant merchants. For instance, if the comparison result is true, then the merchant is compliant otherwise, the merchant is indeed non-compliant. Further, a filtered non-compliance report is generated including the filtered list of non-compliant merchants. Alternatively, a filtered compliance report may also be generated including a filtered list of compliant merchants, in case the non-compliant merchants were mistakenly added to the compliant list of merchants. This and other aspects are explained further in detail in FIG. 5. Further, the notification module 234 transmits the filtered non-compliance report to the acquirers 302.
In a non-limiting example, the pseudo-code for implementing the operation of the optimization model 218 for filtering out merchants involved in crypto services is given below:
Generate a list of merchants that are involved in crypto activities;
Determine the URL of the website of each merchant in the list via a DBA name of each merchant;
Determine one or more keywords from the website based, at least on the URL;
Determine the secondary merchant category based on the optimization model 218 using the one or more keywords as labels.
Classify the merchants in the list as crypto or non-crypto merchant category based on the result of the optimization model.

FIGS. 4A, 4B, and 4C, collectively illustrate a schematic representation of the iterative process performed by the categorization model 216 on a graph 400, in accordance with an embodiment of the present disclosure.
To that end, FIG. 4A depicts the graph 400 generated by the graph generation module 230 of the server system 200. In an embodiment, the graph 400 is a merchant-card bipartite graph. It is noted that using a merchant-card bipartite graph for determining merchant category labels by the labeling model 228 leads to simple and quicker graph processing since the graph complexity is removed. As shown in FIG. 4A, the graph 400 includes a first set of nodes corresponding to one or more payment cards such as C1, C2, C3, … Cn (collectively, referred to as payment cards C1-Cn and ‘n’ is a Natural number), and a second set of nodes corresponding to a plurality of merchants such as M1, M2, M3, … Mm (collectively, referred to as merchants M1-Mm and ‘m’ is a Natural number). It is understood that the payment cards C1-Cn are substantially similar to the payment cards 118(1)-118(n) of FIG. 1, and the merchants M1-Mm are substantially similar to the merchants 106(1)-106(n) of FIG. 1. Further, the graph 400 also includes one or more edges 402(1), 402(2), … 402(p) (collectively, referred to as edges 402(1)-402(p) and ‘p’ is a Natural number) that are directed and connect the payment cards C1-Cn and the merchants M1-Mm with each other. In other words, the edges 402(1)-402(p) indicate a payment transaction that occurred between them.
In a non-limiting example, the payment cards C1-Cn are initialized with an initial weight value based on the type of transactions that the payment cards C1-Cn are involved in with the merchants M1-Mm. For instance, the initial weight value may be either ‘0’ or ‘1’. A payment card performing a relevant type of transaction may be referred to as a relevant payment card. It should be noted that the relevant type of transaction may refer to a type of transaction that directly indicates that the merchant accepting such type of transaction is a compliant merchant. In other words, the declared merchant categories of such merchants have already been confirmed. Further, the relevant transactions also include a transaction that has been performed by the same payment card (i.e., the same first node of the set of first nodes) with different unlabeled merchants. It is noted that a merchant is considered unlabeled when the compliance status (i.e., whether the declared merchant category is confirmed or not) has not been confirmed.
Therefore, in the illustrated example, the relevant payment cards (e.g., a payment card C3) may be initialized with the initial weight value of ‘1’, and the rest of the payment cards may be initialized with the initial weight value of ‘0’ as shown in FIG. 4A. However, in other embodiments, the relevant payment cards and the rest of the payment cards may be initialized with a different value, without limiting the scope of the invention.
FIG. 4B illustrates the operations during the first iteration of the graph 400 depicted in FIG. 4A during the operation of the categorization model 216. As depicted in FIG. 4B, the merchants M1-Mm are provided with a weight value each, which is updated based on the initial weight values of the payment cards C1-Cn. The weight value of each merchant M1-Mm may be referred to as a merchant weight value. Thus, after the first iteration, the initial weight value from the relevant payment cards is propagated to the merchants that are connected to the corresponding relevant payment cards via the one or more edges 402(1)-402(p). During the first iteration, the merchant weight value for the merchants M1-Mm may be updated as w1, w2, … wm based, at least on the initial weight value. Further, the merchant weight value w1-wm is obtained using the following equation (1):
Merchant weight value (w1-wm)= (Number of relevant payment cards)/(Total number of payment cards) …Eqn. 1
It is noted that the merchant weight values correspond to a probability of a merchant from the plurality of unlabeled merchants being the same merchant category as a merchant category of a known compliant merchant from the plurality of known compliant merchants.
For instance, suppose the number of relevant payment cards connecting the merchant m1 is 2, and the total number of payment cards of 10. Therefore, the merchant weight value w1 for the merchant M1 would be about 2/10 = 0.22, upon using the equation 1. Further, based on the merchant weight values and the known compliant merchant dataset, the merchants M1-Mm are assigned a merchant category label. It is noted that merchants with similar weights will indicate they may belong to the same merchant category. Therefore, by relying on the known compliant merchant dataset the declared merchant category (i.e., confirmed) to assign the merchant category label for the unlabeled merchants in its vicinity (i.e., having similar weights)
For instance, if the merchant weight value is greater than or equal to 0.5 for any of the merchants M1-Mm, then the corresponding merchants of the merchants M1-Mm may be labeled with the same merchant label. In an alternative instance, that is, when the merchant weight value is less than 0.5 then the corresponding merchants of the merchants M1-Mm may be labeled with another merchant label. It is noted that the process of computing weights can be iteratively repeated till an Nth step by back-propagating the calculated weights, where the model converges.
FIG. 4C illustrates the operations during a subsequent iteration of operation of the categorization model 216 on the graph 420 depicted in FIG. 4B. As depicted in the graph 430 of FIG. 4C, the labels assigned to the merchants M1-Mm are back-propagated to the payment cards C1-Cn. Prior to back-propagating, card weight values are updated using the merchant's weight values. As used herein, the term “card weight value” refers to a weight value associated with a payment card which indicates a probability that the corresponding payment card is making payment transactions with unlabeled merchants.
In a non-limiting example, in accordance with the present disclosure, the relevant payment card may be maintained with a card weight value that is the same as the initial weight value, which in the current scenario is ‘1’. However, in other embodiments, the relevant payment cards may be provided with a different value, without limiting the scope of the invention. Therefore, in the illustrated example, the payment card C3 is maintained with the initial weight value, that is, ‘1’.
Further, the rest of the payment cards may be provided with a card weight value that is updated based on the –back-propagation of the merchant weight values w1-wm. Also, for simplicity, the rest of the payment cards other than the relevant payment cards may be referred to as irrelevant payment cards, and hence the card weight value may be referred to as irrelevant card weight value. Furthermore, for determining the irrelevant card weight value, the following equation (2) may be used:
Irrelevant card weight value (w1^'-wm^' )= █(sum of merchant weight@values connected to@the irrelevant paymnet card)/(Total number of merchants) …Eqn. 2
For instance, when the merchants M1 and M3 are connected to the payment card C1, the irrelevant card weight value w1’ may be calculated using the equation (2). In such a scenario, the irrelevant card weight value w1’ may be (w1 + w3)/ m. Moreover, the iterations of the categorization model, i.e., a graph-based label propagation technique may be iteratively repeated on the graph 400 until the convergence of the graph-based label propagation technique. Upon convergence, a merchant category of each of the plurality of unlabeled merchants is determined. Further, this determined merchant category is compared with a declared merchant category of each of the plurality of unlabeled merchants. If the result of the comparison yields that the declared merchant category is false, then the merchant is labeled as a non-compliant merchant and added to a non-compliant merchant report. Otherwise, if the result of the comparison yields that the declared merchant category is true, then the merchant is labeled as a compliant merchant.
FIG. 5 illustrates a schematic representation of a process flow 500 for filtering the list of non-compliant merchants, in accordance with an embodiment of the present disclosure. In the illustrated example, a step of an overall process of implementing the graph-based label propagation technique via the categorization model 216 (as explained above with reference to FIGS. 2 and 4A-4C) is represented with a graph label propagation block 502 as shown in FIG. 5. Similarly, a step of determining the merchant DBA name 504 and the merchant website URL 506 (hereinafter interchangeably also referred as “merchant URL 506”) is represented by a block 508. Further, an output of the graph label propagation block 502 is given to the block 508 as shown in FIG. 5.
In a non-limiting example, the non-compliance report including the list of merchants labeled as non-compliant is fed to the block 508 as shown in FIG. 5. As may be understood, every machine learning model is prone to errors, therefore it is possible that few of the merchants may be incorrectly labeled as non-compliant. Therefore, the list of merchants labeled as non-compliant included in the non-compliance report has to be filtered to remove the incorrectly labeled merchants. Therefore, as discussed earlier, the server system 200 determines a merchant DBA name (see, 504) of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset. As used herein, the term “merchant doing business as name” or “merchant DBA name” refers to a business’s assumed, trade, or fictitious name. Generally, the merchant DBA name in comparison to a merchant legal name is usually a name customers see on a front door of a business, whereas the merchant legal name is what appears on the business’s tax documents. The merchant DBA name may be pre-stored in the database 204 as merchant data in data fields such as but not including ‘merchant DBA field’ within the historical payment transaction dataset 220. For instance, other than the merchant DBA name 504, the merchant data may also correspond to data fields such as merchant name identifier, unique merchant identifier, timestamp information, geo-location data, information related to payment transactions associated with the merchants, and the like.
Further, using the merchant DBA name 504, the server system 200 can obtain the merchant URL 506 associated with the website (e.g., merchant website 510) of the corresponding non-compliant merchants, by searching for the website using the web scrapping technique (e.g., web data scraping 512). As used herein, the term “web scraping” refers to a web searching technique that uses intelligent automation methods to scrape or search through thousands or millions of datasets in a smaller amount of time from websites present on the Internet. In an embodiment, the data obtained upon web scraping is unstructured in Hypertext Markup Language (HTML) format that can be converted into structured data in a dataset in the form of a spreadsheet within a database, so that it can be used for various applications. In another embodiment, the data obtained upon web scrapping is structured when scrapped from websites that have Application Programming Interface (API) which allows web scrapping to access their data in the structure format. For instance, websites like Google®, Twitter®, Facebook®, etc., have APIs that allow access to their data in a structured format.
In various non-limiting examples, web scrapping may be performed in a variety of different ways such as using online services, particular APIs, creating a code from scratch, or the like. Generally, web scrapping requires two elements, such as, a crawler and a scraper. The term “crawler” refers to an artificial intelligence (AI) algorithm that browses the web to search for the particular data required by following the links across the internet. On the other hand, the term “scraper” refers to a specific tool created to extract data from the website.
Further, upon the implementation of the web scrapping technique, initially, the server system 200 may receive the merchant URL 506. The server system 200 uses the merchant DBA name 504 and performs a search for an associated website URL to the merchant DBA name 504 using the web scrapping technique. Further, the server system 200 may load all the HTML code for the merchant website 510 and a more advanced scraper might even extract all Cascading Style Sheet (CSS) and JavaScript elements as well. Then the scraper obtains the required data from this HTML code and outputs this data in the format specified by the server system 200 or an administrator of the server system 200. Mostly, this is in the form of an Excel spreadsheet or a Comma-separated values (CSV) file, but the data can also be saved in other formats, such as a JavaScript Object Notation (JSON) file.
Furthermore, in a non-limiting example, the web scraping technique may be available in different types such as self-built web scraping, browser extension or software web scraping, and cloud or local web scraping. In the illustrated example, the web scraping technique is used for searching for the merchant website 510. However, in other examples, the web scrapping technique may be used for other purposes such as price monitoring, market research, News monitoring, sentiment analysis, email marketing, etc., without limiting the scope of the invention. Therefore, it is noted that one or more keywords associated with each webpage of the website accessed using the merchant URL associated with each non-compliant merchant can be determined using the described web scraping techniques
Upon determining the one or more keywords, the optimization model 514 is configured to determine a secondary merchant category based, at least in part, on the one or more keywords. It is understood that the optimization model 514 is an NLP model. In particular, the optimization model 514 determines a context of the website based, at least in part, on the one or more keywords. Then, the secondary merchant category based, at least in part, on the context of the website.
In one particular non-limiting implementation, the NLP model may be to a Robustly Optimized Bidirectional Encoder Representations from Transformers (BERT) Approach (Roberta) model. In a non-limiting example, the Roberta model shares a BERT model's architecture. More specifically, the Roberta model is a reimplementation of the BERT with some modifications to the key hyper-parameters and tiny embedding tweaks. It should be noted from the above explanation that, the Roberta model is a transformer-based language model that uses self-attention to process input sequences and generate contextualized representations of words in a sentence.
In the illustrated example, the optimization model 514 is configured to perform a plurality of operations. Moreover, specifically, the optimization model is trained to perform the plurality of operations based, at least on the NLP technique. The optimization model may determine a context of the website (e.g., merchant website 510) by analyzing the one or more keywords from the website URL (e.g., merchant URL 506) using the NLP model. As used herein, the term “natural language processing” refers to an interdisciplinary subfield of linguistics, computer science, and AI concerned with the interactions between computers and human language, in particular how to program computers to process and analyze large amounts of natural language data.
In a non-limiting example, the context may include a plurality of important keywords that are used as labels by the server system 200 for training the optimization model 514. Then, upon determining the secondary merchant, the server system 200 compares the determined merchant category and the secondary merchant category to determine if any of the merchants have been incorrectly labeled as non-compliant within the list of non-compliant merchants. Thereafter, the server system 200 generates a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants. Furthermore, the server system 200 may transmit the filtered non-compliance report to a plurality of acquirers, the plurality of issuers, or regulatory bodies.
Further, in a non-limiting example, the server system 200 may transmit at least one of the list of non-compliant merchants and the filtered list of non-compliant merchants to the plurality of acquirers or the plurality of issuers, so that the plurality of acquirers/issuers can make sure that the payment network 112 is secure for both the merchants 106 and the cardholders 104.
FIG. 6 illustrates a process flow diagram depicting a method 600 for identifying non-compliant merchants, in accordance with an embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 600, and combinations of operations in the method 600 may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions. The plurality of operations is depicted in the process flow of the method 600. The process flow starts at operation 602.
At 602, the method 600 includes accessing, by a server system, a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system. The historical payment transaction dataset includes information related to a plurality of historical payment transactions and the known compliant merchant dataset includes information related to a plurality of known compliant merchants.
At 604, the method 600 includes determining, by the server system, a plurality of relevant cardholders involved in payment transactions at a plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset.
At 606, the method 600 includes determining and extracting, by the server system, a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants.
At 608, the method 600 includes determining, by the server system via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions.
At 610, the method 600 includes labeling, by the server system, each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants.
At 612, the method 600 includes generating, by the server system, a non-compliance report including a list of non-compliant merchants.
FIG. 7 illustrates a process flow diagram depicting a method 700 for determining a merchant category of each of the plurality of unlabeled merchants via the categorization model, in accordance with an embodiment of the present disclosure. The method 700 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 700 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 700, and combinations of operations in the method 700 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 700. The process flow starts at operation 702.
At 702, the method 700 includes generating, by a server system, a graph including a first set of nodes and a second set of nodes connected via one or more edges. The first set of nodes corresponds to one or more payment cards associated with the plurality of relevant cardholders. The second set of nodes corresponds to the plurality of unlabeled merchants. The one or more edges corresponds to the subset of relevant transactions performed between the first set of nodes and the second set of nodes connected by the one or more edges.
At 704, the method 700 includes generating, by the server system, a weight value for each of the second set of nodes based, at least in part, on the graph. The weight value corresponds to a probability of a merchant from the plurality of unlabeled merchants being the same merchant category as a merchant category of a known compliant merchant from the plurality of known compliant merchants.
At 706, the method 700 includes assigning, by the server system, a merchant category label to each node in the second set of nodes based, at least, on the generated weight value and the known compliant merchant dataset.
At 708, the method 700 includes back-propagating, by the server system, the assigned merchant category labels to the first set of nodes from the second set of nodes.
It is noted that the operations 702-708 can be iteratively repeated till the categorization model 216 converges. As may be understood, the categorization model 216 converges when a particular node has the same assigned merchant category label as one or more neighbor nodes of the particular node.
FIG. 8 illustrates a process flow diagram depicting a method 600 for generating a filtered non-compliance report, in accordance with an embodiment of the present disclosure. The method 800 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 800 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 800, and combinations of operations in the method 800 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 800. The process flow starts at operation 802.
At 802, the method 800 includes determining, by the server system, a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset.
At 804, the method 800 includes determining, by the server system, a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name.
At 806, the method 800 includes determining, by the server system, one or more keywords associated with each webpage of the website associated with each non-compliant merchant based, at least in part, on the URL of the website.
At 808, the method 800 includes determining, by the server system via an optimization model, a secondary merchant category based, at least in part, on the one or more keywords.
At 810, the method 800 includes filtering, by the server system, each non-compliant merchant from the list of non-compliant merchants based, at least in part, on comparing the determined merchant category and the secondary merchant category.
At 812, the method 800 includes generating, by the server system, a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants.
At 814, the method 800 includes transmitting, by the server system, the filtered non-compliance report to one of a plurality of acquirers and a plurality of issuers.
FIG. 9 illustrates a simplified block diagram of the acquirer server 900, in accordance with an embodiment of the present disclosure. The acquirer server 900 is an example of the acquirer server 108 of FIG. 1. The acquirer server 900 is associated with an acquirer bank/acquirer, in which a merchant may have an account, which provides a payment card. The acquirer server 900 includes a processing module 902 operatively coupled to a storage module 904 and a communication module 906. The components of the acquirer server 900 provided herein may not be exhaustive and the acquirer server 900 may include more or fewer components than those depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
The storage module 904 is configured to store machine-executable instructions to be accessed by the processing module 902. Additionally, the storage module 904 stores information related to, 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 904 is configured to store payment transactions.
In one embodiment, the acquirer server 900 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 908. 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 902 is configured to communicate with one or more remote devices such as a remote device 910 using the communication module 906 over a network such as the network 116 of FIG. 1. The examples of the remote device 910 include the server system 102, the payment server 114, the issuer server 110, or other computing systems of the acquirer server 900, and the like. The communication module 906 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 906 is configured to receive a payment transaction request performed by the cardholders 104 via the network 116. The processing module 902 receives payment card information, a payment transaction amount, customer information, and merchant information from the remote device 910 (i.e., the payment server 114). The acquirer server 900 includes a user profile database 912 and the transaction database 908 for storing transaction data. The user profile database 912 may include information of cardholders. 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 days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction.
FIG. 10 illustrates a simplified block diagram of the issuer server 1020, in accordance with an embodiment of the present disclosure. The issuer server 1020 is an example of the issuer server 110 of FIG. 1. The issuer server 1020 is associated with an issuer bank/issuer, in which an account holder (e.g., the plurality of cardholders 104(1)-104(N)) may have an account, which provides a payment card (e.g., the payment cards 118(1)-118(N)). The issuer server 1020 includes a processing module 1022 operatively coupled to a storage module 1024 and a communication module 1026. The components of the issuer server 1020 provided herein may not be exhaustive and the issuer server 1020 may include more or fewer components than those depicted in FIG. 10. 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 1020 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
The storage module 1024 is configured to store machine-executable instructions to be accessed by the processing module 1022. Additionally, the storage module 1024 stores information related to, contact information of the cardholders (e.g., the plurality of 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 1024 is configured to store payment transactions.
In one embodiment, the issuer server 1020 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholders, account identification information, payment card number, etc.) in a database. The details of the cardholders 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, etc.
The processing module 1022 is configured to communicate with one or more remote devices such as a remote device 1028 using the communication module 1026 over a network such as the network 116 of FIG. 1. Examples of the remote device 1028 include the server system 200, the payment server 114, the acquirer server 108 or other computing systems of the issuer server 1020. The communication module 1026 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 1026 is configured to receive a payment transaction request performed by an account holder (e.g., the cardholder 104(1)) via the network 116. The processing module 1022 receives payment card information, a payment transaction amount, customer information, and merchant information from the remote device 1028 (e.g., the payment server 114). The issuer server 1020 includes a transaction database 1030 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 machine, 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 1020 includes a user profile database 1032 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 plurality of 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.
FIG. 11 illustrates a simplified block diagram of the payment server 1150, in accordance with an embodiment of the present disclosure. The payment server 1150 is an example of the payment server 114 of FIG. 1. The payment server 1150 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 1150 includes a processing module 1152 configured to extract programming instructions from a memory 1154 to provide various features of the present disclosure. The components of the payment server 1150 provided herein may not be exhaustive and the payment server 1150 may include more or fewer components than that depicted in FIG. 11. 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 1150 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
Via a communication module 1156, the processing module 1152 receives a request from a remote device 1158, such as the issuer server 110, the acquirer server 108, 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 1150 includes a database 1160. The database 1160 also includes transaction processing data such as issuer ID, country code, acquirer ID, and merchant identifier (MID), among others.
When the payment server 1150 receives a payment transaction request from the acquirer server 108 or a payment terminal (e.g., IoT device), the payment server 1150 may route the payment transaction request to an issuer server (e.g., the issuer server 110). The database 1160 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 server 108 is configured to send an authorization request message to the payment server 1150. The authorization request message includes, but is not limited to, the payment transaction request.
The processing module 1152 further sends the payment transaction request to the issuer server 110 for facilitating the payment transactions from the remote device 1158. The processing module 1152 is further configured to notify the remote device 1158 of the transaction status in form of an authorization response message via the communication module 1156. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 110. Alternatively, in one embodiment, the processing module 1152 is configured to send an authorization response message for declining the payment transaction request, via the communication module 1156, to the acquirer server 108. In one embodiment, the processing module 1152 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. 6-8, 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 spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software, and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
Particularly, the server system 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 than those which, are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:1. A computer-implemented method, comprising:
accessing, by a server system, a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system, the historical payment transaction dataset comprising information related to a plurality of historical payment transactions and the known compliant merchant dataset comprising information related to a plurality of known compliant merchants;
determining, by the server system, a plurality of relevant cardholders involved in payment transactions at the plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset;
determining and extracting, by the server system, a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants;
determining, by the server system via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions;
labeling, by the server system, each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants; and
generating, by the server system, a non-compliance report comprising a list of non-compliant merchants.
2. The computer-implemented method as claimed in claim 1, wherein the categorization model is configured to iteratively perform a plurality of operations till performance of the categorization model converges, the plurality of operations comprising:
generating, by the server system, a graph comprising a first set of nodes and a second set of nodes connected via one or more edges, the first set of nodes corresponding to one or more payment cards associated with the plurality of relevant cardholders, the second set of nodes corresponding to the plurality of unlabeled merchants, the one or more edges corresponding to the subset of relevant transactions performed between the first set of nodes and the second set of nodes connected by the one or more edges;
generating, by the server system, a weight value for each of the second set of nodes based, at least in part, on the graph, the weight value corresponding to a probability of a merchant from the plurality of unlabeled merchants being the same merchant category as a merchant category of a known compliant merchant from the plurality of known compliant merchants;
assigning, by the server system, a merchant category label to each node in the second set of nodes based, at least, on the generated weight value and the known compliant merchant dataset; and
back-propagating, by the server system, the assigned merchant category labels to the first set of nodes from the second set of nodes.
3. The computer-implemented method as claimed in claim 2, wherein assigning the merchant category label to each node in the second set of nodes further comprises:
assigning, by the server system, the merchant category label to each node in the second set of nodes based, at least in part, on determining that the generated weight value is greater than and equal to a predefined threshold.
4. The computer-implemented method as claimed in claim 2, wherein the categorization model converges when a particular node has the same assigned merchant category label as one or more neighbor nodes of the particular node.
5. The computer-implemented method as claimed in claim 2, wherein the graph comprises a merchant-card bipartite graph.
6. The computer-implemented method as claimed in claim 1, wherein the categorization model is a graph label propagation machine learning model.
7. The computer-implemented method as claimed in claim 1, further comprising:
determining, by the server system, a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset;
determining, by the server system, a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name;
determining, by the server system, one or more keywords associated with each webpage of the website associated with each non-compliant merchant based, at least in part, on the URL of the website;
determining, by the server system via an optimization model, a secondary merchant category based, at least in part, on the one or more keywords;
filtering, by the server system, each non-compliant merchant from the list of non-compliant merchants based, at least in part, on comparing the determined merchant category and the secondary merchant category; and
generating, by the server system, a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants.
8. The computer-implemented method as claimed in claim 7, wherein determining the secondary merchant category further comprises:
determining, by the server system, a context of the website based, at least in part, on the one or more keywords; and
determining, by the server system, the secondary merchant category based, at least in part, on the context of the website.
9. The computer-implemented method as claimed in claim 1, wherein the optimization model is a Natural Language Processing (NLP) machine learning model.
10. The computer-implemented method as claimed in claim 1, further comprising: transmitting, by the server system, a filtered non-compliance report to one of a plurality of acquirers and a plurality of issuers.
11. The computer-implemented method as claimed in claim 1, wherein the server system is a payment server associated with a payment network.
12. A server system, comprising:
a memory configured to store instructions;
a communication interface; and
a processor in communication with the memory and the communication interface, the processor configured to execute the instructions stored in the memory and thereby cause the server system to perform at least in part to:
access a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system, the historical payment transaction dataset comprising information related to a plurality of historical payment transactions and the known compliant merchant dataset comprising information related to a plurality of known compliant merchants;
determine a plurality of relevant cardholders involved in payment transactions at the plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset;
determine and extract a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants;
determine, via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions;
label each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants; and
generate a non-compliance report comprising a list of non-compliant merchants.
13. The server system as claimed in claim 12, wherein the categorization model caused the server system to iteratively perform a plurality of operations till performance of the categorization model converges, the plurality of operations comprising:
generating a graph comprising a first set of nodes and a second set of nodes connected via one or more edges, the first set of nodes corresponding to one or more payment cards associated with the plurality of relevant cardholders, the second set of nodes corresponding to the plurality of unlabeled merchants, the one or more edges corresponding to the subset of relevant transactions performed between the first set of nodes and the second set of nodes connected by the one or more edges;
generating a weight value for each of the second set of nodes based, at least in part, on the graph, the weight value corresponding to a probability of a merchant from the plurality of unlabeled merchants being the same merchant category as a merchant category of a known compliant merchant from the plurality of known compliant merchants;
assigning a merchant category label to each node in the second set of nodes based, at least, on the generated weight value and the known compliant merchant dataset; and
back-propagating the assigned merchant category labels to the first set of nodes from the second set of nodes.
14. The server system as claimed in claim 13, wherein the server system is further caused, at least in part, to assign the merchant category label to each node in the second set of nodes based, at least in part, on determining that the generated weight value is greater than and equal to a predefined threshold.
15. The server system as claimed in claim 13, wherein the categorization model converges when a particular node has the same assigned merchant category label as one or more neighbor nodes of the particular node, wherein the categorization model is a graph label propagation machine learning model, wherein the graph comprises a merchant-card bipartite graph.
16. The server system as claimed in claim 13, wherein the server system is further caused, at least in part, to:
determine a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset;
determine a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name;
determine one or more keywords associated with each webpage of the website associated with each non-compliant merchant based, at least in part, on the URL of the website;
determine, via an optimization model, a secondary merchant category based, at least in part, on the one or more keywords;
filter each non-compliant merchant from the list of non-compliant merchants based, at least in part, on comparing the determined merchant category and the secondary merchant category; and
generate a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants.
17. The server system as claimed in claim 16, wherein the server system is further caused, at least in part, to determine the secondary merchant category by:
determining a context of the website based, at least in part, on the one or more keywords; and
determining the secondary merchant category based, at least in part, on the context of the website.
18. The server system as claimed in claim 12, wherein the optimization model is a Natural Language Processing (NLP) machine learning model.
19. The server system as claimed in claim 12, wherein the server system is further caused, at least in part, to transmit a filtered non-compliance report to one of a plurality of acquirers and a plurality of issuers.
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:
accessing a historical payment transaction dataset and a known compliant merchant dataset from a database associated with the server system, the historical payment transaction dataset comprising information related to a plurality of historical payment transactions and the known compliant merchant dataset comprising information related to a plurality of known compliant merchants;
determining a plurality of relevant cardholders involved in payment transactions at the plurality of known compliant merchants based, at least in part, on the historical payment transaction dataset and the known compliant merchant dataset;
determining and extracting a subset of relevant payment transactions from the historical payment transaction dataset based, at least in part, on determining that the subset of relevant payment transactions have been performed by the plurality of relevant cardholders at the plurality of known compliant merchants and a plurality of unlabeled merchants;
determining, via a categorization model, a merchant category of each of the plurality of unlabeled merchants based, at least in part, on the subset of relevant payment transactions;
labeling each of the plurality of unlabeled merchants as one of a compliant merchant and a non-compliant merchant based, at least in part, on comparing the determined merchant category and a declared merchant category of each of the plurality of unlabeled merchants;
generating a non-compliance report comprising a list of non-compliant merchants;
determining a merchant Doing Business As (DBA) name of each non-compliant merchant from the list of non-compliant merchants based, at least in part, on the historical payment transaction dataset;
determining a Universal Resource Locator (URL) of a website associated with each non-compliant merchant from the list of non-compliant merchants based, at least, on the merchant DBA name;
determining one or more keywords associated with each webpage of the website associated with each non-compliant merchant based, at least in part, on the URL of the website;
determining via an optimization model, a secondary merchant category based, at least in part, on the one or more keywords;
filtering each non-compliant merchant from the list of non-compliant merchants based, at least in part, on comparing the determined merchant category and the secondary merchant category;
generating a filtered non-compliance report based, at least in part on, the list of filtered non-compliant merchants; and
transmitting the filtered non-compliance report to one of a plurality of acquirers and a plurality of issuers.