Description: The present disclosure relates to artificial intelligence-based processing systems in a financial domain and, more particularly, to electronic methods and complex processing systems for detecting and reporting anomalous transaction patterns at anomalous Automated Teller Machines (ATMs).
BACKGROUND
With the evolution of technology, criminals have been using increasingly sophisticated money laundering techniques for laundering their money to keep it safe from the eyes of the law. As may be understood, the term ‘money laundering’ refers to the process of disguising the origins of illegally obtained funds, generally through criminal activities, so as to make it appear as if these funds came from legitimate sources. Money laundering is generally used by criminals to facilitate further criminal activities, therefore it is necessary to put a stop to it. Such criminal activities may include activities such as fraud, kidnapping, illegal poaching, human trafficking, terror financing, and the like. Typically, the process of money laundering constitutes of three stages, including placement, layering, and integration. Examples of money laundering techniques include Automated Teller Machine (ATM) money laundering, smurfing, currency exchanges, wire transfers, cash smuggling, counterfeiting, using shell companies, electronic money laundering, and the like.
In order to curb money laundering, various Anti-Money Laundering (AML) techniques and regulations have been developed or mandated by different financial institutions and government regulators. One such popular AML technique includes a rule-based approach for detecting money laundering activities. In this technique, if a particular transaction or a cardholder violates one or more rules, then a risk alert is generated. This risk alert is later reviewed by an analyst or a team of analysts to determine whether the flagged transaction or cardholder is actually involved in the money laundering activity or not. However, as would be readily apparent, reviewing such alerts manually is a complex and cumbersome task that generally requires analysts to navigate a large network of financial interactions between various entities within the payment network to validate anomalous movements. Furthermore, it has also been observed that this technique is often associated with very high false positive rates as well.
Another conventional technique includes using Artificial Intelligence (AI) or Machine Learning (ML) based models for analyzing historical transactions within the payment network to generate risk alerts. In such techniques, the AI or ML model is trained to analyze the transactions associated with a cardholder. Further, the AI or ML model is generally configured to determine if the transactions performed by any cardholder violate one or more rules of the financial institution operating the model and if so, raise an alert flag. Once, an alert is generated for a transaction, such transactions can be reported to a concerned entity. However, as may be understood, this rule-based approach is rigid in nature and is unable to adapt to a change in market conditions (such as government regulations) among other issues. Further, since there is a general lack of labeled data for training such models, the overall accuracy of such models is not good as well. Most importantly, such models are trained for a generic set of transactions and thus, display extremely poor performance when determining if any money laundering activity is related to any ATM within a particular region.
It should be noted that ATM-related money laundering activities have been on the rise in recent times. Further, the conventional techniques described earlier generally fail to predict ATM-related money laundering activities since the transaction patterns at ATM’s are quite complex and unique. In other words, anomalous transaction patterns associated with ATM-related money laundering are very distinct from the other forms of money laundering.
Thus, there exists a technological need for technical solutions for detecting and reporting anomalous transaction patterns at anomalous Automated Teller Machines (ATMs).
SUMMARY
Various embodiments of the present disclosure provide methods and systems for detecting and reporting anomalous transaction patterns at anomalous Automated Teller Machines (ATMs).
In an embodiment, a computer-implemented for detecting anomalous transaction patterns at anomalous ATMs is disclosed. The computer-implemented method performed by a server system includes accessing anomalous card data from a database associated with the server system. The anomalous card data includes information related to historical transactions performed within a specific region via a set of anomalous cards at a plurality of ATMs. The computer-implemented method further includes generating an Automatic Teller Machine (ATM)-anomalous card correlation dataset based, at least in part, on the anomalous card data. The computer-implemented method includes generating a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs based, at least in part, on the ATM-anomalous card correlation dataset. Further, the computer-implemented method includes determining, via a second Machine Learning (ML) model, a plurality of anomalous transaction patterns associated with the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs. Furthermore, the computer-implemented method includes generating, via a clustering model, a plurality of anomalous transaction pattern clusters for the plurality of ATMs based, at least in part, on the plurality of anomalous transaction patterns. Herein, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponds to a corresponding ATM from the plurality of ATMs. Furthermore, the computer-implemented method includes generating and transmitting a report to an issuer server based, at least in part, on at least one of the plurality of anomalous transaction pattern clusters.
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 anomalous card data from a database associated with the server system. The anomalous card data includes information related to historical transactions performed within a specific region via a set of anomalous cards at a plurality of ATMs. Further, the server system is caused to generate an Automatic Teller Machine (ATM)-anomalous card correlation dataset based, at least in part, on the anomalous card data. The server system is further caused to generate a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs based, at least in part, on the ATM-anomalous card correlation dataset. Further, the server system is caused to generate, via a second Machine Learning (ML) model, a plurality of anomalous transaction patterns associated with the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs. The server system is caused to generate, via a clustering model, a plurality of anomalous transaction pattern clusters for the plurality of ATMs based, at least in part, on the plurality of anomalous transaction patterns. Herein, anomalous transaction pattern clusters of the plurality of anomalous transaction pattern clusters correspond to a corresponding ATM from the plurality of ATMs. Further, the server system is caused to generate and transmit, a report to an issuer server based, at least in part, on at least one of the plurality of anomalous transaction pattern clusters.
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 anomalous card data from a database associated with the server system. The anomalous card data includes information related to historical transactions performed within a specific region via a set of anomalous cards at a plurality of ATMs. The method further includes generating an Automatic Teller Machine (ATM)-anomalous card correlation dataset based, at least in part, on the anomalous card data. The method includes generating a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs based, at least in part, on the ATM-anomalous card correlation dataset. Further, the method includes determining, via a second Machine Learning (ML) model, a plurality of anomalous transaction patterns associated with the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs. Furthermore, the method includes generating, via a clustering model, a plurality of anomalous transaction pattern clusters for the plurality of ATMs based, at least in part, on the plurality of anomalous transaction patterns. Herein, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponds to a corresponding ATM from the plurality of ATMs. Furthermore, the method includes generating and transmitting a report to an issuer server based, at least in part, on at least one of the plurality of anomalous transaction pattern clusters.

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 detailed block diagram representation depicting a process flow of detecting a set of anomalous cards and a plurality of anomalous transaction patterns, in accordance with an embodiment of the present disclosure;
FIG. 4 illustrates a flow diagram representation of a process flow of training of a first machine learning (ML) model, in accordance with an embodiment of the present disclosure;
FIG. 5 illustrates a flow diagram representation of a process flow of training of a second ML model, in accordance with an embodiment of the present disclosure;
FIG. 6 illustrates a timing diagram representation for showing the clustering of unique anomalous transaction patterns of an example set of transactions, in accordance with an embodiment of the present disclosure;
FIG. 7 illustrates a block diagram representation of a process flow of identifying anomalous ATMs engaged in money laundering, in accordance with an embodiment of the present disclosure;
FIG. 8A illustrates a process flow diagram depicting a method of determination of a set of anomalous cards via the first ML model, in accordance with an embodiment of the present disclosure;
FIG. 8B illustrates a process flow diagram depicting a method for determining a set of anomalous cards, in accordance with an embodiment of the present disclosure;
FIG. 8C illustrates a process flow diagram depicting a method for detecting anomalous transaction patterns at Automated Teller Machines (ATMs), in accordance with an embodiment of the present disclosure;
FIG. 8D illustrates a process flow diagram depicting a method for determining a plurality of anomalous transaction patterns associated with a plurality of ATMs, 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. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
Embodiments of the present disclosure may be embodied as an apparatus, a system, a method, or a computer program product. Accordingly, embodiments of the present disclosure may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit”, “engine”, “module”, or “system”. Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable storage media having computer-readable program code embodied thereon.
The terms “account holder”, “user”, “cardholder”, and “buyer” are used interchangeably throughout the description and refer to a person who has a payment account or a payment card (e.g., credit card, debit card, etc.) associated with the payment account, that will be used by a merchant to perform a payment transaction. The payment account may be opened via an issuing bank or an issuer server.
The term “merchant”, used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same entity. For example, the merchants may include buyers and sellers of commodities for profit, a trader, a storekeeper, etc. Further, a merchant providing services such as cash withdrawals, deposits, funds transfers, balance inquiries, and the like without direct interaction with bank staff may be referred to an Automated Teller Machine (ATM).
The terms “payment network” and “card network” are used interchangeably throughout the description and refer to a network or collection of systems used for the transfer of funds through the use of cash substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Payment networks are companies that connect an issuing bank with an acquiring bank to facilitate online payment. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash substitutes that may include payment cards, letters of credit checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as Mastercard®.
The term “payment card”, used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility to fund a financial transaction via the associated payment account. For instance, payment cards are used at ATMs to withdraw money in cash. 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 term “Automated Teller Machine” refers to a specialized computer device that allows a cardholder to perform a variety of banking-related activities without the need for the cardholder to visit his/her issuing bank. For instance, cardholders may visit an ATM and withdraw funds by inserting payment cards into the ATM. In an alternative scenario, the cardholder may also withdraw funds from an ATM by relying on the account details of their payment account with their issuing bank.
The terms “payment transaction”, “financial transaction”, “event”, and “transaction” are used interchangeably throughout the description and refer to a transaction of payment of a certain amount being initiated by the cardholder. More specifically, refers to electronic financial transactions including, for example, online payment, payment at a terminal (e.g., point of sale (POS) terminal, ATM, self-service kiosks, and the like. In the case of an ATM, the payment transactions may include depositing or withdrawing an amount to their payment account or from their payment account using the ATM. When depositing the amount in cash to the ATM, a transaction amount (i.e., monetary value) gets added to a corresponding payment account of the cardholder when the details regarding the same are added by the cardholder into the ATM terminal. For instance, if the cardholder wishes to deposit cash into their personal payment account, then the cardholder may enter their account number and other relevant account details such as an account Personal Identification Number (PIN) on the ATM terminal and place the cash on a cash receiver unit associated with the ATM. In another example, when the cardholder wishes to withdraw cash from their payment account, then the cardholder may swipe their payment card and provide the relevant details such as PIN at the ATM terminal, upon authorization from the issuer bank of the cardholder, a cash dispensing unit may dispense the cash amount required by the cardholder.
The term “Money Laundering” used throughout the description refers to the process of disguising the origins of illegally obtained funds, generally through criminal activities, so as to make it appear as if these funds came from legitimate sources. On the other hand, the term “Anti-money Laundering” used throughout the description refers to efforts that are carried out by an institution or individual to counter or curb money laundering activities. Various AML techniques may include AML regulations, AML laws, AML policies, and the like.
OVERVIEW
Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for detecting anomalous transaction patterns at anomalous Automated Teller Machines (ATMs). In an embodiment, the present disclosure describes a server system for detecting anomalous transaction patterns at anomalous ATMs. The server system may be a payment server associated with a payment network. The server system includes a processor and a memory. In an embodiment, the server system is configured to access a payment card-related dataset from a database associated with the server system. Herein, the payment card-related dataset may include information related to historical transactions performed within a specific region by a plurality of cardholders via a plurality of payment cards at a plurality of merchants. The server system is further configured to generate a plurality of payment card-related features based, at least in part, on the payment card-related dataset.
In a non-limiting example, the plurality of payment card-related features corresponding to each cardholder may include at least a daily total transaction amount, a daily unique denomination amount, a daily transaction count, total unique ATM locations, daily average transaction time, daily average transaction amount, total standalone transactions within a predefined time, and the like.
Further, in an embodiment, the server system may be configured to generate a first machine learning (ML) model by performing a first set of operations iteratively till the performance of the first ML model converges to first predefined criteria. For instance, the first predefined criteria may be a saturation of the card-related loss function value. Herein, the card-related loss function value is saturated after a plurality of iterations of the first set of operations is performed.
It may be noted that the first set of operations may be performed iteratively by the server system for training the first ML model to learn transaction patterns of payment cards to distinguish between a legitimate payment card and an anomalous payment card from the plurality of payment cards. In an embodiment, the first set of operations may include: generating the first ML model based, at least in part, on one or more first model parameters, determining via the first ML model, a plurality of card-related latent representations for the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders, computing a card-related loss function value based, at least in part, on the plurality of card-related latent representations corresponding to each cardholder of the plurality of cardholders, and optimizing the one or more first model parameters associated with the first ML model based, at least in part, on back-propagating the card-related loss function value.
Further, while performing the first set of operations, when the performance of the first ML model converges to the first predefined criteria the training stops and the first ML model can be used for determining a set of anomalous cards from the plurality of payment cards. Therefore, the server system is further configured to determine the set of anomalous cards, via the first ML model, from the plurality of payment cards based, at least in part, on the plurality of payment card-related features and an anomaly threshold.
In an embodiment, for determining the set of anomalous cards, the server system via the first ML model, may be configured to determine an actual output corresponding to each cardholder of the plurality of cardholders based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders. The server system may be further configured to determine a predicted output corresponding to each cardholder of the plurality of cardholders based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders. The server system may then be configured to compute an error value for each cardholder of the plurality of cardholders based, at least in part, on comparing the actual output and the predicted output for the corresponding cardholder.
Further, the server system may be configured to compute an anomaly score for each cardholder of the plurality of cardholders based, at least in part, on the error value and predefined score computation criteria. The server system may be configured to label one or more payment cards from the plurality of payment cards associated with the plurality of cardholders as anomalous based, at least in part, on the anomaly score corresponding to each cardholder of the plurality of cardholders being at least greater than an anomaly threshold. The server system may thus be configured to generate the set of anomalous cards from the plurality of payment cards based, at least in part, on aggregating the one or more payment cards labeled as anomalous. In an embodiment, the first ML model may include an unsupervised Long-Short Term Memory (LSTM) based auto encoder model.
Further, in an embodiment, the server system may be configured to store information related to historical transactions performed within the specific region via the set of anomalous cards at the plurality of ATMs as the anomalous card data in the database, based at least in part, on the payment card-related dataset. Upon determining the set of anomalous cards, a correlation between anomalous transaction patterns that are associated with anomalous transactions performed by the set of anomalous cards at each ATM of a plurality of ATMs may have to be determined. Therefore, the server system may be configured to access the anomalous card data from the database. Herein, the anomalous card data may include information related to historical transactions performed within the specific region via the set of anomalous cards at the plurality of ATMs. The server system may further be configured to generate an ATM-anomalous card correlation dataset based, at least in part, on the anomalous card data. The server system may be further configured to generate a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs based, at least in part, on the ATM-anomalous card correlation dataset. In an embodiment, the plurality of transaction pattern-related features corresponding to each ATM may include at least a transaction amount pattern and a transaction time pattern.
Further, the server system may be configured to generate a second ML model by performing a second set of operations till the performance of the second ML model converges to second predefined criteria. In a non-limiting example, the second predefined criteria may be a saturation of the anomalous card-related loss function value, the anomalous card-related loss function value being saturated after a plurality of iterations of the second set of operations is performed.
It may be noted that the server system may perform the second set of operations iteratively for training the second ML model to learn the correlation between the plurality of anomalous transaction patterns associated with the plurality of ATMs.
Further, it may be understood that the second set of operations may include: generating the second ML model based, at least in part, on one or more second model parameters, determining, via the second ML model, a plurality of anomalous card-related latent representations for the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs, computing an anomalous card-related loss function value based, at least in part, on the plurality of anomalous card-related latent representations corresponding to each ATM of the plurality of ATMs, and optimizing the one or more second model parameters associated with the second ML model, based, at least in part, on back-propagating the anomalous card-related loss function value.
Upon training the second ML model, the server system is further configured to determine, via the second ML model, a plurality of anomalous transaction patterns associated with the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs.
It may be noted that for determining the plurality of anomalous transaction patterns associated with the plurality of ATMs via the second ML model, the server system may be configured to determine an actual transaction pattern corresponding to each ATM of the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs. Then, the server system may determine a predicted transaction pattern corresponding to each ATM of the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs. Further, the server system may then generate a pattern error value for each ATM of the plurality of ATMs based, at least in part, on comparing the actual transaction pattern and the predicted transaction pattern for the corresponding ATM. The server system may compute a pattern anomaly score for each ATM of the plurality of ATMs based, at least in part, on the pattern error value. Further, the server system may label one or more transaction patterns from a plurality of transaction patterns for each ATM of the plurality of ATMs as anomalous based, at least in part, on the pattern anomaly score corresponding to each ATM of the plurality of ATMs being at least greater than a pattern anomaly threshold. Lastly, the server system may determine the plurality of anomalous transaction patterns associated with each ATM of the plurality of ATMs based, at least in part, on aggregating the one or more transaction patterns labeled as anomalous. In an embodiment, the second ML model may include an unsupervised Long-Short Term Memory (LSTM) based auto encoder model.
In an embodiment, the server system is further configured to generate, via a clustering model, a plurality of anomalous transaction pattern clusters for the plurality of ATMs based, at least in part, on the plurality of anomalous transaction patterns. Herein, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponds to a corresponding ATM from the plurality of ATMs. In an embodiment, the clustering model may include at least one of a K-means model, Hierarchical Clustering Model (HCM), Density-Based Spatial Clustering of Application with Noise (DBSCAN) model, Mean Shift Model (MSM), Gaussian Mixture Model (GMM), a Spatial Clustering Model (SCM), and the like.
In an example embodiment, the server system may also be configured to determine, via a third ML model, a plurality of anomalous ATMs from the plurality of ATMs based, at least in part, on the plurality of anomalous transaction pattern clusters associated with each ATM of the plurality of ATMs, wherein the third ML model includes a graph-based semi-supervised ML model.
Moreover, the server system is configured to generate and transmit, a report to an issuer server based, at least in part, on at least one of the plurality of anomalous transaction pattern clusters.
Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure is intended to detect anomalous transaction patterns at anomalous ATMs. Conventional methods failed to track anomalous transactions at ATMs as their transaction pattern did not match with usual money laundering patterns and hence generated high false positives that are related to ATMs. The method proposed in the present disclosure captures such alerts for ATMs’ anomalous transactions, thereby reducing the false positives by a significant amount.
Moreover, as the method proposed in the present disclosure automatically generates a report about money laundering at ATMs, review and report preparation time has been reduced. Further, the method can identify anomalous cards, location IDs, ATMs, and issuer IDs involved in money laundering, thereby making the method more efficient and more precise in detecting money laundering and its root cause. This feature also helps to highlight entities within the financial system that require further investigation and security.
In addition, it may be noted that even if transaction pattern is different at different locations due to their transaction policies and regulations, the method can identify money laundering activities at each location (ATM). Thus, it can be concluded that the method proposed in the present disclosure continuously learns patterns in real-time at different locations and can easily identify payment cards, locations, and issuers that are most likely to be engaged in money laundering.
Further, for identifying anomalous customers such as the ATMs in a network of payment cards and the ATMs, a semi-supervised graph-based approach may be used. By using this approach in the proposed method, interconnectedness and relationships among different entities (ATMs and payment cards) within the network facilitate the method to identify individuals who exhibit behavior consistent with money laundering. Furthermore, the graph-based nature of the approach enables the detection of complex patterns and anomalies that might be difficult to uncover through traditional analysis methods. Therefore, by using such a method, financial institutions gain valuable insights into suspicious behaviors and take appropriate actions to mitigate money laundering risks.
Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 11.
FIG. 1 illustrates a block diagram representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, detecting anomalous transactions, detecting anomalous transaction patterns at anomalous Automated Teller Machines (ATMs), reporting anomalous transaction patterns at performed as the anomalous ATMs and the like. It is noted that the term ‘anomalous transactions’ as used herein refers to card-related payment transactions that are likely to be money laundering-related transactions. In other words, anomalous transactions are those transactions that are suspicious in nature and may correspond to transactions that are performed to carry out money laundering activities. Further, anomalous transaction patterns are transaction patterns that when considered as a whole are likely to correspond with money laundering-related transactions.
The environment 100 generally includes a plurality of entities such as a server system 102, a plurality of cardholders 104(1), 104(2), … 104(N), where ‘N’ is a non-zero Natural number (collectively, interchangeably referred to hereinafter as plurality of cardholders 104 or cardholders 104), a plurality of ATMs 106(1), 106(2), … 106(N) where ‘N’ is a non-zero Natural number (collectively, interchangeably referred to hereinafter as plurality of ATMs 106 or ATMs 106), 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, New Radio (NR) communication protocol, any future communication protocol, or any combination thereof. In some instances, the network 116 may utilize a secure protocol (e.g., Hypertext Transfer Protocol (HTTP), Secure Socket Lock (SSL), and/or any other protocol, or set of protocols for communicating with the various entities depicted in FIG. 1.
In an embodiment, the cardholders 104 use one or more payment cards 118(1), 118(2), … 118(N) where ‘N’ is a non-zero Natural number (collectively, interchangeably referred to hereinafter as the plurality of payment cards 118 or payment cards 118) respectively to make payment transactions. As may be understood, the cardholder (e.g., the cardholder 104(1)) may be any individual, representative of a corporate entity, a non-profit organization, or any other person that is presenting payment account details during an electronic payment transaction. The cardholder (e.g., the cardholder 104(1)) may have a payment account issued by an issuing bank (not shown in figures) associated with the issuer server 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 cardholders 104 may use their corresponding electronic devices (not shown in figures) to access a mobile application or a website associated with the issuing bank, or any third-party payment application to perform a payment transaction. In various non-limiting examples, the electronic devices may refer to any electronic devices such as, but not limited to, personal computers (PCs), tablet devices, Personal Digital Assistants (PDAs), voice-activated assistants, Virtual Reality (VR) devices, smartphones, laptops, and the like.
In an embodiment, the ATMs 106 may be independent electronic telecommunication devices installed at different locations for cardholders (e.g., the cardholders 104) of different financial institutions to perform financial transactions at any time and without the need for direct interaction with bank staff. In a non-limiting example, the financial institutions may include banks, trust companies, insurance companies, investment banks, non-banking entities, and the like. Further, examples of the financial transactions may include cash withdrawals, cash deposits, funds transfers, balance inquiries, account information inquiries, and the like.
Thus, it may be noted that, in some embodiments, the ATMs 106 may be arranged, operated, and owned by banks. In some other embodiments, the ATMs 106 may be arranged, operated, and owned by non-banking entities or private entities in association with banks as well. It is noted that an ATM (such as the ATM 106(2)) that is arranged, operated, and owned by non-banking entities may be called white-label ATMs. As may be understood, financial transactions that are performed at the ATMs 106 are communicated to a host processor associated with and operated by the banks and/or the non-banking entities. In a particular scenario, the ATMs 106 and the host processor are communicably coupled with each other via the network 116. In other scenarios, the ATMs 106 and the host processors may be connected with each other via the Internet as well.
In one embodiment, the cardholders 104 are associated with the issuer server 110. In one embodiment, the issuer server 110 is associated with a financial institution normally called an “issuer bank”, “issuing bank” or simply “issuer”, in which a cardholder (e.g., the cardholder 104(1)) may have the payment account, (which also issues a payment card, such as a credit card or a debit card), and provides microfinance banking services (e.g., payment transaction using credit/debit cards) for processing electronic payment transactions, to the cardholder (e.g., the cardholder 104(1)).
In an embodiment, the merchants are generally associated with the acquirer server 108. In an embodiment, the merchant may be an ATM, such as the ATM 106(1), i.e., 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, or institutions that own platforms that make either online purchases or purchases made via software applications possible. The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
In a non-limiting example, it may be noted that when a cardholder (e.g., the cardholder 104(1)) visits an ATM (e.g., the ATM 106(1)) to withdraw cash of a certain amount. At first, the cardholder 104(1) may insert a payment card (e.g., the payment card 118(1)) associated with him in a card reader unit of the ATM 106(1) that is configured to read and transfer data from the payment card 118(1) to the host processor. Then, the ATM 106(1) may request the cardholder 104(1), via a display screen or a speaker, to provide further details such as a cardholder identification number, a withdrawal amount, PIN code, and the like, for the host processor to authenticate the identity of the cardholder 104(1) with the issuer server 110 of the issuing bank. Upon successful authentication by the issuer server 110, the host processor sends an approval code to the ATM 106(1) so that the cash of the requested amount can be deducted from the cardholder’s account and then, dispensed via a dispenser unit of the ATM 106(1) such that the cardholder 104(1) may collect the money in cash. In such scenarios, the ATMs 106 may be considered as merchants themselves, and the banks or the non-banking entities to whom the ATMs 106 belong may be referred to as acquiring banks.
In another example, the cardholders 104 may use their corresponding payment accounts to conduct payment transactions with the merchants. Moreover, it may be noted that each of the cardholders 104 may use their corresponding 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. In an embodiment, 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 cardholders 104 (e.g., the cardholder 104(1)) may transact at any merchant from the plurality of merchants (e.g., the ATM 106(1)).
In a non-limiting example, a subset of the cardholders 104 making transactions at the ATMs 106 may not be making such transactions for a legitimate reason, i.e., such cardholders may be involved in money laundering activities. Since the importance of curbing such money laundering activities is known, various AML rules and regulations are applied by the various financial institutions within the payment network, such as the payment server 114, the issuer server 110, the acquirer server 108, and the like. As described earlier, generally a transaction is marked or labeled as a money laundering-related transaction if one or more rules are met. Examples of the one or more rules include an inability to identify the actual owner of a business, unusual transaction histories such as frequent high-volume transactions, money in bank accounts, buying items with intangible values such as art, jewelry, databases, programs, and the like, unusual monetary losses that are not questioned by investors, a high volume of cash transactions such as paying employee salary in cash, etc., among other suitable rules. In a particular scenario, the one or more rules may vary for determining a particular form of money laundering activities. For instance, ATM-related money laundering activities may be detected by the separate one or more rules such as the following:
If the frequency of small monetary value transactions is high, rather than having a singular larger transaction may depict a money laundering activity.
ATMs often have withdrawal limits, forcing the money launderers to use multiple ATMs to withdraw larger sums of money. This may result in a pattern of repeated transactions of the withdrawal limit at different locations and may depict a money laundering activity.
Money launderers may use ATMs in different geographic locations to avoid detection. This can result in different patterns of transactions across different states or countries.
Money launderers may withdraw money at odd hours or in quick succession, which can be indicative of anomalous behavior.
Money launderers may use multiple bank accounts to withdraw money from the same or different ATMs. This can result in a pattern of transactions across different accounts.
In other words, the anomalous factors or one or more rules that may depict the presence of ATM-related money laundering activities may include frequency of transactions, withdrawal limits, geographic dispersion, timing, using multiple accounts, and the like. However, as described earlier, these rule-based techniques led to a plurality of problems such as high false positives for ATM alerts, high complexity, high rigidity, the use of unique transaction patterns by the money launderer at any of the ATMs 106 to avoid triggering these rigid rules, and the like.
Therefore, to address the above-mentioned technical problem and to detect ATM-related money laundering activities with greater preciseness and accuracy, one or more embodiments of the server system 102 proposed in the present disclosure are configured to perform one or more operations described herein.
In one embodiment, the server system 102 is configured to facilitate issuers and/or regulatory authorities in detecting ATM-related money laundering activities using various Artificial Intelligence (AI) or Machine Learning (ML) models. In some embodiments, the server system 102 may be deployed as a standalone server or may be implemented in the cloud as software as a service (SaaS). The server system 102 may be configured to provide or host a software application on electronic devices used by the issuers and/or regulatory authorities to detect ATM-related money laundering activities. In other words, the server system 102 is configured to detect and report anomalous transaction patterns at anomalous ATMs.
As may be understood, for the server system 102 to be able to facilitate such a feature, the server system 102 needs to collect information related to the payment cards 118 that are a part of the network. Therefore, in an 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 various non-limiting examples, the database 120 may include one or more hard disk drives (HDD), solid-state drives (SSD), an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a redundant array of independent disks (RAID) controller, a storage area network (SAN) adapter, a network adapter, and/or any component providing the server system 102 with access to the database 120. In one implementation, the database 120 may be viewed, accessed, amended, updated, and/or deleted by an administrator (not shown) associated with the server system 102 through a database management system (DBMS) or relational database management system (RDBMS) present within the database 120.
In an embodiment, the database 120 stores a payment card-related dataset 122. Further, the server system 102 is configured to access the payment card-related dataset 122 from the database 120 associated with the server system 102. Herein, the payment card-related dataset 122 may include information related to historical transactions performed within a specific region by a plurality of cardholders 104 via a plurality of payment cards 118 at a plurality of merchants. More specifically, the payment card-related dataset 122 includes time series data related to historical transactions performed by the cardholders 104 via the payment cards 118 at a plurality of merchants. In an example embodiment, the plurality of merchants may include a retailer, a brick-and-mortar store, a grocery store, an online retailer, and the like.
In an embodiment, the database 120 may also store the various AI/ML models such as a first machine learning (ML) model 124, a second machine learning (ML) model 126, a clustering model 128, and the like. In an example embodiment, the database 120 may also store anomalous card data (not shown in FIG. 1). In some embodiments, the database 120 may further 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, fraudulent payment transaction data and the like as well.
In an example, the time series data related to the historical transactions may also include real-time transaction data of the cardholders 104 and the ATMs 106 as well. The real-time transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past ‘x’ number of days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction. In addition, the database 120 provides a storage location for data and/or metadata obtained from various operations performed by the server system 102.
The server system 102 may be further configured to generate a plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the payment card-related dataset 122. In a non-limiting example, the plurality of payment card-related features corresponding to each cardholder may at least include a daily total transaction amount, a daily unique denomination amount, a daily transaction count, total unique ATM locations, daily average transaction time, daily average transaction amount, and total standalone transactions within a predefined time, and the like.
As may be understood, the historical transactions performed within a specific region are taken by the server system 102 to generate the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104 due to the fact that each specific region or country has a different pattern of money withdrawal from ATM’s based on their specific AML rules and AML regulations. In other words, the first ML model 124 or the second ML model 126 operates on regional transactions to determine region-specific anomalous transaction patterns at anomalous ATMs. As may be understood, this approach is more accurate due to the presence of different money withdrawal patterns within different regions, as described earlier.
In some embodiments, the plurality of payment card-related features may be generated for the payment card-related dataset 122 that is collected by the server system 102 on a daily basis or a regular basis and may not be restricted to be related to transactions carried out at the ATMs 106 and could to related to any other merchants as well. In a non-limiting example, the unique amounts may refer to the maximum transaction limits are ATMs 106 and the unique ATM locations may refer to the locations of the ATMs 106.
In some other embodiments, the plurality of payment card-related features may further include issuer details, acquirer details, card details, product details, and the like. Further, in an embodiment, the server system 102 may be configured to train the AI or ML models using the plurality of payment card-related features generated using the payment card-related dataset 122. More specifically, the server system 102 may be configured to generate the first ML model 124 by training the first ML model 124 to learn transaction patterns of payment cards 118 to distinguish between a legitimate payment card and an anomalous payment card from the plurality of payment cards 118. It is noted that this determination is made on the basis of whether the transaction pattern associated with a particular payment card is determined to be legitimate or anomalous. The process for generating the first ML model 124 is explained in detail later in the present disclosure with reference to FIG. 4.
From the above discussion, it can be gathered that the server system 102 is configured to determine, via the first ML model 124, a set of anomalous cards from the plurality of payment cards 118 based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104. In particular, the first ML model 124 also employs an anomaly threshold for determining the set of anomalous cards. It is noted that the process for determining the set of anomalous cards is explained in detail later in the present disclosure with reference to FIG. 3.
Upon determining the set of anomalous cards, the server system 102 may further be configured to store information related to historical transactions performed within the specific region via the set of anomalous cards at the plurality of ATMs 106 as the anomalous card data in the database 120, based at least in part, on the payment card-related dataset. Further, in an embodiment, the server system 102 is configured to access the anomalous card data from the database 120. In a non-limiting example, the anomalous card data may include information related to historical transactions performed within the specific region via the set of anomalous cards at the plurality of ATMs 106.
In an embodiment, the server system 102 is further configured to generate an ATM-anomalous card correlation dataset based, at least in part, on the anomalous card data. As may be understood, the ATM-anomalous card correlation dataset includes information related to those transactions that were performed using the set of anomalous cards by their corresponding cardholders at the ATMs 106.
Further, the server system 102 is configured to generate a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the ATM-anomalous card correlation dataset. In various non-limiting examples, the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106 may include a transaction amount pattern, a transaction time pattern, and the like. As may be understood, a single transaction pattern may represent or include a sequence of payment transactions performed using the payment card within a specific time period. For instance, the transaction sequence performed by a card within 5-minute intervals may be a single transaction pattern.
Further, in an embodiment, the server system 102 may be configured to generate a second ML model 126 by training the second ML model 126 to learn the correlation between one or more anomalous transaction patterns associated with the plurality of ATMs 106. It is noted that the process for generating and training the second ML model 126 is explained in detail later in the present disclosure with reference to FIG. 5.
Moreover, the server system 102 is configured to determine, via the second ML model 126, a plurality of anomalous transaction patterns associated with the plurality of ATMs 106 based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106.
The server system 102 may further be configured to generate the clustering model 128 by training the clustering model 128 to cluster or group identical or similar transaction patterns at each ATM from the plurality of ATMs 106 in a single cluster. It is noted that the process for generating and training the clustering model 128 is explained in detail later in the present disclosure with reference to FIGS. 3 and 6.
Further, the server system 102 is configured to generate, via the clustering model 128, a plurality of anomalous transaction pattern clusters for the plurality of ATMs 106 based, at least in part, on the plurality of anomalous transaction patterns. Herein, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponds to a corresponding ATM from the plurality of ATMs 106. Furthermore, as may be understood, each of the plurality of anomalous transaction pattern clusters may indicate a unique group of anomalous transaction patterns.
The server system 102 may further be configured to generate and transmit a report to the issuer server 110 based, at least in part, on the plurality of anomalous transaction pattern clusters. In some scenarios, the report may be transmitted to the regulatory authorities or bodies as well. Further, upon receiving the report, the issuers and/or regulatory authorities or bodies may determine what action to take to prevent such money laundering activities based on their own set of policies.
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 116 or integrated within the payment server 114. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 for executing instructions, a memory 208, a communication interface 210, a user interface 212, and a storage interface 214. The one or more components of the computer system 202 communicate with each other via a bus 216. The components of the server system 200 provided herein may not be exhaustive and the server system 200 may include more or fewer components than those depicted in FIG. 2. Further, two or more components depicted in FIG. 2 may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities.
In some embodiments, the database 204 is integrated into the computer system 202. In one non-limiting example, the database 204 is configured to store a payment card-related dataset 218, a first machine learning (ML) model 220, a second ML model 222, and a clustering model 224. The payment card-related dataset 218, the first ML model 220, the second ML model 222, and the clustering model 224 are identical to the payment card-related dataset 122, the first ML model 124, the second ML model 126, and the clustering model 128 of FIG. 1. In an embodiment, the database 204 may also store anomalous card data (not shown in FIG. 2).
Further, the computer system 202 may include one or more hard disk drives as the database 204. The storage interface 214 is any component capable of providing the processor 206 access to the database 204. The storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204.
The processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for detecting a set of anomalous cards, determining anomalous transaction patterns, clustering identical patterns, identifying anomalous customers (ATMs), generating and transmitting a report related to such anomalous transactions to an issuer server associated with the issuing bank, and the like. Examples of the processor 206 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a graphical processing unit (GPU), a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like.
The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.
The processor 206 is operatively coupled to the communication interface 210, such that the processor 206 is capable of communicating with a remote device 226 such as the 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. It should be noted that the server system 200 is identical to the server system 102 described in reference to FIG. 1.
In one implementation, the processor 206 includes a data pre-processing module 228, an anomalous card detection module 230, a correlation module 232, a clustering module 234, an anomalous customer detection module 236, and a report generation module 238. It should be noted that components, described herein, such as the data pre-processing module 228, the anomalous card detection module 230, the correlation module 232, the clustering module 224, the anomalous customer detection module 236, and the report generation module 238 can be configured in a variety of ways, including electronic circuitries, digital arithmetic, and logic blocks, and memory systems in combination with software, firmware, and embedded technologies.
In an embodiment, the data pre-processing module 228 includes suitable logic and/or interfaces for accessing the payment card-related dataset 218 from the database 204 associated with the server system 200. As may be understood that the payment card-related dataset 218 includes information related to historical transactions performed within a specific region by a plurality of cardholders 104 via a plurality of payment cards 118 at a plurality of merchants. In particular, the payment card-related dataset 218 includes the time series data related to the historical transactions performed within a specific region by the cardholders 104 via the payment cards 118 at the plurality of merchants.
As may be understood, the historical transactions may be performed within a predetermined interval of time (e.g., 6 months, 12 months, 24 months, etc.) within a specific region. It is noted that the server system 200 is configured to operate using the payment card-related dataset 218 associated with a specific region because different AML rules and regulations are applied over different regions by different governments or regulatory bodies, which leads to different money laundering or anomalous transaction patterns within different regions. The term ‘region’ may refer to a geographical area that is covered under certain AML rules and regulations. For instance, a state or a country is an example of a region.
In some non-limiting examples, the payment card-related dataset 218 may also include 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 historical transactions, cardholder identifier, permanent account number (PAN), merchant DBA name, country code, transaction identifier, transaction location (i.e., geo co-ordinates of the transaction ), ATM location, and the like. In one example, payment card-related dataset 218 may define a relationship between a cardholder account and a merchant account (for example, an account associated with a merchant such as an ATM). For example, when a cardholder 104(1) withdraws cash of a certain amount from an ATM such as ATM 106(2), makes a fund transfer from a cardholder’s account to a merchant’s account, a cardholder 104(2) deposits cash of a certain amount within his own account, and the like, a relationship is defined between the cardholder 104(2) and the merchant.
In another embodiment, the payment card-related dataset 218 may include information related to past payment transactions such as transaction date, transaction time, geo-location of a transaction, transaction amount, transaction marker or label (e.g., anomalous or non-anomalous, i.e., legitimate), and the like. In yet another embodiment, the payment card-related dataset 218 may include information related to the acquirer server 108 such as the acquirer ID, the date of merchant (e.g., the ATM 106(1)) registration with the acquirer server 108, amount of payment transactions performed at the acquirer server 108 in a day by a particular cardholder using his payment card, number of payment transactions performed at the acquirer server 108 in a day by a particular cardholder using his payment card, maximum transaction amount, minimum transaction amount, number of anomalous merchants or non-anomalous merchants registered with the acquirer server 108, and the like.
In an embodiment, the data pre-processing module 228 may further be configured to generate a plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the payment card-related dataset 218. It may be noted that the plurality of payment card-related features corresponding to each cardholder may include at least a daily total transaction amount, a daily unique denomination amount, a daily transaction count, total unique ATM locations, daily average transaction time, daily average transaction amount, total standalone transactions within a predefined time, and the like.
It may be noted that, whether the step of feature generation is needed or not may be dependent upon which type the AI/ML model is used by the server system 200 for performing further steps to achieve the objective of the server system 200. Further, feature generation may include the implementation of steps by the data pre-processing module 228. Herein, the steps may include data understanding, data cleaning, feature extraction, feature selection, and the like.
In some embodiments, the data pre-processing module 228 may generate a plurality of payment card-related features using one or more feature engineering techniques. For instance, the one or more feature engineering techniques may include feature extraction, one-hot encoding, binning, scaling and normalization, feature interactions, polynomial features, time-based features, domain-specific feature engineering, and the like.
It may be understood that the plurality of payment card-related features generated corresponding to each cardholder of the plurality of cardholders 104 may capture the underlying patterns and relationships in the data points present in the payment card-related dataset 218. This nature of the plurality of payment card-related features improves the model’s performance and interoperability. The plurality of payment card-related features may then be fed to the anomalous card detection module 230.
In an embodiment, the anomalous card detection module 230 includes suitable logic and/or interfaces for determining, via the first ML model 220, a set of anomalous cards from the plurality of payment cards 118 based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104 and an anomaly threshold.
As may be understood, for determining the set of anomalous cards using the first ML model 220, the first ML model 220 may have to be generated. Thus, in an embodiment, the anomalous card detection module 230 may be configured to generate the first ML model 220 by performing a first set of operations for training the first ML model 220 to learn to determine a transaction pattern of a payment card (e.g., the payment card 118(1)) of the payment cards 118 to be one of legitimate and anomalous at the plurality of merchants.
The first set of operations may include generating the first ML model 220 based, at least in part, on one or more first model parameters. In an embodiment, at first, various components or units of the model are initialized. For instance, considering that the first ML model 220 is a Long Short-Term Memory (LSTM) based auto encoder model, components such as hidden units, activation function, loss function, and an optimizer have to be initialized before the model is trained. These components may constitute the one or more first model parameters. Then, a plurality of card-related latent representations for the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104 is determined. Then, a card-related loss function value based, at least in part, on the plurality of card-related latent representations corresponding to each cardholder of the plurality of cardholders 104 is computed. Finally, the one or more first model parameters associated with the first ML model 220 are optimized based, at least in part, on back-propagating the card-related loss function value. As may be noted the first set of operations are iteratively performed till the performance of the first ML model 220 converges to the first predefined criteria. In an embodiment, the first predefined criteria may be a saturation of the card-related loss function value. Herein, the card-related loss function value is considered to be saturated after a plurality of iterations of the first set of operations is performed. In other words, if the card-related loss function value remains consistent for a first predefined count of the iterations of the first set of operations, then it can be considered saturated. For example, the first predefined count may be a significant count such as for 10-20 iterations. In another embodiment, the first predefined criteria may include a situation where the first ML model 220 stops learning further or the card-related loss function value stops decreasing. The process for generating the first ML model 220 is explained in detail later in the present disclosure with reference to FIG. 4.
Upon generating the first ML model 220, the first ML model 220 is then used by the anomalous card detection module 230 for determining the set of anomalous cards from the plurality of payment cards 118. Further, for determining the set of anomalous cards, the anomalous card detection module 230 may be configured to use the first ML model 220, to determine an actual output corresponding to each cardholder of the plurality of cardholders 104, to determine a predicted output corresponding to each cardholder of the plurality of cardholders 104, to generate an error value for each cardholder of the plurality of cardholders 104, to compute an anomaly score for each cardholder of the plurality of cardholders 104, label one or more payment cards from the plurality of payment cards 118 as anomalous based on the anomaly score being greater than the anomaly threshold, aggregating the one or more payment cards 118 labeled as anomalous to generate the set of anomalous cards. The process for determining the set of anomalous cards is explained in detail later in the present disclosure with reference to FIG. 3. In another embodiment, the set of anomalous cards may be fed to the correlation module 232 by the anomalous card detection module 230.
In some embodiments, the anomalous card detection module 230 may further be configured to store information related to historical transactions performed within the specific region via the set of anomalous cards at a plurality of ATMs 106 as the anomalous card data in the database 204, based at least in part, on the payment card-related dataset 218.
In an embodiment, the correlation module 232 includes suitable logic and/or interfaces for accessing the anomalous card data from the database 204. Herein, the anomalous card data may include the information related to the historical transactions performed within the specific region via the set of anomalous cards at the plurality of ATMs 106. Further, the correlation module 232 may be configured to generate an ATM-anomalous card correlation dataset based, at least in part, on the anomalous card data. More specifically, the correlation module 232 is configured to extract the anomalous card data from the database 204 to generate the ATM-anomalous card correlation dataset based, at least in part, on one or more correlating parameters. In various non-limiting examples, the one or more correlating parameters may include at least a location, a location identity (ID), an issuer ID, an acquirer ID, frequency of transactions, withdrawal limits, geographic dispersion, timing, use of multiple payment accounts and the like.
In another embodiment, the correlation module 232 is configured to generate a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the ATM-anomalous card correlation dataset. In various non-limiting examples, the plurality of transaction pattern-related features corresponding to each ATM include at least a transaction amount pattern, a transaction time pattern, and the like. Further, the correlation module 232 is configured to generate via a second ML model 222, a plurality of anomalous transaction patterns associated with the plurality of ATMs 106 based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106. In some scenarios, the second ML model 222 may be generated by the correlation module 232 as well. In particular, for generating the second ML model 222, the correlation module 232 is configured to perform a second set of operations iteratively till the performance of the second ML model 222 converges to the second predefined criteria.
More specifically, the second set of operations may include generating the second ML model 222 based, at least in part, on one or more second model parameters. In an embodiment, at first, various components or units of the second ML model 222 are initialized. For instance, considering that the second ML model 222 is a Long Short-Term Memory (LSTM) based auto encoder model, components such as hidden units, activation function, loss function, and an optimizer have to be initialized before the second ML model 222 is trained. These components may constitute the one or more second model parameters. Then, a plurality of anomalous card-related latent representations for the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106 is determined. Then, an anomalous card-related loss function is computed and the anomalous card-related loss function is back propagated to optimize the one or more second model parameters associated with the second ML model 222. The process for generating the second ML model 222 is explained in detail later in the present disclosure with reference to FIG. 5.
In an embodiment, the plurality of anomalous transaction patterns associated with the plurality of ATMs 106 is fed to the clustering module 224 by the correlation module 232.
In an embodiment, the clustering module 234 includes suitable logic and/or interfaces for generating, via the clustering model 224, a plurality of anomalous transaction pattern clusters for the plurality of ATMs 106 based, at least in part, on the plurality of anomalous transaction patterns. Herein, it is noted that each of the plurality of anomalous transaction pattern clusters corresponds to a corresponding ATM of the plurality of ATMs 106.
For generating the one or more anomalous transaction pattern clusters using the clustering model 224, the clustering model 224 may have to be generated. Thus, in an embodiment, the clustering module 224 may be configured to generate the clustering model 224 by performing a clustering-related set of operations. For example, the clustering model 224 may be generated using one or more clustering algorithms or models. In various non-limiting examples, the clustering model 224 is at least one of a K-means model, Hierarchical Clustering Model (HCM), Density-Based Spatial Clustering of Application with Noise (DBSCAN) model, Mean Shift Model (MSM), Gaussian Mixture Model (GMM), a Spatial Clustering Model (SCM) and the like. Moreover, the process for training the clustering model 224 is explained in detail with reference to FIGS. 3 and 6.
In one example embodiment, the plurality of anomalous transaction pattern clusters for the plurality of ATMs 106 may be fed to the anomalous customer detection module 236. Therefore, the anomalous customer detection module 236 includes suitable logic and/or interfaces for determining, via a third ML model (not shown in FIG. 2), a plurality of anomalous ATMs from the plurality of ATMs 106 based, at least in part, on the plurality of anomalous transaction pattern clusters associated with each ATM of the plurality of ATMs 106. Herein, the third ML model may include a graph-based semi-supervised ML model.
In particular, for determining the plurality of anomalous ATMs using the third ML model, the third ML model may have to be generated. Thus, in an embodiment, the anomalous customer detection module 236 may be configured to generate the third ML model by performing a third set of operations. Further, the process for generation and training of the third ML model and the identification of the one or more anomalous location IDs are explained in the description with reference to FIG. 7.
In another embodiment, the plurality of anomalous transaction pattern clusters for the plurality of ATMs 106 may be fed to the report generation module 238. The report generation module 238 suitable logic and/or interfaces for generating a report to an issuer server (e.g., the issuer server 110) based, at least in part, on the plurality of anomalous transaction pattern clusters. In another scenario, the report generation module 238 may also generate the report based, at least in part, on the plurality of anomalous transaction pattern clusters along with a set of pre-defined rules. In a non-limiting example, the set of pre-defined rules may be related to the frequency of transactions, withdrawal limits, geographic dispersion, timing, using multiple accounts, and the like. In an embodiment, the report may include details such as money laundering alerts, location-specific money laundering alerts, suspicious location IDs, suspicious cardholder IDs, and the like for various time intervals and locations corresponding to each transaction pattern cluster associated with each anomalous ATM. In other words, the report may be generated to report the suspicious behavior corresponding to ATM-related money laundering activities of each anomalous ATM from the subset of anomalous ATMs. Further, upon receiving this report, the issuers and/or the government or regulatory bodies may determine what action to take to prevent such money laundering activities based on their own set of policies.
FIG. 3 illustrates a detailed block diagram representation 300 depicting a process flow for detecting a set of anomalous cards 302 and a plurality of anomalous transaction patterns (i.e., different anomalous transaction patterns clusters see, 304), in accordance with an embodiment of the present disclosure.
As depicted by FIG. 3, the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104 (depicted and referred to herein, as ‘payment card-related features 306’) are fed to the first ML model 220. The first ML model 220 is trained to learn to determine the behavior patterns associated with the plurality of payment cards 118 associated with the plurality of cardholders 104. Further, the first ML model 220 may classify these behavior patterns to determine if a particular payment card is anomalous or legitimate. In other words, based on the determined behavior pattern, the corresponding payment card may be labeled to be either an anomalous card or a legitimate card.
It may be noted that the plurality of payment card-related features 306 may include features that are understood and/or interpreted by the server system 200 based, at least in part, on the payment card-related dataset 218. More specifically, the payment card-related features 306 may be features indicating a payment transaction behavior of the cardholders 104 that are involved in making payment transactions at the plurality of merchants.
Further, in an embodiment, as may be understood that the first ML model 220 is trained for determining the set of anomalous cards (see, 302) from the payment cards 118 that make payment transactions at the plurality of merchants by the plurality of cardholders 104. For instance, the payment transactions may include e-commerce transactions, retail transactions, bill payments, cash withdrawals, cash deposits, fund transfers, and the like.
As may be understood, since there is always a lack of labels associated with datasets in the financial domain, at first, the first ML model 220 may be trained using unsupervised learning techniques to tackle this lack of proper labels. In a particular implementation, the first ML model 220 may be a Long Short-Term Memory (LSTM) based auto encoder model that is trained using deep learning neural networks in an unsupervised manner based at least in part on the payment card-related dataset 218. In one scenario, the payment card-related dataset 218 may be split into training data, validation data, and test data for training and testing the first ML model 220. The LSTM model may include encoders 308 and decoders 310 as shown in FIG. 3. As may be understood, such components, i.e., the encoders 308 and decoders 310, when initialized are done so using the one or more first model parameters. These one or more first model parameters may simply be referred to as the basic parameters required for producing a generic model. It is noted that these one or more first model parameters can be trained and optimized according to a task (herein, for determining the set of anomalous cards) so that the first ML model 220 generated from the optimized one or more first model parameters may perform accurate predictions.
To that end, during the training or model generation process, an input (e.g., the payment card-related features 306) in a predefined format (see, 312) may be fed to a series of encoders 308. The encoders 308 may generate a plurality of card-related latent representations (hereinafter, interchangeably also referred to as ‘latent representations 314’) for the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104. The latent representation 314 thus generated may be fed to the decoders 310. The series of decoders 310 of the first ML model 220 may further attempt to re-generate the input 312 as an output in a predefined format (see, 316). During this process, a card-related loss function value may be computed. In other words, the card-related loss function value is computed based, at least in part, on the plurality of card-related latent representations corresponding to each cardholder of the plurality of cardholders 104. Further, the card-related loss function value is back propagated to optimize the one or more first model parameters associated with the first ML model 220. As may be noted this set of operations (referred to as the ‘first set of operations’) may be repeated iteratively till the performance of the first ML model 220 converges to the first predefined criteria. At this stage, the first ML model 220 is considered to be trained. As described earlier, the first predefined criteria refer to a saturation of the card-related loss function value.
Upon completion of the training process of the first ML model 220, the first ML model 220 is now ready to be used by the server system 200 for determining the set of anomalous cards 302. Therefore, the test data such as the first test dataset of the payment card-related dataset 218 may be fed to the first ML model 220 as the input 312 for each payment card, and a first predicted output dataset may be generated as the output 316. As may be understood, during the testing phase, at first, the first ML model 220 determines an actual output corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104. It is noted that the actual output is the actual behavior pattern depicted by a particular cardholder.
Then, the first ML model 220 is configured to determine a predicted output corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104. As may be understood, this predicted output is generated by the first ML model 220. It is noted that the predicted output is the behavior pattern that should be depicted by a particular cardholder.
Now, it would be apparent if the actual behavior of the particular cardholder deviates from the predicted behavior, then there would be an anomaly in the behavior of this particular cardholder. To determine this deviation, the first ML model 220 is configured to generate an error value for each cardholder of the plurality of cardholders 104 based, at least in part, on comparing the actual output and the predicted output for the corresponding cardholder. In a non-limiting example, the error 318 may be computed as a summation of each error value for each cardholder (i.e., for each payment card) as shown by Eqn. 1:
"Error"= ?¦?"|X- " "X" ?"|" ? … Eqn. 1
Herein, the term ‘X’ refers to the input (an input time series data), and the term ‘"X" ?’ refers to the output data for all the features used in the first ML model 220.
In addition, the server system 200, via the first ML model 220, may further compute an anomaly score for each cardholder of the plurality of cardholders 104 based, at least in part, on the error value and predefined score computation criteria. In a non-limiting example, the anomaly score may include a Z-score (see, 320) as shown in FIG. 3. As used herein, the term “Z-score” refers to a standard score that is a statistical measure that quantifies ‘how many standard deviations an observation or data point is away from the mean of a distribution’. In some embodiments, the Z-score may be used for data normalization or standardization. In some other embodiments, the Z-score may also be used for outlier detection, anomaly detection, quality control, performance assessment, risk assessment, market research, and the like. In the current scenario, for computing the Z-score, the predefined score computation criteria considered may correspond to quantifying how many standard deviations ("s" ) of the error value (X) for each payment card is away from the mean ("µ" ) of a distribution of the error value (X), and the equation used may be shown by Eqn.2:
"Z-score"="(X-µ)/s" … Eqn. 2
Herein, the term ‘X’ each data point corresponding to an error value for each payment card, ‘"µ" ’ refers to the mean of each data point of the error value ‘X’, and ‘"s" ’ refers to a standard deviation of each data point of the error value ‘X’.
In a non-limiting example, based on the anomaly score determined for corresponding to each cardholder of the plurality of cardholders 104 (or corresponding to each payment card of the plurality of payment cards 118, it is noted that both phrases are equivalent and mean the same thing as the payment card is always associated with the cardholder and an anomalous card will only belong an anomalous cardholder), the server system 200, via the first ML model 220, may assign a label to one or more payment cards from the plurality of payment cards 118 associated with the plurality of cardholders 104 as anomalous based, at least in part, on the anomaly score corresponding to each cardholder of the plurality of cardholders 104.
However, it may be noted that prior to assigning the label to each payment card, an anomaly threshold may have to be computed with which the anomaly score may be compared, and then based on that, the label may be assigned to the corresponding payment cards 118. Therefore, in an embodiment, the server system 200 may be configured to determine, via the first ML model 220, the anomaly threshold based, at least in part, on predefined legitimate transaction behavior.
In an embodiment, the predefined legitimate transaction behavior may refer to a payment transaction behavior of the payment cards 118 at the ATMs 106 that can be considered as legitimate according to standard policies of AML. For instance, the standard policies may be related to a pattern of payment transactions at the ATMs 106 that is irregular in terms of a count of transactions, an amount of each transaction, a variation in a location of each transaction, not having multiple bank accounts related to a single cardholder, and the like. Thus, based on the predefined legitimate transaction behavior, predefined anomaly detection thresholds may have been set and prestored in the database 204. The server system 200 may choose one threshold value from the database 204 based on an application and requirements of a current scenario. The chosen threshold value may be determined as the anomaly threshold by the server system 200. For instance, the anomaly threshold may be a single numerical value or a range of values.
In a scenario, when the anomaly score may be greater than the anomaly threshold, an anomalous flag may be assigned to the corresponding payment card and the corresponding flagged payment card may be classified under the set of anomalous cards 302. In another when the anomaly score may be less or equal to the anomaly threshold, a non-anomalous flag may be assigned to the corresponding payment card and the corresponding flagged payment card may not be classified under the set of anomalous cards 302 but under a set of legitimate cards. In other words, the server system 200 labels one or more payment cards from the plurality of payment cards associated with the plurality of cardholders 104 as anomalous based, at least in part, on the anomaly score corresponding to each cardholder of the plurality of cardholders 104 being at least greater than the anomaly threshold.
For example, the anomaly threshold may include a range of -3 to +3. In case the anomaly score is outside this range i.e., less than ‘-3’ and greater than ‘+3’, then the payment card having such an anomaly score may be classified under the set of anomalous cards 302 and classified as the otherwise when the anomaly score is within the above-mentioned range. Therefore, it may be noted that the first ML model 220 is trained to learn to determine the behavior pattern of each cardholder to determine which cardholders are acting in an anomalous manner thus, labeling their payment cards as anomalous based on the value of the Z-score. It is further noted that the training process of the first ML model 220 has been explained further with reference to FIG. 4 later in the present disclosure.
Upon determining the set of anomalous cards 302, for detecting ATM-related money laundering activities, an underlying transaction pattern that each anomalous card may be following at various ATMs 106 may have to be determined or identified. This facilitates the server system 200 to successfully track whether the transaction pattern of the payment cards 118 at the ATMs 106 is anomalous or legitimate on a regular basis. In an embodiment, the server system 200 may store information related to historical transactions performed within the specific region via the set of anomalous cards 302 at the plurality of ATMs 106 as the anomalous card data in the database 204, based at least in part, on the payment card-related dataset 218.
To that end, in an embodiment, the server system 200 may be further configured to access the anomalous card data from the database 204. The anomalous card data may include information related to historical transactions performed within the specific region via the set of anomalous cards 302 at the plurality of ATMs 106. Further, the server system 200 may generate an ATM-anomalous card correlation dataset based, at least in part, on the anomalous card data. Further, the server system 200 is configured to generate a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the ATM-anomalous card correlation dataset. Further, the second ML model 222 may be configured to learn or determine a plurality of anomalous transaction patterns associated with the plurality of ATMs 106 based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106. In other words, the second ML model 222 has to learn the correlation between the behavior of the anomalous cards and the correlation between different anomalous cards to determine the plurality of anomalous transaction patterns associated with each ATM of the plurality of ATMs 106.
It may be noted that payment transaction patterns followed by each anomalous card at different merchants may be different from each other, however, the set of anomalous cards 302 may follow similar patterns at the same ATM on a regular basis and/or on a predefined cycle. Therefore, learning the underlying payment transaction pattern of each payment card at each ATM is necessary for detecting anomalous cards that may perform such anomalous transactions at the ATMs 106 in the future. Further, learning the correlation between the one or more anomalous transaction patterns associated with the set of anomalous cards 302 at each ATM by the second ML model 222 may provide information about the underlying payment transaction pattern that may be unique for each ATM.
In a non-limiting example, the second ML model 222 may be an LSTM-based auto-encoder model that is trained using unsupervised learning techniques. It is noted that the process of training and testing the second ML model 222 is similar to that of the first ML model 220, and hence the process is not repeated for the sake of brevity. It is further noted that the training process of the second ML model 222 has been explained further with reference to FIG. 5 later in the present disclosure.
For example, upon completion of the training of the second ML model 222, the second ML model 222 is then fed with the test data such as a second test dataset of the anomalous card-related dataset as an input 322 for each payment card. As may be understood, during the testing phase, at first, the second ML model 222 determines an actual transaction pattern corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106. It is noted that the actual transaction pattern is the actual behavior pattern depicted by a particular cardholder.
Then, the second ML model 222 is configured to determine a predicted output, i.e., predicted transaction pattern as an output 324 as shown in FIG. 3, corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106. It is noted that the predicted output is the behavior pattern that should be depicted by a particular cardholder.
Further, the second ML model 222 generates a pattern error value for each ATM of the plurality of ATMs 106 based, at least in part, on comparing the actual transaction pattern and the predicted transaction pattern for the corresponding ATM. The second ML model 222 then computes a pattern anomaly score for each ATM of the plurality of ATMs 106 based, at least in part, on the pattern error value. Later, the second ML model 222 labels one or more transaction patterns from a plurality of transaction patterns for each ATM of the plurality of ATMs 106 as anomalous based, at least in part, on the pattern anomaly score corresponding to each ATM of the plurality of ATMs 106 being at least greater than a pattern anomaly threshold. Finally, the second ML model 222 determines the plurality of anomalous transaction patterns associated with each ATM of the plurality of ATMs 106 based, at least in part, on aggregating one or more transaction patterns labeled as anomalous.
In another example, upon completion of the training of the second ML model 222, the second ML model 222 may generate a plurality of fine-tuned anomalous card-related latent representations (hereinafter, interchangeably referred to as ‘latent representations 326) corresponding to the plurality of anomalous card-related features upon backpropagating the anomalous card-related loss function value.
Further, in an embodiment, upon determining the plurality of anomalous transaction patterns associated with a subset of anomalous ATMs, the plurality of anomalous transaction patterns may be clustered together, if there exist similar anomalous transaction patterns. To that end, the server system 200 may be configured to train and/or generate the clustering model 328 to cluster identical transaction patterns at each location of the plurality of locations in a single cluster. Herein, the clustering model 328 is substantially similar to the clustering model 224 of FIG. 2.
In one example embodiment, the clustering model 328 may be a clustering algorithm such least one of a K-means model, Hierarchical Clustering Model (HCM), Density-Based Spatial Clustering of Application with Noise (DBSCAN) model, Mean Shift Model (MSM), Gaussian Mixture Model (GMM), a Spatial Clustering Model (SCM) and the like.
Herein, the clustering model 328 is considered to be a K-means model for the sake of explanation hereinafter, and therefore the same should not be construed as a limitation of the present disclosure. As may be understood, the K-means model is a widely used unsupervised ML algorithm used for clustering data. It aims to perform a partition of a given dataset into k clusters, where each data point belongs to the cluster with the nearest mean or centroid. The algorithm iteratively assigns data points to clusters and updates the cluster centroids until convergence.
Further, as may be understood, in the case of the k-means algorithm, the number of clusters (that serves as a hyperparameter of the algorithm) is different at various regions/countries because of local AML rules and AML regulations. For instance, a ‘silhouette coefficient’ may have been used within-cluster sum of squares for measuring the quality of clusters produced by the k-means algorithm.
In a non-limiting example, the pseudo-code for implementing the operation of the k-means model on the clustering model 328 is given below:
Assume ‘k’, consider the Silhouette coefficient to determine an optimal number of clusters;
Randomly initialize k cluster centroids;
Assign each data point to a nearest centroid; and
Re-calculate the centroid for the clusters with assigned datapoints,
Iteratively repeating steps 3 and 4 till the model converges.
It is noted that the clustering model 328 converges when the centroids no longer change significantly or when a maximum number of iterations has been reached. Once the k-means algorithm converges, each data point (anomalous transaction pattern) belongs to a specific cluster based on the nearest centroid.
In a non-limiting example, upon the completion of the training of the clustering model 328, for clustering the plurality of anomalous transaction patterns, the plurality of anomalous transaction patterns is accessed from the second ML model 222. Therefore, in an embodiment, for generating the one or more anomalous transaction clusters, the server system 200 may be caused to access, via the clustering model 328, the plurality of anomalous transaction patterns from the second ML model 222. Further, the server system 200 may be caused to generate, via the clustering model 328, the plurality of anomalous transaction pattern clusters for the subset of anomalous ATMs based, at least in part, on the plurality of anomalous transaction patterns. A graphical representation of the plurality of anomalous transaction clusters (see, 330) is shown in FIG. 3.
It may be noted that the plurality of anomalous transaction pattern clusters are clusters of identical transaction patterns that are anomalous. This means that the plurality of anomalous transaction pattern clusters are transactions that are performed by cardholders 104 that are more likely to be involved in money laundering. Therefore, such transactions may have to be reported to concerned authorities to prevent the occurrence of such activities in the future.
Therefore, upon clustering, in one embodiment, the server system 200 may generate a report (see, 332) to an issuer server (e.g., the issuer server 110) based, at least in part, on the plurality of anomalous transaction pattern clusters. It may be noted that upon the generation of the report, the issuers and/or the AML authorities may take actions to prevent such money laundering activities based on their own set of policies.
In another embodiment, as the plurality of anomalous transaction pattern clusters are location-specific (i.e., the location of the ATM), a location of the corresponding ATMs where the corresponding plurality of anomalous transaction patterns are observed may be determined. This is because there is a possibility that the reason for the occurrence of the plurality of anomalous transaction patterns at such locations may be because the locations themselves are partially or completely involved in money laundering.
Thereafter, the server system 200 may be configured to determine, via the third ML model 334, a plurality of anomalous ATMs from the plurality of ATMs 106 based, at least in part, on the plurality of anomalous transaction pattern clusters associated with each ATM of the plurality of ATMs 106. Herein, the third ML model may include a graph-based semi-supervised ML model. For example, an ATM where the plurality of anomalous transaction patterns is observed may itself be partially or completely assisting money laundering activities, therefore, determining such ATMs also becomes important. It is further noted that the training and operation of the third ML model 334 have been explained further with reference to FIG. 7 later in the present disclosure.
FIG. 4 illustrates a flow diagram representation 400 of a process flow of training of the first ML model 220, in accordance with an embodiment of the present disclosure. In an embodiment, the server system 200 may train and generate the first ML model 220 via the anomalous card detection module 230. It may be noted that the anomalous card detection module 230 may perform the first set of operations to generate the first ML model 220. The first set of operations may be performed iteratively until the performance of the first ML model 220 converges to the first predefined criteria. In an embodiment, the first predefined criteria are a saturation of the card-related loss function value. Herein, the card-related loss function value may get saturated after a plurality of iterations of the first set of operations is performed.
Once the first ML model 220 converges to the first predefined criteria, the first ML model 220 is now completely trained. It may be noted that the first ML model 220 is trained to learn to determine a transaction pattern of a payment card (e.g., the payment card 118(1)) of the payment cards 118 to be one of legitimate and anomalous at one or more locations of the plurality of locations (e.g., the ATMs 106).
As may be understood that the first ML model 220 may be an unsupervised model such as the LSTM model that is trained using deep learning neural networks. As used herein, the term “Long Short-Term Memory (LSTM)” refers to a type of recurrent neural network (RNN) architecture that is widely used for sequential data analysis, such as natural language processing, speech recognition, and time series forecasting. As may be understood, LSTM networks are designed to overcome the limitations of traditional RNNs, which struggle with capturing long-term dependencies in sequential data. Further, it may be noted that, the key feature of LSTM networks may be their ability to selectively retain or forget information over long sequences, enabling them to remember important past information and discard irrelevant information. This is achieved through the use of memory cells and gates (input gate and output gate) that control the flow of information within the network.
Further, in an embodiment, the LSTM model that is used in the current scenario of the present disclosure may be an LSTM-based autoencoder model. In such an embodiment, initially, the first ML model 220 may be generated based on the one or more first model parameters 426. This step may be referred to as a step of model generation (see, 430). For instance, considering that the first ML model 220 is a Long Short-Term Memory (LSTM) based auto encoder model, components such as hidden units, activation function, loss function, and an optimizer have to be initialized before the model is trained. These components may constitute the one or more first model parameters 426.
In an embodiment, the first ML model 220 may include an encoder 308 with one input layer 312 with shape (number of rows, number of inputs), and two hidden layers of shape (number of inputs, 64) and (128) respectively (see, 404 and 406). An output of a second hidden layer 406 of the two hidden layers 404 and 406 generates compressed representations (e.g., the latent representations 314) of input features (e.g., the payment card-related features 306). This step may be referred to as a step of latent representation generation (see, 408).
In an embodiment, the decoder 310 follows the architecture of the encoder 308 with two hidden layers of shape (128, 64) and (64) respectively (see, 410 and 412) followed by an output layer 316. Thus, it may be understood that prior to feeding the input features to the first ML model 220, it has to be converted to sequence data. Then, based on a comparison (see, 414) of the output from the output layer 316 and the input from the input layer 312, a reconstruction loss (e.g., the card-related loss function value 402) is computed and the first ML model 220 is used for training of both the encoder 308 and the decoder 310. This step may be referred to as a step of loss computation (see, 416).
It may also be noted that the first ML model 220 may be trained for specific regions/countries because each region has a different pattern of money withdrawal from ATMs based on their specific rules and regulations. Herein, the card-related loss function value 402 is the metric for model performance as the first ML model 220 is an unsupervised model. Moreover, to improve the model performance, the card-related loss function value 402 may have to be reduced and the one or more first model parameters 426 may have to be optimized. This is achieved, by backpropagating the card-related loss function value 402. Therefore, the card-related loss function value 402 is backpropagated to the input of the first ML model 220. This step may be referred to as a step of backpropagation (see, 418).
In a non-limiting example, the pseudo-code for implementing the training of the first ML model 220 is given below:
Initialize LSTM units and parameters such as hidden units, activation function, loss function, and optimizer (model parameters);
Initialize hyperparameters for the training;
Generate the model;
Generate latent representations for the input features via an encoder;
Determine reconstruction loss;
Backpropagate the reconstruction loss; and
Iteratively repeating steps 3 to 6 till the model converges.

In an embodiment, as mentioned above, the LSTM model may include 3 hidden layers with 128, 64, and 32 units respectively. Further, the activation function, the loss function, and the optimizer may also be chosen. Examples of the activation function may include binary step, linear, sigmoid, rectified linear unit (RELU), and the like. Examples of the loss function may include mean squared error (MSE), binary cross-entropy (BCE), and the like. Examples of the optimizer may include stochastic gradient descent (SGD), Adam, and the like.
Further, in an embodiment, the hyperparameters may include a batch size, a validation split, a number of epochs (iterations), and the like, and these hyperparameters may be initialized accordingly. Furthermore, in an embodiment, the performance of the first ML model 220 may converge when either the validation loss does not decrease for the first predefined consecutive epochs or the number of epochs is greater than a second predefined count of epochs. This step may be referred to as a step of checking whether the performance of the first ML model 220 converged to the first predefined criteria (see, 420). If the performance of the first ML model 220 converges to the first predefined criteria, then the training process stops (see, 422), and if it has not converged yet, then the reconstruction loss backpropagates and training continues (see, 424).
Upon completion of the training of the first ML model 220, the first ML model 220 is used by the anomalous card detection module 230 for determining an actual output corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104. Further, the anomalous card detection module 230 determines a predicted output for a first test dataset of the payment card-related dataset 218 for each payment card. Herein, the predicted output corresponds to each cardholder of the plurality of cardholders 104. Further, the anomalous card detection module 230 generates the error value for each cardholder. This error value is computed for each data point of the first test dataset and the error 318 as computed using Eqn. 1 is the overall error value for the corresponding payment card. Further, the anomalous card detection module 230 computes the anomaly score using Eqn. 2 based on the error value for each payment card. Furthermore, the anomalous card detection module 230 may label one or more payment cards of the payment cards 118 as anomalous when the anomaly score is greater than the anomaly threshold. Based on the label, the set of anomalous cards 302 may be generated.
In an embodiment, it may be noted that, upon determining the set of anomalous cards 302, the set of anomalous cards 302 may be attached with a batch file for every ATM location. Later, a ratio of a batch group count to a number of unique cards may be evaluated by the server system 200 via the anomalous customer detection module 236. Further, if the ratio may be greater than a predefined value then the corresponding ATM may be tagged as an anomalous ATM. Therefore, the anomalous customer detection module 236 may then determine a plurality of anomalous ATMs from the plurality of ATMs 106.
FIG. 5 illustrates a flow diagram representation 500 of a process flow of training of the second ML model 222, in accordance with an embodiment of the present disclosure. In an embodiment, the server system 200 may train and generate the second ML model 222 via the correlation module 232. It may be noted that the correlation module 232 may perform the second set of operations to generate the second ML model 222. The second set of operations may be performed iteratively until the performance of the second ML model 222 converges to the second predefined criteria. In an embodiment, the second predefined criteria are a saturation of the anomalous card-related loss function value. Herein, the anomalous card-related loss function value is saturated after a plurality of iterations of the second set of operations are performed.
Once the performance of the second ML model 222 converges to the second predefined criteria, the second ML model 222 is now completely trained. It may be noted that the second ML model 222 is trained to learn to determine the plurality of anomalous transaction patterns associated with the plurality of ATMs 106. Prior to utilizing the second ML model 222, the correlation module 232 extracts the information related to historical transactions performed within a specific region via the set of anomalous cards at the plurality of ATMs 106. Further, based on this, the ATM-anomalous card correlation dataset.
As may be understood that the second ML model 222 may be an unsupervised model such as the LSTM model that is trained using deep learning neural networks in a way similar to how the first ML model 220 is trained. Therefore, it may be noted that initially, the second ML model 222 is generated based on the one or more second model parameters 504. This step may be referred to as a step of model generation (see, 508). Herein, the one or more second model parameters 504 may be similar to the one or more first model parameters 426.
Further, the correlation module 232 may be configured to generate a plurality of transaction pattern-related features (hereinafter, interchangeably referred to as ‘transaction pattern-related features 506’) corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the ATM-anomalous card correlation dataset.
Further, the transaction pattern-related features 506 are then used to train the second ML model 222. Further, as the second ML model 222 is also an LSTM-based autoencoder model, the second ML model 222 may also include the encoder 308 with one input layer 322 with shape (number of rows, number of inputs), and a hidden layer of shape (number of inputs, 322) (see, 510). An output of a second hidden layer 512 generates compressed representations (e.g., the anomalous card-related latent representations, hereinafter, interchangeably referred to as the latent representations 514) on input features (e.g., the transaction pattern-related features 506). Herein, the latent representations 514 are substantially similar to the latent representations 326 of FIG. 3. This step may be referred to as a step of latent representation generation (see, 516).
Further, in an embodiment, as may be known that the decoder 310 follows the architecture of the encoder 308 followed by the output layer 324. Then, based on a comparison (see, 532) of the output of the output layer 324 and the input from the input layer 322, a reconstruction loss (e.g., the anomalous card-related loss function value 502) is computed and the second ML model 222 is used for training of both the encoder 308 and the decoder 310. This step may be referred to as a step of loss computation (see, 518). In an embodiment, the decoder 310 follows the architecture of the encoder 308 with two hidden layers of shape (128, 64) and (64) respectively (see, 528 and 530) followed by an output layer 324.
It may be noted that the anomalous card-related loss function value 502 is the metric for model performance as the second ML model 222 is an unsupervised model. Moreover, to improve the model performance, the anomalous card-related loss function value 502 may have to be reduced and the one or more second model parameters 504 may have to be optimized. By reducing the anomalous card-related loss function value 502, the latent representations 514 are to be fine-tuned. Therefore, the anomalous card-related loss function value 502 may have to be backpropagated and the one or more second model parameters 504 may have to be optimized. Further, this step may be referred to as a step of backpropagation (see, 520).
In a non-limiting example, the pseudo-code for implementing the training of the second ML model 222 is similar to that of the training of the first ML model 220. Moreover, in an embodiment, the performance of the second ML model 222 may converge when the second predefined criteria are matched by the second ML model 222. This step may be referred to as a step of checking whether the performance of the second ML model 222 converged to the second predefined criteria (see, 522). If the second ML model 222 converges to the second predefined criteria, then the training process stops (see, 526), and if it has not converged yet, then the reconstruction loss backpropagates and training continues (see, 524).
Upon completion of the training of the second ML model 222, in one embodiment, the second ML model 222 is used by the correlation module 232 for generating the predicted output for a second test dataset of the ATM-anomalous card correlation dataset. Therefore, the correlation module 232 generates the ATM-anomalous card correlation dataset based, at least in part, on extracting information related to historical transactions performed within a specific region via the set of anomalous cards 302 at a plurality of ATMs 106. More specifically, the correlation module 232 is configured to extract the information related to historical transactions performed using the set of anomalous cards 302 at the plurality of ATMs 106 to generate the ATM-anomalous card correlation dataset based, at least in part, on the one or more correlating parameters. In an embodiment, the one or more correlating parameters may include at least a location, a location identity (ID), an issuer ID, frequency of transactions, withdrawal limits, geographic dispersion, timing, use of multiple payment accounts, and the like. Further, the correlation module 232 is configured to generate a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the ATM-anomalous card correlation dataset. In various non-limiting examples, the plurality of transaction pattern-related features corresponding to each ATM include at least a transaction amount pattern, a transaction time pattern, and the like.
In another embodiment, the correlation module 232 is configured to generate the plurality of fine-tuned anomalous card-related latent representations corresponding to the transaction pattern-related features 506.
FIG. 6 illustrates a timing diagram representation 600 for showing the clustering of unique anomalous transaction patterns of an example set of transactions, in accordance with an embodiment of the present disclosure. In a non-limiting example, the example set of transactions may include a set of anomalous transactions associated with an anomalous card 118(4) of the set of anomalous cards (e.g., the set of anomalous cards 302) at an ATM 106(1), and that may be high-velocity transactions. Herein, the set of anomalous cards 302 may be a subset of the payment cards 118(1)-118(N), therefore, the payment card 118(4) may be detected to be anomalous.
As may be understood that a feature of high-velocity transactions can be considered as one of the factors based on which a set of transactions can be classified as being anomalous. Herein, anything that is identified as anomalous is considered to be most likely to be engaged in money laundering activities. For instance, a set of transactions that the payment card 118(4) may have been performed at the ATM 106(1) may include successive transactions of a predefined amount with a time difference between such successive transactions being less than a predefined time period. In an example, the predefined amount may include a maximum transaction limit at the ATM 106(1) and the predefined time period may include 5 minutes, 10 minutes, 15 minutes, etc.
Thus, as may be observed from FIG. 6, an amount of 2000000 pesos is been withdrawn from the ATM 106(1) for a first predefined count of consecutive transactions within an interval of about 5 minutes, the denomination differing only for the last few transactions. For example, the first predefined count may include about 10 or more. This type of transaction can be considered as one type of pattern or may be referred to as a pattern type 1 (see, 602) as shown in FIG. 6. This type of transaction may be carried by one payment card or more than one payment card. However, since the amount is huge, it is a maximum transaction limit of the ATM 106(1) and the velocity of the transactions is also high, such a transaction pattern may be classified as anomalous. Therefore, a payment card that performed ATM transactions having such a pattern may be classified under the set of anomalous cards 302.
Similarly, another pattern includes an amount of about 900000 pesos being withdrawn for a long period of time by one card and one particular location (e.g., the ATM 106(1)). This type of transaction can be considered as another type of pattern or may be referred to as a pattern type 2 (see, 604) as shown in FIG. 6. This type of transaction may be carried by one payment card or more than one payment card. However, since the amount is huge, it is a maximum transaction limit of the ATM 106(1) and the velocity of the transactions is also high, such a transaction pattern may be classified to be anomalous. Therefore, a payment card that performed ATM transactions having such a pattern may also be classified under the set of anomalous cards 302.
Further, identifying the correlation between such transactions to be the amount being very high among all and having a high velocity of transactions provides the location-specific correlation dataset for each type of pattern (602 and 604). Upon determining the correlation and when the correlation turns out to be resembling a predefined anomalous behavior then, identical anomalous transactions are clustered together. Later, a report may be generated stating the occurrence of such anomalous transactions and transmitted to the issuers and/or AML authorities for them to take certain actions to prevent such money laundering activities at ATMs 106. Moreover, the ATM 106(1) at which such a pattern is practiced may be identified to be anomalous too as such anomalous transaction patterns are determined to be practiced there, and hence can be considered to be most likely to be involved in money laundering.
FIG. 7 illustrates a block diagram representation 700 of a process flow of identifying anomalous customers engaged in money laundering, in accordance with an embodiment of the present disclosure. In an embodiment, a network of the payment cards 118 and the ATMs 106 may have a corresponding network of the payment cards 118 and issuers and/or acquirers associated with the payment cards 118 and the ATMs 106. In such a network some components are legitimate and some are anomalous, however, not all the components are provided with such a label. Therefore, a graph-based semi-supervised ML model can be used for identifying anomalous customers that are most likely to be involved in money laundering as it may be known that some of the components of the network may be labeled to be either anomalous or legitimate. In an embodiment, the anomalous customer detection module 236 is configured to determine, via the third ML model 334, a plurality of anomalous ATMs from the plurality of ATMs 106 based, at least in part, on the plurality of anomalous transaction pattern clusters associated with each ATM of the plurality of ATMs 106. Herein, the third ML model 334 may include the graph-based semi-supervised ML model.
Further, for labeling the unlabeled nodes, there exist multiple techniques such as a graph sample and aggregated (GraphSAGE) approach. As used herein, the term “GraphSAGE approach” is a graph-based approach that uses a graph neural network (GNN) algorithm that is used for learning node representations in a graph. It aims to generate embeddings for nodes by aggregating information from their local neighborhood.
Further, in the case of determining the plurality of anomalous ATMs such an approach may be used for labeling unlabeled nodes, then a graph 702 is shown in FIG. 7 may be considered having nodes A, B, C, D, E, and F that are part of a labeled group of nodes named VL. The graph 702 also includes nodes, U, V, W, X, Y, and Z which are part of an unlabeled group of nodes named VU. Both the labeled nodes and the unlabeled nodes may be interconnected with each other as shown in FIG. 7 via edges. Herein, edges between the nodes may determine a relation between the nodes which generally is a payment transaction between the neighboring nodes.
It may be noted that labels assigned to the nodes in the labeled group VL may include label ‘L1’ to nodes C, D, E, and F and label ‘L2’ to nodes A and B. Herein, suppose the label ‘L1’ may correspond to a legitimate node and the label ‘L2’ an anomalous node. Further, each node may be associated with respective features such as ‘X’. Therefore, the graph 702 of the network is shown in FIG. 7 is a heterogeneous graph as it has both labeled nodes and unlabeled nodes.
Upon generating the graph 702, the next step in the GraphSAGE approach includes performing neighborhood sampling 704 to limit the computation and memory requirements by focusing on a local region of the graph 702. In this step, a fixed-size neighborhood for each node in the graph 702 is sampled. This neighborhood consists of the immediate neighbors or a randomly sampled subset of neighbors. Therefore, a subset of the nodes may be VSUB including nodes A, B, C, U, V, and X.
The next step is to perform feature aggregation 706, in which features of the neighboring nodes of each node are aggregated and combined in a meaningful way. Examples of the feature aggregation 706 may include mean, sum, or concatenation of the neighbor features.
Further, the third ML model 334 such as a GraphSAGE model associated with the GraphSAGE approach uses neural networks to learn node representations from the aggregated features upon training the GraphSAGE model by a process of ML-based model training 708. Therefore, initially, the node representations (or node embeddings) are generated by a process of node embeddings generation 710. Once the GraphSAGE model learns the node representations, it can be evaluated on various tasks to assess its performance, and applications that can use such a model may include recommendation systems, social network analysis, knowledge graph embedding, and the like.
In a non-limiting example, the pseudo-code for implementing the training and using the third ML model 334 is given below:
Pre-training
Initialize the node embeddings for each node type in the graph, including both labeled nodes and unlabeled nodes;
b. Select a subset of nodes VSUB from VL and VU for the specific node type;
c. Perform multiple iterations of neighborhood sampling and aggregation:
i. Sample the k-hop neighborhood for each node in VSUB, considering the specific node type;
ii. Aggregate the features of the sampled nodes using a message-passing mechanism (e.g., mean or max pooling); and
iii. Update the node embeddings based on the aggregated features;
d. Repeat step c for a specified number of iterations; and
e. After pre-training, each node in VL and VU for the specific node type has a learned representation or embedding;
Fine-tuning:
a. Initialize a classifier (e.g., softmax classifier) on top of the learned node embeddings for the specific node type;
b. Use the labeled nodes VL and their associated labels YL to train the classifier;
c. Update the classifier's parameters using a suitable optimization algorithm (e.g., stochastic gradient descent); and
d. Repeat the training process until convergence or a specified number of epochs.
Node Labeling:
a. After the classifier is trained, use it to predict labels for the unlabeled nodes VU for the specific node type;
b. Apply the trained classifier to the node embeddings of the unlabeled nodes; and
c. Assign labels to the unlabeled nodes based on the predicted probabilities or the most probable class;
Output: The labeled nodes VL and the newly labeled nodes from step 3c for the specific node type.
It may be noted that the step of pre-training includes performing neighborhood sampling 704 and feature aggregation 706, followed by fine-tuning using a classifier and updating the node embeddings. Finally, the algorithm predicts labels for the unlabeled nodes based on the trained classifier and generate a set of newly labeled group of nodes indicating anomalous customers (see, 712), and this step may be referred to as node labeling 714. Therefore, this is how anomalous customers such as anomalous ATMs are identified that are engaged in money laundering.
FIG. 8A illustrates a process flow diagram depicting a method 800 of a determination of a set of anomalous cards (e.g., the set of anomalous cards 302) via a first Machine Learning (ML) model (e.g., the first ML model 220), 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 a server system (e.g., the server system 200), an actual output corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104.
At 804, the method 800 includes determining, by the server system 200, a predicted output corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders 104.
At 806, the method 800 includes generating, by the server system 200, an error value for each cardholder of the plurality of cardholders 104 based, at least in part, on comparing the actual output and the predicted output for the corresponding cardholder.
At 808, the method 800 includes computing, by the server system 200, an anomaly score for each cardholder of the plurality of cardholders104 based, at least in part, on the error value and predefined score computation criteria.
At 810, the method 800 includes labeling, by the server system 200, one or more payment cards from the plurality of payment cards 118 associated with the plurality of cardholders 104 as anomalous based, at least in part, on the anomaly score corresponding to each cardholder of the plurality of cardholders 104 being at least greater than an anomaly threshold.
At 812, the method 800 includes generating, by the server system 200, the set of anomalous cards 302 from the plurality of payment cards 118 based, at least in part, on aggregating the one or more payment cards labeled as anomalous.
FIG. 8B illustrates a process flow diagram depicting a method 820 for determining a set of anomalous cards (e.g., the set of anomalous cards 302), in accordance with an embodiment of the present disclosure. The method 820 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 820 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 820, and combinations of operations in the method 820 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 820. The process flow starts at operation 822.
At 822, the method 820 includes accessing, by a server system (e.g., the server system 200), a payment card-related dataset (e.g., the payment card-related dataset 218) from a database (e.g., the database 204) associated with the server system 200. Herein, the payment card-related dataset 218 may include information related to historical transactions performed by a plurality of cardholders (e.g., the cardholders 104) via a plurality of payment cards (e.g., the payment cards 118) at a plurality of merchants.
At 824, the method 820 includes generating, by the server system 200, a plurality of payment card-related features (e.g., the payment card-related features 306) corresponding to each cardholder of the plurality of cardholders 104 based, at least in part, on the payment card-related dataset 218.
At 826, the method 820 includes determining, by the server system 200 via a first machine learning (ML) model (e.g., the first ML model 220), a set of anomalous cards (e.g., the set of anomalous cards 302) from the plurality of payment cards 118 based, at least in part, on the plurality of payment card-related features 306 corresponding to each cardholder of the plurality of cardholders and an anomaly threshold.
At 828, the method 820 includes storing, by the server system 200, information related to historical transactions performed within the specific region via the set of anomalous cards 302 at a plurality of Automated Teller Machines (ATMs) (e.g., the ATMs 106) as anomalous card data in the database 204, based at least in part, on the payment card-related dataset 218.
FIG. 8C illustrates a process flow diagram depicting a method 840 for detecting anomalous transaction patterns at Automated Teller Machines (ATMs), in accordance with an embodiment of the present disclosure. The method 840 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 840 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 840, and combinations of operations in the method 840 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 840. The process flow starts at operation 842.
At 842, the method 840 includes accessing, by a server system (e.g., the server system 200) anomalous card data from a database (e.g., the database 204) associated with the server system 200. In an embodiment, the anomalous card data may include information related to historical transactions performed within a specific region via a set of anomalous cards (e.g., the set of anomalous cards 302) at a plurality of ATMs (e.g., the ATMs 106).
At 844, the method 840 includes generating, by the server system 200, an ATM-anomalous card correlation dataset based, at least in part, on the anomalous card data.
At 846, the method 840 includes generating, by the server system 200, a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the ATM-anomalous card correlation dataset.
At 848, the method 840 includes determining, by the server system 200 via a second ML model (e.g., the second ML model 222), a plurality of anomalous transaction patterns associated with the plurality of ATMs 106 based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106.
At 850, the method 840 includes generating, by the server system 200 via a clustering model (e.g., the clustering model 328), a plurality of anomalous transaction pattern clusters for the plurality of ATMs 106 based, at least in part, on the plurality of anomalous transaction patterns. Herein, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponds to a corresponding ATM from the plurality of ATMs 106.
At 852, the method 840 includes generating and transmitting, by the server system 200, a report to an issuer server (e.g., the issuer server 110) based, at least in part, on at least one of the plurality of anomalous transaction pattern clusters.
FIG. 8D illustrates a process flow diagram depicting a method 860 for determining a plurality of anomalous transaction patterns associated with a plurality of ATMs 106, in accordance with an embodiment of the present disclosure. The method 860 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 860 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 860, and combinations of operations in the method 860 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 860. The process flow starts at operation 862.
At 862, the method 860 includes determining, by a server system (e.g., the server system 200), an actual transaction pattern corresponding to each ATM of a plurality of ATMs (e.g., the ATMs 106) based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106.
At 86, the method 860 includes determining, by the server system 200, a predicted transaction pattern corresponding to each ATM of the plurality of ATMs 106 based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs 106.
At 866, the method 860 includes generating, by the server system 200, a pattern error value for each ATM of the plurality of ATMs 106 based, at least in part, on comparing the actual transaction pattern and the predicted transaction pattern for the corresponding ATM.
At 868, the method 860 includes computing, by the server system 200, a pattern anomaly score for each ATM of the plurality of ATMs 106 based, at least in part, on the pattern error value.
At 870, the method 860 includes labeling, by the server system 200, one or more transaction patterns from a plurality of transaction patterns for each ATM of the plurality of ATMs 106 as anomalous based, at least in part, on the pattern anomaly score corresponding to each ATM of the plurality of ATMs 106 being at least greater than a pattern anomaly threshold.
At 872, the method 860 includes determining, by the server system 200, the plurality of anomalous transaction patterns associated with each ATM of the plurality of ATMs 106 based, at least in part, on aggregating the one or more transaction patterns labeled as anomalous.
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, that provides a payment card. In an embodiment, the merchant may be an ATM (e.g., the ATM 106(1)). 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, the contact information of the merchant (ATM), 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 merchant 106, and account identification information) in a transaction database 908. The details of the merchant 106 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 104. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction.
FIG. 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 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, the contact information of the cardholders (e.g., the cardholders 104(1)-104(N)), a bank account number, availability of funds in the account, payment card details, transaction details, payment account details, and/or the like. Further, the storage module 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 104 may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholders 104.
The processing module 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, 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 cardholders 104(1)-104(N)) may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholders 104.
FIG. 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 the 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. 8A-8D, 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 from those which, are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:1. A computer-implemented method, comprising:
accessing, by a server system, anomalous card data from a database associated with the server system, the anomalous card data comprising information related to historical transactions performed within a specific region via a set of anomalous cards at a plurality of ATMs;
generating, by the server system, an Automatic Teller Machine (ATM)-anomalous card correlation dataset based, at least in part, on the anomalous card data;
generating, by the server system, a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs based, at least in part, on the ATM-anomalous card correlation dataset;
determining, by the server system via a second Machine Learning (ML) model, a plurality of anomalous transaction patterns associated with the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
generating, by the server system via a clustering model, a plurality of anomalous transaction pattern clusters for the plurality of ATMs based, at least in part, on the plurality of anomalous transaction patterns, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponding to a corresponding ATM from the plurality of ATMs; and
generating and transmitting, by the server system, a report to an issuer server based, at least in part, on the plurality of anomalous transaction pattern clusters.

2. The computer-implemented method as claimed in claim 1, further comprising:
accessing, by the server system, a payment card-related dataset from the database, the payment card-related dataset comprising information related to historical transactions performed within the specific region by a plurality of cardholders via a plurality of payment cards at a plurality of merchants;
generating, by the server system, a plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders based, at least in part, on the payment card-related dataset;
determining, by the server system via a first ML model, the set of anomalous cards from the plurality of payment cards based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders and an anomaly threshold; and
storing, by the server system, information related to historical transactions performed within the specific region via the set of anomalous cards at the plurality of ATMs as the anomalous card data in the database, based at least in part, on the payment card-related dataset.

3. The computer-implemented method as claimed in claim 2, wherein the plurality of payment card-related features corresponding to each cardholder comprises at least a daily total transaction amount, a daily unique denomination amount, a daily transaction count, total unique ATM locations, daily average transaction time, daily average transaction amount, and total standalone transactions within a predefined time.

4. The computer-implemented method as claimed in claim 1, wherein the plurality of transaction pattern-related features corresponding to each ATM comprises at least a transaction amount pattern and a transaction time pattern.

5. The computer-implemented method as claimed in claim 2, further comprising:
generating, by the server system, the first ML model based, at least in part, on performing a first set of operations iteratively till performance of the first ML model converges to first predefined criteria, the first set of operations comprising:
generating, by the server system, the first ML model based, at least in part, on one or more first model parameters;
determining, by the server system via the first ML model, a plurality of card-related latent representations for the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders;
computing, by the server system, a card-related loss function value based, at least in part, on the plurality of card-related latent representations corresponding to each cardholder of the plurality of cardholders; and
optimizing, by the server system, the one or more first model parameters associated with the first ML model based, at least in part, on back-propagating the card-related loss function value.

6. The computer-implemented method as claimed in claim 5, wherein the first predefined criteria is a saturation of the card-related loss function value, the card-related loss function value being saturated after a plurality of iterations of the first set of operations is performed.

7. The computer-implemented method as claimed in claim 2, wherein determining the set of anomalous cards from the plurality of payment cards via the first ML model, further comprises:
determining, by the server system, an actual output corresponding to each cardholder of the plurality of cardholders based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders;
determining, by the server system, a predicted output corresponding to each cardholder of the plurality of cardholders based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders;
generating, by the server system, an error value for each cardholder of the plurality of cardholders based, at least in part, on comparing the actual output and the predicted output for the corresponding each cardholder;
computing, by the server system, an anomaly score for each cardholder of the plurality of cardholders based, at least in part, on the error value and predefined score computation criteria;
labeling, by the server system, one or more payment cards from the plurality of payment cards associated with the plurality of cardholders as anomalous based, at least in part, on the anomaly score corresponding to each cardholder of the plurality of cardholders being at least greater than the anomaly threshold; and
generating, by the server system, the set of anomalous cards from the plurality of payment cards based, at least in part, on aggregating the one or more payment cards labeled as anomalous.

8. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, the second ML model based, at least in part, on performing a second set of operations iteratively till performance of the second ML model converges to second predefined criteria, the second set of operations comprising:
generating, by the server system, the second ML model based, at least in part, on one or more second model parameters;
determining, by the server system via the second ML model, a plurality of anomalous card-related latent representations for the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
computing, by the server system, an anomalous card-related loss function value based, at least in part, on the plurality of anomalous card-related latent representations corresponding to each ATM of the plurality of ATMs; and
optimizing, by the server system, the one or more second model parameters associated with the second ML model, based, at least in part, on back-propagating the anomalous card-related loss function value.

9. The computer-implemented method as claimed in claim 8, wherein the second predefined criteria is a saturation of the anomalous card-related loss function value, the anomalous card-related loss function value being saturated after multiple iterations of the second set of operations is performed.

10. The computer-implemented method as claimed in claim 1, wherein determining the plurality of anomalous transaction patterns associated with the plurality of ATMs via the second ML model, further comprises:
determining, by the server system, an actual transaction pattern corresponding to each ATM of the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
determining, by the server system, a predicted transaction pattern corresponding to each ATM of the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
generating, by the server system, a pattern error value for each ATM of the plurality of ATMs based, at least in part, on comparing the actual transaction pattern and the predicted transaction pattern for the corresponding ATM;
computing, by the server system, a pattern anomaly score for each ATM of the plurality of ATMs based, at least in part, on the pattern error value;
labeling, by the server system, one or more transaction patterns from a plurality of transaction patterns for each ATM of the plurality of ATMs as anomalous based, at least in part, on the pattern anomaly score corresponding to each ATM of the plurality of ATMs being at least greater than a pattern anomaly threshold; and
determining, by the server system, the plurality of anomalous transaction patterns associated with each ATM of the plurality of ATMs based, at least in part, on aggregating the one or more transaction patterns labeled as anomalous.

11. The computer-implemented method as claimed in claim 2, wherein the first ML model and the second ML model are unsupervised Long-Short Term Memory (LSTM) based auto encoder models, and the clustering model is at least one of a K-means model, Hierarchical Clustering Model (HCM), Density-Based Spatial Clustering of Application with Noise (DBSCAN) model, Mean Shift Model (MSM), Gaussian Mixture Model (GMM), and a Spatial Clustering Model (SCM).

12. The computer-implemented method as claimed in claim 1, further comprising:
determining, by the server system via a third ML model, a plurality of anomalous ATMs from the plurality of ATMs based, at least in part, on the plurality of anomalous transaction pattern clusters associated with each ATM of the plurality of ATMs, wherein the third ML model comprises a graph-based semi-supervised ML model.

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

14. A server system, comprising:
a communication interface;
a memory comprising executable instructions; and
a processor communicably coupled to the communication interface and the memory, the processor configured to cause the server system to at least:
access anomalous card data from a database associated with the server system, the anomalous card data comprising information related to historical transactions performed within a specific region via a set of anomalous cards at a plurality of ATMs;
generate an Automatic Teller Machine (ATM)-anomalous card correlation dataset based, at least in part, on the anomalous card data;
generate a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs based, at least in part, on the ATM-anomalous card correlation dataset;
determine, via a second Machine Learning (ML) model, a plurality of anomalous transaction patterns associated with the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
generate, via a clustering model, a plurality of anomalous transaction pattern clusters for the plurality of ATMs based, at least in part, on the plurality of anomalous transaction patterns, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponding to a corresponding ATM from the plurality of ATMs; and
generate and transmit a report to an issuer server based, at least in part, on the plurality of anomalous transaction pattern clusters.

15. The server system as claimed in claim 14, wherein the server system is further caused to:
access a payment card-related dataset from the database, the payment card-related dataset comprising information related to historical transactions performed within the specific region by a plurality of cardholders via a plurality of payment cards at a plurality of merchants;
generate a plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders based, at least in part, on the payment card-related dataset;
determine, via a first ML model, a set of anomalous cards from the plurality of payment cards based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders and an anomaly threshold; and
store information related to historical transactions performed within the specific region via the set of anomalous cards at the plurality of ATMs as the anomalous card data in the database, based at least in part, on the payment card-related dataset.

16. The server system as claimed in claim 15, wherein the server system is further caused to:
generate the first ML model based, at least in part, on performing a first set of operations iteratively till performance of the first ML model converges to first predefined criteria, the first set of operations comprising:
generate the first ML model based, at least in part, on one or more first model parameters;
determine via the first ML model, a plurality of card-related latent representations for the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders;
compute a card-related loss function value based, at least in part, on the plurality of card-related latent representations corresponding to each cardholder of the plurality of cardholders; and
optimize the one or more first model parameters associated with the first ML model, based, at least in part, on back-propagating the card-related loss function value.

17. The server system as claimed in claim 15, wherein to determine the set of anomalous cards from the plurality of payment cards via the first ML model, the system is further caused to:
determine an actual output corresponding to each cardholder of the plurality of cardholders based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders;
determine a predicted output corresponding to each cardholder of the plurality of cardholders based, at least in part, on the plurality of payment card-related features corresponding to each cardholder of the plurality of cardholders;
generate an error value for each cardholder of the plurality of cardholders based, at least in part, on comparing the actual output and the predicted output for the corresponding each cardholder;
compute an anomaly score for each cardholder of the plurality of cardholders based, at least in part, on the error value and predefined score computation criteria;
label one or more payment cards from the plurality of payment cards associated with the plurality of cardholders as anomalous based, at least in part, on the anomaly score corresponding to each cardholder of the plurality of cardholders being at least greater than the anomaly threshold; and
generate the set of anomalous cards from the plurality of payment cards based, at least in part, on aggregating the one or more payment cards labeled as anomalous.

18. The server system as claimed in claim 14, wherein the server system is further caused to:
generate the second ML model based, at least in part, on performing a second set of operations iteratively till performance of the second ML model converges to a second predefined criteria, the second set of operations comprising:
generate the second ML model based, at least in part, on one or more second model parameters;
determine via the second ML model, a plurality of anomalous card-related latent representations for the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
compute an anomalous card-related loss function value based, at least in part, on the plurality of anomalous card-related latent representations corresponding to each ATM of the plurality of ATMs; and
optimize the one or more second model parameters associated with the second ML model, based, at least in part, on back-propagating the anomalous card-related loss function value.

19. The server system as claimed in claim 14, wherein to determine the plurality of anomalous transaction patterns associated with the plurality of ATMs via the second ML model, the server system is further caused to:
determine an actual transaction pattern corresponding to each ATM of the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
determine a predicted transaction pattern corresponding to each ATM of the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
generate a pattern error value for each ATM of the ATMs based, at least in part, on comparing the actual transaction pattern and the predicted transaction pattern for the corresponding ATM;
compute a pattern anomaly score for each ATM of the plurality of ATMs based, at least in part, on the pattern error value;
label one or more transaction patterns from a plurality of transaction patterns for each ATM of the plurality of ATMs as anomalous based, at least in part, on the pattern anomaly score corresponding to each ATM of the plurality of ATMs being at least greater than a pattern anomaly threshold; and
determine the plurality of anomalous transaction patterns associated with each ATM of the plurality of ATMs based, at least in part, on aggregating the one or more transaction patterns labeled as anomalous.

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, by the server system, anomalous card data from a database associated with the server system, the anomalous card data comprising information related to historical transactions performed within a specific region via a set of anomalous cards at a plurality of ATMs;
generating an Automatic Teller Machine (ATM)-anomalous card correlation dataset based, at least in part, on the anomalous card data;
generating a plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs based, at least in part, on the ATM-anomalous card correlation dataset;
determining via a second Machine Learning (ML) model, a plurality of anomalous transaction patterns associated with the plurality of ATMs based, at least in part, on the plurality of transaction pattern-related features corresponding to each ATM of the plurality of ATMs;
generating, by the server system via a clustering model, a plurality of anomalous transaction pattern clusters for the plurality of ATMs based, at least in part, on the plurality of anomalous transaction patterns, each anomalous transaction pattern cluster of the plurality of anomalous transaction pattern clusters corresponding to a corresponding ATM from the plurality of ATMs; and
generating and transmitting a report to an issuer server based, at least in part, on the plurality of anomalous transaction pattern clusters.